Zorko писал(а):
Вот тебе список решаемых мною повседневно задач. Он покажет, насколько мне подходит Хаскел. И не сделал ли я ошибки, выбрав Оберон. Но учти, мне нужен универсальный язык, а не узкоспециализированный. И я предпочту решать его проблемы, а не уходить на другой язык, который не решит моих проблем даже в малом.
- Делать веб-сайты на Хаскелле уж всяко проще, чем на обероне -- есть куча библиотек для этих целей, веб-серверов, фреймворков.
Вот недавно на русской лямбда-планете прошло сообщение "Минимальный yesod сайт для публикации на keter" о каком-то инструменте для упрощения деплоймента веб-сайтов для веб-фреймворка Yesod.
Как такие сайты запускать на стандартных лампах (LAMP -- Linux+Apache+MySQL+PHP) -- я не в курсе, не интересуюсь этой темой. Если есть возможность запустить исполнимый файл для винды или линукса -- то какие могут быть ещё проблемы?
- Для создания программ с GUI хаскелл подходит хуже, чем дельфы, вижуал бейсик и C#, но всё же есть и обвязки для GTK, QT, wxWidgets
- Микроконтроллеры? Ретро-платформы? Увы, никак, это слишком узкая область, что бы этим заморачивался кто-то кроме тебя да ещё нескольких людей на планете.
- Есть какие-то наработки для интеграции с Java, но сомневаюсь, что бы они помогли тебе в этом вопросе.
Насчёт iOS: "iPhone, встречай Haskell".
Есть какие-то наработки для Андроида, но в данное время меня эта тема мало интересует.
- Этот вопрос я не понял. Знание Хаскелла помогает хотя бы расширением кругозора -- это уже немалая польза. Иначе смотришь на те же задачи -- велик шанс найти решения получше.
Если человеку хватает бейсика, ну что ж, можно за него лишь порадоваться.
Zorko писал(а):
Сколько лет мне надо учиться в университете на матфаке, чтобы оценить преимущества функционального программирования перед императивным и Хаскела перед Обероном?
Для изучения Хаскелла нужно не больше, чем для изучения Оберона. Где ты нахватался ложных сведений о завышенном пороге изучения Хаскелла? Тут так же как с изучением ООП -- лишь старые привычки могут помешать, отсутствие же таковых облегчает изучение.
Zorko писал(а):
Учти, груз платформенных особенностей платформ, для которых я программировал, и фишек/тонкостей синтаксиса и семантики языков, которые я использовал в течение жизни, лежит в моём мозге с ограниченным количеством нейронов. Именно этот груз мешает мне. Мои нейрончики заполнены не сопроматом, дифференциальными уравнениями и теорией графов, а вот этим грузом, уже бесполезным. И отформатировать бы рад, но как?
Человеческая память имеет свойство со временем стираться, так что как только начнёшь изучать что-то новое -- старое будет уходить само по себе. И вообще ты как-то уж слишком драматизируешь. ))
Zorko писал(а):
А вот Оберон-2/КП (в той или иной конечно степени) — уже гораздо более серьёзный кандидат на решение моих задач. Да, я сейчас решаю их на PHP/Си/Delphi/FreePascal/ассемблер, но очень не против решать их все на Обероне. Дело за малым. Потенциально среда XDev на базе модифицированного Оберона сможет помочь решать все эти проблемы. Даже трансляцию Оберона в PHP можно будет сделать, хотя это конечно плохая идея.
Потенциальные возможности -- это, конечно, здорово, только как они помогают тебе в реальности?
Ты утверждаешь, что Оберон гораздо лучше подходит для тебя, чем Хаскелл, хотя тут же признаёшь, что пока он тебе всё равно не помогает...
Zorko писал(а):
geniepro писал(а):
В серьёзных же проектах может иметь значение распределение обязанностей между программистами, например. И здесь definition-модули из модулы-2 или ады гораздо полезнее, чем упрощённый экспорт из обероновских модулей...
Что же именно удобнее? Перечислять импортированные процедуры по одной списком? Вообще же, насколько я помню, интерфейсы Модулы не генерятся автоматически как в Обероне, т.е. их надо создавать ручками как сишные хидеры. Получим рассинхронизацию интерфейса с реализацией и т.п. В чём же здесь преимущество? По-моему, ты недостаточно хорошо понимаешь экспорт Оберона, он проще, но совершеннее модуловского. Кроме того, здесь решён эргономический аспект: зачем при коллективной разработке нескольким людям работать одномоментно над одним модулем?
Особенности модулей Оберона подчёркивают их направленность для работы одиночек или сверхмалых команд из нескольких человек.
Идея definition-модулей не в том, что они должны генерироваться из тела модуля (implementation-модуль), наоборот, это тело модуля должно генерироваться из спецификации модуля (definition-модуль). Архитектор проекта распределяет обязанности между участниками проекта, раздаёт им спецификации модулей, а затем компонует получившиеся у них реализации модулей в единую программу.
И в таких задачах весьма полезны иерархические модули.
К сожалению, в Хаскелле, несмотря на наличие иерархических модулей, нет выделенных спецификаций модулей, есть упрощённый вариант экспорта типа интерфейсной части юнитов в Дельфях. Но даже такой вариант лучше, чем вообще отсутствие его.
В оберонах можно получить список экспортируемых модулем сущностей, но этот список ни на что не влияет и полезен разве что только для документирования модуля...