Ужасная поддержка в IDE

Cursive длч intelij idea вроде хорошо работает.

Вкусом говна интересуешься? Сам и пробуй, молча. Остальным твои извращения не интересны.

Типизация библиотекой — не самое хорошее решение

Ну, например, если твой код хоть немного сложнее факториала или hello, world. Тогда без дебаггера ты просто ноль.

Тогда уж так

(если (не (смущают (и скобочки jvm))))

Тогда уж так

Верно. Я пару минут размышлял, написать «правильно» или «по-русски». В итоге решил, что все равно ведь стёб, и остановился на втором варианте как более читаемом.

(правильных (поцонов (не (смущают (йоу ]

правильные $ посоны $ просто $ пишут $ на $ хаскеле

А что конкретно в продакшене то?

в продакшене то?

Запомни: частицы -то, -либо, кое-, -нибудь, -таки, -(т)ка, -де пишутся через дефис, %username%.

> можно писать под android

только будет тормозить

а точно будет тормозить? (я просто ни разу не пробовал, а было бы интересно :))

очень сильно?

Ну здрасте. Как раз каналы и корутины решают сейчас больше всех, покрывая много юзкейсов где раньше использовались фьючеры/промисы.

А можно сакральный смысл этого, ну кроме Ъ, конечно. Не лучше ли довольствоваться фьючерами/промисами там, где можно обойтись без каналов?

Алсо, что в Clojure понимается под корутинами?

Алсо, что в Clojure понимается под корутинами?

https://github.com/clojure/core.async ящитаю

Отвратительные экзепшены

А в Ъ Ынтырпрайз Джава тоже.

Блевотный дебаггер

Он не блевотный. Его как бы нет почти нет :).

Ужасная поддержка в IDE

CIDER же! ;)

https://github.com/clojure/core.async ящитаю

Ну наверно, просто как-то нелогично выглядело же. Каналы тоже в основном в контексте core.async существуют. Т.е. получается сказать «каналы и корутины» то же самое, что сказать «ботинки и обувь».

Представил. И даже видел: https://github.com/clojure/core.typed (хорошим кодом я это не считаю, т.к. смесь из кучи математики + кучи кода + одного разработчика + кучи лет разработки и когда я смотрел на него последний раз, то там были хаки для обхода циклических зависимостей + макросы по 100 с лишним строк).

А все же надеяться больше не на кого :). Ну есть еще https://github.com/Prismatic/schema (рядом, но не совсем то).

Вот ты узнал, что функция у тебя не работает. Как ты без дебаггера узнаешь, на каких входных данных (и при каком состоянии системы/shared state) она не работает? Отладочные принты для всех 100500 переменных? :)

Clojure приучает к хорошему :). Да, покрытие кода тестами, если разработчик желает долгой жизни проекту должно приближаться к 100%.

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

Универсальный совет прост: пользоваться только очень популярными, активно используемыми и разрабатываемыми либами. И читать их код. Тем более, что в большинстве случаев это просто врапперы для java-либ.

а точно будет тормозить? (я просто ни разу не пробовал, а было бы интересно :))

очень сильно?

Оно не тормозит, но сами приложения долговато грузятся. А так вполне можно писать.

Ну наверно, просто как-то нелогично выглядело же. Каналы тоже в основном в контексте core.async существуют. Т.е. получается сказать «каналы и корутины» то же самое, что сказать «ботинки и обувь».

Канал суть очередь. Корутина суть дешевый тред. Это два разные концепта и совершенно друг от друга не зависимые, хотя в конексте кложуры и взаимодействующие.

А можно сакральный смысл этого, ну кроме Ъ, конечно. Не лучше ли довольствоваться фьючерами/промисами там, где можно обойтись без каналов?

Смысл в том, что фьючеры ни разу не selling point. Они сейчас много где есть. Да в той же джаве, откуда они в кложуру были перетянуты как-есть.

Плюс в ClojureScript ты промисами никак не подовольствуешься.

Корутина суть дешевый тред.

Если речь, о так называемых дешевых тредах из core.async, то я там дешевизны никакой не увидел. Обычные JVM-ные треды, которые, в свою очередь, есть полноценные треды ОС. Т.е. все равно надо лечить ограниченим тред-пула. Я что-то не так делаю?

Смысл в том, что фьючеры ни разу не selling point. Они сейчас много где есть. Да в той же джаве, откуда они в кложуру были перетянуты как-есть.

А кто ж спорит-то? Ну синтаксис покрасивее разве что :). Наоборот, ближе к plain java - чем плохо? Меньше магии, больше механики. Хорошая программа должна быть простой, тупой, надежной и эффективной. Как автомат Калашникова ;).

Если речь, о так называемых дешевых тредах из core.async, то я там дешевизны никакой не увидел. Обычные JVM-ные треды

Нет, там CSP-шные зеленые треды. Ты видимо не дочитал/дослушал до конца.

А кто ж спорит-то? Ну синтаксис покрасивее разве что :). Наоборот, ближе к plain java - чем плохо? Меньше магии, больше механики. Хорошая программа должна быть простой, тупой, надежной и эффективной. Как автомат Калашникова.

Нет, ну что это за аргумент вообще. С таким успехом никакая кложурная либо скаловская магия вообще не нужна, можно продолжать писать на автомате Гослинга.

Нет, там CSP-шные зеленые треды. Ты видимо не дочитал/дослушал до конца.

Э-э-э, чукча не читатель, чукча писатель. Моя сразу код писать и при этом на поведение JVM смотреть, тама треды считать. Много насчитать... :). Ну ладно, завтра будет аргументация с кодом и цифрами :).

Нет, ну что это за аргумент вообще. С таким успехом никакая кложурная либо скаловская магия вообще не нужна, можно продолжать писать на автомате Гослинга.

Ну да :). Хотя не совсем об этом речь. Вот мне нравится такой пример: swing и seesaw. Вроде в seesaw ничего не изобрели. Обычный враппер для swing. Но его API прекрасен. Приятно писать. Чего не скажешь о swing на java.

Э-э-э, чукча не читатель, чукча писатель. Моя сразу код писать и при этом на поведение JVM смотреть, тама треды считать. Много насчитать... :). Ну ладно, завтра будет аргументация с кодом и цифрами :).

Ты видимо использовал макро thread (который таки создает нити ОС) вместо go.

Пример понятен, но не всегда худые врапперы решают проблему. Возвращаясь к теме кложуровских промисов, они совершенно убогие по сравнению со скаловскими. И если бы не магический core.async, то clojure скале бы сливал всухую в вопросах решения сложных конкуррентных задач.

Э-э-э, чукча не читатель, чукча писатель. Моя сразу код писать и при этом на поведение JVM смотреть, тама треды считать. Много насчитать... :). Ну ладно, завтра будет аргументация с кодом и цифрами :).

В браужере вполне зелено. В самой кложуре - это детали реализации.

https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/co...

А что конкретно в продакшене то?

На бекенде крутится нечто вроде краулера.

Да, покрытие кода тестами, если разработчик желает долгой жизни проекту должно приближаться к 100%.

обычно у заказчика нет денег на тесты

нафигачить 100500 фич до вечера, не очень качественно - но лишь бы как-то работали - это да

качественные фичи - редко

тесты - очень-очень редко

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

Вроде всё круто, но хочется услышать вашего мнения.

JS и в Африке JS

нужно правильно понимать психологию мелкого бизнеса, выдающего что-то на аутсорс. Им нужно прежде всего сэкономить, и всё остальное потом. Если бы им не нужно было экономить, они бы заказали готовое хорошее решение у монстров (Microsoft и партнеры, например). Но у них нет денег заказывать у монстров, поэтому они в интернете нагуглили «software company in russia» и ждут что это будет вталово по дешману. Тратить пол-бюджета на тесты? Какие тесты? Нет, не слышали.

типа LightTable

Что за шрифт на скриншоте?

А все же надеяться больше не на кого :).

Да толку от core.typed если им никто не пользуется, а разрабатывает его ровно один человек на основе своей диссертации? Свалит Эмброз и проект загнётся, т.к. лично я сильно сомневаюсь, что кто-то полезет в эти дебри, чтобы развивать их.

Так что тесты наше всё)

Оно не тормозит, но сами приложения долговато грузятся.

Там же сейчас с art появилась aot компиляция, должно быстро на 4.4+ запускаться.

Статическая типизация там не как в haskell, а унификация не как в прологе.

Логов достаточно в простых случаях, и только с малым количеством влияющих на процесс переменных. А так дебагер рулит, и без него никак. Ты решишь проблему и логами, но убъёшь на это три часа, а я 10 минут с дебагером.

Дебагер нужен только если код - куча неподдерживаемого говна.

Ты решишь проблему и логами, но убъёшь на это три часа, а я 10 минут с дебагером.

На практике наоборот. Ты часами будешь копаться со своими дебагером, пока нормальный человек с нормальным кодом все по логам поймет.

Статическая типизация там не как в haskell, а унификация не как в прологе.

Да почти тоже самое.

Да почти тоже самое.

Лол.

Что за шрифт на скриншоте?

Fira Mono — бесплатный, с кириллицей, от Эрика Шпикерманна (дизайнер знаменитого FF Meta).

Меня переубеждать не надо. (: Я сам как-то больше дебагер предпочитаю.

Ты часами будешь копаться со своими дебагером, пока нормальный человек с нормальным кодом все по логам поймет.

Ну это передёргивание. Интересна ситуация когда код одинаковый. А не «идеальный код с идеальными логами» против «говнокода с дебагером».

Спасибо

Ну это передёргивание. Интересна ситуация когда код одинаковый. А не «идеальный код с идеальными логами» против «говнокода с дебагером».

Еще раз - если тебе нужен дебаггер, то это уже значит, что ты делаешь что-то неправильно. Так что язык без дебагера - хороший язык, потому что он заставляет тебя делать правильно. worse is better. Программист - он ведь такая сука, что сам по себе хороший код писать не будет, его заставлять надо.

Еще раз - если тебе нужен дебаггер, то это уже значит, что ты делаешь что-то неправильно.

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

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

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

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

Ну и будут они писать код с printf-ами и прочей временной чушью, которую, по мере решения проблем, будут вычищать. А ты потом будешь сосать лапу, пытаясь понять, что же авторы имели в виду.

Видел я сотни такого говна в embedded.

Ну и будут они писать код с printf-ами и прочей временной чушью, которую, по мере решения проблем, будут вычищать.

При чем тут принтфы? Просто будут писать код control flow которого понятен и естественен. Потому дебагер и не нужен.

ну в embeded с дебагерами как раз нет никогда проблем

Просто будут писать код control flow которого понятен и естественен.

А эльфы будут испражняться благоухающими цветочками и попердывать радугами.