JavaScript надежность

подписался на топик. Та же ситуация и тоже интересно.

Аналогично. Ждем комментариев от профи в этой области :)

проблемой возникновения большого количества ошибок в рантайме из-за динамической типизации

Так толсто, что даже тонко. Динамическая типизация не избавляет от необходимости продумывать архитектуру приложения. Или вы имели в виду динамические области видимости?

Используйте unit тесты (jasmine, jsunit)

Разделяйте код на модули при помощи, например, require.js.

MVC фрэймворки помогают иметь чистую архитектуру.

jQuery создает слой для кросс-браузерности.

Ну и современные браузеры и скорость интернет соединения позволяет все это иметь (если результат минимизировать в один единственный файл при помощи того же оптимизатора от гугла)

Object.prototype.toString = function(){return "shoot in the foot!"}; 
function Foot() {}; 
Foot.prototype = {};
f = new Foot(); 

Если в коде есть такое то проблема явно не в JS.

Как людям удается создавать приложения такой сложности на JS?

Костылями подпирают. Поэтому и тормозит так.

Как вы отлаживаете большие приложения на JS?

F12 в огнелисе.

Как обеспечиваете модульность и при этом производительность?

Выбирать надо.

Так толсто, что даже тонко.

По поводу типизации и ошибок - не я первый заметил проблему. Об этом и GOOGLE пишет и многие другие.

Как не продумывай архитектуру, программу пишет человек, а он грешен, т.е. ошибается. К примеру, написал foo.pirnt вместо foo.print. В Java при сборке получишь ошибку, а в Javascript только тогда, когда исполнение дойдет до нужной ветви, а ведь может дойти в самый неожиданный момент.

Пример я заведомо привел примитивный для иллюстрации. Чем больше приложение, тем больше этих проблем.

К примеру, написал foo.pirnt вместо foo.print

Дык, чего пенять на интерпретатор-то? Он на то и интерпретатор, чтобы код строчка за строчкой исполнять. И тормозить не по-детски.

написал foo.pirnt вместо foo.print

Intellij IDEA вам в помощь (aka WebStorm)

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

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

Для всего остального приглашаю использовать unit tests.

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

К примеру, написал foo.pirnt вместо foo.print. В Java при сборке получишь ошибку, а в Javascript только тогда, когда исполнение дойдет до нужной ветви, а ведь может дойти в самый неожиданный момент.

Это проблема JavaScript, а не динамически типизированных языков.

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

не думаю, в том же python также. думаю. это проблема всех динамических языков

думаю. это проблема всех динамических языков

Это проблема реализаций, а не языков. Некоторые реализации CL, например, такое ловят.

WebStorm попробовал - действительно вещь хорошая.

Например это?

// В одном файле
Object.prototype.pirntf = function(){

};
// В другом
Foo = function(){};

var foo = new Foo();
foo.pirntf(); // тут omnicompletion мне подсказал

Подчеркнуло только зеленым цветом слово pirntf («опечатка!»).

Когда убрал линию про прототип, в другом файле подчеркнуло что «функция pirntf не сущевствует».

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

jslint и им подобные помогают избежать потенциальные ошибки на этапе написания кода

Думаю, он имел в виду не «динамических», а «интерпретируемых».

в любом языке с динамической типизацией без юнит-тестов вообще никак, и JS - не исключение

интерпретируемых

Интерпретируется же байткод (свой, JVM, машкод), а на стадии трансляции в него (*.py -> *.pyc, например, или прямо в REPL) вполне можно проверять всё, что душе угодно (я не знаю как CPython себя тут ведёт).

А вот нефиг на языке, предназначенном для валидации данных в веб-формочках, писать «приложения».

Ну можно брать имя поля из вызова нативного кода рандомной dll через ctypes, как это проверить?

как это проверить?

Если сущность простая и определенная, то молчим, если простая и неопределённая, то пишем warning, если сложная, то ничего не можем сделать, поэтому молчим. SBCL, например, молчит про (slot-value obj 'bad-slot), но ловит (class-bad-slot obj) на правах неопределённой функции.

И ещё он ловит (pirnt foo) и (bad-slot foo) для generic и accessor (который тоже generic) соответственно.

Думаю, он имел в виду не «динамических», а «интерпретируемых».

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

А как происходит взаимодействие JS с Java back-end'ом? Т.е как сервлет может отдать данные JS коду? И как это хозяйство вообще пишется

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

а вообще жс мой самый любимый язык, не смотря на все его недостатки.

1. Умение писать код.

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

3. Юнит-тесты, безусловно.

Из браузера сделали кроссплатформенную (причём настолько кроссплатформенную, что даже джава тихо курит в сторонке) базу для клиент-серверных приложений, к тому же с хорошей системой безопасности и реальной конкуренцией. Альтернатив JavaScript-у просто нет, если хочется этим пользоваться.

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

В HTML5 валидировать данные по регекспу можно и без js.

REST сервисы, сервлет отправляет данные в формате JSON, клиент сайд их парсит нативно и что-то с ними делает

TDD лучше чем любая типизация.

Это проблема JavaScript, а не динамически типизированных языков.

это проблема любого интерпретатора.

А вот нефиг на языке, предназначенном для валидации данных в веб-формочках, писать «приложения».

в php та же проблема.

Видел процесс разработки на JS у людей, которые на нем работают. Да, ты просто кушаешь кактус. No miracle

А как интерпретатор связан с динамически типизированными языками? Есть такие компилируемые языки.

Это проблема динамической типизации на 100%. А вдруг там будет метод pirnt?

Выше уже ответили, что в некоторых динамически типизированных языках опечатка pirnt отлавливается на этапе компиляции.

А как интерпретатор связан с динамически типизированными языками?

а в том-то и дело, что никак. Пролистай повыше

Просто по факту что pirnt нет вообще нигде в коде? Хм, может быть. Но это частный случай не валидирующий аргументов. Также евангелисты динамической типизации хвалят свои ЯП за возможность парсинга имени метода и лишь потом выполнении кода исходя лишь из названия (findByNameAndLastName). Тут быть увы никак.

Выше уже ответили, что в некоторых динамически типизированных языках опечатка pirnt отлавливается на этапе компиляции.

ну в статической типизации ошибка тем более будет отловлена при компиляции, даже если есть метод pirnt, но у него неверная сигнатура (несоответствие типа). А вот при динамической типизации всё пролетит «нормально».

И чего ты хотел этим сказать?

ты не мог бы немного раскрыть тему?

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

Если упомянуть что JS на практике неразрывно связан с CSS, то тут ядерный ад. В разных браузерах все расплывается, не появляется, events срабатывают по разному в разное время, атрибуты игнорируются, приходится дебажить невменяемые ошибки jQuery. Этому можно научиться, но по правде это просто приобретение привычки к вкусу кактуса.

Это проблема JavaScript, а не динамически типизированных языков.

это проблема любого интерпретатора.

Это не так. Такая же проверка на опечатки возможна и для интерпретатора. Чем он собственно отличается от компилятора? В общем, кто-то ошибся выше, и не следует за ним повторять.

Хотя, пожалуй, здесь ошибка появится только в run-time.

Если при старте, то хорошо, а если внутри if через 2 дня, то плохо