Чи можуть статичні та динамічно набрані мови розглядатися як різні інструменти для різних типів завдань?

9

Так, задаються подібні запитання, але завжди з метою з'ясувати, "хто з них краще".

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

Незважаючи на це, я, безумовно, бачу цінність у навчанні С для обробки складних операцій на нижчих рівнях коду (який, я вважаю, має багато спільного зі статичним проти динамічним на рівні компілятора), але те, що я намагаюся обернути головою чи є конкретні контексти проектів (можливо, певні типи динамічних операцій, що вимагають великих даних?), що включають інші речі, крім продуктивності, де є набагато більше сенсу працювати з Java або C # проти чимось на зразок Python.

dynamic-typing static-typing

— Ерік Реппен
джерело

5

Відповідь "Так". Кожен тип мови - і справді кожна мова - має свої сильні та слабкі сторони, і тому він краще підходить для деяких завдань, ніж інші.

— ChrisF

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

— сара

10

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

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

— Мейсон Вілер
джерело

3

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

— Мейсон Уілер

9

@ Mason Wheeler: Дуже хороша відповідь. + 1 Я додам, що статична перевірка типу також допомагає знайти помилки раніше, якщо правильність типу перевірки компілятора. Наприклад, я налагодив програму Ruby на 200 рядків учора, і було дві помилки, пов’язані з типом, які я міг виявити лише запустивши програму. Я не хочу думати, що відбувається в 100-лінійному проекті. Таким чином, динамічне введення тексту дає вам більше гнучкості, що добре в описаних вами контекстах, за ціною, яку ви не можете знайти певні помилки під час компіляції. Тож статично типізовані стосуються не лише ефективності, а й коректності.

— Джорджіо

1

@MasonWheeler Два роки та набагато більше C # та Java, ніж я торгувався на потім, я б зараз не погоджувався з кількома речами. Складні веб-додатки повністю виконані з динамічними мовами. Час компіляції та запуску є безглуздим, коли ви можете внести зміни, які видно відразу. І я розробив думку, що всяке метушні щодо типів має набагато більше сенсу в процедурній мові, ніж у мові, якою повинен керуватися OOP, де дані не повинні постійно міняти руки в першу чергу.

— Ерік Реппен

1

@Erik: * wince * По-перше, оцінюючи статичну типізацію як концепцію Java, це ніби судити машини як концепцію Pinto. По-друге, все, де зміни можуть бути «помітні негайно» - це, за визначенням, не дуже складна програма, тому що навіть при сучасному обладнанні складні програми потребують досить багато часу для підготовки коду, будь то компілятор чи інтерпретатор ( або компілятор JIT), що здійснює підготовку. Навіть найбільш вражаючі веб-програми, як правило, дуже прості програми, підкріплені дуже складними базами даних, це зовсім інша справа.

— Мейсон Уілер

1

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

— Rufflewind

4

Те, як я на це дивлюсь, якщо ви можете працювати природним чином у мові, що набирається статичним способом, то статичне введення тексту - це шлях. Загалом, мета типової системи - запобігти виконанню операцій із невизначеною семантикою - як (string) "hello" + (bool) true. Наявність додаткового рівня безпеки, що заважає вам виконувати ці операції, може бути хорошим способом запобігання помилок у вашому коді, навіть без обширних тестових одиниць. Тобто безпека типу забезпечує ще один рівень впевненості в семантичній правильності вашого коду.

Але типові системи дуже важко виправити. Я не вірю, що в нашому часі написання цієї системи є досконалою системою. (Під «ідеальною системою типів» я маю на увазі систему суворого типу, яка не потребує багатослівних анотацій коду, яка не генерує помилково-позитивних помилок типу і помилки типу яких програмісту легко зрозуміти.) Далі, вона може бути важко зрозуміти дійсно хороші системи типів, які існують. Коли я вивчав Haskell, я не можу сказати вам кількість незрозумілих помилок типу, які я отримав під час спроби написати те, що виглядало (на мене) як правильний код. Зазвичай код був насправді невірним (що вказує на користь типової системи), але це зайняло багатороботи, щоб зрозуміти повідомлення про помилки компілятора, щоб я міг виправити основні проблеми. У мовах ОО, ви, зрештою, можете подумати, що "цей аргумент повинен бути протилежним типу введення, а не коваріанту!", Або (що більше ймовірно) повертається до набірних машин, щоб вийти з меж системи типів. Системи типів можуть бути набагато складнішими, ніж ви думаєте.

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

— Айдан Каллі
джерело

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

— Мейсон Вілер

Я думаю, що багато проблем, пов'язаних із "небезпеками" динамічно набраних мов, не враховують, як ми пишемо цей матеріал. Багато з Python та JS можна писати консольно. Компіляція гвинта проти часу виконання, я можу спробувати його зараз і побачити, що відбувається. Я думаю, що ви досягли однієї дуже хорошої точки. Ніщо не робить мене божевільнішим в розробці веб-сторінок, ніж клієнт, ніж коли всі нібито добрі постачальники браузерів дають заплутану передачу жахливого коду, в той час як IE6 або 7 робить несподіване, а це - лайно, коли це, а не просто, добре ... смоктання більш типовим чином.

— Ерік Реппен

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

— jbtule

4

Вони різні інструменти, але це не за продуктивністю. Вся справа в складності .

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

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

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

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

Детальніше дивіться тут: https://softwareengineering.stackexchange.com/a/105417/17428

— Еоніл
джерело

1

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

— Джорджіо

2

@Giorgio Ну, це, можливо, тому, що я залежний від матеріалів статичної перевірки. Мені це так мило, і я буквально не можу жити без них навіть у невеликих масштабах: p

— Eonil,

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

— Джорджіо

1

В даний час я програмую на мовах статичного типу (C # і F #), але мені подобається програмування на динамічних мовах (Smalltalk, Ruby). Багато плюсів і мінусів у людей, що асоціюються з одним типом проти іншого, більше стосуються мови, ніж коли ти застосовуєш типи. Наприклад, у динамічних мовах зазвичай є більш чіткий і стислий синтаксис, однак F # і OCaml зі своєю системою виводу мають такий же синтаксис, як і будь-яка динамічна мова. І при статичному введенні у вас є справжні автоматичні рефактори та автозаповнення, але Smalltalk, який має весь вихідний код у базі даних та кожен метод, складений окремо, був першою мовою, яка справді мала серйозні автоматизовані рефактори, і це працювало чудово. Зрештою, сучасні динамічні та статичні мови сьогодні є безпечними для типу, що є найважливішим аспектом вашої системи типу,

— jbtule
джерело

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

— Erik Reppen

@erik, О так, більше ніж імплікація набору тексту та var: F # Тип висновку

— jbtule

-1

Зараз 2015 рік, який додає до розмови кілька цікавих фрагментів:

Значні частини корпоративного світу задуму розглядають або починають використовувати Python (динамічний) замість Java (сувора статична)
Підприємство фронтенд світ бачить речі , як AngularJS v2, заснований на TypeScipt: а набране розширення Javascript.

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

Досить іронічно: мені цікаво, чи зустрінуться вони посередині, чи пройдуть повз один одного із звуковим бумом терміну, що проходить ...? ;)

— Корнель Массон
джерело

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

— Den

Динамічно набрані задні кінці використовуються на великих масштабах. Зокрема, Джанго користується великою популярністю в журналістиці і підтримує кінці для NYT, Guardian та Washington Post. Walmart працює на Node. Єдиний міф - це ідея, що не можна писати масштаб без статичних типів. І, витративши деякий час на роздуми над деякими катастрофами базової коди, що перебуває у нас, я думаю, що людям, яким це зручно, краще за це працювати, чи вони працюють зі статичними чи динамічними.

— Ерік Реппен

Дійсно, я мав би кращу команду Python на своєму великому проекті підприємства, а не поганий Java. Просто для уточнення своєї позиції: я подав вищезазначену відповідь як оцінку

— Корнел Массон

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

— Корнел Массон