Я завжди вважаю ці дискусії цікавими для читання. Не стільки для інтелектуальної дискусії щодо плюсів і мінусів різних доступних мов, а тому, що зазвичай можна прив’язати чиюсь позицію до цієї теми, виходячи з їх роботи / досвіду / сфери, що цікавить. Тут прямо з аргументами "передчасної оптимізації" були спеціалісти CS та програмісти з технічного обслуговування, які цитують Knuth зліва і справа, і ті, хто працює в реальному світі, де важливі питання, вважають, що вони всі божевільні (я член останньої групи бути справедливим).
Зрештою, ви можете розробити чудове програмне забезпечення на C або C ++ або вставити мову тут . Це зводиться до можливостей розробника, а не до мови. Бути знавцем мови, як правило, потрібно лише в тому випадку, якщо ви вибрали неправильну мову для початку і тепер вам потрібно перетворити її на вирішення своєї проблеми, в більшості випадків це єдині ситуації, коли вам потрібно зануритися в незрозумілі функції або компілятор хитрощі для досягнення мети.
Я часто чую, як люди починають ці аргументи як "Я знавець мови X і бла-бла". Я чесно негайно дискредитую цих людей, тому що, на мою думку, вони вже підійшли до проблеми з неправильного кута, і все після цього заплямовано бажанням використовувати свій інструмент для вирішення проблеми та показати, наскільки це "круто".
Я так часто спостерігаю, як розробники вибирають набір інструментів першим і намагаються зв'язати його зі своєю проблемою вдруге, що абсолютно неправильно і призводить до лайм-рішень.
Як я згадував у коментарі до іншої відповіді, ці мовні війни часто переростають у аргументацію того, що мова X дозволяє програмісту робити більш німі речі. Хоча читати цікаво, всі ці твердження справді означають, що у вас є проблема з наймом хороших розробників, і вам потрібно вирішити це питання безпосередньо, а не намагатися надавати допомогу ситуації, продовжуючи наймати поганих розробників і вибираючи такі інструменти, які вони можуть робити як мало можливо пошкодження.
На мій погляд, хороші розробники, будь то розробка програмного забезпечення або обладнання, досліджуйте проблему, розробляйте рішення та знаходьте інструменти, які дозволять їм висловити рішення найкращим чином. Не має значення, чи потрібний вам інструмент є те, що ви ніколи раніше не використовували, після того як ви використовували 3-4 мови / інструменти розробки для проектів, що вибирали новий, повинні мати мінімальний вплив на час вашої розробки.
Звичайно, "найкращий спосіб" є суб'єктивним терміном, і його також слід визначити на етапі дослідження. Потрібно розглянути безліч питань: продуктивність, простота вираження, щільність коду тощо на основі наявної проблеми. Я не включав ремонтопридатність у цей список з причини, мені все одно, яку мову ви вибрали, якщо ви вибрали відповідний інструмент і знайшли час, щоб зрозуміти проблему, це повинно вийти "безкоштовно". Складне підтримання коду часто є результатом вибору неправильного інструменту або поганої структури системи, це призводить до некрасивого хакітського безладу, щоб змусити його працювати.
Стверджувати, що будь-яка мова є «кращою», ніж будь-яка інша, нерозумно, не визначаючи конкретної проблеми, що цікавить. Об'єктно-орієнтований підхід не завжди кращий, ніж функціональний підхід. Є деякі проблеми, які дуже добре піддаються об'єктно-орієнтованій парадигмі дизайну. Є багато, що цього не роблять. Це ж твердження можна зробити про багато мовних особливостей, на які люди, схоже, люблять харчуватися.
Якщо ви витрачаєте більше 20% свого часу на проблему, яка фактично набирає код, ви, ймовірно, створюєте дуже погану систему, або у вас дуже погані розробники (або ви все ще навчаєтесь). Ви повинні витратити більшу частину свого часу на переднє діаграмування проблеми та визначення взаємодії різних частин програми. Залишивши групу талановитих розробників у приміщенні з маркерною дошкою та вирішити проблему та сказати їм, що їм заборонено писати будь-який код чи вибирати будь-які інструменти, поки вони не почуватимуться комфортно з усією системою, вони зроблять більше для покращення якості Вихід та швидкість розвитку, ніж вибір будь-якого гарячого нового інструменту гарантовано покращить час розробки. (розгляньте розвиток scrum як орієнтир для полярного, протилежного моєму аргументу)
Часто прикрою реальністю є те, що багато підприємств можуть виміряти цінність розробника лише за кількістю написаних рядків або за допомогою «відчутного результату». Вони розглядають 3 тижні в приміщенні з маркером як втрату продуктивності. Розробники часто змушені швидко пройти стадію роздумів або змушені використовувати інструмент, встановлений політичним питанням компанії: "Брат мого начальника працює на IBM, щоб ми могли використовувати лише їх інструменти", такий сміття. . Або ще гірше, ви отримуєте від компанії постійно мінливий набір вимог, оскільки вони не здатні провести належне дослідження ринку або не розуміють впливу змін на цикл розвитку.
Вибачте за те, що я злегка не ставлю тему з цією розпустою, я маю досить сильні думки щодо цієї теми.