Разработчики из компании Google продемонстрировали (http://arstechnica.com/gadgets/2015/05/01/googles-dart-langu.../) на конференции Dart Developer Summit проект по организации разработки приложений для платформы Android с использованием языка программирования Dart. Проект пока носит экспериментальный характер, но связанный с ним инструментарий уже опубликован на GitHub под именем Sky SDK (https://github.com/domokit/sky_sdk).
Создаваемые при помощи Sky SDK приложения формируются только на языке Dart, без использования Java, и нацелены на обеспечение высокой производительности и плотной интеграции с Web. Перед проектом поставлены достаточно амбициозные цели по обеспечению отрисовки со скоростью 120 кадров в секунду, что в два раза превышает сегодняшние возможности экранов обычных мобильных устройств, которые могут обновляться с частой 60 Гц. С учетом того, что многие приложения могут лишь мечтать о выводе с частотой 60FPS, заявления о 120FPS выглядят фантастично. Отрисовка с частотой 60FPS подразумевает вывод кадра каждые 16 мс, если кадр не успеет сформироваться за этот промежуток, пользователь столкнётся с "заиканием" анимации.
Разработчики Sky подготовили демонсрационное (https://play.google.com/store/apps/details?id=org.domokit.sk...) приложение, в котором на отрисовку кадра тратится всего 1.2 мс, что даёт повод рассчитывать, что для реальных более сложных приложений вполне возможно обеспечить вывод гладкой анимации с гарантированным временем отрисовки кадра за 8 мс, что соответствует 120FPS. Для борьбы с "заиканием" графики и притормаживанием интерфейса, Sky изначально построен на исключающей блокировки архитектуре - нить для обработки интерфейса выполняется отдельно от нити приложения, что позволяет сохранить быстрый и отзывчивый интерфейс даже во время интенсивных вычислений.В целевой пакет помещаются только связанные с запуском приложения компоненты, само приложение может быть загружено через Web, по аналогии с web-приложениями. Минусом такого подхода является привязка к наличию сетевого соединения, а плюсом - доступ к всегда актуальной версии программы. При этом создаваемые в Sky приложения не привязаны к Android и потенциально могут быть запущены в iOS и любых других системах для которых имеется Dart VM, достаточно подготовить для каждой платформы свой runtime.
Sky SDK состоит из двух частей. Первым компонентов является написанный на языке C++ движок Sky (Sky engine), предоставляющий ключевые примитивы, такие как графическая система и планировщик задач с поддержкой работы в режиме мягкого реального времени. Вторым компонентом выступает фреймворк Sky, в котором реализованы средства для создания приложений, такие как наборы виджетов и механизмы реализации анимации. Sky framework функционирует поверх Sky engine и построен с использованием языка Dart.Приложения могут обращаться к службам операционной системы через Mojo IPC (https://github.com/domokit/mojo). Например, для доступа к сетевым возможностям предоставляется интерфейс network_service.mojom. Несмотря на то, что разработчики могут при помощи данного механизма обращаться к низкоуровневым интерфейсам напрямую, предпочтительным вариантом является использование специально подготовленных библиотечных обвязок.
URL: http://arstechnica.com/gadgets/2015/05/01/googles-dart-langu.../
Новость: http://www.opennet.me/opennews/art.shtml?num=42153
Лучше заменить JS на Dart в обычных браузерах,
Vanilla JS - продакшн сумрачного гения!
Но зачем? Работает — и фиг с ним.
Нет желания писать код с использованием 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); // NaNMath.max(1, true); // 1
Math.max(0, true); // 1
Math.max(1, false); // 1
Math.max(-1, true); // 1
Math.max(-1, false); // 0Math.max(-1, []); // 0
Math.max(-1, [1]); // 1
Math.max(-1, [1, 4]); // NaN
> Нет желания писать код с использованием undefined, getElementBy{Id,TagName,Name}isFinite(); // false
isFinite(undefined); // false
isFinite(null); // truenull == false // false
!null // true
true == 'true' // true
false == 'false'; // falseparseInt('fuck'); // NaN
parseInt('fuck', 16); // 15
> 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'; // falsefalse == '' // 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
> Null же эквивалентен нулю (хоть и не равен).экви-валентный -> равно-значный
Величины равнозначны, но их значения не равны - о как! )))
Вы уж там как-нибудь определитесь - равны или не равны (не забудьте про военное время) ))
Ок-ок, моё понимание разницы между null, undefined и 0 в JS хромает на все конечности. Особенно если учесть, что null == undefined // true и что оба означают отсутствие значения. Разница лишь в том, что null это «переменная объявлена пустым значением», а undefined «переменная ещё не объявлена». Хотя в том же С++ NULL это именно 0.Главное избегать использования == если не уверен в том, какое значение примет переменная, и использовать вместо него === если хочешь получить однозначный результат. И помнить о том, что объекты при помощи == и === можно только проверить на соответствие самим себе (a = {}; a===a//true), а NaN не равен даже сам себе (a = NaN; a===a//false) и проверяется только через isNaN().
У человека с прямыми руками, который не первый месяц пишет код для продакшна на js, никогда в жизни не возникнет проблем с подобными вещами.
Слава богу я не извращенец на js, пусть дорастет до стандарта.
js пусть умрет как и его писатели.
> /[a-z]/.test("Z"); // falseА чего ты, собственно, ожидал?
/[a-z]/i.test("Z"); // trueMath.max - автоматическое приведение типов не всегда легко понять, но следует понимать, что приводится будет к тому, что фонкция ожидает получить на входе, а в данном случае это числа.
'foo' - JS пытается найти в строке число, а его нет. Потому NaN.
Math.max(3,'4') вернёт 4.null - фактически и обозначает 0, ничего. Потому приводится к числу 0.
Хотя, как ни странно, null == 0 // false.
[] - приводится к нулю так-как пустой. [] == 0 // trueundefined - не имеет определённого значения, в отличие от 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
> Нет желания писать код с использованием undefined, getElementBy{Id,TagName,Name}Кстати, лично я всегда использую querySelector() вместо всех разновидностей getElementBy.
>> Нет желания писать код с использованием undefined, getElementBy{Id,TagName,Name}
> Кстати, лично я всегда использую querySelector() вместо всех разновидностей getElementBy.А потом пол опеннета исходит на говно "браузеры тормозят" ))))))
Мне кажется если тебе нужно делать такие вызовы так часто, что «браузеры тормозят», то нужно всерьёз задуматься о рефакторинге кода. ИМХО, но постоянных вызовов querySelector и getElementBy не должно быть в принципе. Хотя, конечно, getElementById работает быстрее чем querySelector по тому же ID где-то на 50%-60%, а getElementByClassName быстрее querySelectorAll и вовсе раз в 100-200 (https://jsperf.com/getelementsbyclassname-vs-queryselectoral...). Но всё зависит от того как часто тебе нужно их дёргать.
шило на мыло? Dart не лучшая замена :)
Сделай лучше и желательно как стандарт...
Dart хотя бы работает. А так-то я за scala-js, но он еще, мягко говоря, сыроват
Молодцы. Им давно об этом говорили. Некоторые энтузиасты даже сами стали портировать ВМ под андроид.
Плавали - знаем.
Попиарят на конференциях и закроют как неперспективную технологию.
Для веба VM зaкoпaли - и для Андройда зaкoпaют. Язык имел неплохие перспективы пока Гугл не пpидушил его в кoлыбели. Главное чтобы с Go не получилось так же.
Лучше бы с Go получилось так же. А то уже весь гитхаб этим крапом засран.
А мне go нравится из-за gcc-go.
Писать ПО на новомодных языках, в наше время это просто баловство. Через время может оказаться что язык никому не нужен. Как язык D, что то делают, релизы выходят а популярности нет
просто ты не в треде,го уже взлетел больше года назад это было понятно, и я тебя удивлю уже понятно что взлетит Rust. Также понятно что питон и руби будут толкаться боками, а над ними будут ржать урод пхп еще лет 5 минимум.
Считаю Вы правы по большей стпени.
Все руби программисты давно уже ушли в node/io.js или в тот же Rust.
Ну и собственно, Оракул, По поводу Rust, мне вот не очевидно что он взлетит, докажи обратное!
> Все руби программисты давно уже ушли в node/io.js или в тот же
> Rust.
> Ну и собственно, Оракул, По поводу Rust, мне вот не очевидно что
> он взлетит, докажи обратное!Зачем доказывать, что он не взлетит, если он взлетит? )))
И опять "загружать приложения с веба" - да нехай они сдохнут с таким подходом.
io.js уже можно на ARM рапускать ;)
> нить для обработки интерфейса выполняется отдельно от нити приложенияИ что она будет выводить, эта "нить для обработки интерфейса", если она сама по себе, а приложение само по себе? Как в том анекдоте, "я печатаю со скоростью 300 знаков в минуту, получается абсолютная фигня".
А зачем вообще нужна эта анимация?
Perl, Python, Java, C#, Dart, Go, Rust, ...Но почему нельзя использовать только C/C++, которые самые массово используемые языки для создания прикладного софта, и к тому же продолжают активно развиваться? Вот зачем, неужели так важно какая именно компания создала язык, что все компании начинают клепать свои языки, причём в случае Google их даже сразу несколько.
деточка C вообще для прикладного софта мало подходит. С++ да можно нафигачить но гемору это поддерживать и рефакторить просто ужас.
> Perl, Python, Java, C#, Dart, Go, Rust, ...
> Но почему нельзя использовать только C/C++, которые самые массово используемые языки для
> создания прикладного софта, и к тому же продолжают активно развиваться? Вот
> зачем, неужели так важно какая именно компания создала язык, что все
> компании начинают клепать свои языки, причём в случае Google их даже
> сразу несколько.А Пых? Только без ООП конечно
Ну да, PHP и Ruby забыты в списке ненужных языков.
В некоторых случаях C/C++ использовать - то же самое что палить из пушки по воробьям. Как раз веб-сервисы на Perl/Python писать удобно, высоко нагруженные сервисы на Java или C# пишут, в последнее время Node.Js и Go с их асинхронным подходом очень популярны. Перспективы Rust пока выглядят туманными, в частности не ясна сфера применения ЯП(для GUI есть C++/Java/C#, для веб-приложений Perl/PHP/Python/Java и т.п.). В общем, на одних плюсах далеко не уедешь. Ваш вопрос можно перефразировать: зачем нужны C/C++ когда есть ассемблер?
> Перспективы 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-s...
и то, что пока поддерживает библиотеки на C, но не C++: https://doc.rust-lang.org/book/ffi.html
helloworld под elf можно на сях скоплять под elf где то в 83 байта, точно размер уже не помню но там тупо один вызовы ядра дергается.
C/C++ в браузере? Ну-ну :) А вообще был такой проект и даже не один из них - от гугла. Оба мертвы. Предлагаю найти в сети причины :)
> Для борьбы с "заиканием" графики и притормаживанием интерфейса, Sky
> изначально построен на исключающей блокировки архитектуре - нить для
> обработки интерфейса выполняется отдельно от нити приложения, что
> позволяет сохранить быстрый и отзывчивый интерфейс даже во время
> интенсивных вычислений.Охренеть новизна подхода. А как-то там проверяется, что нить для обработки интерфейса именно обрабатывает интерфейс? Любителей пихать весь код приложения в коллбэки нажатия на кнопочки нисколько не убавилось.
звучит как: Гугл развивает газообразные металлы высокой твердости для использования в качестве жидкости.
ох лучше бы свою инплементацию swift под андройд написали.
лучше бы UI фреймворк на сях переписали и биндинги сделали ко ВСЕМУбольше не вставало бы вопросов, все бы писали на том, что им нравится)
Люто, неистово плюсую!
Будем посмотреть. Пока все ждали mir и wayland, Google выкатил freon без шума и пыли.>Sky изначально построен на исключающей блокировки архитектуре - нить для обработки интерфейса выполняется отдельно от нити приложения, что позволяет сохранить быстрый и отзывчивый интерфейс даже во время интенсивных вычислений.
Хочу такое на десктоп!
> Хочу такое на десктоп!а ни кто и не запрещает программистам на Desktop -- делать в своих программах несколько нитей!
и такой подход даже поощряется...
...а вот когда делают несколько нитей и при этом устраивают "Состояние гонки" -- такое мало кому нравится :)
Android? Sky?
Sky engine для Net-приложений? sky.net?
Дартисты!
Дартисты-баристы! (обслуга, короче :))
т.е. типа нашли причину почему тормозит и лагает
Да это мы вобще побырому решили все вопросы.
А язык GO Google похоронил, у него нет будущего и учить его нет смысла?
Его ведь можно было довести до ума, добавить скорости работы, посмотреть чего люди и компании хотят и чего они будут хотеть в будущем, добавить всё это из коробки, добавить ООП из коробки, устранить бардак в библиотеках, добавить GUIшечек на все случаи жизни и библиотек для них, всё структурировать, довести до ума IDE, добавить в неё мощную систему выявления ошибок, и сделать, чтобы он занял то место в Android/Linux, какое занимают языки платформы .NET в Windows.Но ничего этого нет, и похоже уже не будет.
Я за фундаментальное изменение языка.
Dart проще GO, но приложения на нём будут ещё тормознее.
Интересный и перспективный язык, но что-то в нём настораживает.
> А язык GO Google похоронил, у него нет будущего и учить его нет смысла?Прогресс слишком ускорился, сейчас ничего нет смысла учить.
Выпускают что-нибудь дедоделанное для "непродвинутых пользователей", и через два релиза выкидывают и заменяют чем-нибудь абсолютно другим.
На собеседованиях не попросят спроектировать наскоро архитектурку какого-нибудь сервиса, но точно спросят, как будет вести себя тот или иной код в каждой из поддерживаемых версий php.
Вместо того, чтоб написать свою библиотеку для реализации какого-то функционала, заставят найти существующую, прочитать описание двух апи-вызовов и использовать. И вместо понимающего человека получается экономически эффективный "непродвинутый пользователь", способный лишь набрать две буквы и стрелочками выбрать из выпавшего списка нужную строку автодополнения.
В такой среде даже если ты знаешь больше других, нужен ну ОЧЕНЬ понимающий работодатель, чтобы твоё "могу написать это с нуля и оптимизировать" ценилось выше чьего-то "зачем писать самому, если в гугле можно найти библиотеку, а потом докупить серверов, если что".
> дедоделанноенедоделанное
>> ...создания высокопроизводительных Android-приложений...Всегда терялся в догадках о том, что за зверюка такая это "высокопроизводительное приложение" и чем она отличается от "не высокопроизводительного приложения" :)