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

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

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

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

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

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

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

Ответ на »сообщение 951« (AVC)
___________________________
Думаю, Ваши абстракции не сильно отличаются от чисто функциональных и, как правило, они имеют вид

x:=f(x,...)

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

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

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

Программированием (в т.ч. и настоящим) все-таки можно заниматься, не вполне представляя себе математические основы своего ремесла; возможно, за счет того, что в учебниках изложены хорошие, универсальные "паттерны".
Программирование - это не обязательно решение задачи математическими средствами. Тот же Ершов достаточно неплохо выделил три вида программирования. Оно может выливаться в конструирование, где математику, скрытую под ногами, знать и не нужно.

Поэтому я так и "встрепенулся", когда info21 помянул теорию множеств (мол, чем грамотнее человек, тем чаще он пользуется теорией множеств (т.к. она является фундаментом чуть ли не всех наших абстракций) и Бурбаки.
Кстати, о теории множеств. Вы смотрели когда-нибудь на язык SETL, созданный в 1970 г.? На программирование IMHO полезно смотреть сквозь призму основных строительных элементов - языков. Я бы выделил такие, "ортогональные", неординарные и наиболее значимые: ассемблер, Forth, Oberon, Smalltalk, Lisp, Prolog, SETL.

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

Наверное, все это выглядит довольно смешно.
Но, все же, помогите (довольно глупому) программисту понять, каким же именно делом он занимется!

Был бы здесь ASU он бы сечас Вам ответил чего-нибудь эдакое...

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

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

И было в моем представлении все довольно стройно и гармонично.
Но после чтения (хотя и по диагонали) книги Мейера об объектно-ориентированном конструировании программных систем, мне пришлось продумать свои мысли на один шаг дальше.
Если АТД -- это математическая модель, то, наверное, и обращаться с ним (АТД) надо соответственно: определить множество, задать операции, определить аксиомы.
Поэтому я так и "встрепенулся", когда info21 помянул теорию множеств (мол, чем грамотнее человек, тем чаще он пользуется теорией множеств (т.к. она является фундаментом чуть ли не всех наших абстракций) и Бурбаки.
Ясно, что аксиомы (свойства АТД) задаются в математической (аппликативной) манере.
Но тут-то я и осознал, что как правило не пользуюсь чисто функциональными (аппликативными) спецификациями.
(Эх, да что греха таить, совсем ими не пользуюсь.)
Тут-то и парадокс.
Я обожаю находить хорошие (как мне кажется, конечно) абстракции и строить из них программы.
Но теперь я стал сомневаться в сознательности того, что я делаю (раз я не определяю всякий раз аксиомы для своих АТД).

Возникают разные предположения.
1) Программированием (в т.ч. и настоящим) все-таки можно заниматься, не вполне представляя себе математические основы своего ремесла; возможно, за счет того, что в учебниках изложены хорошие, универсальные "паттерны".
2) Существует какой-то иной, помимо математики, способ вводить работоспособные абстракции.
3) На самом деле я никогда не пользовался АТД, а просто разделял интерфейс и реализацию. (Только опять же, как я это делал?)
4) И т.д.

Наверное, все это выглядит довольно смешно.
Но, все же, помогите (довольно глупому) программисту понять, каким же именно делом он занимется!

Ответ на »сообщение 949« (Илья Ермаков)
___________________________
В смысле направления. Теория-то есть уже. И не одна.Вопрос, как её представить программисту.

Ответ на »сообщение 948« (12)
___________________________
В смысле?

Ответ на »сообщение 945« Илья Е.
___________________________
Илья, Вам не кажется, что Вы попытались сказать об обратном
переводе?

Ответ на »сообщение 941« (AVC)
___________________________
>>>У того же Мейера: пока чистая спецификация - АТД, как только хоть капелька реализации - уже класс.
Пожалуй тут есть аналогия: АТД - теория множеств, объекты - алгебра (точнее исчисление). Отсюда и отсутствие операций над АТД.