сравнение 15 языков программирования

[Olej]

сравнение того, как выглядит одна и та же задача на 15 языков программирования:

http://mylinuxprog.blogspot.com/2014/02/10.html - здесь для 10-ти языков, наиболее часто употребляемых на практике
C
C++
Java
Perl
Python
Ruby
JavaScript
PHP
Lua
bash

http://mylinuxprog.blogspot.com/2014/03/blog-post.html - здесь ещё 5 более редких языков:
Go
Scheme
Scala
Ocaml
Haskell

А здесь, уже для полноты картины, сравнение скорости выполнения одного и того же вычислительного фрагмента на всех этих языках - http://mylinuxprog.blogspot.com/2014/02/blog-post.html

[smallNix]

Эээ... Я извиняюсь, но, по-моему, странное сравнение. Результаты и так представимы. Интерпртируемые проиграют в скорости компилируемым. Java порадит длинющие операторы типа System.out.ptintln... С++ может (хотя и не факт) проиграть С в скорости выполнения, но выиграет в скорости проектирования большой задачи. Если бы какой-то язык был лучше - он бы другие языки вытеснил. В чём смысл сравнения? Программы C/C++ будут собираться с флагами оптимизации по скорости или нет? То, что С опередит bash очевидно, но это не говорит, что я буду системные скрипты на C писать
Автору моё признание за труд, но боюсь, что кроме простого эстетического удовольствия статья не принесёт пользы. Хотя, может я и ошибаюсь - хотелось бы увидеть другие точки зрения.
P.S.: а на указанном сайте есть множество других прекрасных статей - автору спасибо 
Сообщение объединено: 23 марта 2014, 10:12:10
Вот лично мне было бы интересно сравнение похожих языком, например C++ и D. Но, кажется, что D  не сможет стать таким же популярным.

[ogost]

python идеально подходит для "quick&dirty" проектов, для проверки работоспособности идеи, набросков кода в некотором роде. конечно ничто не мешает использовать его и в полноценных крупномасштабных проектах, только стоит основательно подойти к оптимизации кода, поскольку язык-то интерпретируемый.

[Olej]

python идеально подходит для "quick&dirty" проектов, для проверки работоспособности идеи, набросков кода в некотором роде.

А как же крупнейший проект OpenStack который сейчас так активно развивается получивши импульс поддержки от RedHat ?

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

Интерпретируемый, не интерпретируемый, компилируемый ... - сейчас это уже сильно смазалось.
Java - интерпретируемый?
А Forth?
А Lisp на SECD машине ... виртуальной? ... а если реальной (и такая была как-то, у HP, кажется)?

А в Python, кстати, модули в отдельных файлах - компилируются (в промежуточную форму), и сохраняются в отдельных файлах... Могут компилироваться с оптимизацией (тогда и расширения файлов поменяются).

Сообщение объединено: 24 марта 2014, 21:14:30

Если бы какой-то язык был лучше - он бы другие языки вытеснил. В чём смысл сравнения?

Конечно каждый язык хорошо для чего-то своего, для своей области.
Смысл сравнения?
Смысл в том, чтобы сравнить как одни и те же конструкции, потребности, возможности - выражаются разными конструкциями в разных языках (ввод-вывод, обработка исключений и т.д.)
Смысл для начинающих, студентов - в том, чтобы увидеть как хоть выглядит какой язык ... Я не со скуки эти заметки написал, а именно как ответ на вопросы таких дотошных студентов ... по крайней мере 4-5 первых языка, ... а остальные 10 - это уже по инерции ... из "эстетического удовольствия".

Интерпртируемые проиграют в скорости компилируемым.

Вопрос не в том, что "проигрывают", а сколько?
Интерпретация интерпретации рознь, и различия в производительности интерпретирующих реализаций (разных) может быть 3-4 порядка ... куда больше, чем разница классики компиляции C и ближайших к нему быстрых в интерпретации языков.
Интересно и то, что из 15 языков имеющих реальное распространение - только 2 (C/C++ и Go) остались чисто компилирующими - компиляция уходит в прошлое

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

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

Но C++ - страшно громоздкий язык после всех расширений и добавлений ... "и огород, на случай если крот придёт"(с) Крылов.
В этом смысле куда изящнее и просто удовольствие доставляет Go - от разработчиков C & UNIX... и сделанный ими для ОС Plan 9.

Вот лично мне было бы интересно сравнение похожих языком, например C++ и D. Но, кажется, что D  не сможет стать таким же популярным.

Меня D совершенно не заинтересовал... А вот C++ / Go - это и есть вам такое сравнение.
Так же, как меня совершенно не интересует C# ... но по другим причинам - идеологически ничем не отличающийся в лучшую сторону от Java.

[smallNix]

Я скорее практик, нежели теоретик. У меня нет возможности сильно сравнивать языки. Я могу сравнить только то, с чем сталкивался лично. Моё предпочтение - С++. По поводу системного программирования - регулярно этим занимаюсь, как и прикладным, впрочем. Не могу сказать, что С - лучший выбор. С позволяет написать что-то побыстрее, но как только проект чуточку разрастается С++ даёт несравненное удовольствие в поддержке, осмысленной работе и проектировании системы (лично мне). На С я пишу, когда у меня с кем-нибудь совместный проект.
Интерпретируемые языки - это что-то странное, по-моему они придуманы для ленивых (не надо на меня набрасываться). Единственное зачем я их использую - это системные скрипты.
С++, вероятно может проиграть С в производительности, на это указывал сам Страуструп, но ненамного. Кроме того это напрямую зависит от конкретной задачи и способа её реализации.
Студенты народ ленивый, они хотят писать на том, что проще может потому и просят. Они ещё не понимают, что не существует универсального языка... Хотя, возможно, что я не прав и просто кричу со своей колокольни %) Но 15 языков.... Это перебор Если я посмотрю на исходный код Pascal и С в приложении Hello, World. О чём мне это скажет.... Не могу сделать выводов. Немножко разный синтаксис. Не более того. Производительность может зависеть даже не от языка, а от компилятора/интерпретатора. Поэтому сравнение оченнннь субъективно

[Olej]

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

Ну а всё таки? :
- весь Linux, ядро - прописан на C;
- к драйверам, модулям ядра Linux - с C++ и не суйся;
- большинство из сотен утилит GNU (весь /usr/bin + /usr/sbin) прописаны на C (по крайней мере первоначально, сейчас многое переписано на Python);
- на C++ из числа утилит UNIX/Linux не представлено практически ничего.

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

Но интерено же?
Из 15 "живых" языков программирования, которые разные люди выбирают для разных сфер применения ... если оставить в стороне "мёртвые" языки (PASCAL, FORTRAN, ... санскрит ) - только-только с большим трудом набралось только 2 языка чисто компилирующих ... а реально даже 1 (Go - это пока экзотика, а C/C++ различать не будем, у них и компилятор один).
1 из 15-ти ... - это о чём-то говорит?! ... меньше 7%

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

Ну ... Страуструп вообще много о чём говорит ... а позже сам от своих слов отказывается.
C++ может уступать в производительности только там, где использует высокоуровневые конструкции, не имеющие аналогов в C ... например потоковые операции << , >> для сложных структур данных...
В остальном нет на то оснований...
Интересно ... разговаривая со многими практиками, оказывается что это не очевидно:
- C++ использует стандартную C библиотеку libc.so ... он без неё не может работать
- в дополнение к своей собственной библиотеке C++ (в компиляторах GCC и Clang - они разные)
- и все "традиционные" операции C++ выполняет именно через запросы к библиотеке C

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

Студенты - народ разный
Я говорил о студентах обобщённо, "студент" - это тот, кто изучает... часто это самоучки. Я встречал не одного школьника, которые к 8-9-му классу в программировании уже даст фору штатному выпускнику ВУЗа. Собственно, разговоры с таким вот самоучкой и подтолкнули меня написать это сравнение.
А дегенераты, отсиживающие 5 лет для получения диплома? ... Дегенераты меня не интересуют.

Но 15 языков.... Это перебор Если я посмотрю на исходный код Pascal и С в приложении Hello, World. О чём мне это скажет.... Не могу сделать выводов. Немножко разный синтаксис. Не более того. Производительность может зависеть даже не от языка, а от компилятора/интерпретатора. Поэтому сравнение оченнннь субъективно

Во-первых, "Hello, World" действительно ничего не скажет! Слишком тривиально.
Потому и задача была выбрана со скрытым смыслом: там а). и комплексная математива (внешние пакеты, модули, библиотеки) и б). ввод-выво и в). обработка исключений и г). классы и объекты, где они есть...
Поэтому для сравнение этого достаточно.

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

15 языков? ... Это именно те 15 языков, которые применяют на практике в разных обстоятельствах. Всё что сверх того - это уже будет никому не интересная экзотика ... маргиналы
Интересно сравнить именно философию существующих языков, даже не синтаксис ... хотя синтаксис отчасти разъясняет философию.
15 языков вовсе не обязательны, чтобы на них писать (хотя программист ... так себя называющий ... знающий 1 язык? ... шеренги нынешних PHP-программистов - это сильно убого ).
"Чужие" языки хороши тем (взгляд на них), что они позволяют перенести их приёмы в свой родной язык.

P.S. Когда-то ... но это очень давно ... мне было поручено написание специализированной САПР системы, на PL/1 ... в совершенно нереальные, дикие сроки.
И я тогда "зачитался" языком APL ... который никогда не был реализован ни в одном виде в русскоязычном пространстве - он требунт совершенно специальной клавиатуры.
Но из APL я позаимствовал в PL/1 массивные операции, массивы как элементарный базовый тип проекта + функции высших порядков над ними (редукция и т.п.) - оказалось что в PL/1 это всё выразимо ... только ним никто не пользуется.
САПР сделали и сдали в совершенно нереальные сроки.
Ним потом, как public-проектом, пользовались не в одном городе России, много лет потом шли отзывы из совершенно неожиданных мест...


Сообщение объединено: 28 марта 2014, 12:12:46

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

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

[Datarza]

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

[Olej]

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

Интересно...
Бурно развивающийся язык Go, сугубо нативно компилируемый, ... который можно назвать "современным развитием C", в последних своих ... технологичеких изысках - опроверг это утверждение: его активно стали применять для написания именно скриптов, за счёт очень быстрой компиляции (чем C и уж особенно C++) и ... своего рода JIT, когда скрипт компилируется только 1, первый раз, а затем только повторно используется результат.

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

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