тут проблема в том, что + применяется в том числе для конкатенации. - же только для вычитания, вот интерпретатор и выбирает более "логичный" вариант.
в такой ситуации косяк разработчика, не иначе.
проблема в том, что интовая переменная, проходящая через хер знает что и много классов, где-то становится строкой, а потом ты плюсуешь эту переменную и на выходе получается хрен знает что.
я, как раз сегодня с этим столкнулся (как java/android developer, временно сидящий на js проекте) не много прихуел, т.к. заметил я это далеко не сразу
ты прям живешь в идеальном мире, где проект пишется максимум полгода, всегда одной командой, одними людьми, и на него никогда не сажали хер пойми кого
null === 0
false
null !== 0
true
null <= 0
true
null >= 0
true
В каком букваре нужно это почитать?
JS - помойка.
Да, если читать спецификацию, жить становится гораздо проще.
Но это, как будто опытный бомж учит неопытного ковыряться в помоях.
Вне всяких сомнений, язык предоставляет весьма полезный и мощный функционал. Но как я вилкой то буду чистить? Ответ:
Раз-раз-раз-раз-раз-раз-раз!
Или по вашему зря существуют обёртки над ней, вроде кофе скриптов и прочих? Да, эта предъява спорная. Тем не менее, надеюсь вы понимаете, к чему я клоню.
Java, к слову, раскидывает нормальные приоритеты для конкатенации строк вперемешку с интами, ведь у неё тоже знак плюс отвечает как за арифметическую операцию, так и за конкатенацию строк.
>В каком букваре нужно это почитать?
В любом букваре по js, это очевидные вещи для любого, кто осилил приведение типов.
А помойка в голове у того, кто бравирует своей гоупостью и ленью.
>Java, к слову,
Серьезно? Ты решил сравнить язык с сильной статической типизацией с языком со слабой динамической? Вон из проынссии, неуч.
>Серьезно? Ты решил сравнить язык с сильной статической типизацией с языком со слабой динамической?
Я решил сравнить язык, мультипарадигменный, весь из себя развеликолепный, с каким то строго типизированным, который принимает только один хуец, а не все сразу.
>В любом букваре по js, это очевидные вещи для любого, кто осилил приведение типов.
Как на счёт того, что бы ткнуть пальцем? Или ты просто так скозал, как обычно?
Дорастешь до мидла хотя бы, начнешь спеки читать и в твоем мире станет гораздо меньше удивительных вещей.
Нихрена подобного. У JS асинхронное выполнение кода. Это значит, что при линейном выполнении (без переходов, функций и т.п.) строка, например, 35 может быть выполнена ДО 33-34...
Что-то ты херню морозишь.
Во-первых, что вообще за зверь такой - "асинхронное выполнение кода"? Это как?
строка, например, 35 может быть выполнена ДО 33-34...
Инструкции выполняются последовательно. Если в строках 33-34 вызывается неблокирующая операция, то да, её результат может быть получен после исполнения строки 35. Но это не значит, что код строки 33 выполнился раньше, чем код строки 35. Просто в 33 строке код означает, условно, не "выеби гусей и доложи об успехах", а "начинай ебать гусей. Если мне понадобится отчет о проделанной работе - я приду позже". Вот и все.
Во-вторых, даже в си строка 35 запросто может выполниться раньше, чем строки 33-34, если оптимизатор решит, что так будет быстрее и эта перестановка инструкций не повлияет на результат.
Эм... даже я, офигенно далекий от фронтенда человек, знаю что JS использует внутри eventloop на основе Libev или чего-то такого. Никакой асинхронности там в принципе нет, всегда исполняется ровно одна инструкция.
По сути это почти то же, что дает asyncio в питоне, и ровно то же самое что lievev/gevent в питоне.
А вообще речь шла о типизации в языках, как она делает определенные вещи сложнее.
Так что коммент вдвойне обосрался.
Никакой асинхронности там в принципе нет, всегда исполняется ровно одна инструкция.
Но ведь ты описал самую что ни на есть асинхронность)
И asyncio в питоне позволяет писать именно асинхронный код. Для асинхронности совсем не обязательно исполнять несколько инструкций одновременно. Достаточно неблокирующего io и eventloop-а. А асинхронность-через-многопоточность (которая уже требовала бы исполнения нескольких инструкций одновременно) - это лишь костыль, позволяющий асинхронно выполнять операции, которые трудно/невозможно сделать неблокирующими.
Нет там никакой асинхронности, во всяком случае не в оригинальном смысле, в котором она есть при multithreading/multiprocessing. Тут код выполняется исключительно последовательно, одна инструкция за раз, нет параллельного выполнения, все детерминировано.
Хотя можно наверно спорить о значении "асинхронный".
Асинхронность и многопоточность - вещи ортогональные. "В оригинальном смысле" асинхронность - это когда есть неблокирующие операции, результат которых получается и обрабатывается программой в тот момент, когда этот результат становится доступным. Все. Никакого требования выполнять код параллельно нет. Да, один из способов реализации асинхронности - это посредством multithreading/multiprocessing отправить код выполняться в другой поток/процесс и потом, когда этот код завершит свое выполнение, обработать результат в главном потоке. Но это совершенно не обязательное требование. Если читать файл с помощью системного вызова aio_read с нотификацией через SIGEV_SIGNAL, то код будет все так же выполняться "исключительно последовательно, одна инструкция за раз, без параллельного выполнения", в одном единственном потоке и т.д., но синхронным он от этого не станет, т.к. хендлер сигнала вызовется по завершению операции чтения и твой код будет спокойно продолжать выполнение до момента получения этого самого сигнала.
И по поводу "все детерминировано" тоже не совсем верно. Да, детерминировано больше, чем при обычной вытесняющей многозадачности. Если мы про достаточно высокоуровневые языки, то выполнение кода может прерваться только в местах с await, а не в любой момент, как с многопоточностью (и то, это речь именно про высокоуровневые языки с async/await или голыми коллбеками. В том же си прерывание для обработки сигнала может застать тебя в любой момент). Но какой именно код (какая корутина) начнет выполняться после await - не детерминировано точно так же, как и не детерминировано, какой поток получит управление в случае с мультитредингом.
про приведение типов опять срачик? подозреваю, что употребляя 1+'1' ожидается приведение к численному типу, а не к строке.
почему срачник то сразу. если это не типизированный язык то как хочет так и складывает. намного безопаснее привести число к строке чем строку к числу
К тому же все правила автоматического приведения типов подробно описанны в спецификации языка и разжеванны в любой книжке для новичков.
Нубы не читают спеки, они выучили 1 язык и считают, что все остальные должны быть на него похожи. Представляю что бы они сказали, увидев лисп или пролог.
для начала - мое знакомство с программированием ограничилось только институтом, так что меня даже нубом назвать то сложно.
второе, на мой взгляд, динамическая типизация - не лучшее решение человечества.
третье, сравнивать ооп и предикативные языки - верх кощунства.
з.ы. - lisp понравился, и не потому что в аське код заблеванный получался.
А ничего, что жабаскрипт не объектно-ориентированный язык, а мультипарадигменный, такой же как и коммон лисп, наприме?
>второе, на мой взгляд, динамическая типизация - не лучшее решение человечества.
Во-первых, зык, это инстремент. Написать такое все равно что написать: "рожковые ключи - не лучшее решение человечества, другое дело баллонный". Взгляды, это хорошо, но они должны быть на чем-то основаны.
Во-вторых, статическая типизация никак не уменьшает количество ошибок.
медиум.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3
Домен латинницей напишите. Администрация пикабу совсем с катушек слетела.
IT-юмор
5.6K постов52.5K подписчика
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору