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

Я шукаю методологію вибору мови. Я не прошу думок щодо мов. Мені поставлено завдання порівняти поточну мову нашого магазину з іншими, які є в наявності. Ми - магазин веб-розробок btw.

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

Мені також потрібно мати менш технічну інформацію, як, наприклад, розмір пулу талантів для даної мови та середня зарплата в цьому пулі. Як буде бачити ринок наш вибір?

Ми почали шукати консультанта, який допоможе нам зрозуміти всі ці речі, але, як ми виявили, що більшість консультантів походять із передумови розвитку, і часто здається, що відповідь " ххх - найкраща мова, тому що саме я Ви використовували найбільше за останні п ять років, і це ніколи мене не підводило. Ви можете доповнити його yyy для передньої частини та використовувати zzz- бібліотеку "

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

Хтось ще мав пройти цю вправу? Якщо у вас є, чи можете ви поділитися кроками та / або методологією, якою ви проходили процес?

@FrustratedWithFormsDesigner натякнув на це вище, я буду більш тупим: вам доручили дороге, але марне завдання.

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

Інакше кажучи, якби була ідеальна мова, кожен використовував би її замість цих "об'єктивно" дефектних мов. Це також визначає ступінь управління мікроелементом, яка повинна бути провінцією інженерів, які повинні змусити його працювати. Ерланг може бути "об'єктивно найкращим", але якщо цього ніхто не знає, додайте 6-місячну / початкову вартість інженера та ще 6 місяців / інженера, щоб отримати компетентність.

Оскільки у мене немає вашої роботи, я не переживаю її втратити, хоча ви можете. Я дав би генеральному директорові доповідь про тезу "Фізична церква-Тьюрінг". Тоді я б зібрався зі старшими інженерами і отримаю їх не суворий, не об’єктивний погляд на те, що слід використовувати, і скажу генеральному директору, що саме ви використовуєте. В обмін ви обіцяєте, що інженери не будуть проводити засідання правління, фінансових директорів, методів бухгалтерського обліку, підбору ВП та ін. Ми є причиною, що ми спеціалізуємось, і у нього немає більше місця в інженерних уподобаннях, ніж ви в його домені.

Деякі широкі мазки пензлем, які слід врахувати:

Мовна популярність

Це насправді не має значення, оскільки популярність не обов'язково ототожнюється з продуктивністю, виразністю чи будь-якими іншими мовними якостями, які мають більше значення, але ця думка часто перетворює на всі інші міркування, оскільки:

1. Простіше знайти розробників програмного забезпечення популярною мовою.
2. Простіше знайти інструменти та бібліотеки популярною мовою.
3. Ті, хто приймає рішення, не розуміють мовних компромісів, тому приймуть безпечне рішення ("багато компаній використовують цю мову, тому це повинно бути добре").

Застосування до проблемної області

Будь-яка програма може бути написана будь-якою мовою програмування, повністю завершеною Тьюрінгом, але деякі мови краще підходять для певних проблемних доменів, ніж інші. Якщо ви пишете веб-додатки, ви, ймовірно, будете тяжіти до мов та інструментів, які добре підходять для цього, і, швидше за все, це будуть об'єктно-орієнтовані мови.

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

І, звичайно, є все між ними. Багато мов підтримують декілька парадигм, а деякі програмні зразки існують виключно для подолання обмежень у тих мовах, у яких відсутні певні функції або парадигми.

Виразність та продуктивність

Деякі мови є більш виразними, ніж інші. Те, що можна записати однією мовою за допомогою тисячі рядків коду, можна записати більш виразною мовою, використовуючи сто рядків коду. Компроміс полягає в тому, що сто рядків коду, ймовірно, написані менш популярною мовою людьми, що володіють більшою кваліфікацією.

Багато рядків коду, присутніх на об'єктно-орієнтованих мовах, що використовуються для написання додатків для бізнес-бізнесу, є церемоніальними. Ця церемонія, хоч і витрачає часу і зусиль на розвиток, також забезпечує видиму структуру, яка в іншому випадку не була б зрозумілою більш виразною мовою. Це дозволяє людям з меншим досвідом, ніж їм інакше потрібно було б працювати над кодом зі зниженою кількістю ризику.

Ера кількох мов

Я закінчу, стверджуючи, що бажання визначитися з однією мовою може бути помилковою дилемою. Заявки сьогодні часто пишуться не однією, а багатьма мовами. Кожна мова має свої сильні сторони, і (теоретично) спеціально розроблена для завдання, яке використовується. Деякі проблемні домени (наприклад, логіка веб-браузера або доступ до бази даних) потребують конкретних мов.

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

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

Навіть знання фактів все ще залишає вас досить суб'єктивним вибором. Ваш генеральний директор хоче, щоб він зводився до приблизної метрики, на зразок доларів за функцію. Щоб отримати точну картину, вам доведеться зробити кілька прототипів, потім поговорити про те, як легко було навчитися, як швидко було написати прототип, коли ви засвоїли основи, як легко ви думаєте, що було б підтримувати , і як ви широко застосовуєте, на вашу думку, це було б для тієї роботи, яку ти зазвичай робиш.

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

Ось приблизний список задніх категорій:

• Microsoft. (Можуть мати підкатегорії. Про них я нічого не знаю.)
• OOP у важкій вазі, як і Drupal.
• Легкий OOP, як пляшка пітона.
• Грайте / піднімайте / scalatra за допомогою Scala.
• Грайте / піднімайте за допомогою Java.
• Весняний.
• Стручкоподібні.
• Рельсоподібні.
• На основі Haskell
• Node.js

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

• JavaScript у стилі OOP
• JavaScript у функціональному стилі, як у підкреслення
• JavaScript у реактивному стилі, як у Бекона
• Веб-інструментарій Google
• В'яз

Витратити день-два на кожну категорію, реалізуючи простий прототип, зайняло б у вас пару місяців, після чого ви мали б набагато краще уявити про сильні та слабкі сторони кожної. Можливо, ви могли б швидше виключити, спираючись на культуру чи досвід своєї компанії.

Оскільки це бізнес-звіт, я також би зайняв деякий час, гуглюючи такі речі, як "Яку мову використовує <компанія>", замінюючи різні компанії, якими ви захоплюєтесь. Багато з них написали власні відомості про те, чому вони зробили конкретний вибір мови, що дозволить вам включити чудові посилання.

Визначте та оплатіть недоліки, властиві вашому існуючому процесу розробки, як $ A. Визначте вартість переходу на будь-який інший процес розробки як $ B.

Якщо $ A менше B $, зупиніться.

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

Якщо чесно, якщо ви зараз не намагаєтеся розробляти веб-додатки у Fortran, єдиний вплив, який ви використовуєте, матиме на вартість підрядників, які ви використовуєте для заповнення прогалин. Основний потік та зрілі мови / інструменти / процеси розробки вже вирішили більшість проблем, з якими ви, мабуть, зіткнетеся, коли як найгарячіші, новітні та найсексуальніші інструменти мають найдорожчі тренери та підрядники, але найменш зрілі рішення. І якщо у вас є недоліки, які вимагають такої зміни, навряд чи ваш вибір мови повністю вирішить їх.

Однак, якщо рентабельність не є основною метою тут, то потрібно враховувати стигму, яку можна вважати старомодною проти кудів того, щоб бути передовим. Попросіть у свого начальника значення долара використовувати для цієї частини рівняння.