> Так от чего в Java провалилась идея разделения предвиденных ошибок и непредвиденных исключений? Может из-за реализации?
Отчасти — из-за реализации. Отчасти — потому что сама идея разделения исключений не проходит бритву Оккама. Checked exceptions — эта новая сущность, но никаокй пользы от ее введения нет. Это доказано последующими языками с таким же механизмом обработки (try-catch), но без checked exceptions. Оказалось, без них даже лучше.
> Тогда к Go это не имеет ни какого отношения, там другая реализация
А настолько ли другая? Что меня больше всего раздражало в checked exceptions:
1. компилятор обязательно заставляет их обрабатывать. Именно из этого и растут ноги того самого страшного try с пустым catch, которым теперь любители го попрекают джавистов. Боюсь, у вас скоро будет то же самое.
2. checked exceptions уродуют сигнатуры методов, препятствуют полиморфизму. Очень похоже, что в го то же самое, но не уверен.
Так это вопрос к авторам языка. Я же привел классические примеры checked и unchecked exceptions из джава и то, как они выглядят в го. Похоже ребята уверенно наступают на те же грабли, что и джава 20 лет назад. Но там хотя бы был единый механизм обработки, а тут два разных.
> Автор считает, что должно быть разделение на ошибки и исключения. В чем я его поддерживаю.
Два сценария:
1. файл в папке не найден — это исключение, обрабатывается ифом
2. элемент в массиве не найден — это ошибка, panic, обрабатывается в recover.
> Это значит, что механизм разделения на два вида исключений (обрабатываемые и необрабатываемые) провалился.
Неужели? Почему же тогда в комментарии, с которого началась эта дискуссия автор радостно объясняет нам важность такого разделения, да еще как будто в го первыми до него додумались. Получается, мало того, что идея далеко не нова, так она еще и успела провалиться много лет назад. Зачем же это затаскивают в го? Наступают на те же грабли?
P.S. Если серьезно, то я не считаю, что идея с checked exceptions прямо полностью провалилась. В некоторых случаях (тот же I/O) польза от них была.
> Который не работает с лямбдами? Ведь если вы работали с Java'ой, вы знаете что checked exception's не дружат с лямбдами.
Да, checked exceptions не дружат с лямбдами. Но разве это значит, что весь механизм обработки исключений не работает с лямбдами?
> Так же остается вопрос о передаче исключений между потоками (есть хорошая статья о FutureTask, но это не решение).
Что за статья и почему не решение? Напрямую с потоками в джаве мало кто работает. В современных фреймворках типа Akka, проблем с обработкой исключений нет.
> В Java нет value типов, кроме примитивных(обещают в 10ой), а так же нет ADT(вообще не обещают), а значит возврат таких типов не несет особого смысла.
Т.е. если что-то из перечисленного появится, пара результат-исключение станет более предпочтительна, чем try-catch?
Согласен с критикой джавы. Не согласен, что в скале есть какие-то серьезные проблемы интероперабельности. Да, свои коллекции, свои парадигмы. Но можно писать джава-стайл с джава-коллекциями, аннотациями, спрингом и хибернейтом (хотя последнее, честно говоря, не пробовал).
Про историю создания со многим можно согласиться.ю но некоторые моменты хотелось бы прокомментировать:
> мощная система типов, которая, в прочем, плохо ложится на ООП-core, в отличие от того же Haskell-а
Ну не знаю, как там по сравнению с хаскелем, а по сравнению с джавой, скала далеко впереди и по ООП- и по ФП-компоненте.
> язык загромоздили тоннами синтаксического сахара
По-моему, количество реального синтаксического сахара сильно преувеличивается. Так при желании всю скалу можно назвать сахаром поверх джавы.
>… метапрограммирование через AST и макросы. Кому-то очень понравилась идея, а также душила жаба, что подобной фигни еще нет в scala.
Была фигня, называлась плагины к компилятору. Просто сделали еще более высокоуровневое и безопасное API к компилятору. Это вполне вписывается в концепцию расширяемого языка.
> Для истинных ценителей ФП есть красивейший Haskell.
Ну да, красивейший хаскель не взлетел. Как и прекрасный F#, за которым популярная платформа производства крупнейшей корпорации. Видимо, истиных ценителей чистого ФП не так много. Но и в чисто императивном стиле писать надоело. На первый план выходят гибридные языки, скала как раз яркий представитель этой группы. Выходит, так оно и задумывалось.
> нет задачи, которую можно решить в Scala/Clojure/Groovy и т.д. и нельзя решить в Java.
Хорошо. Тогда переформулирую так:
Только если все (и менеджмент — в первую очередь) четко понимают, зачем конкретно они взяли скалу, благодаря каким фреймворкам/фичам языка можно решить поставленные задачи эффективнее, чем рамках джавы, тогда переход идет относительно спокойно.
divan0 > Подход Go тут является и зрелым и свежим одновременно, он чрезвычайно прост и при этом непривычен для понимания, и требует определенных усилий, чтобы прочувствовать всю мощь. Но, что самое важное — он отлично работает на практике.
Sevlyar > Go бескомпромисен, он побуждает, или даже, вынуждает программиста использовать те практики, которые считаются хорошими в мире Go. Если у вас вызывает дискомфорт такое отношение или если для вас хорошие практики отличны от того, что принято в Go, то конечно же у вас будет негативное впечатление от этого ЯП.
Хочу автогенератор таких предложений, только чтобы вместо Go подставлялся язык по выбору.
> Возможно, некоторые не понимают разницу между «предвиденной ошибкой» и «непредвиденной исключительной ситуацией». Путают или смешивают эти понятия, что не мудрено, ибо C++, C#, Java и др. идеологически используют единый подход для работы с ними: throw, try-catch-finally.
Не понимают разницу, идеологически используют единый подход? В Java есть checked exceptions, unchecked exceptions и errors. И для каждого из этих типов есть свои подходы по применению и обработке (см. напрмер http://habrahabr.ru/post/183322/).
Да, в Java еще 20 лет назад осилили единый механизм обработки исключений. Но разве это плохо, для разных случаев и разных подходов использовать унифицированный механизм? Если бы кому-то было надо в Java, могли бы возвращать из методов Pair<Result, Exception>. Но вы вряд ли где-нибудь встретите такое, ведь это просто неудобно.
Да, согласен, что подход «вот вы ту все пишите на беспонтовой джаве, а я вас сейчас быстренько пересажу на модную скалу» в реальной жизни не работает. Только если все (и менеджмент — в первую очередь) четко понимают, зачем конкретно они взяли скалу, почему нельзя решить поставленные задачи в рамках джавы, тогда переход идет относительно спокойно. Постепенно изучаются фрейморки, принятые подходы и практики, начинает расти продуктивность.
> сам язык достаточно эстетически неприятный, неминималистичный, передроченый всевозможными концептами
Ну тут уж кому шашечки, а кому — ехать. Можно долго искать эстетичный, минималистичный и глубоко концептуальный ЯП, и закончить брейнфаком :) Скала в этом плане далеко не идеальный язык, конечно. Но я смотрю на другие языки и понимаю, что Одерский и ко умудрились замесить именно такие фичи и в таких пропорциях, что это стало огромным шагом вперед по сравнению с остальными.
> Имеете в виду автоматическое создание свойства, вроде int prop{ get; set; }?
Первый шаг в сторону от геттеров-сеттеров — это признание на уровне синтаксиса языка наличие такое сущности как «свойство». Конкретно в C# так было сразу, но например, в Java свойство выглядит как два отдельных метода getX и setX, и у автора в примере так же.
Второй шаг в сторону от геттеров-сеттеров — автогенерация в тривиальных случаях. Появился в C# хоть и не сразу, но уже очень давно.
> Но ведь это всё равно пара геттер-сеттер
Я разве где-то утверждал обратное? Я говорил, что писать в С# геттеры-сеттеры двумя отдельными методами — не есть хорошо.
Сто лет уже как добавили специальный синтаксис для пропертей, чтобы «инкапсулированный» вариант выглядел практически так же как первый вариант в посте. Зачем? Наверно затем, что в подавляющем большинстве случаев люди хотят работать со свойствам как с публичными полями, а не как с двумя отдельными методами.
По-моему для этого пункта подобран крайне неудачный пример. Первый вариант из 4-х строчек очевидно выигрывает у второго по читабельности, минималистичности и простоте отладки. Появление геттеров-сеттеров, размывающих семантику свойств, преподносится как благо, хотя в том же C# (пример вроде на нем) от них уже давно стараются по максимуму уйти.
С некоторыми пунктами вполне можно согласиться. Но некоторые наверняка писались со слов «джавистов», слишком уж субъективно сформулированы. Это сильно напоминает мне собственный опыт общения с консервативно настроенными java-программистами, которых без понимания и мотивации с их стороны просто заставили использовать скалу. Результат вполне естественный — отторжение. Вот например:
> Скалисты пытались использовать как можно больше возможностей языка, тогда как джависты ограничивались лишь необходимым минимумом.
Кто определял меру необходимости? Уверен, что джависты.
> Скалисты постоянно злоупоребляли абстракциями, которые не имели к предметной области никакого отношения.
Злоупотребление абстракциями — любимое развлечение начинающих программистов, которые только познакомились с идеями ООП. Попытка объявить это недостатком конкретного ЯП настораживает…
> Скалисты вцелом пытались написать короче (объявляя это «красотой» решения), тогда как джависты — понятней.
Понятней для кого? Очевидно, для джавистов. И да, код на скала обычно сильно короче и красивее.
> Постоянно приходилось использовать решения из экосистемы Java, которые иногда давали проблемы с интеграцией в Scala
Ну да, небось пытались затащить в проект какой-нибудь Spring или Hibernate и огребли. Зачем вообще тогда скалу брали…
> Отдельный вопрос — экосистема Scala. Извечная полемика какую библиотеку использовать, что подключать и вообще зачем новая библиотека scala, если есть прекрасная старая из java.
Ага, как я и предположил по предыдущему пункту. Джависты натащили в проект «прекрасных старых» библиотек и сами же потом начали возмущаться, что они плохо подходят.
> Хоть и сложно давать оценку производительности, но какого-либо существенного прироста замечено не было. Коллега уверен, что на java все было бы сделано быстрее и качественней.
«Коллега» — это видимо тот, с чьих слов записаны эти пункты. Мне один такой коллега расказывал, что он со своими познаниями в java.util.concurrent может написать на джаве Акку за неделю. Что с ним стало через год? Пишет Spark-коннектор для распределенной системы. На скале, конечно.
И да, первый и последний пункт противоречат друг другу. Это один из признаков, что у менеджера не все в порядке с головой. Как иначе объяснить то, что он столкнул людей лбами в своем проекте, настолько, что они разделились на две группировки «скалисты» и «джависты». Видимо, скалисты оказались в меньшинстве как количественно так и по сеньорности, и все запиливали демотивированные джависты, у которых выбили почву из под ног незнакомым стеком технологий. В итоге получилось так себе, но стоит ли винить во всем язык программирования?
P.S. Не взыщите, если неверно восстановил ситуацию. Делать глубокие выводы по одному комментарию — дело неблагодарное. Но уж очень знакомыми кажутся аргументы.
Еще довод: крутые фреймворки, написанные на Scala, такие как Akka, Spark, Play. Бывает, что намучившись с их Java API, люди прислушиваются к голосу здравого смысла и переводят разработку на Scala.
> Scala неизменно отпугивает обилием ~, !, ->, <-, =>, !!, ~~ и прочих значков.
Значков, которые встроены в Scala примерно столько же, сколько и в других языках типа Java и C#. Да, Scala разрешает использовать значки в названиях методов, но никто же не заставляет.
> IDE жутко тормозят, парся сложный синтаксис.
Да, компиляция проходит медленее, чем в Java. Правда, вроде не столько из-за парсинга, сколько из-за автовывода и проверки типов. Т.е. делает более умные вещи, облегчая жизнь разработчику.
> Например, потратив пару дней на изучение парсеров/комбинаторов, я написал красивый и изящный код.
А какая альтернатива, например, для Java? JavaCC, Antlr — там разве не надо тратить время на изучение синтаксиса? Мощь Scala в том, что она позволяет решить проблемы с помощью DSL не выходя за рамки языка.
Отчасти — из-за реализации. Отчасти — потому что сама идея разделения исключений не проходит бритву Оккама. Checked exceptions — эта новая сущность, но никаокй пользы от ее введения нет. Это доказано последующими языками с таким же механизмом обработки (try-catch), но без checked exceptions. Оказалось, без них даже лучше.
> Тогда к Go это не имеет ни какого отношения, там другая реализация
А настолько ли другая? Что меня больше всего раздражало в checked exceptions:
1. компилятор обязательно заставляет их обрабатывать. Именно из этого и растут ноги того самого страшного try с пустым catch, которым теперь любители го попрекают джавистов. Боюсь, у вас скоро будет то же самое.
2. checked exceptions уродуют сигнатуры методов, препятствуют полиморфизму. Очень похоже, что в го то же самое, но не уверен.
Два сценария:
1. файл в папке не найден — это исключение, обрабатывается ифом
2. элемент в массиве не найден — это ошибка, panic, обрабатывается в recover.
Все логично, какие могут быть вопросы…
Неужели? Почему же тогда в комментарии, с которого началась эта дискуссия автор радостно объясняет нам важность такого разделения, да еще как будто в го первыми до него додумались. Получается, мало того, что идея далеко не нова, так она еще и успела провалиться много лет назад. Зачем же это затаскивают в го? Наступают на те же грабли?
P.S. Если серьезно, то я не считаю, что идея с checked exceptions прямо полностью провалилась. В некоторых случаях (тот же I/O) польза от них была.
Да, checked exceptions не дружат с лямбдами. Но разве это значит, что весь механизм обработки исключений не работает с лямбдами?
> Так же остается вопрос о передаче исключений между потоками (есть хорошая статья о FutureTask, но это не решение).
Что за статья и почему не решение? Напрямую с потоками в джаве мало кто работает. В современных фреймворках типа Akka, проблем с обработкой исключений нет.
> В Java нет value типов, кроме примитивных(обещают в 10ой), а так же нет ADT(вообще не обещают), а значит возврат таких типов не несет особого смысла.
Т.е. если что-то из перечисленного появится, пара результат-исключение станет более предпочтительна, чем try-catch?
Согласен с критикой джавы. Не согласен, что в скале есть какие-то серьезные проблемы интероперабельности. Да, свои коллекции, свои парадигмы. Но можно писать джава-стайл с джава-коллекциями, аннотациями, спрингом и хибернейтом (хотя последнее, честно говоря, не пробовал).
Про историю создания со многим можно согласиться.ю но некоторые моменты хотелось бы прокомментировать:
> мощная система типов, которая, в прочем, плохо ложится на ООП-core, в отличие от того же Haskell-а
Ну не знаю, как там по сравнению с хаскелем, а по сравнению с джавой, скала далеко впереди и по ООП- и по ФП-компоненте.
> язык загромоздили тоннами синтаксического сахара
По-моему, количество реального синтаксического сахара сильно преувеличивается. Так при желании всю скалу можно назвать сахаром поверх джавы.
>… метапрограммирование через AST и макросы. Кому-то очень понравилась идея, а также душила жаба, что подобной фигни еще нет в scala.
Была фигня, называлась плагины к компилятору. Просто сделали еще более высокоуровневое и безопасное API к компилятору. Это вполне вписывается в концепцию расширяемого языка.
> Для истинных ценителей ФП есть красивейший Haskell.
Ну да, красивейший хаскель не взлетел. Как и прекрасный F#, за которым популярная платформа производства крупнейшей корпорации. Видимо, истиных ценителей чистого ФП не так много. Но и в чисто императивном стиле писать надоело. На первый план выходят гибридные языки, скала как раз яркий представитель этой группы. Выходит, так оно и задумывалось.
Хорошо. Тогда переформулирую так:
Только если все (и менеджмент — в первую очередь) четко понимают, зачем конкретно они взяли скалу, благодаря каким фреймворкам/фичам языка можно решить поставленные задачи эффективнее, чем рамках джавы, тогда переход идет относительно спокойно.
Sevlyar > Go бескомпромисен, он побуждает, или даже, вынуждает программиста использовать те практики, которые считаются хорошими в мире Go. Если у вас вызывает дискомфорт такое отношение или если для вас хорошие практики отличны от того, что принято в Go, то конечно же у вас будет негативное впечатление от этого ЯП.
Хочу автогенератор таких предложений, только чтобы вместо Go подставлялся язык по выбору.
Не понимают разницу, идеологически используют единый подход? В Java есть checked exceptions, unchecked exceptions и errors. И для каждого из этих типов есть свои подходы по применению и обработке (см. напрмер http://habrahabr.ru/post/183322/).
Да, в Java еще 20 лет назад осилили единый механизм обработки исключений. Но разве это плохо, для разных случаев и разных подходов использовать унифицированный механизм? Если бы кому-то было надо в Java, могли бы возвращать из методов Pair<Result, Exception>. Но вы вряд ли где-нибудь встретите такое, ведь это просто неудобно.
> сам язык достаточно эстетически неприятный, неминималистичный, передроченый всевозможными концептами
Ну тут уж кому шашечки, а кому — ехать. Можно долго искать эстетичный, минималистичный и глубоко концептуальный ЯП, и закончить брейнфаком :) Скала в этом плане далеко не идеальный язык, конечно. Но я смотрю на другие языки и понимаю, что Одерский и ко умудрились замесить именно такие фичи и в таких пропорциях, что это стало огромным шагом вперед по сравнению с остальными.
Первый шаг в сторону от геттеров-сеттеров — это признание на уровне синтаксиса языка наличие такое сущности как «свойство». Конкретно в C# так было сразу, но например, в Java свойство выглядит как два отдельных метода getX и setX, и у автора в примере так же.
Второй шаг в сторону от геттеров-сеттеров — автогенерация в тривиальных случаях. Появился в C# хоть и не сразу, но уже очень давно.
> Но ведь это всё равно пара геттер-сеттер
Я разве где-то утверждал обратное? Я говорил, что писать в С# геттеры-сеттеры двумя отдельными методами — не есть хорошо.
> Действительно, зачем?
Не понял, к чему относится этот вопрос.
По-моему для этого пункта подобран крайне неудачный пример. Первый вариант из 4-х строчек очевидно выигрывает у второго по читабельности, минималистичности и простоте отладки. Появление геттеров-сеттеров, размывающих семантику свойств, преподносится как благо, хотя в том же C# (пример вроде на нем) от них уже давно стараются по максимуму уйти.
> Скалисты пытались использовать как можно больше возможностей языка, тогда как джависты ограничивались лишь необходимым минимумом.
Кто определял меру необходимости? Уверен, что джависты.
> Скалисты постоянно злоупоребляли абстракциями, которые не имели к предметной области никакого отношения.
Злоупотребление абстракциями — любимое развлечение начинающих программистов, которые только познакомились с идеями ООП. Попытка объявить это недостатком конкретного ЯП настораживает…
> Скалисты вцелом пытались написать короче (объявляя это «красотой» решения), тогда как джависты — понятней.
Понятней для кого? Очевидно, для джавистов. И да, код на скала обычно сильно короче и красивее.
> Постоянно приходилось использовать решения из экосистемы Java, которые иногда давали проблемы с интеграцией в Scala
Ну да, небось пытались затащить в проект какой-нибудь Spring или Hibernate и огребли. Зачем вообще тогда скалу брали…
> Отдельный вопрос — экосистема Scala. Извечная полемика какую библиотеку использовать, что подключать и вообще зачем новая библиотека scala, если есть прекрасная старая из java.
Ага, как я и предположил по предыдущему пункту. Джависты натащили в проект «прекрасных старых» библиотек и сами же потом начали возмущаться, что они плохо подходят.
> Хоть и сложно давать оценку производительности, но какого-либо существенного прироста замечено не было. Коллега уверен, что на java все было бы сделано быстрее и качественней.
«Коллега» — это видимо тот, с чьих слов записаны эти пункты. Мне один такой коллега расказывал, что он со своими познаниями в java.util.concurrent может написать на джаве Акку за неделю. Что с ним стало через год? Пишет Spark-коннектор для распределенной системы. На скале, конечно.
И да, первый и последний пункт противоречат друг другу. Это один из признаков, что у менеджера не все в порядке с головой. Как иначе объяснить то, что он столкнул людей лбами в своем проекте, настолько, что они разделились на две группировки «скалисты» и «джависты». Видимо, скалисты оказались в меньшинстве как количественно так и по сеньорности, и все запиливали демотивированные джависты, у которых выбили почву из под ног незнакомым стеком технологий. В итоге получилось так себе, но стоит ли винить во всем язык программирования?
P.S. Не взыщите, если неверно восстановил ситуацию. Делать глубокие выводы по одному комментарию — дело неблагодарное. Но уж очень знакомыми кажутся аргументы.
Значков, которые встроены в Scala примерно столько же, сколько и в других языках типа Java и C#. Да, Scala разрешает использовать значки в названиях методов, но никто же не заставляет.
> IDE жутко тормозят, парся сложный синтаксис.
Да, компиляция проходит медленее, чем в Java. Правда, вроде не столько из-за парсинга, сколько из-за автовывода и проверки типов. Т.е. делает более умные вещи, облегчая жизнь разработчику.
> Например, потратив пару дней на изучение парсеров/комбинаторов, я написал красивый и изящный код.
А какая альтернатива, например, для Java? JavaCC, Antlr — там разве не надо тратить время на изучение синтаксиса? Мощь Scala в том, что она позволяет решить проблемы с помощью DSL не выходя за рамки языка.
А еще лучше Scala с кейс-классами и статической типизацией.