воскресенье, 13 сентября 2009 г.

[comp.prog.bugs] На днях вышел новый релиз Scala – 2.7.6. Типа с одним баг-фиксом

Релизы новых версий компилятора языка Scala всегда поражали меня одним свойством – спустя несколько дней/недель количество багов, выявленных в новой версии, превышало десяток (а то и не один). Чем это можно объяснить? Для меня это загадка. Вроде бы и задача не архисложная (все-таки в компиляторе Scala не нужно ни машинный код генерировать, ни агрессивные оптимизации проводить) и хорошо покрываемая тестами. И сроков у них жестких не видно. И народу над Scala работает порядочно (а может как раз в этом и дело?)… Но я не припомню релизов, после которых список найденных ошибок содержал бы меньше десяти пунктов.

И вот цитата из анонса Scala 2.7.6 (т.е. шестого(!) обновления версии 2.7):

Мы выпускаем следующую минорную версию Scala 2.7 для исправления одной редкой проблемы, которая может приводить к сообщению “malformed Scala signature”. Никаких других исправлений или изменений не включено; если вы никогда не встречали подобного сообщения, вы не заметите никакой разницы после обновления.

Ну типа – всего один баг-фикс, да еще такой специфический, что если вы с ним никогда не сталкивались, то особой разницы не заметите. Хотя, думаю, правильнее было бы сказать – если вы с ним никогда не сталкивались, то лучше на 2.7.6 и не переходить… Поскольку, буквально вскоре после этого анонса появилось письмо от главного разработчика фреймворка Lift (а Lift, если кто не в теме – это для Scala такой же PR-локомотив, каким для Ruby был Ruby-On-Rails, если не больше): “Unfortunately, Lift doesn't compile under 2.7.6…” А затем и еще одно письмо: “Upgrading from 2.7.5 made Eclipse inoperable. Failed to revert configuration, had to restore from backup.”

Практически, как в старом профессиональном анекдоте: “В любой работающей программе остается, как минимум, три ошибки. Исправление любой из них добавляет в программу еще, как минимум, три новых ошибки.”

Эта заметка из разряда “у соседа корова сдохла – пустячок, а приятно”, но лично меня происходящее заставляет задумываться – а можно ли вообще сейчас писать надежные программы? Ведь если у разработчиков Scala (очень не глупых людей, среди которых есть опытные мегамонстры компиляторостроения, использующих безопасные Java и Scala, работающих на безопасной JVM, без давления со стороны заказчиков) не получается, то что уж говорить о всех остальных?…

10 комментариев:

Skynin комментирует...

Да, сам наблюдаю за развитием Scala (потому что считаю что именно за таким подходом развития ЯП - будущее) Но тоже никак не пойму, в чем же дело... Во-первых, как вижу из анонсов - архитекторы во главе с Одерски еще не наигрались, добавляют фичи в язык абы попробовать, поэксперементировать. Так же и с стандартаными библиотеками, которые ввиду частоты изменений - никак не станут по факту - стандартными. И при этом - глюкавость компилятора уж какой год.

То бишь нарушение главных канонов промышленного программирования массового продукта: Добейся стабильности работы, а потом уже берись за новые фичи

И если вначале, когда только узнал что есть такой язык Scala было непонятно, почему не идет в массы(ведь java программисты давно жалуются на законсервированное развитие Java и облизываются в сторону приятных финтиклюшек C#), то теперь все более понятно, что дело не в сложностях освоения (как раз Одерски и добивался - пиши по джавовски, а по ходу научишься Scala-way) а как раз в - несерьезности какой-то.

И похоже... пока какая-то корпорация не возьмет под свое крыло, насадив жестокие правила внесения изменений в язык и библиотеки, тестирования и проч занудства что неприятно творцам - так и будет, "мечта о Scala", а писать будут на том что есть, и дожидаться Java 7, хотя там ничего существенного не обещается.

eao197 комментирует...

2Skynin: я бы к этому добавил еще одно -- на мой взгляд, язык Scala все-таки чуть переусложнен.

Мне это видится так: есть некоторая часть умных и любознательных программистов. Которым самим интересно осваивать и применять сложные инструменты (что и объясняет живучесть Haskell-ей и OCaml-ов в узких нишах). Это же объясняет и успешность выполняемых на таких языках проектов -- просто напросто их делают программисты, намного выше среднего уровня.

Так вот пока Scala используется в основном такими энтузиастами. Отсюда и терпимое отношение к изменениям в языке, и спокойное отношение к багам в компиляторе/библиотеках. Но вот что будет, когда на Scala придется пересаживать "среднего" Java-иста? Имхо, одна только контравариантность мноих отворотит от языка.

Skynin комментирует...

Это да, но все же Scala не заставляет программиста(т. е. императивного середняка) забыть все, и обучаться новому мышлению.

> Так вот пока Scala используется в основном такими энтузиастами
Главная причина, у всех троих - а в продакшн то не берут :)

И если Haskell с OCaml'ом ввиду отсутствия программистов: существующие должны глубоко переучиться, то со Scala, в первую очередь - из-за неустаканенности.

> Имхо, одна только контравариантность мноих отворотит от языка.
Как во многие вещи при переходе от Си к С++ - можно не вдаваться, так и с Java на Scala - переписывай просто Java код на Scala синтаксис - и все.

Но конечно, доказать что первично невозможно :) и язык сложней Javы, и устойчиво работающего компилятора с стандартизированными либами и прочей инфраструктурой (мощные плагины под IDE, методики проектирования и рефакторинга с учетом возможностей языка) нету.

eao197 комментирует...

Переход от C к C++ не так уж прост. Можно, конечно, использовать C++ как старый добрый C или даже как "C с классами". Но при этом не будет раскрываться вся мощь языка. А чтобы раскрыть всю мощь, требуется немало вложить сил. Именно поэтому C++ не вытеснил C из ниши системного программирования, и поэтому же с C++ большой процент программистов ушли на Java/C# (т.е. факторов много, но сложность языка -- один из самых важных).

Так же и в Scala -- можно будет писать на нем в стиле Java, только зачем тогда его сложность? В общем, у меня складывается впечатление, что Scala слишком академичен, чтобы быть восстребованным очень широкими массами. Может быть, если кто-то выпустит язык для JVM, который будет чем-то средним между Java и Scala, то этот язык может сильно потеснить Scala.

Но вот будет ли такой язык кем-нибудь создан? Да и вообще -- каково будущее Java/JVM после его перехода под крыло Oracle?

Skynin комментирует...

> как "C с классами". Но при этом не будет раскрываться вся мощь языка.
О том и речь - что можно без "мощи языка"
А на Haskell - не перейдешь, "без мощи"

> Именно поэтому C++ не вытеснил C из ниши системного программирования
Думается что - за ненадобностью возможностей "С с классами".

> Так же и в Scala -- можно будет писать на нем в стиле Java, только зачем тогда его сложность?
Так есть не гнаться за мощью языка - сложностей и не будет.

> Scala слишком академичен
Есть конечно такое. И в подходе к изменениям в языке, и в реализации

> Да и вообще -- каково будущее Java/JVM после его перехода под крыло Oracle?
Количество кода на Java обеспечили ей будущее долгое :) Конкурентов пока не видно (разве что когда Mono догонит реализации JVM, начнут писать на C#, и тогда...)
Два опен JDK даже появились.

eao197 комментирует...

> Количество кода на Java обеспечили ей будущее долгое :) Конкурентов пока не видно (разве что когда Mono догонит реализации JVM, начнут писать на C#, и тогда...)

Это да. Но как язык Java, похоже, уже перестал развиваться, а развитие языку необходимо... И если раньше Oracle и IBM были по одну сторону барикад в развитии Java и Unix-а, то теперь они становятся прямыми конкурентами. IBM дофига вложила в Java. И как они теперь в области Java будут между собой разбираться?

Skynin комментирует...

> Но как язык Java, похоже, уже перестал развиваться, а развитие языку необходимо...
По мелочам будет в Java 7. Хотя сама платформа - пару важных вещей приобретет.

По крупному... у всех перед глазами пример развития по крупному - превращения в монстра - "С++"
Кстати, третьим пунктом опаски по отношению к Scala и назвал бы - Одерски и Ко взявши за удачный пример движение от Си к "Си с классами" похоже идут к монстру.

И
Plain C - развивается? Отсутствие развития - помеха держать второе место в Tiobe Index?

> И если раньше Oracle и IBM были по одну сторону барикад в развитии Java и Unix-а,
Java уже не принадлежит никому. Мало того, именно куча бизнес-софта на ней у Oracle и IBM не дадут ей умереть. В худшем случае - появятся несовместимые диалекты VM и языка, что тоже врядли. Потому что прибыль Oracle и IBM от принуждения к переходу на свои варианты джавы особо не увеличится. У них и так свои версии есть IBM Developer Kits and Runtime Environments и JRockit И скорей, они свои варианты Scala начнут делать, чем трогать устоявшийся массовый ЯП.

Как Брюс Эккель где-то в блогах сказал (примерно) - Java стала языком системного программирования для JVM, которая(VM) пригреет множество других языков, изначально написанных под JVM типа Scala, Groovy, Clojure, или реализаций JRuby, Jython.

> И как они теперь в области Java будут между собой разбираться?
Никак. Вернее так же как - с Си и С++.

Даже M$ обещала Mono'вцев в суды не тягать :)

С проекта же "Open JDK 7" вполне вероятно получится нечто вроде "The Linux Foundation". А есть еще Apache Harmony, для подстраховки :)

eao197 комментирует...

Plain C все-таки развивается. Не так давно был C99 принят (http://en.wikipedia.org/wiki/C99) и еще не все компиляторы имеют его полную поддержку.

А что до монстров, то они возникают не от хорошей жизни. В том же C++ практически все возможности востребованны. Да и Java с C# сейчас уже не те, что были сначала. Но что объединяет их -- возможности языка расширяются по мере его использования. В Scala ситуация, имхо, пока не такая.

По поводу Java и JVM: имхо, и Oracle, и IBM, и еще целой куче больших и маленьких шараг выгодно сохранение стабильной JVM и стабильной Java. Но, при этом, кто-то может захотеть сделать для JVM более современный язык, интероперабельный с Java-библиотеками. Т.е. развитие Java будет заморожено. А соревноваться будут разные Scala и Clojure.

Skynin комментирует...

Plain C все-таки развивается. ... С99 ...
Java 7 также содержит приятные мелочи. Поэтому тоже пока к ней не относится - "уже перестал развиваться"

Кстати, мне понравились больше варианты изменений lcc-win32 и Limbo.

А что до монстров, то они возникают не от хорошей жизни.
Есть 2 противоположные концепции развития чего-либо: специализация-универсальность.

Монстры появляются от второго. А вот успех - от внешних условий, которые трудно оценить заранее.

Плайн Си как более специализированный выжил и успешен в системном программировании. Его оттуда - в обозримом будущем - ни один "универсал" не вытеснит. И развиваться принципиально, ему некуда - только... в сторону универсальности.

Универсал же, чтобы конкурировать с специализированным - вынужден обрастать всеми специальными возможностями. Отсюда - швейцарский нож и скальпель, ножницы, шило. Т.е. никто никого не победил. И возникли они все - от жизни+концепция. Хорошая/плохая была жизнь... трудно сказать.

Знаю из личного опыта - оконные гуи на плайн Си писать муторней чем на С++. (Си мой первый язык, и первая профессиональное программирование на нем было).

Да и Java с C# сейчас уже не те, что были сначала. Но что объединяет их -- возможности языка расширяются по мере его использования.
И так, и не так. они конечно меняются. Но как как указал выше - изменения могут привести к появлению монстра - а выгод для "основной среды обитания" не дать.
Тогда вполне может постигнуть судьба "perl", когда "убогий" специалист "php" - убивает расплывшегося от специальных возможностей универсала.

В Scala ситуация, имхо, пока не такая.
Потому что пока не прошел "проверку боем". Потому и расширения вызваны не реальной жизнью, а идеями о реальном применении "Одерски и Ко". И авторы же - мало прикладывют усилий для такой проверки обычными программерами.

Например я убедил бы руководство перейти на Scal'у. Но при таком уровне ошибок компилятора и библиотек - зачем же себе наживать проблем ?

Но, при этом, кто-то может захотеть сделать для JVM более современный язык, интероперабельный с Java-библиотеками.
К Java как ЯП это уже не имеет отношения. Нужно анализировать байт-код, и саму машину, их недостатки и ограничения. Нет в JVM сейчас invokedynamic - медленные реализации динамических языков получаются. А будут - быстрее, когда появится. Но код на JRuby останется таким же.
Так же и с поддержкой многопотоковости - actor'ы на JVM сейчас медленнее работают, чем на VM у Эрланга. Но если они будут в каком-либо языке сейчас, то и останутся.
Зато блокировка для синхронизации - на уровне базового класса Object встроена по синтаксису, и по реализации в JVM. И т.д.

То есть и сейчас никто не мешает с с помощью синтаксического сахара сделать более лучший чем Javа язык для JVM, но... с другой стороны, наверное и не делают, скажем C# для JVM, потому что возможности флагманского языка должны бы поддерживаться на уровне самой VM или CLR, а не "сахаром".

и Oracle, и IBM, и еще целой куче больших и маленьких шараг выгодно сохранение стабильной JVM и стабильной Java.
Да, и я так думаю, что конкуренция Jav'е не угрожает.

eao197 комментирует...

2Skynin: спасибо за столь развернутый и дельный комментарий. Все по теме. Нет смысла в чем-нибудь возражать.