Корень суммы составляющих его цифр, т.е. корень из 27, иррационален. Также, "... умножении составляющих его цифр на ..." описывает умножение массива на число, т.е. а итоге одно число не выходит.
Подскажите, пожалуйста, почему ответчик должен доказывать дату? Разве по умолчанию ответчик не считается правым, и не должен истец доказывать, что ответчик нарушил что-то?
Отличие в приведении типов. В переменную типа (num, String) можно присвоить тип (int, String), с классами так не сработает. Нужно было бы кучу классов добавлять: Tuple2<A, B>, Tuple3<A, B, C>, ..., вот эти записи по сути оно и есть, только с синтаксическим сахаром.
Мне бы больше хотелось приложение основанное на расширенной реальности (смартфон, очки?), которое бы помогало найти носок в куче парный к тому, что я держу в руках. Было бы вдвойне офигенно, если б оно мне ещё сразу говорило, надо ли мне выворачивать его. Ради такого я бы заплатил, и не поленился бы сфоткать мои 100 носков в анфас и в профиль однажды.
Тип test здесь выводится пустой строкой. Таким образом, в обоих примерах явное приведение типов внутри функций, предлагаемое вами, содержит ошибку и является источником unsoundness (не знаю как по-русски, "противоречивость" может быть?).
Похоже, что в утверждении
Данный подход опасен, но при осторожном использовании может быть очень мощным средством
нужен особый акцент на слове "осторожном".
Я бы в своем коде не стал вообще использовать перепресвоение типа без рантайм-проверки, за одним исключением - если есть доказательство, что переприсвоение корректно. В данном случае (split и concat) даже с рантайм проверкой было бы грустно, т. к. программист не ожидает, что изменение кода подобное примерам из предыдущего комментария потенциально может ввести райнайм ошибку, и может сделать коммит не проверив.
let test = split('21,3', ',')';
let first = test[0];
Тип first выводится равным `21`.
Однако, вот так плохо:
let t = '21,3';
let test = split(t, ',')
let first = test[0];
Тип test выводится пустым массивом, и третья строчка посвечивается ошибкой. Неожиданно, кажется что split должна возвращать string[] если на вход подана string.
Скажите, вот вы не пишете тела функций, но всё-таки, что туда можно написать? Вот, к примеру, для последней функции split, компилятор примет тело "str.split(sep);"? А какие ещё тела он примет для такого возвращаемого типа? Я что-то плохо представляю как нечто такое можно верифицировать.
Сетка из 60 сайтов софтовой тематики. Использование AI для контента. Приятно читать статью, надеюсь остальные, кто этим всем занимается, тоже теряют деньги. Плюсик вам.
Как понять, что перед вами плохой разработчик. Не стопроцентный способ, но сигнал: если он вывел правила подобные описанным в статье, то собственно вот, вы поняли. Либо у него так себе с анализом, и он нашел подтверждения этим правилам, когда вообще-то их нет, либо он оценивает других разработчиков по параметрам ортогональным разработке.
Разумеется я про суждение о силе программистами по его речи. Остальное в статье - капитанство.
"Все терпилы, один я самурай".
Корень суммы составляющих его цифр, т.е. корень из 27, иррационален. Также, "... умножении составляющих его цифр на ..." описывает умножение массива на число, т.е. а итоге одно число не выходит.
Мда, более опытный товарищ не знает про text-align. Бывает.
Прочитав заголовок, ожидал, что статья про гитхаб, а оказалась про митапы в фудкорте.
Подскажите, пожалуйста, почему ответчик должен доказывать дату? Разве по умолчанию ответчик не считается правым, и не должен истец доказывать, что ответчик нарушил что-то?
А почему нет? Если лицензия составлена так, что оплаты достаточно на любом звене включения библиотеки в цепочке продуктов, то в чем проблема?
Отличие в приведении типов. В переменную типа (num, String) можно присвоить тип (int, String), с классами так не сработает. Нужно было бы кучу классов добавлять: Tuple2<A, B>, Tuple3<A, B, C>, ..., вот эти записи по сути оно и есть, только с синтаксическим сахаром.
Деструктиризация есть?
Знаю программиста без технического бекграунда. Довольно успешен. Язык хорошо подвешен. Пользы он, разумеется, не приносит никому кроме себя.
Да только js и php нормальные языки, остальные сделаны в отрыве от накопленных человечеством знаний.
Мне бы больше хотелось приложение основанное на расширенной реальности (смартфон, очки?), которое бы помогало найти носок в куче парный к тому, что я держу в руках. Было бы вдвойне офигенно, если б оно мне ещё сразу говорило, надо ли мне выворачивать его. Ради такого я бы заплатил, и не поленился бы сфоткать мои 100 носков в анфас и в профиль однажды.
То же самое и с другим сложным примером:
Тип
testздесь выводится пустой строкой. Таким образом, в обоих примерах явное приведение типов внутри функций, предлагаемое вами, содержит ошибку и является источником unsoundness (не знаю как по-русски, "противоречивость" может быть?).Похоже, что в утверждении
нужен особый акцент на слове "осторожном".
Я бы в своем коде не стал вообще использовать перепресвоение типа без рантайм-проверки, за одним исключением - если есть доказательство, что переприсвоение корректно. В данном случае (
splitиconcat) даже с рантайм проверкой было бы грустно, т. к. программист не ожидает, что изменение кода подобное примерам из предыдущего комментария потенциально может ввести райнайм ошибку, и может сделать коммит не проверив.Спасибо.
Вот так работает хорошо:
Тип
firstвыводится равным `21`.Однако, вот так плохо:
Тип
testвыводится пустым массивом, и третья строчка посвечивается ошибкой. Неожиданно, кажется чтоsplitдолжна возвращатьstring[]если на вход поданаstring.С typescript не знаком.
Скажите, вот вы не пишете тела функций, но всё-таки, что туда можно написать? Вот, к примеру, для последней функции split, компилятор примет тело "str.split(sep);"? А какие ещё тела он примет для такого возвращаемого типа? Я что-то плохо представляю как нечто такое можно верифицировать.
За что, у меня же отпуск :) Прекрасно передано ощущение часов текущих сквозь пальцы, и гугл календарь подчеркивает его отлично
Сетка из 60 сайтов софтовой тематики. Использование AI для контента. Приятно читать статью, надеюсь остальные, кто этим всем занимается, тоже теряют деньги. Плюсик вам.
Хорошая идея. Показывать второе предупреждение, если юзер подозрительно быстро кликнул.
А если бы на воротах было написано МИНЫ, пошли бы?
Вылет, а не выезд. Luxexpress, Питер-Талинн, 35 евро.
Как понять, что перед вами плохой разработчик. Не стопроцентный способ, но сигнал: если он вывел правила подобные описанным в статье, то собственно вот, вы поняли. Либо у него так себе с анализом, и он нашел подтверждения этим правилам, когда вообще-то их нет, либо он оценивает других разработчиков по параметрам ортогональным разработке.
Разумеется я про суждение о силе программистами по его речи. Остальное в статье - капитанство.