В субботу выступал на небольшой встрече разработчиков 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.
Материалы моего выступления доступны здесь.
Аудитория собралась образованная. После доклада о возможностях Lisp-а меня еще долго держали вопросами, причем не только грамотными, но и очень каверзными.
Правда, как ни странно, хотя я и попытался разжевать во всех подробностях, что такое лисп и как он используется, все равно в разных вариациях услышал вопрос: "Ну нафиг нам твой Lisp со всеми этими скобочками? Есть ведь JetBrains MPS, Xtext, antlr, бла-бла-бла..."
У меня встречный вопрос: а что вы чаще используете, паттерны или MPS? В Lisp-е я не задумываясь, влегкую, введу новые операторы, сделаю библиотеку паттернов и других общих архитектурных фрагментов; все будет DRY, никакого копи-пейста. И это будет все тот же самый язык, на котором написан основной код проекта.
А вы такое сможете со своей Java, C#, С++, даже с использованием этих дополнительных утилит? И даже если сможете, то почему не делаете?
Тут нет никакой загадки: любой external DSL всегда по определению сложнее в реализации и поддержке, чем аналогичный embedded. И чем сложнее DSL, тем заметнее разница в сложности реализации всей инфраструктуры external DSL (парсер, набор синтаксических правил и т.д.) и embedded DSL, для которого ничего дополнительно приделывать не нужно.
Спасибо всем присутствовавшим, мне было интересно с вами пообщаться. Надеюсь, я заинтересовал вас языком Clojure, и через какое-то время появится наша Belarussian Clojure Users Group.
Материалы моего выступления доступны здесь.
Для Clojure нужно знать один из лиспов или можно взяться сразу за него? Что посоветуете на почитать?
ОтветитьУдалитьТо, что я сейчас посоветую -- мое личное мнение.
ОтветитьУдалитьВо-первых, 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 вам покажется знакомым и очень удобным.
Успехов!
Этот комментарий был удален автором.
ОтветитьУдалитьНифига. Именно в том порядке, что я перечислил, или параллельно. Не читал SICP и OnLisp -- считай, что лиспа не знаешь.
ОтветитьУдалитьТогда понятен скептицизм по отношению к Кложуре со стороны жабщиков/скалеров - слишком много придется учить
ОтветитьУдалитьХа! Тем, кто не учился в универе -- конечно много! Между прочим, SICP преподается на _п_е_р_в_о_м_ курсе MIT-a и Stanford-а. А у нас SICP и выпускники не все осилят. Отсюда и общий уровень образования наших "лучших в мире" программистов, и качество быдло-кода и положение нашей страны в IT, как еще одной Индии. Где инновации, где продукты, где мегастартапы? World of Tanks, блин, вот и все.
ОтветитьУдалитьClojure -- это язык профессионалов. Неучи и лентяи пусть пишут на своих Java и C#.
та я в курсе :) В т.ч. про "лучших в мире" программистов, нуечей и лентяев.
ОтветитьУдалитьДмитрий, большое спасибо доклад, было действительно интересно.
ОтветитьУдалитьНадеюсь Вы не сильно обиделись за вопрос про MPS, я прекрасно понимаю проблему внешних DSL, просто хотелось подзадорить дискуссию :)
Вообще, у нас не один стартап в стране, их гораздо больше, просто не все так пиарятся как WoT. Вот например http://targetprocess.com/ - вполне себе отличный стартап, который делается исключительно в BY и на "своих C#". Хотя с другой стороны, из общения с их програмистами заметил, что SICP и Clojure, читали/знают/используют, может действительно есть какая-то связь :) Хотя сколько вы знаете мировых стартапов использующих Clojure? Лично я только один - backType... А наличие вот такой тусовки - явный признак, что мы пытаемся выкарабкаться. Так что хотел бы услышать ещё ваших докладов ;)
Здравствуй, Павел,
ОтветитьУдалитьСпасибо за твои вопросы на дискуссии, сразу видно, что ты "в теме", и зришь точно в корень проблемы. Твои вопросы были одними из самых сложных и интересных :-)
То, что несколько достойных стартапов у нас есть -- это я знаю. Но и уровень подготовки у этих стартаперов -- гора-а-аздо выше среднего выпускника того же БГУИР. Да что там выпускника, даже программиста со стажем. Чтобы не быть голословным, приведу пример небольшой фирмы, не помню название -- в одном здании с Научсофтом. Я был как-то на одном занятии их курсов по AI. Большинство из тех, кто там работают -- или уже имеют PhD, или пишут свои диссертации. Зато и продукт их (трейдинговый бот) -- на голову бьет всех существующих конкурентов. Если сравнить уровень этих ребят и уровень программеров на Itransition, где я какое-то время работал, -- разница -- небо и земля.
Я не в курсе о стартапах на Clojure, если только не считать массу мелких веб-приложений, которые тут же понаписали, как появилась Compojure :-) Из интересных вещей: World of Singles, TypeWire (http://www.typewire.io/ -- стартап, из которого выделился WebNoir), Incanter, heroku (там теперь есть поддержка Clojure). Причина тут проста: лисп очень неохотно пускают в продакшен из-за разных мифов и суеверий.
Успехов!
> В Lisp-е я не задумываясь, влегкую, введу новые операторы, сделаю библиотеку паттернов и других общих архитектурных фрагментов; все будет DRY, никакого копи-пейста.
ОтветитьУдалитьЗнаешь что пугает в этой схеме? Что вот ты введёшь, а твой коллега не поймёт. Потому что сколько лисперов - столько диалектов лиспа, у каждого свой лисп. Нет ли в этом подводных граблей?
:-) :-) :-) Моя плакать! Сколько я видель говнокода на С++, С# и Java, который разобрать без дебуггера -- вообще нереально! Интересно, а как же в этих языках решают проблемы сложных абстракций? Неужели, код на С++ готовят как-то по-другому?
ОтветитьУдалитьНормальная документация всегда решает. Смотри сюда: https://github.com/dbushenko/Clojure-WebApp . Здесь полно сложных языковых конструкций. Но народ разобрался, даже патчи слали. Так что граблей нету, документировать нужно, вот и все.
Вас ввели в заблуждение. Есть ныне common lisp, застандартизированный ANSI, который понимают все лисперы одинаково. Есть еще один диалект scheme, он специфицированный и так же прекрасно всеми понимаемый. Есть clojure, который еще слишком молод, чтобы быть специфицированным, но и он недалеко от них ушел синтаксисом и функциями.
ОтветитьУдалитьТо, что вы спрашивали, возможно, касается использования макросов, которые действительно из стандартных форм (функция параметры...) могут выделывать разные кренделя. И тогда да, вероятность недопонимания вырастает в разы.
Reader-макросов в кложуре нет именно по этой причине. Рич Хикки -- идейный враг произвольного синтаксиса.
ОтветитьУдалитьКак-то с большим позитивнейшим воодушевлением взялся изучать Clojure ... не-е, не то, не понравилось. Это какой-то "недолисп", согласен утверждение холиварное. Common Lisp безусловно рулит. Вот Schema с CL может очень серьёзно поспорить (хотя, лично я думаю что CL выйдет попедителем) и это будет очень не простой спор. А Clojure сливает. Это моё субъективное мнение. Спорить, честно скажу не готов - не так подробно изучил Clojure (да и давненько это было). Просто в определённый момент понял, что изучать дальше Clojure не имеет смысла. Что касается интеграции с java'ой - сейчас активно развивается ABCL(реализация CL). Если вдруг чёрт дёрнет и приспичит получше изучить Clojure, спишемся - я буду готов к жаркой полемике ;)
ОтветитьУдалитьНафиг не сдалось. Нравится Common Lisp -- пиши на CL-е. Мне так же безразлично твое мнение о Clojure, как и тебе -- мое.
ОтветитьУдалить> Что касается интеграции с java'ой - сейчас активно развивается ABCL(реализация CL)
ОтветитьУдалитьХехе, он уже сколько лет "активно развивается", а до стабильной версии всё не дайдёт :) Последний раз я его тыкал года 2 назад. Тогда его версия было что-то вроде 0.23 (или даже больше), сейчас - 0.27. Так что ещё не скоро мы увидим CL на JVM.
Скажем так, дело даже не в мажорном релизе ABCL-а. В нем есть сразу несколько существенных недостатков:
ОтветитьУдалить1. Это не родной для JVM язык. Поскольку ABCL пытается следовать стандарту CL, вся интеграция с java идет через туеву хучу врапперов. Как результат -- огромный оверхед и тормоза. Причем это фундаментальная архитектурная фишка, исправить ее в пределах проекта ABCL невозможно.
Интеграция с java в ABCL -- далеко не самая удобная, особенно на фоне Clojure.
2. ABCL не успевает за трендами. Учитывая, что спека на CL была опубликована до бурного развития параллельных технологий на ПК, в ABCL присутствуют очень старые примитивы построения многопоточных приложений. В отличие от Clojure, конечно.
Есть еще несколько пунктов, но они -- мое личное мнение, возможно не очень объективное.
Митовский 6.001 больше не читают.
ОтветитьУдалитьДа, в 2008-м вроде Сассман отчитал эти лекции в последний раз. Пруфлинк: http://mitadmissions.org/blogs/entry/the_end_of_an_era_1
ОтветитьУдалитьПосле него курс реально даунгрейдили. Я уж не знаю, связано ли это как-то с желанием ориентироваться на "середнячков" вместо умных и талантливых студентов, но 6.001 разбили сразу на три курса 6.00, 6.01, 6.02 и пишут там на Python-е. Курс стал реально легче и менее "хаккерский". Я могу этому порадоваться только лишь на том основании, что смогу привести очередной пример тупизны америкосов и победы бюрократии над здравым смыслом.
Для меня, например, достаточно сложно сравнивать 6.001 с новыми курсами, для первого есть видео лекции, книга с этим курсом, он хорошо известен, достаточное количество поколений студентов прошли через него, а вот с новичками сложней, я лишь видел лектурал ноты для 6.01, и сами курсы еще молоды, что бы их было корректно сравнивать со старичком.
ОтветитьУдалитьПомнится, сам Сассман тогда обосновывал это как-то так: раньше, чтобы написать хорошую программу, нужно было много думать и совсем чуть-чуть писать, для чего отлично подходил Scheme; теперь же программистам в реальном мире чаще приходится мало думать, и много искать в интернете, а для этого более "правильным" языком является Python.
ОтветитьУдалитьМало думать, много искать в интернете -- это не программист, блин, а стандартный кодер, индус, который пережевывает спеку в исходник. Программист -- это инженер в первую очередь, творец, изобретатель наконец. Программисту как раз думать надо.
ОтветитьУдалитьТо, что курс CS в MIT упрощают до уровня среднего кодера, на мой взгляд -- сродни диверсии. Lisp -- самый выразительный из всех языков. Раньше выпускники MIT владели самым мощным из всех ЯП. Теперь они владеют самым простым и читабельным. The road to hell, блин...
Таки обратная совместимость кложуре бы не помешала, раз. Во-вторых Рич Хикки однозначно решил за публику что ей надо, а что нет [макроридеры, квадратные скобки для имен параметров]. Напоминает Джобса.
ОтветитьУдалитьНи в коем случае не развожу холивор, но технически кложура новшеств не принесла. Маркетинг крутой держится только засчет явы.
Обратная совместимость с чем? С CL? Scheme? NewLisp? ARC? Elisp? AutoLisp? Продолжать?
ОтветитьУдалитьВо-вторых, каждый автор каждого лиспа принимает такие же решения. Сравни стандарты CL и Scheme и можешь начинать холивар еще и там заодно.
Ява в кложуре -- не маркетинг. Это единственная возможность ввести лисп в мейнстрим. Если бы кложура была очередным компайлером в машинный код, то мы получили бы очередную схему со своим хитрым синтаксисом.
Конечно, с CL. Остальные диалекты частного применения.
ОтветитьУдалить"каждый автор" - вот этого и опасается один из здесь присутствующих. Потом под дотнет кто-то придумает свой диалект. Может стоит направить энергию на поддержку одного самого крупного лиспа.
Так кложура и получилась лиспом с хитрым синтаксисом, ограниченным одной ВМ. И яву то в каждую дырку не засунешь.
> Конечно, с CL.
ОтветитьУдалитьВот тут и начинается твое личное мнение, далеко не самое объективное и очень предвзятое.
> вот этого и опасается один из здесь присутствующих.
Речь шла о макросах и чрезмерном их применении, а вовсе не о диалектах лиспа. И нечего устраивать геноцид лиспов по признаку совместимости со стандартом Common Lisp.
> Может стоит направить энергию на поддержку одного самого крупного лиспа.
Конечно. Сейчас этим и заняты в clojure/core.
> Так кложура и получилась лиспом с хитрым синтаксисом, ограниченным одной ВМ. И яву то в каждую дырку не засунешь.
Трололо? Займись лучше чем-нибудь полезным. У кложуры и у коммон лиспа есть свои ниши, и они совпадают далеко не везде. Именно из-за целевой платформы в первую очердь.
> Тогда понятен скептицизм по отношению к Кложуре со стороны жабщиков/скалеров - слишком много придется учить
ОтветитьУдалитьМне кажется Dmitry сильно преувеличивает. Достаточно прочитать, например, Programming Clojure (сейчас книжка несколько устарела, скоро выйдет второе издание), чтобы начать писать нормальный код.
> ограниченным одной ВМ
Кроме джавной реализации есть еще и дотнетовская, а также ClojureScript - диалект, компилирующийся в js.
Честно говоря, после Programming Clojure врядли человек сможет писать на Clojure как на лиспе. Эта книга мало описывает метарограммирование -- то, благодаря чему лисп и является таким мощным инструментом.
ОтветитьУдалитьНу, вообще-то на протяжении всей книги автор показывает, как написать DSL для сборки приложений. Это, как я понимаю, и есть метапрограммирование?
ОтветитьУдалитьСовершенно верно, это метапрограммирование. В той же степени, в которой арифметика -- это математика. Programming Clojure дает азы, и хорошо, если она тебе понравилась. Возможно заинтересуешься и чем-то посерьезнее. Очень рекомендую посмотреть SICP (глава 4), On Lisp, Let over Lambda. Это книги значительно выше уровнем.
ОтветитьУдалитьЭти книги немного о другом, на мой взгляд. Их стоит читать для повышения общего уровня образованности. Для эффективного использования clojure они совершенно необязательны, полезнее потратить время на чтение (и написание) кода.
ОтветитьУдалитьПол Грэм по этому поводу очень хорошо выразился в свое время. В пересказе это звучит примерно так: "Начинающего программиста нельзя научить программированию по принципу 'снизу-вверх', потому что он не знает, где верх" :-) Как мне тебе объяснить ценность этих книг, если ты их не читал? Знание синтаксиса языка не делает из новичка программиста. А эти книги -- делают. Так что я уверен, тебя ждет очень увлекательное чтение :-)
ОтветитьУдалить> Еще раз: я не говорю, что SICP или on lisp (не знаю насчет LOL'а) - плохие или ненужные книжки. Я говорю о том, что утверждение о том, будто бы без них невозможно эффективно писать на clojure - вымысел и бред.
ОтветитьУдалитьКонечно, ты можешь писать на Clojure без SICP и OnLisp. Но никаких преимуществ Clojure перед другими языками ты не получишь. В твоих руках Clojure будет примерно тем же, что и Scala -- обычный язык программирования, нацеленный на конкурентность :-)
Так что, конечно, пиши на Clojure и без OnLisp, я буду только рад, если нас (clojure-программеров) станет больше. Со временем появится интерес и к более сложным возможностям кложуры, учитывая ее "лисповость".
Большое спасибо за доклад, благодаря выложенной презентации и конспекту доклада открыл для себя и знакомых lisp. Пока lisp приносит массу удовольствия и новую "ветку талантов", думаю скоро станет основным языком.
ОтветитьУдалитьЕсли этот доклад будет доступен в более удобном виде, благодарить вас, за открытие для себя lisp'a, будут гораздо больше программистов.
Отдельное спасибо за список литературы в коментариях к этому посту.
Спасибо за такой отзыв, мне очень приятно! :-) Планирую записать скринкаст с кратким изложением основных тем доклада и live-демонстрацией работы с лиспом при помощи Emacs/Slime.
ОтветитьУдалитьОсновной аргумент для начала изучения - лёгкие 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, но вот лисп :)
Да в курсе я о MPS и о нескольких других подобных разработках :-) У них у ВСЕХ есть недостаток: они сложные. Что бы там ни говорили, как бы ни доказывали, а все-таки, не станет программист для себя на каждую ерундовину делать DSL на MPS. А вот лиспер -- станет, притом не задумываясь даже о том, DSL это будет или так, мелкое изменение в самом лиспе.
ОтветитьУдалитьMPS хорош там, где нужен один-два крупных DSL-а. Мелкие изменения в язык на нем вносить не станут.