Comments 97
Я помню прекрасный разговор в Киеве, который состоялся у меня с местными ****-овцами три года назад. Дискуссия шла вокруг языков для JVM, и барышня сказала, что вот, мол, у них открыты первые вакансии на Scala. Я спросил у нее подробностей и выяснил, что
После этого скеписиса к скале у меня прибавилось. И, к слову сказать, за эти три года вроде как Scala не стала сильно популярнее.
Ну а про то, что Scala-программиста днем с огнем не найти, в отличие от приличных джавистов, я и говорить не буду. Вон, как Тинькофф мучаются.
- в одном из проектов — это не прод, а тесты
- в другом — это эксперимент
- в третьем скалы вообще нет, а в вакансии — это просто замануха, чтобы умных ребят заманить (мол, знает скалу, значит умный и надо его брать)
После этого скеписиса к скале у меня прибавилось. И, к слову сказать, за эти три года вроде как Scala не стала сильно популярнее.
Ну а про то, что Scala-программиста днем с огнем не найти, в отличие от приличных джавистов, я и говорить не буду. Вон, как Тинькофф мучаются.
Мне кажется правильной реакцией было бы если бы у вас скепсиса к той самой барышне прибавилось. Scala тут не виновата.
Мучается он… Был я когда-то у них (люксофт питерский, но отдел полностью под Тинькофф) на собеседовании: запомнилось ощущение абсолютной неадекватности интервьюверов. Вместо собеседования по scala — tricky questions по темам, в которых сами плавают. Они так долго искать будут людей если не организуют процесс собеседования кандидатов.
Еще вариант — переименовать в hascalator.
"Я нахожу меня порванным между очевидными преимуществами" — это точно вручную переводилось?
Не Java разработчикам (или которые только иногда на нём пишут) всё это кажется странным...
ЗА: Если компания использует Scala, можно быть уверенным в их серьезном подходе к разработке
Работал в двух фирмах, которые используют Скалу и ещё в одной на ней пишет супруга. Пока это предположение не подтвердилось.
Работал в двух фирмах, которые используют Скалу и ещё в одной на ней пишет супруга. Пока это предположение не подтвердилось.
ЗА: Если компания использует Scala, можно быть уверенным в их серьезном подходе к разработке
Это утверждение и следующий за ней абзац откровенно повеселили. Я так познакомился с Erlang'ом, просто потому, что архитектору был выдан карт-бланш и очень хотелось попробовать Erlang, а тут такая возможность. Медленно переписываем теперь. Со Scala забавные ситуации, когда вместо того, чтобы взять Спринг или Джангу для того, чтобы по-быстрому написать несложный рест-сервис, разработчики воротят нос и два месяца втыкают в сликовские транзакции и пишут тот код, который для Джавы уже есть готовый. К сожалению, я отмечаю то, что людям важнее писать на Скале, чем выпустить продукт.
Хотя я согласен, что Скала может пробивать лед для тех языков, которые придут за ней и будут более удобны в работе, особенно для среднего уровня программиста.
> Со Scala забавные ситуации, когда вместо того, чтобы взять Спринг или Джангу для того, чтобы по-быстрому написать несложный рест-сервис, разработчики воротят нос и два месяца втыкают в сликовские транзакции…
Такие высказывания веселят не меньше. Какая разница, втыкать 2 месяца в джангу или в слик?
Мне вот писать рест сервис на Akka сейчас будет быстрее чем на Спринге или тем более на джанге, например)
Такие высказывания веселят не меньше. Какая разница, втыкать 2 месяца в джангу или в слик?
Мне вот писать рест сервис на Akka сейчас будет быстрее чем на Спринге или тем более на джанге, например)
Такие высказывания веселят не меньше. Какая разница, втыкать 2 месяца в джангу или в слик?Лично знаком с приведённой ситуацией. И ваш довод никак не противоречит. Разработчики знали и спринг, и джангу, но очень желали сделать с помощью скалы и слика.
И причем тут скала как таковая? Это же разработчики хотели?
А кто им разрешил? Тот, кому тоже не очень важно то продукт выпускать?
А кто им разрешил? Тот, кому тоже не очень важно то продукт выпускать?
Может быть, разработчики, зная Джангу и Спринг, настолько их ненавидели, что хотели попробовать что-то другое?
… ненавидели...Очень профессионально :)
То есть вы утверждаете, что разработчик обязан относиться с пиететом и уважением к любой освоенной им технологии?
Напротив, именно разобравшись в чем-то достаточно глубоко, вы обретаете моральное право на личное отношение.
Я, например, лично знаю человека, который очень глубоко знает C++.- вплоть до понимания различий между разными версиями gcc и различий в имплементации шаблонов в нем, clang и msvc++.
Так вот, этот товарищ мрачнеет, когда ему приходится заниматься разработкой/поддержкой кода на C++. Он предпочитает Java, Objective C… А «кресты» именно не любит. И причины своей неприязни легко может изложить, пересказав пару «очаровательных» историй, в которые влипал из-за неудобства их синтаксиса и компиляции.
А что — профессионалы обязаны любить любой инструмент?
Напротив, именно разобравшись в чем-то достаточно глубоко, вы обретаете моральное право на личное отношение.
Я, например, лично знаю человека, который очень глубоко знает C++.- вплоть до понимания различий между разными версиями gcc и различий в имплементации шаблонов в нем, clang и msvc++.
Так вот, этот товарищ мрачнеет, когда ему приходится заниматься разработкой/поддержкой кода на C++. Он предпочитает Java, Objective C… А «кресты» именно не любит. И причины своей неприязни легко может изложить, пересказав пару «очаровательных» историй, в которые влипал из-за неудобства их синтаксиса и компиляции.
А что — профессионалы обязаны любить любой инструмент?
Профессионалы должны выбирать инструмент по задаче, а не пользоваться критериями из разряда вкусовщины. Нет ничего профессионального в том, чтобы потратить дополнительные деньги заказчика на новую технологию, которая не дает заказчику и его бизнесу никаких преимуществ. Это я вам конкретно по этому случаю говорю – никаких преимуществ Скала не принесла, но напротив – увеличила стоимость поддержки.
Дает преимущества, если на самом деле технология хреновая, а учат они хорошую.
«Вкусовщина» профессионала всегда имеет под собой основания. Когда вам опытный человек говорит «X — дрянь», он имеет в виду отнюдь не то, что при изучении X от него ушла подружка, а то, что в X присутствует плохой код, неудобный API, много ошибок или еще что-то, что делает X плохим.
Я выше уже написал, что фраза «я ненавижу C++» может означать, например, что для того, чтобы собрать программу из двух частей, собранных разными компиляторами и использующих шаблоны, нужно убить кучу сил и времени. Как вариант.
Я не понимаю, почему эмоциональная оценка не может быть результатом рациональных убеждений. Мы, вроде, люди, так?
«Вкусовщина» профессионала всегда имеет под собой основания. Когда вам опытный человек говорит «X — дрянь», он имеет в виду отнюдь не то, что при изучении X от него ушла подружка, а то, что в X присутствует плохой код, неудобный API, много ошибок или еще что-то, что делает X плохим.
Я выше уже написал, что фраза «я ненавижу C++» может означать, например, что для того, чтобы собрать программу из двух частей, собранных разными компиляторами и использующих шаблоны, нужно убить кучу сил и времени. Как вариант.
Я не понимаю, почему эмоциональная оценка не может быть результатом рациональных убеждений. Мы, вроде, люди, так?
Дает преимущества, если на самом деле технология хреновая, а учат они хорошую.
Как определяется степень хорошести? Джанго — плохая технология, потому что в ней плохой код, неудобный АПИ и много ошибок? А Play хороший потому, что в нем хороший код, кдобный АПИ и нет ошибок? Я правильно понял ваш подход?
Нет хреновых технологий, есть те, которые лучше подходят для задачи и есть те, которые хуже.
Проблема только в одном сейчас.
Процентов наверно 70, если не больше, проектов сейчас пишутся с одинаковой степенью эффективности (для заказчика) на практически любом популярном языке. Под эффективностью я тут понимаю решение бизнесзадач заказчика.
Т.е. условный бизнеспроект можно без серьезных преимуществ со стороны этих технологий написать на: PHP, Go, Python, Java, Scala, Clojure, С# и что там я еще забыл.
Такие важные составляющие решения как: скорость разработки, надежность, достаточная производительность. Будут определяться на 99% людьми участвующими в проекте.
И вот тут проявляется интересный факт. Различность технологий позволяет разным людям, с разными (но работающими естественно) решениями работать вместе эффективно.
Разность этих технологий позволяет людям объединяться по интересам и работать вместе не перегрызая друг другу горло) И это хорошо.
Бизнесу надо сделать правильно ровно одну вещь. Это нанять хорошего техдира, который сможет не мешать группе людей, на удобной им технологии сделать хорошо бизнесу. Ему надо только сдерживать совсем уж безудержные порывы разработчиков. Ну чтобы они начали проект на коболе в 2016 году, или на брейнфаке ))
Процентов наверно 70, если не больше, проектов сейчас пишутся с одинаковой степенью эффективности (для заказчика) на практически любом популярном языке. Под эффективностью я тут понимаю решение бизнесзадач заказчика.
Т.е. условный бизнеспроект можно без серьезных преимуществ со стороны этих технологий написать на: PHP, Go, Python, Java, Scala, Clojure, С# и что там я еще забыл.
Такие важные составляющие решения как: скорость разработки, надежность, достаточная производительность. Будут определяться на 99% людьми участвующими в проекте.
И вот тут проявляется интересный факт. Различность технологий позволяет разным людям, с разными (но работающими естественно) решениями работать вместе эффективно.
Разность этих технологий позволяет людям объединяться по интересам и работать вместе не перегрызая друг другу горло) И это хорошо.
Бизнесу надо сделать правильно ровно одну вещь. Это нанять хорошего техдира, который сможет не мешать группе людей, на удобной им технологии сделать хорошо бизнесу. Ему надо только сдерживать совсем уж безудержные порывы разработчиков. Ну чтобы они начали проект на коболе в 2016 году, или на брейнфаке ))
Не знаю насчет процентов, может для веб-разработки в большинстве случаев и не важно на чем писать, но кроме скорости самой разработки, есть еще и стоимость поддержки и внесения изменений. Я смотрю на это изнутри продуктовой компании, для нас это важно. И вот в случае не нагруженного рест-сервиса, о котором я писал выше, стоимость владения кодовой базой на Скале гораздо выше, чем на питоне, хоты бы потому, что скалисты стоят дороже. Хотя, есть другие части системы, где эта же самая Скала подходит отлично и вообще best-fit.
Я, на всякий случай, уточню, что я не про конкретную технологию говорю, тем более, что конкретно Джанго не знаю вовсе.
Я говорю об оценке в целом.
Специалист взял в руку инструмент, поработал им день и на вопрос, «насколько хорош этот инструмент», выругался матом.
Это была эмоциональная оценка.
Вместо нее он мог бы выдать список, в котором было бы две запоротые детали, вывернутое запястие, отдавленная нога и стружка, попавшая в глаз из-за кривой защиты резца.
Но специалист просто вам ответил «эта вещь мне не нравится». А потом, как в анекдоте, грязно выругался.
Вам кажется, что он непрофессионален? Или профессионал не имеет права на точку зрения относительно инструмента?
Рискну предположить, что, возможно, лично вы хорошо знаете этот фреймворк, любите и недоумеваете, почему кто-то другой может его не любить. Спешу вас заверить, что даже если есть объективные критерии любить или не любить инструмент, у всех они разные (значимость разная). И вовсе необязательно все крутые спецы обязаны любить что-то одно, а кто не любит — «вон из профессии».
Я говорю об оценке в целом.
Специалист взял в руку инструмент, поработал им день и на вопрос, «насколько хорош этот инструмент», выругался матом.
Это была эмоциональная оценка.
Вместо нее он мог бы выдать список, в котором было бы две запоротые детали, вывернутое запястие, отдавленная нога и стружка, попавшая в глаз из-за кривой защиты резца.
Но специалист просто вам ответил «эта вещь мне не нравится». А потом, как в анекдоте, грязно выругался.
Вам кажется, что он непрофессионален? Или профессионал не имеет права на точку зрения относительно инструмента?
Рискну предположить, что, возможно, лично вы хорошо знаете этот фреймворк, любите и недоумеваете, почему кто-то другой может его не любить. Спешу вас заверить, что даже если есть объективные критерии любить или не любить инструмент, у всех они разные (значимость разная). И вовсе необязательно все крутые спецы обязаны любить что-то одно, а кто не любит — «вон из профессии».
«Специалист взял в руки микроскоп и попытался им целый день забивать гвозди, и на вопрос, «насколько хорош этот инструмент», выругался матом. Это была эмоциональная оценка.» Думаю, моя мысль понятна.
«Оценка в целом» это такое размытое понятие, что я бы не стал им оперировать. Если, например, задача относится к сфере высокочастотного трейдинга, то наверняка в первую очередь подумают о С++ и Java, как бы к ним не относились. Но это лучшие инструменты для решения задачи построения приложения подобного рода и выбирать надо их, несмотря на эмоциональную оценку, любовь и личную привязанность.
Если надо нарисовать простенькую интернет-витрину для магазина шапок, то более подходящими будут какие-то CMS на PHP или Рельсы или еще что-то подобное. И если для решения задачи подобного рода выбирается С++, то тут у меня возникают вопросы. И дело не в том, что на плюсах нельзя написать такое, дело в том, что это не подходящий инструмент, который удорожает разработку и поддержку. Именно об этом я и писал, но не в такой утрированной форме.
А технологий без недостатков нет и я не знаю ничего, к чему не было бы претензий. Если технология живет и занимает нишу, то это означает ровно то, что лучшего инструмента по заданному набору критериев просто нет (не рассматривая граничные случаи типа Кобола в фин.сфере, конечно же).
Ну и да, если вместо внятных аргументов я слышу «фу-фу-фу, я не буду на этом говне писать», то я отношу это как раз к непрофессионализму. Мое личное мнение.
Я не пользуюсь вашей системой ценностей, основанной на эмоциональной привязанности, это для меня не имеет никакого значения.
«Оценка в целом» это такое размытое понятие, что я бы не стал им оперировать. Если, например, задача относится к сфере высокочастотного трейдинга, то наверняка в первую очередь подумают о С++ и Java, как бы к ним не относились. Но это лучшие инструменты для решения задачи построения приложения подобного рода и выбирать надо их, несмотря на эмоциональную оценку, любовь и личную привязанность.
Если надо нарисовать простенькую интернет-витрину для магазина шапок, то более подходящими будут какие-то CMS на PHP или Рельсы или еще что-то подобное. И если для решения задачи подобного рода выбирается С++, то тут у меня возникают вопросы. И дело не в том, что на плюсах нельзя написать такое, дело в том, что это не подходящий инструмент, который удорожает разработку и поддержку. Именно об этом я и писал, но не в такой утрированной форме.
А технологий без недостатков нет и я не знаю ничего, к чему не было бы претензий. Если технология живет и занимает нишу, то это означает ровно то, что лучшего инструмента по заданному набору критериев просто нет (не рассматривая граничные случаи типа Кобола в фин.сфере, конечно же).
Ну и да, если вместо внятных аргументов я слышу «фу-фу-фу, я не буду на этом говне писать», то я отношу это как раз к непрофессионализму. Мое личное мнение.
Рискну предположить, что, возможно, лично вы хорошо знаете этот фреймворк, любите и недоумеваете, почему кто-то другой может его не любить.
Я не пользуюсь вашей системой ценностей, основанной на эмоциональной привязанности, это для меня не имеет никакого значения.
Я вам привел простой пример, вы обобщили его до абсурда. Зачем?
Речь шла о ситуации, когда:
1. Инструмент был использован на основании того, что подходил к поставленной задаче (во всяком случае, предназначался для нее)
2. Инструмент был выбран сознательно
Оценка в целом — действительно размытое понятие, но я говорю о случае, когда вполне конкретный человек решает вполне конкретный класс задач.
Человек оценивает инструмент не «в целом». Он его оценивает в контексте поставленной задачи.
Суммирую:
Если специалист, занимающийся некоторой задачей с помощью некоторого инструмента, говорит, что инструмент — дрянь, он имеет в виду, что инструмент, по его мнению, не подходит для данной задачи.
Напомню, что изначально в дискуссии речь шла о конкретных примерах. Я сказал, что, возможно, специалисты выкинули из рассмотрения некий фреймворк, потому что он им не нравился. Из чего, скажите на милость, вы сделали вывод, что он им не нравился «как сферический в вакууме»? Он им не нравился конкретно — для их целей. Здесь и сейчас.
Речь шла о ситуации, когда:
1. Инструмент был использован на основании того, что подходил к поставленной задаче (во всяком случае, предназначался для нее)
2. Инструмент был выбран сознательно
Оценка в целом — действительно размытое понятие, но я говорю о случае, когда вполне конкретный человек решает вполне конкретный класс задач.
Человек оценивает инструмент не «в целом». Он его оценивает в контексте поставленной задачи.
Суммирую:
Если специалист, занимающийся некоторой задачей с помощью некоторого инструмента, говорит, что инструмент — дрянь, он имеет в виду, что инструмент, по его мнению, не подходит для данной задачи.
Напомню, что изначально в дискуссии речь шла о конкретных примерах. Я сказал, что, возможно, специалисты выкинули из рассмотрения некий фреймворк, потому что он им не нравился. Из чего, скажите на милость, вы сделали вывод, что он им не нравился «как сферический в вакууме»? Он им не нравился конкретно — для их целей. Здесь и сейчас.
Рискну вам напомнить, что пример изначально привел я, я знал о поставленной задаче и я знал о ее сложности. И на этом примере я пытался объяснить свою точку зрения. Это не получилось, и тогда я решил, по вашему выражению, довести ситуацию до абсурда в надежде, что так станет понятнее. И с чего вы решили, что я делаю выводы в вакууме – я не понимаю. Еще раз повторю, чтобы наконец было понятно – в исходной истории все варианты были отвергнуты только потому, что они «не на скале». Какие мне еще пояснения и аргументы надо вам привести?
Может быть, разработчики, зная Джангу и Спринг, настолько их ненавидели, что хотели попробовать что-то другое?
Вряд ли. Просто скучно стало им поди.
Я не писал про 2 месяца на джанге, я писал «по-быстрому на джанге», а это неделя-две. То, что вам лично быстрее на Акке я не оспариваю. Мне больше интересно то, на чем будет быстрее широкому кругу разработчиков.
Широкому кругу быстрее на bottle или flask (питон)
Но что это меняет в контексте данной статьи?
понятно, что использование знакомого инструмента даст результат быстрее и лучше. Вопрос то не в это.
Но что это меняет в контексте данной статьи?
понятно, что использование знакомого инструмента даст результат быстрее и лучше. Вопрос то не в это.
О, а в чем же тогда?
в людях?
цитата из этой статьи
Разработчики из вашего примера со сликом, так и не выпустили ничего работающее?
Может быть, напрасно они сразу за слик схватились?
цитата из этой статьи
Сегодня мы поговорим о том, нужна ли Scala разработчику для саморазвития
Разработчики из вашего примера со сликом, так и не выпустили ничего работающее?
Может быть, напрасно они сразу за слик схватились?
Выпустили, но несколько позже, чем можно было бы. Хотя это скалисты с опытом. Ну и если они, по вашему выражению, напрасно сразу за слик схватились, то как это сочетается с «если выбрали скалу, то это серьезно»?
очень легко сочетается
Пример из нашей жизни, как раз вот один из разработчиков интересовался, сколько проекту лет — 6 лет. от первого коммита. Можно ли сказать, что проект, который компании прибыль — это несерьезно? Вполне серьезно. Никаких проблем из за того, что «скала» мы не испытывали. Да, лет пять назад, были некие сложности с поиском людей, но наша практика показала, что человек который умеет использовать Java, под руководством нашего тимлда, вливается в проект примерно за пару недель. За пару месяцев за ним вообще уже не нужно приглядывать.
Что-то мне подсказывает, что если взять другие инструменты и посмотреть на аналогичные метрики, разницы на порядок точно не будет, и скорее всего не будет отличий даже «в разы».
То есть суть отличий будет
— в сложности проекта как такового
— в людях
Сделал wc -l в src/main/scala — всего 65602 строк. Никакого слика или другого ОРМ у нас нет. В оракл и постгрес ходить умеем, но нужно не часто. Основное хранилище — монга.
Пример из нашей жизни, как раз вот один из разработчиков интересовался, сколько проекту лет — 6 лет. от первого коммита. Можно ли сказать, что проект, который компании прибыль — это несерьезно? Вполне серьезно. Никаких проблем из за того, что «скала» мы не испытывали. Да, лет пять назад, были некие сложности с поиском людей, но наша практика показала, что человек который умеет использовать Java, под руководством нашего тимлда, вливается в проект примерно за пару недель. За пару месяцев за ним вообще уже не нужно приглядывать.
Что-то мне подсказывает, что если взять другие инструменты и посмотреть на аналогичные метрики, разницы на порядок точно не будет, и скорее всего не будет отличий даже «в разы».
То есть суть отличий будет
— в сложности проекта как такового
— в людях
Сделал wc -l в src/main/scala — всего 65602 строк. Никакого слика или другого ОРМ у нас нет. В оракл и постгрес ходить умеем, но нужно не часто. Основное хранилище — монга.
… пробивать лед… для среднего уровня...Это самое грустное. Средний уровень должен расти, а не привыкать десять лет к «новинкам» (из 60-ых) типа анонимных функций.
Скала должна «пробивать лёд» НЕ ДЛЯ котлина, а К хаскелю, агде, идрису…
Во что там втыкать? Джуны за месяц в состоянии освоить слик и akka-http. И scala, впервые ее увидев в начале месяца.
ЗА: Если компания использует Scala, можно быть уверенным в их серьезном подходе к разработке
Вот на этом невысказанном предположении и держится весь хрупкий механизм нашего молодого народовластия.
Используем Скалу в одном из наших под-проектов.
Скажу так, что сколько бы я не пытался начать изучать Java — синтаксис и портянки кода просто убивают всякое желание в этом всём разбираться. За Java 8 ничего не скажу — не пробовал. ИМХО.
Скала в этом плане действительно лаконичнее и проще читается. Но это с одной стороны. С другой стороны, если начать выкручивать Скалу на полную катушку, т.е начать использовать все функциональные возможности: view bounds, higher kinded types, монады, вариативность и ещё бог знает что, то в проекте вы, скорее всего, быстро останетесь одни, потому что этот лес нагромождений мало кто захочет разгребать, чтобы разобраться и понять саму бизнес-логику, которую вы в этом всём закопали. Вот пока не пишешь сложного (овер-функционального) кода на Скале — всё хорошо. Как только осознал, что написал сложно (через месяц сам не сразу понимаешь, как оно работает) — очень хочется какой-нибудь более простой и однозначный язык.
Скажу так, что сколько бы я не пытался начать изучать Java — синтаксис и портянки кода просто убивают всякое желание в этом всём разбираться. За Java 8 ничего не скажу — не пробовал. ИМХО.
Скала в этом плане действительно лаконичнее и проще читается. Но это с одной стороны. С другой стороны, если начать выкручивать Скалу на полную катушку, т.е начать использовать все функциональные возможности: view bounds, higher kinded types, монады, вариативность и ещё бог знает что, то в проекте вы, скорее всего, быстро останетесь одни, потому что этот лес нагромождений мало кто захочет разгребать, чтобы разобраться и понять саму бизнес-логику, которую вы в этом всём закопали. Вот пока не пишешь сложного (овер-функционального) кода на Скале — всё хорошо. Как только осознал, что написал сложно (через месяц сам не сразу понимаешь, как оно работает) — очень хочется какой-нибудь более простой и однозначный язык.
Ситуация дополнительно усугубляется следующим. Синтаксис Java ограничивает разработчика и заставляет его делать вещи Java-way, начиная от code style и заканчивая паттернами. В результате, хороший код на Java везде выглядит примерно одинаково.
Scala, наоборот, развязывает разработчику руки и предоставляет массу альтернатив. Это развивает вкусовщину, религиозные войны в коммьюнити и взаимную нечитаемость и неподдерживаемость кода.
Дедушки помнят девиз одного популярного некогда языка "There’s More Than One Way To Do It". Вспомните, где он теперь? =)
P.S. Несмотря на это, большую часть промышленного кода пишем на Scala.
Scala, наоборот, развязывает разработчику руки и предоставляет массу альтернатив. Это развивает вкусовщину, религиозные войны в коммьюнити и взаимную нечитаемость и неподдерживаемость кода.
Дедушки помнят девиз одного популярного некогда языка "There’s More Than One Way To Do It". Вспомните, где он теперь? =)
P.S. Несмотря на это, большую часть промышленного кода пишем на Scala.
а еще больше порядка в программах на Go, и растет он быстрее
(немного старческого брюзжания)
Молодые люди желают свободы. Везде и всегда. Я в 20 тоже полагал, что чем больше свободы предлагает мне компилятор, тем круче язык.
А потом, в процессе переламывания очередного копья о завитушки собственного очередного «красивого программного решения» начал осознавать, что главное в нашем деле — не супервозможности, а удобство разработки/отладки/поддержки.
Я, например, до сих пор недоумеваю, за что людям так нравится Питон, в котором принято, чуть что, хвататься за рефлексию, а инкапсуляция отсутствует как таковая.
Молодые люди желают свободы. Везде и всегда. Я в 20 тоже полагал, что чем больше свободы предлагает мне компилятор, тем круче язык.
А потом, в процессе переламывания очередного копья о завитушки собственного очередного «красивого программного решения» начал осознавать, что главное в нашем деле — не супервозможности, а удобство разработки/отладки/поддержки.
Я, например, до сих пор недоумеваю, за что людям так нравится Питон, в котором принято, чуть что, хвататься за рефлексию, а инкапсуляция отсутствует как таковая.
Я, например, до сих пор недоумеваю, за что людям так нравится Питон
Скобок нет. Отступы поди им нравятся.
Это отсутствие скобок меня обескуражило первым же делом. Особенно когда я начал задавать себе неудобные вопросы типа:
1. А что будет, если нечаянно ткнуть лишний пробел?
2. А что будет, если в куске кода использовать табуляции, а в другом — скобки?
3. А что будет, если в одной строке сперва отбивать табами, а потом — пробелами? (я так люблю делать, например)
Все эти вопросы не имеют значительного смысла в языках, где операторные скобки видны даже людям с сильным астигматизмом.
1. А что будет, если нечаянно ткнуть лишний пробел?
2. А что будет, если в куске кода использовать табуляции, а в другом — скобки?
3. А что будет, если в одной строке сперва отбивать табами, а потом — пробелами? (я так люблю делать, например)
Все эти вопросы не имеют значительного смысла в языках, где операторные скобки видны даже людям с сильным астигматизмом.
Скобки — это:
— дополнительное пустое место на экране (обычно целая строка);
— лишняя информация (так как отступы обычно есть).
— дополнительное пустое место на экране (обычно целая строка);
— лишняя информация (так как отступы обычно есть).
скобки это не только визуальная отбивка. Например в Java фигурные скобки обеспечивают ещё дополнительную локальную область видимости переменных внутри метода
Во-первых, «пустое» место бывает не всегда, а только если скобки выносить на отдельную строку. Я, например, приучен Джавой писать так:
Давайте найдем в моем коде лишние пустые строки.
А во-вторых, я сам иногда НАМЕРЕННО (представьте себе) отделяю блоки кода пустыми строками друг от друга, чтобы улучшить их читабельность. Мне мало имеющихся фигурных скобочек, я хочу больше пустоты.
Что касается лишней информации, я уже написал (полушутя) про астигматизм. Теперь уточню серьезно.
Умение четко видеть вертикальную границу текста — навык, требующий не только тренировки, но и хорошего глазомера.
При этом скобки помогают четко видеть, где блок кода заканчивается.
Я, кстати, часто в IDE ставлю курсор на открывающуюся скобочку, чтобы увидеть закрывающуюся. Куда прикажете в питоне курсор ставить?
void someFunction(int arg) {
if (something) {
foo();
} else {
anotherFoo();
}
}
Давайте найдем в моем коде лишние пустые строки.
А во-вторых, я сам иногда НАМЕРЕННО (представьте себе) отделяю блоки кода пустыми строками друг от друга, чтобы улучшить их читабельность. Мне мало имеющихся фигурных скобочек, я хочу больше пустоты.
Что касается лишней информации, я уже написал (полушутя) про астигматизм. Теперь уточню серьезно.
Умение четко видеть вертикальную границу текста — навык, требующий не только тренировки, но и хорошего глазомера.
При этом скобки помогают четко видеть, где блок кода заканчивается.
Я, кстати, часто в IDE ставлю курсор на открывающуюся скобочку, чтобы увидеть закрывающуюся. Куда прикажете в питоне курсор ставить?
> Давайте найдем в моем коде лишние пустые строки.
Там, где стоят только скобки, так как конец блока можно указывать отступом.
> А во-вторых, я сам иногда НАМЕРЕННО (представьте себе) отделяю блоки кода пустыми строками друг от друга, чтобы улучшить их читабельность. Мне мало имеющихся фигурных скобочек, я хочу больше пустоты.
Это. конечно, дело вкуса.
> Я, кстати, часто в IDE ставлю курсор на открывающуюся скобочку, чтобы увидеть закрывающуюся. Куда прикажете в питоне курсор ставить?
Ну так это проблемы IDE — при отсутствии скобок можно найти и другие варианты выделения.
Там, где стоят только скобки, так как конец блока можно указывать отступом.
> А во-вторых, я сам иногда НАМЕРЕННО (представьте себе) отделяю блоки кода пустыми строками друг от друга, чтобы улучшить их читабельность. Мне мало имеющихся фигурных скобочек, я хочу больше пустоты.
Это. конечно, дело вкуса.
> Я, кстати, часто в IDE ставлю курсор на открывающуюся скобочку, чтобы увидеть закрывающуюся. Куда прикажете в питоне курсор ставить?
Ну так это проблемы IDE — при отсутствии скобок можно найти и другие варианты выделения.
Субъективно, всех скалистов уже задолбал этот холивар, так что дискуссия/срач вряд ли получится.
По поводу популярности и вакансий — растет, за год существенно прибавилось, хотя заманухи также хватает.
По поводу популярности и вакансий — растет, за год существенно прибавилось, хотя заманухи также хватает.
Scala медленно растет. Медленнее, чем лично мне хотелось бы, например. Потому что Java тоже растет, и растет быстрее. И доля Scala, соответственно, не особо увеличивается.
> Возможно Scala вообще никогда не станет мейнстримом как Java или JS.
Точно, что никогда не станет, так как мейнстриму необходим легкий поиск сотрудников даже в небольшом городке. А это означает низкий порог вхождения и т.д.
Вопрос только в том, займет ли Scala какую-то нишу или лет через 5, когда ФП будет внедрено повсеместно, просто засохнет.
Точно, что никогда не станет, так как мейнстриму необходим легкий поиск сотрудников даже в небольшом городке. А это означает низкий порог вхождения и т.д.
Вопрос только в том, займет ли Scala какую-то нишу или лет через 5, когда ФП будет внедрено повсеместно, просто засохнет.
А что Scala, на Ваш взгляд, должна приобрести? В языке много чего есть, чего нет добавят / поправят в Dotty, которую собираются зарелизить в какой-то форме (доклад Одерски на ScalaWorld) в обозримом будущем, лишнее уберут. Коммьюнити развивается, работы тоже предостаточно, как для убежденных джавистов, так и для тех кто предпочитает функциональный подход. В чем проблема?
> что нового приобрела Scala как язык за последний год?
Быстро можно расти только с нуля. Язык, у которого серьезные новшества появляются каждый год, это очень молодой язык.
Scala к таковым не относится.
Быстро можно расти только с нуля. Язык, у которого серьезные новшества появляются каждый год, это очень молодой язык.
Scala к таковым не относится.
Все-таки в бигдате доминирует питон. Почему-то Scala многих пугает.
Взгляд неофита в Скале:
Мне важно понимать, во что и как компилируется код, когда я его читаю, какие там есть аллокации. В Java это довольно просто, в этом смысле Java на самом деле недалеко ушла от Си (для кого-то это может звучать дико, но в моем видении это так.) То есть Java это такой Си с хорошей IDE, билд тулами, библиотеками и т. д.
Скала — с ее implicits, mixins, хитрыми коллекциями и магическими фреймворками — уже все совсем непонятно. То есть приближается к динамическим языкам, где проще забить на всякую производительность, расслабиться и радоваться сахарку.
Котлин, как мне кажется, еще сохраняет необходимую прозрачность, при том что фактически весь необходимый скаловский сахар там есть. Очень кстати что JetBrains взялись активно проговаривать эту тему, как компилируется Котлин: https://youtu.be/yYG12qaxWO4?list=PLVe-2wcL84b-Waky1nkWVSNHPg6eOQWU9
К сожалению, пока Котлин очень сырой, но буду ковырять на нем pet проекты и следить.
Не все ли равно как Котлин компилируется, если он это делает быстрее скалы?
А так используешь его в продакшене на Андроиде и чувствуш себя белым человеком (+ ценность как девелопера повышается)
А так используешь его в продакшене на Андроиде и чувствуш себя белым человеком (+ ценность как девелопера повышается)
Скала — с ее implicits, mixins, хитрыми коллекциями и магическими фреймворками — уже все совсем непонятно.
Если интересно, во что скомпилировался конкретный код, всегда можно использовать -Xprint: желаемая-фаза-компилятора. А по сравнению со Spring, JPA и т.д. магии в скаловских фреймворках много меньше (ПМСМ).
Блин, честно, работал в Москве, — пол этажа скала программистов… Сейчас работаю в SF, аналогично, — недостатка в scala разработчиках нет. Scala — это другая ветка эволюции. Здесь не надо сгонять 1000 орков-программистов на один проект. Достаточно небольшой, но компетентной команды профессионалов. Спецназ одним словом. И эта тенденция будет только расти. Посмотрите доклады с любой scala конференции. Уровень докладов, в среднем, на порядок глубже и сильнее чем то, что я, опять же, в среднем, видел на любых конференциях по java. Oracle за 10 лет, имея в распоряжении миллиарды долларов и огромный штат инженеров, не смогла добавить в язык многострадальные value types и ahead of time compiler. Как такое вообще возможно??? И я не говорю уже про type erasure в generics и т. п. баги… Сome on guys, вы всё ещё верите, что в java когда-нибудь появятся идеи, описанные здесь? Это просто невозможно с точки зрения её дизайна, да и Oracle в этом не заинтересована. Нет ничего плохого в том, что java рано или поздно уйдёт со сцены, как это было в своё время с COBOL. Ну просто мир движется вперёд, технологии развиваются, появляются новые идеи и концепции. Пора это уже наконец понять, закопать стюардессу и идти дальше!
Достаточно небольшой, но компетентной команды профессионалов. Спецназ одним словом.
Это высказывание намекает нам, что небольшая команда профессиональных скала-разработчиков чем-то отличается от такой же команды разработчиков java. И как «спецназ» может сделать какую-то задачу особенно хорошо или быстро (не знаю, что здесь имеется ввиду). Но это умозаключение не только ничем не подтверждено, но и вполне вероятно может оказаться просто ложным.
Уровень докладов, в среднем, на порядок глубже и сильнее чем то, что я, опять же, в среднем, видел на любых конференциях по java.
Возможно, это связано с тем, что язык сложноват и требует квалификацию выше средней?
имея в распоряжении миллиарды долларов и огромный штат инженеров, не смогла добавить в язык многострадальные value types и ahead of time compiler. Как такое вообще возможно???
Зато от версии к версии они почти абсолютную совместимость сохраняют, что видимо для бизнеса приоритетнее, чем новые фичи языка, которые (к слову) медленно но в языке появляются.
Нет ничего плохого в том, что java рано или поздно уйдёт со сцены
Вероятно уйдет, да, но скала этого скорее всего не увидит. Думаю, на опыте скалы будут появляться новые языки, которые будут более подходить более широкой аудитории и решать те же задачи.
> Возможно, это связано с тем, что язык сложноват и требует квалификацию выше средней?
Квалификация требуется на уровне первого курса любого технического универа + умение читать. Но сейчас вроде везде так…
Да, действительно, есть некоторые баги компилятора scala, при попытке «обойти» которые рождается не самый простой код. Это правда. Но такой код, как правило, сосредоточен в библиотеках + в той же грядущей Scala 2.12 уже многое пофикшено. В целом, я бы назвал это болезнями роста.
> Зато от версии к версии они почти абсолютную совместимость сохраняют, что видимо для бизнеса приоритетнее, чем новые фичи языка, которые (к слову) медленно но в языке появляются.
Абсолютная совместимость бывает только на кладбище. Давайте посмотрим на параллельный мир JavaScript / Frontend Side. Да там в месяц 20 новых фреймворков появляется :-), а совместимость ломается каждые пару лет (см ng1 vs ng2) и почему-то бизнес это не сильно парит…
Квалификация требуется на уровне первого курса любого технического универа + умение читать. Но сейчас вроде везде так…
Да, действительно, есть некоторые баги компилятора scala, при попытке «обойти» которые рождается не самый простой код. Это правда. Но такой код, как правило, сосредоточен в библиотеках + в той же грядущей Scala 2.12 уже многое пофикшено. В целом, я бы назвал это болезнями роста.
> Зато от версии к версии они почти абсолютную совместимость сохраняют, что видимо для бизнеса приоритетнее, чем новые фичи языка, которые (к слову) медленно но в языке появляются.
Абсолютная совместимость бывает только на кладбище. Давайте посмотрим на параллельный мир JavaScript / Frontend Side. Да там в месяц 20 новых фреймворков появляется :-), а совместимость ломается каждые пару лет (см ng1 vs ng2) и почему-то бизнес это не сильно парит…
> Квалификация требуется на уровне первого курса любого технического универа + умение читать
Скажите название того вуза, где на первом курсе проходят функциональное программирование со всеми этими вашими функторами и монадами, модель акторов и разные радости ООП в полном объеме.
>… почему-то бизнес это не сильно парит
Вы видели хоть одну банковскую систему полностью на JavaScript?
Скажите название того вуза, где на первом курсе проходят функциональное программирование со всеми этими вашими функторами и монадами, модель акторов и разные радости ООП в полном объеме.
>… почему-то бизнес это не сильно парит
Вы видели хоть одну банковскую систему полностью на JavaScript?
Нет. Но бухгалтерских на 1C полно. ;-)
Вообще-то можно, наверное, написать и банковский опер-день на JavaScript. Писали же раньше на Clipper.
Но нужно ли, если есть Java? — По крайней мере на сервере.
Вообще-то можно, наверное, написать и банковский опер-день на JavaScript. Писали же раньше на Clipper.
Но нужно ли, если есть Java? — По крайней мере на сервере.
Вот что касается функторов и монад — сначала ими активно пользуются, а уже потом какой-нибудь гуру объясняет, что это функторы и монады.
Квалификация требуется на уровне первого курса любого технического универа + умение читать.
Я согласился бы с вами, если бы вы написали, что для того, чтобы писать на скала как на джаве (т.е. без особых изощрений) достаточно средней квалификации. Но, боюсь, уровня первого курса а тем более любого технического универа сейчас недостаточно, чтобы писать почти ни на каком языке.
да, действительно, есть некоторые баги компилятора scala
про баги и болезнь роста — это ответ на какой вопрос?
Давайте посмотрим на параллельный мир JavaScript
вы уж меня простите, но причем тут JavaScript? От безысходности чтоли? Кстати, в JavaScript-е обратную совместимость блюдут достаточно строго — в современной реализации до сих пор можно найти интересные «особенности» ранних версий.
20 новых фреймворков появляется
хорошо, про языки поговорили, давайте теперь за фреймворки возьмемся — ок.
почему-то бизнес это не сильно парит
во-первых, откуда такая уверенность, что бизнес это не парит? во-вторых, напомню, мы говорим не о javascript-овых фреймворках, а потере скалой совместимости между версиями, вы считаете это ок?
Но это умозаключение не только ничем не подтверждено, но и вполне вероятно может оказаться просто ложным.
Только в следующем абзаце вы его как раз и подтверждаете:
Возможно, это связано с тем, что язык сложноват и требует квалификацию выше средней?
Да, именно более высокой квалификацией небольшая команда разработчиков на Scala будет отличаться от аналогичной команды разработчиков на Java (в среднем, конечно).
Вероятно уйдет, да, но скала этого скорее всего не увидит.
Вероятно, нет (по крайней мере в обозримом будущем).
Только в следующем абзаце вы его как раз и подтверждаете
То, что язык требует более высокой квалификации для входа совершенно не означает, что он позволяет сделать какую-то задачу особенно хорошо или быстро (я так и не понял, что именно тут имелось ввиду).
Да, именно более высокой квалификацией небольшая команда разработчиков на Scala будет отличаться от аналогичной команды разработчиков на Java
Тут получается вот что: требования к квалификации выше, но очевидного профита от этого не видно — ведь единственная очевидно повешенная квалификация скалиста — это опыт борьбы с самим языком — о других навыках этих людей мы наверняка не знаем — что вероятно в какой-то степени влияет на результаты его деятельности, но умение решать задачи от этого навыка серьезно не зависят. По крайней мере никакими доказательствами обратного я не владею.
Все недоразумения из-за того, что Scala — фактически три разных языка
- Сильно улучшенная джава (за это все так любят скалу)
- Функциональный язык (применять аккуратно)
- Академический/экспериментальный язык (хороший способ писать совершенно нечитабельный код)
Сильно улучшенная джава (за это все так любят скалу)
Это замануха для привлечения Java программистов. :-)
Функциональный язык (применять аккуратно)
Это мода на функциональщину. :-)
Академический/экспериментальный язык (хороший способ писать совершенно нечитабельный код)
А вот это суть Scala и есть. ;-)
Scala в первую очередь это промышленный язык, сложно его назвать академическим. Крупнейшие европейские компании используют его в продакшене.
Кому что. Никто же не заставляет прикручивать scalaz и активно использовать имплиситы в промышленном проекте, не так ли? Scala в этом отношении немного похожа на C++ — нужно знать, какими фичами языка можно пользоваться, а какими — не стоит.
А что такого в Kotlin функционального? Pattern matching есть? С типом Option как с монадой он работает? Может еще и функция значение последнего выражения возвращает бeз необходимости писать return?
- функции вне классов
- лямбды
- функции высших порядков
- замыкания (с возможностью модификации)
- хвостовая рекурсия
- библиотека https://github.com/MarioAriasC/funKTionale которая использует возможности языка, позволяет делать:
Function composition, Currying, Partial Application, Option, Either/Disjunction, Memoization
Этим сейчас редкий язык не модет похвастаться. Ну кроме TCO, но она конфликтует с моделью безопасности jvm, так что я не уверен, что Kotlin ее везде поддерживает.
В функциональной парадигме главное — поощрение иммутабельности и испрользованию возвращаемого значения из функций. Этого я в Kotlin не вижу.
В функциональной парадигме главное — поощрение иммутабельности и испрользованию возвращаемого значения из функций. Этого я в Kotlin не вижу.
В функциональной парадигме главное — поощрение иммутабельности и испрользованию возвращаемого значения из функций. Этого я в Kotlin не вижу.
Это как раз в Kotlin есть
Ну а как же val (знаю что это readonly, но все таки) и primary-consturctors.
Очень легко создавать неизменяемые класс
data class User(val name:String, val birthday: Date)
val me = User("lani", Date(17, 2, 3))Это, конечно, шаг в сторону ФП.
То почему бы в классе не сделать val по умолчанию, а var требовать явно, как это сделано в Scala?
Kotlin тут чуть лучше Java, но до ориентированных на ФП языков, все-таки не дотягивает.
То почему бы в классе не сделать val по умолчанию, а var требовать явно, как это сделано в Scala?
Kotlin тут чуть лучше Java, но до ориентированных на ФП языков, все-таки не дотягивает.
1) Потому что Котлин прагматичный мультипарадигменный язык, а не чисто функциональный.
2) Все равно придется каждый раз выбирать между var и val (а не как в Java все без final изменяемое).
Все равно придется каждый раз выбирать между var и val (а не как в Java все без final изменяемое).
Но ведь Java тоже всерьез рассматривает переход на val/var, судя по недавнему голосованию. Может так получиться, что через n лет, когда котлин станет менее сырым, все его фичи не будут стоить того, чтобы соскакивать с джавы.
Java тоже всерьез рассматривает переход на val/var
Это хорошо, но в JEP-286 говорится только про локальные переменные, да и будет это минимум в 10.
Не говоря уже о том что var/val это такая мелочь в различие языков.
все его фичи не будут стоить того, чтобы соскакивать с джавы.
properties, extension-functions, nullability, readonly collection, first class functions, primary constructors, data class и тд — этого в Java придется ждать очень долго (ведь совместимость для нее важнее).
А уже через полгода после релиза, в Kotlin 1.1 добавили async/await и yeild (в тестовом режиме пока).
Также в JB заявили что они начали разработку компилятора Kotlin->LLVM и возможно в следующем году, можно будет "соскочить" но только уже с JVM.
properties, extension-functions, nullability, readonly collection, first class functions, primary constructors, data class и тд — этого в Java придется ждать очень долго (ведь совместимость для нее важнее).
Если бы вопрос был только в количестве фич, то скала уже давно была бы мейнстримовым мейнстримом. Похоже джава просто ждет, какие из фич новых языков лучше всего выстреливают, перенимает их себе и делает (условно) 95% JVM-программистов вполне удовлетворенными, снимая при этом с их менеджмента огромные риски от перехода на новый язык.
в JB заявили что они начали разработку компилятора Kotlin->LLVM и возможно в следующем году, можно будет «соскочить» но только уже с JVM
Вряд ли, потому что вся огромная Java-экосистема заточена под JVM, а еще один LLVM-язык без экосистемы едва ли кому-то нужен. А вот если джава таки осилит AOT-компиляцию, которую они уже давно обещают, многим уже существующим LLVM-поделушкам может прийти внезапный конец.
А как насчет других структур данных, в Скале их довольно много, а чем может похвастаться Kotlin? Есть ли там immutable списки, туплы и тп?
Вот тут хорошо объясняется https://youtu.be/CX_K1r0Vklg
Вкраце: все коллекции по умолчанию immutable (List, Map), от них уже наслаждаются MuttableList, MuttableSet и тд. (от них уже ArrayList). Плюс если некая магия, для превращения их рантайме в стандартные Java коллекции.
Туплов больше 3 нет (тк они не нужны), вместо них есть data class
Вот неплохая статья по поводу ФП в Kotlin
ЗА: Если компания использует Scala, можно быть уверенным в их серьезном подходе к разработке
Поверьте мне это далеко не так, встречаются компании, это конечно редкость, которые использують скалу, только потому что они модные стратапы. А на самом деле там такой ужас понаписан, который на джаве редко встретишь.
я думаю популярность Scala в сравнении с Clojure объясняется тем, что последний появился чуть позже. При том что Clojure гораздо более приятней, удобней и практичней, к тому же принуждает к определенной «функциональной дисциплине». Не столь насильственно как например Haskell, но и безо всякой разнузданности (как в Scala). Медленно но верно, популярность языка растет.
Sign up to leave a comment.
Scala или не Scala? Вот в чем вопрос