Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 17
Такие записки выглядят для меня примерно так:
«Я долгие годы пользовался плоской отверткой. Но пришло время и я узнал о крестовых… это был прорыв. Но прошло время и я узнал торксах… Все, больше я обычные отвертки не могу использовать..»
Инструмент есть инструмент. Если автор нашел более удобный для своих задач это же хорошо.
Но это ничего не говорит о предыдущих инструментах.
Но вообще забавно, я сам после того как поработал со скалой, стал ковырять кложу.
И есть ощущение, что для сайтов оно хорошо подходит.
Но на сайтах же мир не заканчивается.
Есть области где скала подходит очень хорошо.
«Я долгие годы пользовался плоской отверткой. Но пришло время и я узнал о крестовых… это был прорыв. Но прошло время и я узнал торксах… Все, больше я обычные отвертки не могу использовать..»
Инструмент есть инструмент. Если автор нашел более удобный для своих задач это же хорошо.
Но это ничего не говорит о предыдущих инструментах.
Но вообще забавно, я сам после того как поработал со скалой, стал ковырять кложу.
И есть ощущение, что для сайтов оно хорошо подходит.
Но на сайтах же мир не заканчивается.
Есть области где скала подходит очень хорошо.
Советую прочитать эту статью — Элитные языки программирования.
Благодарю, ознакомился. Только вот все о чем говорит автор применимо и к Scala, я о REPL и т.д.
Ссылка для общего ознакомления, не сильно касающееся этой статьи. Важна первая часть из материала — «конкретной задаче — свой инструмент», поэтому глупо и неправильно выбирать один язык, так как он не может быть хорош для всех видов задач.
А вот статья с обратным посылом, что лучше выбрать один язык и использовать его для всего: www.teamten.com/lawrence/writings/java-for-everything.html
Сколько людей — столько мнений.
Сколько людей — столько мнений.
нет
I found that to be particularly gruesome when working with seasoned Java developers. Yeah, sure, they have been doing OOP for a long time, for whatever that’s worth. But that doesn’t mean that it’s a good idea to recreate Java in Scala with just a little bit less of boilerplate. In well over a year of working in Scala teams there hasn’t been a single day where I felt that there was a shared mindset about how to develop a system or even approach a problem.
С одной стороны, он не первый, кто пересел со Scala на Clojure и говорит о том, что разработка на последнем намного более прямолинейна. Но с другой стороны, простите, если ситуация в стиле лебедь рак и щука, то почему винить язык? Скорее это проблема в том, что команда не может договориться внутри себя.
Но если правду сказать, наш проект страдает от тех же проблем. Отсутствие однозначной политики разработки + тонна возможностей + неправильный выбор библиотек + команда в 12 человек = далеко не гладкий код.
Правильно пишете. Та самая тонна возможностей порождает кучу неоднозначностей. Люди любят бросаться в крайности и использовать найденные мегафичи к месту и не к месту, а в Scala их навалом и договориться оч сложно. Можно провести мысленный эксперимент: взять какую-нибудь Java-команду, и если каждый по отдельности начнет интересоваться и пробовать Scala, то со временем всем настолько понравится, что захотят проект частично/полностью смигрировать. Но полученный в изоляции опыт и впечатления у всех будут разными, вот и получится каша. Наверное единственный вариант этого избежать — учиться всем одновременно и централизованно, тогда и все соглашения будут всем понятны.
Что касается Closure, то мне кажется, народ начинает интересоваться им (и прочими ФЯП) по причине «о, да тут после сплошной Java-императивности еще и функциональщина есть, выглядит интересно, надо еще покопать в ту сторону».
Что касается Closure, то мне кажется, народ начинает интересоваться им (и прочими ФЯП) по причине «о, да тут после сплошной Java-императивности еще и функциональщина есть, выглядит интересно, надо еще покопать в ту сторону».
Согласен. Внутри команды такую проблему решить можно. Те же Twitter неплохо в «Effective Scala» описали что они юзают, а что стараются избегать. Но проблема глубже — у разных команд / проектов могут быть свои конвенции…
Хотя, лично я не считаю предоставление массы возможностей как можно решить задачу минусом.
Хотя, лично я не считаю предоставление массы возможностей как можно решить задачу минусом.
Перевод очень плохой — мне, как плохо знакомому со Scala человеку, пришлось почитать исходную статью на английском чтобы понять о чем вообще речь.
Например:
Вот честно, не понял смысл предложения «Вместо этого ты пыталась быть всеобщей любимицей, предлагая каждой разработке ПО парадигму, известную всему человечеству.» И соответственно эти два абзаца в вашем переводе тоже не понял полностью.
Исходник
Смысл
Часть предложений у вас поменяло смысл на прямо противоположный
В исходнике наоборот «не было ни одного дня, когда я бы чувствовал командного духа», в вашем переводе получилось что он чувствовал этот командный дух постоянно и это еще не учитывая того, что в исходнике речь шла не совсем о командном духе и было точно описано в несколько словосочетаний о чем именно.
Или
В исходнике прямо противоположное
Если буквально, то: «Мне не нужен прерыв» если художественно то «Речь вовсе не о перерыве, я нашел партнера получше.»
Например:
Сначала я воспринял за любезность то, что ты пыталась угодить мне, предлагая такую работу, которая приходилась мне по духу. Но затем я заметил, что это не было чем-то таким, что ты предлагала именно мне. Вместо этого ты пыталась быть всеобщей любимицей, предлагая каждой разработке ПО парадигму, известную всему человечеству.
Для меня это оказалось ужасным открытием, когда стал работать в команде с опытными Java разработчиками. Знаешь, в течение долгого времени они занимались ООП, и как бы то ни было, это того стоит. Только не значит, что это хорошая идея воссоздать Java в Scala, где будет всего лишь чуть меньше шаблонов. В течение более чем одного года работы в командах Scala не было ни одного дня, когда я бы не чувствовал командного духа, направленного на то, чтобы разработать систему или приблизиться к решению проблемы.
Вот честно, не понял смысл предложения «Вместо этого ты пыталась быть всеобщей любимицей, предлагая каждой разработке ПО парадигму, известную всему человечеству.» И соответственно эти два абзаца в вашем переводе тоже не понял полностью.
Исходник
At first, I took it as a compliment that you tried to please me by offering me to work the way I liked. But then I noticed that it wasn’t something you did for me in particular. Instead, you try to be everybody’s darling by offering every software development paradigm known to man.
I found that to be particularly gruesome when working with seasoned Java developers. Yeah, sure, they have been doing OOP for a long time, for whatever that’s worth. But that doesn’t mean that it’s a good idea to recreate Java in Scala with just a little bit less of boilerplate. In well over a year of working in Scala teams there hasn’t been a single day where I felt that there was a shared mindset about how to develop a system or even approach a problem.
Смысл
Поначалу мне показалось очень приятным то, что ты предлагаешь мне выполнять задачи именно тем способом, который мне нравится. Но спустя некоторое время я заметил, что ты предлагаешь это не только мне. Вместо этого ты хочешь понравится всем, одновременно предлагая все известные человечеству парадигмы программирования.
Ужаснее всего это было при работе с опытными Java-разработчиками. Да, конечно, они очень долго занимались ООП и наверное это того стоило. Но это вовсе не означает, что попытка воссоздать Java на Scala с несколько меньшим количеством шаблонного кода, является хорошей идеей. В течение более чем года работы в использующих Scala командах не было ни одного дня, когда я бы чувствал, что у нас есть общее понимание того, как надо разрабатывать систему или хотя бы единый подход к решению проблем.
Часть предложений у вас поменяло смысл на прямо противоположный
В течение более чем одного года работы в командах Scala не было ни одного дня, когда я бы не чувствовал командного духа, направленного на то, чтобы разработать систему или приблизиться к решению проблемы
В исходнике наоборот «не было ни одного дня, когда я бы чувствовал командного духа», в вашем переводе получилось что он чувствовал этот командный дух постоянно и это еще не учитывая того, что в исходнике речь шла не совсем о командном духе и было точно описано в несколько словосочетаний о чем именно.
Или
У меня перерыв; я нашел замену лучше.
В исходнике прямо противоположное
I don’t need to take a break; I have found a better match.
Если буквально, то: «Мне не нужен прерыв» если художественно то «Речь вовсе не о перерыве, я нашел партнера получше.»
Заранее оговорюсь, что не хочу спровозировать конфликт на почве религиозных разногласий, все это мое персональное мнение.
Scala изначально позиционировался как универсальный язык для всего. Основными целями было:
1. Создать гибкий инструмент, который бы позволил использовать вместе различные парадигмы.
2. Совместимость с Java.
3. Максимальная лаконичность записи. Ничего лишнего.
4. Создание новых синтаксических конструкций через DSL.
5. Наиболее полная система типов.
6. Стать новым IT стандартом.
Считалось, что эти ништяки станут привлекательным для большинства программистов и заставят их пересесть на новый велосипед. Плюс всевозможная реклама подстегивала интерес. Что получилось реально:
1. Различные парадигмы плохо сочетаются друг с другом. Кроме того, использовать в коде сразу несколько парадигм делает код запутанным, а сам язык увеличивает свой «порог вхождения». В 95% случаев функциональный подход используют для лямбд и работе с коллекциями: это модная фича, а программеры уже приучены. Функциональный подход при проектировании приложения встречается крайне редко. В итоге язык становится неким монстром Франкенштейна из плохо сшитых частей разных тел.
2. С дополнительными костылями. Коллекции несовместимы, структуры другие. Постоянно нужно держать в уме во что это будет компилиться. Учитывая что 99% библиотек и фреймворков написаны на Java, это дополнительная сложность.
3. Вообще странно. С одной стороны в Scala есть длинные ключевые слова, которые можно было бы сократить, с другой стороны, вся стардартная библиотека изобилует злоупотреблениями ввиде операторов. Вместо английского названия метода, объясняющего операцию, стоит одна или несколько закорючек, интуитивно не понятных без документации. В угоду DSL был окончательно испорчен синтаксис, позволяющий записывать одно и то же разными способами. Многие называют это гибкостью, когда это больше похоже на отсутствие костей. Сомнительная идея выражений через вызовы методов порождают сложные правила применения операций. В итоге, чем короче хочется написать, тем больше приходится нагружать язык синтаксической магией. Многие конструкции, типа XML, совершенно рудиментарные и искусственно внесены в язык, чтобы где-то сократить написание.
4. Удобство DSL — спорная идея, т.к. привносит магию. Обычно DSL используются для создания builder-а для сложного объекта по типу конфигурации. Попытка расширять конструкции языка через DSL сильно искусственна. Поэтому создатели Scala в последнее время смотрят в сторону макросов Nemerle.
5. А реальный смысл делать систему типов 100% type-safe и настолько сложной? Обычно в редких случаях, где появляется unchecked type casting, программист сам неплохо контролирует это. Как-то же программируют и на языках с динамической типизацией.
6. Несмотря на рекламу, Scala слабо адаптируется в среде программистов. Каждый обязан ее попробовать, но очень скоро вау-эффект пройдет. Создатели Scala ориентированы на совершенно других задачах, нежели требуется в реальных проектах. Скоро это поняли и создали инициативу typesafe.com. Однако покрываемая typesafe.com предметная область сильно ограничена. То есть, либо ты должен использовать Java фреймворк, что только усложняет ситуацию, либо шлепать функционал самому.
P.S. Если цитировать гения «Make it as simple as possible but not simpler», то Scala не может считаться гениальным языком :)
Scala изначально позиционировался как универсальный язык для всего. Основными целями было:
1. Создать гибкий инструмент, который бы позволил использовать вместе различные парадигмы.
2. Совместимость с Java.
3. Максимальная лаконичность записи. Ничего лишнего.
4. Создание новых синтаксических конструкций через DSL.
5. Наиболее полная система типов.
6. Стать новым IT стандартом.
Считалось, что эти ништяки станут привлекательным для большинства программистов и заставят их пересесть на новый велосипед. Плюс всевозможная реклама подстегивала интерес. Что получилось реально:
1. Различные парадигмы плохо сочетаются друг с другом. Кроме того, использовать в коде сразу несколько парадигм делает код запутанным, а сам язык увеличивает свой «порог вхождения». В 95% случаев функциональный подход используют для лямбд и работе с коллекциями: это модная фича, а программеры уже приучены. Функциональный подход при проектировании приложения встречается крайне редко. В итоге язык становится неким монстром Франкенштейна из плохо сшитых частей разных тел.
2. С дополнительными костылями. Коллекции несовместимы, структуры другие. Постоянно нужно держать в уме во что это будет компилиться. Учитывая что 99% библиотек и фреймворков написаны на Java, это дополнительная сложность.
3. Вообще странно. С одной стороны в Scala есть длинные ключевые слова, которые можно было бы сократить, с другой стороны, вся стардартная библиотека изобилует злоупотреблениями ввиде операторов. Вместо английского названия метода, объясняющего операцию, стоит одна или несколько закорючек, интуитивно не понятных без документации. В угоду DSL был окончательно испорчен синтаксис, позволяющий записывать одно и то же разными способами. Многие называют это гибкостью, когда это больше похоже на отсутствие костей. Сомнительная идея выражений через вызовы методов порождают сложные правила применения операций. В итоге, чем короче хочется написать, тем больше приходится нагружать язык синтаксической магией. Многие конструкции, типа XML, совершенно рудиментарные и искусственно внесены в язык, чтобы где-то сократить написание.
4. Удобство DSL — спорная идея, т.к. привносит магию. Обычно DSL используются для создания builder-а для сложного объекта по типу конфигурации. Попытка расширять конструкции языка через DSL сильно искусственна. Поэтому создатели Scala в последнее время смотрят в сторону макросов Nemerle.
5. А реальный смысл делать систему типов 100% type-safe и настолько сложной? Обычно в редких случаях, где появляется unchecked type casting, программист сам неплохо контролирует это. Как-то же программируют и на языках с динамической типизацией.
6. Несмотря на рекламу, Scala слабо адаптируется в среде программистов. Каждый обязан ее попробовать, но очень скоро вау-эффект пройдет. Создатели Scala ориентированы на совершенно других задачах, нежели требуется в реальных проектах. Скоро это поняли и создали инициативу typesafe.com. Однако покрываемая typesafe.com предметная область сильно ограничена. То есть, либо ты должен использовать Java фреймворк, что только усложняет ситуацию, либо шлепать функционал самому.
P.S. Если цитировать гения «Make it as simple as possible but not simpler», то Scala не может считаться гениальным языком :)
Как то все очень за уши притянуто и надумано…
Вообще, для всех программистов самым главным принципом должен быть «Здравый смысл».
Не один раз слышал как рассказывали про плохую скалу и как с ней наплакались в проекте.
А потом оказывалось, что они совершенно бездумно смешав Java и Scala на проекте, породили ужасного франкенштейна… и естественно в этом виновата Scala.)
Казалось бы, что может быть проще…
DSL кажется магией и непонятно зачем он вообще нужен?
Ну так не используй раз не понимаешь.
Зачем считать возможность удобного написания DSL минусом языка?
Не умеешь красиво сочетать разные парадигмы?
Есть классный анекдот про пилу дружба, которой пилили не включив))
Не нравится соместимость с Java?
Ну так пораскинь мозгами. Scala это не расширение Java.
Она не должна быть интероперабельна полностью, это убьет всю идею новых возможностей.
Создатели дали хороший механизм совместимости, как раз полностью достаточный.
Из Scala можно юзать все написанное на Java.
Если нужна совместимость в обратную сторону, значит или ты знаешь что делаешь и понимаешь почему нужно думать об этом. Или же ты не понимаешь… и тогда аргументы о костылях неуместны.
Не понимаешь зачем нужна строгая типизация?
Значит просто не делал проектов где это критично.
Хотя сейчас большинство проектов это, условно, «просто сайтики», там это мало заметно.
Пока не окунешься в эту боль, объяснения мало помогут.
Это как рассказывать что огонь обжигает.
Вроде и понятно, но реально начнешь избегать когда сам обожжешься.
6-й пункт вообще сектой какой-то попахивает…
Кто-то, в здравом уме, выбирает технологии по «вау-эффекту»?
Расскажите создателям Scala, что они ориентированы на совершенно других задачах, нежели требуется в реальных проектах. А то они бедные идут в слепую…
Да еще и не покрывают собой всю предметную область.
Вон Oracle, раз и покрыли на Java всю предметную область, а typesafe что-то тормозят.)
Про сложность использования Java фреймворков и библиотек в начале писал.
Все от людей зависит.
> Если цитировать гения «Make it as simple as possible but not simpler», то Scala не может считаться гениальным языком :)
Ну вам то оно конечно виднее. Вы кстати в разработке скольких языков участвовали, что бы делать такие заявления?
Вообще, для всех программистов самым главным принципом должен быть «Здравый смысл».
Не один раз слышал как рассказывали про плохую скалу и как с ней наплакались в проекте.
А потом оказывалось, что они совершенно бездумно смешав Java и Scala на проекте, породили ужасного франкенштейна… и естественно в этом виновата Scala.)
Казалось бы, что может быть проще…
DSL кажется магией и непонятно зачем он вообще нужен?
Ну так не используй раз не понимаешь.
Зачем считать возможность удобного написания DSL минусом языка?
Не умеешь красиво сочетать разные парадигмы?
Есть классный анекдот про пилу дружба, которой пилили не включив))
Не нравится соместимость с Java?
Ну так пораскинь мозгами. Scala это не расширение Java.
Она не должна быть интероперабельна полностью, это убьет всю идею новых возможностей.
Создатели дали хороший механизм совместимости, как раз полностью достаточный.
Из Scala можно юзать все написанное на Java.
Если нужна совместимость в обратную сторону, значит или ты знаешь что делаешь и понимаешь почему нужно думать об этом. Или же ты не понимаешь… и тогда аргументы о костылях неуместны.
Не понимаешь зачем нужна строгая типизация?
Значит просто не делал проектов где это критично.
Хотя сейчас большинство проектов это, условно, «просто сайтики», там это мало заметно.
Пока не окунешься в эту боль, объяснения мало помогут.
Это как рассказывать что огонь обжигает.
Вроде и понятно, но реально начнешь избегать когда сам обожжешься.
6-й пункт вообще сектой какой-то попахивает…
Кто-то, в здравом уме, выбирает технологии по «вау-эффекту»?
Расскажите создателям Scala, что они ориентированы на совершенно других задачах, нежели требуется в реальных проектах. А то они бедные идут в слепую…
Да еще и не покрывают собой всю предметную область.
Вон Oracle, раз и покрыли на Java всю предметную область, а typesafe что-то тормозят.)
Про сложность использования Java фреймворков и библиотек в начале писал.
Все от людей зависит.
> Если цитировать гения «Make it as simple as possible but not simpler», то Scala не может считаться гениальным языком :)
Ну вам то оно конечно виднее. Вы кстати в разработке скольких языков участвовали, что бы делать такие заявления?
У меня есть положительный опыт командной разработке на Scala. Не смотря на сложные концепции, код получается компактным и легко исправляется. Бывает сложно провести рефакторинг из-за вывода типов и имплиситов, но все проблемы разрешимы. Возможно, здесь поможет IDE, просто я не умею ими пользоваться — даже под виндой пользуюсь vim.
Что интересно в статье — он перешел на Clojure. То есть к Java, JavaScript или Python уже точно не вернется ;-).
Что интересно в статье — он перешел на Clojure. То есть к Java, JavaScript или Python уже точно не вернется ;-).
Почему, те кто переходит на Clojure, уже не возвращается на Java, JavaScript или Python?
наверное у них наступает Lis головного мозга )
А если серьезно, то в Java — потому что итак пишет под JVM.
Насчет Python я бы не был столь категоричен — у языка есть свои ниши, да и на тех же нишах(что и Clojur/Scala) он тоже ничуть не уступает(я про Big Data, Data Mining etc.).
По поводу JS отчасти согласен )
А если серьезно, то в Java — потому что итак пишет под JVM.
Насчет Python я бы не был столь категоричен — у языка есть свои ниши, да и на тех же нишах(что и Clojur/Scala) он тоже ничуть не уступает(я про Big Data, Data Mining etc.).
По поводу JS отчасти согласен )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Прощальная записка языку программирования