понедельник, 12 сентября 2011 г.

Впечатления о встрече разработчиков Scala

В субботу выступал на небольшой встрече разработчиков Scala. Если в общем и целом: все было здорово, мне очень понравилось. Отдельное спасибо Василию Ременюку за классную организацию встречи. Было все, что нужно: удобное помещение, проектор, ноутбук и даже автомат с бесплатным кофе.

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

Правда, как ни странно, хотя я и попытался разжевать во всех подробностях, что такое лисп и как он используется, все равно в разных вариациях услышал вопрос: "Ну нафиг нам твой Lisp со всеми этими скобочками? Есть ведь JetBrains MPS, Xtext, antlr, бла-бла-бла..."

У меня встречный вопрос: а что вы чаще используете, паттерны или MPS? В Lisp-е я не задумываясь, влегкую, введу новые операторы, сделаю библиотеку паттернов и других общих архитектурных фрагментов; все будет DRY, никакого копи-пейста. И это будет все тот же самый язык, на котором написан основной код проекта.

А вы такое сможете со своей Java, C#, С++, даже с использованием этих дополнительных утилит? И даже если сможете, то почему не делаете?

Тут нет никакой загадки: любой external DSL всегда по определению сложнее в реализации и поддержке, чем аналогичный embedded. И чем сложнее DSL, тем заметнее разница в сложности реализации всей инфраструктуры external DSL (парсер, набор синтаксических правил и т.д.) и embedded DSL, для которого ничего дополнительно приделывать не нужно.

Спасибо всем присутствовавшим, мне было интересно с вами пообщаться. Надеюсь, я заинтересовал вас языком Clojure, и через какое-то время появится наша Belarussian Clojure Users Group.

Материалы моего выступления доступны здесь.

38 комментариев:

  1. Для Clojure нужно знать один из лиспов или можно взяться сразу за него? Что посоветуете на почитать?

    ОтветитьУдалить
  2. То, что я сейчас посоветую -- мое личное мнение.
    Во-первых, Clojure нужно использовать именно как лисп. Встроенные механизмы поддержки конкурентности отдельно от его "лиспости" -- не киллер фича. Коктейль Молотова получается, только если использовать его возможности метапрограммирования, бесшовной интеграции с платформой Java и, естественно, конкурентности "из коробки".
    Самая сложная часть -- это использование Clojure как Lisp. Для этого очень рекомендую книги:
    1) Structure and Interpretation of Computer Programs (http://mitpress.mit.edu/sicp/). Есть и в русском варианте, и даже в печатном русском.
    Из этой книги вы узнаете, что такое лисп, как он устроен, как им пользоваться для решения повседневных задач программиста.
    2) On Lisp (http://www.paulgraham.com/onlisp.html). Книга о метапрограммировании на лиспе. Абсолютный must have, если хотите достичь просветления. Книгу непросто понять неподготовленному пользователю, так что вначале рекомендую ознакомиться с Practical Common Lisp (http://www.gigamonkeys.com/book/).
    3) Конкретно Clojure лучше изучать по книгам в следующем порядке:
    Practical Clojure
    Clojure in Action
    The Joy of Clojure.

    То, что я перечислил -- минимум, необходимый для успешного старта. Еще лично от себя порекомендую по лиспу Land of Lisp, Paradigms of Artificial Intelligence, Let over Lambda. Для того, чтобы лучше вникнуть в функциональное программирование на Clojure -- попробуйте изучить ML и Haskell. После них многое в Clojure вам покажется знакомым и очень удобным.
    Успехов!

    ОтветитьУдалить
  3. Этот комментарий был удален автором.

    ОтветитьУдалить
  4. Нифига. Именно в том порядке, что я перечислил, или параллельно. Не читал SICP и OnLisp -- считай, что лиспа не знаешь.

    ОтветитьУдалить
  5. Тогда понятен скептицизм по отношению к Кложуре со стороны жабщиков/скалеров - слишком много придется учить

    ОтветитьУдалить
  6. Ха! Тем, кто не учился в универе -- конечно много! Между прочим, SICP преподается на _п_е_р_в_о_м_ курсе MIT-a и Stanford-а. А у нас SICP и выпускники не все осилят. Отсюда и общий уровень образования наших "лучших в мире" программистов, и качество быдло-кода и положение нашей страны в IT, как еще одной Индии. Где инновации, где продукты, где мегастартапы? World of Tanks, блин, вот и все.
    Clojure -- это язык профессионалов. Неучи и лентяи пусть пишут на своих Java и C#.

    ОтветитьУдалить
  7. та я в курсе :) В т.ч. про "лучших в мире" программистов, нуечей и лентяев.

    ОтветитьУдалить
  8. Дмитрий, большое спасибо доклад, было действительно интересно.

    Надеюсь Вы не сильно обиделись за вопрос про MPS, я прекрасно понимаю проблему внешних DSL, просто хотелось подзадорить дискуссию :)

    Вообще, у нас не один стартап в стране, их гораздо больше, просто не все так пиарятся как WoT. Вот например http://targetprocess.com/ - вполне себе отличный стартап, который делается исключительно в BY и на "своих C#". Хотя с другой стороны, из общения с их програмистами заметил, что SICP и Clojure, читали/знают/используют, может действительно есть какая-то связь :) Хотя сколько вы знаете мировых стартапов использующих Clojure? Лично я только один - backType... А наличие вот такой тусовки - явный признак, что мы пытаемся выкарабкаться. Так что хотел бы услышать ещё ваших докладов ;)

    ОтветитьУдалить
  9. Здравствуй, Павел,

    Спасибо за твои вопросы на дискуссии, сразу видно, что ты "в теме", и зришь точно в корень проблемы. Твои вопросы были одними из самых сложных и интересных :-)

    То, что несколько достойных стартапов у нас есть -- это я знаю. Но и уровень подготовки у этих стартаперов -- гора-а-аздо выше среднего выпускника того же БГУИР. Да что там выпускника, даже программиста со стажем. Чтобы не быть голословным, приведу пример небольшой фирмы, не помню название -- в одном здании с Научсофтом. Я был как-то на одном занятии их курсов по AI. Большинство из тех, кто там работают -- или уже имеют PhD, или пишут свои диссертации. Зато и продукт их (трейдинговый бот) -- на голову бьет всех существующих конкурентов. Если сравнить уровень этих ребят и уровень программеров на Itransition, где я какое-то время работал, -- разница -- небо и земля.

    Я не в курсе о стартапах на Clojure, если только не считать массу мелких веб-приложений, которые тут же понаписали, как появилась Compojure :-) Из интересных вещей: World of Singles, TypeWire (http://www.typewire.io/ -- стартап, из которого выделился WebNoir), Incanter, heroku (там теперь есть поддержка Clojure). Причина тут проста: лисп очень неохотно пускают в продакшен из-за разных мифов и суеверий.

    Успехов!

    ОтветитьУдалить
  10. > В Lisp-е я не задумываясь, влегкую, введу новые операторы, сделаю библиотеку паттернов и других общих архитектурных фрагментов; все будет DRY, никакого копи-пейста.

    Знаешь что пугает в этой схеме? Что вот ты введёшь, а твой коллега не поймёт. Потому что сколько лисперов - столько диалектов лиспа, у каждого свой лисп. Нет ли в этом подводных граблей?

    ОтветитьУдалить
  11. :-) :-) :-) Моя плакать! Сколько я видель говнокода на С++, С# и Java, который разобрать без дебуггера -- вообще нереально! Интересно, а как же в этих языках решают проблемы сложных абстракций? Неужели, код на С++ готовят как-то по-другому?
    Нормальная документация всегда решает. Смотри сюда: https://github.com/dbushenko/Clojure-WebApp . Здесь полно сложных языковых конструкций. Но народ разобрался, даже патчи слали. Так что граблей нету, документировать нужно, вот и все.

    ОтветитьУдалить
  12. Вас ввели в заблуждение. Есть ныне common lisp, застандартизированный ANSI, который понимают все лисперы одинаково. Есть еще один диалект scheme, он специфицированный и так же прекрасно всеми понимаемый. Есть clojure, который еще слишком молод, чтобы быть специфицированным, но и он недалеко от них ушел синтаксисом и функциями.
    То, что вы спрашивали, возможно, касается использования макросов, которые действительно из стандартных форм (функция параметры...) могут выделывать разные кренделя. И тогда да, вероятность недопонимания вырастает в разы.

    ОтветитьУдалить
  13. Reader-макросов в кложуре нет именно по этой причине. Рич Хикки -- идейный враг произвольного синтаксиса.

    ОтветитьУдалить
  14. Как-то с большим позитивнейшим воодушевлением взялся изучать Clojure ... не-е, не то, не понравилось. Это какой-то "недолисп", согласен утверждение холиварное. Common Lisp безусловно рулит. Вот Schema с CL может очень серьёзно поспорить (хотя, лично я думаю что CL выйдет попедителем) и это будет очень не простой спор. А Clojure сливает. Это моё субъективное мнение. Спорить, честно скажу не готов - не так подробно изучил Clojure (да и давненько это было). Просто в определённый момент понял, что изучать дальше Clojure не имеет смысла. Что касается интеграции с java'ой - сейчас активно развивается ABCL(реализация CL). Если вдруг чёрт дёрнет и приспичит получше изучить Clojure, спишемся - я буду готов к жаркой полемике ;)

    ОтветитьУдалить
  15. Нафиг не сдалось. Нравится Common Lisp -- пиши на CL-е. Мне так же безразлично твое мнение о Clojure, как и тебе -- мое.

    ОтветитьУдалить
  16. > Что касается интеграции с java'ой - сейчас активно развивается ABCL(реализация CL)
    Хехе, он уже сколько лет "активно развивается", а до стабильной версии всё не дайдёт :) Последний раз я его тыкал года 2 назад. Тогда его версия было что-то вроде 0.23 (или даже больше), сейчас - 0.27. Так что ещё не скоро мы увидим CL на JVM.

    ОтветитьУдалить
  17. Скажем так, дело даже не в мажорном релизе ABCL-а. В нем есть сразу несколько существенных недостатков:
    1. Это не родной для JVM язык. Поскольку ABCL пытается следовать стандарту CL, вся интеграция с java идет через туеву хучу врапперов. Как результат -- огромный оверхед и тормоза. Причем это фундаментальная архитектурная фишка, исправить ее в пределах проекта ABCL невозможно.
    Интеграция с java в ABCL -- далеко не самая удобная, особенно на фоне Clojure.
    2. ABCL не успевает за трендами. Учитывая, что спека на CL была опубликована до бурного развития параллельных технологий на ПК, в ABCL присутствуют очень старые примитивы построения многопоточных приложений. В отличие от Clojure, конечно.

    Есть еще несколько пунктов, но они -- мое личное мнение, возможно не очень объективное.

    ОтветитьУдалить
  18. Митовский 6.001 больше не читают.

    ОтветитьУдалить
  19. Да, в 2008-м вроде Сассман отчитал эти лекции в последний раз. Пруфлинк: http://mitadmissions.org/blogs/entry/the_end_of_an_era_1

    После него курс реально даунгрейдили. Я уж не знаю, связано ли это как-то с желанием ориентироваться на "середнячков" вместо умных и талантливых студентов, но 6.001 разбили сразу на три курса 6.00, 6.01, 6.02 и пишут там на Python-е. Курс стал реально легче и менее "хаккерский". Я могу этому порадоваться только лишь на том основании, что смогу привести очередной пример тупизны америкосов и победы бюрократии над здравым смыслом.

    ОтветитьУдалить
  20. Для меня, например, достаточно сложно сравнивать 6.001 с новыми курсами, для первого есть видео лекции, книга с этим курсом, он хорошо известен, достаточное количество поколений студентов прошли через него, а вот с новичками сложней, я лишь видел лектурал ноты для 6.01, и сами курсы еще молоды, что бы их было корректно сравнивать со старичком.

    ОтветитьУдалить
  21. Ну и в сторону скажу, поминать про "очередной пример тупизны америкосов и победы бюрократии над здравым смыслом" как бы моветон все-таки.

    ОтветитьУдалить
  22. Помнится, сам Сассман тогда обосновывал это как-то так: раньше, чтобы написать хорошую программу, нужно было много думать и совсем чуть-чуть писать, для чего отлично подходил Scheme; теперь же программистам в реальном мире чаще приходится мало думать, и много искать в интернете, а для этого более "правильным" языком является Python.

    ОтветитьУдалить
  23. Мало думать, много искать в интернете -- это не программист, блин, а стандартный кодер, индус, который пережевывает спеку в исходник. Программист -- это инженер в первую очередь, творец, изобретатель наконец. Программисту как раз думать надо.
    То, что курс CS в MIT упрощают до уровня среднего кодера, на мой взгляд -- сродни диверсии. Lisp -- самый выразительный из всех языков. Раньше выпускники MIT владели самым мощным из всех ЯП. Теперь они владеют самым простым и читабельным. The road to hell, блин...

    ОтветитьУдалить
  24. Таки обратная совместимость кложуре бы не помешала, раз. Во-вторых Рич Хикки однозначно решил за публику что ей надо, а что нет [макроридеры, квадратные скобки для имен параметров]. Напоминает Джобса.
    Ни в коем случае не развожу холивор, но технически кложура новшеств не принесла. Маркетинг крутой держится только засчет явы.

    ОтветитьУдалить
  25. Обратная совместимость с чем? С CL? Scheme? NewLisp? ARC? Elisp? AutoLisp? Продолжать?
    Во-вторых, каждый автор каждого лиспа принимает такие же решения. Сравни стандарты CL и Scheme и можешь начинать холивар еще и там заодно.
    Ява в кложуре -- не маркетинг. Это единственная возможность ввести лисп в мейнстрим. Если бы кложура была очередным компайлером в машинный код, то мы получили бы очередную схему со своим хитрым синтаксисом.

    ОтветитьУдалить
  26. Конечно, с CL. Остальные диалекты частного применения.
    "каждый автор" - вот этого и опасается один из здесь присутствующих. Потом под дотнет кто-то придумает свой диалект. Может стоит направить энергию на поддержку одного самого крупного лиспа.
    Так кложура и получилась лиспом с хитрым синтаксисом, ограниченным одной ВМ. И яву то в каждую дырку не засунешь.

    ОтветитьУдалить
  27. > Конечно, с CL.
    Вот тут и начинается твое личное мнение, далеко не самое объективное и очень предвзятое.

    > вот этого и опасается один из здесь присутствующих.
    Речь шла о макросах и чрезмерном их применении, а вовсе не о диалектах лиспа. И нечего устраивать геноцид лиспов по признаку совместимости со стандартом Common Lisp.

    > Может стоит направить энергию на поддержку одного самого крупного лиспа.
    Конечно. Сейчас этим и заняты в clojure/core.

    > Так кложура и получилась лиспом с хитрым синтаксисом, ограниченным одной ВМ. И яву то в каждую дырку не засунешь.
    Трололо? Займись лучше чем-нибудь полезным. У кложуры и у коммон лиспа есть свои ниши, и они совпадают далеко не везде. Именно из-за целевой платформы в первую очердь.

    ОтветитьУдалить
  28. > Тогда понятен скептицизм по отношению к Кложуре со стороны жабщиков/скалеров - слишком много придется учить
    Мне кажется Dmitry сильно преувеличивает. Достаточно прочитать, например, Programming Clojure (сейчас книжка несколько устарела, скоро выйдет второе издание), чтобы начать писать нормальный код.

    > ограниченным одной ВМ
    Кроме джавной реализации есть еще и дотнетовская, а также ClojureScript - диалект, компилирующийся в js.

    ОтветитьУдалить
  29. Честно говоря, после Programming Clojure врядли человек сможет писать на Clojure как на лиспе. Эта книга мало описывает метарограммирование -- то, благодаря чему лисп и является таким мощным инструментом.

    ОтветитьУдалить
  30. Ну, вообще-то на протяжении всей книги автор показывает, как написать DSL для сборки приложений. Это, как я понимаю, и есть метапрограммирование?

    ОтветитьУдалить
  31. Совершенно верно, это метапрограммирование. В той же степени, в которой арифметика -- это математика. Programming Clojure дает азы, и хорошо, если она тебе понравилась. Возможно заинтересуешься и чем-то посерьезнее. Очень рекомендую посмотреть SICP (глава 4), On Lisp, Let over Lambda. Это книги значительно выше уровнем.

    ОтветитьУдалить
  32. Эти книги немного о другом, на мой взгляд. Их стоит читать для повышения общего уровня образованности. Для эффективного использования clojure они совершенно необязательны, полезнее потратить время на чтение (и написание) кода.

    ОтветитьУдалить
  33. Пол Грэм по этому поводу очень хорошо выразился в свое время. В пересказе это звучит примерно так: "Начинающего программиста нельзя научить программированию по принципу 'снизу-вверх', потому что он не знает, где верх" :-) Как мне тебе объяснить ценность этих книг, если ты их не читал? Знание синтаксиса языка не делает из новичка программиста. А эти книги -- делают. Так что я уверен, тебя ждет очень увлекательное чтение :-)

    ОтветитьУдалить
  34. > Еще раз: я не говорю, что SICP или on lisp (не знаю насчет LOL'а) - плохие или ненужные книжки. Я говорю о том, что утверждение о том, будто бы без них невозможно эффективно писать на clojure - вымысел и бред.

    Конечно, ты можешь писать на Clojure без SICP и OnLisp. Но никаких преимуществ Clojure перед другими языками ты не получишь. В твоих руках Clojure будет примерно тем же, что и Scala -- обычный язык программирования, нацеленный на конкурентность :-)
    Так что, конечно, пиши на Clojure и без OnLisp, я буду только рад, если нас (clojure-программеров) станет больше. Со временем появится интерес и к более сложным возможностям кложуры, учитывая ее "лисповость".

    ОтветитьУдалить
  35. Большое спасибо за доклад, благодаря выложенной презентации и конспекту доклада открыл для себя и знакомых lisp. Пока lisp приносит массу удовольствия и новую "ветку талантов", думаю скоро станет основным языком.
    Если этот доклад будет доступен в более удобном виде, благодарить вас, за открытие для себя lisp'a, будут гораздо больше программистов.
    Отдельное спасибо за список литературы в коментариях к этому посту.

    ОтветитьУдалить
  36. Спасибо за такой отзыв, мне очень приятно! :-) Планирую записать скринкаст с кратким изложением основных тем доклада и live-демонстрацией работы с лиспом при помощи Emacs/Slime.

    ОтветитьУдалить
  37. Основной аргумент для начала изучения - лёгкие eDSL. У меня просто пример хороший есть перед глазами. Adobe для своего фреймворка Flex сделали mxml - декларативное описание UI в xml плюс код на ActionScript 3 внутри. Но этот язык(?) очень сильно завязан на flex framework, для использования его с другими gui framework'ами доступна лишь часть плюшек. Отход от таких понятий как экземпляр класса и свойство в сторону описания свойств кнопки или списка, связывание данных (data binding) и декларативное описание состояний в десяток раз ускоряют разработку и упрощают приложение. Даже controller из mvc просто заменяется на легко тестируемый view model из mvvm. В итоге есть сильное желание отвязать mxml от flex фреймворка допилив часть компилятора (которая транслирует mxml в ActionScript3).
    К слову о MPS, на нём пишется редактор (http://www.realaxy.com/editor/index?lang=ru_RU) который позволяет создавать языковые расширения для ActionScript 3. Предлагаемая парадигма разработки - Language Oriented Programming и редактор является мощной IDE для самописных расширений. ИМХО ActionScript 3 слишком убог для использования в LOP, но вот лисп :)

    ОтветитьУдалить
  38. Да в курсе я о MPS и о нескольких других подобных разработках :-) У них у ВСЕХ есть недостаток: они сложные. Что бы там ни говорили, как бы ни доказывали, а все-таки, не станет программист для себя на каждую ерундовину делать DSL на MPS. А вот лиспер -- станет, притом не задумываясь даже о том, DSL это будет или так, мелкое изменение в самом лиспе.
    MPS хорош там, где нужен один-два крупных DSL-а. Мелкие изменения в язык на нем вносить не станут.

    ОтветитьУдалить