Собственно, о хаскеле в вебе
По мотивам поста и комментов в ru_lambda и соответствующей статьи.
Что я могу сказать. Абстрагируемся от того, что это не continuation-based подход к веб-разработке, а стандартный request-response, в данном случае в виде fastcgi. Хотя смысла при таком подходе использовать чистый функциональный язык я особо не вижу, потому что, минимум половину всей полезной работы занимает разбор стейта и диспетчерезация реквестов (что все мусор, по-хорошему).
Ладно, попробую разобрать собственно код jekor'a.
dispatch "GET" [ "help" ] = articlePage "help"
dispatch "GET" [ "privacy" ] = articlePage "privacy"
dispatch "GET" [ "terms-of-use" ] = articlePage "terms-of-use"
dispatch "GET" [ "source" ] = articlePage "source"
...
dispatch "GET" [ "article", x ] = articlePage x
...
dispatch "GET" [ "link", "new" ] = newLink
dispatch "POST" [ "link", "new" ] = newLink
...
Ну и так далее, там простыня километров на двадцать, разбавленная всякими "case of".
Я, конечно, все понимаю -- статическая типизация, и все такое. Но лично я на лиспе бы сделал (на мой взгляд) приличнее: склеил бы из реквеста символ навроде 'post-link-new, проверил бы его fdefinition (404 при ошибке) и натравил бы funcall. Ну и все, никаких тебе килобайт диспетчеризации, знай, пиши себе функции.
Далее, в том примере практически весь код монадный, все функции начинаются с do :) Какой смысл писать на хаскеле все императивно? Но вон в комментах ru_lambda некий товарищ вроде бы поступил грамотней, но я, в силу своего скудоумия в теории хаскеля, не очень понял, что он написал :) Хотелось бы взглянуть на код.
Теперь, об обработке ошибок. В статье мужик по этому поводу недоволен и жалуется, но я хочу отметить даже не этот момент. По-моему, при выбранном им подходе, писать вебапп на хаскелее -- все равно что на си++: при каждом чихе надо перекомпилировать код и рестартить fastcgi сервер. По мне, так, это боль :) Я уж не говорю про рай в виде CL или erlang, где код можно править прям по-живому, но в данном случае банально удобней даже скриптовые языки.
Про базы данных там сказали (если есть возможность -- базы данных не используйте), пропустим :)
Про хтмл: по-моему, это выглядит позорно:
let xhtml = renderHtml $ header <<
[thetitle << title ,
concatHtml $ map includeDep deps ,
primHtml ""
""
"",
concatHtml head ] +++
body << [headerB ,
jsNotice,
thediv ! [identifer "body" ] << concatHtml body ,
footerB ]
output xhtml
В комментах к посту товарищ что-то там красиво пришет про HStringTemplate и HSP, но, опять же, хотелось бы посмотреть на реальный код.
Короче, как-то все не то. По комфорту это даже не руби, не говоря уж о CL.
Куда бы двигался я: в первую очередь, конечно, в сторону continuation-based фреймворка. Думаю, хаскель туда впишется отменно. Потом, явно надо активней использовать доступные хаскелю средства метапрограммирования, чтобы избегать простыней красивого, статически-типизированного, но все же совершенно бесполезного кода. Ну и что-то надо явно делать с выводом HTML, js, и сборкой SQL. Потому как в коде в виде строк они выглядят совершенно безобразно, даже не принимая во внимание геморрой с обработкой ошибок и от сливания статической типизации в этом месте.
Что я могу сказать. Абстрагируемся от того, что это не continuation-based подход к веб-разработке, а стандартный request-response, в данном случае в виде fastcgi. Хотя смысла при таком подходе использовать чистый функциональный язык я особо не вижу, потому что, минимум половину всей полезной работы занимает разбор стейта и диспетчерезация реквестов (что все мусор, по-хорошему).
Ладно, попробую разобрать собственно код jekor'a.
dispatch "GET" [ "help" ] = articlePage "help"
dispatch "GET" [ "privacy" ] = articlePage "privacy"
dispatch "GET" [ "terms-of-use" ] = articlePage "terms-of-use"
dispatch "GET" [ "source" ] = articlePage "source"
...
dispatch "GET" [ "article", x ] = articlePage x
...
dispatch "GET" [ "link", "new" ] = newLink
dispatch "POST" [ "link", "new" ] = newLink
...
Ну и так далее, там простыня километров на двадцать, разбавленная всякими "case of".
Я, конечно, все понимаю -- статическая типизация, и все такое. Но лично я на лиспе бы сделал (на мой взгляд) приличнее: склеил бы из реквеста символ навроде 'post-link-new, проверил бы его fdefinition (404 при ошибке) и натравил бы funcall. Ну и все, никаких тебе килобайт диспетчеризации, знай, пиши себе функции.
Далее, в том примере практически весь код монадный, все функции начинаются с do :) Какой смысл писать на хаскеле все императивно? Но вон в комментах ru_lambda некий товарищ вроде бы поступил грамотней, но я, в силу своего скудоумия в теории хаскеля, не очень понял, что он написал :) Хотелось бы взглянуть на код.
Теперь, об обработке ошибок. В статье мужик по этому поводу недоволен и жалуется, но я хочу отметить даже не этот момент. По-моему, при выбранном им подходе, писать вебапп на хаскелее -- все равно что на си++: при каждом чихе надо перекомпилировать код и рестартить fastcgi сервер. По мне, так, это боль :) Я уж не говорю про рай в виде CL или erlang, где код можно править прям по-живому, но в данном случае банально удобней даже скриптовые языки.
Про базы данных там сказали (если есть возможность -- базы данных не используйте), пропустим :)
Про хтмл: по-моему, это выглядит позорно:
let xhtml = renderHtml $ header <<
[thetitle << title ,
concatHtml $ map includeDep deps ,
primHtml ""
""
"",
concatHtml head ] +++
body << [headerB ,
jsNotice,
thediv ! [identifer "body" ] << concatHtml body ,
footerB ]
output xhtml
В комментах к посту товарищ что-то там красиво пришет про HStringTemplate и HSP, но, опять же, хотелось бы посмотреть на реальный код.
Короче, как-то все не то. По комфорту это даже не руби, не говоря уж о CL.
Куда бы двигался я: в первую очередь, конечно, в сторону continuation-based фреймворка. Думаю, хаскель туда впишется отменно. Потом, явно надо активней использовать доступные хаскелю средства метапрограммирования, чтобы избегать простыней красивого, статически-типизированного, но все же совершенно бесполезного кода. Ну и что-то надо явно делать с выводом HTML, js, и сборкой SQL. Потому как в коде в виде строк они выглядят совершенно безобразно, даже не принимая во внимание геморрой с обработкой ошибок и от сливания статической типизации в этом месте.