Форум программистов
 

Восстановите пароль или Зарегистрируйтесь на форуме, о проблемах и с заказом рекламы пишите сюда - alarforum@yandex.ru, проверяйте папку спам!

Вернуться   Форум программистов > IT форум > Общие вопросы по программированию, компьютерный форум
Регистрация

Восстановить пароль
Повторная активизация e-mail

Купить рекламу на форуме - 42 тыс руб за месяц

Ответ
 
Опции темы Поиск в этой теме
Старый 11.06.2009, 11:17   #51
BaronTreep
Форумчанин
 
Регистрация: 29.05.2009
Сообщений: 320
По умолчанию

Цитата:
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, как раз, там после объявления класса не нужно второй раз определять методы класса - только внутри него.
BaronTreep вне форума Ответить с цитированием
Старый 11.06.2009, 11:40   #52
atomicxp
Форумчанин
 
Аватар для atomicxp
 
Регистрация: 01.05.2009
Сообщений: 110
Радость

Цитата:
Сообщение от pu4koff Посмотреть сообщение
Вы вероятно не совсем понимаете что такое интерфейс.
Не волнуйся, я понимаю. Даже знаю такие страшные слова как полиморфизм через наследование и полиморфизм через интерфейс.
atomicxp вне форума Ответить с цитированием
Старый 11.06.2009, 11:55   #53
atomicxp
Форумчанин
 
Аватар для atomicxp
 
Регистрация: 01.05.2009
Сообщений: 110
По умолчанию

Цитата:
Сообщение от BaronTreep Посмотреть сообщение
Судя по этим классификациям C++ -> C далеко не лидеры. Но это незаменимые инструменты для СИСТЕМНОГО программирования.
Там дело не в том что язык умеет или не умеет, если вкратце, то и C++ и C# предоставляют весь уровень абстракции который мне нужен, так же как и Java и некоторые другие. К сожалению в C# подкачала функциональность библиотек и способ реализации в виде виртуальных машин. Тоже самое могу сказать о Java, и хотя она приемлимо кроссплатформенна, но с учётом того какой прогресс осуществили кроссплатформенные опенсорс библиотеки это как-то уже не актуально.

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

Причём количество перерастает в качество, дублирования кода не допустимы. Я согласен насчёт краткой формы, естественно под этим подразумеваю не количество символов, а количество используемых для построения элементов с поправкой на всю систему.
atomicxp вне форума Ответить с цитированием
Старый 11.06.2009, 13:24   #54
BaronTreep
Форумчанин
 
Регистрация: 29.05.2009
Сообщений: 320
По умолчанию

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

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

Код:
 Arr.size
Arr.min
Arr.max
Arr.sort
Arr.sort.reverse
Arr.find_all
Arr.map
# и т.д. и т.п.
Получается и удобно и кратко, на уровне определения.

А если вернуться к файлам и сокетам, то ничего не мешат мыслить в том же направлении - использовать класс IO с двумя методами:
Код:
 ... = IO.read(...)
IO.write(..., ...)
И в зависимости от типа аргументов это будет общение с файлами, с сокетами или ещё с чем-то. + зашить все проверки открытия/закрытия и исключений в сами методы, потому что это стандартный код и нет смысла его повторять каждый раз.
BaronTreep вне форума Ответить с цитированием
Старый 11.06.2009, 14:44   #55
atomicxp
Форумчанин
 
Аватар для atomicxp
 
Регистрация: 01.05.2009
Сообщений: 110
Хорошо

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

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

Даже если учесть, что в C++ это будет класс построенный по некоторому принципу, то есть по патерну проектирования называемого интерфейсом. В связи с этим существует интересная концепция UML для отображения проектируемой системы в графическом виде. И естественно стереотипы, которые помогают упорядочить программистам свои мысли, ну и заодно понимать друг друга.
atomicxp вне форума Ответить с цитированием
Старый 22.06.2009, 13:19   #56
mustaf0id
 
Регистрация: 05.05.2009
Сообщений: 9
По умолчанию

Что касается функционального программирования, по моему наиболее важная его характеристика - то что функции не имеют побочного эффекта, и необходимой абстракции (например, подобно const для переменных, чтобы функция могла записывать только в локальные переменные и вызывать только функции, также не имеющие побочного эффекта, а считывать только из своих параметров) в C++ нет. Но с учетом наличия в C++ указателей вообще сомнительно, что там возможна реализация такой абстракции. Т.е. конечно предполагается что функтор сравнения который передается в тот же std::sort ничего там не будет модифицировать, но языком его возможности никак не ограничены =). В Хаскеле это очень удобно тем, что подобные функции легко тестировать и вообще при таких ограничениях труднее сделать ошибку . Кроме того, с оптимизацией подобных функций компилятору было бы проще...
mustaf0id вне форума Ответить с цитированием
Старый 15.11.2009, 03:04   #57
MasterGH
Пользователь
 
Аватар для MasterGH
 
Регистрация: 08.11.2009
Сообщений: 16
По умолчанию

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

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

Последний раз редактировалось MasterGH; 15.11.2009 в 03:09.
MasterGH вне форума Ответить с цитированием
Ответ


Купить рекламу на форуме - 42 тыс руб за месяц

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
в поисках органайзера crazy horse Софт 6 11.02.2008 16:56
Нахождение совершенных чисел. Паскаль NikLik Помощь студентам 3 23.11.2007 22:19