Топ языков программирования по скорости

Видео:Самый быстрый язык программированияСкачать

Рейтинг языков программирования в 2021 году

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

Например, в середине в 80-х стал очень популярен язык Prolog, но потом его популярность резко снизилась. И сейчас на нем практически никто не пишет. А место популярного новичка занял Python.

Как же узнать рейтинг языков программирования? Общего рейтинга не существует, так как нет простого способа собрать подобную статистику. Но существуют разные способы оценки популярности языков программирования. Рассмотрим самые популярные рейтинги.

Видео:ВЫБИРАЕМ ЯЗЫК ПРОГРАММИРОВАНИЯ ))))Скачать

1. Рейтинг TIOBE Index

Рейтинг TIOBE Index построен на оценке результатов поисковых запросов, содержащих название языка. Логика этого индекса очень проста: «Если язык ищут в поисковых системах, то он популярен». Конечно же, это заявление спорное, потому что программисты-профессионалы крайне редко будут искать в поисковике именно название языка программирования. Они чаще ищут решение конкретной задачи. Но громадный плюс этого рейтинга в том, что он достаточно объективно показывает интерес к тому или иному языку.

Индекс TIOBE показывает самые популярные языки программирования, информации о которых искали на 25-ти самых популярных поисковых системах, то есть запросы вида: «+» programming». Индекс обновляется раз в месяц.

Индекс TIOBE на март 2021 года выглядит так:

На графике изменений индекса хорошо видны как менялась популярность языков программирования. Но при этом первое-второе место постоянно делят два языка Java и C. Хотя Java активно продвигается компанией Oracle, а язык C никто не продвигает.

И еще интересно то, что C++ ни разу не смог превысить по популярности C.

Видео:5 САМЫХ ЛЁГКИХ языков программированияСкачать

2. Рейтинг Wappalyzer для веб-приложений

Сервис Wappalyzer использует различные методы для идентификации веб-технологий. Рейтинг языков программирования для разработки сайтов на январь 2020 выглядит так.

В веб-программировании однозначно лидирует язык PHP, почти 80% сайтов написано на этом языке.

Видео:Никогда не учите эти языки программирования #програмист #программированиеСкачать

4. Рейтинг IEEE Spectrum

Ежегодный рейтинг IEEE Spectrum Top Programming Languages использует 11 метрик из 8-ми источников, включая поисковые запросы, упоминания в твиттере и даже упоминания в вакансиях на работу программиста. С одной стороны этот рейтинг использует больше данных, но с другой стороны во многих источниках данные имеют связанный характер. Чем больше публикуются вакансий на некоторый язык программирования, тем больше запросов будет в поисковых системах. То есть у новых языков больше шансов попасть на вершину рейтинга.

Рейтинг IEEE за 2020 год выглядит так:

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

Видео:Мой рейтинг Языков ПрограммированияСкачать

5. Рейтинг Stack Overflow

Сайт Stack Overflow — это площадка, на которой разработчики могут задавать и отвечать на вопросы по программированию. Этот сайт имеет около 40 миллионов посещений в месяц. Есть русскоязычная версия сайта: ru.stackoverflow.com

Этот рейтинг рассчитывается на основе опроса разработчиков. В 2020 году было опрошено более 65 000 разработчиков и составлен рейтинг языков программирования. Скорее это рейтинг языков, которые вызывают вопросы. В этом рейтинге лидером стал JavaScript.

Такая популярность вполне объяснима, сейчас JavaScript бурно развивается и каждая новая возможность вызывает массу вопросов, поэтому программисты идут на сайт Stack Overflow, чтобы задать вопросы.

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

Видео:😱 САМЫЕ СЛОЖНЫЕ ЯЗЫКИ ПРОГРАММИРОВАНИЯСкачать

6. Вакансии на Head Hunter

Можно подойти к рейтингу языков программирования с другой стороны и посмотреть, какие языки указываются в вакансиях и сколько собираются платить. Одна из самых популярных площадок для поиска работы в IT-сфере — это сайт HeadHunter. Там есть отдельный раздел — вакансии для программистов.

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

Здесь видно, что программист, знающий Pascal (среда Delphi), все еще востребован.

Видео:Python против C++, C#, JS. Ускоряем Python [ JIT Numba ]Скачать

7. Google Books Ngram Viewer

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

В начале этой статьи приведены графики использования слов Prolog и Python. А теперь введем JavaScript, Python и PHP.

Видно как в 1992 году появляется интерес к JavaScript и он быстро обгоняет Python и PHP.

Похожие записи:

Комментарии 30

Совсем мелкая ошибка в предпоследнем предложении. Вы написали «В начале этой статьи приведены графики использования слов Prolog и Pascal», а там были Prolog и Phyton.

Не Phyton а Python. (Pascal мой первый язык программирования (Turbo, а далее Delphi))

«Для оценки перспективности своих усилий каждый программист должен регулярно смотреть рейтинг языков программирования.» — совет неоднозначный. Профессионал обычно хорошо знает 1-2 языка и специализируется на них довольно долго. Изучение другого языка происходит обычно по причине старта какого-нибудь проекта, или тупика в карьере с текущими знаниями.

Здравствуйте! Спасибо за статью!
Хотел бы узнать Ваше мнение насчет языка программирования Prolog. Дело в том, что язык программирования Prolog используется в разработке программ для искусственного интеллекта.Так как технологии искусственного интеллекта развиваются все интенсивнее, не станет ли язык программирования Prolog популярным, ну или востребованным?

Здравствуйте! Язык Prolog стал популярен в 1980-х годах в связи с японской программой создания программы искусственного интеллекта. Но эту программа кончилась грандиозным провалом. В результате все наработки были розданы бесплатно и никаких полезных программ так и не было создано. Поэтому сейчас Prolog полностью морально устарел и не используется. Даже если и будет новый прорыв в разработке искусственного интеллекта, то, скорее всего, он будет связан с другой технологией и другим языком программирования.

В девяностом году шеф мой взял аспиранта себе на написание САПР, типа Симулинк в Матлабе. Тогда ещё XT-шки были в диковинку. И был в то время бум создания «Искусственного интеллекта». Ходили шутки, что это нужно, когда своего интеллекта не хватает. Ну и аспирант этот решил создавать этот САПР на языке Пролог. Тогда ещё книг, типа Братко не было. В ДОСе работали. Ну и он разобрался в языке этом глубоко так. Ему понравилось в нём лазить по деревьям и делать откаты. В других языках это геморройно было, а в Прологе это вшито как аксиома (исходные кирпичики языка). То есть если программа заходит в тупик, то как-то самореализуется всё там, что она, делая откаты назад сама ищет выход из этого тупика. И аспиранту это нравилось в ней. Написал он в ней САПР свой, «Гаммой» назвал его, была куча публикаций. Но потом бросил заниматься этим и диссертации не защитил. Его пригласили в СберБанк программистом работать, а там зарплаты уже со стипендией аспиранта не сравнить. Так всё это и забросилось. Отчёт в семи томах кода сохранился с той поры и валяется где-то. У меня на даче очень много книг по Прологу на чердаке стопками лежит не тронутых, а Братко, по моему, аж десять экземпляров. В то время хлеб стоил сто рублей, а книги эти по рублю продавались. На растопку жалко их рвать…

у меня тоже лежит экземпляр книги по Прологу и не выбросил до сих пор в макулатуру. Да и другие книги по выч-технике и програм-ю 80-х и 90-х годов. В библиотеку их не возьмут. А ещё 3-х томник Ленина и т.п.

Интересный обзор! А что вы можете сказать про Rust в контексте перспективы дальнейшего развития?

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

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

Как видно из обзора функциональные языки программирования типа Lisp — практически не используются в настоящий момент? Это очень узкая сфера использования? Или есть другие причины?

Источник

Видео:Какой язык программирования выбрать в 2023 году? #golang #программирование #айтишникСкачать

Сравнение скорости работы языков программирования на примере решения задачи обучения нейронной сети

Видео:Какой язык программирования выбрать новичкуСкачать

Цель работы

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

Видео:Какой язык программирования учить сейчас? О выборе между frontend и backend.Скачать

Железо и ОС

Для тестирования по Ubuntu и Windows ( ноутбук DELL Inspiron-7577):

CPU: Intel Core i7-7700HQ @ 8x 3.8GHz

рис. 1 (вывод команды screenfetch на ноутбуке DELL Inspiron-7577 под ОС Ubuntu)

Для тестирования на под MAC:

CPU: Intel Core i7 2.7GHz

Так-же мы провели тесты на Raspberry pi 4:

CPU: ARMv7 rev 3 (v7l) @ 4x 1,5Ghz

рис. 2 (вывод команды screenfetch на raspberry pi 4)

Видео:Язык программирования Go. Фёдор КороткийСкачать

Программа для тестирования

Для проведения тестов была написана программа имитирующая сеть из 5 нейронов, целью программы является научится правильно решать задачу нахождения исключающего или с точностью delta = 0.01. Все параметры и свойства нейросети, а также алгоритм работы и обучения были взяты из этих 2 постов:

Единственные изменения были внесены в коэффиценты E (эпсилон) — скорость обучения, α (альфа) — момент (E = 0.3, α = 0.5). При использовании значений указанных в статье нейросеть в течении длительного времени (8 ч.) не могла найти решения.

По своей структуре программа представляет из себя некую ООП модель, в которой класс NeuronNet оперирует массивами объектов класса Neuron и Sinaps. Объект класса Sinaps содержит в себе ссылки на 2 объекта класса Neuron. Для расчетов с плавающей точкой применяется тип данных double.

Алгоритм тестирования:

рис. 3 (пример вывода программы написанной на языке Kotlin, запущенной под ОС Ubuntu)

Видео:JAVA vs PYTHON. Сравнение языков программирования.Скачать

Результаты тестирования

При работе программы написанные на Kotlin, Java, php, ruby и Python давали одинаковые ответы после обучающего сета, вывод после обучающего сета программы написанной на С++ был другим, что повлекло за собой изменение количества эпох которое ей потребовалось для должного обучения. По этой причине будут приведены как сравнения времени работы всей программы так и времени которое потребовалось для прохождения одной эпохи.

таб. 1(время прохождения всех эпох до обучения нейросети)

таб. 2(время прохождения одной эпохи)

Видео:Вся суть программирования на PythonСкачать

Анализ результатов

граф. 1 (время прохождения всех эпох для программ запущенных на ОС Ubuntu)

Как и ожидалось Kotlin и Java показали одинаковую скорость работы обогнав Python примерно в 20 раз. Рассмотрим некоторые не столь очевидные наблюдения.

Неожиданно медленными оказались результаты работы программы написанной на C++. Отчасти это можно объяснить большим количеством эпох которое ей потребовалось для нахождения правильного ответа. Однако даже с учетом этого (см граф. 2) она отстает по быстродействию от Java программ.

граф. 2 (время прохождения одной эпохи для программ запущенных на ОС Ubuntu)

Еще одной причиной подобных результатов может быть различное использование ресурсов процессора (см рис. 4, рис. 5)

рис. 4 (вывод монитора порта Ubuntu во время выполнения программы написанной на Kotlin)

рис. 5 (вывод монитора порта Ubuntu во время выполнения программы написанной на C++)

Как можно видеть, Java единовременно использует минимум 4 ядра, в то время как программа на C++ — одно. Однако, этим нельзя объяснить превосходство в скорости в 8 раз, так как Java не задействует все ядра на 100%.

Существенные различия в скорости работы программы написанной на Python в зависимости от ОС. При запуске программ на Java на разных ОС различия в скорости работы составили не более 40% (даже на разных машинах, за исключением raspberry), однако при запуске програмы на Python были получены следующий значения: Ubuntu — 104c, Windows — 204c, MAC — 335c. Отношение скорости работы программы на Kotlin к скорости работы программе на Python составляет 21 для ОС Ubuntu, 26 для Raspberry и аж 43 для Mac.

Все интерпретируемые языки программирования показали одинаковую скорость работы на Raspbery

Источник

Видео:ВСЕ ЯЗЫКИ ПРОГРАММИРОВАНИЯ — ДЕРЬМОСкачать

Самый быстрый язык программирования: Scala, Java или может быть Python?

Понадобилось мне написать программку, пересчитывающую массив географических координат из одной системы в другую. Написал на Ruby в несколько строчек. Время выполнения — 16,5 сек. Чего так долго? Решил написать то же самое, но на разных языках, чтобы заценить производительность современных языков программирования. Результаты оказались неожиданными.

[TOC Самый быстрый ЯП]

Ruby простой, удобный и. очень медленный. Вообще-то, это мой любимый язык программирования. Нравится лаконичностью и универсальностью. Хочешь web-приложение — ставь Ruby on Rails и ваяй. Нужен скрипт для системного администрирования — Ruby тоже очень хорош. Но в Руби всё настолько модное, динамическое и объектно-ориентированное, что язык, прямо скажем, очень нетороплив. И это справедливая плата за удобство. 16,5 сек.

Видео:5 самых востребованных языков программирования в 2022 годуСкачать

JRuby

Обалденный проект! JRuby берет скрип на Ruby и компилирует в байт-код Java. А VM от Явы славится своей отполированностью и производительностью. Плюс огромный бонус — возможность прозрачно вызывать из Ruby код на Java из миллиона первосортных библиотек и наоборот. Но не будем отвлекаться. Взял я свою программу и натравил на нее компилятор JRuby. Время расчетов сократилось в 2 раза и составило 8,6 секунды. Получаем ускорение в 2 раза с нулевыми затратами.

Go — моднейший и распиаренный язык от Google. Программа компилируется в бинарный код. Разработчики обещают высочайшую производительность. Проверяем. 3,7 сек. Отлично! Но ведь Си всё равно будет быстрее?!

JRuby опробовали и получили 8,6. А что получится, если весь код сразу написать на Java? Тут нас ждет вторая неожиданность — 3,1 сек. Быстрее, чем Go и Си. Как это объяснить я не знаю. Возможно, кто-нибудь в комментариях расскажет, как код в виртуальной машине может выполняться быстрее нативного кода? У меня есть всего одна гипотеза и даже мне она кажется сомнительной: а вдруг виртуальная машина настолько умная, что оптимизирует код во время выполнения и распараллеливает часть задач? В любом случае, Java — это сила!

Видео:Бывший лучший язык программированияСкачать

Scala

Модный ЯП, претендующий на роль убивца Java. Тоже компилируется в бинарный код для виртуальной машины Java. Синтаксис Scala намного более приятный и — что самое главное — намного более лаконичный. А что со скоростью? Наверное, примерно как у JRuby? И тут третий сюрприз — 3,1 сек., то есть как и у Java. Но если не округлять, что у Java 3.104 сек, а у Scala 3,091. Ну вообще!

Видео:ЧТО ИМЕЕТ БОЛЬШЕ ВОЗМОЖНОСТЕЙ, C++ ИЛИ PYTHON?Скачать

JavaScript

Рассмотрим JavaScript на примере NodeJS 4-й ветки. Получилось 3,5 сек. Go и C посрамлены. Как интерпретируемая программа может оказаться быстрее нативного кода? Возможно, всё дело в чудо-движке V8 от Google, который не устают нахваливать за скорость. Кстати, это именно он установлен во всех браузерах Chrome и Chromium.

Вот мы и добрались до самого яркого представителя быдланской пэхапэплеяды. Использовалась версия PHP 5.6, хотя уже есть PHP 7, которая, как заявляют некоторые, примерно в 2 раза быстрее. Но 7 еще мало распространена, а тогда как версия 5.6 вездесуща. В режиме CLI программа отработала за 16,5 сек. Ровно столько же, сколько и на чистом Ruby. Мы получили мощное доказательство того, что не случайно специалисты объединили эти три прекрасные языка — PHP, Python, Ruby — в быдланскую плеяду. Кстати, о Python.

Видео:TOP 10 Языков программированияСкачать

Python

Для теста я использовал Python третьей ветки (3.5). Запускаем, ждем, ждем, ждем. и через 51,412 сек. программа заканчивает расчеты. В быдланской плеяде новый «чемпион». Конечно, я сразу же решил, что где-то пропустил важный нюанс оптимизации. Пришлось погрузиться в изучение этого языка и прочитать не один трактат по оптимизации. Затем я переписал программу, хотя переписывать было почти нечего: включается таймер, далее идет цикл с вычислениями по жестко заданной формуле, таймер выключается и печатаются результаты. 3 часа чтения документации и еще час на оптимизацию кода дали поистине потрясающий результат: время работы сократилось с 51,412 до 50,336 сек.

Зачем нужен этот старый пердун среди молодых и сильных атлетов? А затем, что время от времени встречаю утверждение, что Perl — это как PHP, только в 100 раз круче и быстрее, поэтому многие крутые проекты пишут на Перле. Может и вправду быстрее? Запускаем и. 18 секунд. На помойку.

Видео:Какой язык программирования учить в 2023?Скачать

Какой язык программирования выбрать?

Любой, который больше нравится. За исключением Python, конечно. Но если требуется выполнить узкую задачу — большое количество арифметических вычислений — и требуется скорость, то Java и Scala очень хороши. Кстати, теперь я понял, почему Hadoop написан на Java, а Spark на Scala.

Видео:Отличие GO от других языков программированияСкачать

Сводная таблица

Методика

Тестовые программы состояли из 3 частей:

Таймер включался только перед выполнением второй части и выключался перед третьей частью. Считать время импорта данных из CSV не было смысла, так как для этого использовались достаточно объемные библиотеки, которые для каждого языка разные. Таймер включался только для блока вычислений, который во всех языках был одним и тем же. В конце работы программы печаталось два числа: контрольная сумма и время исполнения в миллисекундах. Принудительная оптимизация включалась только для gcc, в остальных случаях использовались параметры компиляции по умолчанию.

Краткость — сестра таланта

В качестве бонуса. Самый большой объем был у программы на Java. Самый малый — у Perl. Почти столько же у JavaScript.

Комментарии

очень неграмотная статья.
тобишь таймер включался только перед вычислениями? минуя подгрузку таблиц и интерпретацию (которая поставит любой интерпретируемый язык на последние места по сравнению с компилируемыми)?
очень «умно». а ещё более «умно» делать из этого заголовок: «Самый быстрый язык программирования».

по такой логике можно составить список «самых медленных языков программирования», основываясь на том, какой из них позже всех выведет — «Hello world!».

а то что Java и Scala (при всём уважении) показали такие быстрые результаты по сравнению с тем же Go или Си — наводит на мысль что были допущены ошибки не только в замерах скорости.

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

Глупость. Сравнивать надо реализации одного и того же алгоритма. Если замерять время работы всей программы (то есть, сравнивать кислое с горячим), то мы узнаем только то, разработчики какой библиотеки импорта из CSV пишут более качественный код.

тест проведён неграмотно.

так а кто вам сказал что тесты производятся совместно со сторонними библиотеками?

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

1. замеряется время.
2. запускается ВСЯ программа, а не её КУСОК.
3. после завершения программы — отнимаем текущее время от замеренного.

и на основании этого делается вывод о скорости программы.
а при создании аналогичных алгоритмов для других языков (опять же средствами языков и его библиотек) можно сделать вывод о СКОРОСТИ ЯЗЫКА для решения данной проблемы.

какие ошибки допустили вы?
1. использовали (я предполагаю) сторонние библиотеки, которые могут быть написаны криво.
2. замерили ТОЛЬКО КУСОК кода, вместо ВСЕЙ программы, забыв и про интерпретацию и при индивидуальную особенность каждого языка. один делает что-то быстрее, другой делает тоже самое медленней.
3. на основании ошибок в методологии — сделали вывод о скорости языков ВООБЩЕ.

>одного и того же алгоритма.

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

как я сказал выше, что мешает по вашей странной логике, замерить время ДО ‘Hello world» и ПОСЛЕ — и на основании этого сделать вывод о скорости языков? это же проще. пусть неправильно, но для вас — прокатит.

использовали (я предполагаю) сторонние библиотеки, которые могут быть написаны криво

Уважаемый эксперд, вы хоть статью читали и то, что вам отвечают? Какие кривые библиотеки? Замерялся только блок арифметических вычислений. Алгоритм везде один и тот же. Внешнего кода нет.

вы можете бодаться дальше, но факт «на лицо» — тест некорректен.
особенно для того что-бы делать из него такие громкие выводы.

не верите мне? ну наберите в интернете «тестирование языков на скорость», там будет описано: как это делают адекватные люди, какие способы используют, какие алгоритмы и результаты, которые (что не удивительно) абсолютно противоречат вашим.

Страшное дело, когда гуманитарий берется рассуждать по техническим вопросам. Ну а попытка спрятаться за Гугл — отличительный признак №1 такого «спеца». 🙂

Тест офигительный. Статья еще лучше. Если отдельные пионеры чем-то недовольны, то это проблемы самих пионеров. Читайте правильные статьи, от своих одноклассников. Что я еще могу сказать? ;))

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

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

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

Автору спасибо за качественный обзор!

Scala мальчикам, Python девочкам.

А если попробывать JPython и PyPy?

Во первых — тексты программ в студию. Для объективности, надо-бы посмотреть как расчёты в разных ЯП организованы.

Но вообще, мой опыт показывает, что в общем случае, задачи, будучи правильно реализованными, покажут примерно одинаковую производительность во всех языках и средах выполнения. Примерно одинаковую — это + — 50% по времени выполнения. При этом надо понимать, что области применения у разных языков различные, и, очевидно, какие-то конкретные штуки те или иные языки и среды будут выполнять совершенно по разному.

JIT это вам совсем не интерпретация. Загуглите педивикию. Вообще, JIT в v8 — давно уже вплотную приблизился по скорости к нативному C,C++. Прямую ссылку не дам, но пару лет назад на конференции разрабов Unity3D — достаточно подробно тему проивзодительности JS в современных браузерах обсасывали. Меня тогда очень поразило, что связка C#->LLVM->ASM.JS уже тогда могла работать быстрее чем нативный C#->IL->JIT из MONO 2.10 в unity3d. Если интересует инфа более релевантная для вашего случая, то она прекрасно гуглится по запросу «javascript v8 vs c++ performance».

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

Практически любой. Фича вводится дополнительной библиотекой. Например, в C# есть структура BigInteger, позволяющая хранить числа любой длины (в пределах доступного объема ОЗУ, разумеется) и выполнять ограниченный набор арифметических операций над ними.

Но Ruby действительно рулит! 🙂

Практически любой. Фича вводится дополнительной библиотекой. Например, в C# есть структура BigInteger, позволяющая хранить числа любой длины (в пределах доступного объема ОЗУ, разумеется) и выполнять ограниченный набор арифметических операций над ними.

можно это реализовать на любом ООП-языке, особенно поддерживающем перегрузку операторов(можно на питоне, c++, паскале, даже на javascript-e)

По-моему, всё ровно наоборот. Скрипт на Ruby будет работать где угодно. Если скрипт старый, то можно использовать RVM. А вот что делать с бинарником C/C++, который, например, динамически слинкован со старыми библиотеками? Только выкинуть.

простите, не знаю таких проблем. Если бинарник С/С++ динамически залинкован со старой библиотекой, то обновляется библиотека. На этом и стоится обновление функционала многих самописных программ в разных компаниях. Конечно, если программист чудак на букву м, то можно поиметь ошибку в виде «точка входа в динамическую библиотеку не найдена» итд. Но такое случается гораздо реже, чем морока с той же джавой. А многие вообще тупо статистически линкуют прогу с библиотеками. Обновлять по частям нельзя, зато и проблем с запуском никаких.

Если бинарник С/С++ динамически залинкован со старой библиотекой, то обновляется библиотека.

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

А многие вообще тупо статистически линкуют прогу с библиотеками.

Для старья это единственный разумный выход. Раньше так, например, распространяли бинарники браузера Opera для Linux. Так до сих пор запускается. 😉

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

а зачем ставить еще одну версию, когда можно просто поставлять jvm вместе с софтом, а перед запуском передать в определенных переменных окружения путь к нужному бинарнику java? Я много раз так создавал пакеты под виндой для старого софта, который нуждался в определенной версии jre, например 1.3. Да и некоторые програмы сами так и делают, конечно минус — размер вырастает сразу на 50 Mег.

А не поставляют. Я и видел-то прогу с зашитым jvm в экезшник всего один раз. Проблема тут не в размере, проблема тут в «легендарной» совместимости ради которой и был придуман этот дичайший костыль под названием Java Virtual Machine. Ненавижу. Дома я вообще никогда не ставлю того что требует jvm. А на работе выбирать не приходится. Хотя вынужден признать, что нынче программ написанных на джаве мне ставить приходится куда меньше чем прежде. Помню как в 2003м заказчику ставили оракл и оракл формы. О эти чудные мгновенья, именно тогда я проклял джаву и оракл. Заняло неделю чтоб найти jre версию на которой эти формы запустятся. И то не на сайте sun.com, той версии не было уже. Когда я таки запустил формы, у нас были вопли как у роскосмоса при успешном запуске ракеты. А сейчас джава принадлежит ораклу, так что ненавидеть удобно, всё в одном флаконе, не надо распаляться. Но секса с джавой с тех пор не убавилось если программист не потрудился jvm зашить в экзешник. Программисты, скажите, зачем вы пишете программы на джаве? неужели такой охрененный язык ради которого нужно терпеть все эти костыли? Или потому что работодатель хочет, ибо их идиоты повелись на маркетологов джавы?

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

хотя c++ под дотнет тоже есть

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

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

Писака ты, а не умный людь. 😀 Сильно сомневаюсь, что ты хоть по одному языку прочитал руководство полностью. А они знаешь ли довольно большие. Конкретно код в студию! На всех языках. Вот потом умничать будешь.

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

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

Нет, просто грамотность — это показатель интеллекта. Если человек русский язык не осилил, то языки программирования и подавно не для его IQ. Перестань прогуливать уроки, поднажми на орфографию и когда-нибудь я соизволю с тобой пообщаться на тему программирования. А пока тебе отведена роль хомячка, подыскивающего IP всяких помоек для обучения фильтра говнокаментов. И не более того, не надо себе льстить. 😉

ИМХО
Всерьёз читать сей опус не рекомендую.

PS: почитал комменты, автор нагл и агрессивен.

какие 3,1 сек у джавы? у меня на компе она только запускается 11 секунд.
там используется файл rt.jar который если не изменяет память представляет собой зип-архив 30 мб. и при запуске он целиком читается с диска, распаковывается каждый файл из него.
все это жутко нерационально реализовано, отсюда и медленно.
и программы на джаве жрут огромное количество оперативки. Многие иде написанные на джаве жрут до хрена памяти и медленно работают даже на очень быстрых компьютерах. У меня на ноутбуке такие проги как pyCharm написанные на джаве запускаются по 2 минуты. не пользуюсь из-за этого.
Питон хоть меньше памяти жрет и быстрее запускается.
В питоне тоже стандартная реализация не совсем рациональная и плохо оптимизированная(по скорости выполнения кода).
В джаве код быстро работает но запускается долго и памяти расходует много.
В C/C++ надо учитывать что там к проге грузятся динамические рантайм-библиотеки размером несколько мегов. Тоже время занимает.

и IDE WebStorm которая на этом сайте рекламируется(написанная на джаве) у меня на компе запускается по 5 минут)))).
Хотя говорят удобная ИДЕ.

JavaScript как язык по динамичности примерно такой же как питон.
Из объектов можно динамически при работе программы удалять-вставлять свойства и методы,
динамическая типизация(можно менять тип переменной при выполнении программы).
Массив в JS может состоять из значений разных типов и можно работать как с динамическим списком(аналог и подходит для реализации типа список питона).

То есть видимо Питон не из-за каких-то своих особенностей медленней чем JS, а из-за того что просто не сделали быструю реализацию.
Потому что V8 для js разрабатывает гугл, а питон Python Software Foundation (некоммерческая организация).

Наверное надо попробовать сделать реализацию питона поверх V8.

Мде. Методика теста вызывает сомнения.

НЕЛЬЗЯ проверять «только арифметический блок»! Рантайм вполне может начать вычисления *ДО* того, как формально управление будет передано алгоритму. V8 может (и будет!) делать такие вот «предварительные оптимизации», которые в рамках данного теста оказываются «за бортом».

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

Да, это верно даже в отношении «всего одна формула». Я предлагаю вызов для уважаемого pomodor: я берусь улучшить Ваш «алгоритм» на javascript, python, C (этими языками я владею уверенно) или PHP (у вас очень плохой результат для PHP, уверен, что где-то ошибка) «вслепую», не зная как именно Вы его имплементировали так, что скорость выполнения или использование памяти уменьшится хотя бы на 5%.

Я уж не говорю про статические оптимизации в компилируемых языках.

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

Код в студию. Без тест-кейзов исследованию веры нет.

Я уж не говорю про такие прелести как сборщик мусора, который есть в каждом представленном языке, кроме C, и который, полагаю, ни разу не отработал из-за ограниченного объема данных и allocate only подхода. А если и отработал — то ПОСЛЕ ТОГО, КАК ТАЙМЕР ВЫКЛЮЧИЛИ, хе-хе.

Чем и объясняется «фантастическая скорость» Go, Java, JS и иже с ними: у них оставался отложенный кусок, который БУДЕТ создавать проблемы на реальном проекте, но который был «хитро пропущен» в тесте.

Тесты некорректны. Не могут виртуальные машины быть быстрее нативного кода. Хотя бы потому, что они сами написаны на нём ))) Это как быть более католиком, чем сам Папа Римский )))

Могут. За счет runtime-оптимизации. Виртуальная машина находится на более привилегированном положении, так как может «видеть», как исполняться код, снимать метрики и подкручивать характеристики в процессе исполнения. При компиляции в нативный код доступна только статическая оптимизация.

А почему аффтар забывает, что руби входит в пыхоплеяду (быдлянскую плеяду)?

>Несмотря на то, что схемка и смолток делают остальные скрипты совершено ненужными, массы динамических петушков выбирают ПЫХОПЛЕЯДУ (Perl, PHP, Python, Ruby).

М-да, аффтар — типичный фанбой руби.

P. P. S. За парсер отедльное не-спасибо.

JavaScript быстрее C.

Насколько автор должен быть безграмотным, чтоб подобное вообще вообразить?

Ага, а питон медленнее руби в 3 раза. А потом на эту статью ссылаются в споре, лол

А то что эта статья первая в выдаче гугла только подтверждает наблюдение, что запросы по IT/science тематике на русском ведут на какой-то лютый треш от диванных специалистов. Уж не знаю, рунет ли в целом «не очень» или просто гугл не может в норм алгоритмы поиска на русском

Выложил бы тесты с проверочными данными на гитхаб, а?

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

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

Спасибо за шикарный обзор, который постарался, но не отбил у меня желание изучать Python! 🙂

Я не переживаю что мне не хватит скорости питона. Я как и Лутц скажу: «Вы не переживайте что язык питон медленный, вам его скорости хватит!». С запасом хватит.

Источник