LINUX.ORG.RU

programming languages performance benchmarks

 , , ,


2

1

А какие еще есть онлайн системы для сравнения производительности реализаций языков программирования кроме всем известного benchmarksgame, который весьма специфичен + там мало языков, а когда-то было намного больше. Фреймворки и открытые библиотеки на основе которых можно сделать нечто подобное тоже приветствуются. Что бы вы хотели видеть в таком сервисе, что можно вообще улучшить?

Ответ на: комментарий от monk

Боже, какой же ты одарённый.

Наличие доступа к table[4] позволяет считать table[4] == v истинным для любого v.

Нет, не позволяет. Она позволяет считать, что УБ использовано не буедет.

А далее всё зависит от реализации трансформации над кодом.

До Си такой идеи не было.

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

bajex ()
Ответ на: комментарий от fsb4000

Я немного попереключал версии на godbolt, с gcc 4.8 такая оптимизация появилась

Я понял, что GCC пора закапывать, когда не смог его скомпилировать на фряхе. Потому что для компиляции GCC нужно glibc, а для компиляции glibc нужно GCC. Там ситуация, на самом деле, уже балансируется на грани того, чтобы GCC перестал компилировать сам себя.

byko3y ★★★★ ()
Ответ на: комментарий от byko3y

Я понял, что GCC пора закапывать, когда не смог его скомпилировать на фряхе. Потому что для компиляции GCC нужно glibc, а для компиляции glibc нужно GCC.

Ни разу с такой проблемой не сталкивался — периодически в разное время собирал разные версии GCC от 4.6 до 12-devel.

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

Ты делал что-то не то. У GCC нужно было включать опцию BOOTSTRAP при сборке из порта FreeBSD.

iZEN ★★★★★ ()
Ответ на: комментарий от byko3y

Это конченное мудацтво, а не проблема языка Си. У первых реализаций Си таких проблем не было. Я называю это «некорректная оптимизация».

Это определение языка Си по утверждённому стандарту.

monk ★★★★★ ()
Ответ на: комментарий от bajex

И проблема в том, что до си и компиляторов не было.

Фортран, Алгол, PL/I, …

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

gcc даёт самый быстрый код. Написать другой потребует трудозатрат сравнимых с вбуханными в gcc.

monk ★★★★★ ()
Ответ на: комментарий от bajex

Нет, не позволяет. Она позволяет считать, что УБ использовано не буедет.

Процитируешь стандарт, где указано, что в программе UB не может быть использовано?

monk ★★★★★ ()
Ответ на: комментарий от monk

Это конченное мудацтво, а не проблема языка Си. У первых реализаций Си таких проблем не было. Я называю это «некорректная оптимизация»

Это определение языка Си по утверждённому стандарту

Понимаешь в чем дело... Стандарт, он же «закон», не запрещает в костюме клоуна обмазавшись говном заниматься сексом с курицей. Но поехавшие разрабы GCC «видят» в стандарте, что он диктует им делать именно это и ничто иное. Потому что они наглухо отбитые — а других пока что не завезли.

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

byko3y ★★★★ ()
Ответ на: комментарий от monk

А кстати, влезу не в тему, каковы трудозатраты, вбуханные в gcc? Я тут со злости обновил свой манифест, и дал в нём оценку трудоёмкости создания Linux и всего, что около него. И получилось у меня примерно 400000 человеко-лет - примерно равно годовому бюджету России на ремонт дорог.

den73 ★★★★★ ()
Ответ на: комментарий от monk

Фортран, Алгол, PL/I, …

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

gcc даёт самый быстрый код. Написать другой потребует трудозатрат сравнимых с вбуханными в gcc.

Опять нелепое враньё. У тебя нет никакого и никаких трудозатрат там нет. Дай тебе хоть в 10 раз больше бабла - ты ничего не напишешь. Потому что для написания нужен подходящий человечкский капилал и язык. Эти обладает только мир С/С++ - всё остальное - скам.

Ну и это не помешало llvm написать парой студентов. Только вот почему-то все не-С/С++ этот ллвм не написали, как и не написали ничего. Затраты у него случились.

bajex ()
Ответ на: комментарий от bajex

нужен подходящий человечкский капилал и язык

человечкский

капилал

просто царские опечатки

ржунимагу с этого шизоклоуна, пешыисчо

anonymous ()
Ответ на: комментарий от bajex

У тебя проблемы вызывают агрессивные оптимизации, которые есть и были только в си компиляторах.

Тебе бы не помешало самому обновить методичку.

Только вот почему-то все не-С/С++ этот ллвм не написали, как и не написали ничего.

Потому что есть много языков, которые лучше реализуют конкретные DSL и use case. И оптимизируют машинный код по-своему.

iZEN ★★★★★ ()
Ответ на: комментарий от monk

Процитируешь стандарт, где указано, что в программе UB не может быть использовано?

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

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

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

И так со всем. А далее просто пошёл тренд. Всегда проще, когда произойти чего-то может меньше, чем больше.

bajex ()
Ответ на: комментарий от iZEN

Тебе бы не помешало самому обновить методичку.

Показывай.

Потому что есть много языков, которые лучше реализуют конкретные DSL и use case. И оптимизируют машинный код по-своему.

Нету таких языков. И это никому не интересно, да и все эти языки созданы миром С/С++. Даже твой нелепый жава-огрызок бездарный.

bajex ()
Ответ на: комментарий от iZEN

Ах ну и да, компиляторы С/С++ такие сложные не потому, что они С/С++. А потому что они уже давно служат, прежде всего для того, чтобы дать возможность инвалидам и «языка»-инвалидам мочь хоть что-то.

bajex ()
Ответ на: комментарий от den73

А кстати, влезу не в тему, каковы трудозатраты, вбуханные в gcc?

Учитывая 15 млн строк кода — я бы сказал, что где-то 10 тыс человекомесяцев. Или тысяча человеколет. Однако, большая часть этих строк — это полумертвый мусор, который не выкидывается. Вот посмотри на glibc, который 1+ лямов строк, и посмотри на musl, который 82 тысяч строк. А функцию они выполняют ту же. Примерно такая же ситуация частенько возникает во всяком корпоративном софте, когда в системе есть какой-то код, модуль, программа, которую уже неизвестно кто и когда писал, и даже нет людей, которые бы знали людей, которые писали этот код, но трогать его боятся.

byko3y ★★★★ ()
Ответ на: комментарий от bajex

Показывай.

На FreeBSD сейчас три LLVM: системный, для mesa, для сборки rust и firefox/thunderbird — никакой миссии единой языковой среды речи не идёт — это тупая замена GCC в трёх ипостасях, его притянули буквально «за уши» отдельные маргинальные проекты ради хайпа, больше ничего. Обходились бы GCC с тем же успехом и в ус не дули.

iZEN ★★★★★ ()
Последнее исправление: iZEN (всего исправлений: 3)
Ответ на: комментарий от byko3y

Наверное потому, что musl - это бездарно говно от обезьян для обезьян? И никому «лишь бы работает» в мире С/С++ ненужно, а нужно эффективно.

bajex ()
Ответ на: комментарий от iZEN

Чего ты несёшь? У тебя явно проблемы - проверься. Почитай на что ты отвечаешь. Ты спорил с тем, что есть какие-то не-си компиляторы и ты показываешь си-компилятор.

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

Ну и в сравнении с гцц - llvm/clang - это бездарное дерьмище.

bajex ()
Ответ на: комментарий от bajex

Наверное потому, что musl - это бездарно говно от обезьян для обезьян? И никому «лишь бы работает» в мире С/С++ ненужно, а нужно эффективно.

Oh rly?

byko3y ★★★★ ()
Ответ на: комментарий от byko3y

и посмотри на musl, который 82 тысяч строк. А функцию они выполняют ту же

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

Также и gcc. Можно взять маленький tcc, но скорость скомпилированной программы будет в разы меньше.

monk ★★★★★ ()
Ответ на: комментарий от byko3y

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

bajex ()
Ответ на: комментарий от byko3y

Byte search (strchr) 0.142 0.243 0.198 0.028 - это уже похоже на враду, всё остальное - фейчина.

bajex ()
Ответ на: комментарий от monk

Также и gcc. Можно взять маленький tcc, но скорость скомпилированной программы будет в разы меньше.

tcc не является компилтором. Тебе уже показали шланг, которы развался как огрызок слепленный на коленки на мусорных си с классами. Где 80% сложности - это эффективность компиляции и адаптация для бездарной скриптухи.

Где подобное от тебя? Сколько в мире всякого фп-сброда. И нихрена нет, только воруют и то лишь потому, что С/С++-хозяин дал такую возможность.

К тому же 90% производительности там достигается элементарно. И причина этой производительности - язык, а не компилятор.

Ты прикрутил к своему дерьму ворованный llvm? Помогло? Нет.

bajex ()
Ответ на: комментарий от bajex

У тебя проблемы вызывают агрессивные оптимизации, которые есть и были только в си компиляторах.

Вплоть до 2000 года числодробилки на фортране работали значительно быстрее, чем те же алгоритмы на Си.

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

Естественно. Трудозатраты я не в бабле меряю.

Ну и это не помешало llvm написать парой студентов.

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

monk ★★★★★ ()
Ответ на: комментарий от bajex

И нихрена нет, только воруют и то лишь потому, что С/С++-хозяин дал такую возможность.

У Haskell и SBCL свои компиляторы, не зависящие от С/С++.

monk ★★★★★ ()
Ответ на: комментарий от bajex

Ты спорил с тем, что есть какие-то не-си компиляторы и ты показываешь си-компилятор.

GCJ ещё можно упомянуть. Но не взлетело в виду малой восстребованности и актуальности.

А твоё бсд никому не интересно.

Она интересна людям, которые хотят разобраться в том зоопарке программного софта, который доступен в исходниках. К сожалению GNU/Linux отгородился от пользователей барьером из мантейнеров и завязок на конкретный дистрибутив, политику бинарного распространения. Даже source-based дистрибутивы Linux — удел маргиналов в твоём понимании. Это привело к ограничению и гранулярности кодовых баз — этакий набор клеток, в каждой из которых свои правила поведения для пользователей.

Ну и в сравнении с гцц - llvm/clang - это бездарное дерьмище.

К сожалению, нельзя отказаться ни от одного из них в пользу чего-то одного унифицированного. Необходимо держать их вместе (не по одной версии) и пользоваться периодически для сборки. Унификация C/C++ не завершена. А прошло уже столько лет. Это — позорище.

iZEN ★★★★★ ()
Ответ на: комментарий от iZEN

Унификация C/C++ не завершена. А прошло уже столько лет. Это — позорище

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

byko3y ★★★★ ()
Ответ на: комментарий от monk

Вплоть до 2000 года числодробилки на фортране работали значительно быстрее, чем те же алгоритмы на Си.

Это, это нелепая фейчина для идиотов.

Естественно. Трудозатраты я не в бабле меряю.

Нету никакого ественно. Быть у тебя хоть милларды бабла, хоть миллиарды рабов - ты ничего не сделаешь и не сделал.

Потому что родить что-то может только мир С/С++ - всё остальное бесполезный мусор и паразиты. И твоя проблема не в трудозатратах - ты просто врёшь. Проблема в том, что у тебя нет языка и не человеческого капитала. А вот рабов и «языков» у тебя много, а это и есть такие же ресурсы. Где вопрос качества, не наличия ресурса.

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

У тебя нет даже этого. Да и с того момента поменялось мало что. Тебе уже сказали, что 90% производительности там достигается элементарно.

bajex ()
Ответ на: комментарий от monk

У Haskell и SBCL свои компиляторы, не зависящие от С/С++.

Зависящие. К тому это не компиляторы, а мусор. Это дерьмо как транслировалось в сишку так и транслируется.

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

bajex ()
Ответ на: комментарий от monk

А вот для компьютерных игр важна скорость и там используют C++ везде, где возможно (то есть кроме телефонов).

в играх плюсовый движок обложен со всех сторон скриптами или в лучшем случае другим ву-языком типа c#

Ford_Focus ★★★★★ ()
Ответ на: комментарий от Ford_Focus

и потом оказывается, что на фуфыксе 24фпс, а на норм проце 240фпс

anonymous ()
Ответ на: комментарий от iZEN

Она интересна людям, которые хотят разобраться в том зоопарке программного софта, который доступен в исходниках. К сожалению GNU/Linux отгородился от пользователей барьером из мантейнеров и завязок на конкретный дистрибутив, политику бинарного распространения.

Нет, она не может быть интересна людям. И им же и не интересна по той самой причине.

Никакого софта там нет. Бездарное дерьмо. Всё ворованное.

Даже source-based дистрибутивы Linux — удел маргиналов в твоём понимании.

В моём понимании не source-base ненужен. И я всегда пользовался и пользуюсь гентой. Хоть она и дерьмо, как и linux, но в сравнение с бсд-дерьмом это эталон.

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

Нет - это привело к тому, что мир linux куда как сложнее. Потому как развивается для «нужно» а не для «ой, хозяин, снеми мея - шлюху».

К сожалению, нельзя отказаться ни от одного из них в пользу чего-то одного унифицированного. Необходимо держать их вместе (не по одной версии) и пользоваться периодически для сборки. Унификация C/C++ не завершена. А прошло уже столько лет. Это — позорище.

Никому никакая унификация ненужна - это для бездарных обезьян. Люди подобным не пользуются.

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

bajex ()
Ответ на: комментарий от monk

Покажи, где здесь хоть намёк на трансляцию в сишку: https://github.com/sbcl/sbcl

Нахрен мне эта бездарная параша. Я про хаскель говорил. Это вообще мусор на который даже смотреть смысла не имеет.

bajex ()
Ответ на: комментарий от alienclaster

Будет экосистема на лиспе - будут писать на лиспе

не будут

Ford_Focus ★★★★★ ()
Ответ на: комментарий от monk

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

К тому же, сама формалировка Fortran was faster than C уже определяет этот клоуна бездарным идиотом. Потому что нет никакой быстроты си - это херня для придуманная бездарными идиотами.

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

bajex ()
Ответ на: комментарий от monk

Давай попроще. Что мы имеем. Есть какая-то бездарная фортран-обезьяна. Это уже диагноз. Эта обезьяна пошла и насрала что-то на си(ну по её заявлениям. Есть ли там си неизвестно). А далее непонятно как и чем собрало и что-то там получила. И оказывается какое-то бездарное дерьмо быстрее си.

Тут первый же вопрос возникает. Какое отношение высер бездарной собаки на «си» имеет к си? Си код написан людьми, а не собаками. А то, что собака может насрать лабу на си - это не показатель.

И то, там собака даже лабу не бацала. 90% там был какой-то конвертер дерьма, коих были тысячи.

bajex ()
Ответ на: комментарий от monk

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

Ford_Focus ★★★★★ ()
Ответ на: комментарий от bajex

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

В системе должен быть ОДИН CC, выбранный тобою, а не разработчиками дистрибутива/разработчиками приложений. Ты понимаешь важность такой концепции или тебе всё равно?

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

iZEN ★★★★★ ()
Ответ на: комментарий от iZEN

Ты обгдался с одним и начал кукарекать о другом? Системе достаточно только одного компилятора и такого которого я хочу.

К тому же, есть только один компилятор одной версии - это последний гцц. Т.е. никакого выбора нет. Если у тебя он есть - ты идиот.

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

Никакой необходимости нет. Ты опять опозорился. Системе нужен один компилятор С/С++. Опять ты реалии своей бездарной херни проецируешь на реальность.

bajex ()
Ответ на: комментарий от monk

Я на самом деле поступил иначе. Примерно то же, что в Linux, есть и у микрософта. Полагая производительность труда и объём функционала равным, и зная (одна бабка сказала), что в МС трудится 40 тыс инженеров, и прикидывая, что в 90-е появлялось что-то новое, а с начала нулевых уже практически ничего нового нет, оцениваю в 400 тыс. человеко лет. Забавно, что у вас сошлись оценки по gcc. В целом конечно сложно провести границы. Минимальный набор софта «для ИТ-суверенитета» почти написан микрософтом, а меня именно этот объём интересует. С другой стороны, есть куча жизненно важного для ИТ-суверенитета софта, к которому микрософт не касался (КАДы, моделирование). И с третьей стороны, у микрософта один SQL-сервер (который они к тому же купили), а вообще в мире их много. Но класс, мне нравится, спасибо!

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от bajex

Никому никакая унификация ненужна - это для бездарных обезьян. Люди подобным не пользуются.

А могли бы. (См. проект Oberon). Да те же Pascal/Delphi (позже FreePascal как жалкое подобие первоначальной концепции) сражались с C/C++ за право быть безопасными, быстрыми и удобными (за счёт модульности и оптимизаций кода). Где они теперь? В «бутылке» маргинальных продуктов для обучения и поддержки унаследованных систем.

iZEN ★★★★★ ()
Ответ на: комментарий от monk

Только гораздо медленнее. Возвращаясь к примеру кода на Haskell в начале этой темы. Есть короткий и медленный и есть быстрый, но огромный и почти нечитаемый.
Также и gcc. Можно взять маленький tcc, но скорость скомпилированной программы будет в разы меньше

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

Мне понравилась лекция бабули, которая в 80-х занималась разработкой оптимизирующих компиляторов, и самый запомнившийся мне тезис был плана «это говно невозможно оптимизировать». Половина сложности нынешних сишных компиляторов — это фронтенд, который превращает C/C++ в ML-подобный язык a.k.a. SSA/IR/etc.

Вот транслятор IR в машинный код уже представляет собой настоящую ценность, которую ничем не заменишь и сложность трансляции не обойдешь. Правда, нужно понимать, что в среднем по палате приложении 95% кода занимают 5% процессорного времени, и потому пофигу вообще с какой скоростью они выполняются. Оставшиеся 5% можно оптимизировать руками. Ну или написать на Си и положить на полку (привет питону). memset медленный? Напиши свой или возьми быструю реализацию из того же glibc — но на кой черт захламлять приложуху переусложненными, хоть и очень быстрыми либами?. И в итоге все равно на каких-нибудь числодробилках GPGPU и FPGA будут уделывать ЦП в хламину, то есть, на один-два порядка — поэтому, внезапно, TensorFlow на питоне с видеокартой уделает по производительности абсолютно любую реализацию на любом языке, ограниченную ЦП.

byko3y ★★★★ ()
Ответ на: комментарий от iZEN

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

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

Си просто опередил своё время и выстрелил в уже ближе к нулевым. Когда выросло новое поколение, которое массово пришло и в область и в СПО.

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

bajex ()
Ответ на: комментарий от byko3y

GCC — это сплошной многоярусный идол преждевременной оптимизации.

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

in_dance ()
Ответ на: комментарий от bajex

К тому же, есть только один компилятор одной версии - это последний гцц. Т.е. никакого выбора нет. Если у тебя он есть - ты идиот.

У меня есть mesa-libs/mesa-dri, без которых невозможен графический режим работы. А им нужен рантайм LLVM-10.

У меня есть системный LLVM-11, без него невозможна работа операционной системы, сборка ПО из дерева портов и самой ОС из исходников.

LLVM-12 требуется для сборки последних версий Rust и Mozilla Firefox/Thunderbird. Ставится на время сборки (только build-зависимость), потом можно удалить.

Про GCC в последнее время что-то глухо - может GCC-10 для чего-то и понадобился, но лишь на время сборки какого-то пакета. В системе и среди установленных пакетов он лишний.

Недавно предпринял очередную попытку собрать всё ПО одним GCC-12 - не вышло - несобирающиеся зависимости. Ранее удавалось собрать 99% установленного ПО, на сегодняшний день - нереально.

На самом деле у меня выбора нет.

iZEN ★★★★★ ()
Последнее исправление: iZEN (всего исправлений: 2)
Ответ на: комментарий от iZEN

Да те же Pascal/Delphi (позже FreePascal как жалкое подобие первоначальной концепции) сражались с C/C++ за право быть безопасными, быстрыми и удобными (за счёт модульности и оптимизаций кода)

Я рекомендую изучить историю, потому что сражение там было совсем не то, каким ты его рисуешь. Сражение там было за обладание деньгами от самых утонченных ценителей смузи, а не за улучшение технологий и не за оптимизацию трудозатрат на разработку. Вирт, по сути, почти в одно рыло поднял весь паскаль. Потом уже, когда машина хоть как-то раскрутилась, неохотно манагеры в кабинетах зашевелились и начали раздумывать в этом русле. Появились робкие реализации компиляторов, появился Turbo Pascal, который в свое время давал пососать и сишным компиляторам, как по оптимизации кода, так и по скорости работы самого компилятора. Но потом пришло новое поколение эффективных манагеров, и еще одно, Turbo Pascal скурвился, а замены ему не было. А предок JVM — UCSD Pascal, возник почти за 20 лет до JVM.

Но пути манагеров бессмысленны и беспощадны, потому в итоге мы имеем вырвиглазный сишный синтаксис повсюду, и бесполезные классы вместо построенных на функциях и типах данных языков. Да, в итоге индустрия постепенно и неохотно приходит к let x: u32 = 2; вместо int x = 2;, в C++ и Java вводят лямбды и ADT с pattern matching вместо классов, но наследие уже накоплено и избавляется от онного индустрия очень неохотно.

byko3y ★★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)