Интересно, что при функциональном подходе и модули становятся просто структурами (в смысле Бурбаки).

Ответ на »сообщение 944« (12)
___________________________
Вообще говоря, программирование является математичным только до определенного порога, деятельность программиста лежит в лишь частично формализуемой области. Полностью описать семантику большинства универсальных языков програмирования формально, не прибегая к естественному языку, невозможно. И пытаться не стоит - нужно уметь увидеть тот рубеж, на котором стоит остановиться и не биться головой о  принципиальный барьер...
ИМХО, однако не только мое имхо - вот у нас на конференции (см. выше) товарищ с ВМК МГУ то же самое мнение выссказал...

Я имел в виду не всю математику, Сергей. Сильно упрощая, берется система взаимодействующих объектов, а свойства их математической структуры выводят из описания свойств взаимодействий ими осуществляемых. Что-то типа "черного ящика" в физике.

>>>В математике нет деления на описание и реализацию.

В некотором смысле есть. Сравните "группа" и "группа целых чисел".

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

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

Чему удивляться? Функциональный подход - поэзия, а императивный - проза.

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

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

Вот я и хочу, чтобы мне помогли перевести с математического на программистский.
Правда, мысль о единстве интерфейса я пока не понял.
Хотя привычные нам понятия интерфейса и реализации имеют отношение к моему вопросу.
У того же Мейера: пока чистая спецификация - АТД, как только хоть капелька реализации - уже класс.

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

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

Ответ на »сообщение 939« (12)
___________________________
>>>Если перевести на язык программиста, то речь идет не об единстве структуры, а об единстве интерфейса.
Перевод сомнительный.
В математике нет деления на описание и реализацию. Поэтому программистские споры про наследование интерфейсов и реализаций аналога в математике не имеют.
Каждый программист будет проецировать математические подходы на свои проблемы.
Для меня аналогия с единством структуры более значима, чем с единством интерфейса. Для Вас наоборот.

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

Ответ на »сообщение 937« (AVC)
___________________________
Есть вероятность того, что со временем мне удастся перетащить этот лингвистический проект на Ada. Руководитель, наслушавшись моих рассказов про паскалевское семейство и про то, "откуда есть пошли все явы и шарпы", весьма этим всем заинтересовался. Однако Оберон все-таки окажется тут слишком минимальным - ребятам нужна стандартная библиотека, обобщенка и т.п., а в Ada-2005 есть все, что и в С++ (в том числе аналог STL), и гораздо больше, при этом все сделано, в отличие от последнего, через правильное место.
Буквально на днях у нас в ОГУ прошла международная конференция "Методы физико-математических наук", мы с Борисом Рюмшиным делали доклады на Оберон-тематику, и было два гостя с докладом про Аду - один, С.И. Рыбин, с ВМК МГУ (работает в корпорации AdaCore), другой - из Харьковского ГУ. Получилось весьма интересное общение, почерпнули друг у друга много нового, договорились о дальнейших контактах. Кроме того, провели встречу со студентами на тему сегодняшнего состояния ИТ-индустрии в России и о перспективах Паскаль-семейства. Студенты получили еще одно подтверждение тому, что я им рассказывал на лекциях, а некоторых преподавателей-сишников, возможно, вскоре удастся "подвинуть" на правильный путь :-))

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


Спасибо за совет!
Про контейнеры я знал, однако в команде авто-птр с векторами используют, мотивируя тем, что во всех "нормальных" реализациях STL вектор не выполняет копирование своих элементов через их =, а выполняет низкоуровневое копирование памяти...

Главное - что Вы в курсе.
Я бы сам, правда, все же поостерегся от употребления auto_ptr с контейнерами.
Наверное, потому что я человек законопослушный: сказано нельзя - значит нельзя! :)