Party hard по-программистски, или как мы писали ClojureCup 2014

[tonsky]

Пожалуйста :)

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

[ingspree]

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

То же самое хотел сказать. :) Очень круто вышло.

[PQR]

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

В итоге это мнение поменялось, или действительно всё так и есть — сложно читать и приходится входить из концепций языка в реальном мире?

[tonsky]

В реальном мире цель работы программы — это менять свое состояние и состояние вокруг, т.е. сайд-эффекты. Кложа прагматичный язык, и не пытается этот факт скрыть или как-то пристыдить, в ней все нормально и с императивными конструкциями, и с мутабельным состоянием. Т.е. всё что есть в обычных языках тут тоже есть. Но, у них даже более удобные и безопасные конструкции для работы с ним предусмотрены помимо обычных get/set! (напр., atom-ы). Концепция языка предполагает, впрочем, что работа с мутабельным состоянием делается редко и явно. Это особо не усложняет программирование, но программа получается проще в понимании и надежней.

[ingspree]

> Это особо не усложняет программирование, но программа получается проще в понимании и надежней.

С другой стороны, привычки приходится ломать прилично.

[tonsky]

Да, но in a good way. Потом обратно уже не хочется.

[ttim]

У нас была проблема незнания идиом того как работать с мутабельным стейтом в кложе. А об использовании атомов что-то мы не подумали =)

Но вот представление всего состояния программы в одном немутабельном состоянии общую логику сильно упростило на мой взгляд.

[ingspree]

> обертку над ним quiescent (а это неправильное, но терпимое)

Забыл спросить, а чего неправильное-то? А то мы тоже его взяли и я в принципе доволен.

[ttim]

Там ссылка на коммит есть =)

Ну и как оказалось (написали в комментах к коммиту) это была проблема вида RTFM: все аргументы кроме первого не учитываются quiescent-ом для re-render-а, они там называются static arguments. Как мне кажется странное решение, и не то чтобы это было нужно.

Еще из немного неприятного: по +- понятным причинам слетала поддержка резолва аргументов в IDE. Можно было наверное вручную раскрывать макросы, но не сделали.

А вообще как чисто решение для state->view над реактом — quiescent приятен.

[ingspree]

А, статики да, спорная идея. Мне еще не хватает children'ов в нормальном синтаксисе, хоть бери и форкай, а то чувак подзабил как-то.

[ttim]

Я вообще не понял зачем они нужны, ведь если они не меняются, то и rerender-а не будет? Зато передавать нескольких аргументов мапой/вектором приходится. Странно.

И чилды нужны, так что реально форкать надо =)