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

Позвольте нам решать, ладно ?

Конечно, же решайте. Моя задача поделиться опытом Оберона и указать на проблемы, которые всплыли в Хаскеле. Ээти проблемы были и в Модуле-2 (делюсь своим опытом -- не интересно, ради Бога), но в меньшей степени -- ибо там всегда при неквалифицирующем импорте требовалось явно перечислять импортируемые сущности, что при длинном списке просто подталкивало к квалифицирующему импорту.

Ваше дело слушать или игнорировать. Разумеется. Никому ничего не навязываю. Хотите думать -- думайте. Нет -- не надо.

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

Если Вы полезете в VCL для того, чтобы "дернуть" и портировать оттуда какой-то код (а я тогда полез именно затем - за реализацией прозрачности битмапов) - то Вам от этого действительно станет гораздо легче...
Когда (а не если) я заглядываю в VCL, чтобы позаимствовать оттуда реализацию какой-либо функциональности, я использую Ctrl+мышь. Компьютер справляется с поиском и открытием файла Classes.pas намного быстрее любого программиста.
"Человек должен думать, машина - работать" (с) не мое.

Ответ на »сообщение 2645« (Руслан Богатырев)
___________________________
Two words for you: Stack trace :))
Руслан, если у меня в дельфи где то что то не работает и вылетает ошибка, то я получаю номер строчки и название файла где эта ошибка произошла.
Кстати тоже самое и в java и в сишарп. Это без всяких дебагеров и assert-ов.
Как видите средства доступные нам, прекрасно помогают в локализации источника проблемы и быстром устранении  неисправности.

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

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

Частенько удивляются, почему Оберон-программисты так редко прибегают к отладке, а обычно обходятся точками контроля инвариантов (ASSERT) или анализом дампа. А на отсеки-то уже все разбито и локализация производится очень быстро. Нет неквалифицирующего импорта -- нет и стимула для размывания ответственности.
Частенько удивляются, почему хорошие программисты пишут модульные тесты...
Думаю, дальше продолжать не надо? Если бы Oberon стал "серебряной пулей" мы бы сейчас обсуждали совсем другие вопросы.

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

Ответ на »сообщение 2630« (Илья Ермаков)
___________________________
Ага, ну вот узнал я, например, что класс TThread находится в модуле Classes. И что с того? Мне от этого должно стать легче?
Если Вы полезете в VCL для того, чтобы "дернуть" и портировать оттуда какой-то код (а я тогда полез именно затем - за реализацией прозрачности битмапов) - то Вам от этого действительно станет гораздо легче...
Что хоть за отношение к коду... нехозяйское какое-то :-) Написать - и все равно, что с чем там связано и где лежит...

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

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

Немецкий историк Моммзен утверждал: "Das Buch ohne Index ist kein Buch".
Так что у квалифицированного импорта долгая история. :)

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

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

И получится как в Обероне? ;)

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

Ага, ну вот узнал я, например, что класс TThread находится в модуле Classes. И что с того? Мне от этого должно стать легче?

Интересно. Даже не ожидал, что такая проблема вскроется на ровном месте. Хотя понятно, что схема "квалифицирующий-неквалифицирующий импорт" роднит Haskell и Delphi. Хорошо, попробую объяснить свое понимание того, почему Вирт, наступив на эти грабли в Модуле-2, принял другое решение в Обероне. Тогда как другие языки и их пользователи продолжают на них с недоумением наступать.

Итак, для многих импорт из сторонних модулей есть средство включения внешних возможностей в свою программу/модуль. Разумеется, если мы смотрим на это с позиции синтеза программы (т.е. потребителей чужого кода), то нам хочется минимизировать свои проблемы: узнать, что подключить, чтоб былО. При этом, как верно подметил Geniepro, нет желания явно указывать каждую точку "заимствования" -- не красиво, текст увеличивается. Если есть выбор: квалифицирующий -- неквалифицирующий, то (это показал и многолетний опыт Модулы-2) будут выбирать путь наименьшего сопротивления -- неквалифицирующий импорт. Так сейчас (в данный момент написания программы) проще, а последствия -- они еще когда будут.

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

Импорт есть заимствование. Нет необходимости выяснять достоверность -- не важен источник. Лишь бы работало.

Теперь посмотрим на ситуацию с позиции не синтеза, а анализа программы. Когда в нем возникает потребность? Самый простой случай -- что-то где-то не работает. Значит, ставится задача локализовать источник проблемы, чтобы устранить неисправность. Другой распространенный случай -- модификация работающей программы (самим автором спустя продолжительное время или же третьим лицом, который впервые видит чужой исходный текст). Чтобы провести модификацию, надо сначала выявить контекст исполнения. Т.е. решить обратную задачу -- построить карту зависимостей с локализацией взаимного влияния сущностей. Иначе тронешь -- и все может развалиться. А еще хуже -- пойдут наведенные эффекты, которые сразу и не всплывут, а дадут о себе знать по закону подлости в самый неподходящий момент (за несколько дней до сдачи проекта, либо вообще в ходе эксплуатации).

Вот, кстати, на чем еще вскрываются проблемы ООП: полиморфизм, "делегирование" ответственности вышестоящим классам размывает контекст. То, что хорошо работало для сокращения синтеза, начинает проявлять все свои болячки на этапе анализа. За все, как известно, надо платить: пытаемся сэкономить на конкретике, вводя обобщения и умолчания-делегирования -- размывается ответственность. Становится сложнее локализовать неисправность.

Как решает задачи локализации мэйнстрим? Правильно -- трассировкой и отладкой. Не буду вдаваться в обсуждение того, что как тестирование, так и отладка -- это видимость благополучия. Ибо программа задает целый класс вычислений и, как правило, нет физической возможности все до единого варианта перепроверить. Что остается? Анализировать правильность конструкций и композиций сущностей. Четко знать степень ответственности каждого элемента и иметь возможность, как в подлодке, решать задачу непотопляемости за счет разбиения на герметизированные отсеки.

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

Относительно нивелирования проблемы за счет средств инструментария. Зачем порождать проблему, чтобы потом ее героически решать? Ключевым в программировании является человеческий фактор. Работа минером (щупать, к чему та или иная сущность относится, вместо явной таблички с надписью "заминировано") -- не самый лучший вариант для программиста. Ему хотя бы отличить даже внутренние вещи от внешних и стандартных -- уже была бы польза. А когда все едино -- напоминает принцип  "что твое, то и мое, а что мое -- то ты не трожь". Для выяснения в словаре наличия тех или иных слов можно каждый раз "переспрашивать" (делать запросы), а можно просто посмотреть списочек (целый фрагмент). Не зря в конце книг с давних пор приводят различные указатели (предметный, имен и т.п. с отсылками на точки локализации -- страницы). Хотя желающие могут генерировать свои гипотезы и каждую из них проверять полнотекстовым поиском в всем тексте книги. А что -- тоже подход.

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

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

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

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

Это, конечно, неудобство, но с помощью так любимого нашими оберонщиками "грамотного проектирования" можно всё это предотвратить при желании...
Осталось только так сильно обжечься на подобной ситуации, что бы это стало действительно серьёзным доводом, и заставлять разработчиков использовать только квалифицированный импорт, что очень легко контролировать (по наличию только import qualified без простого import)... :о)

Ответ на »сообщение 2642« (Trurl)
___________________________
Объекты, которыми манипулируют функции, не имеют состояний.
Обьект не имеющий состояния это нонсенс. Так что можно сказать что функции оперируют не обьектами а кортежами (tuples). Которые представляют собой неизменяемые структуры данных.
И соединить функциональное и ОО программирование никак нельзя. Разве что только как внешние системы обменивающиеся сообщениями.