Может потому, что сама парадигма полностью реализована в полутора языках, а все остальное - только элементы или частичная поддержка

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

ОО-среда должна быть «живой», т.е. меняться (реагировать) в зависимости от условий и входных данных.

man паттерны. Они хотя бы понятны, т.к. сразу понятно, где искать концы.

Но это лирика, на практике обмен сообщениями - более верный подход, нежели кривой вызов методов объектов, как это в тех же плюсах

На чьей практике?

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

Очередная жертва шаблонов. Для меня точно также Scala и Common Lisp являются функциональными языками (радикальных пуристов прошу не беспокоиться). Именно это я вкладываю в смысл понятия «гибридный или мульти-парадигменный язык программирования». Развивать эту тему дальше не имею желания, хотя в интернете часто видел как пристают к тем, кто назвал что-то функциональным или объектно-ориентированным языком, когда в глазах некоторых есть только один функциональный язык (haskell) и только один истинно объектно-ориентированный (smalltalk). Таких приставунчиков я обычно посылаю мысленно в далекое пешее эротическое путешествие. Могу и не только мысленно, но и озвучить при необходимости.

Ну и какие принципы ООП не реализуются в CL?

Да даже хотя бы то, что в CL не все есть объект.

Не «не полная», я не чистая, тогда уж. Если не чистые системы считать неполноценными, то вам всегда придется довольствоваться одной парадигмой. Я считаю это скорее крупным минусом среды, нежели плюсом.

Вот с этим согласен. Просто говоря о ООП-языке, мы говорим о чистой, полной поддержке ООП. Говоря о функциональном языке - мы говорим о чистой, полной поддержке ФП. Если язык мультипарадигменен и дает возможность на имеративщину насобачивать кучу сахара, свителок и перделок - то давайте это так и называть, а не убеждать, что скажем CLOS = чистое/полное ООП. Элементы ООП, достаточно удобные, с возможностью макросов - да. Но того, что вы получите от смаллтолка и разработке в его среде и экосистеме - не получите в CLOS.

Я вообще не вижу ни одной ниши, где плюсам не было бы замены

Числодробилки же. Упреждая вопрос о фортранах и пр.: www.linux.org.ru/wiki/en/User:AIv/LRnLA в самом конце.

Очередной унылый срач получился...

Т.е. в лиспе есть то, что не является объектом

А что значит «являться объектом»?

Ну и какие принципы ООП не реализуются в CL?

Да даже хотя бы то, что в CL не все есть объект.

ну и? Методы по тому же Integer можно диспатчить? Можно. Что ещё надо? Или ты хочешь как в ruby писать 42.times { puts «hello world» } ? Это уже слегка перебор.

Но того, что вы получите от смаллтолка и разработке в его среде и экосистеме - не получите в CLOS.

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

Представим себе Лисп систему, допустим CL, из которого выкинули все императивные операции в принципе, все мутабельное состояние и т.п. посредством какого-нибудь (shadow-symbol), дописали оставшиеся части рантайма Haskell. Получится ли у нас чистый функциональный язык? Теперь то же самое, но выкидываем уже все, что не объект или работает не с объектом. Тот же вопрос.

Числодробилки же.

Да ну. Из коробки не параллелится, прямой поддержки в языке и оптимизаций в ядре соответствующих нет (для fp80, векторов, там вот этого всего). Лучше уже тогда Matematica всякая и прочие Matlab'ы.

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

man паттерны. Они хотя бы понятны, т.к. сразу понятно, где искать концы.

А что не понятного в классах?

На чьей практике?

Хотя бы телекоммуникации.

Очередная жертва шаблонов. Для меня точно также Scala и Common Lisp являются функциональными языками (радикальных пуристов прошу не беспокоиться). Именно это я вкладываю в смысл понятия «гибридный или мульти-парадигменный язык программирования». Развивать эту тему дальше не имею желания, хотя в интернете часто видел как пристают к тем, кто назвал что-то функциональным или объектно-ориентированным языком, когда в глазах некоторых есть только один функциональный язык (haskell) и только один истинно объектно-ориентированный (smalltalk). Таких приставунчиков я обычно посылаю мысленно в далекое пешее эротическое путешествие. Могу и не только мысленно, но и озвучить при необходимости.

Если бы сразу назвали гибридным языком - не имел бы вопросов

А что значит «являться объектом»?

Мне и правда приводить цитату из блю-бук?

по ссылочке сходите

ну и? Методы по тому же Integer можно диспатчить? Можно. Что ещё надо? Или ты хочешь как в ruby писать 42.times { puts «hello world» } ? Это уже слегка перебор.

А что в этом плохого?

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

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

Представим себе Лисп систему, допустим CL, из которого выкинули все императивные операции в принципе, все мутабельное состояние и т.п. посредством какого-нибудь (shadow-symbol), дописали оставшиеся части рантайма Haskell. Получится ли у нас чистый функциональный язык? Теперь то же самое, но выкидываем уже все, что не объект или работает не с объектом. Тот же вопрос.

Лисп тут не очень хороший пример. Что-то подобное сделали в свое время с Prolog и получили Erlang. Получилось годно.

Я допускаю, что эта задача может быть эффективно решена на Лиспе.

Ну значит Matematica и прочие Julia отлично справятся, что не так, то?

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

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

Лисп тут не очень хороший пример. Что-то подобное сделали в свое время с Prolog и получили Erlang. Получилось годно.

Значит работает подход, в принципе.

Мне и правда приводить цитату из блю-бук?

Да.

Но того, что вы получите от смаллтолка и разработке в его среде и экосистеме - не получите в CLOS

Чего например?

то что это нифига не критерий «объекта». В лиспе то же самое будет выглядеть как (times 42 #'(lambda () (princ «Hello world»))), и я так же могу обозвать 42 объектом.

очень большая проблема фанатов ООП в том, что мало кто из них может чётко сформулировать что такое ООП.

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

Дальше сам найдешь)

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

Это не критерий, пока не копаешь как оно работает. Приведенный код на лиспе и руби имеют разные механизмы работы.

Стоит ли его изучать?

IMHO, стоит.

Почему — ну он довольно выразительный и практичный. Есть условно говоря, «новое поколение» ООП, развившееся за последние 10 лет. Это языки Google Пщщ Go и Digital Mars D.

Оба языка призваны изменить не «теорию программирования», а практику. В обоих есть две центральные идеи, ради которых эти языки вообще имеют смысл.

Это «ad hoc интерфейсы» в Go и метапрограммирование через CTFE функции в D.

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

ИМХО, профит есть.

Есть инструментарий, призванный поддержать основные этапы жизненного цикла разработки программ. Например, скачивание и установку новых версий библиотек (пакетный менеджер), тестирование (юнит-тесты), профилирование. В Go это команда go install/go test/ , в D — есть пакетный менеджер Orbit (на github), который пытается повторить go install, есть dmd -unittest «из коробки».

Хотя вообще такие вещи можно делать через maven и jenkins, например (пакетный менеджер с репозиториями и continuous integration ферма с (авто)запуском юниттестов). Так и делают, см. например lycus.org .

(продолжение)

Может ли он стать достойной заменой плюсам?

Как бы тебе сказать... С точки зрения функциональности — это уже замена. С точки зрения того, что код на D — это код на другом языке, которого ещё нет, а код на плюсах — уже есть, это проблемно. С точки зрения того, что язык плюсы знают (или делают вид, что знают) все кому не лень, а язык D знают полтора анонимуса и то все тусуются в нюьсгруппе, это проблемно. Например, OpenMorrowwind, FLTK — это примеры, когда код проектов был изначально написан на D1, но переписан на плюсы в итоге, потому что плюсопрограммеров в разы больше.

С другой стороны, процентов 90% D программеров по совместительству плюсопрограммеры.

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

Язык С++ сам по себе представляет собой проблему. Потому что:

а) это только язык, то есть, только часть из этапов жизненного цикла разработки программ. Язык как система, как метод должен облегчать все эти этапы. Язык как «затычка» пытается решить только один этап — кодирование, да и это язык-затычка С++ делает плохо.

б) язык «три в одном»: плоский си, классы, шаблоны. В итоге, вместо простого набора «ортогональных» (взаимонезависимых) концепций мы имеем ненужные сложности и громоздкости. У изучающего такой язык нет полной картины, что такое язык — вместо того, чтобы заниматься смыслом программы (семантикой), он борется с синтаксисом и подходя к станку, долго думает, какой подъязычок ему выбирать.

в) отсутствует модульность

г) язык слишком низкоуровневый.

д) велика фрагментация. Например, компиляторозависимость: GNU C++, MSVC, Intel C++, clang, и прочие типа dmc, openwatcom, tendra, open64, comeau/...

Можно, конечно считать референсной имплементацией gnu c++. Но в итоге реальный код на С++ — это код на какой-то имплементации компилятора, а не на С++.

ё) язык ещё долго никуда не денется.

С другой стороны, есть и плюсы плюсов. Это:

г) язык слишком низкоуровневый.

а) язык не принадлежит какой-то одной компании.

ё) язык ещё долго никуда не денется.

Какие у него области применения?

те же, что и у С++, Java, C#.

(окончание)

Говорят, сейчас он сырой, а что именно сыро?

Во-первых, для ознакомления с текущим состоянием языка, изучать его лучше по книжке Андрея Александреску «Язык программирования D».

Там описана последняя, актуальная версия D2, на немного «изменяющих сознание» примерах (в том смысле, что если уже знаешь плюсы, становится совсем грустно и печально за плюсы, и наоборот, компактность и выразительность языка D — радует).

Во-вторых, есть текущее состояние реализаций языка. Это компиляторы dmd от Волтера Брайта и Digital Mars https://github.com/D-Programming-Language/dmd , компилятор GNU D (gdc) https://github.com/D-Programming-GDC/GDC , компилятор LLVM ldc https://github.com/ldc-developers/ldc , компилятор для .NET http://dnet.codeplex.com/ , компилятор D на самом D https://github.com/bhelyer/SDC .

Список отсортирован «по зрелости» и эффективности. Первая реализация от Волтера Брайта, автора языка — авторская. Библиотеки (druntime/phobos, аналоги C runtime/glibc) разрабатываются сообществом, но Волтер и Александреску определяют основную «политику партии». Gnu D компилятор довольно неплохо оптимизирует, кроме того есть порты кросскомпилятора на mingw или android. ldc неплохой LLVM компилятор. Имеет смысл, если нужно завязываться на какие-то преимущества LLVM. D.NET — проект вроде как брошен. Работает, однако, но что там с разработкой проекта и дальнейшем развитием — полное х.з.

SDC --- подаёт надежды. Когда-нибудь, лет через 5 будет самодостаточный D компилятор.

В-третьих, есть текущее состояние конкретной реализации. Например, если взять dmd, D2, phobos, и посмотреть.

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

с другой стороны, в D сборщик мусора можно и отключить (и использующими его конструкциями не пользоваться). Как пример, см. исходники ядра операционной системы xombb на гитхабе.

б) эффективность реализации хеш-таблиц под вопросом. Исходники есть, можно переписать на свою реализацию (или использовать свою библиотеку со своим API).

в) сам тулчейн dmd довольно архаичен. dmd, optlink, zortech make, и т.п.

С тулчейном такая ситуация: когда появился D, был готовый компилятор для C++ под винду 32-битную, который был переписан. Остальное жуткое легаси осталось. Когда D стал поддерживаться под Linux, FreeBSD, MacOSX, в качестве тулчейна начал использоваться gcc. Там этих легаси проблем нет.

Ну и, когда появился win64 dmd, там тулчейн тоже был довольно серьёзно похакан/переписан. Там тоже проблем меньше.

Проблемы же с win32 тулчейном следующие — в реально больших приложениях (как например, в игрушке от h3r3tic) компилятор выдавал ICE, а линкер Optlink сыпался в странных местах. Линкер был написан на ассемблере, исходники, ЕМНИП, потеряны, так что нужно просто переписать это окаменевшее легаси мамонта на самом D и забыть о проблеме.

Ну, ещё в багзилле время от времени появляются проблемы языка/тулчейна.

С новыми релизами они как правило, фиксятся.

Всё — накипело. ... Причины предстоящего демарша в другом:

Язык медленно развивается. Многие возможности, которые нужны и полезны стоят в запросах на багзилле с 2006 года и раньше. Их отсутствие в реализации ведет к костылям и обходным путям, которые не добавляют программе красоты и стабильности.

пример?

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

сейчас не сказал бы... довольно активно разрабатывается. Про регрессии, ломающие код — так это как раз обратная сторона активности

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

пример? сейчас не сказал бы, что это так уж актуально. Например, в книге Александреску описаны многие тонкие места насчёт pure/immutable/константости и т.п. не нравится стд. библиотека — пиши в ньюсгруппу, багзиллу, пулл реквесты на гитхаб. совсем не нравится — не используй, используй свой велосипед

Библиотеки, которые не компилируются и не поддерживаются. Надоело скачивать крупную библиотеку типа GtkD и несколько часов пытаться её скомпилировать. Надоели библиотеки, которые брошены и не поддерживаются.

частично это должен пофиксить пакетный менеджер вроде Orbit. Кстати, для Gtk2/3 есть более новая библиотека, использует новомодный UFCS синтаксис (когда window.open(a,b,c) = open(window,a,b,c) ) . см. на гитхабе, анонс в ньюсгруппе.

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

ни разу не проблема. Есть ньюсгруппы, читаем/постим нормальным ньюсридером. Для детишек из поколения веб 2.0 есть очень быстрый форум.

Какие-то дрязги по походу разработки. Вечный срач между разработчиками новой стандартной библиотеки и одной из старых (Tango). Вместо того, чтобы объединить усилия, каждый тянет одеяло на себя.

сейчас нет такого — Tango окаменевшее говно мамонта, которое для D2 не актуально (да и пару лет назад, разработка Tango велась по минимуму, типа теперь код собирается новым релизом dmd, и всё). Разработка phobos куда активнее. Все основные разработчики представлены на гитхабе, Волтер реагирует на пуллреквесты. Компиляторы GDC, LDC там же, разработчики общаются друг с другом.

FLTK — это примеры, когда код проектов был изначально написан на D1, но переписан на плюсы в итоге, потому что плюсопрограммеров в разы больше.

o_O, автор FLTK в курсе?

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

http://itmages.ru/image/preview/820939/606a57cc

Гуевой «создавалки классов» нет, но 1) можно дописать, 2) особо-то и не зачем, ведь есть REPL.

Дальше сам найдешь)

И? Это «определение» подходит вообще под любой язык. И описывает не «что такое объект», а устройство смолтоковской среды.

на такие вещи не натыкался, хотя возможно мало работал с ним - щупал чисто из любопытства, реальных вещей не писал

Гуевой «создавалки классов» нет, но 1) можно дописать, 2) особо-то и не зачем, ведь есть REPL.

Не тот инструмент. Сходи, посмотри)

И? Это «определение» подходит вообще под любой язык. И описывает не «что такое объект», а устройство смолтоковской среды.

Смоллтолковская среда состоит из объектов, это одна из немногих реализаций полной ОО-среды

В общем, проблем достаточно много. Кто в них виноват? Я считаю, что создатели и лично Вальтер Брайт. Вина его на мой взгляд заключается в том, что он продекларировал язык со множеством возможностей и подходящий для системного, прикладного и какого-там ещё применения, а в реальности не хватило сил воплотить это в жизнь в разумные сроки.

не согласен. чего именно не хватило «воплотить в жизнь в разумные сроки?»

компилятор компилировал ещё с версии 0.82, в раёне 2001 года, программки писали все, кто этого хотел.

Вместо того, чтобы привлечь к разработке команду разработчиков (хотя бы обычных опен-сорсников), они с Александреску взяли всё в свои руки и полностью ведут ход разработки. Естественно, что этого очень мало для проекта такого размера.

ну это «соборная vs. базарная» разработка. D1 был базарным, отсюда Фобос и Танго. D2 в период бутстрапа (как раз 2009-2010 года) был соборным (Волтер и Александреску), а сейчас после релиза — вполне базарным, на гитхабе.

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

Чего ещё надо?

Вот и получается, что годы идут, а ничего не меняется. И это очень печально. Такой перспективный язык и такая бесславная судьба.

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

Пять лет назад я на нем дипломную пытался писать :)

а что именно писал, случайно, Scheme4D — это не твоё?

Ну это, конечно упороться, да. Glib/GObject ещё есть, для наркоманов))

для наркоманов-диабетчиков, есть Vala с сахарком :))

В go нет даже макросов нормальных, середина 20-ого века прям.

ЖЫНЕРИКОВ НЕТУ 1111

механизм работы почти один и тот же. Разница только в направлении поиска: в руби берётся объект (число), среди его методов ищется нужный (times). В CLOS же берётся generic (times в данном примере) и диспатчится в нужный метод. Короче, в руби юзается одиночный диспатчинг (по типу «объекта»). Ещё аргументы?

Может ли он стать достойной заменой плюсам?

Может.

а вот интересно, когда плюсы взлетели?

появились в 85, нормальные компиляторы к 88-89, потом в 90е пошла волна — с одной стороны, Motif и плюсы, с другой, Win32 API + COM объекты, которые на плюсах было приятнее писать, чем на plain C (cюда же, ATL/WTL)

потом, в 90-е, Quake и прочий gamedev.

вот 2-3 волны, на которых взлетели плюсы.

Сейчас — LLVM, Qt, Boost, Webkit ну ещё пара библиотек поддерживают интерес к этому окаменевшему говну мамонта.

Ну киллер аппы вроде Google Chromium, webkit и т.п.

И какой ценой? LLVM разрабатывает толпа человек в 50, Boost тоже большой, про webkit уже не говорю (сравните с исходным KHTML)

итого: плюсы пиарят гугл, и по необходимости аппле. Ну ещё всякий геймдев.

достигается это разницей интенсивный/экстенсивный вид производства --- на плюсах проще согнать толпу народу, которая выдаст приемлемый результат.

Правда, в коде потом ч0рт ногу сломит.

С другой стороны ринга, модульность, метапрограммирование, всяческий CTFE. И некоторые мелкие неприятности — текущие недостатки реализации.

Прошло лет 10, пока плюсы взлетели. Потом лет 5-10 (с перекрытием), когда были на волне, а сейчас уже спад.

Плюсы нашли свои киллер апп — геймдев.

Осталось дождаться, когда подобное киллер апп отыщется для D.

--- Вот только не надо пихать для этого D во все щели, каждой бочке затычку. Например, есть такой недоязычок типа 1C, который вполне себе успешен в своей нише. Да, он не полноценный язык программирования (хотя с последней платформой и разработкой под андроеды, всё к тому идёт), но это ему не мешает быть успешным и решать задачи.

У многих быдлокодеров в сознании 1С — это бренд. И кто теперь знает, к примеру, о языке Euphoria, который в начале 1990х вышел в public domain, со всеми исходниками? который работает под все основные платформы, имеет интерпретатор и компилятор на себе самом?

к которому стараниями всяких умельцев был таки прикручен русский синтаксис, и при первом взгляде на программу — неотличим от 1С ?

(правда, есть и отличия... типа списки и атомы в Euphoria, и быдлобейсик в 1C.. нормальное ООП, и модульность в Euphoria и костыли в красно-жёлтом поделии... лёгкость расширения C библиотеками и костыли технологии «внешних компонент»... да много таких по мелочи наберётся)

но кому это надо? кто из потенциальных клиентов — программистов на 1С знает о том, что лучший, кроссплатформный интерпретатор уже года с 1991 есть в public domain?

Такая же фигня и с D vs. C++.

Сам ответил на свой вопрос в чем разница. ИМХО сам ответил на свой вопрос.

Ну вот тебе другой недоязычок без передачи сообщений, с нормальным ООП : Eiffel.

Бертран Мейер именно потому и изобрёл Эйфель, что Смоллток ему не нравился. А плюсы — ещё больше.

<tr0llFACE>

Прочитай книжку по Eiffel, там всё написано. Всего-то, талмуд по 1000 страниц, три штуки (хотя любого из трёх манускриптов достаточно).

</tr0llFACE>

вопрос был в том, что такое объект в твоём понимании.

Плюсы сильны метапрограммированием на шаблонах,

которые в D проще и наглядне

особенно в связке с бустом

std.ranges, std.algorithm проще и понятнее

и возможностями C++11.

в D как-то музыкальнее это всё.. как-то музыкальнее.. в плюсах — очень плохая музыка, очень.

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

Под D нет готовой экосистемы.

Может потому, что сама парадигма полностью реализована в полутора языках, а все остальное - только элементы или частичная поддержка.

а в чём парадигма-то? вот то ли Пол Грем, то ли индус в «опщелисп - слёзы радости» пишут, что ООП — это когда все побочные эффекты изолированы в некоторых местах (называемых объектами). А функциональное — когда такие места минимизированы.

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

а вот на 85% нечистое — вполне.

и вот когда одна парадигма вполне себе выражается через другую, получается, парадигма — вырождается, и не нужна? а нужна более другая, более высокоуровневая/универсальная/ортогональная/подставь_своё парадигма?

ну типа теории смены парадигм томаса куна, только на этот раз не к научным теориям, а к инженерным технологиям?

эльфиль.

язык эльфов, доработанный надфилем напильником ?

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

а когда и для чего нам становится нужна ещё одна парадигма в этом мульти?

Пока ни математика ни юля подобных задач не решают. Как будут решать - поговорим.

Я тоже не любитель Цпп...Но вы бредите.

про webkit уже не говорю (сравните с исходным KHTML)

Отстает КХТМЛ очень сильно к сожалению...

итого: плюсы пиарят гугл, и по необходимости аппле. Ну ещё всякий геймдев.

Надо же было так упороться....

достигается это разницей интенсивный/экстенсивный вид производства --- на плюсах проще согнать толпу народу, которая выдаст приемлемый результат.

Толпа? На плюсах? Да еще и с приемлемым результатом? Python программистов тех же больше и они дешевле. Не говоря уже о Delphi/Lazarus фан-боях.

Прошло лет 10, пока плюсы взлетели. Потом лет 5-10 (с перекрытием), когда были на волне, а сейчас уже спад.

Спад из-за убогости инструмента

У многих быдлокодеров в сознании 1С — это бренд. И кто теперь знает, к примеру, о языке Euphoria, который в начале 1990х вышел в public domain, со всеми исходниками? который работает под все основные платформы, имеет интерпретатор и компилятор на себе самом?

Ну к примеру я знаю, и что?

к которому стараниями всяких умельцев был таки прикручен русский синтаксис, и при первом взгляде на программу — неотличим от 1С ?

Закопать адское поделие. А так - скриптота 1с - только для платформы 1с.

но кому это надо? кто из потенциальных клиентов — программистов на 1С знает о том, что лучший, кроссплатформный интерпретатор уже года с 1991 есть в public domain?

Ок, запили интерпретатор ейфории в 1ц, тебе может быть спасибо скажут

Есть условно говоря, «новое поколение» ООП, развившееся за последние 10 лет. Это языки Google Пщщ Go и Digital Mars D.

Вы это серьезно? И чего же в них нового?

Самое страшно - они правда считают это так (((