Який передбачуваний приріст продуктивності динамічного набору тексту? [зачинено]

Я часто чув твердження, що мови, що динамічно набираються, є більш продуктивними, ніж мови, які мають статичний характер. Які причини цієї претензії? Хіба це не просто інструментарій із сучасними концепціями, такими як конвенція щодо конфігурації, використання функціонального програмування, вдосконалені моделі програмування та використання послідовних абстракцій? Справді, буває менше затруднень, оскільки (наприклад, на Java) часто надмірні декларації типу не потрібні, але ви також можете опускати більшість декларацій типу на мовах статичного типу, які використовують умови виводу, не втрачаючи інших переваг статичного введення тексту. І все це доступно і для сучасних мов, що мають статичний тип, як Scala.

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

Пояснення: Мене більше цікавлять великі / середні проекти, ніж швидкі хаки. :-)

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

Причини динамічного набору тексту є більш продуктивним:

• Це більш стисло - багато сторонніх кодових шаблонів можна видалити, якщо все динамічно набрано декларації типу, логіки набору тексту тощо. Усі інші речі, однакові, коротший код пишеться незначно швидше, але що важливіше, можна швидше читати та підтримуйте (оскільки вам не потрібно перебирати багато сторінок коду, щоб зрозуміти, що відбувається)
• Простіші "зловмисні" методи, такі як набирання качок та виправлення мавп, можуть отримати результати дуже швидко (хоча згодом можуть вас заплутати ...)
• Більш інтерактивна - динамічне введення тексту, можливо, більше підходить для інтерактивного програмування, подібного до REPL, для швидкого прототипування, налагодження в режимі реального часу запущених екземплярів програми або навіть кодування в реальному часі.
• Тестові випадки можуть виявити помилки під час виконання - якщо припустимо, що ви використовуєте TDD або, принаймні, маєте хороший тестовий набір, це має вирішити будь-які проблеми введення тексту у вашому коді.
• Кращий поліморфізм - динамічні мови з більшою ймовірністю сприяють створенню поліморфних функцій та абстракцій, що може підвищити продуктивність та повторне використання коду. Наприклад, Clojure широко використовує динамічний поліморфізм у багатьох своїх абстракціях .
• Прототипи - моделі даних / об'єктів на основі прототипу, на мій погляд, є більш потужними та гнучкими, ніж статично типізовані спадкові спадщини. Динамічні мови швидше дозволяють або заохочують підхід, заснований на прототипі, відмінним прикладом є Javascript.

Причини статичного набору тексту є більш продуктивним:

• Кращий дизайн - примушення думати про типи значень у вашому програмному забезпеченні на передній план може підштовхнути вас до більш чистих і логічних рішень. (Я кажу, що можна - все-таки можна створити дійсно поганий код ...)
• Краща перевірка часу компіляції - статичне введення тексту дозволяє забезпечити більше помилок під час компіляції. Це величезна перевага, і, мабуть, найкраща річ у загальномовному типізованому мові.
• Автоматичне завершення - статичне введення тексту може також надати більше інформації для IDE, щоб автоматичне завершення пошуку коду чи документації було більш ефективним.
• Перешкоджає хакам - вам доведеться зберігати дисципліну типу у своєму коді, що, швидше за все, буде перевагою для довгострокового ремонту.
• Введення тексту - у деяких мовах (напр., Scala) це може отримати багато лаконічних переваг динамічних мов і надалі підтримуватиме дисципліну типу.

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

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

За допомогою динамічних мов ви можете писати скажений код швидше, ніж при використанні набраної мови.

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

Це підвищення продуктивності :)

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

Тож підвищення продуктивності може бути міфом для середнього / великого проекту протягом його життя.

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

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

Деякі випадки, коли ви можете помітити, як перевірка типу перешкоджає, - це загальні контейнери та спільне / протиріччя в аргументах та типах повернення.

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

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

Однак я нещодавно почав використовувати Haskell. Haskell дозволяє мені писати абстрактний, загальний код так само легко, як і будь-яка динамічно набрана мова, яку я використовував. Мій приклад Java / JavaScript вище в Haskell не має сенсу, оскільки в ньому немає об'єктів, методів, подій або навіть багато мутацій, але інші види загального коду дуже легко написати.

Насправді, Haskell може написати якийсь загальний код, який динамічно набраних мов не може; ідеальним прикладом є readфункція, яка в основному протилежна toString. Ви можете отримати Intабо будь-який Doubleабо будь-який тип, який хочете (до тих пір, як це у певному класі типу). Ви навіть можете мати поліморфні константи , тому maxBoundможуть бути максимумом Int, Double, Char... і т.д .., Все залежить від того, якого типу він повинен бути.

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

Однак навіть у типовій системі Haskell є деякі набридливі проблеми, яких у вас не було б у динамічно набраній мові. Найбільше мене дратувало - це спосіб обробки чисел; наприклад, вам доведеться возитися з типовою системою, щоб використовувати length(список) як подвійний, з чим у вас не було б проблем без системи типу. Ще одна дратівлива річ, з якою я зіткнувся - це робота Word8(непідписаний тип int) та функції, які очікують Int.

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

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

Це має історичні причини. Якщо повернутися на кілька десятиліть назад, динамічні мови, безперечно, були набагато продуктивнішими, ніж статичні мови (в той же час значно повільніше). Perl, очевидно, набагато продуктивніший, ніж C, якщо ви знаєте і те, і завдання під рукою дозволяє будь-яке. Але з часом мови багато запозичили один у одного, і новіші мови звужують розрив (і в продуктивності, і в продуктивності).

Ось кілька моментів, які слід врахувати:

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

Безпека пам’яті : Це підвищення продуктивності, що вам не доведеться турбуватися про те, щоб стріляти в ногу. Перед "керованими" статичними мовами, такими як Java, статичні зазвичай означали прямий доступ до пам'яті. Налагодження також є частиною продуктивності, і небезпечний доступ до пам'яті може призвести до дійсно незрозумілих помилок.

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

Велика стандартна бібліотека. З-за великої стандартної бібліотеки Python славно рекламувався як "батареї включені". Це порівняно з C, які мають дуже мінімалістичну стандартну бібліотеку. Але на таких платформах, як Java та .net, велика стандартна бібліотека стає стандартною, і нові мови, такі як Scala та F #, успадковують це "безкоштовно".

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

Синтаксис закриттів та лямбда - динамічні мови зазвичай мали це з самого початку, але статичні мови прийняли це, останнім часом Java.

ВІДПОВІДАЙТЕ можливість швидкого тестування фрагментів коду в інтерактивному режимі - величезна користь. Але хоча інструменти IDE, як "безпосереднє" вікно у Visual Studio, статичні мови можуть певною мірою імітувати це.

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

Підсумок: Історично це було правдою, але сьогодні відповідь менш чіткий.

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

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

Рефлексія Рефлексія - це принципово динамічна функція набору тексту. Ви перевіряєте типи об'єктів на raterime rater, ніж час компіляції. Коли він був представлений, це було нахмурено, але в C # використання рефлексії стає все більш і більш всюдисущим, наприклад, ASP.Net MVC сильно використовує рефлексію.

Атрибути Атрибути є прикладом динамічного набору тексту. Ви можете додати довільні атрибути до класу під час компіляції, а потім перевіряєте під час виконання (через відображення) та маніпулюєте на ньому об'єктами. Щось на зразок MEP - це в основному структура розширення, заснована на моделі динамічного типу.

Linq - SQL, EF mv. Різні трансформатори Linq перевіряють запити як об’єкти виконання та генерують sql на ходу. Це не стає більш динамічним, ніж перевірка коду під час виконання. CodeDom - інша сторона монети, де код може створюватися під час виконання

Roslyn Roslyn в основному реалізує eval, що колись вважалося визначальною рисою справді динамічної мови.

Dynamic The dynamic-type є найбільш чітко динамічною особливістю в C #, і рекламується при спрощенні та продуктивності взаємодії із зовнішніми об'єктами та мовами. Але він також використовується в Asp.net MVC для зручності.

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

Вся функція сучасних мов настільки велика, що статичне та динамічне введення само по собі не має великої ваги.

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

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

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

Програмування стає набагато простішим, коли ваша мова не замикає вас на релігійному виборі парадигм, а намагається бути просто хорошим інструментом. Існує ряд статичних та динамічних мов та змішаних мов, які досягають успіху в цьому. Деякі з них легко вивчити, найбільш важко освоїти.
Їх сила походить від того, як можна скласти їхні індивідуальні особливості, щоб легко створити прості рішення складних проблем. Це виключає певну ортогональність, яку можна досягти лише завдяки делікатному балансу включення чи упущення всіх досліджених досі мовних особливостей. Якби ви спробували додати статичний набір до Ruby, ви його покалічили, якщо б ви спробували відібрати його від Haskell, ви розтрощили б його. На відміну від цього: якби ви забрали його з C, люди навряд чи помітили б, і якщо ви відібрали його від Java, дехто може вам подякувати.

Зі свого особистого досвіду можу вам сказати таке: мені подобається Рубі. Це розширило мій кругозір і те, як я проектую системи. IMHO його слід використовувати в першу чергу для навчання людей програмуванню. Це ненав’язливо, потужно, лаконічно, весело. Я розумію, чому хтось із православної мови сподобається.
Однак у довгостроковій перспективі статична типізація дозволяє відкласти роботу статичному аналізатору, а при виводі типу це в основному відбувається без витрат. Результат - код, який простіше у обслуговуванні і часто працює швидше.

Але знову ж таки, статичне введення самотужки не може зробити нічого. Це питання комбінації. Я думаю, що десь між F #, Scala, Nemerle, OCaml або haXe ви можете знайти свій власний оптимум. Але це в кінцевому підсумку залежить від вас, адже мова повинна дозволяти вам вкладати свої думки без зусиль, а не змушувати вас згинати їх навколо себе. Зрештою, ніщо не приносить більшого підвищення продуктивності, ніж якщо програмування - це весело.

Особисто єдиною причиною динамічного введення тексту може допомогти, якщо ви справді повільний машиніст або ви створюєте гігантські функції / методи / whatevers, які важко орієнтуватися. Ви також повинні взяти участь у всьому випуску тестування підрозділу. Динамічні типи вимагають (якщо вам не подобається писати порушений код) енергійних тестів на одиницю (Щоб переконатися, що ваші динамічні типи не вибухають несподівано (тобто змінна в основному качка, але dcuk випадково іноді)). Статистика буде намагатися набагато сильніше запобігти цьому (І так, ви можете зробити аргумент для енергійних одиничних тестів)

Я думаю, що перш за все вам потрібно визначити "продуктивність". Що означає "продуктивність праці" та що вона включає?

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

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

Великою перевагою динамічного набору тексту є продуктивність.

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

Штрафи за швидкість (або відсутність!) Та споживання ресурсів не такі погані, як можна було б очікувати, і в більшості випадків більш ніж компенсуються швидкістю та гнучкістю розвитку.

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

Що (мабуть) було б різним, було б дослідження, яке проводилось сьогодні: -

1. Java JVM покращилися до невпізнання.
2. Сучасні IDE покращили б продуктивність C ++ та Java-кодерів, однак це дуже мало змінило мову мов сценаріїв.
3. C # буде включений і, ймовірно, знаходитиметься в тому ж парці кулі, що і Java, але трохи краще.

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