LINUX.ORG.RU

JavaScript надежность


2

10

Добрый вечер! Увидел тему про Linux на JS в разделе. Видел PDF.js и возникает у меня следующий вопрос. Сколько не пытался писать на JS (обычно пишу на Java и еще иногда приходится на C) всегда сталкивался с проблемой возникновения большого количества ошибок в рантайме из-за динамической типизации. Как людям удается создавать приложения такой сложности на JS?

У меня получалось быстро и относительно без багов написать только с GWT, но это по сути это Java. Но мне довелось читать много негативных отзывов по GWT, что дескать просто на JavaScript проще.

Почему проще? Как вы отлаживаете большие приложения на JS? Как обеспечиваете модульность и при этом производительность?

Речь сейчас именно о сложных скриптах, а не простых интерфейсиках с jQuery UI.

Может есть литература на тему. Вся что мне попадалась сводилась к примитиву, который нормальный специалист способен освоить за день.

Перемещено tazhate из development

★★

Последнее исправление: olegk (всего исправлений: 1)
Ответ на: комментарий от vertexua

Только у тебе ошибку укажет через 3 дня на продакшне после run. Просто именно тогда код дойдет до нужного места.

Зачем продакшн? Делаешь прогон юнит-тестов и все очепятки вылазят. А тесты и для статики писать надо, иначе ССЗБ. В конечном итоге никакого особого профита от статики в этом аспекте нет. Хотя, если кодер - криворукая обезьяна, которой каждую секунду IDE должен сопли подтирать, тогда динамика конечно злейшее зло, спору нет.

anonymous
()
Ответ на: комментарий от anonymous

Понятно дело, ълитарии ошибок типов не допускают. Извини

vertexua ★★★★★
()
Ответ на: комментарий от anonymous

Вообщем можешь не стараться переубедить меня что при потенциальной возможности ошибки в динамике выше чем в статике я хочу видеть 100% динамический код, чем 5% динамический

vertexua ★★★★★
()
Ответ на: комментарий от anonymous

А тесты и для статики писать надо

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

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

в hello world конечно пофиг, статика или динамика...

drBatty ★★
()
Ответ на: комментарий от drBatty

меньше писать надо

Почему меньше? Разве в статике не пишутся тесты на логику? В динамике пишутся те же самые тесты. Откуда берутся лишние?

anonymous
()
Ответ на: комментарий от anonymous

Почему меньше? Разве в статике не пишутся тесты на логику? В динамике пишутся те же самые тесты. Откуда берутся лишние?

тесты на логику разве будут проверять соответствие типов? Повторяю, если по логике нужно целое число 0, то можно скормить твоему коду практически любую строчку, с вероятностью 99.9% она сконвертится в 0. В тестах. А в продакшене - не сконвертится. Рано или поздно. Впрочем, если этот код поддерживать кому-то другому...

drBatty ★★
()
Ответ на: комментарий от drBatty

тесты на логику разве будут проверять соответствие типов?

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

Повторяю, если по логике нужно целое число 0, то можно скормить твоему коду практически любую строчку, с вероятностью 99.9% она сконвертится в 0.

Слабая типизация - говно, об этом никто не спорит. Речь идет о strong dynamic, очевидно.

anonymous
()
Ответ на: комментарий от anonymous

Соответствие типов вообще проверять не надо. Потому что оно и так упадет чуть менее чем всегда на логических.

Несоответствие типов в системе на динамически-типизированном языке может всплывать через годы (!) после написания проблемного кода. Просто потому что соответствующее сочетание данных вероятностно редко. Это может быть и не важно, но как только такой баг находится он становится уязвимостью, до тех пор пока не будет исправлен, что может быть совсем не легко - пытаться что-то локализовать в сложном, мутабельном, связном и динамическом control flow - то ещё занятие.

quasimoto ★★★★
()
Ответ на: комментарий от quasimoto

пытаться что-то локализовать в сложном, мутабельном, связном и динамическом control flow - то ещё занятие.

Ну так оно то еще занятие хоть с динамической системой типов, хоть со статической

И решение тут одно - избегать сложности, связности, мутабельного состояния... :)

Несоответствие типов в системе на динамически-типизированном языке может всплывать через годы (!) после написания проблемного кода.

Логические ошибки тоже. Вопрос лишь в том, каково соотношение в количестве этих ошибок.

anonymous
()
Ответ на: комментарий от anonymous

Ну так оно то еще занятие хоть с динамической системой типов, хоть со статической

Но суть в том, что это ошибка вида 1 + null. Которую трудно искать (уже по другим причинам, да). Поэтому лучше вообще не искать, то есть из

соотношение в количестве этих ошибок.

убрать все ошибки вида «тип A != тип B» (в т.ч. для параметрически полиморфных типов), «f : A -> ... реализована не для всех элементов типа A» и т.п. (насколько хватает желания «бодаться с тайпчекером»).

quasimoto ★★★★
()
Ответ на: комментарий от quasimoto

Но суть в том, что это ошибка вида 1 + null. Которую трудно искать

Ну если сложно, да связно, да с мутабельным состоянием - трудно, да. А если нет - то не трудно.

(насколько хватает желания «бодаться с тайпчекером»)

Так с ним все время приходится в статике. Вне зависимости от желания.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.