Николай Рыжиков - Clojure: интерактивная разработка для интерактивного веб
Вставка
- Опубліковано 4 жов 2024
- Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/Ypf1HW
- -
. . . . Николай Рыжиков -
Clojure: интерактивная разработка для интерактивного веб
Java-конференция Joker 2014
Санкт-Петербург, 20 - 21 октября 2014
Современный веб-сервер становится интерактивным (websockets, server sent events) и распределённым (microservices). А разрабатывать его нужно, как всегда, быстро и надежно.
В докладе я расскажу про язык программирования Clojure и о том, почему он является идеальным инструментом для разработки интерактивных систем:
Какие библиотеки и инструменты есть для web-стека;
Как программирование значениями и чистыми функциями (ФП) упраздняет многие проблемы concurrency;
Как работать с изменяемым состоянием с использованием Software Transactional Memory;
Как писать простой асинхронный код с помощью библиотеки core.async;
Как разрабатывать, интерактивно взаимодействуя с работающей системой прямо из редактора.
Потрясающе!
Большой и жирный лойс, отличный видеокурс, наглядно всё демонстрирующий.
К докладчику: у вас ошибка в первом JavaScript примере, - простой перенос после return, в JavaScript с этим есть подводный камень, если после return стоит перенос, то компилятор подразумевает там точку с запятой, так что по факту ваш код равен:
function myfn(x, y) {
return;
x*x + y*y;
}
А следовательно функция всегда будет возвращать undefined. Значение после return с переносом следует оборачивать в скобки, при этом скобка должна открываться на строке с return:
function myfn(x, y) {
return (
x*x + y*y
);
}
+Viacheslav Lotsmanov (unclechu) На самом деле это раздражает. Зато можно задачки для друзей составлять, типа что вернет такой то код. А в итоге окажется что в разных браузерах по разному. Это просто js, этим все сказано.
страшно представить как он программирует сидя )))
начни писать на clojure/script и сможешь, стоя на голове :)
уже 2 года пишу, пока не могу на голове :)
Да, а лёжа , он вообще, подключается мозгом в repl и фигачит мысленно прямо в ast на прод.
CompilerException java.lang.RuntimeException: No such namespace: ohs, compiling:(NO_SOURCE_PATH:32:3) - у меня даже номера строк таких нет, на что ругается?
Скобки неправильно посчитаны 10 и 12 будет
what laptop are you using ?
This is a Chromebook.
а что за операцинока у него? убунта?
Igor Konoplyanko по иконкам - это последний андроид.
chrome os, похоже
Ни че не понял, пойду дальше учить бейсик.
не уловил фишку функционального языка, я так же могу наклепать функций (в процедурном языке) и передавать обычные массивы, при этом я улавливаю фишку где у меня данные и где алгоритм работающий с данными.
насчет стиля именования ch, jv, ohs, us, cnt - это жесть, в маленьком то скрипте потеряешь смысл, я уже молчу про большую программу. Надеюсь это не общепринятый код-стайл.
про генерацию html и css это боль (зачем?). Они же самодостаточны и гораздо удобнее редактировать их отдельно (аля MVC встраивая данные в шаблоны, а не делая шаблоны кодом). То есть, генерировать хтмл теги через хелперы-функции(методы) которые тупо клепают html теги (причем все), мы отучили от такого людей давно :)
+Евгений Гикс "мы отучили от такого людей давно" - выдаёте желаемое за действительное. А как же куча препроцессоров аля jade, stylus, less, sass, которые так популярны нынче? Не могу с вами никак согласиться, CSS в частности как есть отнюдь не самодостаточен, копипаста и отсутствие всякой вложенности - вот это боль. Плюс генерация повторяющегося кода - это гораздо лучше, и легче поддерживать, чем тонну копипасты.
По поводу именования - полностью согласен, так нужно делать, если хочешь сам же потом разгадывать загадки, спустя время.
Фишка функционального ЯП - иммутабельность данных, надёжный ожидаемый результат, лёгкость распараллеливания вычислений. То, что вы можете применять эту парадигму в императивном ЯП, - это отлично, и хорошо если вы это делаете, но хорошо понять парадигму помогают именно ФЯП. В императивных ЯП всегда можно случайно и не нарочно нарушить иммутабельность, а потом сидеть и отлаживать.
Viacheslav Lotsmanov
Я вижу вы разбираетесь в ФП, давайте по-дискутируем. :)
Что конкретно (без маркетинга) дает мне ФП (я его правда не знаю и вот хочу понять в чем я выиграю).
Иммутабильность данных, если это требуется то, это достигается соглашениями или если возможно конструкциями языка (в ООП же можно вообще огородится одними геттерами). Но в чем плюс структурной парадигмы - если нам нужно реальные переменные, они у нас есть (именно переменная где данные не являются управляющими и которые можно менять сколько угодно раз, например обновить в массиве данных дату последнего посещения пользователя страницы, не копируя весь массив/объект).
Насчет CSS - все эти "препроцессоры" придумали не для нас, а для людей, которым нужен близкий css-стиль. Мы же можем на императивном языке сделать что хочешь (сам лично писал PHP -> CSS с блекджеком и ...)
В общем, можно ли на ФП написать крупный проект с тонной слоев абстракции (а без этого никак) и при этом не сойдя с ума от количество функций? То есть, меня интересует не утопия, которую решает этот язык (как и ООП утопия), а конкретно как он ведёт себя с проектом, который крупнее обычного скрипта с сокращенными именами в стили Си.
+Евгений Гикс по опыту работы с большими проектами могу сказать, что императивный язык в огромном проекте - большая проблема, т.к. отдладка ошибок, - просто ад, приходится искать где же какая функция запатчила какой-то там объект не тем, что ожидалось, в специфичной редко возникаемой ситуации (см. плавающие баги).
Написать большой проект (с большим кол-вом абстракций) можно, и даже нужно. Более того, после освоения функциональной парадигмы начинаешь писать в функциональном стиле в императивных языках, и не потому что это какая-то религия, а потому что избавляешь себя от ситуаций с вырыванием волос на голове при отладке, т.к. чистые функции можно целиком покрыть тестами и быть увереным, что функция возвращает правильное значение, когда в неё передали такой-то аргумент, а не в том, что она возвращает правильное значение, если вон та переменная (а зачастую целый ворох из хеш-мапов) из скоупа выше в данный момент времени имеет правильный тип/значение.
Чем больше проект, тем больше сложностей добавляет повсеместная мутабельность, вы никогда не можете быть уверены в своём коде.
Это моё личное мнение, я предложил бы попробовать написать такой проект, и попробовать его поотлаживать, и сравнить аналогичный проект аналогичной величины, написанный императивно, и составить собственное мнение, что же легче поддерживать/разрабатывать в краткосрочной перспективе и долгосрочной.
Опять все абстрактно.
Чистые функции возможны для каких-то алгоритмов (и возможно сложных), но реализовать систему кода (то есть целый программный проект) чистыми функциями по-моему не реально (утопично). Если и возможно то скорее через какие-то костыли, крайне не удобные (и скорее они представляют пустую прослойку. То есть что значит "пустую" - некий код который выполняет просто прокси для данных, хотя я могу ошибаться, может есть тут революционное решение?).
Чистые функции легко пишутся на императивном языке (чаще они являются элементами не чистых функций). Это все простое соглашение, типа хороший стиль (например сам ООП не заставляет писать все свойства объекта скрытыми, то есть сама инкапсуляция достигается опять же соглашениями, правилами стиля).
>Чем больше проект, тем больше сложностей добавляет повсеместная мутабельность
Если программист изменяет глобальные значения, то он либо понимает что делает, либо он не программист. Но даже тут есть своя плюшка. Можно сделать грязный хак, который будет временным решением. Или протестировать налету с другими значениями. В общем зачем вставлять палки в колеса, когда это не нужно?
Имхо, в 21 веке лучше показывать код в IDE, а то порой вообще не понятно что да как, такое ощущение что автор сам для себя комментирует.
lein или boot + редактор = достаточно :)
вот и выросло поколение людей, которые не знают что такое vim
Потрясающе!