Архітектурні відмінності між динамічною та статичною мовами

Чи є якісь основні архітектурні відмінності при розробці програм, які будуть побудовані на статичних мовах (таких як C # або Java) та динамічних мовах (таких як Ruby або Python)?

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

Також, чи існують якісь динамічні моделі дизайну?

Розберемо кілька речей:

1. Інтерактивні сценарії та статичні мови не є взаємовиключними. У обох F # і Haskell є інтерфейси REPL.
2. Динамічні мови та висока продуктивність не є взаємовиключними, хоча деякі оптимізації є. У більшості браузерів JavaScript на сьогоднішній день працює досить проклято.
3. Навіть у динамічних мовах все одно потрібно документувати, запам’ятовувати та думати про типи.
4. Через зростаючу популярність виводу типу, багатьом статичним мовам вже не доводиться записувати типи дуже часто. У статичних мовах із сильним висновком типу компілятор визначає, які типи є у вашого коду, так що більшу частину часу, і повідомляє вам, чи коли-небудь ви робите щось, що порушує визначення типів. Що стосується синтаксису, то це забезпечує найкраще з обох світів.
5. OOP та динамічні мови не є взаємовиключними. PHP тепер підтримує класи та навіть успадкування.

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

1. Динамічні мови дозволяють отримати цікаві способи передачі даних по малому .
2. Статичні мови дозволяють зменшити кількість тестувань, які вам потрібно зробити, роблячи неможливі багато видів помилок.
3. У цьому ж ключі статичні мови дозволяють цікаві функції перевірки та функції автоматичного перетворення, як одиниці вимірювання у F # .
4. Вкрай, статичні мови дозволяють укладати кодові контракти та формальну перевірку, яка може документувати та вирівнювати, запобігаючи таким чином , як потенційні поділки за нулями, нескінченні цикли, нульові посилання, недійсні розміри списку чи індекси, помилки діапазону та інші логічно недійсні стану що ви можете визначити.
5. Враховуючи це ще більше, оптимізацію процесора можна зробити на основі цих статичних обмежень, що дає ще кращі показники.

Існує також один тип програми, який ніколи не можна було б зробити без статичного набору: Сингулярність , ОС без апаратних меж процесу. Він написаний невеликою кількістю C, деяким C # та діалектом C # під назвою Spec #, який підтримує кодові контракти.

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

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

Існує значна архітектурна різниця. Продуктивність.

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

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

Я ніколи не думав у цьому напрямку. Отож, коли з’явився Google, блог Пітера Норвіга був одним із найкращих хітів. Зазначається, що деякі моделі дизайну легше реалізувати в динамічних мовах, ніж традиційні об'єктно-орієнтовані мови, такі як C ++. Я думаю, що мають бути відмінності в дизайні / архітектурі, оскільки він зазначає, що в динамічних мовах реалізація простіша. Я спробую додати більше відповіді, коли я навчаюся далі.

Чи є якісь основні архітектурні відмінності при розробці програм, які будуть побудовані на статичних мовах (таких як C # або Java) та динамічних мовах (таких як Ruby або Python)?

Ні.

Трохи простіше написати фантазійні рамки для динамічних мов. Але це не є додатком.

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

Ні, насправді.

Ви можете писати хороші речі будь-якою доброю мовою.

Чи є якісь корисні функції, досяжні з одним типом, що не з іншим (в дизайні та архітектурі, звичайно)?

Ні.

Різниця полягає в тому, що динамічні мови - "писати, запускати, виправляти". Можна експериментувати і швидко виправити.

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

Крім цього, вони майже однакові за своїми можливостями.

Чи є якісь динамічні структури дизайну?

Можливо. Python eval()та execfile()функції - певним чином - вказують на динамічну функцію мови, яку важко (але далеко не неможливо) обробляти статичною мовою. Було б набагато більше рядків коду для складання та виконання коду в одному і тому ж просторі процесу.

Це не динамічна мова. Це просто простіше.