Динамічні та статично типізовані мови для веб-сайтів [закрито]

Це твердження говорить про те, що статично набрані мови не ідеальні для веб-сайтів:

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

^{Джерело: http://www.infoq.com/interviews/kallen-scala-twitter}

Це правильно? Чому або чому ні?

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

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

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

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

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

І так, на мій досвід статично набрана, складена мова на презентаційному шарі може стати великою перешкодою. Зміст потрібно постійно змінювати, набагато частіше, ніж вимоги бізнесу. І зазвичай це потребує чітка команда ("розробники"). Зазвичай вони знають багато про HTML, JavaScript, веб-стандарти, CSS, але не так багато про такі серверні мови, як Java та C #. Вони також припускають, що будь-які зміни в шаблоні одразу доступні; вони не використовуються для компіляції та введення помилок. І вони праві: статично набрані мови дуже хороші для жорстких, складних вимог, таких як доступ до даних та ділових правил, але не такі гарні для розробки інтерфейсу.

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

Однак я також згоден, що Скала дещо інший. Будучи в той же час набагато менш багатослівним і значно виразнішим за Java, я вважаю, що його можна використовувати для розробки презентацій - тому, можливо, його можна успішно використовувати як мову шаблонів. І якщо його також можна поєднати з такою основою, як Play (яка збирає веб-сайт автоматично після кожної зміни), це може бути переможцем IMHO. Тим не менш, навіть Play обрала мову, схожу на Groovy (динамічну) шаблон, що не є хорошим знаком.

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

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

Я думаю, що текст (і більшість відповідей) змішують статично типові мови та надмірно багатослівні мови. Звичайно, перехрестя дуже велике (особливо якщо розглядати лише найпоширеніші мови); але є кілька цікавих прикладів невербальних, статично типових мов: Go, Haskell, Scala, Rust ...

Я закликаю вас прочитати сильний набір тексту Брюса Еккеля проти сильного тестування . Основним аргументом є те, що якість програмного забезпечення зводиться до тестування. Ви можете протестувати безліччю різних способів. Компілятори тестують деякі речі під час компіляції: спробуйте зберегти рядок у змінній int, і це, швидше за все, накине на вас. У динамічних мовах багато тестувань відбувається під час виконання. Зрештою, не має значення, коли відбувається тестування. Це просто має статися. Те, що ви отримуєте від некомпіляції на динамічних мовах, втрачає тестування під час виконання. Ви ретельно перевіряєте все, правда?

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

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

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

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

Я думаю, що автор цієї публікації не заглянув у сам Скалу. Хоча я погоджуюся, що Java та C # мають обмеження і трохи негнучкі до веб-розробки, Scala - це статично набрана мова, яка зовсім інша, ніж ви зазвичай думаєте, коли це чуєте. Scala дозволяє також вводити качок як безпечну для версії виправлення мавп (через неявні перетворення). Це робить бібліотеки програмування трохи складнішими, тому що вам доведеться думати про типи, але якщо ви просто використовуєте бібліотеку типу Lift, вона дуже схожа на динамічну мову, за винятком того, що компілятор повідомить вас про явні помилки, де ви просто не використовуєте її правильно. Особисто я думаю, що підйомна веб-рамка не повинна ховатися від рубіну на рейках або подібного. Подивіться приклади коду тут чи туті вирішуйте самі. Я розвиваюсь в ліфті вже досить довгий час, і ніколи не було ситуації, коли у мене була помилка типу, і хоч "А, чоловіче, якби це було динамічно, це працювало б" ... тому що якби це було динамічно, я б просто не сказав мені, що виникла помилка, поки вона не вийшла з ладу під час виконання.

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

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

Розширена нудна відповідь: Багато розробників наполягають на тому, що веб-сайт повинен бути виконаний з динамічною програмою. langr. але правда полягає в тому, що, врешті-решт, засоби веб-розробки, як правило, використовують або емулюють статичні мови.

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

Набрав Лагн. також допомагає використовувати IDE (ів), що вимагає багато перевірки типу.

(привезений вашим сусідом прогр. і дизайнером-компілятором ;-))

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