Ответ на »сообщение 2519« (Geniepro)
___________________________

Ответ на »сообщение 2518« (Илья Ермаков)
___________________________
Однако Ваша фраза подразумевает, что программы на Хаскелле обязаны быть ненадёжными, глючными...
Это противоречит общепринятому мнению о Хаскелле...
У Вас есть какие-нибудь серьёзные основания считать, что Вы правы на этот счёт, или это просто боязнь новизны?
Чем плохо позволить программисту описать задачу в наиболее наглядном для него виде?
Нет, речь не о том, что "обязаны". Просто моему глазу показалось, что в языке есть темные закоулки и подводные камни, вызванные тем, что разработчики таки погнались за некоторыми "фичами". И реализации могут содержать скрытые ошибки, в частности, при оптимизации и т.п. Имеется ли набор тестов, который используется для проверки реализаций Хаскеля на корректность? Этот язык не столь прост, чтобы об этом не задуматься.
По поводу второго вопроса: по мне, к примеру, либо if, либо сопоставление с образцом, либо | - но что-то одно... Когда равноценных путей слишком много, возникает известная проблема буриданова осла.
В Обероне разработчик вместе с синтаксисом сразу "всасывает" единый стиль, общую идеологию, поэтому, кстати, легко разбираться в чужик исходниках. То же самое можно сказать про Ada, где единообразие было обеспечено не только языком, но и политикой стандартизации как военного языка.
А есть другой подход - "чтоб никого не обидеть, включим в язык все варианты". По мне лучше первый :-)

Ответ на »сообщение 2523« (Илья Ермаков)
___________________________
Now we are talking :)) Значит вы лукавили когда про ключи хаскелевского компилятора говорили.
в ББ тоже есть сложный отладчик. Только он не в компиляторе а в среде.



В дампе в ББ все состояние программы как на ладони, весь срез - щелкай мышкой по ссылкам-указателям, анализируй и думай, в чем ошибка.


Абсолютно тоже самое в java и в сишарп. Что вобщем то и немудрено - языки то одного уровня с обероном (как бы вам и не хотелось в этом признаться :)) )

Ответ на »сообщение 2522« (Jack Of Shadows)
___________________________

Нищета-с :)) Разработка таких сложных и громоздких программ стоит не один лимон долларов.

Несколько примеров.

Возможно, Вы знаете, что был в свое время очень солидный отладчик Logitech Multiscope Debugger (OS/2, Windows, MS-DOS) для Modula-2 (написан на Modula-2). То был отладчик для языка Modula-2 - более сложного, чем Oberon. Мало кто знает, что написал его иранец Mansour Safai - автор известного инструментария Visual Cafe (Java) компании Symantec. Сафаи был ведущим разработчиком в Logitech, а потом вице-президентом в Symantec (заодно там же - генеральным менеджером департамента инструментария для языков программирования и Интернета). К сожалению, он умер 9 февраля прошлого года в возрасте 43 лет.

Вот мнение одного весьма уважаемого эксперта: Pierluigi Zappacosta, one of the original founders of Logitech and friend of Safai for more than 15 years: “In areas such as interactive debugging of applications, Mansour and his teams have delivered the most innovative systems of the past decades.” Кстати, Сафаи был иранцем, но стал программистом экстра-класса и получил отличное европейское образование в Швейцарии (Ecole Poly-technique Federal de Lausanne).

Другой отладчик VID для языков TopSpeed-семейства (C, C++, Pascal, Modula-2, Clarion) написан на Modula-2 (как и все компиляторы, и IDE).

Стоимость разработки отладчика - не миллион долларов, несколько меньше :) Но и не 5 тысяч.

Поэтому языкам обласканным финансовым вниманием толстосумов (дельфи, vb, java) повезло.

Не совсем верный тезис. Отладчики Оберонам, разумеется, не помешали бы. Но в любом деле надо понимать, зачем оно (это дело) делается, и какова цена вопроса. Для Оберона отладчик нужен еще в меньшей степени, чем для Modula-2, а для нее - много меньше, чем для C++. Уж такие это языки, что отладчик здесь сильно вторичен. Новосибирцы для XDS отладчик не делали, а свели к решенной задаче - генерировали код под внешние распространенные отладчики (CodeView). Вполне разумный подход.

Ответ на »сообщение 2522« (Jack Of Shadows)
___________________________
По поводу отладки в Обероне...
Джек, я по "долгу службы" сейчас работаю как с проектами на BlackBox, так и с проектом на С++ (Visual Studio). После ББ я плююсь на отладчик студии.
В дампе в ББ все состояние программы как на ладони, весь срез - щелкай мышкой по ссылкам-указателям, анализируй и думай, в чем ошибка. В Цешных/Дельфовых/etc средах без метаинформации такое удобство не обеспечишь - вот и приходится, высунув язык, гонять пошагово... А если приходится работать в Studio 6.0, где даже std::string по-человечески не раскрываются... В плане легкости отладки Студия с Обероном и рядом не стояла.

Ответ на »сообщение 2510« (Илья Ермаков)
___________________________
Не надо утрировать,
Правильно, утрировать не надо, ни мне ни вам. :))
Вы начали с укола в сторону хаскеля, мол де полсотни отладочных ключей в компиляторе означает что программы на хаскеле ужасно глючны, раз требуют такого компилятора. Это утрирование. Это выдирание из контекста.
Прежде все процесс отладки - работа необходимая и сложная. Работа требующая мощных и сложных инструментов.
И как следствие такие вот мощные и сложные инструменты существуют и для императивного подхода и для функционального. Но они разные.

ИП:
Сложные инструменты отладки существуют в виде программ поверх компилятора, то есть в виде сред. Дельфи, MS VS, Eclipse - все это мощные и очень сложные инструменты отладки, с возможностью остановки программ в выбранных точках, пошаговым исполнением, десятками окон для обзора значений переменных, стека вызова функций, дизассемблера, модулями удаленной отладки, профилировщиками.
Потому компилятор особенно отладно не нагружен.

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

Вопрос: Почему нет адекватных средств отладки для оберона ?
Ответ: Нищета-с :)) Разработка таких сложных и громоздких программ стоит не один лимон долларов.
Поэтому языкам обласканным финансовым вниманием толстосумов (дельфи, vb, java) повезло.
А оберону - нет.
Только вот не надо сейчас начинать "я ошибок не делаю и мне отладчик не нужен".
А то потом трудно будет спорить с Сергеем Перовским которому не нужен сборщик мусора :))

Вечный вопрос - есть ли в программировании место искусству?

Можно ли позволить программам быть произведениями искусства, писать стихи на языке программирования?
Или программы должны быть написаны по нескольким шаблонам бульварной прессы?

Программы на Хаскелле подобны хайку - несколько строк, а сколько в них глубинного, потаённого смысла, который может обсуждаться веками...
Этим он (Хаскелл) и отличается от тяжеловесного, грубоватого Оберона, и от корявого С++...

____________________

Если сравнивать программистов с солдатами, то мне в голову приходят такие аналогии:

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

Программист на С++ - морской котик, который либо разоберётся в премудростях своей профессии, либо погибнет...

Программист на Хаскелле - снайпер, ворошиловский (или альпийский) стрелок, выстрел которого не имеет права на ошибку...

Ответ на »сообщение 2518« (Илья Ермаков)
___________________________

И вновь вместо языка - компактного и безотказного инструмента имеем сундук с abilities, possibilities & features...

Самый компактный язык (из промышленно используемых, брейнфаки не в счёт) - это, пожалуй, Лисп/Scheme. Несмотря на обширность их библиотек (к языку они не относятся - это окружение языка), сами эти языки - очень просты и компактны...

Ответ на »сообщение 2518« (Илья Ермаков)
___________________________

И вновь вместо языка - компактного и безотказного инструмента имеем сундук с abilities, possibilities & features...

Да, мы уже убедились, что правоверные оберонщики должны быть аскетами и пуританами... :о)
Хоть и находятся даже среди них люди, грешащие Зонноном, но они не в счёт, верно? ;о)

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

Однако Ваша фраза подразумевает, что программы на Хаскелле обязаны быть ненадёжными, глючными...
Это противоречит общепринятому мнению о Хаскелле...
У Вас есть какие-нибудь серьёзные основания считать, что Вы правы на этот счёт, или это просто боязнь новизны?


"Haskell's choise: provide multiple ways, and let the programmer decide".

Чем плохо позволить программисту описать задачу в наиболее наглядном для него виде?

Ответ на »сообщение 2514« (Geniepro)
___________________________

Ответ на »сообщение 2510« (Илья Ермаков)
___________________________

Выдержка из Simon Peyton Jones. "Wearing the hair shirt. A retrospective on Haskell" (стр.15) :

Tony Hoare’s comment “I fear that Haskell is doomed to succeed” ("Боюсь, Хаскелл обречён на успех")
"Haskell's choise: provide multiple ways, and let the programmer decide".
И вновь вместо языка - компактного и безотказного инструмента имеем сундук с abilities, possibilities & features...

Ответ на »сообщение 2516« (AVC)
___________________________
Хоар вроде бы сейчас занимается как раз-таки ортогональным к ФП подходом - развитием методов автоверификации и доказательства императивного кода. На мой взгляд - для практики самый перспективный подход. И оберонщики здесь тоже на месте не стоят, хе-хе ;)