Ответ на »сообщение 2740« (Руслан Богатырев)
___________________________
В таких принципиаьно разных языках как оберон и хаскель, конечно совнершенно разные механизмы.
В обероне нет много чего что есть в хаскеле. Однако несмотря на это, я думаю глупо требовать от оберонщиков отказываться от оператора присваивания.
В ветке по оберону кто то завел очередную волынку про включение некоторых функциональных механизмов в оберон.
Так я был первый кто сказал что это глупо. Что вы поломаете оберон но так и не получите что то лучшее.
Что нужно прежде всего выбирать парадигму в которую вписываются те приемы которые вам нужны и удобны, и соответственно выбирать построенный по этой парадигме инструмент, а не пытаться тащить отовсюду все что вам приглянулось в одну кучу. Достаточно народу до вас это пыталось сделать. И мы имеем уже достаточное количество провалившихся экспериментов, чтобы понять что конкретные элементы и механизмы ЯП становятся полезными и удобными лишь работая в связке друг с другом, а не потому что эта полезность и нужность в них заложена.
Я уже говорил что не сомневаюсь что обязательный квалифицирубщий импорт полезен в обероне, с его модулями, хранящими состояние.
Но в хаскеле нет таких модулей. Для хаскеля модуль, хранящий состояние - это нонсенс.
И заставляяя всех программистов писать длиннющие идентификаторы вы практически никакой пользы и удобства не получите (особенно учитывая то что квалифицирующий импорт в хаскеле есть), зато нервы всем попортите изрядно.
Пора бы уже понять и признать. Что без определенной среды, без определенных, работающих совместно механизмов языка, вырванный из контекста ОБЯЗАТЕЛЬНЫЙ квалифицирующий импорт далеко не такая полезная и нужная штука как вам кажется.
Так же как и я понимаю и признаю, что map fold и filter, вырванные  из контекста ФП, и засунутые в оберон, где даже нет нормального встроенного типа списка, где есть разделение на выражения и операторы, где все настроено на работу с целой пачкой разных циклических операторов (опять операторов а не выражений, возвращяющих значение), будут просто как у собаки боковой карман, на черта не нужны, мешаться под ногами, быть обузой а не удобством.

Потому мы к вам и не дезем со своими бирюльками. Но и вы господа сови ОЧЕНЬ ПОЛЕЗЫНЕ бирюльки держите при себе. Нам они на черта не сдались.

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

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

Отлично. Я рад, что мы нашли понимание. Можно будет дальше двигаться в русле конструктива. Делить-то нам собственно нечего, только обогащаться -- смотреть что ценное у кого можно стырить :)

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

Оберонщики превозносят Оберон, отрицая ФП в принципе, функциональщики - наоборот. Грустно все это.

Вы излишне упрощаете картину, если не сказать -- утрируете. Предложение разобраться в границах применимости ФП исходило от оберонщиков. Да и сами функциональщики немало сделали для того, чтобы тоже помочь в этом разобраться. Разбор задачи по ACM -- думаю, очень полезный опыт совместных усилий. Разбор Geniepro очень полезный. Побольше бы таких вещей. Думаю, резюмировал достаточно взвешенно и уж никак ФП не выглядело в этой ситуции в проигрыше. Что касается "мелочи" в отношении квалифицирующего импорта, то никто не запрещает это использовать в Хаскеле и Delphi (как некоей дисциплине) исходя из многолетнего опыта Вирта и людей, связанных с Модулой-2 и Обероном. Взять чужой опыт и использовать в любимом языке. Но сама реплика неожиданно для меня вызвала бурю негодования (хотя нет худа без добра, что-то полезное, думаю, для себя мы все вынесли).

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

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

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

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

Просто пояснил, что в решении Geniepro меня смутило. А дальше пошла цепочка упорного недопонимания (возможно с обеих сторон).

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

Я обновил ту программку на ЖЖ...

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

>>>Если для Оберона естественно и логично каждый раз точно указывать, что за объект-модуль используется в том или ином месте, потому что это вытекает из требований к динамичной компонентности, то в статических программах, написанных на том же Хаскелле, это уже не так логично и естественно.

Но почему-то в статических программах, написанных на SML, это опять уже логично и естественно. ;-)
А на OCaml, кажется, не так логично.

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

Имя класса второстепенно, имя модуля - который является активной сущностью - важнее...

Вот она, суть взгляда оберонщиков на модули, кардинально не совпадающего с взгядом на модули со стороны функциональщиков!!!

В Обероне модуль - не просто единица упаковки данных и кода, а именно некий объект со своими меняющимися со временем состоянием и поведением, компонент, одним словом...

В чистом ФП модули не могут хранить изменяемое состояние, функции, определённые в этих модулях, могут вызываться из других модулей и обрабатывать данные, находящиеся в других модулях, и не более...

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

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

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

Где и когда эти слова применялись к ФП?
А то запомнились только перлы (вроде "разумности" маклиспа). :)

По поводу разумности Маклиспа все претензии к горячим финским парням, написавшим книгу "Мир Лиспа", откуда этот абзац я и выдрал (квалифицировав ссылку на источник, кстати :о))

А то, что у ФП есть некоторые ограничения - так это даже Jack Of Shadows много раз повторял в этой ветке...

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

Ответ на »сообщение 2730« (Илья Ермаков)
___________________________
Я уже написал, если в Delphi два класса реализуют функциональность по-разному, то и называться они должны по-разному. Это защитит гораздо лучше любых встроенных средств языка. А то ведь и модули можно назвать MemoryManager1, MemoryManager2 - и все старания по квалифицирующему импорту пропадут даром.
Мы с Вами пишем на модульных языкак - это значит, что функциональность реализует не класс (который всего лишь тип данных), а тот модуль, в котором он определен. Имя класса второстепенно, имя модуля - который является активной сущностью - важнее...
Ваша позиция проистекает от того, что Вы используете ООП в стиле немодульных языков - класс как контейнер для поведения, а модуль - просто пакет для подключения...
Если Вам так удобно и привычно для ваших задач - ну и прекрасно! Наша с Русланом позиция проистекает из более прямого взгляда на архитектуру паскалевских языков...

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

В том-то и дело, что непонимание с обеих сторон. Оберонщики превозносят Оберон, отрицая ФП в принципе, функциональщики - наоборот. Грустно все это.

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

У нас позиция другая - если можно ввести большую ясность/прозрачность/аккуратность, то это надо делать...
Вы не поверите, но у меня тоже такая позиция ;)
Проблема в том, что для обеспечения максимальной ясности/прозрачности/аккуратности в любом языке нужны усилия программиста. И если они есть, то разница между некоторыми языками может очень сильно нивелироваться. Я уже написал, если в Delphi два класса реализуют функциональность по-разному, то и называться они должны по-разному. Это защитит гораздо лучше любых встроенных средств языка. А то ведь и модули можно назвать MemoryManager1, MemoryManager2 - и все старания по квалифицирующему импорту пропадут даром.