metaclass | Функциональщина в бухгалтерии

Entry tags:

Функциональщина в бухгалтерии

Самоочевидно ли то, что с помощью filter/map/fold можно реализовать бухгалтерскую отчетность более простым и очевидным образом, чем с помощью select .. where .. group by?

Нет, наверно я хотел задать не этот вопрос. Правильный вопрос: сколько в час денег попросит человек, способный за неделю-две разобраться в вышеописанном вопросе?

Flat | Top-Level Comments Only

А с производительностью все очень просто: первоначальная выборка производится в СУБД, средствами SQL
Ах это...

Нема дурных фетчить 1005000 проводок, даже если считалка отчетов рядом с СУБД запущена :)

Ну да, да - СУБД вам и изоляцию сделает, чтобы все аккуратненько было, и отфильтрует - схеширует, и вот уж тогда поверх наложицо ФП, придавая окончательный шарм всей конструкции.
Особенно сильно ей рады будут невиновные и непричастные. Приходишь - и вместо привычного говоноооп говнофп.
Отличная идея, по-моему.

Разного рода сложносочиненная постобработка на ФП выглядит гораздо гуманнее, чем на SQL.
Хотя бы потому, что структур данных, доступных там, сильно больше, чем одних реляционных множеств кортежей на все про все.

Разного рода сложносочиненная постобработка на ФП выглядит гораздо гуманнее, чем на SQL.
Это вам кажется, что гуманно - по мне так совершенно антигуманно чуть ли не до медицинского уровня.

потому что ты тупой и боишься остаться без работы

Кстати, что-то не припомню я там никаких структур. Множество, список, хеш - ничего выдающегося.

+Алгебраические типы данных, если это не кложурь и прочие лиспы.
+Вектора(массивы)
И возможность комбинировать это все произвольным образом.

Алгебраические типы данных
Ну то есть записи, если по-простому.

+Вектора(массивы)
Ага, массивы - это, оказывается, теперь что-то новое и неизведанное.

>Ну то есть записи, если по-простому.
Это не записи. Записи - декартово произведение, вариантные(АТД) - сумма.

Про массивы - не во всех СУБД они есть в виде пригодных для использования типов.

Это не записи. Записи - декартово произведение
Стало быть, когда я пишу struct thestruct{ int i; char *ptr} - это у меня получается декартово произведение?

Про массивы - не во всех СУБД они есть в виде пригодных для использования типов.
И, что характерно - даже там, где они есть, лучше от их использования воздерживаться.

Да, декартово произведение - значением этой структуры является декартово произведение множеств допустимых значений отдельных полей.

Поистине удивительно, до чего серьезные проблемы удается так ловко решать.

адт -- это варианты (union in C), причём можно комбинировать а структуры данных

такие задачи плохо ложатся в реляционную модель (типа "субъектами договоров могут быть частные лица с паспортом, контакты в скайпе, местные организации с ИНН, госорганы и НКО, а также иностранные предприятия разных стран, в том числе разные офисы ТНК")

да тот же ldap например

в СУБД тогда изобретают разные костыли типа классической object name + { attributes values } с последующей её настройкой по кластерам таблиц

такие задачи плохо ложатся в реляционную модель

Это почему это они плохо ложатся?

потому что произведение в ней есть, а копроизведения нет

Как вы только еще прямохождению не разучились.

>> Алгебраические типы данных
> Ну то есть записи, если по-простому.

АлгТД можно имитировать иерархией расширяемых записей. Одной не обойтись...

Ну да, все лучше, чем водку жрать.

не, ну правда же, что скл это язык для бабушек или там менеджеров в экселе и аксессе. как язык для написания хоть какой-нибудь логики он такая же популярная беда, как vbscript. он просто увы есть, а остановится и сделать что-нибудь нормальное руки не дошли :(

Меня вот прям трогает эта популярнейшая уверенность в том, что все вокруг убогие идиоты и лишь Васе Пупкину с неба недавно была провозглашена истина, причем про тот же "скл" знают обычно не более чем полкнижки "освой самостоятельно sql за 24 часа".

не, ну давайте, давайте переведём его на русский язык. чем плохо: ОБЪЯСНИ ВЫБРАТЬ .. ИЗ .. ГДЕ
отличное программистское 1С решение.
давайте запросы исполнять НАПИШИ ОТВЕТ ПОЖАЙЛУЙСТА

ещё надо DO WHAT I MEAN и WHAT IF

а вообще да, полкнижки, да, все вокруг убогие идиоты. для них системы и пишутся. всё больше программистов с каждом днём - пользователи. я чего.

В общем, изучайте матчасть.
А еще лучше - не изучайне, не надо оно вам. Не дано, так сказать.

(no subject)

vinslivins.livejournal.com - 2013-02-07 09:27 (UTC) - Expand

не, ну реально, почему только в sql надо убивать кучу места и времени, печатая эти длинные слова? чем я это заслужил? почему во всех остальных языках по-человечески, и кто, выходит, убогие идиоты?

Какие "длинные слова"? SQL про краткости вообще какой-то APL напоминает. Хотя, конечно, смотря что писать.
В общем, мой вам совет - бросьте к чертям это дело, посвятите себя семечкам.

(no subject)

vinslivins.livejournal.com - 2013-02-07 09:32 (UTC) - Expand

(no subject)

plumqqz.livejournal.com - 2013-02-07 09:38 (UTC) - Expand

Flat | Top-Level Comments Only