| 1.1, Аноним (-), 09:36, 03/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Лучше заменить JS на Dart в обычных браузерах,
Vanilla JS - продакшн сумрачного гения!
| | |
| |
| |
| 3.34, Аноним (-), 12:17, 04/05/2015 [^] [^^] [^^^] [ответить]
| +/– | |
Нет желания писать код с использованием undefined, getElementBy{Id,TagName,Name}
/[A-Z]/.test("A"); // true
/[a-z]/.test("a"); // true
/[a-z]/.test("z"); // true
/[a-z]/.test("Z"); // false
Math.max(3, 0); // 3
Math.max(3, {}); // NaN
Math.max(3, []); // 3
Math.max(3, true); // 3
Math.max(3, 'foo'); // NaN
Math.max(-1, null); // 0
Math.max(-1, undefined); // NaN
Math.max(1, true); // 1
Math.max(0, true); // 1
Math.max(1, false); // 1
Math.max(-1, true); // 1
Math.max(-1, false); // 0
Math.max(-1, []); // 0
Math.max(-1, [1]); // 1
Math.max(-1, [1, 4]); // NaN
| | |
| |
| 4.35, Аноним (-), 12:20, 04/05/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> Нет желания писать код с использованием undefined, getElementBy{Id,TagName,Name}
isFinite(); // false
isFinite(undefined); // false
isFinite(null); // true
null == false // false
!null // true
true == 'true' // true
false == 'false'; // false
parseInt('fuck'); // NaN
parseInt('fuck', 16); // 15
| | |
| |
| 5.45, Lain_13 (ok), 00:46, 05/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
 > isFinite(); // false
> isFinite(undefined); // false
> isFinite(null); // true
Пустой параметр это undefined, а undefined это фактически любое значение от -∞ до ∞ включительно. Естественно isFinite выдаёт false. Null же эквивалентен нулю (хоть и не равен).
> null == false // false
> !null // true
! - логический оператор и может вернуть только true или false. Null приводится к 0, а не 0 это true. !1 // false
> true == 'true' // true
> false == 'false'; // false
false == '' // true
true === 'true' // false
При сравнении с булевым значением происходит приведение к булевым значениям, а не пустая строка это всегда true. Пустая строка - всегда false. Во избежание проблем лучше вообще всегда использовать === и !== — они не выполняют приведения типов.
> parseInt('fuck'); // NaN
> parseInt('fuck', 16); // 15
Ну так естественно, parseInt ищет целое число начиная с первого символа, отличного от пробела. Если этот символ не может быть интерпретирован как число или знак числа - возвращается NaN. Если же число найдено, то вся строка после него, начиная с первого же не числового значния, будет отброшена. Естественно, что при указании основания 16, вместо стандартного 10, "f" будет интерпретировано как 15 (0xF), а 'uck' — отброшено так-как 'u' не может быть интерпретировано как число. parseInt('fck',16) // 252 (0xFC). Ещё интереснее становится если указать основание 36 — числами будет считаться весь диапазон от A до Z включительно. parseInt('fuck',36) // 739172
| | |
| |
| 6.53, Aleks Revo (ok), 08:51, 17/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
 > Null же эквивалентен нулю (хоть и не равен).
экви-валентный -> равно-значный
Величины равнозначны, но их значения не равны - о как! )))
Вы уж там как-нибудь определитесь - равны или не равны (не забудьте про военное время) ))
| | |
| |
| 7.57, Lain_13 (ok), 14:02, 17/05/2015 [^] [^^] [^^^] [ответить]
| +/– | |
Ок-ок, моё понимание разницы между null, undefined и 0 в JS хромает на все конечности. Особенно если учесть, что null == undefined // true и что оба означают отсутствие значения. Разница лишь в том, что null это «переменная объявлена пустым значением», а undefined «переменная ещё не объявлена». Хотя в том же С++ NULL это именно 0.
Главное избегать использования == если не уверен в том, какое значение примет переменная, и использовать вместо него === если хочешь получить однозначный результат. И помнить о том, что объекты при помощи == и === можно только проверить на соответствие самим себе (a = {}; a===a//true), а NaN не равен даже сам себе (a = NaN; a===a//false) и проверяется только через isNaN().
| | |
|
|
| 5.51, Аноним (-), 14:03, 11/05/2015 [^] [^^] [^^^] [ответить]
| –2 +/– |
У человека с прямыми руками, который не первый месяц пишет код для продакшна на js, никогда в жизни не возникнет проблем с подобными вещами.
| | |
| |
| 6.52, Аноним (-), 12:17, 12/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Слава богу я не извращенец на js, пусть дорастет до стандарта.
js пусть умрет как и его писатели.
| | |
|
|
| 4.43, Lain_13 (ok), 00:28, 05/05/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> /[a-z]/.test("Z"); // false
А чего ты, собственно, ожидал?
/[a-z]/i.test("Z"); // true
Math.max - автоматическое приведение типов не всегда легко понять, но следует понимать, что приводится будет к тому, что фонкция ожидает получить на входе, а в данном случае это числа.
'foo' - JS пытается найти в строке число, а его нет. Потому NaN.
Math.max(3,'4') вернёт 4.
null - фактически и обозначает 0, ничего. Потому приводится к числу 0.
Хотя, как ни странно, null == 0 // false.
[] - приводится к нулю так-как пустой. [] == 0 // true
undefined - не имеет определённого значения, в отличие от null, и потому NaN.
{} - объект приводится к undefined, а не null и потому получаем NaN.
true и false автоматически приводятся к 1 и 0 соответственно.
[1] и [1,4]- массив с одним элементом можно привести к целому числу взяв этот элемент, а вот массив с множеством только к undefined так-как непонятно какой из них следует выбрать.
Кстати, Math.max и Math.min можно применить к массиву.
Math.max.apply(null,[1,3,2]) // 3
| | |
| 4.44, Lain_13 (ok), 00:30, 05/05/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> Нет желания писать код с использованием undefined, getElementBy{Id,TagName,Name}
Кстати, лично я всегда использую querySelector() вместо всех разновидностей getElementBy.
| | |
| |
| 5.54, Aleks Revo (ok), 09:00, 17/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
>> Нет желания писать код с использованием undefined, getElementBy{Id,TagName,Name}
> Кстати, лично я всегда использую querySelector() вместо всех разновидностей getElementBy.
А потом пол опеннета исходит на говно "браузеры тормозят" ))))))
| | |
| |
| 6.56, Lain_13 (ok), 13:01, 17/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Мне кажется если тебе нужно делать такие вызовы так часто, что «браузеры тормозят», то нужно всерьёз задуматься о рефакторинге кода. ИМХО, но постоянных вызовов querySelector и getElementBy не должно быть в принципе. Хотя, конечно, getElementById работает быстрее чем querySelector по тому же ID где-то на 50%-60%, а getElementByClassName быстрее querySelectorAll и вовсе раз в 100-200 (https://jsperf.com/getelementsbyclassname-vs-queryselectorall/144). Но всё зависит от того как часто тебе нужно их дёргать.
| | |
|
|
|
|
| |
| 3.42, Аноним (-), 23:01, 04/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Dart хотя бы работает. А так-то я за scala-js, но он еще, мягко говоря, сыроват
| | |
|
|
| 1.2, анонимус (??), 10:17, 03/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Молодцы. Им давно об этом говорили. Некоторые энтузиасты даже сами стали портировать ВМ под андроид.
| | |
| 1.3, Аноним (-), 10:23, 03/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +16 +/– |
Плавали - знаем.
Попиарят на конференциях и закроют как неперспективную технологию.
| | |
| 1.4, anonymous (??), 10:43, 03/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
Для веба VM зaкoпaли - и для Андройда зaкoпaют. Язык имел неплохие перспективы пока Гугл не пpидушил его в кoлыбели. Главное чтобы с Go не получилось так же.
| | |
| |
| 2.11, Аноним (-), 16:33, 03/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
Лучше бы с Go получилось так же. А то уже весь гитхаб этим крапом засран.
| | |
|
| 1.5, Аноним (-), 11:59, 03/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Писать ПО на новомодных языках, в наше время это просто баловство. Через время может оказаться что язык никому не нужен. Как язык D, что то делают, релизы выходят а популярности нет
| | |
| |
| 2.15, Аноним (-), 18:00, 03/05/2015 [^] [^^] [^^^] [ответить]
| +4 +/– |
просто ты не в треде,го уже взлетел больше года назад это было понятно, и я тебя удивлю уже понятно что взлетит Rust. Также понятно что питон и руби будут толкаться боками, а над ними будут ржать урод пхп еще лет 5 минимум.
| | |
| |
| 3.21, ДругойАноним (?), 19:36, 03/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Все руби программисты давно уже ушли в node/io.js или в тот же Rust.
Ну и собственно, Оракул, По поводу Rust, мне вот не очевидно что он взлетит, докажи обратное!
| | |
| |
| 4.55, Aleks Revo (ok), 09:02, 17/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Все руби программисты давно уже ушли в node/io.js или в тот же
> Rust.
> Ну и собственно, Оракул, По поводу Rust, мне вот не очевидно что
> он взлетит, докажи обратное!
Зачем доказывать, что он не взлетит, если он взлетит? )))
| | |
|
|
|
| 1.8, Аноним (-), 14:02, 03/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
> нить для обработки интерфейса выполняется отдельно от нити приложения
И что она будет выводить, эта "нить для обработки интерфейса", если она сама по себе, а приложение само по себе? Как в том анекдоте, "я печатаю со скоростью 300 знаков в минуту, получается абсолютная фигня".
| | |
| 1.10, Аноним (-), 16:31, 03/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
Perl, Python, Java, C#, Dart, Go, Rust, ...
Но почему нельзя использовать только C/C++, которые самые массово используемые языки для создания прикладного софта, и к тому же продолжают активно развиваться? Вот зачем, неужели так важно какая именно компания создала язык, что все компании начинают клепать свои языки, причём в случае Google их даже сразу несколько.
| | |
| |
| 2.17, Аноним (-), 19:18, 03/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
деточка C вообще для прикладного софта мало подходит. С++ да можно нафигачить но гемору это поддерживать и рефакторить просто ужас.
| | |
| 2.20, Black_Ru (?), 19:36, 03/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
 > Perl, Python, Java, C#, Dart, Go, Rust, ...
> Но почему нельзя использовать только C/C++, которые самые массово используемые языки для
> создания прикладного софта, и к тому же продолжают активно развиваться? Вот
> зачем, неужели так важно какая именно компания создала язык, что все
> компании начинают клепать свои языки, причём в случае Google их даже
> сразу несколько.
А Пых? Только без ООП конечно
| | |
| 2.23, lucentcode (ok), 19:56, 03/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
 В некоторых случаях C/C++ использовать - то же самое что палить из пушки по воробьям. Как раз веб-сервисы на Perl/Python писать удобно, высоко нагруженные сервисы на Java или C# пишут, в последнее время Node.Js и Go с их асинхронным подходом очень популярны. Перспективы Rust пока выглядят туманными, в частности не ясна сфера применения ЯП(для GUI есть C++/Java/C#, для веб-приложений Perl/PHP/Python/Java и т.п.). В общем, на одних плюсах далеко не уедешь. Ваш вопрос можно перефразировать: зачем нужны C/C++ когда есть ассемблер?
| | |
| |
| 3.25, arzeth (ok), 21:14, 03/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Перспективы Rust пока выглядят туманными, в частности не ясна сфера применения ЯП
Ну я вижу Rust (хотя пользовался им мало) как полную замену C/C++:
Скорость почти такая же. Ассемблерить тоже можно. Во время компиляции быдлокод компилируется с меньшей вероятностью. Со всякими Double free мучиться не надо.
Разве что полностью пустая программа
fn main() {
}
после rustc -O x.rust && strip --strip-all x весит 299 360 байт, а не 6224 байт как у GCC 5.1 x86_64. Хотя кто-то умудрился hello world скомпилировать растом в 151 байт: http://mainisusuallyafunction.blogspot.ru/2015/01/151-byte-static-linux-binar
и то, что пока поддерживает библиотеки на C, но не C++: https://doc.rust-lang.org/book/ffi.html
| | |
| |
| 4.41, Аноним (-), 19:32, 04/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
helloworld под elf можно на сях скоплять под elf где то в 83 байта, точно размер уже не помню но там тупо один вызовы ядра дергается.
| | |
|
|
| 2.38, абвгдейка (?), 13:51, 04/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
C/C++ в браузере? Ну-ну :) А вообще был такой проект и даже не один из них - от гугла. Оба мертвы. Предлагаю найти в сети причины :)
| | |
|
| 1.12, Аноним (-), 16:54, 03/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
> Для борьбы с "заиканием" графики и притормаживанием интерфейса, Sky
> изначально построен на исключающей блокировки архитектуре - нить для
> обработки интерфейса выполняется отдельно от нити приложения, что
> позволяет сохранить быстрый и отзывчивый интерфейс даже во время
> интенсивных вычислений.
Охренеть новизна подхода. А как-то там проверяется, что нить для обработки интерфейса именно обрабатывает интерфейс? Любителей пихать весь код приложения в коллбэки нажатия на кнопочки нисколько не убавилось.
| | |
| 1.13, Piter_Ring (ok), 17:38, 03/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
 звучит как: Гугл развивает газообразные металлы высокой твердости для использования в качестве жидкости.
| | |
| |
| 2.18, vitalif (ok), 19:25, 03/05/2015 [^] [^^] [^^^] [ответить]
| +2 +/– |
 лучше бы UI фреймворк на сях переписали и биндинги сделали ко ВСЕМУ
больше не вставало бы вопросов, все бы писали на том, что им нравится)
| | |
|
| 1.22, Аноним (-), 19:43, 03/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
Будем посмотреть. Пока все ждали mir и wayland, Google выкатил freon без шума и пыли.
>Sky изначально построен на исключающей блокировки архитектуре - нить для обработки интерфейса выполняется отдельно от нити приложения, что позволяет сохранить быстрый и отзывчивый интерфейс даже во время интенсивных вычислений.
Хочу такое на десктоп!
| | |
| |
| 2.37, Xasd (ok), 13:45, 04/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
 > Хочу такое на десктоп!
а ни кто и не запрещает программистам на Desktop -- делать в своих программах несколько нитей!
и такой подход даже поощряется...
...а вот когда делают несколько нитей и при этом устраивают "Состояние гонки" -- такое мало кому нравится :)
| | |
|
| 1.39, Аноним (-), 14:06, 04/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
А язык GO Google похоронил, у него нет будущего и учить его нет смысла?
| | |
| |
| 2.40, Аноним (-), 14:17, 04/05/2015 [^] [^^] [^^^] [ответить]
| +/– | |
Его ведь можно было довести до ума, добавить скорости работы, посмотреть чего люди и компании хотят и чего они будут хотеть в будущем, добавить всё это из коробки, добавить ООП из коробки, устранить бардак в библиотеках, добавить GUIшечек на все случаи жизни и библиотек для них, всё структурировать, довести до ума IDE, добавить в неё мощную систему выявления ошибок, и сделать, чтобы он занял то место в Android/Linux, какое занимают языки платформы .NET в Windows.
Но ничего этого нет, и похоже уже не будет.
Я за фундаментальное изменение языка.
Dart проще GO, но приложения на нём будут ещё тормознее.
| | |
| 2.48, нектобы (?), 00:36, 06/05/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> А язык GO Google похоронил, у него нет будущего и учить его нет смысла?
Прогресс слишком ускорился, сейчас ничего нет смысла учить.
Выпускают что-нибудь дедоделанное для "непродвинутых пользователей", и через два релиза выкидывают и заменяют чем-нибудь абсолютно другим.
На собеседованиях не попросят спроектировать наскоро архитектурку какого-нибудь сервиса, но точно спросят, как будет вести себя тот или иной код в каждой из поддерживаемых версий php.
Вместо того, чтоб написать свою библиотеку для реализации какого-то функционала, заставят найти существующую, прочитать описание двух апи-вызовов и использовать. И вместо понимающего человека получается экономически эффективный "непродвинутый пользователь", способный лишь набрать две буквы и стрелочками выбрать из выпавшего списка нужную строку автодополнения.
В такой среде даже если ты знаешь больше других, нужен ну ОЧЕНЬ понимающий работодатель, чтобы твоё "могу написать это с нуля и оптимизировать" ценилось выше чьего-то "зачем писать самому, если в гугле можно найти библиотеку, а потом докупить серверов, если что".
| | |
|
| 1.50, Аноним (-), 16:36, 07/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
>> ...создания высокопроизводительных Android-приложений...
Всегда терялся в догадках о том, что за зверюка такая это "высокопроизводительное приложение" и чем она отличается от "не высокопроизводительного приложения" :)
| | |
|
