Здравствуйте, VladD2, Вы писали:

VD>Какие еще интерпретаторы? Скала компилируется в байткод Явы и (наверно) можно использовать Явовские отладчики.

Верно! Просто там при встраивании кажется дергается класс Interpreter(точно не помню, завтра прихвачу код и выложу...), то что он компилится в байт код и потом грузится в JVM это понятно.

Я имел в виду общий случай (можно встроить ведь и Groovy?). Что касается отладки то я имел ввиду
именно поддержку со стороны IDE. Проблемма в том что они обычно не могут отлаживать что попало.
Хотя в Netbeans можно подцепить отладчик к произвольному процессу(в т.ч. и удаленно) и отлаживать
при наличии исходников — вот только они, помоему, должны быть уложены в соответствующие проекты.
Поправьте, если ошибаюсь.

Здравствуйте, Gajdalager, Вы писали:

G>А чтобы можно было пользовать мощь гибридного ФП-ИП подхода в промышленном программировании, нужны ещё и библиотеки, написанные с учётом этого подхода (например DB-маппер уровня Хибернейта или враппер над оным) да тулзы разные (к примеру, визуальный редактор GUI)... Вот тогда можно будет писать проекты только на Скале.

Речь не идет о том что писать проекты только на скале. Что касается hibernate, то что мешает его
использовать как есть? С другой стороны, например, для работы с БД я врядли смогу привести много
примеров того куда можно засунуть ФП-шный фишки (например RowMapper в Spring, если делать через
анонминый класс то это почти лямбда). Что касается GUI через ФП — тут моя фантазий пасует... (во всем
виноват Swing ).

По поводу того что бизнес логика это форточки — категорически не согласен! Форточки это представления
результатов каких-то операций проведенных в соответствии с БЛ, а сама БЛ может быть очнеь даже сложной и включать себя работу с несколькими БД, уадаленные вызовы и т.д.

>>Это из разряда "87.34569712% всех приводимых цифр взяты с потолка"?
VGn>Это — придирка к словам.

Мне просто не понравилось утверждение:

Проблемы не в сложности самих задач, а в их количестве, классификации и построении на этой базе архитектуры. ФП на верхнем уровне только усложнит и замедлит этот процесс.

А значит + ещё 1000 кодеров.

Просто +1000 кодеров — это совсем необязательно.

VGn>>Во многих задачах ФП просто не имеет сысла. Имхо формочки на ФП — это бред.

>>А кто говорит о формочках? Мы же говорили о "системах по типу системы, разрабатываемой тысячей разработчиков + сотня архитекторов + сотня аналитиков + толпы манагеров и другого сброда. С соответствующей архитектурой"

VGn>А чем занимается 90% народа при разработке таких систем? Реализацией бизнес-логики.
VGn>А что такое бизнеслогика в крупных корпоративных системах? По большей части формочки.

???

Я честно не понимаю, как бизнес-логика связана с формочками.

Формочки — это интерфейс к бизнес-логике. Средство ввода данных и получения отчетов о проделанной работе. А это средство ввода может быть любым — от формочек до веб-интерфейса до потоковых данных откуда-нибудь с биржи. А бизнес-логика может быть вообще на чем угодно написана. Причем тут формочки — вообще не понимаю

Меня например, долго убеждали, что бизнес-логика должна быть отделена от формочек по-максимуму.

>>Телекоммуникации, data mining — это вполне такие системы. А ФП там применяются.

VGn>Я работаю в телекоммуникациях. У нас ФП не применяется. (Не скажу что это правильно. Но это — факт.)

Ну а в Эрикссоне и Нортеле применяется. И это тоже факт

VGn>Минус поставил, надеясь не отвечать. Потому что считаю такой разговор малосодержательным.

Я просто не понимаю, почему

Проблемы не в сложности самих задач, а в их количестве, классификации и построении на этой базе архитектуры. ФП на верхнем уровне только усложнит и замедлит этот процесс.

Может, их просто надо правильно готовить?

VGn,

>>А кто говорит о формочках? Мы же говорили о "системах по типу системы, разрабатываемой тысячей разработчиков + сотня архитекторов + сотня аналитиков + толпы манагеров и другого сброда. С соответствующей архитектурой"

VGn>А чем занимается 90% народа при разработке таких систем? Реализацией бизнес-логики.
VGn>А что такое бизнеслогика в крупных корпоративных системах? По большей части формочки.

Что-то твои умозрительные заключения противоречат практике.
Advanced programming language design in enterprise software

Мой скромный опыт в enterprise говорит, что подавляющее количество сил и времени уходит на преобразование данных (графические рисунки <-> xml, business rules <-> java, xml1 <-> xml2, xml <-> java, xml <-> sql, string <-> binary etc). А jsp — это туфта. Нам требовалось порядка 90 форм, и мы вшестером их сделали за 2 недели. По готовым метаданным это делалось быстро и совершенно тупо. А можно вообще убрать людей, и купить генератор, например jaxfront.

VD>Более того, ни одна серьеная программа не мыслима без состояния. Фанитики ФП могут говорить, что угодно, но состояние будет обязательно. Просто возможно вместо объектов оно будет храниться в разных монадах, хэш-таблицах процесса и т.п.

В случае ФП контроллируемым значением может быть некая промежуточная (или контрольная) функция (естественно, не без состояния)

__>По поводу того что бизнес логика это форточки — категорически не согласен! Форточки это представления
__>результатов каких-то операций проведенных в соответствии с БЛ, а сама БЛ может быть очнеь даже сложной и включать себя работу с несколькими БД, уадаленные вызовы и т.д.

Наверное, это — камень в мой огород.
Полностью согласен с данным утверждением. Упоминая формочки в качестве основной части бизнес-логики корпоративных систем, я имел в виду верхний уровень абстракции. То, что основные источники, условия и результаты работы находятся именно там.
Из 15 сборок в моём нынешнем проекте к GUI имеют отношение только 2 (причём не самые объёмные). При этом я считаю, что эти самые формочки у меня составляют около 70% бизнес-логики. Остальное — это API и всего-навсего реализация, со всеми БД, AD, шедалерами, ремоутингом, кофигурированием и т.п.
Безусловно, это очень обобщённое утверждение.
Но заказчик думает именно так. И, по большому счёту, он прав.

M>Просто +1000 кодеров — это совсем необязательно.
Рост сложности прямо пропорционален росту трудозатрат.

M>Я честно не понимаю, как бизнес-логика связана с формочками.
M>Формочки — это интерфейс к бизнес-логике. Средство ввода данных и получения отчетов о проделанной работе. А это средство ввода может быть любым — от формочек до веб-интерфейса до потоковых данных откуда-нибудь с биржи. А бизнес-логика может быть вообще на чем угодно написана. Причем тут формочки — вообще не понимаю
M>Меня например, долго убеждали, что бизнес-логика должна быть отделена от формочек по-максимуму.

Если говорить о реализации, то ты прав на все 100%.
Но разговор изначально был о целях. Любой встречный ПМ скажет тебе, что важнее чтобы "Эта иконка была василькового цвета" (с)FightClub,
чем твой способ доступа к БД или протокол передачи данных.

M>Ну а в Эрикссоне и Нортеле применяется. И это тоже факт
Это по большей части системный софт.

M>Я просто не понимаю, почему
M>

M>Проблемы не в сложности самих задач, а в их количестве, классификации и построении на этой базе архитектуры. ФП на верхнем уровне только усложнит и замедлит этот процесс.

M>Может, их просто надо правильно готовить?

Есть рецепты?

Здравствуйте, VGn, Вы писали:

VGn>Полностью согласен с данным утверждением. Упоминая формочки в качестве основной части бизнес-логики корпоративных систем, я имел в виду верхний уровень абстракции. То, что основные источники, условия и результаты работы находятся именно там.
VGn>Из 15 сборок в моём нынешнем проекте к GUI имеют отношение только 2 (причём не самые объёмные). При этом я считаю, что эти самые формочки у меня составляют около 70% бизнес-логики. Остальное — это API и всего-навсего реализация, со всеми БД, AD, шедалерами, ремоутингом, кофигурированием и т.п.
VGn>Безусловно, это очень обобщённое утверждение.
VGn>Но заказчик думает именно так. И, по большому счёту, он прав.

Брр... Очень странно. Что, всё-таки, ты вкладываешь в слово "бизнес-логика"? Представь, что делается система управления какой-то торговлей. Есть, скажем, код, рассчитывающий скидку клиенту по его предыдущим закупкам. Он может использоваться в формочке розничной продажи, формочке оптовой отгрузки со склада, в web-интерфейсе. Ты его будешь копипастить в три места?
Обычно всё-таки стараются отделить слой бизнес-логики от presentation layer.

Здравствуйте, mini_root_2, Вы писали:

__>Здравствуйте, VladD2, Вы писали:

VD>>Какие еще интерпретаторы? Скала компилируется в байткод Явы и (наверно) можно использовать Явовские отладчики.

__>Верно! Просто там при встраивании кажется дергается класс Interpreter(точно не помню, завтра прихвачу код и выложу...), то что он компилится в байт код и потом грузится в JVM это понятно.
Выкладываю:

 BufferedReader reader=new BufferedReader(new InputStreamReader(System.in));
 PrintWriter writer=new PrintWriter(System.out);
 Settings s=new Settings();
 ConsoleReporter r=new ConsoleReporter(s,reader,writer);   
 Interpreter i=new Interpreter(s,r,writer);
 i.interpret("Console.println(2+2)");

А по-поводу того чтобы использовать скалу вместо явы (а не скалу на яве), то пока ну будет нормальной
поддержки со стороны IDE, нормальной документации (а еще лучше книжек) и т.д — особого смысла не вижу.
Кроме того из скалы без проблем можно дергать явовские классы. Вопрос по поводу отладки, как отлаживать:
i.interpret("Console.println(2+2)");

D>Брр... Очень странно. Что, всё-таки, ты вкладываешь в слово "бизнес-логика"? Представь, что делается система управления какой-то торговлей. Есть, скажем, код, рассчитывающий скидку клиенту по его предыдущим закупкам. Он может использоваться в формочке розничной продажи, формочке оптовой отгрузки со склада, в web-интерфейсе. Ты его будешь копипастить в три места?
D>Обычно всё-таки стараются отделить слой бизнес-логики от presentation layer.

Это ты с кем сейчас споришь?

Здравствуйте, VGn, Вы писали:

VGn>Это ты с кем сейчас споришь?

При этом я считаю, что эти самые формочки у меня составляют около 70% бизнес-логики.

Я просто хочу понять, что ты понимаешь под термином бизнес-логика. Я всегда считал, что бизнес-логика — это совокупность правил, принципов и зависимостей в некоторой предметной области. Как формочки могут составлять "правила, принципы и зависимости" — мне не ясно. Ты имеешь в виду, что код, воплощающий эти "правила, принципы и зависимости" реализован в методах формочек? Тогда, ИМХО, 70% — это многовато. Хотя, конечно, от задачи зависит...

D>Обычно всё-таки стараются отделить слой бизнес-логики от presentation layer.

Предлагаю в данном контексте от слова "бизнес-логика" (действительно употребляемого обычно в другом смысле) веруться обратно к "бизнес-уровню" или придумайте сами как это назвать.
Вот только дай людям повод к словам придраться! Блин!

D>Я просто хочу понять, что ты понимаешь под термином бизнес-логика. Я всегда считал, что бизнес-логика — это совокупность правил, принципов и зависимостей в некоторой предметной области.

Значит всегда путал бизнес-логику с бизнес-правилами.
Бизнес-логика — это всего лишь логика работы программы минус системная логика.

M>>Просто +1000 кодеров — это совсем необязательно.
VGn>Рост сложности прямо пропорционален росту трудозатрат.

Почему? И откуда это следует?

Помнится, в Германии надо было гос. портал по поиску работы переделать. Сделать его более удобным в использовании и быстрым. 2 или 3 года, 40 миллионов долларов. Портал так и не сделали.

С другой стороны Flickr, YouTube и даже Google начинались чуть ли не на коленке.

M>>Я честно не понимаю, как бизнес-логика связана с формочками.
M>>Формочки — это интерфейс к бизнес-логике. Средство ввода данных и получения отчетов о проделанной работе. А это средство ввода может быть любым — от формочек до веб-интерфейса до потоковых данных откуда-нибудь с биржи. А бизнес-логика может быть вообще на чем угодно написана. Причем тут формочки — вообще не понимаю
M>>Меня например, долго убеждали, что бизнес-логика должна быть отделена от формочек по-максимуму.

VGn>Если говорить о реализации, то ты прав на все 100%.
VGn>Но разговор изначально был о целях. Любой встречный ПМ скажет тебе, что важнее чтобы "Эта иконка была василькового цвета" (с)FightClub,
VGn>чем твой способ доступа к БД или протокол передачи данных.

Что важнее в системе? Иконка василькового цвета или протокол передачи данных? Пусть иконка будет хоть фотореалистично нарисована, но если протокол передачи данных глючит, то иконка положение не спасет.

Мне интерфейс доступа к данным все равно на чем писать. Хоть на Coldfusion. Мы же не только о формочках говорим. Мы говорим о

системах, разрабатываемых тысячей разработчиков + сотня архитекторов + сотня аналитиков + толпы манагеров и другого сброда. С соответствующей архитектурой.

Пример

If you want to do a simple round-trip from BOS to LAX in two weeks, coming back in three, willing to entertain a 24 hour departure window for both parts, then limiting to "reasonable" routes (at most 3 flights and at most 10 hours or so) you have about 5,000 ways to get there and 5,000 ways to get back. Listing them is a mostly trivial graph-search (there are a few minor complications, but not many), that anybody could do in a fraction of a second.

The real challenge is that a single fixed itinerary (a fixed set of flights from BOS to LAX and a fixed set back) with only two flights in each direction may have more than 10,000 possible combinations of applicable "fares", each fare with complex restrictions that must be checked against the flights and the other fares. That means that the search space for this simple trip is of the order 5000 x 5000 x 10000, and a naive program would need to do a _lot_ of computation just to validate each of these possibilities.

---

Если вы хотите слетать из BOS в LAX и обратно через две недели с возвратом через три, так, чтобы было окно в 24 часа перед вылетом в обе стороны, то ограничение возможных полетов (максимум 3 вылета в течение 10 часов) состоит в выборке из примерно 5000 вариантов полета туда и 5000 вариантов полета оттуда. Список этих полетов достигается простым поиском по графу, которые кто угодно может сделать в долб секунды.

Сама проблема состоит в том, что один фиксированный план полета с только двумя вылетами туда/обратно может содерждать более 10 000 комбинаций стоимости, каждая из которых содержит строгие ограничения, которые должны быть сопоставлены с другими стоимостями и полетами. Таким образом область поиска на одно путешествие — 5000 x 5000 x 10000, и наивной программе придется совершать множество вычислений для тго, чтобы проверить все возможности

Ну и причем в описанной проблеме формочки?

Вот эти формочки: http://www.orbitz.com/ (вверху было описание именно этого сервиса). Эти формочки вполне декларативно описываются в HTML. А вот бизнес логика — это та самая скрытая часть айсберга. И написана она может быть на чем угодно.

Orbitz — это Lisp + C
Ядро Амазона — это Lisp + C

M>>Ну а в Эрикссоне и Нортеле применяется. И это тоже факт
VGn>Это по большей части системный софт.

И? Выдержка из описания AXD 301 switch

Call handling

The following connection types are supported in the AXD 301:
• Permanent connections set up by operator order.
— Point-to-point virtual-path and virtual-channel connections.
— Point-to-multipoint virtual-path and virtual-channel connections.
• On-demand, end-to-end connections set up from subscribers via signaling.
— Point-to-point, virtual-channel connections.
— Point-to-multipoint, virtual-channelconnections.
• Soft permanent, edge-to-edge connections across a PNNI routing domain set up by operator demand.
— Point-to-point, virtual-channel connections.
— Point-to-multipoint, virtual-channelconnections.

For on-demand control of connections, three different signaling protocols are presently supported:
• UNI and Q.2931—for users and private networks; this interface may also be used between public networks when BICI is not supported.
• PNNI—for use between nodes in the same network.
• BICI (B-ISUP)—for use between public networks, between nodes where PNNI is not supported, or between PNNI routing domains within a network.

Ключевые моменты выделены. У операторов/подписчиков вполне могут быть себе формочки для управления/настройки этого самого свитча. Но они не составляют и десятой части всей логики системы. А система вполне себе благополучно написана на функциональном Эрланге.

M>>Я просто не понимаю, почему
M>>

M>>Проблемы не в сложности самих задач, а в их количестве, классификации и построении на этой базе архитектуры. ФП на верхнем уровне только усложнит и замедлит этот процесс.

M>>Может, их просто надо правильно готовить?

VGn>Есть рецепты?

Наверняка есть Народ ведь пишет (см. примеры выше). И более того, радуются, когда пишут

Здравствуйте, VGn, Вы писали:

Здравствуйте, Mikl Kurkov, Вы писали:

MK>Кстати у них на сйте лежит мануал по KDB+, выгодно отличающийся от материалов на родном сайте презентабельностью.

Хм. А я был уверен что это от К-шников дока. Еще удивился, насколько они качественные доки начали делать

Здравствуйте, Mamut, Вы писали:

M>Помнится, в Германии надо было гос. портал по поиску работы переделать. Сделать его более удобным в использовании и быстрым. 2 или 3 года, 40 миллионов долларов. Портал так и не сделали.
Почему-то напомнило эту историю

Здравствуйте, Mirrorer, Вы писали:

M>Здравствуйте, Mikl Kurkov, Вы писали:

MK>>Кстати у них на сйте лежит мануал по KDB+, выгодно отличающийся от материалов на родном сайте презентабельностью.

M>Хм. А я был уверен что это от К-шников дока. Еще удивился, насколько они качественные доки начали делать

Видно, вы ее не читали. Довольно отстойная дока со множеством опечаток. Хорошая книга-дока у KX есть, но, почему-то, не в открытом доступе.

Здравствуйте, Quintanar, Вы писали:

Q>Видно, вы ее не читали. Довольно отстойная дока со множеством опечаток.

Внимательно не читал. Факт. Просмотрел по диагонали.
Но мне просто не с чем было сравнивать. Единственное что до этого я видел по К это Kref 1998 года выпуска. Kref неплохой справочник по языку. Но хоть какое-то общее описание системы я первый раз увидел именно в отстойной доке.

И в ней же с удивлением открыл, что K нормально интегрируется с .NET и Java. Опять же, я не пробовал руками эту интеграцию. Вполне может быть что качество у нее неидеальное.

Q>Хорошая книга-дока у KX есть, но, почему-то, не в открытом доступе.
Жаль