Я всегда нахожу эти дебаты интересными для чтения. Не столько для интеллектуальной дискуссии о плюсах и минусах различных доступных языков, сколько потому, что вы обычно можете придерживаться чьей-то позиции по теме, основываясь на их работе / опыте / сфере интересов. Это прямо там с аргументами «преждевременной оптимизации», когда майоры и программисты CS цитировали Кнута влево и вправо и тех, кто работает в реальном мире, где вопросы производительности думают, что они все сумасшедшие (я член последней группы по честному).
В конце концов, вы можете разработать отличное программное обеспечение на C или C ++ или вставить язык здесь . Все сводится к возможностям разработчика, а не к языку. Быть экспертом по языку обычно требуется только в том случае, если вы выбрали неправильный язык для начала, и теперь вам нужно обратить его в решение вашей проблемы, в большинстве случаев это единственные ситуации, когда вам нужно погрузиться в неясные функции или компилятор трюки для достижения цели.
Я часто слышу, как люди начинают эти аргументы как «Я эксперт по языку X и бла-бла». Я честно немедленно дискредитирую этих людей, потому что, по моему мнению, они уже подошли к проблеме с неправильной точки зрения, и все, что после этого испорчено по их желанию использовать свой инструмент для решения проблемы и показать, как это круто.
Я так часто наблюдаю, как разработчики сначала выбирают набор инструментов, а потом пытаются согнуть его до своей проблемы, что совершенно неверно и приводит к дерьмовым решениям.
Как я упоминал в комментарии к другому ответу, эти языковые войны часто сводятся к утверждению, что язык X позволяет программисту делать более глупые вещи. Несмотря на то, что читать интересно, все эти утверждения действительно означают, что у вас есть проблема с наймом хороших разработчиков, и вам нужно обратиться к этой проблеме напрямую, а не пытаться объединить усилия для помощи ситуации, продолжая нанимать плохих разработчиков и выбирая инструменты так, чтобы они могли делать как можно меньше повреждение как можно
На мой взгляд, хорошие разработчики, будь то разработка программного или аппаратного обеспечения, исследуют проблему, создают решение и находят инструменты, которые позволяют им наилучшим образом выразить решение. Это не должно иметь значения, если необходимый инструмент - это то, что вы никогда не использовали раньше, после того, как вы использовали 3-4 языка / инструменты разработки для проектов, новые должны иметь минимальное влияние на ваше время разработки.
Конечно, «лучший способ» - это субъективный термин, который также должен быть определен на этапе исследования. Нужно учитывать множество вопросов: производительность, простота выражения, плотность кода и т. Д. В зависимости от рассматриваемой проблемы. Я не включил ремонтопригодность в этот список по какой-то причине, мне все равно, какой язык вы выберете, если вы выбрали подходящий инструмент и нашли время, чтобы понять проблему, которая должна появиться «бесплатно». Трудно поддерживать код часто является результатом выбора неправильного инструмента или плохой структуры системы, что приводит к ужасному хаосу, который заставляет его работать.
Утверждать, что любой язык «лучше», чем любой другой, глупо без определения конкретной проблемы, представляющей интерес. Объектно-ориентированный подход не всегда лучше, чем функциональный подход. Есть некоторые проблемы, которые очень хорошо подходят для объектно-ориентированной парадигмы проектирования. Есть много, которые этого не делают. То же самое можно сказать и о многих языковых особенностях, которые люди, похоже, любят использовать.
Если вы тратите более 20% своего времени на проблему, связанную с набором кода, возможно, вы создаете очень плохую систему или у вас очень плохие разработчики (или вы все еще учитесь). Вы должны тратить большую часть своего времени на то, чтобы составить схему проблемы и определить, как взаимодействуют различные части приложения. Заставить группу талантливых разработчиков в комнате с доской для маркеров и решить проблему и сказать им, что им не разрешается писать какой-либо код или выбирать какие-либо инструменты, пока они не будут чувствовать себя комфортно со всей системой, сделает больше для улучшения качества производительность и скорость разработки, чем выбор любого горячего нового инструмента, гарантированно сокращают время разработки. (посмотрите на развитие схватки как на точку отсчета, противоположную моему аргументу)
Часто прискорбная реальность такова, что многие компании могут измерить ценность разработчика только по количеству написанных строк или по «ощутимому результату». Они рассматривают 3 недели в комнате с маркером как потерю производительности. Разработчики часто вынуждены проходить через «продуманную» стадию разработки или вынуждены использовать набор инструментов из-за какой-то политической проблемы внутри компании: «Брат моего босса работает на IBM, поэтому мы можем использовать только их инструменты», такого рода мусор , Или, что еще хуже, вы получаете от компании постоянно изменяющийся набор требований, потому что они не способны проводить надлежащее исследование рынка или не понимают влияния изменений на цикл разработки.
Извините за то, что немного не в теме с этой напыщенной работой, у меня есть довольно сильные мнения по этой теме