JavaScript надежность

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

Люблю контрпримеры «запили мне фичу вот тут где надо динамика». Ради бога, напишу апкастов и паттерн матчинга - будет. Это будет ничуть не менее по быдлокодерски как любая строчка на динамике. И это будет динамика. В нормальном преимущественно статическом ЯП. Я не типозадрот.

да. Over9000 юниттестов пишешь и прогоняешь, во ВСЕХ случаях.

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

А ИСПОЛЬЗОВАТЬ ты потом эту функцию как будешь? тебе придется потом при каждом вызове этой функции кастить результат.

Каждая ошибка где IDE подчернуло «вы подставляете Яблоко вместо Велосипед» будет _возможно_ отловлена после того как я запущу здоровенную систему. Возможно не будет. Возможно будет найдена завтра

Компилятор радостно пожрёт «НЁХ» вместо нуля

s/компилятор/интерпретатор/

Потому что примерно тогда вырабатывался стандарт Common Lisp (CL).

Нихуя там у CL в стандарте не предусмотрено, потому что символ не содержит информации о своих биндингах. Вот в нормальных лиспах, типа Racket, в этим все хорошо.

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

Это в каком смысле?

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

http://www.cis.upenn.edu/~bcpierce/papers/index.shtml#Dynamic%20Types

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

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

На практике такого не наблюдается пока что. Как, например, добавить «внешний чекер» CL? Без написания стороннего codewalkerа, разумеется. Даже если смириться с тем, что типизированные функции должны стать макросами - контроля за порядком их раскрытия нет, так что ничего не получится.

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

Опять же, на практике рантайм и так поддерживает tagging и top type можно встретить где угодно (Java, C#, F#, Haskell, Scala, эм boost::any?).

А как я могу пользоваться объектами о которых ничего не знаю. Могу их передавать дальше или забывать из своих структур. И будет тип Object раз уж не повезло. А когда нужно что-то сделать, то да, паттернматчинг. Всяко лучше чем если будет этот Object всегда и я через 100 вызовов методов вызову метод .foo и буду молиться что он там есть.

Ты учился еще до того времени, как помер Брежнев? Потому что примерно тогда вырабатывался стандарт Common Lisp (CL).

типа того. Но этот ваш лисп, извиняй, не осилил. Я вообще его смысла _не понял_, несмотря на знакомых фанатов с горящими глазами...

Каждая ошибка где IDE подчернуло «вы подставляете Яблоко вместо Велосипед» будет _возможно_ отловлена после того как я запущу здоровенную систему. Возможно не будет. Возможно будет найдена завтра

1. Во-первых, нам на практике нахуй не надо быть уверенным, что все отловлено. Достаточно быть уверенным, что ошибки нет с некоей достаточно значимой вероятностью Х (если только мы не пишем софт для ядерных реакторов).

2. Чтобы получать именно ГАРАНТИИ надо заниматься тем самым типодрочерством, которое ты не любишь. Как только ты начинаешь в своей программе кастить туда-сюда топы, так сразу точно как в динамике гарантий отлова ошибки уже нет и яблоко с велосипедом ты ВОЗМОЖНО нигде не перепутал.

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

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

Что мешает мне получить гарантии с нормальными типами в классе А, но при этом кастить в классе В и знать что там могут быть ошибки? Не повод юзать динамику и знать что ошибки типов могут быть везде

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

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

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

в статике в 95% случаев у меня не скомпиллится, без всяких тестов.

Это в каком смысле?

В том, что чек зависимых типов алгоритмически неразрешим (т.к. эквивалентен мат. доказательству).

http://www.cis.upenn.edu/~bcpierce/papers/index.shtml#Dynamic Types

То есть никак несовместимо.

На практике такого не наблюдается пока что.

почему нет? Вполне наблюдается.

Как, например, добавить «внешний чекер» CL?

Так же, как написан внутренний тайпчекер SBCL?

Без написания стороннего codewalkerа, разумеется.

А почему без? И почему нельзя использовать уже существующий?

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

Непонял, что? Какие типизированные ф-и? Откуда они взялись и зачем их делать макросами?

Опять же, на практике рантайм и так поддерживает tagging и top type можно встретить где угодно (Java, C#, F#, Haskell, Scala, эм boost::any?).

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

в статике в 95% случаев у меня не скомпиллится, без всяких тестов.

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

А ИСПОЛЬЗОВАТЬ ты потом эту функцию как будешь? тебе придется потом при каждом вызове этой функции кастить результат.

опять таки в 95% случаев я ЗНАЮ, что у меня функция выдаёт ЦЕЛОЕ, и ничего кастовать мне в принципе не нужно. А если не целое - это ошибка, и у меня тупо не соберёться. А у тебя даже будет работать, и тебе ещё и проверять надо при ВСЕХ допустимых значениях, правильно или нет. Если выдаёт строку, которая сама кастуется в 0, это не значит, что работа правильная, даже если по логике должно быть целое 0. В продакшене будет 666, которое скастуется в (int)666, и всё рухнет.

хотя никаких реальных аргументов за это нет,

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

Совсем уж тупые компиляторы будут компилировать так долго как будут работать некоторые программы до ошибки

Что мешает мне получить гарантии с нормальными типами в классе А, но при этом кастить в классе В и знать что там могут быть ошибки?

Если ты используешь ф-ю класса В, которая внутри возвращает то, что ты кастил, то тебе придется кастить выход этой ф-и используя ее в ф-и класса А.

Каждая ошибка где IDE подчернуло «вы подставляете Яблоко вместо Велосипед»

в PHP строки кастуются в целое сами, и это НЕ ОШИБКА, даже с т.з. IDE. Как ты это отловишь?

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

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

А откуда взялась ошибка на проде, если я ее нашел на первом же тесте?

Достаточно быть уверенным, что ошибки нет с некоей достаточно значимой вероятностью Х

убил-бы...

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

Не понял вопроса. Но ведь PHP говно, почему мы его обсуждаем?

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

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

кроме того, если уж использовать твою методу (без «типодрочерства»), то прикрутив внешний чекер к динамическому ЯП мы получим ТОЧНО такую же вероятность (очевидных факт). Только сохраним ряд профитов - ну начиная с того, что наш чекер может быть чекером произвольной строгости, заканчивая значительно более удобным использованием динамических аспектов языка.

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

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

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

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

убил-бы...

За что? На практике мы в любом случае не можем сделать Х = 1, даже если строго математически доказали корректность нашей программы. Так что вопрос лишь в значении Х.

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

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

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

А у тебя даже будет работать, и тебе ещё и проверять надо при ВСЕХ допустимых значениях, правильно или нет.

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

Только на практике такими чекерами никто не пользуется.

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

Нет, все-таки нужны и все страдают от динамичности кроме самых упоротых. Зачем страдать тогда?

Как показывает практика, единственные, кто страдает от динамичности - это статикодебилы, которые на динамике не пишут.

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

статикодебилы

ну все понятно )

а у вас покрытие тестами 100%? Поздравляю.

а у вас покрытие тестами 100%? Поздравляю.

А каким образом можно написать код с не 100% покрытием? То есть это выходит надо написать ф-ю и ниразу ее не запустить? Или что? или как?

А у меня на тестах упадет. Какая мне разница в результате чего я нашел ошибку - в результате компиляции или в результате прогона тестов?

для компиляции не нужно ПИСАТЬ тесты. Очевидно же!

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

компиляция ГАРАНТИРУЕТ отсутствие ошибок определённого типа. К примеру

int a[10];
a = 17;

просто НЕ СОБЕРЁТСЯ.

ошибка: incompatible types when assigning to type «int[10]» from type «int»

и голову не надо ломать. А вот какой тест ты напишешь для php? быдлокод

$a = array();
$a = 17;

Но я указал круг задач динамических ЯП. Там просто не нужна надежность.

А можно лучше перечислить круг задач, в которых надежность нужна и именно по этой причине (а не по причине скорости, допустим) там динамические ЯП не используются?

Но ведь PHP говно, почему мы его обсуждаем?

потому-что это C++ без статической типизации. Там «типы» как говно - что хочешь, то и лепи. Вот только как не лепи, получается говно.

Любое серьезное приложение, не веб-магазины.

Ну это проблемы С++

То есть это выходит надо написать ф-ю и ниразу ее не запустить?

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

для компиляции не нужно ПИСАТЬ тесты. Очевидно же!

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

компиляция ГАРАНТИРУЕТ отсутствие ошибок определённого типа.

Да нет, она ничего не гарантирует, она лишь говорит, что с вероятностью Х ошибки такого класса нет. Тесты тоже говорят, что с вероятностью Y ошибки такого класса нет. Ну нам понятно, что Х > Y, и если бы эта разница была бесплатной - то и вопроса бы никакого не стояло, даже если мала (а она и есть мала). Но раз уж она платна, то встает вопрос - а стоит ли овчинка выделки? Насколько велик этот малый процент и стоит ли за него платить? Кроме того тут еще надо учесть цену ошибок (сложность отлова ошибок данного класса и их исправления), соотношения с ошибками, которые и типами не ловятся и их цену.

Вы только что признали, что далее линейного flow функций ваше приложение не продвинулось.

Это ложь. Зачем же вы так нагло врете?

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

это уже проблемы железячников. Пусть добавляют CRC, тройное резервирование, что хотят. Наш код надёжен на 100%. Кривое железо - не моя проблема.

Любое серьезное приложение, не веб-магазины.

То есть из ваших слов следует, что серьезных приложений, написанных на динамических ЯП, просто не существует в природе, так?

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

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

это уже проблемы железячников. Пусть добавляют CRC, тройное резервирование, что хотят. Наш код надёжен на 100%. Кривое железо - не моя проблема.

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

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