Соглашусь с автором в том что Clojure отличный язык. Годовой опыт коммерческого использования не дал мне повода для сомнений а наоборот подтвердил это. Язык очень простой, писать и проверять код очень просто. Как следствие при меньших трудозатратах выход намного выше.
Но. Касаемо использования данной библиотеки у меня сомнения, точнее не вижу вообще в ней смысла. Так же как не нашел смысла в core.async, 99% atom'ы и agent'ы решают задачи с успехом. По сути core.async поможет только если вы строите приложение внутренний через обмен сообщениями, но оправдано ли это?
Если у кого-то есть вопросы сомнения по поводу Clojure в продакшене, можете задать вопросы кэтому комментарию, попытаюсь ответить.
Вы считаете что написать много типов это так же быстро как их не писать. Для меня это звучит аналогично следующему — есть магазин в 100 метрах и я до него дойду за 1 минуту и есть магазин в 1000 метрах до которого вы добежите за 1 минуту, значит добираться до них как минимум однинаково по времени, а может и быстрее если бежать с большей скоростью.
Если бы у меня не было богатого опыта со Scala, на реальных крупных проектах, а не коленочных поделках, были бы сомнения насколько полезно писать программы с большим кол-во пользовательских типов и связей между ними.
Про вермишель на питоне/перле/схеме, тут вы передергиваете имхо, на этих языках можно решить задачу намного лаконичнее — компактно и без потери читаемости.
Конечно если вы на одну чашу весов ставите код на Haskell подобном языке где выстрадана структура типов и приведена к читаемому виду, а на другой написаный на коленке код на перечисленных языка, преимущества не на стороне последних, но вот если потратить времени не более чем на продумывание программы на типах, получиться то о чем я говорил — лаконично.
Не соглашусь с вашим тезисом, я очень долго работал на статически типизируемых языках со сложной системой типов: Java, Scala.
По итогу я не нашел преимуществ. Код очень сильно разбухает из-за типов. Изменение в бизнес логике превращаются в переписывание большого куска кода или костыли.
Разбираться в проектах написанных на языках со сложной системой типов очень трудно, если ты не автор. Нужно сперва изучить всю модель абстракции — за которой скрыта реальная логика работы.
Если вы утверждаете о каких то домашних проектах то ок, вы в праве писать на чем угодно, но мне слабо верится что в ваш работодатель будет ждать пока вы отрефакторите свою "идеальную" систему типов под новую задачу.
Скажу ещё так, используя Lisp с которым вы не согласились, а конкретно Clojure, вы напишете ваш проект значительно быстрее и ещё успеете все тестами прокрыть, за время которое вы обдумываете какие типы создать в Haskell, конечно если вам не хватит REPL'a для проверки всего (REPL oriented programming).
Забыли добавить что большую часть времени будет тратится на возню и "срач" какие типы писать. Что затягивает сроки. Но не избавляет от ошибок.
При изменении бизнес требований, придется переписывать много когда, т.к. все жестко связано типами или вставлять костыли.
Вы вырвали фразу из контекста и прилепили к ней кажущееся очевидным, но по сути некорректный контраргумент.
Тот что однороднось font-end и back-end с точки зреция общего языка, Может Быт хорошей идеей это факт беспорный т.к. нужно знать только 1-н язык и можно использовать абстракции не доступные в JS но доступные в другом языке и т.д…
Но язык этот должен подходить и для front-end и для backend. Если вы будете использовать C++ или Go для фронта, то ничего кроме раздутых сроков и бюджета не получите, для подавляющего числа проектов, надесь понятно почему?
А тут получается что котлин и для бэка не очень, т.к. есть другие альтернативы и получше. Так и для фронта не очень, т.к. придется писать кучу ООП шного кода, вместо простого JS или аналогов.
Для начала вы ответьте на вопрос зачем использовать колтин для разработки back-end'a, если есть другие альтернативы и они полуше, на мой взгляд, т.к. не являются незначительным улучшеним ситаксиса Java, а потому вопрос с фронтом сам отпадет, хотя я его уже обосновал, через резульат который вы получите — кучу ООП гемора и увеличение сроков, как следствие.
Возможно вы просто кроме Java ни на чем и не программировали, поэтому вам котлин кажется глотком свежего воздуха, во всяком случае я не вижу другого объяснения, почему вы считаете небольшое кол-во синтаксического сахара, чем то прорывным и вообще достойным внимания.
Ну я даже не знаю… задавать вопрос «зачем» в комментариях к посту, в котором мы рассказываем о том, какое распространение получил Kotlin?
А где задавать данный вопрос? Мне интересно что люди находят в языке, раз он по вашим словам быстро растет. Не вижу проблемы, с вопросами.
Я прочел всю спеку котлина, но ничего интересного не нашел, в Scala, Clojure больше возможностей и они позволяют намного проще писать ПО и надежнее. У них есть как минимум тоже что в котлине на 99%. Что тогда дает котлин? По вашим словам новые концепции это не важно, может быть в языке какие то старые концепции реализованы лучше? Я хочу понять, т.к. не нашел не одного преимущества.
У Google поддержка ограничивается Android, это и понятно, только здесь у котлина есть преимущество и только одно — Scala и Clojure имеют свой не маленький по размерам рантайм, что не позволяет их использовать в разработке под Андроид.
Вот мне интересно зачем? Отличных языков под JS полно, с точки зрения скорости разработки и надежности написанного ПО, ClojureScript, TypeScript, и т.д. если у вас очень большой SPA. В други случая зачем менять JS, имхо отличный язык — потому что простой.
Под JVM для server side есть так же куча отличных языков Clojure, Scala, Groovy и т.д. которые несут новые концепции а не просто немного синтаксического сахара.
Может кто-то объяснить, приведя хотя бы несколько существенных преимуществ над Java? Только без Null Safety, пожалуйста. А что-то действительно существенное.
А так же что Kotlin дает для разработки front-end'a? Кроме возни и гемора с классами и как следствие тонн всяких конверторов JSON->Object и обратно?
Не до конца вас понял, социалисты и коммунисты — левые или это отдельная категория?
Ибо если исходить из сути идеи — левые, центристы, правые — это диапазоны на шкале ценностей. А социалисты, коммунисты и нацисты, фашисты это по две точки у обоих концов.
Разумный подход для начальства — поговорить со звездой, 99% это будет адекватный человек а его негативное обращение со многими другим возникло не на пустом месте. Подумав, этот человек может изменить подход.
От того что систему будет разрабатывать группа не очень умных зато очень приветливых — хорошего результата ждать не следует.
Быть доброжелательным это самая примитивная стратегия, более того чем хуже специалист тем обычно он дружелюбнее, таким образом компенсирует свою профессиональную слабость.
ИМХО, статья чуть менее чем полностью левацкая. Следующая стадия это — мы не берем на работу хороших специалистов, что бы "остальные" не комплексовали.
На мой взгляд его бедный синтаксис преподносился как одно из преимуществ, утверждалось что это позволит чуть ли не любому новичку в кратчайшие строки влиться в проект, потому как код будет прост и понятен. По этому я и написал что видели.)
Но соглашусь, для меня так же было сразу очевидно что писать бизнес логику на этом языке будет очень напряженно, придется писать много шаблонного кода и как результат в каждом проекте появятся свои абстракции, по факту — костыли.
Статья неоднозначная имхо. Не могу стать как на сторону требующих показать свой сторонний проект так и говорящих что программирование — как один из смыслов жизнь не так уж и важно что бы быть хорошим специалистом.
Я например не имею своего проекта, он мне и незачем, но я читаю очень много и обдумываю.
Согласие с мыслью что нужно быть аккуратно с компаниями которые ищу "увлеченных", зачастую это показатель того что нужен пахарь.
Выглядит и звучит так же, как когда чиновники говорят о прорывах которые в других странах появились уже 10 лет назад.)
Что например мешало добавить удобные методы для создания и манипуляции коллекциями раньше, мне не понятно.
В новой версии JVM у вас может что-то работать уже иначе. И вообще непонятно зачем так "загоняться" по поводу микрооптимизаций JVM. Возможно если вы уперлись в производительность и дальше возможный выход только оптимизации такого рода, а я думаю в подавляющей массе проектов подобное не возникнет, нужно посмотреть в сторону других инструментов/языков.
p.s.
В общем спасибо за статью, то что написал не является целью её критики или утверждения что статья не нужна.)
Если есть доступы на изменение данных это уже плохо. У вас какой то парадокс получается.)
Но даже если предположить что все легко восстановимо, то за чем это? К тому же случайные небольшие изменения можно не заметить, и как вы их потом будите отлавливать и фиксить не понятно, а они будут втихую портить кому-то жизнь ухудшая качестве продукта.
Ну и ещё один, опытные сотрудники должны проводить ревью каждой задачи.
Ну и ещё один, в любой непонятной ситуации с бизнес логикой, спроси тех кто уже давно работает, все ли я понимаю правильно.
Хотя судя по тому что проброской эксепшенов отлавливают такие бизнес кейсы и не делают ревью и эти советы могут и не помоч.
Не думаю что это причина кого-то повышать, не вижу здесь заслуг junior'а, если бы он нашел и указал на это а не все выяснилось в результате ошибки, можно говорить о вознаграждении.
А вот разобраться почему доступ к проду не был защищен и более того креды попали в описание дев настройки нужно. Ну и соответственно потом делать выводы. Возможно это реально случайны косяк, хоть и серьезный, а возможно система.
Что вы имеете ввиду? Насколько мне известно любой Java код можно вызвать из Scala, наоборот нет и это очевидно.) Scala более богатый на возможности язык чем Java.
Соглашусь с автором в том что Clojure отличный язык. Годовой опыт коммерческого использования не дал мне повода для сомнений а наоборот подтвердил это. Язык очень простой, писать и проверять код очень просто. Как следствие при меньших трудозатратах выход намного выше.
Но. Касаемо использования данной библиотеки у меня сомнения, точнее не вижу вообще в ней смысла. Так же как не нашел смысла в core.async, 99% atom'ы и agent'ы решают задачи с успехом. По сути core.async поможет только если вы строите приложение внутренний через обмен сообщениями, но оправдано ли это?
Если у кого-то есть вопросы сомнения по поводу Clojure в продакшене, можете задать вопросы кэтому комментарию, попытаюсь ответить.
Вы считаете что написать много типов это так же быстро как их не писать. Для меня это звучит аналогично следующему — есть магазин в 100 метрах и я до него дойду за 1 минуту и есть магазин в 1000 метрах до которого вы добежите за 1 минуту, значит добираться до них как минимум однинаково по времени, а может и быстрее если бежать с большей скоростью.
Если бы у меня не было богатого опыта со Scala, на реальных крупных проектах, а не коленочных поделках, были бы сомнения насколько полезно писать программы с большим кол-во пользовательских типов и связей между ними.
Про вермишель на питоне/перле/схеме, тут вы передергиваете имхо, на этих языках можно решить задачу намного лаконичнее — компактно и без потери читаемости.
Конечно если вы на одну чашу весов ставите код на Haskell подобном языке где выстрадана структура типов и приведена к читаемому виду, а на другой написаный на коленке код на перечисленных языка, преимущества не на стороне последних, но вот если потратить времени не более чем на продумывание программы на типах, получиться то о чем я говорил — лаконично.
Не соглашусь с вашим тезисом, я очень долго работал на статически типизируемых языках со сложной системой типов: Java, Scala.
По итогу я не нашел преимуществ. Код очень сильно разбухает из-за типов. Изменение в бизнес логике превращаются в переписывание большого куска кода или костыли.
Разбираться в проектах написанных на языках со сложной системой типов очень трудно, если ты не автор. Нужно сперва изучить всю модель абстракции — за которой скрыта реальная логика работы.
Если вы утверждаете о каких то домашних проектах то ок, вы в праве писать на чем угодно, но мне слабо верится что в ваш работодатель будет ждать пока вы отрефакторите свою "идеальную" систему типов под новую задачу.
Скажу ещё так, используя Lisp с которым вы не согласились, а конкретно Clojure, вы напишете ваш проект значительно быстрее и ещё успеете все тестами прокрыть, за время которое вы обдумываете какие типы создать в Haskell, конечно если вам не хватит REPL'a для проверки всего (REPL oriented programming).
Забыли добавить что большую часть времени будет тратится на возню и "срач" какие типы писать. Что затягивает сроки. Но не избавляет от ошибок.
При изменении бизнес требований, придется переписывать много когда, т.к. все жестко связано типами или вставлять костыли.
Вы вырвали фразу из контекста и прилепили к ней кажущееся очевидным, но по сути некорректный контраргумент.
Тот что однороднось font-end и back-end с точки зреция общего языка, Может Быт хорошей идеей это факт беспорный т.к. нужно знать только 1-н язык и можно использовать абстракции не доступные в JS но доступные в другом языке и т.д…
Но язык этот должен подходить и для front-end и для backend. Если вы будете использовать C++ или Go для фронта, то ничего кроме раздутых сроков и бюджета не получите, для подавляющего числа проектов, надесь понятно почему?
А тут получается что котлин и для бэка не очень, т.к. есть другие альтернативы и получше. Так и для фронта не очень, т.к. придется писать кучу ООП шного кода, вместо простого JS или аналогов.
Для начала вы ответьте на вопрос зачем использовать колтин для разработки back-end'a, если есть другие альтернативы и они полуше, на мой взгляд, т.к. не являются незначительным улучшеним ситаксиса Java, а потому вопрос с фронтом сам отпадет, хотя я его уже обосновал, через резульат который вы получите — кучу ООП гемора и увеличение сроков, как следствие.
Возможно вы просто кроме Java ни на чем и не программировали, поэтому вам котлин кажется глотком свежего воздуха, во всяком случае я не вижу другого объяснения, почему вы считаете небольшое кол-во синтаксического сахара, чем то прорывным и вообще достойным внимания.
А где задавать данный вопрос? Мне интересно что люди находят в языке, раз он по вашим словам быстро растет. Не вижу проблемы, с вопросами.
Я прочел всю спеку котлина, но ничего интересного не нашел, в Scala, Clojure больше возможностей и они позволяют намного проще писать ПО и надежнее. У них есть как минимум тоже что в котлине на 99%. Что тогда дает котлин? По вашим словам новые концепции это не важно, может быть в языке какие то старые концепции реализованы лучше? Я хочу понять, т.к. не нашел не одного преимущества.
У Google поддержка ограничивается Android, это и понятно, только здесь у котлина есть преимущество и только одно — Scala и Clojure имеют свой не маленький по размерам рантайм, что не позволяет их использовать в разработке под Андроид.
Вот мне интересно зачем? Отличных языков под JS полно, с точки зрения скорости разработки и надежности написанного ПО, ClojureScript, TypeScript, и т.д. если у вас очень большой SPA. В други случая зачем менять JS, имхо отличный язык — потому что простой.
Под JVM для server side есть так же куча отличных языков Clojure, Scala, Groovy и т.д. которые несут новые концепции а не просто немного синтаксического сахара.
Может кто-то объяснить, приведя хотя бы несколько существенных преимуществ над Java? Только без Null Safety, пожалуйста. А что-то действительно существенное.
А так же что Kotlin дает для разработки front-end'a? Кроме возни и гемора с классами и как следствие тонн всяких конверторов JSON->Object и обратно?
Не до конца вас понял, социалисты и коммунисты — левые или это отдельная категория?
Ибо если исходить из сути идеи — левые, центристы, правые — это диапазоны на шкале ценностей. А социалисты, коммунисты и нацисты, фашисты это по две точки у обоих концов.
Я и имел ввиду левацкая — в смысле радикально левая.)
Оффтоп. Кроме логики я не вижу идей, которые будучи возведенными в абсолют не несли "угрозы".
Разумный подход для начальства — поговорить со звездой, 99% это будет адекватный человек а его негативное обращение со многими другим возникло не на пустом месте. Подумав, этот человек может изменить подход.
От того что систему будет разрабатывать группа не очень умных зато очень приветливых — хорошего результата ждать не следует.
Быть доброжелательным это самая примитивная стратегия, более того чем хуже специалист тем обычно он дружелюбнее, таким образом компенсирует свою профессиональную слабость.
ИМХО, статья чуть менее чем полностью левацкая. Следующая стадия это — мы не берем на работу хороших специалистов, что бы "остальные" не комплексовали.
На мой взгляд его бедный синтаксис преподносился как одно из преимуществ, утверждалось что это позволит чуть ли не любому новичку в кратчайшие строки влиться в проект, потому как код будет прост и понятен. По этому я и написал что видели.)
Но соглашусь, для меня так же было сразу очевидно что писать бизнес логику на этом языке будет очень напряженно, придется писать много шаблонного кода и как результат в каждом проекте появятся свои абстракции, по факту — костыли.
А ведь GO обещал быть простым и понятным языком.
Оказалось простота рушиться когда устаешь писать одно и тоже, и хочется абстракций помощнее.)
Статья неоднозначная имхо. Не могу стать как на сторону требующих показать свой сторонний проект так и говорящих что программирование — как один из смыслов жизнь не так уж и важно что бы быть хорошим специалистом.
Я например не имею своего проекта, он мне и незачем, но я читаю очень много и обдумываю.
Согласие с мыслью что нужно быть аккуратно с компаниями которые ищу "увлеченных", зачастую это показатель того что нужен пахарь.
Выглядит и звучит так же, как когда чиновники говорят о прорывах которые в других странах появились уже 10 лет назад.)
Что например мешало добавить удобные методы для создания и манипуляции коллекциями раньше, мне не понятно.
В новой версии JVM у вас может что-то работать уже иначе. И вообще непонятно зачем так "загоняться" по поводу микрооптимизаций JVM. Возможно если вы уперлись в производительность и дальше возможный выход только оптимизации такого рода, а я думаю в подавляющей массе проектов подобное не возникнет, нужно посмотреть в сторону других инструментов/языков.
p.s.
В общем спасибо за статью, то что написал не является целью её критики или утверждения что статья не нужна.)
Если есть доступы на изменение данных это уже плохо. У вас какой то парадокс получается.)
Но даже если предположить что все легко восстановимо, то за чем это? К тому же случайные небольшие изменения можно не заметить, и как вы их потом будите отлавливать и фиксить не понятно, а они будут втихую портить кому-то жизнь ухудшая качестве продукта.
Ну и ещё один, опытные сотрудники должны проводить ревью каждой задачи.
Ну и ещё один, в любой непонятной ситуации с бизнес логикой, спроси тех кто уже давно работает, все ли я понимаю правильно.
Хотя судя по тому что проброской эксепшенов отлавливают такие бизнес кейсы и не делают ревью и эти советы могут и не помоч.
Не думаю что это причина кого-то повышать, не вижу здесь заслуг junior'а, если бы он нашел и указал на это а не все выяснилось в результате ошибки, можно говорить о вознаграждении.
А вот разобраться почему доступ к проду не был защищен и более того креды попали в описание дев настройки нужно. Ну и соответственно потом делать выводы. Возможно это реально случайны косяк, хоть и серьезный, а возможно система.
Что вы имеете ввиду? Насколько мне известно любой Java код можно вызвать из Scala, наоборот нет и это очевидно.) Scala более богатый на возможности язык чем Java.
Ещё была Scala.)