Исследования относительных затрат на развитие на разных языках

Ответ 1

Количественные сопоставления такого рода очень сложно было бы зафиксировать из-за количества усложняющих переменных: опыт разработчиков с языком, пригодность языка к целевому домену, общее качество разработчиков (утверждалось, что non -mainstream-языки привлекают разработчиков более высокого качества), компромиссы с полученным продуктом (это приложение Ruby или Python так же быстро, как хорошо написанное приложение Delphi или С++?) и т.д.

В Code Complete, 2nd Ed., Стив Макконнелл перечисляет несколько языков с точки зрения их выразительной способности (как многие строки эквивалентного кода C могут быть выражены в одном выражении каждого языка). Было высказано предположение, что производительность программистов в строках кода относительно постоянна независимо от языка; если это так, то выразительная сила каждого языка должна дать приблизительную оценку относительной стоимости развития на каждом языке. Из таблицы 4.1, стр. 62:

LANGUAGE       LEVEL RELATIVE TO C
C              1
C++            2.5
Fortran 95     2
Java           2.5
Perl           6
Python         6
Smalltalk      6
Visual Basic   4.5

Он перечисляет несколько источников для этой таблицы: Оценка стоимости программного обеспечения, Оценка стоимости программного обеспечения с помощью Cocomo II и "Эмпирическое сравнение семи языков программирования" (от Prechelt, от IEEE Computer, октябрь 2000).

Цифры, которые цитирует Макконнелл, всего несколько лет, но из того, что я понимаю, модель Cocomo II смехотворно подробно, поэтому текущий материал Cocomo II может предлагать текущие номера на Delphi и С#.

Ответ 2

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

В общем:

Все они являются лучшими в своих полях:

• Java - лучший вариант разработки Java.
• С# - лучший вариант разработки .NET.
• Delphi - лучший вариант для развития нации.

Все они имеют:

• Мировые сторонние поставщики, которые предоставляют качественные компоненты и библиотеки.
• Всемирно известные приложения, созданные с ними (например, Delphi могут быть более известны: Yahoo Go for TV!, Macromedia Captivate, TotalCommander, MediaMonkey, FinalBuilder, InstallAware, WinLicense, Администратор MySQL и т.д.).

Все они:

• Высоконадежные технологии с возможностями RAD.
• Поддерживаются лучшие инструменты для поддержки развития (UML и т.д.).
• Освобождение основных обновлений в своих технологиях (Java 7,.NET 4.0 и многоплатформенная платформа Delphi).

Отличия:

3 Вещи, в которых лучше С#:

• Количество доступных разработчиков (по сравнению с Java), которые могут кодировать в нем (*).
• У Microsoft позади.
• Более дешевые затраты на разработку с точки зрения заработной платы (обычно).

3 Вещи, в которых лучше Java:

• Количество доступных разработчиков (по сравнению с Delphi), которые могут кодировать в нем (*).
• Переносимость.
• Солнце отстает.

3 Вещи, в которых Delphi лучше:

• Скорость (более высокая производительность для критически важных систем).
• Малая занимаемая площадь (компилятор Delphi генерирует действительно маленькие двоичные файлы).
• Не имеет явных зависимостей (более простое распределение).

(*) есть очень надежный факт, что есть еще другие языки-разработчики, которые могут программировать на С#, чем разработчики других языков, которые могут кодировать на Java, что означает, что легче найти программистов на С#. Возможно, это объясняет, почему на многих веб-сайтах (например, этот) и на форумах, которые разрешают многоязычные вопросы, рефакторинг и т.д., Есть УЗЕЛЕЕ больше вопросов и ответов на С# (84k против 50k). Кроме того, поскольку рабочие места Java лучше всего оплачиваются во многих частях мира, здравый смысл указывает, что разработчики Java остаются дольше на своих рабочих местах, чем на С#, что затрудняет найти Java-разработчиков, доступных для С#. И, конечно, есть некоторые другие факторы, которые можно обсудить, но я уверен, что обычно проще найти программиста на С#, чем Java.

Ответ 3

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

потребовалось в два раза больше времени, чтобы переписать программу на С#, как это было сделано, чтобы первоначально записать ее в Delphi, даже со всей уже разработанной бизнес-логикой и знаниями о домене и представленной в виде существующей кодовой базы Delphi. За это время они не выпускали обновления, потому что все их ресурсы были заняты переписыванием, что позволило их конкуренции получить долю на рынке. И когда это было сделано, это был продукт на уровне 1.0. Glitchy, медленно и трудно использовать, часто с серьезными проблемами обратной совместимости.

Причина открытости для интерпретации, но я считаю, что одним из основных факторов, делающих Delphi гораздо более продуктивным, чем С# (или Java), является внешний вид и язык.

Общеизвестно, что гораздо больше работы, времени и усилий идет на поддержание и отладку современных программ, чем первоначально их обсуждение, но этот принцип не всегда доводится до логического завершения. Если то, что требует наибольшей работы, это поддержка программы, то выбор языка на основе его простого или быстрого написания кода - это преждевременная оптимизация. Вы получаете лучшую отдачу от своих инвестиций, если используете язык, который легко читать и поддерживать. И когда дело доходит до удобочитаемости кода, Паскаль (Delphi) превосходит C-образную передачу.

Это не формальное исследование, но стоит подумать.

Ответ 4

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

Чтобы сделать это правильно:

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

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

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

Итак, вам потребуется сила разработчика, эквивалентная project-size * nos-languages * nos-projects * nos-repetitions. Предполагая, что нетривиальный проект занимает 1 человеко-год, существует 5 проектов, и они разрабатываются 5 раз на каждом языке (чтобы дать нам достаточно большой размер выборки, чтобы быть статистически значимым), то есть 25 лет опыта-разработчика... скажем, от 2 до 5 миллионов долларов США... НА ЯЗЫКЕ ИССЛЕДОВАНО.

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

И даже тогда результаты исследования не будут касаться:

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

И результаты будут устаревшими через 3-5 лет.

Ответ 5

Peopleware (от Tom DeMarco и Timothy Lister) содержит раздел в восьмой главе "Кодирование военных игр". С 1984 по 1986 год участвовало более 600 разработчиков.

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

Ответ 6

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

После своей карьеры в качестве начальника отдела разработки ВВС мой бывший босс Билл Ретцхайм написал книгу об оценке затрат на разработку программного обеспечения. Его выбор, голова и плечи выше всех остальных - это Дельфы. Это была версия 3/4. Рациональный использовал свой оценочный шаблон. Я все еще использую его, и ничего лучшего не появлялось за все годы, которые я делал.

Ясность дизайна и сила выражения в коде не сильно меняются по сравнению с версиями. Большую часть времени вы смотрите на визуальные изменения и инкрементальное увеличение. Основные практические рекомендации 20 лет назад по-прежнему применяются. Именно это делает архитектуру возможной. Мы знаем, как выглядят лучшие методы, поскольку в определенном масштабе код должен соответствовать определенному набору стандартных требований, которые не сильно различаются. Вы почти всегда можете сделать его более приятным в использовании или иметь меньше глупых неудобных интерфейсов, но системы данных, безопасности/фильтрации и документооборота, которые заставляют бизнес-системы работать по-прежнему использовать одни и те же шаблоны дизайна из книги GoF Design Patterns. И если небольшие устройства научили нас чему-либо, то следует отметить высокую ясность и простоту. Это важно для всей группы, насколько легко использовать вашу базу кода для этой цели. Все основные среды могут очень хорошо работать с дизайном домена. Скорость системы и простота разработки делают Delphi и Node.js моими двумя задними предпочтениями. Но умные С# и Java оба хороши. Если бы я был обеспокоен безопасностью среды для разработчиков, я бы пошел на С# в некоторых ситуациях, потому что разработчикам было сложно нарушать правила. Но когда мне не нужны эти правила, то есть большую часть времени, я предпочитаю более открытую среду, которая масштабируется. Когда я не очень забочусь о безопасности, я мог бы предпочесть Node.js, потому что это делается в спешке. Большую часть времени я нахожу, что слишком легко ошибаться в Node, и в конце концов мне нужно полное покрытие тестового кода. Delphi - мой первый выбор на балансе.

Ответ 7

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

--- рассказать о "сравнительных исследованиях" о полной компетенции программиста ---

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

И стоимость разработки обычно составляет лишь небольшую часть совокупной стоимости владения системой, особенно если это что-то вроде многоуровневого приложения, работающего на серверах приложений с базами данных и т.д. Если у клиента уже есть серверный сервер, работающий с IIS с базами данных MS SQL Server в качестве бэкэнд, продажа им приложения Java EE с использованием бэкэнда Oracle делает их плохими, даже если это будет наиболее логичным выбором для приложения в противном случае. Стоимость разработки может быть ниже, но текущая стоимость для клиента будет намного выше.

На другом конце шкалы веб-сайт для вашего продуктового магазина, который хочет начать принимать заказы через сеть для доставки по соседству, не должен реализовываться ни в .NET, ни в Java EE. Стоимость решения (особенно хостинга) значительно перевешивает преимущества. Простая вещь, основанная на, например, php или rails, будет служить этому клиенту намного лучше. Стоимость хостинга снижается, не нужно платить дорогие лицензионные сборы за базы данных и серверы приложений, он мог бы заработать немного денег, используя полученный веб-сайт.

Ответ 8

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

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