Чи заслуговують динамічні набрані мови всі критики? [зачинено]

Я прочитав кілька статей в Інтернеті про вибір мови програмування на підприємстві. Останнім часом популярними стали багато динамічних набраних мов, наприклад Ruby, Python, PHP та Erlang. Але багато підприємств все ще залишаються зі статичними мовами типу C, C ++, C # та Java.

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

Основна причина, чому підприємства не починають використовувати такі мови, як Erlang, Ruby та Python, здається, це те, що вони динамічно набираються. Це також, здається, є основною причиною, чому люди на StackOverflow вирішують проти Ерланга. Дивіться, чому ви вирішили "проти" Ерланга .

Тим НЕ менше, здається , є сильна критика динамічної типізації на підприємствах, але я дійсно не розумію , чому це , що сильний.

Дійсно, чому на підприємствах так багато критики проти динамічного набору тексту? Це насправді так сильно впливає на вартість проектів, чи що? Але, можливо, я помиляюся.

Так, я вважаю, що вони так роблять.

Є кілька причин, які потрібно враховувати при виборі мови для нового проекту:

• Швидкість виконання. Порівняно з C / C ++ / Fortran, Perl і Python настільки повільні, що смішно.
• Швидкість ініціалізації. Порівняно з перерахованими вище швидкими мовами, Java опускається і плаче, коли JVM продовжує завантажувати та завантажувати, і ... while(1)....
• Прототип-здатність. Вичерпно переглядаючи та виконуючи роботу з декларацією / визначенням, необхідною для C ++ або Java, збільшується LOC, що є єдиним відомим показником, який надійно корелює з рахунками помилок. Це також займає багато часу. Це також вимагає трохи більше продумати типи та з'єднання.
• Внутрішня чутливість. Динамічно возитися з вашими внутрішніми є чудовими, поки ви не почнете налагоджувати свій самовиправляючий код . (Python, Lisp, Perl)
• Перевірка правильності. Компілятор може забезпечити швидкий повторний пропуск напівкоректності вашого коду в C ++, і це може бути справді приємно.
• Деталі статичного аналізу C і Java мають досить хороший статичний аналіз. Perl не є повністю статистично проаналізованим на теоретичному рівні (можливо, і Python). Я впевнений, що і Лісп не є.
• Дивні платформи приймають лише C, загалом.
• Ланцюг підтримки. Якщо у вас може бути укладення контракту, ви побачите і працюєте над вашими помилками, це величезна кількість .

Якщо ви можете припустити, що організація, з якою ви працюєте, має принцип "Іти вперед" (для цього існує термін бухгалтерського обліку), і не просто випадково вирішить не працювати над програмним забезпеченням, то у вас є набагато кращий випадок для за допомогою програмного забезпечення. Оскільки немає великого продажу бізнесу (що несе відповідальність за його підтримку) Python / Perl / $ dynamic_language, це значно знижує ризик.

На мій досвід, у сервісів з відкритим кодом часто виникають проблеми з повною відповідальністю за помилки та випуск оновлень. "Це безкоштовно, ви працюєте над цим!" - це не відповідь, прийнятна для більшості підприємств (не серед інших їх компетенцій).

Звичайно, я не говорю про світ webapp / startup, який прагне грати за правилами високого ризику / високої винагороди та бути дуже відкритим для того, щоб залишитися на пенітному краю техніки.

Ви надаєте занадто багато технічного кредиту керівникам підприємств. Є стара приказка: "Ніхто не звільнявся за покупку IBM". Якщо ви підете іншим маршрутом, і все стає непомітним (вони завжди роблять), ніхто не хоче ризикувати, щоб його звинуватили. Дотримуйтесь стандартів і звинувачуйте когось іншого.

Є багато молодих компаній, які з часом стануть підприємствами завтрашнього дня і будуть використовувати ці мови.

І не будемо забувати про мільярдні рядки коду, написані у VBA!

Причина, по якій підприємства використовують C, C ++, C # та Java, не полягає в тому, що вони набрані статично (принаймні, не безпосередньо). Запевняю вас, керівники підприємств не роблять такого вибору на основі об'єктивного порівняння типів систем.

Компанії роблять турботу про:

• Довгострокові витрати на обслуговування : чи можна обґрунтовано очікувати, що справи продовжуватимуть працювати добре через 10 років? Насправді це добре, якщо еволюція мови консервативна та зворотно сумісна (як у Java). Тут є корисним статичне введення тексту, оскільки воно вловлює основні типи помилок під час компіляції, перш ніж вони потрапляють у ваші виробничі системи .....
• Доступність талантів - чи зможете ви знайти розробників, щоб підтримувати вашу блискучу нову систему? Що робити, якщо оригінальний розробник піде, чи всі інші зрозуміють код? Це спричиняє значну перешкоду для впровадження будь-якої "нової" мови (особливо якщо вона також створює нові вимоги до розгортання, побудови систем, оперативної підтримки тощо). Це дає величезні переваги мовам, які широко використовуються (C, C ++, C # і Java)
• Витрати на інтеграцію : чи легко підключитися / інтегруватися з іншими технологіями, які у вас вже є або є ймовірними придбати? Якщо у вас вже є стек застарілих систем J2EE, тоді вам потрібно інтегруватися з ними. Нове рішення Java EE для цього, ймовірно, буде набагато практичнішим, ніж, наприклад, Python.
• Передбачуваність / низький ризик : чи підтверджена платформа / мова, і чи можу я бути впевненим, що вона буде працювати? Зазвичай це важливіше простої продуктивності. Менеджеру набагато простіше переконати свого начальника дати йому великий бюджет на робочу силу для побудови нової системи, ніж для нього повернутися пізніше і сказати, що це не спрацювало .....
• Підтримка / підтримка підприємств - чи є основними міжнародними організаціями підтримка мови та платформи? Чи підпишуть вони договір на підтримку мене, щоб я мав кого зателефонувати, якщо все піде не так?
• Нейтральність постачальника / незалежність платформи - я збираюся замикатися на одному постачальнику? Або у мене доступний широкий спектр майбутніх варіантів постачальників / шляхів переходу? Ви не хочете застрявати в архітектурному тупику, не в змозі досягти прогресу, поки ваші конкуренти їдять ваш обід. Якщо ви робите свою роботу належним чином як архітектор підприємства, вам потрібно подумати над цим предметом як мінімум на 5-10 років.

Особисто я вважаю, що якщо ви хочете використовувати динамічні мови на підприємстві, то на сьогоднішній день ваш найкращий шанс - це використовувати щось, що відповідає за існуючу екосистему підприємства. Найбільш помітними є нові динамічні мови JVM: наприклад, JRuby, Groovy, Clojure. Що стосується управління ІТ, то це "безпечний" динамічний вибір мови, оскільки вони функціонують усередині і чудово грають з рештою екосистеми корпорації Java.

Основна причина, чому підприємства не починають використовувати такі мови, як Erlang, Ruby та Python, здається, це те, що вони динамічно набираються.

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

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

• Мови, що динамічно набираються, як правило, повільніше, ніж їхні родичі, які мають статичний тип.
• Помилки важче зрозуміти і їх важче налагодити
• Компілятор / перекладач, як правило, набагато менш вибагливий щодо того, що можна, а що не можна робити. тобто ви вловлюєте лише синтаксичні помилки на етапі компіляції
• Якщо ви не дуже обережні з дизайном динамічно універсальна мова, ви в кінцевому підсумку з JavaScript, який є мова коду, запахи

EDIT: Я мушу зазначити, що моєю основною мовою програмування на даний момент є Python, який динамічно набирається. Особисто мені подобається свобода, яка виникає з тим, що не потрібно заздалегідь оголошувати змінні, але часом було б непогано вказати (наприклад), які параметри потрібні функції для лову помилок раніше, ніж пізно.

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

Динамічно набрані мови сприймаються як мови сценарію. Ви ніколи не пишете заявку в bash або пакетний файл. Усі динамічно набрані мови, як правило, вкладаються в цю категорію (несправедливо).

Мови, що динамічно вводяться, є повільнішими, ніж статично введені мови. (Але ми побачимо, наскільки добре працює над змінами JIT)

Зауважте: це здебільшого суб’єктивно і ґрунтується на моїх переживаннях та враженнях.

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

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

З іншого боку, динамічно набрані мови дуже прагматичні. Перетворення типів часто відбувається неявно; функції можуть навіть відтворюватися, якщо ви надаєте неправильний тип введення, якщо він веде себе досить схожим. У таких мовах, як Python, навіть рівні доступу базуватимуться на контракті, а не на технічних обмеженнях (тобто це лише privateтому, що вам сказано не використовувати його та має смішне ім'я).

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

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

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

Інша причина, що корпорації підприємств не використовують сильно динамічно набрані мови - це застарілий код. Як би нерозумно нам не здалося, великі корпорації часто дотримуються рішень, які працюють, навіть якщо вони вже минули термін їх зберігання. Ось чому так багато великих компаній застосовують Internet Explorer 6 і так повільно модернізують свої ОС. Ось чому вони часто пишуть новий код "старими" мовами (наприклад, старовинні версії Java): набагато простіше додати кілька рядків коду до неживого програмного забезпечення, ніж отримати схвалення на повне перезапис у новій мова.

tl; dr: статичні мови більше схожі на бюрократію, тому підприємливі менеджери їм подобаються краще.

Ні, я не думаю, що динамічно набрані мови заслуговують на всю критику. (Або, якщо вам зручніше, вони заслуговують стільки ж критики, скільки мов, що мають статичний тиск.)

З мого досвіду (і я не намагаюся узагальнити це твердження), програмісти, які критикують динамічні мови, не використовували їх. Бесіда зазвичай йде "але при статичному наборі компілятора виявляється стільки помилок!" і я кажу "ну, це просто не проблема, на мій досвід". (Зазвичай інші програмісти походять з Java, Delphi або подібних програм; я не знаю жодних програмістів Haskell або ML.)

Єдине , що на насправді коліки мене, коли хто - то стверджує , що метод Foo не може можливо зробити (або може бути дуже важко зробити) в динамічно типізований мову ... коли цей метод був винайдений в, по і динамічно типізований мова. ІДЕ? Невеличка розмова. Автоматичний рефакторинг? Невеличка розмова. Викликаючі / виконавці? Невеличка розмова.

Підприємства просто не використовують нові мови та інструменти досить швидко, і для цього є вагомі причини. Але коли один із основних інструментів на зразок C # реалізує деякі з цих функцій, вони потраплять в основні підприємства ....