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

Это утверждение предполагает, что статически типизированные языки не идеальны для веб-сайтов:

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

^{Источник: http://www.infoq.com/interviews/kallen-scala-twitter}

Это верно? Почему или почему нет?

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

Кроме того, приведенный автором пример не имеет никакого смысла. Скорее всего, этот парень не знает, что полиморфизм может быть достигнут другими способами, нежели утка.

Есть ряд людей, которые утверждают, что динамические языки превосходят друг друга, но обычно это связано с отсутствием у них опыта работы с системами выразительных типов, которые, например, поддерживают структурные подтипы, алгебраические типы данных и функции первого порядка.

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

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

И, да, по моему опыту, статически типизированный, скомпилированный язык на уровне представления может быть большим препятствием. Содержание необходимо постоянно менять, гораздо чаще, чем бизнес-требования. И обычно это должно быть сделано отдельной командой ("front-end" разработчиками). Обычно они много знают о HTML, JavaScript, веб-стандартах, CSS, но не очень много знают о серверных языках, таких как Java и C #. Они также предполагают, что любые изменения в шаблоне доступны немедленно ; они не используются для компиляции и ввода ошибок. И они правы: статически типизированные языки очень хороши для сложных, сложных требований, таких как доступ к данным и бизнес-правила, но не так хороши для разработки интерфейса.

Фактически это одно из основных преимуществ использования специализированного и интерпретируемого языка шаблонов, такого как Velocity . Его простота в использовании, мощность и гибкость адекватны разработчикам уровня представления. И тогда ребята на стороне сервера могут свободно использовать серьезный, статически типизированный язык везде ...

Тем не менее, я также согласен, что Scala несколько отличается. В то же время, будучи гораздо менее многословным и гораздо более выразительным, чем Java, я считаю, что его можно использовать для разработки презентаций, поэтому, возможно, его можно успешно использовать в качестве языка шаблонов. И если он также может быть объединен с такой платформой, как Play (которая автоматически компилирует веб-сайт после каждого изменения), это может стать победителем IMHO. Тем не менее, даже Play выбрал Groovy-подобный (динамический) язык шаблонов, что не является хорошим знаком.

Подводя итог: проблема со Scala гораздо больше связана с тем, что она компилируется. Фактически, механизм определения типа заставляет вас почти забыть, что он также статически типизирован.

(И извините за мой английский. Дайте мне знать, если что-то не понятно, я постараюсь это исправить.)

Я думаю, что текст (и большинство ответов) смешивает статически типизированные языки и чрезмерно многословные языки. Конечно, пересечение очень большое (особенно если рассматривать только самые распространенные языки); но есть несколько интересных примеров не многословных, статически типизированных языков: Go, Haskell, Scala, Rust…

Я рекомендую вам прочитать « Сильное печатание против строгого тестирования» Брюса Экеля . Главный аргумент в том, что качество программного обеспечения сводится к тестированию. Вы можете тестировать разными способами. Компиляторы проверяют некоторые вещи во время компиляции: попробуйте сохранить строку в переменной int, и она, вероятно, будет лаять на вас. В динамических языках большая часть тестирования происходит во время выполнения. В конечном счете, не имеет значения, когда проводится тестирование. Это просто должно произойти. Сколько времени вы получаете, не компилируя в динамических языках, теряется тестирование во время выполнения. Вы все тщательно тестируете, верно?

Учитывая это, предпочтение для скомпилированных языков с жесткими системами типов по сравнению с динамическими языками - это просто предпочтение. Вроде как боксеры против трусов или стринги против французских трусиков. Там нет правильного или неправильного ответа. Носите их с правильным отношением, и это только удивительно.

Я согласен с этим в большинстве случаев, потому что, давайте посмотрим правде в глаза, когда вы имеете дело с клиентами на веб-платформе, гибкость является обязательным условием.

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

Поэтому, если у вас есть изменения в технологии слияния, я бы порекомендовал создать ядро ​​на статически типизированном языке (ядро не сильно меняется) и динамически использовать его для взаимодействия с пользователем.

Я думаю, что автор этого поста не смотрел сам Скала. Хотя я согласен с тем, что Java и C # имеют ограничения и немного негибки для веб-разработки, Scala - это язык со статической типизацией, который сильно отличается от того, о чем вы обычно думаете, когда слышите это. Scala позволяет печатать на утке так же, как безопасную версию исправлений обезьян (через неявные преобразования). Это делает библиотеки программирования немного более сложными, потому что вам придется думать о типах, но если вы просто используете библиотеку, такую ​​как Lift, это очень похоже на динамический язык, за исключением того, что компилятор сообщит вам об очевидных ошибках, когда вы просто не используете ее право. Я лично думаю, что веб-фреймворк лифта не должен прятаться от ruby ​​на рельсах или чем-то подобном. Посмотрите примеры кода здесь или здесьи решить для себя. Я довольно долго занимаюсь лифтом, и у меня никогда не было ситуации, когда у меня была ошибка типа, и хотя «А, боже, если бы это было динамично, это работало бы» ... потому что, если бы оно было динамическим, оно бы просто не сказало была ошибка, пока она не упала во время выполнения.

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

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

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

Я работал с PHP несколько раз, и рано или поздно нам пришлось добавить много кода, который проверяет типы данных, что подразумевается в статически типизированном прогре. яз.

Типизированный Lagn. также помогает использование IDE, которые требуют много проверки типов.

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

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