OberonCore

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

ЗЫ. Эта функция так медленно работает из-за заторможенных массивов в GHC. Этот алгоритм, в принципе, можно переписать, так что бы он работал ненамного медленнее, чем на Си, но выглядеть будет ещё страшнее. Хотя куда уж страшнее-то...

Гораздо же приятнее смотреть на удобочитаемый код, например на Обероне

В некоторой степени границы нет. Диалектика "снаружи - объект, внутри - процесс", конечно, верна (я сам всегда её отстаиваю).

Однако пассивные сущности таки есть. Если мы построим системную модель некоторой, ну, к примеру, организации, то увидим, что потоки между подсистемами есть не только объектные, но и чисто информационные. Например, передача документов или команд (управляющий поток). Путаница возникает при абстрагировании всего этого до нашей информационной модели. Тут-то ведь уже всем реальным потокам (и материальным, и информационным) ставятся в соответствие чисто информационные! Тем более, надо не забывать об этом различии: моделируем ли мы саму подсистему (безусловно, активная сущность, снаружи - объект с интерфейсами, внутри - процесс, обеспечивающий жизнедеятельность - соотв. современным параллельным, агентным моделям типа Active Oberon - Zonnon - Composita и их прообразам типа Occam-Erlang), моделируем ли мы некий объектный поток между подсистемами (с текущего ракурса - достаточно пассивная сущность, которую только передают, но она имеет внутреннее устройство и в другом ракурсе может что-то сама делать - обычное ООП с методами) или моделируем мы исконно информационный поток, например, документы (ОО-подход только путает, нужна хорошая абстрактная типизация без введения активности объектов данных - или, так скажем, без упора на использовании методов).

А вот обероновское видение модульности:
http://wiki.oberoncore.ru/index.php/%D0 ... 0%BB%D1%8C
http://wiki.oberoncore.ru/index.php/%D0 ... 1%80%D0%B0

А вот приведите эту самую быструю сортировку на Обероне -- сравним!

Подход хороший. Но в текущих моделях ЯП невыполнимый (и в Смоллтоке тоже). Речь о чём - не о том, что такая эргономичность не нужна. А о том, что не надо заставлять "медведей танцевать" ( (С) Алан Купер ). Те, кто заставляет текущие ЯП и текущие парадигмы в виде ФП-ООП так работать, просто запудривают мозги. Цель не достигается, а интеллектуальный контроль за происходящим и прозрачность работы теряется.

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

Опять же, документированность бывает разной. Если речь о документации на то, как инструмент работает - то, конечно, чем меньше - тем лучше. Если речь о справочной информации ("таблицы номиналов"), то куда ж в инженерии без неё? Как раз хорошо, когда мы можем держать в голове целиком простую и понятную базовую модель и лазить в справочник только за фактической информацией (которую я, например, запоминать не привык вообще). Низкоуровневость заставляет всё время думать о частностях и держать их в голове. Псевдовысокоуровневость (С++/шапр/явская, так скажем) громоздит непрозрачную модель инструмента, которая не является легко постижимой и запоминаемой. Вместо того, чтобы искать чисто справочную информацию, я должен сначала докопаться, а как оно тут в данном случае вообще сделано, какой ногой в этом месте библиотеки автор почесал правое ухо (у какого объекта метод введён и т.п.).

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

Преобразование целого в строку - это, как ни крути, ну на любом уровне, не связано с работой с активными субъектами. Связано это только с трансформацией чисто пассивной информации. Сервером является некий субъект-преобразователь, клиентом - тот, кто посылает этому преобразователю число, а принимает от него строку.

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

Вот здесь неточность. Вернее, недопонимание. Вы здесь используете клиент-серверную терминологию, поимая под этим ПРОЦЕСС взаимодействия.
Я же говорил об ОБОБЩЁННОЙ ИНФОРМАЦИОННОЙ МОДЕЛИ. Согласен, обычно терминологию "клиент-сервер" для ДЕКЛАРАТИВНЫХ знаний вроде бы не используют... Но мне так показалось методически верно

В таком вот контексте мне и не нравится, с какого перепугу я должен искать РАЗНЫЕ ПУТИ для преобразования сущности в строку - в зависимости от вида этой сущности. Я хотел бы взять контейнер, где эта сущность лежит, и использовать интерфейс... И тогда мне будет всё равно, число там или монстр, который ещё в инет сходит, прежде чем себя напечатать

ВОПРОСЫ ЭФФЕКТИВНОЙ РЕАЛИЗАЦИИ НАМЕРЕННО ОСТАЮТСЯ ЗА КАДРОМ, как технические... Впрочем, Вы уже ответили про эргономику...

Вот-вот. Метод - тоже неуклюжий артефакт мейнстримовского ООП. Как синт. сахар использовать можно, но надо понимать и соблюдать меру.

Вот для такого варианта, если отбросить наследование типа Integer от Object, а значит и отказаться от идеи, что просто число имеет какие-то там методы, то остаются классы типов а-ля Хаскелл.
Определяем отдельно тип, например Integer, который абсолютно ничего не умеет, затем определяем разные классы типов для упорядоченной и единообразной работы не только с числами типа Integer, но и Float, и Complex, и Rational. В этих классах типов определяем методы -- операции работы с числами, и делаем привязку к типам Integer, Float, Complex, Rational...

Затем определяем класс типов Show, единственный метод show у которого предназначен для перевода содержимого значений разных типов в строковое представление.
Делаем реализацию этого класса для того же типа Integer, например, и для всех тех типов, для которых мы хотим иметь метод преобразования в строку.

Вот чем такой спосою не устраивает оберонщиков, хотелось бы знать?..
Тип Integer остаётся "базовым", но мы получаем унифицированный способ перегрузки разных операций, от математических до преобразований в строку...

Что не так с таким подходом?

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

Ну что я могу сказать, ничуть не более понятный код. Для Вас, возможно, на Обероне понятнее. Для меня нет. Вот мы и пришли, что всё это -- просто вкусовщина-субъективщина...

А Вы представьте, что маршрутная часть на Драконе (т.е. то же самое, только сразу интуитивно понятно).
Тогда останется человеку знать, шо такое := и [].

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

Ну да, ДП -- это как спрашивать консультацию у эксперта, ФП -- это как общаться с умным коллегой, а ИП -- это как водить за руку идиота... Вот и вся разница...

Умствования # ум.

Если одно и то же можно выразить одинаково хорошо и в терминах, понятных идиоту, и в замудрённых "высоких материях", то очевидно, что те, кто предпочитает последнее - просто водят нас за нос.

Конечно, легко спекулировать на (реальных) достоинствах ФП-инструментов, которые, на самом деле, не связаны непосредственно с функциональным стилем. Точнее, влекутся им, но далеко не только им.

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



Ну есть математическая модель. И что? Как это связано с невозможностью писать i.ToString()?



Блин. Такая упертость и замыленый взгляд наверное только у оберонщиков.
- Смотри, не в обероне я могу понять код не прыгая в интерфейс, так гораздо быстрее
- А я хочу прыгать в интерфейс
- Смотри, не в обероне я могу понять смысл интерфейса не заглядывая в доку (которые если и бывают, то только у устоявшихся библиотек) или код
- А я хочу смотреть доку и код
- Совмещая объявление и инициализацию я могу избежать вот таких конкретных багов и повысить читабельность
- Это все синтаксический сахар
- Мне все равно как писать i.ToString() или ToString(i), потому что и та и та запись читаются одинаково
- Запись i.ToString() не может быть правильной потому что (далее куча абстрактных рассуждений про базовые типы, ООП и т.д.)



Не надо переводить стрелки. Речь шла об обработке ошибок, а не о том, для чего нужен ASSERT. Или будете пользователю покавать красивый (интерактивный) дамп стэка, когда он попытается записть свой документ в read-only файл?



А если Y представляет координаты цели, а функция должна возвращать ошибку в случае, если цель принадлежит союзнику, то что же все таки будет в y? А если программист забудет проверить возвращенную ошибку? То союзникам так и расскажут, что программист дурак? А может все таки дело в языке, для которого такая ситуация является штатной и единственно возможной (потому что так индусам и прочим студентам меньше места для маневра)?

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

Вы преимущественно кодите, или думаете?Математическая модель ничего не может писать. Даже теоретически.только у меня, наверное. Про остальных не скажу. Вы это к чему? Я то в обероне. А вы нет. Я знаю наверняка. А вы гадаете(пусть и с большой вероятностью).Получается, что Вы - БОГ. Или вам повезло.Это сахар. Я не говорил, что это плохо. Это сахар, я без него обхожусь. Решение - инитить переменные.Всё таки вы наверное больше кодите чем думаете. Без обид.Вы не поняли сути. Если все ассерты пройдены, то значит ваш код корректно работает в любой проверенннной вами ситуации. Если вы не проверили файл на read-only то это вы виноваты(кстати конкретно эта ситуация корректно обрабатывается в ББ ещё на уровне слоя работы с файлами).Понаставьте ассертов. Протестируйте всесторонне. И с большой степенью вероятности нештатная ситуация будет выявлена. Подумайте - потом пишите код. Ваши слова про студентов я могу принять на свой счёт, принять за неуважение, и страшно расстроиться. Я кажется ни разу не усомнился в вашем профессионализме.