В поисках совершенных абстракций

[BaronTreep]

1. процедурное - данные как аргументы
2. функциональное - функции как аргументы

Можно ещё выделить различия.

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

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

3. обобщённое - типы как аргументы
4. объектно-ориентированное - создание типов

А вот с точки зрения ООП - всё объект. Тип = Класс. Аргумент - экземпляр класса. А любое действие имеет смысл только как метод класса. Получается такая иерархия - если в данный момент мы занимаемся одним объектом, то нам не надо думать о других, а если объект уже реализован, то его можно безопасно и просто использовать.



Вот есть три интересные ссылки, сравнения языков по всевозможным критериям и собственно сами возможные критерии:

http://ru.wikipedia.org/wiki/Сравнен...ограммирования
http://www.rsdn.ru/forum/philosophy/1905860.1.aspx
http://www.prowiki.org/wiki4d/wiki.cgi?LanguagesVersusD

Судя по этим классификациям C++ -> C далеко не лидеры. Но это незаменимые инструменты для СИСТЕМНОГО программирования.

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

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

[atomicxp]

Сообщение от pu4koff

Вы вероятно не совсем понимаете что такое интерфейс.

Не волнуйся, я понимаю. Даже знаю такие страшные слова как полиморфизм через наследование и полиморфизм через интерфейс.

[atomicxp]

Сообщение от BaronTreep

Судя по этим классификациям C++ -> C далеко не лидеры. Но это незаменимые инструменты для СИСТЕМНОГО программирования.

Там дело не в том что язык умеет или не умеет, если вкратце, то и C++ и C# предоставляют весь уровень абстракции который мне нужен, так же как и Java и некоторые другие. К сожалению в C# подкачала функциональность библиотек и способ реализации в виде виртуальных машин. Тоже самое могу сказать о Java, и хотя она приемлимо кроссплатформенна, но с учётом того какой прогресс осуществили кроссплатформенные опенсорс библиотеки это как-то уже не актуально.

Сообщение от BaronTreep

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

Мне думается что различия на верхнем уровне в парадигме (ментальной модели) программирования. Далее программисты спускаются в более детальное рассмотрение систем, которые они создают. На высшем уровне этого развития они обретают способность писать код не как попало, а используя жёстко заданные патерны проектирования.

Причём количество перерастает в качество, дублирования кода не допустимы. Я согласен насчёт краткой формы, естественно под этим подразумеваю не количество символов, а количество используемых для построения элементов с поправкой на всю систему.

[BaronTreep]

жёстко заданные патерны проектирования

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

Вот так примерно и сделано в Ruby: есть массив Arr и можно писать

 Arr.size
Arr.min
Arr.max
Arr.sort
Arr.sort.reverse
Arr.find_all
Arr.map
# и т.д. и т.п.

Получается и удобно и кратко, на уровне определения.

А если вернуться к файлам и сокетам, то ничего не мешат мыслить в том же направлении - использовать класс IO с двумя методами:

 ... = IO.read(...)
IO.write(..., ...)

И в зависимости от типа аргументов это будет общение с файлами, с сокетами или ещё с чем-то. + зашить все проверки открытия/закрытия и исключений в сами методы, потому что это стандартный код и нет смысла его повторять каждый раз.

[atomicxp]

Я как бы уже писал выше, надо использовать полиморфизм и стараться руководить кодом через полиморфные интерфейсы (и не важно чем они представлены). Проблема тех же сортировок и прочих функций в том, что их можно использовать с техникой функционального программирования, как и делается в стандартных и расширенных библиотеках C++.

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

Даже если учесть, что в C++ это будет класс построенный по некоторому принципу, то есть по патерну проектирования называемого интерфейсом. В связи с этим существует интересная концепция UML для отображения проектируемой системы в графическом виде. И естественно стереотипы, которые помогают упорядочить программистам свои мысли, ну и заодно понимать друг друга.

[mustaf0id]

Что касается функционального программирования, по моему наиболее важная его характеристика - то что функции не имеют побочного эффекта, и необходимой абстракции (например, подобно const для переменных, чтобы функция могла записывать только в локальные переменные и вызывать только функции, также не имеющие побочного эффекта, а считывать только из своих параметров) в C++ нет. Но с учетом наличия в C++ указателей вообще сомнительно, что там возможна реализация такой абстракции. Т.е. конечно предполагается что функтор сравнения который передается в тот же std::sort ничего там не будет модифицировать, но языком его возможности никак не ограничены =). В Хаскеле это очень удобно тем, что подобные функции легко тестировать и вообще при таких ограничениях труднее сделать ошибку . Кроме того, с оптимизацией подобных функций компилятору было бы проще...

[MasterGH]

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

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