Кто-нибудь знает какие-либо исследования или оценки того, сколько времени требуется для разработки одного и того же приложения на разных языках? На самом деле я ищу Java против С++, но любые сравнения были бы полезны. У меня такое чувство, что в этом коде есть раздел, посвященный этому коду, но моя копия работает.
Edit:
Есть много интересных ответов на этот вопрос, но кажется, что нет действительно хороших исследований. Я сделал предложение в метатемах об этой проблеме.
Pratt и Whitney, поставщики реактивных двигателей для гражданских и военных применений, провели исследование этого много лет назад, фактически не намереваясь провести исследование.
Они пошли на те же показатели, что и все остальные в 1990-х годах. Они собрали кучу данных о своих проектах по управлению реактивными двигателями, включая данные таймера. Они хрустнули. Бедный сок, который получил хруст данных, заметил что-то в результатах: военные проекты единообразно удвоили производительность программистов и 1/4 плотность дефектов в качестве гражданских проектов.
Это само по себе является значительным. Это означает, что вам нужно всего лишь половина программистов, и вы не собираетесь тратить столько времени на исправление ошибок. Что еще более важно, так это сравнение яблок с яблоками. Контроллер реактивного двигателя является контроллером реактивного двигателя.
Затем он пошел искать объяснения кандидата. Все обычные кандидаты: индивидуальный опыт, размер команды, инструменты, программные процессы, стабильность требований, все, были выбиты, и они были исключены, когда было видно, что история этих предметов одинаково одинакова по обе стороны от придел. В конце дня обнаружилась только одна статистически значимая разница.
Гражданские проекты были написаны на всех языках, о которых вы могли подумать. Военные проекты были написаны в Аде.
В КАЖДОМ ОДНОМ ДЕЛО, против всех остальных, для контроллеров реактивных двигателей в Пратте и Уитни, использование Ada давало удвоенную производительность и 1/4 плотность дефектов.
Я знаю, что обезьяны летающего кода будут говорить. "Вы можете делать хорошую работу на любом языке". Теоретически это правда. На практике, однако, кажется, что, по крайней мере, у Пратта и Уитни, язык имел значение.
Последнее, что я услышал об этом, Праттс и Уитни верховное руководство постановили, что проекты по проектированию реактивных двигателей будут выполняться в Аде.
Нет, у меня нет цитаты. Ни одна бумага не была написана. Моим источником этой истории был бедный сок, который хрустнул цифры.
Это, кстати, было до того, как Боинг сделал 777, и до того, как произошла история субподрядчика тормоза 777. Но эта другая история.
Одно из немногих финансируемых научных исследований, которые я знаю о производительности на разных языках, с начала 90-х годов, финансируемых ARPA и ONR,
Опишем результаты эксперимент, в котором несколько традиционные языки программирования, вместе с функциональным языком Haskell, были использованы для прототипа Морской центр наземных боевых действий (NSWC) требование для геометрического региона Сервер. Полученные программы и метрики развития были рассмотрены комитет, выбранный военно-морским флотом. результаты показывают, что Haskell прототип занимал значительно меньше времени развивать и значительно больше кратким и понятным, чем и..
В этой статье (pdf) есть несколько тестов (обратите внимание, что это с 2000 года) между C, С++, Perl, Java, Perl, Python, Rexx и Tcl.
Некоторая общая мудрость, которую я считаю верной (также где-то внутри статьи):
The number of lines written per hour is independent of the language
Мнение: более важным является то, что быстрее для конкретного разработчика, например, самостоятельно. То, к чему вы привыкли, обычно будет быстрее. Если вы привыкли к 20 годам ошибок С++ и никогда не пропускаете неинициализированную переменную, это будет быстрее, чем Java для кого-либо.
Если вы помните все параметры CreateWindowEx() наизусть, это будет быстрее, чем MFC или winforms.
Несколько анекдотических данных:
В Project Euler, который предлагает программные решения для математических задач,
Вопрос задан о "самой быстрой разработке", а не о "кратчайшем" коде. Но возможно, что более короткие решения быстрее придумать - конечно, для медленных машинисток!
Ежегодно проводится соревнование среди роботистов. Участникам даются некоторые спецификации для некоторых аппаратных средств, практическая проблема для решения в программном обеспечении и ограниченное время для этого. Конечно же, очень специфический домен. У программистов есть свой выбор инструментов, включая язык, конечно. Каждый год победившая команда (часто один человек) использовала Forth.
Этот, по общему признанию, ограниченный пример показывает, что "скорость развития" и "влияние языка на скорость" часто очень зависят от проблемной области.
См. также
для некоторых обсуждений этого вопроса.
Было бы разумнее ориентироваться программисты, а не языки. Время написания программы на любом основном языке зависит в большей степени от способности программиста на этом языке, чем от качества этого конкретного языка.
Я думаю, что большинство тестов и заявлений по этой теме будет очень мало.
Тесты всегда могут быть пропущены; см. историю "Зоомагазина".
Язык, который хорошо подходит для решения одной проблемы, может не соответствовать другому.
Самое главное - это умение вашей команды, ее знание конкретной технологии и насколько хорошо вы знаете домен, который вы пытаетесь решить.
ОБНОВЛЕНИЕ: Программное обеспечение для управления реактивными двигателями и вертолетами является очень специализированным подмножеством вычислительных задач. Он характеризуется очень строгими, полными, подробными спецификациями и QA, что означает, что многомиллионный самолет не может потерпеть крах.
Я могу повторить (очень хорошую) цитату Джона Штрома из программного обеспечения для управления Pratt и Whitney, написанного в Аде. Контрольное программное обеспечение для вертолетов Kaman, проданных в Австралию, также было написано в Аде.
Но это не приводит к выводу, что если вы решили написать свой следующий веб-сайт в Ada, у вас будет более высокая производительность и меньше дефектов, чем если бы вы выбрали С# или Java или Python или Ruby. Все языки не одинаково хороши во всех проблемных областях.
Большинство программ должны взаимодействовать с некоторыми другими структурами. Как правило, стоит выбрать язык, на котором есть библиотеки, специально для того, что вы пытаетесь сделать. Например, вы пытаетесь создать распределенную резервную систему обмена сообщениями? Если так, я бы использовал Эрланг. Вы пытаетесь сделать быстрый и грязный веб-сайт, управляемый данными, используйте Ruby и Rails. Вы поняли эту идею. DirectX DirectX, где производительность является ключевой, С++/C/Asm.
Если вы пишете то, что основано на алгоритме, я бы посмотрел на функциональный язык, такой как Haskell, хотя он имеет очень высокую кривую обучения.
Этот вопрос немного старомодный. Ориентация на время разработки исключительно на основе выбора языка имеет ограниченную ценность. Есть так много других факторов, которые имеют равное или большее влияние, чем сам язык:
В качестве примера многие могли бы сказать, что Java - лучший выбор по сравнению с С++ для создания корпоративных (бизнес-приложений) приложений. Обычно это не из-за самого языка, но вместо этого предполагается, что Java имеет лучшие (или более зрелые) веб-серверы и базы данных, доступные для него. Это может быть или не быть правдой, но это не относится к делу.
Вы даже можете обнаружить, что создание приложения с использованием одного и того же языка на разных операционных системах или платформах дает значительно отличающееся время разработки. Например, использование С++ в Linux для создания приложения с графическим интерфейсом может занять больше времени, чем приложение с графическим интерфейсом на основе Windows, использующее С++ из-за менее обширных и зрелых библиотек графического интерфейса avaialble на Linux (это опять-таки дискуссионно).
Согласно Norvig, Lutz Prechelt опубликовал именно такую статью в CACM в октябре 1999 года: "Сравнение Java с C/С++ Вопросы эффективности межличностных вопросов".
Norvig включает ссылку на эту статью. К сожалению, ACM, несмотря на наличие растровой графики, провозглашающей их цель "Продвижение вычислений как науки и профессии", не мог понять, как поддерживать стабильные ссылки на своей веб-странице, так что теперь это всего лишь 404. Возможно, ваша местная библиотека может помочь вам.
Эта история Ады может быть украшенной версией этого: http://www.adaic.com/whyada/ada-vs-c/cada_art.html
Erlang vs С++/Corba
"... Поскольку DCC Erlang составляет менее четверти от размера аналогичной реализации С++/CORBA, разработка продукта в Erlang должна быть быстрой, а код поддерживаем. Мы пришли к выводу, что Erlang и соответствующие библиотеки подходят для быстрого развития поддерживаемых и высоконадежных распределенных продуктов".
Бумага здесь
Есть причина, почему в этом аспекте нет реальных сравнений, кроме анекдотических доказательств (которые можно найти в пользу почти любого языка).
Фактически, код записи занимает относительно небольшую часть времени разработчика. Даже если язык позволяет сократить время кодирования пополам, это будет едва заметным по завершению проекта времени. Дизайн, структура программы, процесс разработки гораздо важнее, а затем есть библиотеки, инструменты и опыт с ними.
Некоторые языки лучше подходят для определенных процессов разработки, чем другие, поэтому, если вы решились на разработку и процесс, вы можете решить, какой язык будет более эффективным, но не раньше.
(не заметил уже подобного ответа, поэтому не обращайте на него внимания)
Проект Plat_Forms предоставляет некоторую информацию этого типа для веб-приложений.
Существует три исследования с различными задачами (сделано в 2007, 2011, 2012), в следующем формате: несколько команд из трех профессиональных разработчиков выполнили одно и то же приложение в контролируемых условиях в течение двух дней. Он охватывает Java, Perl, PHP и Ruby и имеет несколько команд для каждого языка. Оценка сообщает гораздо больше, чем время разработки.
Посмотрите http://www.plat-forms.org или выполните поиск в Интернете для "Plat_Forms".