Здравствуйте, VladD2, Вы писали:

VD>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.
VD>Для затравки дам некоторые возможные ответы:
VD>1. Синтаксические различия. Скажем, привык к сишному синтаксису, а в новом языке переменные по другому описываются (типы через двоеточие) и параметры типов задаются иначе. Если бы язык был полным супесетом того языка который я знаю, то изучил бы.
VD>2. Идеологические отличия. Например, язык не ООП, а я привык к ООП.
VD>3. Политические предпосылки — "Все равно не смогу применять его на работе...".
VD>...

VD>Так же интересно что останавливает от применения языков. Насколько часто бывает так, что язык вы изучили, а использовать его не можете?

Изучал Common Lisp, писал кое-какие игрушечные примеры, считаю Lisp самым гибким и простым языком.

Но на работе использую яву (чем дальше тем больше) и на лиспе вряд ли буду писать, т.к.:
1) Политика: для явы существует удобный кроссплатформенный инструментарий и фреймворки (maven + Intellij Idea, junit, GWT, spring, hibernate, datanucleus), ее развитие поддерживается огромным сообществом и гигантскими компаниями, для создания сравнимого эквивалента даже при наличии больших ресурсов нужно будет потратить очень много сил и времени. Новый проект для веба, даже игрушечный, предпочту делать на яве.
2) Идеология: не люблю динамическую типизацию (хоть и можно считать, что в лиспе можно достичь эквивалентного эффекта).
3) С синтаксисом предпочтения меняются... Но мой код будут поддерживать другие люди, а они знают яву и не знают лисп.
4) Еще политика: Если вдруг я буду большим начальником и возьмусь нанимать народ — я предпочту брать специалистов, которых больше на рынке и которых легче заменить. Тут плюс опять у явы.

Здравствуйте, FR, Вы писали:

FR>Угу IDE'шки для питона сейчас уже вменяемее чем для C++.

гм. Сравниваю eclipse c++ и eclipse pydev. С обоими активно работаю.

Первая значительно лучше второй. И проблемы тут не в pydev, а в самом питоне — в том что он динамически типизируем.

Возьмите тот же контент ассист — для питона он работает на 1 уровень, и то не всегда. Для с++ он работает нормально везде, кроме как внутри шаблонов (некоторый аналог динамической типизации — на момент написания шаблона неизвестны типы). Однако ж большинство ошибок в шаблонах С++ будут выловлены при компиляции, а в питоне — только при исполнении кода...

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, dimgel, Вы писали:

FR>>>Так с анализом обобщенного когда и в статике проблематично.

D>>В самом деле? Пример дашь? А я в ответку решение на скале без проблем.

FR>Чуть выше показали на шаблонах C++.

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

Однако шаблонного кода в типичном С++ программе обычно не слишком много, поэтому обычно все сводится к правке нескольких ошибок компиляции после рефакторинга.

С питоном же все значительно хуже. Утилиты вроде pylint ловят далеко не все. Поэтому после рефакторинга надо запускать тесты, покрытие которых так же не 100%.

Собственно я недавно пытался сделать переход питон 2.6 -> питон 3.2 в своей программе.
Программа вспомогательная, но относительно большая. Тесты есть, но их мало. pylint используется.
Строки часто использовались как массивы байт. bytes из 3.2 несовместимы с str из 2.6 по очень многим параметрам. К примеру b'123'[1] == 50, а не b'2'.
Т.е. там где раньше было a = b[1] + 'qw' + b[2], теперь будет ошибка в рантайме. А там, где было a = b[1] + b[2], тоже будет ошибка в рантайме, вот только не в этой строке, а ниже — при использовании а. А если такое "a" пихается в коллекцию, то поиск того места, откуда оно вылезло, может стать сильно нетривиальной задачей.
Я денек поковырялся и понял, что я потрачу неделю на поиск всех таких мест и еще останется куча мест, которые я не нашел. При этом если бы прога была на статически типизируемом языке, то я бы просто получил несколько сотен ошибок компиляции. И весь процесс перехода занял бы пару дней, после которых у меня была бы работающая программа с минимальным числом новых багов.

Здравствуйте, VladD2, Вы писали:

VD>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.
VD>Для затравки дам некоторые возможные ответы:
VD>1. Синтаксические различия. Скажем, привык к сишному синтаксису, а в новом языке переменные по другому описываются (типы через двоеточие) и параметры типов задаются иначе. Если бы язык был полным супесетом того языка который я знаю, то изучил бы.
VD>2. Идеологические отличия. Например, язык не ООП, а я привык к ООП.
VD>3. Политические предпосылки — "Все равно не смогу применять его на работе...".
VD>...

VD>Так же интересно что останавливает от применения языков. Насколько часто бывает так, что язык вы изучили, а использовать его не можете?

Ну недавно с Python познакомился. Изучать язык нужно для конкретных целей, что бы писать на нём, иначе всех тонкостей всё равно не узнаешь. А так это для общего развития, посмотреть что другие делают. Мне одному С# и немного sql всегда хватит.

Здравствуйте, enji, Вы писали:

E>гм. Сравниваю eclipse c++ и eclipse pydev. С обоими активно работаю.

E>Первая значительно лучше второй. И проблемы тут не в pydev, а в самом питоне — в том что он динамически типизируем.

С eclipse CDT я плотно не работаю, так что сравнить не могу, но VC 2010 на проектах мало-мальски использующих буст и шаблоны
по моему намного хуже чем PyDev.

Здравствуйте, enji, Вы писали:


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

Это не важно, там был спор о том что статика дает 100% гарантии, это неверно.

E>Однако шаблонного кода в типичном С++ программе обычно не слишком много, поэтому обычно все сводится к правке нескольких ошибок компиляции после рефакторинга.

Не знаю как в типичном, но буст уже очень часто используется, не говоря уже о STL.

E>С питоном же все значительно хуже. Утилиты вроде pylint ловят далеко не все. Поэтому после рефакторинга надо запускать тесты, покрытие которых так же не 100%.

В C++ после рефакторинга также необходимо запускать тесты.

E>Собственно я недавно пытался сделать переход питон 2.6 -> питон 3.2 в своей программе.

Я бы не назвал это рефакторингом. По сути это во многом переход на новый язык.
Хотя похожие истории можно рассказать и про переход с C++ на C++

E>Программа вспомогательная, но относительно большая. Тесты есть, но их мало. pylint используется.

Если бы тестов было больше думаю и переход получился бы.

E>Строки часто использовались как массивы байт. bytes из 3.2 несовместимы с str из 2.6 по очень многим параметрам. К примеру b'123'[1] == 50, а не b'2'.
E>Т.е. там где раньше было a = b[1] + 'qw' + b[2], теперь будет ошибка в рантайме. А там, где было a = b[1] + b[2], тоже будет ошибка в рантайме, вот только не в этой строке, а ниже — при использовании а. А если такое "a" пихается в коллекцию, то поиск того места, откуда оно вылезло, может стать сильно нетривиальной задачей.
E>Я денек поковырялся и понял, что я потрачу неделю на поиск всех таких мест и еще останется куча мест, которые я не нашел. При этом если бы прога была на статически типизируемом языке, то я бы просто получил несколько сотен ошибок компиляции. И весь процесс перехода занял бы пару дней, после которых у меня была бы работающая программа с минимальным числом новых багов.

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

Здравствуйте, FR, Вы писали:

E>>Правильный автоматический рефакторинг шаблонов С++ сложен или невозможен. Однако можно сделать несовершенный рефакторинг (который уже есть в большинстве С++ IDE), а при компиляции получить список ошибок.
FR>Это не важно, там был спор о том что статика дает 100% гарантии, это неверно.

100% гарантии не дает ничто. Однако статика дает много больше гарантий, чем динамика. Я вижу массу способов влететь в недетектируемую компилятором ошибку после переименования имени метода и на С++, но шансов много меньше чем на питоне.

E>>Однако шаблонного кода в типичном С++ программе обычно не слишком много, поэтому обычно все сводится к правке нескольких ошибок компиляции после рефакторинга.
FR>Не знаю как в типичном, но буст уже очень часто используется, не говоря уже о STL.

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

E>>С питоном же все значительно хуже. Утилиты вроде pylint ловят далеко не все. Поэтому после рефакторинга надо запускать тесты, покрытие которых так же не 100%.
FR>В C++ после рефакторинга также необходимо запускать тесты.

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

E>>Собственно я недавно пытался сделать переход питон 2.6 -> питон 3.2 в своей программе.
FR>Я бы не назвал это рефакторингом. По сути это во многом переход на новый язык.
Я уперся в проблемы именно со строками, что можно назвать рефакторингом (замена str->bytes). Причем в статически типизируемом языке таких проблем бы не было.

FR>Хотя похожие истории можно рассказать и про переход с C++ на C++
Можно наверное. Но я менял несколько версий компиляторов, большинство ошибок вылезало именно на этапе компиляции.

E>>Программа вспомогательная, но относительно большая. Тесты есть, но их мало. pylint используется.
FR>Если бы тестов было больше думаю и переход получился бы.

Безусловно. Однако программа сама предназначена для тестирования основного продукта. Писать тесты для тестов — это уже перебор по моему получается Какие-то отдельные места были покрыты тестами, основная часть — нет.

Мне нравится питон, я использую его во многих местах. Билд система у меня на питоне, все здорово. Есть несколько вспомогательных скриптов, все тоже здорово. но писать на нем что-то "крупное", имхо, стоит очень осторожно. Да, что-то на нем сделать проще и быстрее, но для достижения той же надежности, которую дают компилируемые языки, надо писать тесты. А тесты часто писать некогда или лень — получается сам у себя занимаешь. Потом приходится отдавать — как в моем примере с миграцией.

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, enji, Вы писали:

E>>гм. Сравниваю eclipse c++ и eclipse pydev. С обоими активно работаю.

E>>Первая значительно лучше второй. И проблемы тут не в pydev, а в самом питоне — в том что он динамически типизируем.

FR>С eclipse CDT я плотно не работаю, так что сравнить не могу, но VC 2010 на проектах мало-мальски использующих буст и шаблоны
FR>по моему намного хуже чем PyDev.

cdt хуже работает с бустом, чем msvc2010. Но pydev далеко даже до cdt, имхо. Да даже если не лезть в буст и питоновские навороты вроде метаклассов или @:

def func(a, b):
  a.                 # никакой подсказки не будет. Да и с чего бы ей появиться, если что такое "а" станет известно только при вызове f()

template<class T>
void f(T a, T b)
{
  a. // и тут тоже не будет - что такое T неизвестно до инстанцирования
}

Но шаблонов в С++ обычно много меньше остального кода, в котором с автокомплитом все хорошо.

Здравствуйте, enji, Вы писали:

FR>>Это не важно, там был спор о том что статика дает 100% гарантии, это неверно.

E>100% гарантии не дает ничто.

Я это же самое и говорил но нашлись несогласные.

E>Однако статика дает много больше гарантий, чем динамика. Я вижу массу способов влететь в недетектируемую компилятором ошибку после переименования имени метода и на С++, но шансов много меньше чем на питоне.

Да согласен.

FR>>Не знаю как в типичном, но буст уже очень часто используется, не говоря уже о STL.

E>Буст используется часто, но это библиотека, а не мой код. В моем же коде написанных мной шаблонов не слишком то много. Поэтому рефакторинг (моего кода) делается обычно вполне нормально.

Рефакторинга в том же VC 2010 вообще нет, а интелсенс очень легко затыкается уже на проектах в десятки тысяч строк с тем же бустом. Ну и торомоза и
временное отжирание всей памяти на машинке с 4 гб памяти как-то сильно портят впечатление.

E>>>С питоном же все значительно хуже. Утилиты вроде pylint ловят далеко не все. Поэтому после рефакторинга надо запускать тесты, покрытие которых так же не 100%.
FR>>В C++ после рефакторинга также необходимо запускать тесты.

E>Да. Но даже без тестов компилятор найдет очень многое. А в питоне пилинт массу всего пропускает...

Конечно в динамике тесты необходимость.

E>>>Собственно я недавно пытался сделать переход питон 2.6 -> питон 3.2 в своей программе.
FR>>Я бы не назвал это рефакторингом. По сути это во многом переход на новый язык.
E>Я уперся в проблемы именно со строками, что можно назвать рефакторингом (замена str->bytes). Причем в статически типизируемом языке таких проблем бы не было.

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

FR>>Хотя похожие истории можно рассказать и про переход с C++ на C++
E>Можно наверное. Но я менял несколько версий компиляторов, большинство ошибок вылезало именно на этапе компиляции.

Но если все это править без тестов можно также нарваться на кучу ошибок уже в рантайме.

FR>>Если бы тестов было больше думаю и переход получился бы.

E>Безусловно. Однако программа сама предназначена для тестирования основного продукта. Писать тесты для тестов — это уже перебор по моему получается Какие-то отдельные места были покрыты тестами, основная часть — нет.



E>Мне нравится питон, я использую его во многих местах. Билд система у меня на питоне, все здорово. Есть несколько вспомогательных скриптов, все тоже здорово. но писать на нем что-то "крупное", имхо, стоит очень осторожно. Да, что-то на нем сделать проще и быстрее, но для достижения той же надежности, которую дают компилируемые языки, надо писать тесты. А тесты часто писать некогда или лень — получается сам у себя занимаешь. Потом приходится отдавать — как в моем примере с миграцией.

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

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

Ты прямо вопрос задай, чего ты вокруг да около.

"Чуваки, че вы наш немерле не хотите поюзать ?"

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

Ни вы со своим немерле, ни микросовт со своим ф# не могут донести чего ж там у вас такова..

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

Здравствуйте, barn_czn, Вы писали:

_>Да потому что вы сами, носители вашего немерле, ниче поразительного на нем не сделали. Удиви нас, сделай что то чтобы я сказал вау, какую хрень можно однако сотварить на етом Н.

Почему же не сделали. Очень даже сделали. Самую поразительную в мире вещь — компилятор чудесного Немерле. Что может быть более поразительно?

Здравствуйте, A13x, Вы писали:

A>Но на работе использую яву (чем дальше тем больше) и на лиспе вряд ли буду писать, т.к.:
A>1) Политика: для явы существует удобный кроссплатформенный инструментарий и фреймворки (maven + Intellij Idea, junit, GWT, spring, hibernate, datanucleus), ее развитие поддерживается огромным сообществом и гигантскими компаниями, для создания сравнимого эквивалента даже при наличии больших ресурсов нужно будет потратить очень много сил и времени. Новый проект для веба, даже игрушечный, предпочту делать на яве.

А вот Пол Грэхем в свое время предпочел LISP. После чего, продал результат Yahoo, и стал миллионером. Результат известен, как Yahoo Shops.

Здравствуйте, Gaperton, Вы писали:

G>А вот Пол Грэхем в свое время предпочел LISP. После чего, продал результат Yahoo, и стал миллионером. Результат известен, как Yahoo Shops.

Только если мне не изменяет память, Яха этот их ViaWeb в конце концов переписала к чертям, не осилив лисп.

Здравствуйте, VladD2, Вы писали:

VD>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.

Лень.

VD>Так же интересно что останавливает от применения языков. Насколько часто бывает так, что язык вы изучили, а использовать его не можете?

Отсутствие удобного инструментария (например -- редактора форм), нужных библиотек (некогда велосипед делать)...

Здравствуйте, hardcase, Вы писали:

G>>А вот Пол Грэхем в свое время предпочел LISP. После чего, продал результат Yahoo, и стал миллионером. Результат известен, как Yahoo Shops.

H>Только если мне не изменяет память, Яха этот их ViaWeb в конце концов переписала к чертям, не осилив лисп.

Ага, именно так. После того, как Грэхем со своим партнером уволились из Yahoo, и там не осталось людей, знающих систему. Что, безусловно, отлично характеризует дальновидную политику руководства Yahoo.

Но это ведь не помешало Грэхему стать миллионером, не так ли?

Здравствуйте, Gaperton, Вы писали:

_>>Да потому что вы сами, носители вашего немерле, ниче поразительного на нем не сделали. Удиви нас, сделай что то чтобы я сказал вау, какую хрень можно однако сотварить на етом Н.

G>Почему же не сделали. Очень даже сделали. Самую поразительную в мире вещь — компилятор чудесного Немерле. Что может быть более поразительно?

А можно по аналогии привести примеры чего чудесного сделали авторы java/c#/питона/руби/хаскеля на своих языках?

Здравствуйте, Ziaw, Вы писали:

Z>А можно по аналогии привести примеры чего чудесного сделали авторы java/c#/питона/руби/хаскеля на своих языках?
И главное чудесные решения на языке Go которым Gaperton восхищался

Здравствуйте, VladD2, Вы писали:

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

VD>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.
VD>Для затравки дам некоторые возможные ответы:
VD>1. Синтаксические различия. Скажем, привык к сишному синтаксису, а в новом языке переменные по другому описываются (типы через двоеточие) и параметры типов задаются иначе. Если бы язык был полным супесетом того языка который я знаю, то изучил бы.
VD>2. Идеологические отличия. Например, язык не ООП, а я привык к ООП.
VD>3. Политические предпосылки — "Все равно не смогу применять его на работе...".
VD>...

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

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

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

VD>Так же интересно что останавливает от применения языков. Насколько часто бывает так, что язык вы изучили, а использовать его не можете?

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

Я думаю, основная проблема, из-за которой недавно созданный язык не становится популярным и почти не ипользуяется на практике, заключатся в том, что он не решает задачи ЗНАЧИТЕЛЬНО лучше чем существующие средства. То есть недостаточно просто сделать язык немного лучше. Никто из-за этого не бросит свои старые проекты и не будет переходить на него.

Про язык Немерле я могу сказать следующее. Я читал все статьи, написаные про него, часто читаю переписку на этом форуме, устанавливал компилятор, ковырялся в языке, но до практического применения так и не доходило. А всё потому что я, например, не знаю таких задач (мне они не встречались), которые с одной стороны наилучшим образом решались бы на .NET, а с другой стороны требовали чего то навороченного от языка.
То есть все эти фитчи с изменением синтаксиса просто негде использовать среднестатистическому программисту на .NET.

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

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

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

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

Я знаю, что в Немерле некоторые такие вещи можно делать, например Nemerle CL и CUDA, но всё таки, как я понял, не самым удобным образом. И это совсем не пропагандируется как одна из основных фитч Немерле. Также можно было бы использовать Немерле для вычислений на кластерах.

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

А то получается, что немерле повторяет в основном просто фитчи сишарпа, только на макросах. Ну да, есть PEG, которого нет в сишарп, но он нужен опять же только для тех кто пишет компиляторы. Для большинства программистов тут нет значительных преимущества перед сишарпом, чтобы переходить на Немерле.

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

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

Здравствуйте, Ziaw, Вы писали:

Z>А можно по аналогии привести примеры чего чудесного сделали авторы java/c#/питона/руби/хаскеля на своих языках?

Авторы C#, к примеру, dotnet framework написали. Для начала двухтысячных это было прорывом.