Состоялся очередной релиз языка программирования Scala – версия 2.8.1. Это баг-фикс релиз, закрывающий несколько десятков багов.
Скачать новую версию можно здесь.
PS. Сколько слежу за релизами Scala, столько не могу понять: откуда такие большие списки ошибок? Или это очень сложный проект, или процесс разработки там какой-то не устоявшийся, или руки у программистов… Смотришь, бывает, на список закрытых проблем и думаешь: “Да, функциональное программирование явно способствует уменьшению количества багов!” ;)
тут вероятно 2 момента:
ОтветитьУдалить1. одерски не разложил язык по хорошему базису; примерно как в русском языке разложить 100000 слов по (сколько-их-там) слогов не так удобно, как по 33 буквам
2. ну и объективно -- как в правописании возникают ошибки, ведь не всегда ясно, какая буква должна быть в слове
но че-то 4000 багов меня тоже смущает... язык нужен все же попроще или помодульнее
вот интересный тикет http://lampsvn.epfl.ch/trac/scala/ticket/36
ОтветитьУдалитьтут он похоже попал на (ну ладно, не всем) известную проблему ООП "треугольник как потомок многоугольника с неизветным числом сторон"
некоторые используют такой паттерн, и при известной аккуратности все ОК; поэтому, видимо, и type changed from defect to enhancement
но можно и нарваться
короче тут видимо ООП как раз и не разложено по должному базису; вместо того, чтобы разложить, принимаются специальные решения для конкретных случаев
и кто-то, например, юзавший тот паттерн, может завопить "нет, верните тикет 36 обратно, мне это нужно"
ОтветитьУдалитьесли мои многабукав не ясны, то вот вывод: проблема в отстутствии модели языка и спецификации языка, а в стиле "а-ля функциональное программирование"
* а не в стиле "а-ля функциональное программирование"
ОтветитьУдалитьи если бы одерски писал компилятор для чистого ФП-языка, то тикета 36 не было бы вообще
ОтветитьУдалитьтак что виновато не ФП, а отстутствие модели для гибрида ООП и ФП
Про ФП я упомянул в том смысле, что апологеты ФП любят кричать, что ФП чуть ли не в разы сокращают количество ошибок в программах. А тут компилятор Scala, который как раз ФП-гуру написан, содержит большое количество ошибок вида "compiler crash".
ОтветитьУдалитьНу и не понятно мне, как можно делать стабильный релиз компилятора (компилятора! ведь это же достаточно строго формализованная штука) в котором затем обнаруживается большое количество compiler crash-ей. И так от релиза к релизу.
ну, если огрубить, то одерский пишет компилятор из Неизвестно Чего в байт-код jvm, и поэтому "достаточно строго формализованная штука" не помогает
ОтветитьУдалитьвот, допустим, на с++:
template< class T > class Vector { ... }; // вектор любой длинны
template< class T, uint n > class NVector: public Vector< T > { ... }; // вектор любой длинны n
что ты скажешь про такое?
@имя:
ОтветитьУдалитьа что я тут должен сказать? Насколько я понимаю, компилятор Scala по сложности не может сравниться с оптимизирующими компиляторами C++, которые генерируют нативный код. Поскольку изрядного количества вещей он не делает, оставляя на откуп JVM и HotSpot.
Но все равно компилятор ломается даже на маленьких программах (http://lampsvn.epfl.ch/trac/scala/ticket/3570). Что-то для C++ такие случаи не припоминаются.
Просто они неправильно выбрали язык для написания компилятора, надо было скалу писать на окамл и было бы как тут http://caml.inria.fr/pub/distrib/ocaml-3.12/notes/Changes всего три "compiler crash" более чем за десять лет :))
ОтветитьУдалитьжцц тоже бывает падает на ровном месте, вот простецкий код без единого шаблончика:
ОтветитьУдалитьhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=40975
( Reported: 2009-08-05 )
это я нашел под заказ, а так гуляя по инету встречал вполне себе короткие и недревние примеры
теперь на тему ФП
так как я не фан ФП, то смысл ФП вижу в подходах, которые оно делает удобными (а кто-то сказажет навязывает) -- в подходах и методах к построению модели предметной области
если же предметная область нуждается в построении ее формальной модели и формальной верификации модели (как, имхо, у одерски) -- то ФП конечно не спасет
однако часто ли обычные программисты встречаются с необходимостью формальной верификации модели, непроводимой компилятором?
с другой стороны ( http://lampsvn.epfl.ch/trac/scala/changeset/22457 ) читаем:
See #3570 for an example of how target.tpe can be non-null, yet it claims not to have a mmeber called nme.EQ. Not sure if that should happen, but we can be robust by dragging in Any regardless.
Значит, компилятор тупо молчит, предоставляя человеку ошибаться и быть "Not sure". Такой язык никуда не годится (или по крайней мере такой стиль программирования).
> всего три "compiler crash" более чем за десять лет
ОтветитьУдалитькомпилятор окамла, написанный на скале, крэшился бы не сильно больше
и компилятор скалы, написанный на окамле, крэшился бы не сильно меньше
вообще я согласен с идеей, что язык должен быть построен на небольшом количестве ортогональных принципов
ОтветитьУдалитьтогда, конечно, компилятор с этого языка будет безбажный (а-ля компилятор c окамла)
дальше, необходимо построить соответствие этих принципов и конструкций ООП -- тут вот начнуться баги именно в *соответствии*; если это делать, как одерски, параллельно с построением компилятора -- естественно, компилятор начнет глючить, причем независимо от языка, на котором он написан
ну или вот еще простенький крэш для жцц:
ОтветитьУдалитьstruct A {};
struct B : A, A {};
struct B : A, A {};
выхлоп: < ... > Preprocessed source stored into /tmp/cc66ty9f.out file, please attach this to your bugreport.
@имя
ОтветитьУдалитьНа Ocaml немало компиляторов написано например http://coq.inria.fr/ Скале и фору может по сложности дать, но крешей тоже не видно http://coq.inria.fr/V8.3/CHANGES
Я думаю причина как раз в том что скрестили ужа и ежа, то есть ООП и ФП и на этой смеси пишут и сам компилятор, OCaml хоть и такой же гибрид но при написании компиляторов ОО практически не используется, и очень много кода именно в чисто функциональном стиле. А в таких задачах он рулит, и на порядок надежнее императивного.
> например http://coq.inria.fr/ Скале и фору может по сложности дать, но крешей тоже не видно
ОтветитьУдалитья говорил (вроде как везде) не о сложности, а о внутренней непротиворечивости модели; грубо говоря, у coq модель верифицировалась математиками последние 120 лет и трудностей в реализации не представляет; у ООП же есть зияющие дыры типа "квадрат не есть прямоугольник"
Однако Скала почти на порядок больше крешится чем даже хаскель (которому с его ленивостью сам бог велел :) )
ОтветитьУдалитьhttp://hackage.haskell.org/trac/ghc/search?q=compiler+crash&noquickjump=1&ticket=on&milestone=on
http://lampsvn.epfl.ch/trac/scala/search?q=compiler+crash&noquickjump=1&ticket=on&changeset=on
@имя
ОтветитьУдалитьПо моему при большей внутренней противоречивости компилятор просто должен чаще выдавать "unknown error" а не вылетать.
@имя:
ОтветитьУдалитьне корректно сравнивать GNU GCC, который написан на чистом C и которому уже лет 25 от роду с компилятором Scala2 (четыре года от силы и написан на самой Scala).
насчет си -- согласен; по-хорошему надо сравнивать с clang -- в его багзиллу я загляну, но щас лееееень
ОтветитьУдалить