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

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

Немного о себе: я не считаю себя программистом, так как я не создавал программы с более сложными объектами, чем стандартные визуальные (кнопки, лэйблы, окна и т.д.). Если уделить программированию годы, то наверняка я освою любую методологию программирования. Ведь у меня за плечами: 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

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

Тыкалка видимо слишком молода, все это происходило на моих глазах. Какая там "середина", уже в 89-м был Turbo-Pascal 5.5 с кое-каким OOП, а еще через год все уже писали "с классами". И это всего через неск лет после появления "персоналок" Вот это "прорыв", я понимаю. А тут что? Есть какая-то (крутая) система которая использовалась там-то... И что?

0

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

Для этого не надо хакать компилятор даже в С и фортране. Просто VMT надо собирать ручками. Т.е. не пользуясь ООП возможностями компилятора.

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

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

0

Сообщение от Igor3D Turbo-Pascal 5.5 с кое-каким OOП

Смешно.

Сообщение от Igor3D а еще через год все уже писали "с классами"

Кто "все"? Все студенты совковых ПТУшек? И "писать с классами" и "писать с использованием ООП" --- разные вещи.

Реальная массовая популярность пришла в середине 90-х вместе с Java.

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

Сообщение от Fulcrum_013 А побежали массово в 90-ых только потому что разработка оконных интерфейсов без ООП - это вооще ужас, мало того появились индустриальные ООП-фреймверки для массового создания оболочек, поэтому тем кто не осилил ООП хотя бы в плане пользователя ООП-фреймверков в индустрии место начало теряться. До этого ООП был удел ГУРУ

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

0

Сообщение от korvin_ Реальная массовая популярность пришла в середине 90-х вместе с Java.

Turbo Vision,OWL, MFC, VCL - типа для мебели? А это как раз начало-середина 90-ых.

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

Сообщение от korvin_ А тем временем во все популярные языки уже добавили, как минимум, замыкания.

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

0

Сообщение от Fulcrum_013 ООП как понимаю появилось раньше. В симуле просто ввели поддержку ООП средствами компилятора. А побежали массово в 90-ых только потому что разработка оконных интерфейсов без ООП - это вооще ужас, мало того появились индустриальные ООП-фреймверки для массового создания оболочек, поэтому тем кто не осилил ООП хотя бы в плане пользователя ООП-фреймверков в индустрии место начало теряться. До этого ООП был удел ГУРУ

"До этого" были "большие" (ЕС) машины, перфокарты, магнитные ленты - и пусть там симула что угодно придумала, это никого не волновало. Да и вообще "программист" была профессия женская (да-да).

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

0

Сообщение от Igor3D Да и вообще "программист" была профессия женская (да-да).

Это в СССР так обычно называли вообще всех эникейщиков, особенно во времена массовой компьютеризации. Насмотрелся на таких горе - программистов. Сидят контрольные суммы в распечатке пересчитывают на счетах и обсуждают когда им категорию поднимут. вообще название "программист" в совдеповской действительности
обозначает "специалист по по" но не обязательно разработчик.

Сообщение от korvin_ Ну вот ты только что ответил на свой же вопрос про отсутствие массового побега на ФП.

Точно так же ФП было доступно вручную с времен появления косвенного вызова. Но почему то в компиляторы внесли именно поддержку ООП а не ФП и "бег" состоялся на ООП но не ФП

0

Сообщение от Fulcrum_013 Turbo Vision,OWL, MFC, VCL - типа для мебели?

VCL-то точно для мебели, а MFC не пнул только ленивый. Ты ещё PDO забыл.
Кроме того, Майкрософт, знаешь ли, сейчас и F# пилит, весь такой функциональный. И угадай, кто основной разработчик GHC (Glasgow Haskell Compiler)?

Сообщение от Fulcrum_013 А это как раз начало-середина 90-ых.

О чём я и говорил, массовое увлечение ООП пришлось на 90-е, ближе к середине, во многом благодаря коммерческому успеху Java.

Сообщение от Fulcrum_013 Для глобальной (стратегической) - АОП гораздо удобней.

Так правильней.

Сообщение от Igor3D "До этого" были "большие" (ЕС) машины, перфокарты, магнитные ленты

И? Моя отсылка к истории была к тому, что ООП тоже не было "мэйнстримом" сразу с момента создания. А твоя к чему?

Сообщение от Igor3D и пусть там симула что угодно придумала, это никого не волновало

Лол, некоторых это волновало. Например Алана Кея, Бьёрна Страуструпа

The creator of C++, Bjarne Stroustrup, has acknowledged that Simula 67 was the greatest influence on him to develop C++

--- https://en.wikipedia.org/wiki/Simula
Собственно весь этот ваш "мэйнстримный ООП" (C++, Delphi, Java, C#) по сути вариации на тему Симулы.

Сообщение от Igor3D Ну так А ЧТО ВЗАМЕН?

Очевидно же: FP и Concurrency.

Сообщение от Igor3D могучие парадигмы которые сделают из любого лоха программиста

Ты что-то путаешь, различные подходы к программированию не для этого придумываются. Для этого есть JS и PHP.

Сообщение от Igor3D Почему я их в упор не вижу?

Может, зрение с возрастом стало подводить? Между тем, применения и статей по всяким Хаскеллам, Скалам и прочему ФП всё больше и больше (в долевом отношении).

https://news.ycombinator.com/item?id=9824477
http://www.ibm.com/developerworks/library/j-ft20/
https://medium.com/@jugoncalve... dd4641d6b9

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

Сообщение от Fulcrum_013 Точно так же ФП было доступно вручную с времен появления косвенного вызова.

Так ты же не понимаешь, что такое ФП. Эти ваши указатели на функции не имеют к ФП такое же отношение, как структуры к ООП.

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

Сообщение от Fulcrum_013 Но почему-то в компиляторы внесли именно поддержку ООП а не ФП

До С++ всё ООП было жутко тормозное по сравнению с "сырой процедурщиной", поэтому никого кроме исследователей не интересовало. Напомню также, что первые Плюсы были всего лишь набором макросов для Си, без всякого "внесения в компиляторы".

0

Сообщение от korvin_ До С++ всё ООП было жутко тормозное по сравнению с "сырой процедурщиной"

Ничего подобного. Та же сырая процедурщина, только структурированная. Не cчитая indirect call, количество которых в этой сырой процедурщине тоже зашкаливать начало, потому и начали сооружать поддержку структурирования и проверки компилятором применимости к наборам данных. Так ООП и появился из сырой процедурщины.

0

Отмечу что изначальная тема была не перетирать косточки ФП/ООП, а более новые парадигмы, АОП в частности.
Есть у кого что сказать насчёт этого или тема себя исчерпала?

0

жи есть

0

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

0

Сообщение от Fulcrum_013 А так же язык Erlang

какое отношение сону имеет к эрлангу? привильный ответ никакого.

Кстати оные быдлофоны без скорострельности/надежности/риалтайма трындеть не будут а только квакать.

что они собственно и делают.

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

иксперт однако.. ну-ну.. еще че расскажешь?

Erlang сверхпродвинутая технология в плане синхронизации данных на разных девайсах ее с DirectPlay сравнивали?

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

0

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

0

Сообщение от pycture хотя что ожидать то, ты даже сервер от клиента не отличаешь . ну предложи еще сравнить телевышку с телевизором.

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

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

Сообщение от pycture какое отношение сону имеет к эрлангу? привильный ответ никакого.

Зато Ericson абсолютно прямое. вопрос прям из серии какое отношение Siemens имеет к телефонам Fujitsu при том что Siemens есть дочерняя компания Fudjitsu.

Добавлено через 1 час 10 минут

Сообщение от korvin_ Очевидно же: FP и Concurrency.

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

0

Сообщение от Fulcrum_013 Перед тем как что либо параллелить стоит хорошо подумать а надо ли параллелить?

Прежде чем задавать такие вопросы, стоит хорошо подумать, почему concurrency != parallelism.

0

Сообщение от Fulcrum_013 Зато Ericson абсолютно прямое. вопрос прям из серии какое отношение Siemens имеет к телефонам Fujitsu при том что Siemens есть дочерняя компания Fudjitsu.

и? с понятием разделения и продажи бизнеса совсем не знаком? то что эриксон продал _мобильное_ подразделение сони никоим образом не приобщает последнюю ни к коммутаторам, ни к эрлангу. с сименсом тоже самое.

0

Сообщение от korvin_ Прежде чем задавать такие вопросы, стоит хорошо подумать, почему concurrency != parallelism.

Во-во, только протрмозка на таск свитчинге и ожидании ресурсов.

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

Сообщение от pycture и? с понятием разделения и продажи бизнеса совсем не знаком? то что эриксон продал _мобильное_ подразделение сони никоим образом не приобщает последнюю ни к коммутаторам, ни к эрлангу. с сименсом тоже самое.

Про минимизацию налогов и пошлин не слышали? Для Европы Siemens принадлежит Fujitsu, для Азии - Fujitsu принадлежит Siemens, в результате одна корпорация которая подпадает под печенюшки для иностранных инвесторов и в Европе и в Азии. То же самое и с Sony Ericson

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

Сообщение от korvin_ Прежде чем задавать такие вопросы, стоит хорошо подумать, почему concurrency != parallelism.

J О каком параллелизме может идти речь при 70 процессах и 1500 потоках на после старта винды, на 4 несчастных конвейера? Если вообще хоть как то можно о параллелизме разговаривать, то разве что на CUDA и мэйнфрэймах.

0

Сообщение от Fulcrum_013 Во-во, только протрмозка на таск свитчинге и ожидании ресурсов.

Ну-ну. Эксперт в треде.

Further still, analogous context switching happens between user threads, notably green threads, and is often very light-weight, saving and restoring minimal context. In extreme cases, such as switching between goroutines in Go, a context switch is equivalent to a coroutine yield, which is only marginally more expensive than a subroutine call.

--- https://en.wikipedia.org/wiki/Context_switch

Вот ещё информация для расширения кругозора:
http://dave.cheney.net/2015/08... event-loop

0

Сообщение от korvin_ Ну-ну. Эксперт в треде.

Если потоков больше чем конвейеров то будут только протормозки при переключении и не более. Мало того что необходимо сохранение/восcтановление всех регистров, так придется еще и кеш перегружать в конечном итоге.

Добавлено через 7 минут
И чем больше раздут стек, тем больше придется перегружать в кеш.

0

Понятно. Чукча не читатель. Так бы сразу и написал.

0