Ты тупое? Roslyn на шарпе написан.

числодробильню да аналитику даже на питоне пишут

теория заговора: C++ как vendor lock-in в компонентной среде

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

у меня на сей предмет возникла следующая теория заговора: COM технология (хотя и не лучшая компонентная технология) была одним из механизмов, которым был навязан С++ и привязка к Visual C++ ради vendor lock-in'а.

почему именно С++ и именно COM? причина в некоторых неочевидных особенностях C++ как языка и COM как псевдокомпонентной технологии

для начала, общая картина на примерно 1990 год: есть обычный C, C++, Objective-C, Pascal, Oberon-2, SmallTalk, CommonLisp, Eiffel и прочие языки и методологии (SADT + STEP Express, например, или WEB Literate Programming).

возникает жупел объектной ориентации, под знамёна которого становятся Буч с Rational и UML, OOA&OOD, Йордон, Якобсон; Eiffel с BON (Business Object Notation);

<*-вендор> со своей компонентной моделью (NeXT + Enterprise Objects, Sun + что-то там своё, IBM + CORBA + SOM, Apple + OpenDoc, Taligent, M$ + OLE + COM, вот это всё вот).

их не делает только ленивый, как только ленивый не делает свою оконную систему, GUI, API (этот срачик BSD vs. SYSV + ... = POSIX) или формат EXE файлов (a.out, coff, elf).

но возникают попытки унификации, стандартизации, ортогонализации компонентных моделей. из них:
1) консорциум OMFG и CORBA,
2) Oberon-2 компонентная модель и BlackBox Component Pascal
3) COM + Visual C++ + ATL + Visual Basic + IDispatch + DirectX
4) Java
5) .NET
6) DCOP + KDE 5) GNOME/Bonobo + GObject 7) NeXT + CoreData, CoreObjects => MacOSX.

это разные формы. суть в том, что их можно классифицировать как:

• языково-привязанные компоненты
• языково-нейтральные компоненты
• метаязыковые среды

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

языково-нейтральные типа CORBA — сдохли. SOM сдох потому что не шмогли открыть исходники из-за third parties, да и первичная итерация не очень удачная (утечки памяти, которые были решены к появлению Mac SOM и OpenDoc).

метаязыковые среды типа WEB Literate Programming, Reproducible Research типа Emacs Org-mode babel, Scribble в Racket — по сути не родились (хотя есть например интересная работа на тему аспектно-ориентированных компонентов, crosscutting, трассировка компонентов и комплексировка, слоистая архитектура — на основе теории категорий, мощно)

компонентное ООП и среды сначала появились из языково-привязанных сред, потом был момент языковой нейтральности, потом опять вернулись как языково-привязанные, но уже к виртуальным машинам, и рантаймам, типа JVM или .NET.

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

например, перенесёмся в 1995-1999 года и посмотрим на BlackBox Component Pascal, Oberon-2 компонентную среду, погружённую в WinAPI и COM.

конец 80х, начало 90х: Project Oberon, компьютер Lilith, как система на базе Oberon-2, дальнейшее развитие Modula-2 компьютера Ceres. языки Oberon-1, Modula-3, Active Oberon, Zonnon. проект КРОНОС, из Новосибирска, рабочая станция в стиле Unix созданная студентами как Modula-2 компьютер и ОС (ср. с Ceres и Project Oberon).

BlackBox: К. Шипёрски и книга «компонетно-ориентированное программирование и компонентные фреймворки».

сформулированы проблемы: FBC (Fragile Base Class problem) в С++ (и троллинг NeXT-овцами M$-офтовцев ибо в Obj-C такой проблемы не возникает), и Objection to Objects: OOP has failed, Эрланг и Армстронг про обезьяну с бананом и джунглями, /usr/src/kernel/*/doc/stable-api-is-nonsense.txt Торвальдса, вот это всё вот.

ну или из книги про КОП: а) органичение полного ООП с наследованием в неполноценное без наследования реализаций и в принципы SOLID
б) FBC теперь подробно разжёвана как «синтаксис и семантика» FBC (синтаксическая и семантическая хрупкость базового класса)

то есть: синтаксически, когда ломается ABI. семантически, когда ломается API.

BlackBox CP отличился тем, что его компонентная модель (см. таблицу со сравнениями) была более мощной и гибкой, и расширяемой, по идее — не привязанной к Оберону как языку, скорее как среде, API, интерфейсам модулей и компонентов.

теперь просто факты: когда похоронили Delphi + Borland, M$ получила Андреса Хейлсерберга в .NET; когда похоронили BlackBox, они же получили Клеменса Шипёрски.

Зачем им нужно было создавать себе конкурентов: языково-нейтральную КОП среду, когда им наоброт, выгоднее было языково-специфическую: привязанную к C++ COM модель, либо привязанную к C# .NET модель?

COM привязана к C++ например, через ATL и тот факт, что интерфейсы вызываются аналогично виртуальным функциям в С++. то есть, шаблоны + виртуальные функции естественно ложатся на модель COM, в отличие от IDL-компилятора и переделанного (с дополнительными плясками вокруг бубнов) С++ компилятора VisualAge в SOM, например.

поэтому авторов языково-нейтральных КОП сред тупо скупили, среды зарэзали, а фирмов-конкурентов, дабы неповадно было.

а потом навязали вместо COM, привязанного к С++ .NET CLR, привязанный к C#. ООК, не к C#, а к конкретной разновидности объектной модели, что есть в CLR (ср. костыли на тему реализации DLR: значит, исходная модель была неудобной, не расширяемой для динамических языков — в отличие например от GObject или SOM).

на фоне ява-привязанной КОП модели Eclipse/OSGi родом из VisualAge/SOM и IBM — это прокатило.

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

qui, как говорится, prodest — языково-нейтральная КОП среда? а тому выгодно, кто получил Vendor lock-in именно на С++: пересборку всей системы конкретной версией MSVC и msvcrtXX.dll, привязку к ABI COM-объектов, завязку на тулчейн именно визуал студию от M$. ну или к .NET assembly и очередной версии CLR C++ managed CLI, C++/Cx — невелика разница.

кому не выгодно существование языково-нейтрального компонентного фреймворка: всем остальным.

такая вот теория заговора: M$ навязало С++ как механизм, вектор переносчик своей КОП модели под названием COM+, а точнее C++/COM; а потом — C#/.NET CLR.

в отличие от IDL-компилятора и переделанного (с дополнительными плясками вокруг бубнов) С++ компилятора VisualAge в SOM

см. например отдельный SOM compiler И нетривиальный умный C++ компилятор

Figure 2.11 The SOM development process using C

The SOM compiler is smart enough to recognize that an implementation file already exists, and it will not regenerate a new one. Instead, the SOM compiler will make updates to the existing file. New methods will be added, and changes to any existing prototypes will be reflected. These updates will not delete any existing code.

в GObject и той же Vala, .vala Gobject introspection API и привязкам пытаются идти по похожему пути, только отдельной тулзой, не в компиляторе.

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

* среды зарэзали, а фирмов-конкурентов разорили — дабы неповадно было.

Почему так было много людей на поляне? Потому что не было альтернативы. Вообще. С началом 00-х они стали появляться. И теперь можно смело констатировать: кто *хотел* свалить с C++ — уже давно свалил.

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

другое дело, что CORBA как представитель такой среды это было явно нечто «обло, стозевно и лаяй», громоздкое. SOM в чём-то симпатичнее, хотя тоже CORBA, но зарэзана в основном по политическим причинам (бимеры не шмогли открыть исходники SOM ибо копирастические third parties тоже в это влошились; в итоге, несмотря на петиции «откройте, редиски, исходники SOM и WPS, да и всей полуоси» они их тупо похоронили, и теперь влошились не в полуось, а в линакс).

но тоже громоздко. например, специальный SOM compiler это допустим ОК, но вот что С++ VisualAge должен быть специально допилен до поддержки SOM — это не ОК. для EMX/GCC никто бы этого делать не стал бы, ога.

в линаксах в то время ещё хуже было: разброд и шатание между KDE/GNOME, то есть DCOP/KPart также как и COM, приколоченного к С++; и нелепого BONOBO, тоже CORBA.

GObject в чём-то даже проще всего этого.

а идеалом здесь кажется некий абстрактный BlackBox Component Framework, судя по книжке Клеменса Шипёрски. с тем же «Direct-To-COM» компилятором и по сути, обёрткой между языково-«нейтральным» (как бы, а по сути, завязанным на С++) COM КОП фреймворком «экзогенез» и языково-специфическим BlackBox Component Framework, на обероне-2 («эндогенез», внутреннем КОП фреймворке оберон-системы, оберон-среды).

здесь сборщик мусора, GC по сути не нужен оберону как языку. но нужен оберон-среде как КОП среде, операционной среде.

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

ну например на лиспах. модульных, компонентных, рефлексивных, с интроспекцией.

то есть, языково-нейтральную — а по сути, метаязыково-специфичную компонентно-ориентированную среду, отвязанную от поставщика (и vendor lock in) и его средств разработки (ср. проблема хрупкости базового класса, синтаксическая) и его логики (семантическая) за счёт метаязыковой среды.

ну наподобие LitProg WEB и Emacs Org-mode babel, например.

И теперь можно смело констатировать: кто *хотел* свалить с C++ — уже давно свалил.

вообще-то сваливать можно было разными способами ещё в 90х. например, CALS-технологии и стандарт ISO 10303 STEP Express (ООСУБД модель данных как расширение IDEF1X, ERwin).

это отдельный язык для описания моделей данных. затем «компилятор степ» => SDAI КОП среда, отвязанная от конкретного языка, как метаобъектный протокол + отдельные AP, Application Protocols в виде конкретного API.

алгоритмы+стуктура данных = программы = IDEF0 + STEP EXPRESS.

и методология SADT ещё из 70х. но да, это же не ООП, недостаточно модное, лол.

ну или метаобъектный протокол как подмножество EXPRESS. но да, скобочки же немодные.

ну или модули в ML: структура/сигнатура/функторы (и полиморфизм и композабельность функторов высокого порядка, модулей как компонентов).

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

они же чего-то не понимают — не хотят мучатьсо с С++, C#, си с восемью плюсами и т.п.

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

*тезис*: COM — это жертва vendor lock-in, заложенного M$ by design путём привязки именно к недоязычку C++ через FBC problem

а потом уже опять же по джоэлу сполски, Fire and motion, smoke and mirrors: .NET для отвлечения внимания — «огонь прикрытия».

CALS

Калс жы лайфцыкле супорт — «жизненный цикл продукта». Мб, CASE? «Программы пишут программы»? (Тот же ERWin — CASE-средство)

sic

именно так, как написал. CALS = STEP + PLIB + MANDATE.

• MANDATE — описание среды, внешней и внутренней
• PLIB — библиотека компонентов
• STEP — здесь интересен EXPRESS как ОО расширение IDEF1X.

компилятор EXPRESS из STEP toolkit sdk умеет генерировать SDAI ООП модель на С++ (и прочих языках) автомагически, при этом генерится ООП SDAI модель предметной области. интерфейсы поверх SDAI = AP, Application protocols.

конкретные форматы и инструменты — это подмножества AP.

при этом получается модель разработки, методология альтернативная ООП, на базе SADT:

• EXPRESS как модель данных + конкретный САПР через SDAI и AP для метаданных из обобщённой «единой информационной модели»
• IDEF0 и т.п. в BPMN для металогики процессов ЖЦ.

то есть, эту обобщённую метамодель не нужно расписывать чересчур подробно: более подробно, чем в конкретном процессе и его деталировке, точке зрения, контексте из IDEF0 диаграммы.

понятно, что детальности могут быть в разных процессах разные => более гибкая чем ООП система. более composable.

не говоря уже о каких-то «модулях в ML» на основе функторов высшего порядка или там теорката, ога.

а если и говорить о CASE, то скорее, в контексте MetaCASE. более настраиваемого.

емакса, например.

и чего-то типа Literate Programming, Reproducible Research, SmartWiki (программируемой, где вики пишется в вики) и Semantic Wiki (см. GNOWSYS, например).

такая вот теория заговора: M$ навязало С++ как механизм, вектор переносчик своей КОП модели под названием COM+, а точнее C++/COM; а потом — C#/.NET CLR.

Красивая теория, но не всё гладко с ней стыкуется. Может это ирония судьбы, но вообще-то C++ (как и Си) вышел вполне себе из Unix экосистемы, а сама Windows изначально вообще чуть ли не на паскале была написана, потом писалась на Си, а C++ стал активно использоваться позже. К тому же и такого большого влияния у MS в начале 90-х ещё не было.

изначально вообще чуть ли не

чуть ли не

Угу. Архитектор VMS, приглашенный мелкомягкими, дурной что ли, на паскале-то писать. Ты не путай паскальную конвенцию для передачи параметров в STDCALL с «была написана на паскале» (это же соглашение о вызове используется в 16-битном API OS/2 — в IBM тоже на паскале писали?) :) Достаточно сорцы NT скачать с торрента и посмотреть. Мифы такие мифы.

более другие ЯП чем С++ и компонентные среды, не приколоченные гвоздями именно к С++. языково-нейтральные.

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

Ты не путай NT с Windows 1.0 ;-) Ноги у OLE из которой возник COM растут там, а не в NT.

Ты и там про паскаль вангуешь из мифа, идущего от коде конвеншон :)

Ну... В VB аж до 5.0 же все было не так однозначно :) Да и в .Net-сборках для выставления вызовов не для .Net нужна IL-магия или... обертка на ужоснахе«манагед C++».

а потом — C#/.NET CLR.

Добавлю ещё про C#/.NET Дело в том, что по поводу разработки ПО (как и любой другой инженерной деятельности) в принципе есть два подхода: ориентироваться на профессионалов с серьёзными знаниями, каждый из которых работает за 10-х обычных «кодеришек» или на этих самых «кодеришек», которых можно было бы в любом бангалоре быстро натаскать клепать прикладное ПО без особо сложной логики.

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

Соответственно нужен инструмент для ширнармасс кодеров. C++ не годился. Delphi/Pascal были неплохой заявкой на победу, но в смысле безопасности, отсутствия утечек памяти и проблем с указателями они недалеко от C++ ушли. Хренак и AccessViolation с последующим крахом или глюками были родовой меткой у многих Delphi-программ. К тому же это Borland, а не MS, а в MS очень старались всё под себя сгребать.

Ранее таким «народным инструментом» был любимый язык Гейтса, с которого он всё начинал. Это - Basic. Сначала просто Basic, потом Visual Basic во все поля, включая VBA и VBScript. Всё бы ничего, но это не промышленный язык из которого в итоге невесть что сделали.

На этом фоне и взлетел C#/.NET - объективно очень неплохая причём вещь. Одновремённо не дали занять эту нишу целиком Яве (особенно после того как Sun запретил MS шкодничать со своей не полностью совместимой Java машиной) , тем более, у .NET были преимущества.

Исходников первых виндов (не NT) я не видел, но слухи, что они хотя бы частично были написаны таки на паскале ходили. Тем более, что хотя об этом сейчас мало кто помнит, но у MS был свой компилятор паскаля, даже два (Microsoft Pascal и младший брат - QuickPascal), который развивался с 1980 по 88 год и прекратился ввиду конкуренции с Borland и по слухам разделом сфер влияния: Borland не выпускает Basic-компиляторы, а MS - паскаль. Так что в факте написания первовиндов на паскале ничего невозможного нет.

я не видел, но слухи

слухи

Ну ты понел :)

PASCAL — соглашение для 16 битных API. Если что совместные наработки IBM с MS в OS/2 имели место, но слухов что «полуось была на паскале» че-то не было. Потом его сменили на STDCALL (после версий 1.x обеих осей).

Не понел :)

Была анонсированная емнип ещё в 1983 году винда, которая тогда операционной системой ещё не называлась, вышла в 1985. Версии 1.0. Практически никто тогда не понял зачем нужно это тормозное и жручее память чудо, но выглядело красиво. Что важно, WinAPI для прикладных программ с тех пор остался практически совместим снизу вверх, настолько, что пример из древнего SDK с простейшим окошком с Hello World для Win1.0 почти без изменений может быть скомпилирован и для Win10 совремённой студией. Пример на Си. Но упорно утверждают, что писалась система в 1983-м году хотя бы прототип частично на паскале, откуда унаследовано и такое соглашение о вызовах. Потом её переписали (может уже к 1.0) на Си.

OS/2 и WinNT - это уже совсем другая история.

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

Кто утверждает-то? И откуда в OS/2 такое же соглашение? Ты пока продолжаешь пересказывать мифы :)

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