JavaScript надежность

Ничего, там, где надо, есть удаленный REPL.

) Уже упало как бы. Уже юзеры напуганы и плачут в туалете

Если говорить серьезно, то статическая типизация не спасает полностью от ошибок типизации. В статике тоже может все упасть из-за неправильных типов. Даже в Haskell есть извороты с Data.Dynamic. Так что, пока сплошные мифы про статику и динамику :)

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

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

Необязательно использовать рефлексию. По-моему с генериками можно так извратиться.

Это единственный способ передачи данных от сервлета к фронтенду? Можно ли это реализовать через Ajax?

аджакс - это тупо транспорт. По нему можно передавать что угодно, хоть бинарные данные. Просто JSON в качестве формата используют из-за скорости енкода/декода и все. Ну и те, кто ниасилил валидацию xml с помощью xsd

Не спасает на 100% не аргумент чтобы говорить что, то что спасает на 99% - не нужно.

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

Про 99% - явное преувеличение. От силы процентов 70% гарантии дает статика.

Тогда что даст RESTful?

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

Как раз 1% или 30% проблем зависит от количества «не осилил типы, написал Object/AnyRef»

Да ошибки типов - обычно довольно техническая вещь (если не Haskell, конечно). Бывают ошибки и посерьезнее.

Но честно говоря все форсят юнит тесты для банальной проверки типов.

Конечно, нет.

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

И с анальными ограничениями. Проблема статики ведь не в том, что статика находит ошибки, а в том, что статика находит ошибки там, где их нет.

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

я в курсе. Всё равно этого недостаточно для надёжного программирования. ИМХО.

Если есть посерьезнее, то зачем при этом терпеть ошибки попроще

Не спасает на 100% не аргумент чтобы говорить что, то что спасает на 99% - не нужно.

Так она и не спасает на 99%. Обычно говорят, что-де статика покрывает значительную часть ошибок - но нам не надо покрывать значительную часть ошибок. Надо покрывать значительную часть _трудноуловимых_ ошибок. Потому что другие ошибки мы легко найдем и без статики при первом же запуске программы (и не надо никаких специальных тестов на типы - достаточно обычных тестов на логику, тех, которые и в случае статики будут). Но ведь статика как раз и отлавливает эти самые ошибки, которые найдутся при первом же запуске, а те ошибки, которые было бы интересно ловить именно статикой - статика не ловит, или ловит слишком высокой ценой (с какими-нибудь зависимыми типами). Это не говоря уж о том, что никакая статика не отловит ошибку, возникновения которой бы программист не ожидал. Это следует просто из самой сути статики.

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

И с анальными ограничениями. Проблема статики ведь не в том, что статика находит ошибки, а в том, что статика находит ошибки там, где их нет.

Это не проблема статики, это проблема убогих систем типов.

Если есть посерьезнее, то зачем при этом терпеть ошибки попроще

А зачем их терпеть, если можно найти и исправить?

Теперь это тред истеричек, паникующих при виде ошибки.

Это не проблема статики, это проблема убогих систем типов.

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

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

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

Проверка на опечатки была либо в рантайме для интерпретатора, либо при компиляции для компилятора. И - всё. Это только в последние ~10 лет появились гламурные IDE, и даже VIM наконец научился искать ошибки, и даже в русских словах...

Зачем ошибки попроще искать? Их найдет компилятор

Проверка на опечатки была либо в рантайме для интерпретатора, либо при компиляции для компилятора. И - всё.

«20 километров до школы, и обе стороны - в гору» (ц)

Слово «анальные» лишь в снах-кошмарах некоторых программирующих

Ничего, там, где надо, есть удаленный REPL.

ЩИТО? Read-eval-print-loop? В продакшене? Мну-бы за яйца подвесили...

Значит типы неправильные.

Ну так «правильных» типов не существует - это математически доказанный факт. А нахрена тогда они нужны, если они заведомо неправильны?

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

И как потом эту говенную ф-ю на магическом типе потом совмещать с обычной?

Но почти весь код лучше типизировать и для человека и для машины

Да нет, не лучше.

Опять же, вот есть у динамики другое преимущество - если у нас есть динамический ЯП, то сделать его статическим легко и просто - нам надо лишь написать внешний чекер и все. Если же у нас есть статический яп, то для добавления динамики следует переписать рантайм языка и коренным образом переработать его дизайн - естественно, полностью потеряв обратную совместимость с уже существующим кодом. Другими словами, динамика - это такая усовершенствованная, гибкая статика. К статическому ЯП система типов прибита, динамический ЯП позволяет использовать для своего анализа целый класс различный систем типов (выбирай - не хочу, можешь хоть каждую ф-ю чекать своим чекером) и все будет корректно, надежно и удобно.

Ну так «правильных» типов не существует - это математически доказанный факт. А нахрена тогда они нужны, если они заведомо неправильны?

Потому что на практике все отлично.

И как потом эту говенную ф-ю на магическом типе потом совмещать с обычной?

Как везде и совмещают. Например можно просто top класс написать. А потом где надо применить паттерн-матчинг. Я так и делают. И это мое родное ССЗБ, которое все-таки нормально работает. Но зачем ССЗБ делать в каждой строчке?

Если говорить серьезно, то статическая типизация не спасает полностью от ошибок типизации. В статике тоже может все упасть из-за неправильных типов. Даже в Haskell есть извороты с Data.Dynamic. Так что, пока сплошные мифы про статику и динамику :)

а в C++ есть class -> void* -> class. И _любой_ кодер посветил не одну ночь на исправление этого своего быдлокода. И что?

если у нас есть динамический ЯП, то сделать его статическим легко и просто

Ну так сделай легко и просто внешний чекер к питону.

Про 99% - явное преувеличение. От силы процентов 70% гарантии дает статика.

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

Зачем ошибки попроще искать? Их найдет компилятор

А, видимо возникла непонятка. Ты говоришь компилятору, интерпретатору, иде, чему угодно - «найди мне простые ошибки» - и он их находит, это и подразумевалось под поиском. Разница между динамикой и статикой лишь в одном: в статике ты это говоришь, нажимая кнопочку «compile», а в динамике - кнопочку «run». Ну и в динамике тебе более корректно укажет место ошибки - то есть исправить проще. И кроме того в динамике ты можешь исправить ошибку и все, а в статике (в случае «неправильных» типов, а они всегда неправильные) тебе, возможно, придется ебстись, доказывая чекеру, что ты не верблюд.

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

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

Потому что на практике все отлично.

В какой вселенной? По моей информации с зависимыми типами на практике все как раз далеко не отлично. Более конкретно - нахуй они не нужны в том виде, в котором существуют на данный момент.

Как везде и совмещают. Например можно просто top класс написать.

И какие операции ты сможешь выполнять с объектом топ-класса? Или ты предлагаешь разрешить апкасты? Ну такая «система типов» дает ровно столько же гарантий, как и динамика, так нахуя оно тогда нужно?

Тем более лучше уж твердо знать, что никаких гарантий нет, чем верить в то, что они «почти есть».

Ну так сделай легко и просто внешний чекер к питону.

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

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

Так приведи список.

По моей информации с зависимыми типами на практике все как раз далеко не отлично. Более конкретно - нахуй они не нужны в том виде, в котором существуют на данный момент

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

Или ты предлагаешь разрешить апкасты? Ну такая «система типов» дает ровно столько же гарантий, как и динамика, так нахуя оно тогда нужно? Тем более лучше уж твердо знать, что никаких гарантий нет, чем верить в то, что они «почти есть».

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

так нахуя оно тогда нужно?

Потом что прекрасно работает на практике без типозадротов. Берешь апкаст с паттерн матчингом с принудительной проверкой всех вариантов и все хорошо

Другими словами, динамика - это такая усовершенствованная, гибкая статика.

во-во: «php это такой усовершенствованный и гибкий C++!»

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

Так в нормальной динамике ф-я еще до того как написана запускается на _логических_ тестах. Так что если ф-я написана, то такой ситуации, что код до чего-то «не дошел» просто не бывает. Вообще не бывает. Естественно, если код никогда не запускать, то тут нужны какие-то альтернативные средства контроля, но нахуя лепить костыли, если можно нажать «run»?

во-во: «php это такой усовершенствованный и гибкий C++!»

Конечно. Потому что что угодно - это такой усовершенствованный и гибкий с++.

https://www.google.ru/search?q=python static analyzis&oq=python static an...

Тут очень сильно просится «Чего только люди не придумают, чтобы ...»

Не знаю о чем вы говорите. Работает почти всегда. Кроме тех случаев когда тип действительно неизвестен.

Что работает почти всегда? flatten мне запили на статике (который лисповый flatten, то есть из списка списков любой вложенности делает обычный список).

Прости, но это как раз то типодрочерство о котором я говорил. Никогда нет гарантий.

Нахуя нужна тогда система типов вообще? Я думал, именно за тем, что она дает гарантии. А если не дает - то какой смысл в ее существовании?

Потом что прекрасно работает на практике без типозадротов. Берешь апкаст с паттерн матчингом с принудительной проверкой всех вариантов и все хорошо

На практике оно и без типов работает точно так же хорошо.

Тут очень сильно просится «Чего только люди не придумают, чтобы ...»

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

Я знал, что ты скажешь это.

Разница между динамикой и статикой лишь в одном: в статике ты это говоришь, нажимая кнопочку «compile», а в динамике - кнопочку «run»

да. Over9000 юниттестов пишешь и прогоняешь, во ВСЕХ случаях. и это только для того, что-бы найти где ты перепутал i с j. В 99% компилятор пошлёт нафиг быдлокод, где ты например использовал строку вместо целого, сославшись на то, что у него дескать «нет такого конструктора». Компилятор радостно пожрёт «НЁХ» вместо нуля, дойдя до него в тесте без всяких проблем. И правильно сделает. В продакшене рухнет очевидно...

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

Ты учился еще до того времени, как помер Брежнев? Потому что примерно тогда вырабатывался стандарт Common Lisp (CL). Здесь умолчим, что сам процесс стандартизации занял больше десяти лет. Ну так вот, что в интерпретируемой, что в компилируемой реализации CL такой отлов опечаток предусмотрен (Lisp-N как никак).