О более новых парадигмах программирования, чем ООП

К сожалению не нашел другого более подходящего раздела для этой новой темы.

Немного о себе: я не считаю себя программистом, так как я не создавал программы с более сложными объектами, чем стандартные визуальные (кнопки, лэйблы, окна и т.д.). Если уделить программированию годы, то наверняка я освою любую методологию программирования. Ведь у меня за плечами: Spectrum48k (Basic, Assembler), немного Delphi7 (Pascal), программирование в промышленных логических языках LD, FBD, SFC. Сейчас пытаюсь освоить С++ (готовность уже на 70%) и среду Qt. Именно в таком порядке я осваивал методологии/технологии программирования.
Из всего ряда особенным образом выделяются языки LD, FBD, SFC. Эти языки привносят в программирование нечто новое, что я постоянно пытаюсь осмыслить. FBD - близок к модели взаимодействия UML. SFC - это аналог модели состояний UML. Помимо этих особенных языков программирования в сфере промышленности используется кибернетическое мышление, системный подход - это тоже отразилось существенно на моем мировоззрении.

При изучении С++ (в версии 99) я пока для себя выяснил следующее: ООП - это парадигма, которая содержит в себе некоторые элементы системного подхода, но пока некоторые ее очень важные фишки не поддерживаются.

Что я хочу получить от общения в этой теме?
1) Я хочу узнать о более новых парадигмах, нежели стандартный ООП. Мне нужны ссылки. Когда-то давно меня обрадовали некоторой парадигмой под названием "Аспектно-ориентированное программирование". Интересная штучка! Она некоторым образом соотносится с моим ходом мысли, но к сожалению нет хорошей литературы, которая бы раскрывала, что собственно дает среда разработки с АОП.
2) Я хочу узнать о более развитых средах разработки нежели QtDesigner и IDE Delphi7. Какая среда в настоящий момент позволяет более эффективно работать с объектами, библиотеками объектов? Где можно более удобно структурировать и переструктурировать приложение?
3) Я хочу рассказать о своих простых и непростых идеях, которые можно было бы применить для повышения эффективности программирования. Но это чуть позже, т.к. может быть я чего-то не знаю.

0

Сообщение от locm Диалектов бейсика очень много и не стоит их ставить в один ряд.

ценное замечание. не будем ставить диалекты бейсика в один ряд с оригиналом. оригинал имеет номера строк и не структурирован. все остальное вторично

0

Тогда уточните какой диалект бейсика вы называете оригиналом? Самый первый бейсик?

Бейск появился в 1964 году, а C++ в 1983 и их некорректно сравнивать, хотя бы потому что бейсик появился почти сразу после появления ЯВУ и возможно в то время, когда программы были небольшими из-за малого объема памяти компа, такой синтаксис с нумерацией был приемлем.

Давайте сравнивать современные версии ЯП, а не те что давно устарели и для практической разработки уже не используются.

0

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

0

Сообщение от pycture все процедурные языки также структурные. ему указали на бейсик. вопросы ?

Из вики.

В соответствии с данной методологией любая программа строится без использования оператора goto из трёх базовых управляющих структур: последовательность, ветвление, цикл; кроме того, используются подпрограммы. При этом разработка программы ведётся пошагово, методом «сверху вниз».

Что мешает в бейсике написать структурную программу? Ведь согласно определению в нем есть ветвления, циклы и подпрограммы.
Напомню что в Сях имеется оператор Goto и на них можно написать быдлокодную неструктурную программу. Так что же давайте и C++ назовем неструктурным языком из-за того что в нем можно использовать оператор Goto и получить сложно читаемый код?

0

Сообщение от locm Из вики.

https://en.wikipedia.org/wiki/BASIC
Unstructured, later procedural, later object-oriented
https://en.wikipedia.org/wiki/... anguage%29
Imperative (procedural), structured
еще вопросы?

0

Сообщение от pycture еще вопросы?

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

К тому же, по вашей ссылке есть раздел Structured BASIC.

0

Сообщение от locm На даты создания языков смотрели? Ничего что бейсик старше Си?

последний раз повторяю. никто це с басиком не сравнивает. изучают начальные парадигмы заложенные в языки. изначально басик неструктурирован, хотя процедуры в нем присуствуют, следовательно процедурный. каким он стал или что могут его диалекты или что там в Second-generation BASICs ни к теме, ни к оригинальному басику не относится

0

Немного возвращаясь к теме, чел со смешными волосами и автор Clojure рассказывает, почему «программирование с изменяемыми состояниями» (к которому относится и ООП) устарело и не соответствует человеческому способу мышления:

0

0

Сообщение от pycture последний раз повторяю. никто це с басиком не сравнивает. изучают начальные парадигмы заложенные в языки. изначально басик неструктурирован, хотя процедуры в нем присуствуют, следовательно процедурный. каким он стал или что могут его диалекты или что там в Second-generation BASICs ни к теме, ни к оригинальному басику не относится

Процедуры там понарошечные. А чего ещё от неоформленных ждать?

0

идея такой парадигмы для ооп
не знаю насколько она была бы применима в реальной жизни
просто люблю подумать :)

назвал её monoref

суть в том, что в любом месте кода любого потока мы можем получить единоличный доступ к любому объекту или N объектов (заблокировать их), причём неважно в какой последовательности они до этого были заблокированы и в каких потоках, и в какой последовательности вы их блочите

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

так вот суть алгоритма

когда мы получаем monoref = из некоего global_ref ( по monoref можно уже работать с объектом )
и если объект заблочен, то пытаемся заблочить поток владеющий этим объектом,
поидее заблочить другой поток можно, когда он сам ожидает кого-либо, т.е. сам находится внутри цикла ожидания и получает команду заморозиться, при этом он сам пытается заморозить другой поток, т.к. ожидает свой объект

в итоге даже при 10 потока работающих с одними и теми же объектами, "выживет" 1 поток который не заморозится и успешно проработает со всеми объектами.

есессно по destructor локального monoref будет также анфризиться и поток владеющий им

0

Сообщение от korvin_ не соответствует человеческому способу мышления

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

Человеку вообще свойственно непрерывно подгонять реальность под свои схемы мышления.

1

Сообщение от iperov назвал её monoref

в DirectX как понимаю lock буфера именно так и работает. причем есть варианты когда лочится не весь буфер а какая то его часть.

Добавлено через 2 минуты

Сообщение от korvin_ Немного возвращаясь к теме, чел со смешными волосами и автор Clojure рассказывает, почему «программирование с изменяемыми состояниями» (к которому относится и ООП) устарело и не соответствует человеческому способу мышления:

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

Добавлено через 3 минуты
Ну и еще вопрос к ФП-никам: почему как только просишь ФП-ников показать ФП аналог какой либо реальной софтины реализованной с помощью ООП(даже если и довольно примитивной), ФП-ники почему то сразу сбегают в другую ветку?

Добавлено через 2 минуты

Сообщение от iperov поидее заблочить другой поток можно то пытаемся заблочить поток владеющий этим объектом

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

Добавлено через 33 минуты

Сообщение от korvin_ почему «программирование с изменяемыми состояниями» (к которому относится и ООП) устарело

Врет и не краснеет. Кроме размеров RAM существует еще и актуальность данных. И никому не надо например позавчерашнее показание датчика угла поворота коленвала автомобиля. Оно нужно исключительно в текущий момент времени. А насчет RAM - так тоже вранье сплошное. На старых компах ОЗУ была на магнитной ленте, что по большому счету не RAM а SAM которую мотать долго, а до этого вообще была перфолента - т.е. SAM с однократной записью. Оттуда все эти идеи про то что нельзя изменять значения переменных и змеятся. С появлением RAM весь этот ФП-бред действительно устарел. А все эта байда смахивает на заказ производителей CPU и RAM которые уже не знают как мотивировать необходимость увеличения быстродействия и объемов. Некуда девать вычислительную мощность - подскажу куда - трассировка лучей и фотонные карты в реальном времени. Так что того на что убить гигагерцы и гигабайты хватит и без ФП.

0

Сообщение от Fulcrum_013 Ну и еще вопрос к ФП-никам: почему как только просишь ФП-ников показать ФП аналог какой либо реальной софтины реализованной с помощью ООП(даже если и довольно примитивной), ФП-ники почему то сразу сбегают в другую ветку?

Ну, ООПшники пока не только не предоставили аналог зависимых типов, но и даже не поняли, что это такое.
Или может предоставишь ООПшный аналог Erlang/OTP?

Сообщение от Fulcrum_013 И никому не надо например позавчерашнее показание датчика угла поворота коленвала автомобиля. Оно нужно исключительно в текущий момент времени.

Ага, после аварии анализировать историю состояний автомобиля будешь по хрустальному шару. Потом ООПшники начинают наворачивать кучу громоздких паттернов, а ля Command с Undo/Redo. Создали себе проблему и превозмогли.

Сообщение от Fulcrum_013 Оттуда все эти идеи про то что нельзя изменять значения переменных и змеятся.

Очередной поток отсутствия хоть каких бы-то ни было знаний в вопросе.

http://c2.com/cgi/wiki?Advanta... rogramming
http://stackoverflow.com/a/1637137

0

Сообщение от korvin_ Ага, после аварии анализировать историю состояний автомобиля будешь по хрустальному шару

Это так ФП-ники баги вылавливают? Хрустальным шаром? Кстати давайте не будем забывать что расчет управляющего воздействия и логгирование данных это разные задачи, тогда и аварии не предвидятся. Кстати "черные ящики" данные тоже переписывают.

Добавлено через 2 минуты

Сообщение от korvin_ Или может предоставишь ООПшный аналог Erlang/OTP?

Который работает на базе виртуальной машины основанной на системе состояний?

Добавлено через 6 минут
Да кстати, если Erlang настолько хорош для создания софта для систем связи то почему Sony Ericson штампует смартфоны под андроид софт на которые пишется на объектно-ориентированной яве?

0

Сообщение от Fulcrum_013 Да кстати, если Erlang настолько хорош для создания софта для систем связи то почему Sony Ericson штампует смартфоны под андроид софт на которые пишется на объектно-ориентированной яве?

системы связи это сотовые коммутаторы (а не быдлофоны), и там он как раз используется чтобы обрабатывать миллионы запросов. Sony Ericson делает мобилки им никакой скорострельности, надежности и рилтайма близко не надо, лишь бы дешего и работало.

0

Сообщение от pycture системы связи это сотовые коммутаторы (а не быдлофоны), и там он как раз используется чтобы обрабатывать миллионы запросов.

Дешего - это когда не надо перепроектировать протокол обмена при внесении каждой мелочи. Оно же еще и надежно. К приемру DCOM в этой области вооще прекрасная штука. Фактически нет разных процессов на клиенте и сервере. Есть процесс выполняемый как клиентом так и сервером, каждым свою часть. А система запрос/ответ в этом плане далеко не фонтан.

Сообщение от pycture Sony Ericson делает мобилки им никакой скорострельности, надежности и рилтайма близко не надо, лишь бы дешего и работало.

А так же язык Erlang. Кстати оные быдлофоны без скорострельности/надежности/риалтайма трындеть не будут а только квакать. Хотя на самом деле это не телефоны а терминалы, и задача коммутаторов не запросы обрабатывать, а синхронизация данных между терминалами. На одном в микрофон трындят, буфер синхронно появляется на другом. Без терминалов все эти коммутаторы ничего не стоят. А по надежности и риалтайму - так Siemens лет 20 как минимум в каждой линейке мобил держит терминал под АСУ-ТП. Итнересно, а те кто пишут что Erlang сверхпродвинутая технология в плане синхронизации данных на разных девайсах ее с DirectPlay сравнивали?

0

Ну вот, появился еще эрудит - и троллинг вспыхнул с новой силой

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

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

1

Сообщение от Igor3D Очевидно что ругая ООП человек хвалит сам себя. Типа "смотрите, все (ну или большинство) парятся с отсталыми технологиями - а вот Я не такой, Я умный, прозорливый и иду верным путем".

С огромной долей вероятности он вообще никаким путем не идет. А только ведет. Холивары.

Добавлено через 11 минут

Сообщение от Igor3D Ах ну да, у ООП мощное "лобби" и все такое - да вообще "от людей правду скрывают"

Хотя в ООП тоже нужны кое какие изменения на уровне компиляторов. К примеру возможности мутации объектов. Как возможность замены указателя на VMT без пляски с бубном, так и к примеру возможность делать часть VMT локальной, с возможностью перезаписей указателей на отдельные методы. т.е. Дать объектам функции мутирования. Оно во многих местах жизню бы облегчило. А то ручками таких мутантов организовывать - обычно та еще пляска с бубном.

0

Сообщение от Fulcrum_013 К примеру возможности мутации объектов. Как возможность замены указателя на VMT без пляски с бубном, так и к примеру возможность делать часть VMT локальной, с возможностью перезаписей указателей на отдельные методы. т.е. Дать объектам функции мутирования. Оно во многих местах жизню бы облегчило. А то ручками таких мутантов организовывать - обычно та еще пляска с бубном.

В нормальных ОО-системах (CLOS, SmallTalk и т.п.) это есть из коробки без необходимости хакать компилятор.

Сообщение от Igor3D Очевидно что ругая ООП человек хвалит сам себя. Типа "смотрите, все (ну или большинство) парятся с отсталыми технологиями - а вот Я не такой, Я умный, прозорливый и иду верным путем". Все это просвечивает "белыми нитками" в постах умников

Очевидно, что, ругая процедурное программирование, человек хвалит сам себя...

Ну ты понял, да?

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

Я тебе открою страшную тайну: ООП "появилось" аж в 67-м году (Simula 67), но "массово побежали на него" лишь в 90-х, ближе к середине и после. Выводы сам сделаешь?

0