Потому что количество комментариев оставленных пользователем — это целое число. Их не может быть 2.5 или 0.349. Если в счётчике дискретных событий любая другая хрень приложение должно упасть и указать на причину ошибки, а не корчить из себя Deep Blue приводя, парся и генерируя случайные числа.
Проблема JS в том, что он а) не позволяет корректно моделировать такие объекты, б) навязывает эту проблему всему окружению.
Я уже около года потихоньку отсматриваю Introduction to Algorithms. Счётчик просмотра ведёт себя точно так же. На первой лекции около 11 000, на 13 (не ржать, я же говорю потихоньку отсматриваю) уже около 2 000. В общем с упорством и последовательностью у людей плохо.
Ок. С начала. Есть mongodb, милая такая база данных с одним маленьким дефектом, дефолтная её консоль реализована как JS интерпретатор.
В силу кривизны рук в одну из записей просачивается неверное целое значение, которое надо быстро исправить.
Я пишу просто скрипт, очень простой. Который однако выбивает всё приложение так как пишет вместо целого числа число с плавающей точкой.
Моя позиция:
1. 1 — должно быть целым числом. В любом случае, всегда, это базовое условие для существования добра во вселенной.
2. Если это невозможно из-за совместимости со стандартом 15 летней давности должна быть возможность оперировать с целыми числами хотя бы хреново с конструкциями вроде Integer(2)+Integer(5).
3. Интерпретатор должен предупреждать что собрался проинтерпретировать ввод пользователя чрез жопу.
Всё, кроме «нативной асинхронной модели» есть в Python, Ruby(хотя я его тоже недолюбливаю), многочисленных LISP'ах, Lua.
Что такое «нативная асинхронная модель» я не знаю :(
Реальный пример: при миграции БД произошла ошибка и в один _очень важный счётчик_ записалося 0 вместо 1. Я пишу db.records.update( {_id: <bla-bla-bla>}, {$set: {my_counter: 1}}). Что бы Вы думали? Правильно! Всё нах поломалось!
Почему? Потому что в «мощный объектно-ориентированный язык» не в курсе про целые числа. Ваще. Их нельзя создать, ими нельзя оперировать, их по-человечески нельзя даже отправить наружу.
Теперь все служебные скрипты я пишу на Python.
В C++ можно посмотреть ассемблер на выходе, подумать что в нём не нравиться и сделать так чтобы нравилось. На нём можно при необходимости выжимать из железок абсолютно всё. Я не фан оптимизации и не пишу на C++, но я могу понять людей которые его терпят за такую возможность. А что такого предлагает JS что в нём терпят многие сотни возможностей отстрелить себе ногу я не понимаю.
Господибожемой. Да при чём тут производительность и прототипы. Почитайте wtfjs и подумайте сколько за каждым из постов убитых человекочасов. А потом (только без соплей про обретённую в замен мощь и гибкость) переведите в деньги.
> Если вы вызываете функцию с невалидными параметрами — это одно. Это не исключительная ситуация, это исключительно кривые руки.
Да ни при чём тут руки. Интерфейсы в живых программа меняются. Валидное вчера может не быть таковым сегодня. И стать снова валидным завтра. В большом проекте вызов функции из соседнего модуля не многим надёжнее запроса по сети к БД.
> хотелось бы услышать ваши комментарии по данному методу оценки знаний
Вспухший от безделья министр решил освоить ещё пару миллиардов. Не обращайте внимания, на местах ничего не изменится :)
Потому что количество комментариев оставленных пользователем — это целое число. Их не может быть 2.5 или 0.349. Если в счётчике дискретных событий любая другая хрень приложение должно упасть и указать на причину ошибки, а не корчить из себя Deep Blue приводя, парся и генерируя случайные числа.
Проблема JS в том, что он а) не позволяет корректно моделировать такие объекты, б) навязывает эту проблему всему окружению.
PS Я что одни связался с DB классом?
В силу кривизны рук в одну из записей просачивается неверное целое значение, которое надо быстро исправить.
Я пишу просто скрипт, очень простой. Который однако выбивает всё приложение так как пишет вместо целого числа число с плавающей точкой.
Моя позиция:
1. 1 — должно быть целым числом. В любом случае, всегда, это базовое условие для существования добра во вселенной.
2. Если это невозможно из-за совместимости со стандартом 15 летней давности должна быть возможность оперировать с целыми числами хотя бы хреново с конструкциями вроде Integer(2)+Integer(5).
3. Интерпретатор должен предупреждать что собрался проинтерпретировать ввод пользователя чрез жопу.
Что такое «нативная асинхронная модель» я не знаю :(
Почему? Потому что в «мощный объектно-ориентированный язык» не в курсе про целые числа. Ваще. Их нельзя создать, ими нельзя оперировать, их по-человечески нельзя даже отправить наружу.
Теперь все служебные скрипты я пишу на Python.
Неправда. На вопросы после доклада отвечал тоже я, а никакой не форс-мажор.
Да ни при чём тут руки. Интерфейсы в живых программа меняются. Валидное вчера может не быть таковым сегодня. И стать снова валидным завтра. В большом проекте вызов функции из соседнего модуля не многим надёжнее запроса по сети к БД.
Вспухший от безделья министр решил освоить ещё пару миллиардов. Не обращайте внимания, на местах ничего не изменится :)