Выбор языка программирования систематически [закрыто]

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

Наш генеральный директор хотел бы получить полную техническую информацию обо всех доступных веб-языках. На каком родительском языке они производные (например, jsp от java, от c / c ++). Мне нужно создать матрицу со всеми ключевыми факторами конкретного языка, а также с недостатками этого языка. Ограничен ли язык платформой, предназначен ли он для функционального программирования, процедурного или ОО или может использоваться с какой-либо парадигмой программирования?

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

Мы начали искать консультанта, который помог бы нам понять все эти вещи, но мы обнаружили, что большинство консультантов имеют опыт разработки, и часто кажется, что ответ « ххх - лучший язык, потому что это тот, который я использовал больше всего за последние n лет, и это никогда не подводило меня. Вы можете дополнить его с помощью yyy для внешнего интерфейса и использовать zzz библиотеку "

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

Кто-нибудь еще должен был пройти это упражнение? Если у вас есть, вы можете поделиться шагами и / или методологией, которые вы использовали для прохождения процесса?

@FrustratedWithFormsDesigner намекнул на это выше, я буду более тупым: вас обвинили в дорогой, но бесполезной задаче.

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

Другими словами, если бы существовал идеальный язык, каждый использовал бы его вместо этих «объективно» дефектных языков. Это также говорит о степени микроуправления, которая должна входить в компетенцию инженеров, которые должны будут заставить его работать. Erlang может быть «объективно лучшим», но если никто не знает об этом, добавьте 6-месячную / инженерную стартовую стоимость и еще 6-месячную / инженерную, чтобы получить компетенцию.

Так как у меня нет твоей работы, я не беспокоюсь о ее потере, хотя ты можешь. Я бы дал генеральному директору статью о физическом тезисе Церковного Тьюринга. Затем я соберусь со старшими инженерами и получу их не строгое, не объективное мнение о том, что следует использовать, и скажу генеральному директору, что вы должны использовать. Взамен вы пообещаете, что инженеры будут избегать заседаний совета директоров, финансовых директоров, методов бухгалтерского учета, выбора вице-президентов и так далее. Есть причина, по которой мы специализируемся, и он не занимает больше места в инженерных предпочтениях, чем вы в его области.

Некоторые широкие мазки кисти, чтобы рассмотреть:

Популярность языка

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

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

Применимость к проблемной области

Любая программа может быть написана на любом языке программирования, полном Тьюринга, но некоторые языки лучше подходят для определенных проблемных областей, чем другие. Если вы пишете веб-приложения, вы, вероятно, будете стремиться к языкам и инструментам, которые хорошо подходят для этого, и они, скорее всего, будут объектно-ориентированными языками.

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

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

Выразительность и производительность

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

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

Эра нескольких языков

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

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

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

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

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

Вот приблизительный список внутренних категорий:

• Microsoft. (Может иметь подкатегории. Я ничего не знаю о них.)
• Тяжелый ООП, как у Drupal.
• Легкий ООП, как бутылка с питоном.
• Играть / поднимать / скалатра, используя Scala.
• Играть / поднимать, используя Java.
• Весна-как.
• Распорки типа.
• Рельсы типа.
• Haskell основе.
• Node.js

На переднем конце:

• ООП в стиле JavaScript
• JavaScript в функциональном стиле, как с Underscore
• Реактивный стиль JavaScript, как с беконом
• Google Web Toolkit
• вяз

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

Поскольку это бизнес-отчет, я бы также потратил некоторое время на поиски в Интернете таких вещей, как «Какой язык использует <company>», заменив различные компании, которыми вы восхищаетесь. Многие из них написали свои собственные официальные документы о том, почему они сделали определенный выбор языка, что послужило бы отличными ссылками для вас.

Определите и оцените недостатки, присущие вашему существующему процессу разработки, как $ A. Определите стоимость перехода на любой другой процесс разработки как $ B.

Если $ A меньше, чем $ B, остановитесь.

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

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

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