Программирование на Python быстрее, чем на C, C ++ или Java? [закрыто]

27

Там в широко распространенное убеждение среди , что более динамичный и слабо типизированных язык, тем более продуктивна программист будет в нем. Гвидо ван Россум (Guido van Rossum) написал о производительности программирования с использованием python в 1998 году и поиске в Интернете. Я все еще вижу людей, ссылающихся на это точное утверждение:

Синтаксически код Python выглядит как исполняемый псевдокод. Разработка программ на Python в 5-10 раз быстрее, чем на C / C ++, и в 3-5 раз быстрее, чем на Java. Во многих случаях прототип приложения может быть написан на Python без написания кода на C / C ++ / Java. Зачастую прототип достаточно функционален и достаточно хорош, чтобы поставляться в качестве конечного продукта, что экономит значительное время на разработку. В других случаях прототип может быть частично или полностью переведен на C ++ или Java - объектно-ориентированная природа Python делает перевод простым процессом.

Была ли эта проблема должным образом оценена с научной точки зрения? Если не для то, возможно, для родных языков сценариев, таких как , или ?

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

Сначала я задавал этот вопрос в скептиках. SE , и кто-то предложил мне задать его и здесь.

Кит Сунде
источник
25
Ну, так как вы ограничили набор возможных ответов, я просто осмелюсь прокомментировать, задав еще один вопрос, на который нужно сначала ответить (imho): есть ли надежные и устоявшиеся показатели для измерения «производительности программиста»?
Павел Михалик
1
@Paul Michalik - я бы предположил, что в любой исследовательский документ, который рассматривал производительность, было бы включено определение (иначе это было бы действительно трудно измерить). Так что, если кто-то ссылается на исследование, было бы полезно, если бы они включили определение в ответ. Вероятно, есть (я предполагаю) несколько различных вполне приемлемых способов измерения производительности, возможно, одним из них будет «Время, необходимое для прохождения ряда юнит-тестов».
Кит Сунд
1
@Paul Michalik - Конечно, но сколько утверждений, которые вы прочитали в книгах, блогах, беседах и статьях программистов, действительно проверено эмпирически? Я уверен, что есть лучшие или худшие способы измерения производительности. Например. «Потребление кофе / время», вероятно, будет хуже, чем даже классические «Линии кода / времени». Я бы воздержался от суждений по поводу конкретных заявлений о производительности, которые мы видели, и могу обосновать их достоинства. Заявления о производительности тоже не просто неверны, я уверен, что «строки кода / времени» измеряют что-то, когда люди не пытаются разрушить метрику.
Кит Сунде
1
Вы можете быть заинтересованы в этой статье: citeseerx.ist.psu.edu/viewdoc/…
DistantEcho
1
@ChrisF - Вы говорите, что этот вопрос не относится к Programmers.SE? Это, конечно, для скептиков, и это, кажется, подходит и здесь. Я был под впечатлением , что вы не должны , пока я прочитал недавний комментарий Роберта Cartaino по этому вопросу: skeptics.stackexchange.com/q/1963/631 , который по существу говорит , что это совершенно нормально , если это представляет интерес для обеих общин, и Я сделал это только после того, как другой пользователь попросил меня сделать это. Учитывая, что вопрос вызывает недовольство, может показаться, что это также интересует это сообщество.
Кит Сунде

Ответы:

17

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

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

[1]: Дж. К. Оустерхаут, Сценарии: программирование на более высоком уровне для 21 века , Компьютер (IEEE), 1998
[2]: Б. Бём, Экономика разработки программного обеспечения , Prentice Hall, 1981

Jawa
источник
9
Хотя это хороший ответ, не забывайте, что современные языки, не относящиеся к написанию сценариев, также имеют множество готовых утилит, которые ускоряют разработку. C # приходит на ум. Любой, кто чувствует, что Python имеет больше готовых утилит, чем C #, просто знает Python лучше, чем C #. В действительности у них обоих есть обширный и сопоставимый диапазон «встроенных» утилит.
Роман Старков
@romkyns, для любого нетривиального проекта вам нужно написать много кода. Даже если у вас много кирпичей Lego, Bionicles волшебным образом не собираются вместе.
2
@Thor, но это действительно помогает получить эти кирпичи Lego заранее, вместо того, чтобы сначала строить нефтяную дрель, завод по производству пластмасс и экструдер с блоком Lego.
Роман Старков
2
и в c ++, и в Java есть универсальные контейнеры, а в c ++ 11 есть такая полная стандартная библиотека для алгоритмов сортировки, итераторов и т. д. Я не уверен, что кто-то, программирующий python, получит существенное преимущество. Кроме того, я трачу большую часть своего времени на программирование, решая, что мне нужно делать, а не печатая. Поэтому я считаю, что просто подсчет количества строк, необходимых для выполнения какого-либо действия, не является четким показателем того, насколько быстро вы станете программистом на этом языке.
Сэм Редуэй
7

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

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

Если вы измеряете производительность как «эффективность лучшей программы», написанной на данном языке, то она еще менее зависит от языка. Смотрите, например, результаты конкурса Galcon AI . Победитель написан на Лиспе. Следующая запись Лисп, однако, занимает # 280. Что это говорит нам о пригодности языка для эффективного написания великолепного ИИ? На мой взгляд, ничего. Это просто говорит нам, что «bocsimacko» придумал и реализовал самые эффективные алгоритмы. Для справки, время не было основным фактором в этом конкурсе - у людей было больше двух месяцев, чтобы разработать свой код.

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

Роман Старков
источник
7
«Вы действительно оцениваете программиста, а не язык» - нет, если это на самом деле сделано с научной точки зрения. Возьми 100 программистов. Выберите общий проект, например «Написать приложение календаря с этими конкретными требованиями». Требования привязаны к автоматизированному модульному тестированию. 50 программистов пишут приложение на C ++, 50 - на Python, отобранных случайным образом, поэтому качество разработчиков равномерно распределено. Результатом будет оценка, объединяющая среднее время до завершения с количеством пройденных модульных тестов. Сравните среднее значение результатов Python со средним результатом C ++ и ... НАУКА!
Морган Херлокер
2
@Prof Может быть, если вы получите тысячу каждого ... но все же, как вы контролируете тот факт, что только люди с определенным мышлением и определенным уровнем способностей будут знать C ++?
Роман Старков
Вы можете сделать свой образец только из людей, которые могут пройти квалификационный тест в C ++ и Python. Многие мои старые профессора проводили очень похожие исследования. Также вы делаете пару предположений, которые другие обсуждали здесь: programmers.stackexchange.com/q/73715/3792
Морган Херлокер
6

http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprtTR.pdf - одно из немногих исследований, о которых мне известно, что было проведено прямое сравнение производительности на разных языках. Он старый, но стоит прочитать, если вы находите тему интересной. Сравнение имеет ряд существенных недостатков, о которых статья очень честна.

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

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

btilly
источник
1

В общем, написание программы на Python обычно будет быстрее, чем написание той же программы на C, C ++, Java.

Это также может работать медленнее.

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

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

Я думаю, что есть некоторая заслуга в корреляции между выразительностью языка и скоростью программирования. Просто представьте простой итерационный шаблон и узнайте, как Pythonic for-loop или понимание списка могут быть более краткими. Мало того, что он может быть немедленно набран быстрее, но он также устраняет проблемы, связанные с ошибками, возникающими из-за единичных ошибок, за пределами индексов и другими такими проблемами, которые могут значительно замедлить процесс кодирования.

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

http://en.wikipedia.org/wiki/Comparison_of_programming_languages#Expressiveness

jon_darkstar
источник
-5

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

Очевидно, что у всех языков есть свои сильные и слабые стороны, но для большинства задач Python будет быстрее писать.

wobbily_col
источник
6
«он взял экран полный код для открытия и записи в файл»: Put это в служебный класс с двумя методами write()и read()и в остальной части доступа к файлам проекта Java будет столь же кратким , как и в Python. Я думаю, что ваш пример слишком ограничен для сравнения Python и Java (хотя я согласен, что Java имеет тенденцию быть более многословным).
Джорджио
Конечно, но языки Python, Perl и более поздние обычно думали об этом заранее, поэтому вам не нужно писать вспомогательные классы (или не так много). Использование служебного класса все еще занимает много времени и является принципом многократно используемого кода, который применяется как на Java, так и на Python, в зависимости от того, что вы на самом деле делаете.
wobbily_col
Это предполагает, что для открытия и записи файла Java требуется от 50 до 60 строк кода. Это просто не правильно.
h22