Если конкуренция использует «lingua obscura» для развития (почему), я должен волноваться? [закрыто]

Я читал эссе Пола Грэма - «Обгоняя средние» (2003), и вот что он должен был сказать:

Чем больше в ИТ-специфике описаний работы, тем менее опасной была компания. Самыми безопасными были те, кому нужен опыт Oracle. Вам никогда не приходилось беспокоиться об этом. Вы также были в безопасности, если они сказали, что хотят разработчиков на C ++ или Java. Если бы они хотели программистов на Perl или Python, это было бы немного пугающе - это начинает звучать как компания, где техническая сторона, по крайней мере, управляется настоящими хакерами

Теперь это устаревшее эссе. Тем не менее, я не понимаю, как использование не обычного языка (C / C ++ / Java, C #) было бы «менее опасным» . Если программисты организации очень свободно владеют языком разработки, они должны одинаково хорошо разбираться в коде в приличном темпе. На самом деле, если вы используете язык, не являющийся обычным явлением, проблемы с обслуживанием / улучшением не столкнутся вам лицом к лицу, поскольку в долгосрочной перспективе будет доступно не так много программистов?

Для создания быстрых и грязных систем я согласен, что некоторые языки позволяют вылетать относительно раньше, чем другие. Но имеет ли смысл эссе / комментарий Пола Грэма в 2012 году и далее? Если стартап использует для разработки типичные языки ИТ , почему его конкуренция должна меньше беспокоить?

Я не вижу, как сам язык имеет значение. ИМХО, это опыт разработчиков с языком, который имеет значение, и доступность фреймворков, так что вы СУХОЙ (не повторяйтесь), а не просто кодируете на определенном языке.

Что мне не хватает? Означает ли это, что стартапы лучше выбирают языки, не относящиеся к ИТ (даже если разработчики могут быть чрезвычайно искусны в них)? Каковы (программирующие) экономические / рыночные силы, стоящие за этим требованием?

PS: «lingua obscura» не предназначен, чтобы обидеть чьи-то чувства :)

Цепочка для инструментов является симптомом.

Когда компания выбирает Oracle, это свидетельствует о:

• Много денег, чтобы бросить вокруг
• Крупная корпорация
• Глубоко вложенная организационная структура со многими уровнями управления
• Компания управляется «костюмами»: либо руководителями, либо маркетингом и продажами.
• Делает большие монолитные программные продукты с гигантскими кодовыми базами
• Формальные процессы для всего

Когда компания выбирает Python, это признак:

• Маленькая молодая компания
• Нет денег, чтобы сэкономить
• Плоская иерархия
• Компания управляется программистами
• Делает небольшие специализированные продукты с небольшими кодами
• В основном неформальные процессы

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

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

Я рассматриваю комментарии PG больше об отношении, чем о специфике языка. Люди с внутренним мышлением в сфере ИТ стараются не опасаться. Они используют технологии с низким уровнем риска, имеют процессы для минимизации риска и используют стратегию с низким уровнем риска. Они слишком заняты, беспокоясь о своем обеде, чтобы съесть свой.

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

Грэм значит менее опасный для него как конкурента, а не просто менее опасный. Он считает, что не Java (или C ++ в 2003 г., или COBOL в 1980 г.) менее опасны, а скорее то, что это нормально , и что существует высокая вероятность того, что компании, которые ищут такие навыки, являются просто средними конкурентами. Но компании, которые ищут сильных талантов в неясных (или, вернее, более мощных и менее известных) языках, - это компании, на которые стоит обратить внимание.

И да, это имеет смысл сегодня. Это имело смысл задолго до того, как Грэм написал это, мы просто не говорили о Java в те дни.

Давайте посмотрим, какие языки были впервые использованы успешными стартапами. Ненаучный список, вне моей головы. Правильное рандомизированное исследование было бы лучше, если бы у кого-то была энергия.

• Facebook: PHP
• Обмен стеками: C #
• Google: Java и Python
• Twitter: Ruby on Rails

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

Посмотрим, верит ли Пол Грэм в наши дни. Он был соучредителем YCominator, который финансирует стартапы. На домашней странице перечислены некоторые из их успешных стартапов. Я прошел их по порядку, очень быстро пытаясь исследовать языки, которые они использовали в первые дни.

• Reddit: Common Lisp
• wufoo: классический asp и php
• scribd: Flash
• Dropbox: Python
• Heroku: Рубин

Ну, есть некоторые признаки предпочтения относительно неясных и, возможно, мощных языков. Но Flash, PHP и классический ASP тоже перечислены.

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

Средний разработчик использует средние инструменты, потому что он не видит ценности более мощных инструментов:

«Пока наш гипотетический программист Blub смотрит на энергетический континуум, он знает, что смотрит вниз. Языки менее мощные, чем Blub, очевидно, менее мощные, потому что им не хватает некоторых функций, к которым он привык. Но когда наш гипотетический программист Blub смотрит в другом направлении, вверх по силовому континууму, он не понимает, что смотрит вверх. То, что он видит, это просто странные языки. Вероятно, он считает их примерно равными по силе Блюбу, но с учетом всего этого и другого волосатого материала. Blub достаточно хорош для него, потому что он думает в Blub ». - Пол Грэм, Beating the Average .

(Акцент мой.)

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

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

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

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

Спросите лучших и самых плохих программистов, которых вы знаете, по любым критериям, какие еще языки они знают. Теперь напишите объявление о работе, чтобы привлечь первого, и у вас есть свой ответ. Даже если ваше приложение написано на C ++, вы получите лучший класс программистов, если наймете тех, кто знает языки, которые не преподаются в школе.

Есть две разные вещи, которые вы должны беспокоиться, если конкурент использует необычный язык:

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

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

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

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

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

Java, C #, C ++ сравнительно многословны и имеют относительно медленные циклы редактирования / тестирования. Это ограничивает скорость, с которой даже самые быстрые разработчики могут предоставлять функции. Более выразительные языки с мощным встроенным метапрограммированием и нулевым временем компиляции позволяют опытным разработчикам создавать функции максимально быстро. Если вы находитесь в гонке за долю рынка и получаете огромное вознаграждение победителю, имеет смысл нанять самых лучших разработчиков, которых вы сможете найти, и использовать любой язык, который позволит им работать быстрее всего. Вы можете беспокоиться о масштабируемости позже.