Comments 43
Читал на днях в оригинале, понравился список «будет ли Scala простой для адаптации в вашей организации». И да, теперь я слежу в Твиттере за Dean Wampler’ом =)
Сплошное нытье, смешанное с обидой непонятно на что. В скале куча инструментов, которые не обязательно использовать одновременно. Очень странно слышать такое от человека с пятилетним стажем, который сам может приложить руку к улучшению языка/документации/IDE, и не один, а с командой.
Он как бы и не ноет. Наоборот говорит, что скала хороша. Но вот большинство команд имеют средний уровень и потому выбор скалы для них может привести не более чем к необоснованным разочарованиям.
Он не говорит о сложности языка, а говорит о сложности восприятия для определенных личностей. И зачастую это непонимание связано больше с нежеланием, чем со способностями.
Он не говорит о сложности языка, а говорит о сложности восприятия для определенных личностей. И зачастую это непонимание связано больше с нежеланием, чем со способностями.
Неверно. Критика вполне конструктивна, и основывается на том, что читать код Scala нормально может только программист-эксперт.
Да не критикует он читабельность кода. В силу специфики и мощи языка, сложность эта неизбежна. Тем более, что бОльшая сложность возникает в большей степени при реализации библиотечных функций, о чем и говорит на примере метода flatMap. Он всем доволен — и Scala, и собой.
Критику же я разглядел только в упоминании про IDE, но там же он и поясняет, что очень сложно создать средство разработки для подобного языка.
Критику же я разглядел только в упоминании про IDE, но там же он и поясняет, что очень сложно создать средство разработки для подобного языка.
«Им необходим четкий, типобезопасный, высокопроизводительные язык и среда.» — чОткий язык это как раз то, что нужно твиттеру :)
Ладно, немного эмоционально получилось, добавлю конструктива:
1. Не надо переводить идиомы дословно. Лучше выкинуть кусок, чем оставлять заведомо непонятный никому оборот.
2. Не надо переводить слова по словарю не поискав их в гугле и не проверив что такая семантика и контекст имеют место хотя бы в нескольких других документах.
3. Ну давайте тексты на вычитку другим людям. Ну если уже совсем никак и друзей владеющих техническим языком нет, то хотя бы паре авторов из этого блога можно написать с просьбой сделать ревью — хоть один да согласиться.
1. Не надо переводить идиомы дословно. Лучше выкинуть кусок, чем оставлять заведомо непонятный никому оборот.
2. Не надо переводить слова по словарю не поискав их в гугле и не проверив что такая семантика и контекст имеют место хотя бы в нескольких других документах.
3. Ну давайте тексты на вычитку другим людям. Ну если уже совсем никак и друзей владеющих техническим языком нет, то хотя бы паре авторов из этого блога можно написать с просьбой сделать ревью — хоть один да согласиться.
После прочтения статьи стало интересно, что же это за книги написанные автором и насколько они востребованы…
Удалось найти только одну и с достаточно негативными отзывами на Amazon.com; почему-то не удивило.
Удалось найти только одну и с достаточно негативными отзывами на Amazon.com; почему-то не удивило.
Это автор Лифта, кстати. В сообществе Скалы это на сегодняшний день один из самых известных проектов.
В таком случае извиняюсь за пренебрежительный тон.
Тем не менее, всё же кажется несколько странным использование множественного числа в отношении написанных книг.
Тем не менее, всё же кажется несколько странным использование множественного числа в отношении написанных книг.
есть еще Simply Lift.
Полак человек неоднозначный. С одной стороны он кажется один из наиболее продуктивных разработчиков в мире. С другой стороны его взгляды и, хм… стиль программирования скажем так спорны.
Не стоит все отзывы на его работы принимать за абсолютную истину. Но и его идеи стоит примерять на себя с осторожностью.
Не стоит все отзывы на его работы принимать за абсолютную истину. Но и его идеи стоит примерять на себя с осторожностью.
Полагаю, что речь идёт о «high cohesion».
Достижимо что угодно и где угодно, вопрос в сложности и стабильности этих достижений.
Ну вот пара первых приходящих в голову особенностей Scala в сравнении в Java:
1. Удобство создания неизменяемых структур данных и их обилие в стандартных библиотеках.
2. Удобство создания чистых функций.
3. Удобство создания маленьких и простых классов и функций.
4. Возможность ухода от использования null и исключений (Option и Either).
5. Более простое делегирование операций благодаря наличию замыканий.
6. Поддержка множественного наследования не только интерфейса но и поведения (trait).
7. Возможность более точной спецификации сигнатур функций благодаря развитой системе типов.
Ну вот пара первых приходящих в голову особенностей Scala в сравнении в Java:
1. Удобство создания неизменяемых структур данных и их обилие в стандартных библиотеках.
2. Удобство создания чистых функций.
3. Удобство создания маленьких и простых классов и функций.
4. Возможность ухода от использования null и исключений (Option и Either).
5. Более простое делегирование операций благодаря наличию замыканий.
6. Поддержка множественного наследования не только интерфейса но и поведения (trait).
7. Возможность более точной спецификации сигнатур функций благодаря развитой системе типов.
Полагаю, что речь идёт о «high cohesion».
В котором «средний программист» не будет _более_ продуктивным. Т.е. плюсов переходить нет.
Аргументы за «Scala сложна» таковы:
— Заобеденные дискуссии содержат в себе критерии для перехода от обычного разработчика к старшему
— Ваши разработчики приходят на работу в 9.15 и уходят до 6ти, не проверяя свой email
Мне кажется, что в таких условиях проекту недолго осталось и без Scala.
— Заобеденные дискуссии содержат в себе критерии для перехода от обычного разработчика к старшему
— Ваши разработчики приходят на работу в 9.15 и уходят до 6ти, не проверяя свой email
Мне кажется, что в таких условиях проекту недолго осталось и без Scala.
Кстати, если кому интересно что за Вирджиния в заголовке.
Я думаю, более стилистически точный перевод на русский звучал бы… "Удивительное рядом — Scala сложна!" или вообще, Внезапно.
Я думаю, более стилистически точный перевод на русский звучал бы… "Удивительное рядом — Scala сложна!" или вообще, Внезапно.
Возможно это мое imho, но основную проблему Scala я вижу в излишней математичности. Язык кажется сложным, потому что он пестрит математическими выражениями. Практически каждый элемент требует знаний и навыков теоретико-множественного исчисления, тогда как программисты больше склонны к алгоритмическому мышлению и далеко не все имеют математическое образование. А основные понятия языка и методы определены в его API, поэтому учить Scala — это не только учить язык, но и все, что идет под scala._. В итоге язык становится оторванным от реальности и представляющим исключительно академический интерес теоретикам программирования, использующим его как площадку для своих паттернов.
Проблема резко усугубляется перегрузкой операторов. Разработчики языка не могут жить спокойно, чтобы лишний раз не наполнить какую-нибудь закорючку сакральным смыслом, вместо того, чтобы написать имя метода на христианском английском. Тем же самым грешат писатели библиотек. В итоге смысл кода становится абсолютно не ясным, если перед глазами нет соответствующего ScalaDoc. Апогей подобного маразма — это тот самый знаменитый Lift.
Синтаксический полиморфизм языка приводит к тому, что целью становится краткость написания взамен понятности.
Еще одна особенность — это повсеместное использование DSL в библиотеках. Хорошо это или плохо — тема отдельного разговора.
Если сравнивать Scala с Groovy, то последний, обладая схожими возможностями, при этом являясь динамическим, т.е. «недоязыком», покрывает Scala в удобстве использования, потому как более-менее пытается следовать Java-way. Сравните, например, внешне скрипт на Gradle и на т.н. «Simple Build Tool»… ;)))
Проблема резко усугубляется перегрузкой операторов. Разработчики языка не могут жить спокойно, чтобы лишний раз не наполнить какую-нибудь закорючку сакральным смыслом, вместо того, чтобы написать имя метода на христианском английском. Тем же самым грешат писатели библиотек. В итоге смысл кода становится абсолютно не ясным, если перед глазами нет соответствующего ScalaDoc. Апогей подобного маразма — это тот самый знаменитый Lift.
Синтаксический полиморфизм языка приводит к тому, что целью становится краткость написания взамен понятности.
Еще одна особенность — это повсеместное использование DSL в библиотеках. Хорошо это или плохо — тема отдельного разговора.
Если сравнивать Scala с Groovy, то последний, обладая схожими возможностями, при этом являясь динамическим, т.е. «недоязыком», покрывает Scala в удобстве использования, потому как более-менее пытается следовать Java-way. Сравните, например, внешне скрипт на Gradle и на т.н. «Simple Build Tool»… ;)))
Грэдл это пипец на марше. Во-первых время запуска, на прокте из 6 модулей в сумме секунд 40. Мавен xthtp 'nj время уже зипует архивы, если проект на джаве. Во-вторых мания авторов делать из всего DSL и рассказывать в документации про этот DSL, а не про стоящую за ним модель. Как результат простейшее действие для своего выполнения требует залезания в исходники самого грэдла или вопроса в рассылку (благодаря чему по потоку сообщений она ещё зимой делала scala-user).
Извините, накипело.
Извините, накипело.
По теме комента: а можно пример элемента _требующего_ знаний теории множеств.
Чем лучше имя на христианском набора символов? Если не понимаешь что оно делает — непонятно в любом случае. Если понимаешь — всё ок. Единственна реальная проблема — это именование таких операторов в устной речи. Но если не увлекаться и граничиваться операторами вроде << или ++ — проблем вообще не видно.
Чем лучше имя на христианском набора символов? Если не понимаешь что оно делает — непонятно в любом случае. Если понимаешь — всё ок. Единственна реальная проблема — это именование таких операторов в устной речи. Но если не увлекаться и граничиваться операторами вроде << или ++ — проблем вообще не видно.
Очень интересный пост, спасибо за перевод.
Это ведь необычно, когда адепт языка/технологии открыто говорит о его минусах.
Это ведь необычно, когда адепт языка/технологии открыто говорит о его минусах.
Очень многие жалуются на сложный код Lift, и выбирают Play второй веб фремворк по удобству для Scala и не нативный для Scala. Так что вполне вероятно что сложность языка(его внутрених библиотек) умноженная на сложность библиотеки(аля lift) — очень сложное нечто. Сам я достаточно просто пишу средние проекты на Scala, но переиспользовать чужие библиотеки не решаюсь.
Одна возможность создавать почти нативный DSL говорит о том что язык выучить невозможно т.к. это бесконечное число языков…
Что тут можно сказать. Scala нужно знать, писать на ней, и внедрять )
Одна возможность создавать почти нативный DSL говорит о том что язык выучить невозможно т.к. это бесконечное число языков…
Что тут можно сказать. Scala нужно знать, писать на ней, и внедрять )
Изучаю Scala в данный момент. Многое непривычно и приходится менять стереотипы сложившиеся при кодинге на Java. Scala может показаться сложнее просто потому, что там больше возможностей. Я уверен, сложность освоения окупится скоростью разработки.
От Java я пришел к Scala через Groovy и Python. Некоторые функциональные особенности языка были уже знакомы, но, безусловно было огромное количество всего нового. Полность. с Вами согласен: после определенного момента скорость разработки непременно повысится — кода получается гораааздо меньше. Очень доволен переходом на Lift.
Sign up to leave a comment.
Да, Вирджиния, Scala сложна!