Ответ на »сообщение 3875« (Руслан Богатырев)
___________________________

В этой связи тот же Хаскель имеет смысл воспринимать не просто как технологический феномен, а как реальный объект для применения маркетингового потенциала Microsoft в ее конкурентной борьбе.

Надеюсь, что так оно и есть. Если Хаскелл войдёт в промышленность как полноценный инструмент, с которым нельзя не считаться - то имхо это только к лучшему. Это лучший вариант развития.
Какой бы ужастной ни казалась Microsoft, но эта фирма смогла поставить себя на роль лидера, с которым считаться будут ещё десятилетия...

Главное, вспомнить основное правило обероновских модулей: "No poronoia!"

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

К примеру, интерес Микрософта к исследованиям в Цюрихе, попытки "перетаскивания" на дотнет, их импровизации на тему "Оберон-скрипт"

Илья, думаю, тут нет поводов для беспокойства. Интерес Microsoft к Цюриху вызван желанием взять под свой контроль столь престижный европейский университет: здесь интересы пересеклись. Вирт был возмущен поведением Sun, и дружба с Microsoft -- небольшая месть. Гуткнехт заинтересован пробить в массы идеи Оберонов. Он сделал ставку на Zonnon под .NET. Определенную известность это принесло. Но пока "рентабельность" низкая -- интеллектуальные затраты (с некоторым отходом от базисных идей Оберона) не соответствуют ожиданиям поддержки Microsoft. Что касается OberonScript, то это "дерзкая" инициатива одного ученика Вирта -- Ральфа Соммерера, который с 1998 г. работает в европейском отделении Microsoft Research в Кембридже.

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

Обратите внимание, что в последние годы Microsoft по линии образования и науки все больше внедряется в Европу через Великобританию. Как говаривал персонаж известного мультфильма, "это ж-ж неспроста". В этой связи тот же Хаскель имеет смысл воспринимать не просто как технологический феномен, а как реальный объект для применения маркетингового потенциала Microsoft в ее конкурентной борьбе. Думаю, это стоит иметь в виду, как ярым стороникам ФП (отсюда можно извлечь свои плюсы), так и "сторонним наблюдателям" из другого лагеря (того же Оберона).

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

Может быть подскажите, как квалифицированный импорт сочетается с "системностью" Oberon? Поясню. В теории систем есть понятия "сильных" и "слабых" связей. "Сильные" связи образуют элементы системы, а "слабые" связи соединяют элементы.

В программировании "сильные" и "слабые" связи как раз и находят свое выражение в модульности.
Сильные связи -- внутри модуля (high cohesion; принцип "No paranoia rule" Клеменса Шиперски).
Слабые связи -- между модулями (low coupling).
Модульность как софтверный принцип, видимо, впервые была явно введена Парнасом и не всеми была сразу понята (см., например, известную книгу Брукса "Мифический человеко-месяц").
Метрика coupling/cohesion для оценки качества ПО была введена Stevens, Myers, Constantine на основе анализа ряда софтверных проектов в IBM.
http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
http://en.wikipedia.org/wiki/Coupling_%28computer_science%29
Главное, это прямо соответствует принципам системного подхода.

Применительно к обсуждаемому вопросу. Если программист явно указывает связи между модулями, то он поступает... противоестественно, поскольку на уровне отдельного модуля решает вопросы системообразования.
Правильное, с позиции теории систем, решение это декларировать потребности (импорт) и возможности (экспорт) в терминах интерфейсов. А что система "подставит" в качестве "поставщиков" или "потребителей" услуг (сервисов), это ее дело, но никак не прикладного программиста. Уточню, реальный "поставщик" и/или "потребитель" услуг может меняться (в runtime, в том числе) в зависимости, например, от состояния системы. А разработчик модуля ни о самой системе, ни о ее состояниях... знать не должен.

Слава Богу, хоть кто-то понимает эту потребность!
А то нас, бедных оберонщиков, прямо заклевали за то, что мы считаем это важным.
Что обидно, заклевали лучшие оппоненты!
Сергей Перовский заявил, что для него это замена реализации на лету не представляет ценности, а Евгений (Geniepro) прямо назвал соответствующие обероновские механизмы "сомнительными".

По сути предлагаемых Обероном механизмов.
В Обероне экспорт модуля может использоваться как место коммутации.
Это разъясняли как Руслан Богатырев, так и Илья Ермаков -- например, в статье
http://oberoncore.ru/download/articles/DesignIdeas.pdf
Модуль экспортирует "гнездо" коммутации (процедурную переменную, указатель на фабричный объект и т.д.), система может "на лету" подключить туда ту или иную реализацию функциональности, загрузив дополнительный настроечный, "теневой" :) модуль, явно не импортируемый другими модулями. Благодаря такой организации, этот модуль может быть заменен на другой, после чего его можно даже просто выгрузить.
Возможно, обероновские механизмы модульности здесь несовершенны и могут быть улучшены.
Но они все же позволяют решать данную задачу, при сохранении простоты языка и программной архитектуры.

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

Другие связи выстраиваются динамически на основе разъемов. И разновидностей таких разъемов весьма много. И описываются эти разъемы как раз-таки в терминах интерфейсов (абстрактные записи).

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

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

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

Ответ на »сообщение 3856« (ASU)
___________________________
4) Инсталлируемые каталоги. "Лицевой" модуль сервиса определяет абстрактные интерфейсы для этого сервиса и предоставляет инсталлируемую точку доступа к фабрике объектов, реализующих эти интерфейсы. Модули реализации динамически инсталлируют фабрики в "лицевые" модули.
Замечу, что во всех этих схемах ООП является служебным механизмам, а не системообразующей схемой. В частности,
Да, конечно, забыл еще один механизм коммутации - родовые шины сообщений.

Ответ на »сообщение 3868« (Jack Of Shadows)
___________________________
Джек, конкретно по возражениям пунктам Руслана - Вы гиперболизируете...
Вопрос-то стоит в разных плоскостях. Есть ФП само по себе, как метод/опыт/подход и т.п.
А есть явление в индустрии - распространение интереса к ФП с самой разной стороны.
А интерес тоже бывает разным и н основанным на разных мотивах. И здоровым, и нездоровым. При этом сам по себе объект интереса вне зависимости от этого остается самим собой - может быть, весьма и весьма превосходным.
Но от того, как и кем будет развиваться к нему интерес, очень зависит его судьба.
Я не раз уже припоминал судьбу ООП... Как все было прекрасно у Кея, и к чему все пришло :-) И разве в этом виноват Кей, и разве это само ООП такое "плохое и дутое"?

Так что, как мне кажется, подобные темы "кому, как, почему и зачем интересно сегодня ФП" должны бы в первую очередь интересовать Вас, т.к. это будущая судьба ФП...

Точно так же, как меня интересует эти моменты применительно к Оберонам.
К примеру, интерес Микрософта к исследованиям в Цюрихе, попытки "перетаскивания" на дотнет, их импровизации на тему "Оберон-скрипт" - все это не только не предмет для радости, но большой повод насторожиться - потому что никто не знает, каким образом они могут извратить прекрасные идеи, "пережевав" их у себя в Researchах и "выплюнув" на массовую аудиторию с подделкой под исходную марку...

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

Ответ на »сообщение 3855« (AVC)
___________________________
Правильное, с позиции теории систем, решение это декларировать потребности (импорт) и возможности (экспорт) в терминах интерфейсов. А что система "подставит" в качестве "поставщиков" или "потребителей" услуг (сервисов), это ее дело, но никак не прикладного программиста. Уточню, реальный "поставщик" и/или "потребитель" услуг может меняться (в runtime, в том числе) в зависимости, например, от состояния системы. А разработчик модуля ни о самой системе, ни о ее состояниях... знать не должен.
Все верно, в Оберонах большая часть межмодульных связей и декларируется в терминах интерфейсов.
Есть модули - основные "строительные блоки" для системы. Модули коммутируются между собой различными способами. И статический импорт - только один, самый простой и прямолинейный из этих способов.
Другие связи выстраиваются динамически на основе разъемов. И разновидностей таких разъемов весьма много. И описываются эти разъемы как раз-таки в терминах интерфейсов (абстрактные записи).
В модульных не-ОО языках (Модула, старая Ада) такие разъемы могли быть только процедурными (обычный callback).
В ОО-модульных языках появляются объектные разъемы.
Эти разъемы могут использоваться по разным схемам.
1) Объектный callback-разъем.
2) Разъем подключения реализации (в Блэкбоксе называется Hook). При этом происходит инверсия импорта - модуль, являющийся "лицом" некоторого сервиса, ничего не знает о некоторых деталях реализации. Наоборот, модуль реализации импортирует "лицевой" модуль и динамически подключает реализацию через объектный разъем. Естественно, разъем можно динамически переключить на другую реализацию (которую тут же динамически и загрузить).
3) Инсталлируемая точка доступа - модификация предыдущей схемы, когда "лицевой" модуль является всего лишь "монтажной платой", на которую инсталлируются доступные другим модулям объектные разъемы.
4) Инсталлируемые каталоги. "Лицевой" модуль сервиса определяет абстрактные интерфейсы для этого сервиса и предоставляет инсталлируемую точку доступа к фабрике объектов, реализующих эти интерфейсы. Модули реализации динамически инсталлируют фабрики в "лицевые" модули.
Замечу, что во всех этих схемах ООП является служебным механизмам, а не системообразующей схемой. В частности, не используется наследование реализации.
Единственный случай, где наследование реализации используется - это framework с базовыми типами-заготовками, поведение которых можно расширять через наследование...

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

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

ФП сегодня как никогда выгодно и модно:

Все очень просто: я выдвинул процитированный тезис и привел свою краткую аргументацию.

Можно не соглашаться:
1) с тезисом;
2) с аргументацией тезиса.

Судя по реакции протест вызывает автор тезиса и его предпочтения. Это называется просто -- переход на личности. Готов выслушать опровержение тезиса и/или аргументаци тезиса. Все остальное -- эмоции, они мало интересны.

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

Надо же, какое у Вас предубеждение против ФП. Именно предубеждение, иначе и не скажешь... 8-о

Евгений, это не предубеждение. Это моя субъективная оценка. Я ее постарался аргументировать. Если Вы не согласны с тем, что ФП модно или выгодно по перечисленным мной пунктам, с интересом выслушаю Вашу точку зрения.

Насколько я знаю, корректность алгоритмов вывода типов для Хаскелла доказана математически. Если возникнут какие-то баги (а баги могут быть везде), то они будут исправлены.

Дело не в багах. Автоматический вывод -- это один из элементов автопилота в ФП. Кто сказал, что автопилоты плохи и никому не нужны? Просто это -- источник проблем, которые надо понимать. Если бы из технологического цикла создания программ человек был бы полностью исключен -- другой вопрос. Но как только сосуществуют две вещи -- пилот и автопилот -- ищите проблемы/беду в их взаимодействии.