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

24

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

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

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

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

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

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

копье
источник
21
Планирует ли генеральный директор использовать эту матрицу для решения таких вопросов, как «Мы ​​будем использовать $ {language} для построения $ {nextBigProject}!» Создание чего-то, что могло бы быть действительно полезным для этого (хотя я не уверен, что это когда-либо будет серьезно полезно), вероятно, заняло бы значительное количество времени, и на нем также будет продолжаться техническое обслуживание.
FrustratedWithFormsDesigner
3
Я думаю, что общее руководство по выбору языка / среды для проекта может состоять в том, чтобы сначала попытаться глубже понять конкретную проблему, которую пытается решить проект (не зависящим от языка), найти инструменты / библиотеки, которые Лучше всего помочь решить это в то время , а затем посмотреть, какие языки вам нужно знать, чтобы работать с этими инструментами / библиотеками. Это, вероятно, даст вам краткий список языков, и оттуда вы сможете откорректировать его на основе вашего знакомства с ними, поддержки поставщиков, бюджета и т. Д.
FrustratedWithFormsDesigner
9
Самый первый вопрос, на который нужно ответить: «Нужно ли вообще что-то менять?» Какие проблемы не решаются вашим текущим выбором языка?
Джон Боде
4
Как Stack Overflow может помочь разработчикам оценить технологии? «Сегодня утром у меня было около 8 фреймворков, пытаясь решить, какой из них я буду использовать ...»
комнат
7
На практике вы также можете бросать дротики. На веб-арене (особенно JavaScript и др.) Есть десятки (если не сотни) вариантов с различными преимуществами, недостатками, сходствами и несовместимостью. Вы можете проанализировать его до смерти или просто сделать обоснованное предположение, пойти дальше и, если необходимо, сделать среднюю коррекцию.
Даниэль Р Хикс

Ответы:

53

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

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

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

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

MSW
источник
6
Ха, я люблю безрассудный энтузиазм последнего абзаца. Я бы сказал, что это домен руководителей из-за этих надоедливых 6 месяцев, которые вы упомянули, и это все, что вам нужно, чтобы сказать ему / ей imho.
Натан Купер
1
"Физический тезис Церковно-тьюринговский" Давай не будем туда идти. Очень немногие языки программирования имеют формальную семантику, в значительной степени необходимое условие для завершения Тьюринга. (Без него это даже не модель вычислений.)
Rhymoid
4
Просто выберите Лисп и покончите с этим.
Эрик
1
Под Лиспом вы, конечно, имеете в виду ClojureScript. :-)
Брайан Кноблаух
1
+1. Ваша работа как инженера - донести до генерального директора, почему это не очень хороший подход. Это может быть сложно, потому что это выглядит как хороший подход, но это необходимо.
Джечлин
25

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

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

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

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

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

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

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

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

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

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

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

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

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

Роберт Харви
источник
7
Я хотел бы добавить к последнему пункту, что если вы хотите использовать несколько языков, было бы полезно рассмотреть платформу, которая поддерживает простое взаимодействие между ними (.Net CLR или JVM).
svick
9
@NathanCooper: Вы имеете в виду, что никогда не писали веб-приложение? Даже маленький? Или пришлось портировать мобильное приложение на несколько платформ? Или работал во встроенном? Или извлекли данные из базы данных SQL?
Роберт Харви
10
@ NPSF3000: Естественно, вы не удосужились раскрыть свой метод магии. Я называю махинации.
Роберт Харви
9
@ NPSF3000 Несмотря на то, что C # может быть хорошим выбором для того, что вы делаете (хотя использование Unity, безусловно, немного растягивает вещи, так как оно явно предназначено для них, чтобы выполнять все многоязычные тяжелые работы за вас), ваш один анекдот не опровергает сути. Конечно, большинство нетривиальных проектов являются мультиязычными в том смысле, что они используют SQL и другие технологии, но даже помимо этого, многие используют параллельные языки программирования или пишут свои приложения на одном языке, а инструменты на другом и т. Д. Я не находите утверждение спорным вообще.
Крис Хейс
7
@ NPSF3000 Если это твоя проблема, скажи это . Не заставляйте нас проходить через эту махинацию попыток выяснить, что вы имеете в виду. Я уверен, что Роберт был бы рад внести изменения, если бы вы прямо заявили: «Я не согласен с тем, что некоторые проблемные области требуют определенных языков». Тем не менее, я не вижу здесь никакого смысла в том, что работа на нескольких языках «полезна по умолчанию».
Крис Хейс
5

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

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

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

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

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

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

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

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

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

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

Карл Билефельдт
источник
4

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

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

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

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

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

Пол Смит
источник