fby

[metaclass]

Посетил таки мероприятие элитных функциональщиков http://fby.by/

Достаточно неплохо, правда, под конец я утомился и доклад xeno_by про Dotty, независимую от компилятора модель языка, метапрограммирование и сохранение AST/метаданных вместе с бинарниками либ слушал в сумеречном состоянии сознания.

Еще не успел послушать целиком levgem, т.к. был на другом потоке, слушал про F#. Вообще, его доклад полезен тем, что это про законченный большой продающийся продукт, в то время, как другие рассказывали больше про общие фичи языка или про некоторые частные идеи.

Было, в целом, достаточно много скалы и F#, наконец-то я посмотрел на новые F# с провайдерами типов (я до сих пор по причине использования 2010 студии сижу на 2.0 версии).

tonsky рассказывал про критерии полезности языков программирования в целом. Упомянул недостаток clojure - слабую масштабируемость разработки, все-таки это язык для мелких команд вплоть до одного человека.

Еще меня очень пугает популярность шизофренистических тест-фреймворков для скалы и F#, где тест-кейсы пишутся в виде псевдо-английских фраз.

В целом, что немного напрягает - сильный разнобой в функциональных языках и нет явно видимого фаворита - во всех языках реализуются/портируются друг от друга похожие фичи, поддержка инструментов, насколько я понял, на данный момент лучше всего в F# - там на конференции прямо в vs всякие приколы типа "запустим тайп-провайдер и в репле получаем его структуру" демонстрировали, метапрограммирование живое в скале с кложей, асинхронность хорошо в хаскеле с эрлангами

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

PS: Кстати, главное что мне понравилось на конференции: сэндвичи с мясом и травой, в чем-то вроде лавашей.
Я первый раз присутствую на мероприятии, где дают нормальную еду для мозга, т.е. мясо, трава и чай/кофе, а не только сладости и печенье. Впрочем, чай я с собой в термосе притащил, т.к. предпочитаю пить достаточно крепкий зеленый с добавкой эхинацеи :)

Comments

[jakobz.livejournal.com]

То что GUI сейчас в основном лепят на ООП - первая причина того, что его на сегодняшний день можно UI сделать либо очень херовым, либо на две страницы и три кнопки, либо очень дорогим.

ООП-подход к UI - не скейлится (как и всё ООП). Сложность растёт экспоненциально от количества полей и кнопок на форме, и количества cross-cutting фич типа валидации, undo, optimistic concurrency, и подобного.

Частично проблемы пока решаются метапрограммированием (который в ФП обычно лучше), датабиндингом (который кастрированные линзы/FRP), и всякими MVVM (которые про то что стейт UI надо держать отдельно и желательно immutable).

Короче из UI осталось выкинуть оставшуюся половину императивщины и ООП, и будет все хорошо.

[binf.livejournal.com]

"GUI сейчас в основном лепят на ООП" - тока под jvm и qt, но это идиотизм. Только декларативный язык, практически xaml под виндвз, html5/css3 под веб. Застраничный язык - js, C# или что-то ещё - вопрос второстепенный.

[jakobz.livejournal.com]

Это всё декларативное - тоже плохо работает для UI, потому что семантика там та же ООП-шная: тот же XAML и HTML - это языки для сериализации ООП-шного дерева компонент.

У каждого этого компонента - здоровенный кусок стейта, куски которого потом в "застраничном коде" пытаются синхронизировать, что и создает ту самую экспоненту в сложности от количества кнопочек. А размазанность этого стейта - создает проблемы с cross-cutting фичами.

[binf.livejournal.com]

не, ну я тоже слышал про что-то типа Yampa в хаскеле, но оно всё очень далёкое от свинцовых реалий нашего Мордора. Wpf кстати очень многое позволяет делать stateless и без C# на чистом xaml и в тенденция там к расширению. Для меня лично проблема c UI даже не в отсутствии функциональщины, в конце концов можно писать застраничный код на F#, инкапсулируя изменяемое состояние в замыканиях на ссылки и т.п. Для сложных UI зачастую проблематично разделить модель представления и саму вьюшку, особенно если доменная структура данных составлена не лучшим образом. Но если уже удалось сделать нормальный view-model, то сама вьюшка получается простой.

[jakobz.livejournal.com]

Мне кажется что вот эта проблема мэппинга viewmodel и UI, или viewmodel и model - она начинается с того, что обычно есть два средства сделать мэппинг:
- ущербный eDSL aka "databinding"
- императивный код, размазанный соплями по всяким beforeRender и onChange

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

Короче для начала нужно бы отказаться от распространённой идеи что eDSL для преобразования viewmodel во view и обратно может и должен быть ущербным. И принять идею что это должен быть полноценный язык, закрывающий 90% задач.

[binf.livejournal.com]

Это всё правда

[n16bs.livejournal.com]

>Короче для начала нужно бы отказаться от распространённой идеи что eDSL для преобразования viewmodel во view и обратно может и должен быть ущербным. И принять идею что это должен быть полноценный язык, закрывающий 90% задач.

И получим react, не?

[jakobz.livejournal.com]

Не обязательно именно реакт, но ехать нужно определенно в ту сторону.

[cross-join.livejournal.com]

Голословные утверждения, показывающие ко всему прочему, ваше незнание исторического контекста возникновения технологий GUI и ООП.

[jakobz.livejournal.com]

Про исторический контекст возникновения - не понял наброса. Да и вообще наброса не понял.