fby

[metaclass]

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

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

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

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

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

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

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

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

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

Comments

[naartir.livejournal.com]

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

А можно раскрыть тему для не видевших clojure в продакшне?

[metaclass.livejournal.com]

Основные проблемы, с моей колокольни:

1) Проверка типов в рантайме. Я неоднократно обращался к integer как массиву или мапу, тупо поставив лишнюю пару скобок, с дикими стектрейсами. Я это вижу глазами и чиню, обучить других тому, что я чую спинным мозгом - невозможно. Я пытался обучить людей ставить логи во все углы для отладки - всем до сраки, "неудобно".

2) Мощность языка. Я за день могу наворотить в проекте такого, что коллеги будут неделю разбираться. В других языках получается изолировать мое творчество в ядре системы и выдать коллегам относительно внятный API+интеллисенс в студиях. В кложуре - извините, хуйс, надо писать документацию и примеры, причем лучше до того как писать код. А мне за удобство для коллег не доплачивают, мне бы свою работу успеть сделать.

Т.е. в кложури нет моральных ограничений или best practices которые позволили бы одновременно работать эффективно мне и при этом не делать код непонятным другим.

[naartir.livejournal.com]

1) Так, праблема. Але людзей, якія ня пішуць логі, трэба біць.

2) Часткова згодны, але за код зусім без дакумэнтацыі і прыкладаў, незалежна ад мовы, зноў такі, трэба біць нагамі. Ужо прабачце, рэбэ. )

Што да clojure, я на яе паглядваю як на мову для аднаго праекта. Мне цікава, якія рэбэ можа назваць годныя альтэрнатывы clojure/clojurescript для ўэба?

[wizzard]

> сильный разнобой в функциональных языках и нет явно видимого фаворита
хм, а в нефункциональных разве есть?

[metaclass.livejournal.com]

Ну в нефункциональных можно выбирать жабу или C#, не ошибешься. Если силен духом - C с ембедом.

[vit-r.livejournal.com]

В целом, что немного напрягает - сильный разнобой в функциональных языках и нет явно видимого фаворита

Ничего. Скоро выберут самый-самый плохой и сделают главным.

"как выжить программистам в условиях, когда важны продажи, а не технологии".

:-D

[metaclass.livejournal.com]

Так и плохой выбрать невозможно.
Надо просить xeno_by сделать скалу хуже, что ле :)
В смысле, ударится в продажи с концами, чтобы технологические прорывы вопреки делались.

Впрочем, если микрософт продвинет дотнет на линуксы, фаворитами будет C# и F# и это очень неплохой варинат.

[vit-r.livejournal.com]

Что бы кто бы ни продвигал, внутри будет код из Бангалора

[geniepro.livejournal.com]

> Ничего. Скоро выберут самый-самый плохой и сделают главным.

И это будет F# -- хуже не придумаешь...

[cross-join.livejournal.com]

Да, не хватает внятных статей типа вот задача, решаем её на дельфи, вот код кусками, теперь куски на кложуре, смотрете, как все стало круто и просто.
Заодно выяснятся классы задач, где имеет смысл подумать о декларативных языках.
В принципе, с этого вообще надо начинать.
GUI или имитационное моделирование на функциональщине - это какой-то нонсенс.

[metaclass.livejournal.com]

GUI на декларативных языках вполне нормально. Вообще для GUI нужно метапрограммирование, а оно+более-менее толковые GUI тулкиты только в скале и clojure есть. А жабогуй греховен и тормозит, не желаем мы его. Все остальное - разного уровня недоделанности и неработоспособности под виндами, потому что люди в основном веб всякий делают или вообще никаких продуктов не делают, а только скрипты запускают.

Насчет имитационного ничего не могу сказать, не знаю, чо там такого особенного.

[cross-join.livejournal.com]

Декларативный подход давно используется для описаний форм. Описания в терминах гуйевых объектов. Но это "мертвый гуй". Чтобы его оживить, нужен код.
В имитационном моделировании объекты живут своей жизнью и обмениваются сообщениями. Симула-67 - ООП в полный рост, хотя уже был Лисп.

[binf.livejournal.com]

== более-менее толковые GUI тулкиты только в скале и clojure есть

xaml + WPF круче, проще и мощнее всего, что есть под JVM неважно для какого ЯП. Я щас вообще не приемлю другого подхода к гуям, кроме декларативного xaml или html5/css3

[veter-r-r.livejournal.com]

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

Редкие исключения типа автора этого жж не выступают на публике в принципе ))

[love5an.livejournal.com]

я из C# сделал что-то функциональное, с декларативностью и куртизанками. Хотя сфера - опердень. Единственный минус - среднестатистические разработчики на C# плохо понимают что происходит.

[jakobz.livejournal.com]

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

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

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

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

[veter-r-r.livejournal.com]

А какие есть преимущества кроме "аутичный гуру будет пилить что-то тихонько на кложури и не убежит на гоа раньше времени"?

[metaclass.livejournal.com]

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

У кложи - удобность для задач, где с типами херово, например белорусской налоговой и статистической отчетности, которую придумывают люди, плохо ударенные на голову Excel. Там в каждой ячейке документа может быть строка, число, фаза луны, функция, рассчитывающая пол будущего ребенка бухгалтера или заклинание вызова ктулху. Кроме того, там есть нормальный репл и интеграция с жабьими либами.

У эрланга - заточенность под кластера, битоебские протоколы и восстановление при ошибках.

[messirvoland.livejournal.com]

> В целом, что немного напрягает - сильный разнобой в функциональных языках и нет явно видимого фаворита
Как мне не нравиться Scala, но она. MS стек без серьезных причин никто брать не будет. У Erlang своя ниша и ему там хорошо. Haskell для общего развития и в продакшен тянуть - безумие. Остается JVM. Clojure слишком динамическая и там скобочки. Вот методом исключения остается Scala. Тем более хайп вокруг нее сформировал не плохое комьюнити, есть уже много интересных фреймворков, типа того же play, akka.

[metaclass.livejournal.com]

Вот я так же думал, но скала уверенным путем идет в тот же ад, что С++.
Кроме того, sbt не работает, maven - содомия, idea плагины не работают, eclipse - грех.

Язык, в котором надо несколько дней заниматься настройкой инструментов, негуманен. Хотя для любителей БДСМ, которыми переполнено IT наверно нормально :)

[binf.livejournal.com]

== асинхронность хорошо в хаскеле с эрлангами

так в F# те же парадигмы и опции - Microsoft.FSharp.Control.MailboxProcessor с агентами.

[berezovsky.livejournal.com]

Левгем вроде стриминговый сервер продаёт.

Интересно, как коррелируют интернет, участники живых конференций и активные проекты.

[ynot.livejournal.com]

с функциональных заоблачных олимпов до сих пор транслировались идеи, что F# - это такой очередной Биллгейтсовский VBA для умственно отсталых.

мы в этом посте наблюдаем ритуальное самоубийство путем разгрызения коллегами, или действительно "рэп больше не кал"?

(епт, капча "Outlook good". Это знакъ)

[metaclass.livejournal.com]

Ничего не знаю про VBA, я с 2010 года на F# пишу, кое-каких фич не хватает, но зато интеграция с C# прямая.

[zealer.livejournal.com]

Могу сказать причину почему "тест-кейсы пишутся в виде псевдо-английских фраз".
Есть менеджеры, которые не идеально понимают рабочую область и хоть бы треть знали что сделано уже, но при этом выдают задания.
Есть программисты, которые не будут писать сложных тестов, потому что они сами не понимают как всё работает.
Есть один CTO, который чтоб заставить людей писать тесты ввёл метрику Code Coverage.
Это поделие в трехсот проектах на .Net (из них 150 в одном солюшене) и с сотней программистов катится в ад.

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

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