Ответ на »сообщение 3595« (Сергей Перовский)
___________________________

Ответ на »сообщение 3592« (info21)
___________________________
>>>уметь жонглировать символами и производить формализмы -- не то же самое, что понимать науку-математику
Это слишком сильное утверждение.

Как могут быть слишком сильными утверждения того же порядка, что и "борщ это не бифштекс"?
Или мы собираемся скатиться на уровень "теста Тьюринга" и всерьез утверждать, что если компьютер можно научить преобразовывать формулы, то он "понимает" алгебру?

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

Ответ на »сообщение 3592« (info21)
___________________________
>>>уметь жонглировать символами и производить формализмы -- не то же самое, что понимать науку-математику
Это слишком сильное утверждение.
Есть профессиональные математики, работа которых, в некотором смысле, как раз "жонглировать символами и производить формализмы". Без понимания тут никуда, но это понимание очень абстрактных вещей.
Инженерный взгляд на матиматику состоит в приведении к формализму конкретных практических задач. К сожалению термин "прикладная математика" стал пониматься очень узко, как вычислительная математика.
А не хватает именно прикладной математики и в подготовке математиков и в подготовке инженеров. Инженер с фундаментальным (в том числе математическим) образованием у нас редкость.

Ответ на »сообщение 3593« (Как слышно? Приём!)
___________________________

Ответ на »сообщение 3592« (info21)
___________________________
Мама моя!
Что такое "понимать науку-математику"?
It is a question!

Тогда уж в корень: что такое вообще -- "понимать"?
А потом применить это к математике.

Ответ на »сообщение 3592« (info21)
___________________________
Мама моя!
Что такое "понимать науку-математику"?
It is a question!

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

Ответ на »сообщение 3584« (info21)
___________________________
Не к математике, а к представлениям о ней людей, ее не понимающих. Таких, разумеется, подавляющее большинство, всюду.
Например, к таковым, без сомненья, можно отнести Дейкстру и Бэкуса...

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

Примерно как делать детей -- не то же самое, что понимать науку генетику.

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

Вложите функцию (ее и только ее) в отдельный модуль. Назовем его для определенности модулем-функцией.

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

Теперь видно, что ФП и ООП не конфликтуют с МП в лице Оберона именно в силу того, что мудрый Вирт предусмотрел возможность конфликта и отсек его еще на дальних подступах. ФП не может обойтись без ИП. Имитировать ИП на ФП да еще имея в виду "императивное" железо и императивный run-time много заковыристее, нежели наоборот. А имитировать приходится, ибо ФП со всех сторон окружают ИП-агрессоры. И в их мире надо выживать.  :)

Небольшое замечание относительно термина "кластерно-модульное программирование". Почему я дал именно такое название.

1. Идея модулей появилась не у Дэвида Парнаса, а парой лет раньше -- у Петера Наура. И назвал он модули "кластерами действий" (Peter Naur "Programming by action clusters". BIT, 1969, #9). Ссылку на эту редкую работу, кстати, Вирт привел еще в своей знаменитой классической работе "Program Development by Stepwise Refinement" (1971) -- http://www.europrog.ru/paper/nw1971.pdf

2. Идея кластеризации (термин хорошо известен в области обработки данных и в сфере "железа") приглянулась Барбаре Лисков (MIT) и она застолбила этот термин для своего языка абстрактных типов данных -- CLU (1975). Собственно CLU есть "половинка" от CLUSTER. Кластер Барбары Лисков -- это своего рода модуль (АТД-модуль), в котором инкапсулированы (связаны друг с дружкой) абстрактный тип данных (АТД) и операции над ним. CLU относят к языкам модульного программирования.

3. Если смотреть на модульное программирование с позиций Вирта (модули Оберона и Модулы-2), то ощущается нехватка более объемлющей конструкции -- набора модулей (в том же КП в роли таких наборов выступают каркасы-framework). Этот набор помимо того, что просто перечисляет относящиеся к нему модули (куст модулей, удобный для групповой загрузки-выгрузки-подмены) еще и вводит определенные правила композиции (будем просто называть конфигурированием набора модулей). Вот почему возникла потребность в понятии, отличном от термина "модуль", но родственное ему по истории и по смыслу. Так я пришел к мысли использовать название "кластер" и термин "кластерно-модульное программирование".

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

>>>Во вторых, законный вопрос, почему это проблема в ООП, но не в ФЯ ?
Потому что ООП стоит на пути решения этой проблемы, мешается под ногами, ставит палки в колеса.
В то время как ФП доступ к решению этой проблемы совершенно прозрачен, между вами и решением нет никакой жесткой структуры вроде иерархии классов. Поскольку в ФП функции тоже являются данными, то их можно динамически передавать "сквозь" любую структуру данных, чего в ООП не сделаешь.

>>>В третьих, может есть альтернативное решение? Может в Оберон-системах, это решается по-другому?
А что уже есть какое то отдельное Оберон-программирование, которое в принципе отличается от ООП ?

Удивительное дело. Почти год назад в соседней ветке, посвященной ФП, я написал в сообщении #57, цитирую: Провокационный вопрос. Вообразим на минутку, что в Обероне мы пишем так, что модули имеют и экспортируют исключительно процедуры-функции, которые не хранят никаких состояний и которые на одни и те же аргументы возвращают один и тот же результат. Это и есть функциональное программирование в императивном языке?

А воз и ныне там. Хорошо, давайте разбираться.

Что есть Оберон? Это язык модульного программирования, в котором есть все необходимые основы императивного программирования, а также средства для построения ООП (конструктор из разряда "собери сам"). В КП этот конструктор вынесен на другой уровень, приближающий язык к мэйнстрим-пониманию ООП, но при этом нижний уровень (классического Оберона) сохранен. Этот уровень складывается из идеи построения классов через записи и ссылки (идея Тони Хоара, реализована в Algol W и классическом Паскале образца 1970 г.). Оберон расширил эту идею, добавив type extension -- "наследование" типов.

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

Если более-менее понятно, что Оберон (классический) не помещен в "прокрустово ложе" мэйнстрим-ООП, можно идти дальше. Идем.

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

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

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

Теперь опишите процедурный тип, в котором прописывается интерфейс нашей функции (сигнатура). Его экспортируем (ставим звездочку). Теперь переходим ко второму требованию. Вирт для того и ввел процедурные переменные, чтобы решить эту задачу (язык Эйлер, Euler). Сделал это, анализируя в начале 1960-х годов ФП и пытаясь найти удобное обобщение Алгола-60. У него появились ссылки на процедуры (процедурные переменные). Они же решили и задачу ухода от передачи формальных параметров по имени (помимо передачи по значению и по ссылке). Ссылки на процедуры -- это процедурные типы (и соотв. им переменные). Собственно экспорт интерфейса функции нужен именно для оперирования ею как обычным типом данных (в смысле атомов, списков и кортежей ФП). Не будем забывать и про то, что в Обероне можно объявлять локальные процедуры (сколь угодно глубоко вкладывать новые функции внутрь "родительских"). Это тоже полезное дело в смысле ФП. Так что контекстом управляем полностью.

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

Так чего же тут бедному Оберону не хватает для полноты счастья ФП? Или очень все сложно?

Похоже, народ устал после бурных дебатов. :)
Наверное, и правда требуется передышка.

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

Ответ на »сообщение 3582« (AVC)
___________________________
сомнительные места обобщенного программирования.
Не усёк, где оные сомнительные места?

Сомнительные места -- те, которые вызывают сомнения. :)
В данном случае, сомнения возникли у меня.
Сомнения -- это всего лишь сомнения, а не приговор. :)

О чем речь.
В приведенных Джеком примерах аспектного программирования, например pointcut before *.SSN SecureSSN, вызывает сомнение, что аспект применим к полю только на основании его текстового имени, никакого родства классов, помеченных звездочкой, не требуется.
Возникла ассоциация, что и в обобщенном программировании требуется только текстовое совпадение, чтобы текстовая строка была применима к конкретному типу переменной.
Вот это мне и кажется сомнительным, т.е. вызывает сомнение.
До тех пор, пока не увидел это в аспектном программировании (т.е. в чем-то для себя непривычном), просто не обращал на это внимания.

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

Ответ на »сообщение 3584« (info21)
___________________________
Не к математике, а к представлениям о ней людей, ее не понимающих. Таких, разумеется, подавляющее большинство, всюду.
Например, к таковым, без сомненья, можно отнести Дейкстру и Бэкуса...
Любое программирование - это формальная система. Любая формальная система одинаково "близка к математике"...
Другой вопрос о близости используемой нотации/конструкциям к стандартно-математическим. Тут ФП, естественно, к ней ближе. Лично я считаю это только минусом - меньшая выразительность с точки зрения инженера...