Судить по одному примеру, извините… Судить, не вдаваясь в детали, не разобравшись,…
Конкретно по этому примеру: если необходимо, код для генерации HTML в данном случае можно вынести из метода (в данном случае fixedRender). Получится вызов функции с параметрами. Эта функция может вызывать шаблон, подставлять в него параметры, возвращать результат.
> «Бизнес-логика — в разработке информационных систем — совокупность правил, принципов, зависимостей поведения объектов предметной области (области человеческой деятельности, которую система поддерживает). Иначе можно сказать, что бизнес-логика — это реализация правил и ограничений автоматизируемых операций. Является синонимом термина «логика предметной области» „
Все бы хорошо, и может быть, даже, в Вашем случае это определение вполне соответствует действительности.
Например, в моем случае «бизнес-логика» не более чем бессмыслица (buzz-word). Например, когда читаю в документации «correspondence types are grouped into groups» (нууу… не совсем так, это я для иллюстрации структуры предложения), ни о каком знании, а тем более логике и речи быть не может — разве что о шаманстве.
Тип функции с пред- и постусловиями можно читать так:
«функция гарантирует, что вернет что-то удовлетворяющее пост-условию, если на входе будет что-то, удовлетворяющее пред-условию»
(читать, конечно, надо в техническом смысле, а не в общечеловеческом; получается что-то вроде forall x:A. P(x) -> B(x), где x — входной параметр, P — пред-условие, B — пост-условие)
Ну, я не уверен в том, что можно судить по разработке на Haskell в целом по отдельно взятому посту. :)
> Я не говорю что «всё плохо, ничего не работает», просто качество+количество библиотек еще не доросло до «продакшен» уровня.
Это зависит от сферы применения. Например, для компиляторов Haskell подходит даже сейчас. Какую сферу применения вы имеете в виду?
> Пример: берем задачу, пишем её на haskell, всё хорошо.
> через месяц появляется требование читать данные из excel файлов.
> ещё через месяц — выводить отчёты в pdf
> ещё через месяц — работать с другой системой через soap
> ещё через месяц — добавить красивый web-интерфейс.
Похоже на задачу из бизнеса. Конечно, вряд ли кто-нибудь станет выполнять такие на Haskell. Хотя, кто его знает. :)
Попробуйте Darcs. У него есть свои минусы, да, но зато очень дружественный консольный интерфейс.
Под дружественным понимается «спрашивает вопросы». Например, набираете darcs whatsnew и darcs сам запускает less, показывая вам изменения в репозитарии относительно некоторого baseline. darcs record показывает изменения в репозитарии, спрашивает, «нужно ли вот это изменение записать?» — а вы отвечаете «да», «нет», «запиши сразу все» и т.д. Даже простой запуск darcs без аргументов выдает справку, которую можно просматривать (а не дамп в stdout, как обычно). В общем, более общительный инструмент. :)
Если честно, я бы вообще не вспоминал про монады в данном случае.
Проще было бы показать CPS на примерах, потом заметить, что одна операция (композиция функций в cps) повторяется очень часто и выделить ее в функцию (которая в Cont называется bind).
Радует, что широкие массы потихоньку просвещаются. :)
PS: кстати, может быть. кого-нибудь заинтересует Arrowlets, там тоже скрывается plumbing (в неместном жаргоне можно сказать «абстрагируется поток управления»), только немного по-другому
Но вы ведь уже использовали линейные типы? Что думаете на этот счет? Мне кажется, что линейные типы просто офигенны. Ну точнее, мне совсем не это кажется (и не кажется вовсе), но хабр не располагает к таким дискуссиям.
Можете посмотреть по ссылке ниже, что можно сделать с помощью линейных типов:
В Mercury должно быть то же самое, только вот для вычисления используется, как я понимаю, поиск (даны предикаты/judgements, ищем доказательство/derivation) вместо подстановки. Так вот, есть подозрение, что линейные типы — хорошая, «правильная» штука. Надо, конечно, побольше конструктивных свидетельств этому подготовить, и глядишь, в следующем Mainstream PL будут линейные типы.
Насколько я знаю, в Mercury есть линейные типы. Этот самый World наверное имеет линейный тип? И правила такие же, наверное, как в линейной логике (предположение линейного типа можно использовать один раз).
И еще такой вопрос: в статье на википедии написано, что Mercury сочетает логическое программирование с функциональным. Предполагаю, что, например, алгоритм проверки типов на нем реализовывать — сплошное удовольствие. Это так?
> на данный момент есть Cloud IDE, можно считать что это аналог REPL
Посмотрел — интересно, правда, REPL не нашел.
> К примеру, вам нужно иметь возможность загрузки и обработки фото при разработке Rich Web клиента с использованием JS.
Получается, что в этом случае есть уже что-то готовое, а интеграцию сервера и клиента уже решили. А если нет? Процесс разработки чем-нибудь различается?
Ваши API позволяют как-нибудь *снизить* количество возможных ошибок в коде пользователя? Для примера: допустим, понятно, что вызывать fopen() с пустым именем файла — это напрашиваться на неприятности. Hivext может с этим помочь, предоставив какие-нибудь средства для анализа/проверки?
> Интересно, в таком случае, какова Ваша оценка экономии времени разработки?
В данном случае существенная, но меня интересует самый худший вариант: когда ничего нет, ничего не подходит, нужно написать свое. (Ни в коем случае не хочу говорить, что только такие варианты имеют место быть.)
> ну не знаю… целью статьи донести к читателю где реально можно экономить больше.
Когда пишут, что все просто отлично, то у меня, например, возникает чувство, что где-то накалывают. :) Поэтому такой вопрос.
> И что, это действительно круто все так же программировать функции, а не объекты?
Странный скачок в рассуждениях. Мое предложение было про то, что у ООП тоже есть проблемы, и не везде оно применимо. Ваше предложение — противопоставление функций и объектов, да еще и с «круто»/«не круто». В чем ваш пойнт?
> Бытует мнение, что облачные платформы в недалеком будущем станут раем для приложений, и рано или поздно почти все приложения будут жить «на небесах».
Примерно то же говорили про ООП, компонентное ПО, потом SOA, «облака», SaaS, теперь PaaS. История повторяется. :)
> В основном, платформы разделяют на три группы, относительно уровня виртуализации:
> * Облачные хостинги
> * Облачные контейнеры
> * Облачные сервисы
Получается, что платформы классифицируются по признаку «виртуализации». «Хостинги» предоставляют ОС, «контейнеры» предоставляют ОС+вебсервер (сервер приложений) и иногда поддержку того или иного ЯП, «сервисы» предоставляют ОС+сервер приложений+ЯП+библиотеки и фреймворки.
> Самая расходная статья это зарплата сотрудников, а если конкретнее, это зарплата программистов и менеджеров.
Наверное, следует читать «в проектах, которые я видел, самая расходная статья была ...»?
У меня есть вопросы по поводу Hivext. Есть ли какой-нибудь REPL (read-eval print loop)? Можно ли разрабатывать и тестировать компоненты приложения независимо друг от друга (в полной изоляции)? Какую работу облегчают сервисы, конкретнее? Допустим, мне очень не нравится вручную разруливать зависимости ресурсов (скрипты, стили для веб-странички), или например, заниматься отловом ошибок, связанных с неправильным экранированием: хочется работать с синтаксическими деревьями, а не с текстом. :)
Также хотелось бы узнать о *недостатках* PaaS и API Облачных сервисов. Почему в статье об этом ни слова?
Конкретно по этому примеру: если необходимо, код для генерации HTML в данном случае можно вынести из метода (в данном случае fixedRender). Получится вызов функции с параметрами. Эта функция может вызывать шаблон, подставлять в него параметры, возвращать результат.
Все бы хорошо, и может быть, даже, в Вашем случае это определение вполне соответствует действительности.
Например, в моем случае «бизнес-логика» не более чем бессмыслица (buzz-word). Например, когда читаю в документации «correspondence types are grouped into groups» (нууу… не совсем так, это я для иллюстрации структуры предложения), ни о каком знании, а тем более логике и речи быть не может — разве что о шаманстве.
Тип функции с пред- и постусловиями можно читать так:
«функция гарантирует, что вернет что-то удовлетворяющее пост-условию, если на входе будет что-то, удовлетворяющее пред-условию»
(читать, конечно, надо в техническом смысле, а не в общечеловеческом; получается что-то вроде forall x:A. P(x) -> B(x), где x — входной параметр, P — пред-условие, B — пост-условие)
Почитаем-с.
То есть
main(IO) :- print(«hi»,IO), print(«there»,IO).
как короткая форма для
main(IO0,IO1) :- print(«hi»,IO0,IO0'), print(«there»,IO0',IO1).
? Или это не имеет смысла в ЛП? (Просто в одном ФЯП call-by-reference помогает упростить «протаскивание» переменной линейного типа — полезно)
Вот это:
:- type bf_state ---> bf_state(
left :: list(int),
cell :: int,
right :: list(int)
).
напоминает zipper для односвязного списка. :) Судя по описанию в тексте, так и используется.
Вопрос: есть ли какие-нибудь книжки по Mercury? Интересно, как там реализовать, например, структуру данных смежного списка с линейными типами.
Ну, я не уверен в том, что можно судить по разработке на Haskell в целом по отдельно взятому посту. :)
> Я не говорю что «всё плохо, ничего не работает», просто качество+количество библиотек еще не доросло до «продакшен» уровня.
Это зависит от сферы применения. Например, для компиляторов Haskell подходит даже сейчас. Какую сферу применения вы имеете в виду?
> Пример: берем задачу, пишем её на haskell, всё хорошо.
> через месяц появляется требование читать данные из excel файлов.
> ещё через месяц — выводить отчёты в pdf
> ещё через месяц — работать с другой системой через soap
> ещё через месяц — добавить красивый web-интерфейс.
Похоже на задачу из бизнеса. Конечно, вряд ли кто-нибудь станет выполнять такие на Haskell. Хотя, кто его знает. :)
Под дружественным понимается «спрашивает вопросы». Например, набираете darcs whatsnew и darcs сам запускает less, показывая вам изменения в репозитарии относительно некоторого baseline. darcs record показывает изменения в репозитарии, спрашивает, «нужно ли вот это изменение записать?» — а вы отвечаете «да», «нет», «запиши сразу все» и т.д. Даже простой запуск darcs без аргументов выдает справку, которую можно просматривать (а не дамп в stdout, как обычно). В общем, более общительный инструмент. :)
Проще было бы показать CPS на примерах, потом заметить, что одна операция (композиция функций в cps) повторяется очень часто и выделить ее в функцию (которая в Cont называется bind).
Радует, что широкие массы потихоньку просвещаются. :)
PS: кстати, может быть. кого-нибудь заинтересует Arrowlets, там тоже скрывается plumbing (в неместном жаргоне можно сказать «абстрагируется поток управления»), только немного по-другому
Можете посмотреть по ссылке ниже, что можно сделать с помощью линейных типов:
sourceforge.net/mailarchive/forum.php?thread_name=AANLkTinQPh5M-APbeWT1%3D2ebFiL0Kprd2sgkChtZwiiV%40mail.gmail.com&forum_name=ats-lang-users
В Mercury должно быть то же самое, только вот для вычисления используется, как я понимаю, поиск (даны предикаты/judgements, ищем доказательство/derivation) вместо подстановки. Так вот, есть подозрение, что линейные типы — хорошая, «правильная» штука. Надо, конечно, побольше конструктивных свидетельств этому подготовить, и глядишь, в следующем Mainstream PL будут линейные типы.
И еще такой вопрос: в статье на википедии написано, что Mercury сочетает логическое программирование с функциональным. Предполагаю, что, например, алгоритм проверки типов на нем реализовывать — сплошное удовольствие. Это так?
Посмотрел — интересно, правда, REPL не нашел.
> К примеру, вам нужно иметь возможность загрузки и обработки фото при разработке Rich Web клиента с использованием JS.
Получается, что в этом случае есть уже что-то готовое, а интеграцию сервера и клиента уже решили. А если нет? Процесс разработки чем-нибудь различается?
Ваши API позволяют как-нибудь *снизить* количество возможных ошибок в коде пользователя? Для примера: допустим, понятно, что вызывать fopen() с пустым именем файла — это напрашиваться на неприятности. Hivext может с этим помочь, предоставив какие-нибудь средства для анализа/проверки?
> Интересно, в таком случае, какова Ваша оценка экономии времени разработки?
В данном случае существенная, но меня интересует самый худший вариант: когда ничего нет, ничего не подходит, нужно написать свое. (Ни в коем случае не хочу говорить, что только такие варианты имеют место быть.)
> ну не знаю… целью статьи донести к читателю где реально можно экономить больше.
Когда пишут, что все просто отлично, то у меня, например, возникает чувство, что где-то накалывают. :) Поэтому такой вопрос.
> И что, это действительно круто все так же программировать функции, а не объекты?
Странный скачок в рассуждениях. Мое предложение было про то, что у ООП тоже есть проблемы, и не везде оно применимо. Ваше предложение — противопоставление функций и объектов, да еще и с «круто»/«не круто». В чем ваш пойнт?
Примерно то же говорили про ООП, компонентное ПО, потом SOA, «облака», SaaS, теперь PaaS. История повторяется. :)
> В основном, платформы разделяют на три группы, относительно уровня виртуализации:
> * Облачные хостинги
> * Облачные контейнеры
> * Облачные сервисы
Получается, что платформы классифицируются по признаку «виртуализации». «Хостинги» предоставляют ОС, «контейнеры» предоставляют ОС+вебсервер (сервер приложений) и иногда поддержку того или иного ЯП, «сервисы» предоставляют ОС+сервер приложений+ЯП+библиотеки и фреймворки.
> Самая расходная статья это зарплата сотрудников, а если конкретнее, это зарплата программистов и менеджеров.
Наверное, следует читать «в проектах, которые я видел, самая расходная статья была ...»?
У меня есть вопросы по поводу Hivext. Есть ли какой-нибудь REPL (read-eval print loop)? Можно ли разрабатывать и тестировать компоненты приложения независимо друг от друга (в полной изоляции)? Какую работу облегчают сервисы, конкретнее? Допустим, мне очень не нравится вручную разруливать зависимости ресурсов (скрипты, стили для веб-странички), или например, заниматься отловом ошибок, связанных с неправильным экранированием: хочется работать с синтаксическими деревьями, а не с текстом. :)
Также хотелось бы узнать о *недостатках* PaaS и API Облачных сервисов. Почему в статье об этом ни слова?