Вышел ocaml 3.09.3

> т.е. сложение двух матриц делать в в функциональном стиле не очень удобно, в имперятивном код-то и попроще и делается побыстрее

Это скорее дело опыта. Мне такие вещи в функциональщине писать проще.

> Жаль только синтаксис у ocaml убогий... Брали бы лучше пример с clean.

Хотелось бы узнать в чем проявляется убогость? Желательно с кросс-примерами с clean.

Он сам по себе.

Что за идея сравнивать ocaml с haskell? У языков разные цели, ocaml _не_ стороается быть чистом ФЯ... Он скорее просто смесь и своеборазный французский стёб.

Но согласись, что лучше делать алгоритм в том стиле, в котором он написан.

> Хотелось бы узнать в чем проявляется убогость? Желательно с кросс-примерами с clean.

1. Почитайте Clean Book. 2. Хочу заметить что убогость - это все на уровне восприятия нравится/не нравится. Мне нравятся языки на которых я могу думать. С ocaml так не получается. Постоянно приходится напрягать мозг на тему как пишется то или иное действо.

> У языков разные цели, ocaml _не_ стороается быть чистом ФЯ... Он скорее просто смесь и своеборазный французский стёб.

ну если его рассматривать чисто как стеб, тогда наверное да
а так:

0) не стандартизирован

1) перегрузка aka классы типов отсутствуют
+ плюс отсутствует неявного приведения типов ...
достаточно нервно писать постоянно (a +. b) /. (float_of_int с)
получается крайне громоздко

2) хвостовая рекурсия присутствует
но предсказать что она __не будет_ использована - невозможно
пример - зависание при рекурсивном вызове метода .... кто бы мог подумать что методы не раскрываются по хвостовой рекурсии

3) полное отсутствие нормальных ООП библиотек

4) бред с модульностью и ООП - два эквивалентных механизма
присутствуют оба и оба через задницу (ООП до сих пор experimental)
т.е - ни богу свечка ни черту кочерга

5) объектная модель смолтолковская, но отсутствуют механизмы типа sendMessage
есть забавные возможности pattern matching по типам
но зачем ... хотя пару элементов можно использовать - выглядит забавно

6) выведение типов - чудо в перьях
смешно когда компилятор пытается тебе доказать, что в выражении
let x = new my_object
x имеет тип не my_object, а что то другое ....

7) шаблоны, объекты и выведение типов и можно потратить час на разгадывание сакральных высказываний компилятора

8) не удобный синтаксис шаблонов - в разных местах одна и таже семантическая конструкция записывается по разному синтаксически, можно потратить достаточно много времени на разбор типа - "что за фигня" и это повсеместная болезнь окамля - синтаксические излишества

9) попытка использовать хваленый p4 приводит к истерике
так как достаточно сложно понять что бы это значило
let a, _, b = nodeZuZu x .....
и это повсеместная болезнь камля - использовать однобуквенные имена и имена типа - eprst

10) слишком умный сборщик мусора - наверное,
очень сильная деградация скорости при усложнении типов данных
по наблюдениям быстро считаются только числа фибоначи
все остальное значительно хуже
на деревьях можно полчить деградацию раз этак в десять (чем тот-же с++)

сюда еще можно добавить многословность как следствие откровенно хренового name scoping

постоянно писать
may_var.SomeGoodModule.prefix_for_difference_fieldOfVar1 <- value1;
may_var.SomeGoodModule.prefix_for_difference_fieldOfVar2 <- value2
ужасно

> 0) не стандартизирован > 3) полное отсутствие нормальных ООП библиотек

Это дело времени, надеюсь. Все с чего-то начинали.

> 1) перегрузка aka классы типов отсутствуют + плюс отсутствует неявного приведения типов ... достаточно нервно писать постоянно (a +. b) /. (float_of_int с) получается крайне громоздко

Да, не компактно - факт. Но привыкаешь быстро и потом особых неудобств не чувствуется (у меня по крайней мере).

> 4) бред с модульностью и ООП - два эквивалентных механизма присутствуют оба и оба через задницу (ООП до сих пор experimental)

Специально для меня проясните пожалуйста в чем это проявляется (я действительно не в курсе :))

> 6) выведение типов - чудо в перьях смешно когда компилятор пытается тебе доказать, что в выражении let x = new my_object x имеет тип не my_object, а что то другое ....

Можно живой пример ? (я с ocaml'ем недолго знаком, и пока такого не видел. нужно быть ко всему готовым :))

>> 0) не стандартизирован > 3) полное отсутствие нормальных ООП библиотек

>Это дело времени, надеюсь. Все с чего-то начинали.

возможно
но на с++ примерно в таком же возрасте уже было несколько независимых реализаций, если следовать хронометражу приблизительно года через 3 должен выйти стандарт на ocaml - вы уверены что выйдет ?

>> 1) перегрузка aka классы типов отсутствуют + плюс отсутствует неявного приведения типов ... достаточно нервно писать постоянно (a +. b) /. (float_of_int с) получается крайне громоздко

> Да, не компактно - факт. Но привыкаешь быстро и потом особых неудобств не чувствуется (у меня по крайней мере).

дал простых типов еще ладно - такие выражения встречаются не так часто, но вот для классов постоянно писать (my_var :> parentClass) - муторно

>> 4) бред с модульностью и ООП - два эквивалентных механизма присутствуют оба и оба через задницу (ООП до сих пор experimental)

> Специально для меня проясните пожалуйста в чем это проявляется (я действительно не в курсе :))

да ни в чем это не проявляется в том то и дело, просто две слабо пересекающиеся системы типов, нужны объекты и интервейсы - делаешь ООП
- теряешь возможности модульной системы, делаешь модули получаешь функторы, но теряешь объекты и интерфейсы - просто досадно

>> 6) выведение типов - чудо в перьях смешно когда компилятор пытается тебе доказать, что в выражении let x = new my_object x имеет тип не my_object, а что то другое ....

> Можно живой пример ? (я с ocaml'ем недолго знаком, и пока такого не видел. нужно быть ко всему готовым :))

напиши два одинаковых класса (наследники базового) и создай объект попробуй с ним поработать, там его еще здоровски клинить начинает, он упорно не тот тип пытается подставить - если честно не помню точно конструкцию, помню только изумление и мысль "где ж тебя переклинило дорогой, где ж тебе тип подсказать" после этого стал придерживаться правила - тип нужно объявлять всегда (ну кроме локальных определений - ибо лень :)

> напиши два одинаковых класса (наследники базового) и создай объект попробуй с ним поработать, там его еще здоровски клинить начинает, он упорно не тот тип пытается подставить - если честно не помню точно конструкцию, помню только изумление и мысль "где ж тебя переклинило дорогой, где ж тебе тип подсказать" после этого стал придерживаться правила - тип нужно объявлять всегда (ну кроме локальных определений - ибо лень :)

хе-хе... это мы уже постигли - верное правило.. и тоже привыкли... обьявляем и не мучаемся :))

> да ни в чем это не проявляется в том то и дело, просто две слабо пересекающиеся системы типов, нужны объекты и интервейсы - делаешь ООП - теряешь возможности модульной системы, делаешь модули получаешь функторы, но теряешь объекты и интерфейсы - просто досадно

можно подробнее, а то я чего-то не пойму. а кто запрещает использовать одновременно ? Никто же не запретил запихать пару-тройку классов внутри модуля и т.п. ?

> но на с++ примерно в таком же возрасте уже было несколько независимых реализаций Ну их те реализации. Нас и одна устроит, была бы качественной.

> если следовать хронометражу приблизительно года через 3 должен выйти стандарт на ocaml - вы уверены что выйдет ?

С чем черт не шутит ? А вдруг ? :))

> хе-хе... это мы уже постигли - верное правило.. и тоже привыкли... обьявляем и не мучаемся :))

и нафиг тогда выведение типов ? плохо когда такое дело вопрос стиля

> а кто запрещает использовать одновременно ? Никто же не запретил запихать пару-тройку классов внутри модуля и т.п. ?

можно - громоздко получается
основной вопрос зачем иметь две системы типов, непересекающихся но в принципе эквивалентных, хотелось бы одну, но общую с возможностями и той и той. Зачем лишняя работа по склеиванию ?

>> но на с++ примерно в таком же возрасте уже было несколько независимых реализаций

> Ну их те реализации. Нас и одна устроит, была бы качественной.

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

>> если следовать хронометражу приблизительно года через 3 должен выйти стандарт на ocaml - вы уверены что выйдет ?

> С чем черт не шутит ? А вдруг ? :))

ANSI - точно нет
ISO - тоже нет
можно как Microsoft - в ECMA ? :)))

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

> я не говорю что камл плохой язык - забавный, есть очень интересные вещи. но это не "промышленный" язык, пока что экспериментальный.

Промышленные языки в наше время С++/Java/PHP ? :)) Согласен, в массы он не пойдет, однако для определенного круга задач в определенной среде он уже сейчас вполне примемлем. Будем ждать, время покажет.

> нет - нет диалога - нет развития да и настораживает это - нет реализаций - никому не нужно - плохой язык .... получается местячковая вещь

Ну, того же haskell'я тоже всего одна живая реализация (ghc, если я не ошибаюсь). У common lisp их куча, вот только толку с этого нет никакого, ибо у каждой из них куча своих заморочек (большая часть библиотек хорошо если на 2-3 работает) и реальной переносимости (для начала Win/Lin) я пока не смог добиться хотябы от одной (про комерческие молчу - не наши методы), хотя лиспу уже лет и лет :(( У С++ много компилеров, но я что-то очень сомневаюсь в легкости написания кода, который будет действительно переносимым (хотя точно не знаю ибо на С++ ничего кроме hello-world не писал). Java ? я в свое время хороший секс поимел с реализациями SUN/Blackdown - спасибо, больше не хочется.

Так что вряд-ли количество реализаций является большим плюсом, скорее рождает еще большее количество костылей и несовместимостей.

> Ну, того же haskell'я тоже всего одна живая реализация (ghc, если я не ошибаюсь).

Ну не только GHC, другие компиляторы тоже развиваются (yhc, jhc), да и hugs тоже.

>> Ну, того же haskell'я тоже всего одна живая реализация (ghc, если я не ошибаюсь).

>Ну не только GHC, другие компиляторы тоже развиваются (yhc, jhc), да и hugs тоже.

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

ЗЫ: анонимус выше своими замечаниями по поводу недоделок в Окамле отбил всякую охоту посмотреть на него более близко.

> Ну не только GHC, другие компиляторы тоже развиваются (yhc, jhc), да и hugs тоже.

То что они есть я знаю, но то что их кто-то использует не знал.. теперь буду :)

> Ну не только GHC, другие компиляторы тоже развиваются (yhc, jhc), да и hugs тоже.

Hugs - This small, portable Haskell interpreter written in C. Ключевое слово interpreter. Jhc - is an experimental compiler with a goal of testing new optimization methods and exploring the design space of haskell implementations.

Слова interpreter и experimental портят картину в плане разработки реальных проектов.

Про yhc: This project is by no means finished, and is not useable as a standard Haskell compiler yet. This project is run by 3 York [ex-]students, and is not an official York Uni project. Что тоже делает его непригодным :))

Итого: имеем GHC is the defacto standard compiler if you want fast code. Зачем тогда остальные ? :)

> пхп/руби/питон/перл имеют только одну реализацию и никто по этому поводу не комплексует.
ну у питона и руби реализаций хватает

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

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

> тема "надежности" языка не раскрыта :)) на самом деле
"надежность" в том что не зависиш от одной единствиной реализации (там с патентами проблемы, афтору надоело/нашелчеминтереснейзанатся, спосорзабил, ...)

> о какой толк от них если переход с одной на другую влечет за собой переписывание кода и игру в "найди десять отличий" ?
не все так плохо, обычно грабли либо в экзотических фичах, либо в библиотеках и в половине случаев виноват сам.
или лучше чем все переписывать на другом языке когда станет ясно что текущая реализация не перспективна ?

> А именно так зачастую и получается. :(
получается как получается, но алтернативные реализации просто так не возникают, там обычно обкатывают новые решения и идеи, лучшие из которых будут приняты и дополнят другие реализации.

> "надежность" в том что не зависиш от одной единствиной реализации (там с патентами проблемы, афтору надоело/нашелчеминтереснейзанатся, спосорзабил, ...)

С этим конечно трудно не согласиться.

> не все так плохо, обычно грабли либо в экзотических фичах, либо в библиотеках и в половине случаев виноват сам. или лучше чем все переписывать на другом языке когда станет ясно что текущая реализация не перспективна ?

Да нет, бывают еще разные степени поддержки стандарта (если таковой имеется) этими самыми реализациями. Да и заточка библиотек под новую среду может превратиться в тот еще безсонный месяц.

> получается как получается, но алтернативные реализации просто так не возникают, там обычно обкатывают новые решения и идеи, лучшие из которых будут приняты и дополнят другие реализации.

Угу, а посему сидим и решаем, будем ли мы использовать те или иные фичи реализации или нет.. А когда начинаем использовать, понимаем, что аффтар урод и завел нас в тупик. Тогда убегаем на другую реализацию, переписываем несовместимые моменты и портируем необходимые библиотеки. В результате чего проклинаем создателя языка, сам язык, тех кто писал реализации и библиотеки, берем книгу по ПЫХу быстро переписываем свое творение на нем, потом приходит шеф, надирает нам зад и увольняет с работы из-за того, что в бюджет конторы не входили кластера на которых наш софт сможет работать. :)))

Веселая шутка конечно, но доля правды тут присутсвует. Плохо это, когда нет совместимости...

>Итого: имеем GHC is the defacto standard compiler if you want fast code. Зачем тогда остальные ? :)

Ну хочется людям - чего тут такого?

> Когда не хочешь делать рекурсии очень удобно -- компилятор ткнет мордочкой в месте где появилась рекурсия, которую не хотел.

Так компилер, на сколько я знаю, генерит одинаковый код что для let, что для let rec. Зачем делать такое синтаксическое отличие, если семантика одна и та же - некошерно как-то ...

// satanic-mechanic