URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 102372
[ Назад ]

Исходное сообщение
"Google развивает средства создания высокопроизводительных An..."

Отправлено opennews , 03-Май-15 09:36 
Разработчики из компании 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


Содержание

Сообщения в этом обсуждении
"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 03-Май-15 09:36 
Лучше заменить JS на Dart в обычных браузерах,
Vanilla JS - продакшн сумрачного гения!

"Google развивает средства создания высокопроизводительных An..."
Отправлено anonymous , 04-Май-15 00:07 
Но зачем? Работает — и фиг с ним.

"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 04-Май-15 12:17 
Нет желания писать код с использованием 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


"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 04-Май-15 12:20 
> Нет желания писать код с использованием 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


"Google развивает средства создания высокопроизводительных An..."
Отправлено Lain_13 , 05-Май-15 00:46 
>    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


"Google развивает средства создания высокопроизводительных An..."
Отправлено Aleks Revo , 17-Май-15 08:51 
> Null же эквивалентен нулю (хоть и не равен).

экви-валентный -> равно-значный

Величины равнозначны, но их значения не равны - о как! )))

Вы уж там как-нибудь определитесь - равны или не равны (не забудьте про военное время) ))


"Google развивает средства создания высокопроизводительных An..."
Отправлено Lain_13 , 17-Май-15 14:02 
Ок-ок, моё понимание разницы между null, undefined и 0 в JS хромает на все конечности. Особенно если учесть, что null == undefined // true и что оба означают отсутствие значения. Разница лишь в том, что null это «переменная объявлена пустым значением», а undefined «переменная ещё не объявлена». Хотя в том же С++ NULL это именно 0.

Главное избегать использования == если не уверен в том, какое значение примет переменная, и использовать вместо него === если хочешь получить однозначный результат. И помнить о том, что объекты при помощи == и === можно только проверить на соответствие самим себе (a = {}; a===a//true), а NaN не равен даже сам себе (a = NaN; a===a//false) и проверяется только через isNaN().


"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 11-Май-15 14:03 
У человека с прямыми руками, который не первый месяц пишет код для продакшна на js, никогда в жизни не возникнет проблем с подобными вещами.

"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 12-Май-15 12:17 
Слава богу я не извращенец на js, пусть дорастет до стандарта.
js пусть умрет как и его писатели.

"Google развивает средства создания высокопроизводительных An..."
Отправлено Lain_13 , 05-Май-15 00:28 
> /[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


"Google развивает средства создания высокопроизводительных An..."
Отправлено Lain_13 , 05-Май-15 00:30 
> Нет желания писать код с использованием undefined, getElementBy{Id,TagName,Name}

Кстати, лично я всегда использую querySelector() вместо всех разновидностей getElementBy.


"Google развивает средства создания высокопроизводительных An..."
Отправлено Aleks Revo , 17-Май-15 09:00 
>> Нет желания писать код с использованием undefined, getElementBy{Id,TagName,Name}
> Кстати, лично я всегда использую querySelector() вместо всех разновидностей getElementBy.

А потом пол опеннета исходит на говно "браузеры тормозят" ))))))


"Google развивает средства создания высокопроизводительных An..."
Отправлено Lain_13 , 17-Май-15 13:01 
Мне кажется если тебе нужно делать такие вызовы так часто, что «браузеры тормозят», то нужно всерьёз задуматься о рефакторинге кода. ИМХО, но постоянных вызовов querySelector и getElementBy не должно быть в принципе. Хотя, конечно, getElementById работает быстрее чем querySelector по тому же ID где-то на 50%-60%, а getElementByClassName быстрее querySelectorAll и вовсе раз в 100-200 (https://jsperf.com/getelementsbyclassname-vs-queryselectoral...). Но всё зависит от того как часто тебе нужно их дёргать.

"Google развивает средства создания высокопроизводительных An..."
Отправлено абвгдейка , 04-Май-15 08:42 
шило на мыло? Dart не лучшая замена :)

"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 04-Май-15 11:37 
Сделай лучше и желательно как стандарт...

"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 04-Май-15 23:01 
Dart хотя бы работает. А так-то я за scala-js, но он еще, мягко говоря, сыроват

"Google развивает средства создания высокопроизводительных An..."
Отправлено анонимус , 03-Май-15 10:17 
Молодцы. Им давно об этом говорили. Некоторые энтузиасты даже сами стали портировать ВМ под андроид.

"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 03-Май-15 10:23 
Плавали - знаем.
Попиарят на конференциях и закроют как неперспективную технологию.

"Google развивает средства создания высокопроизводительных An..."
Отправлено anonymous , 03-Май-15 10:43 
Для веба VM зaкoпaли - и для Андройда зaкoпaют. Язык имел неплохие перспективы пока Гугл не пpидушил его в кoлыбели. Главное чтобы с Go не получилось так же.

"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 03-Май-15 16:33 
Лучше бы с Go получилось так же. А то уже весь гитхаб этим крапом засран.

"Google развивает средства создания высокопроизводительных An..."
Отправлено Dark Amateur , 03-Май-15 17:40 
А мне go нравится из-за gcc-go.

"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 03-Май-15 11:59 
Писать ПО на новомодных языках, в наше время это просто баловство. Через время может оказаться что язык никому не нужен. Как язык D, что то делают, релизы выходят а популярности нет

"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 03-Май-15 18:00 
просто ты не в треде,го уже взлетел больше года назад это было понятно, и я тебя удивлю уже понятно что взлетит Rust. Также понятно что питон и руби будут толкаться боками, а над ними будут ржать урод пхп еще лет 5 минимум.

"Google развивает средства создания высокопроизводительных An..."
Отправлено Black_Ru , 03-Май-15 19:35 
Считаю Вы правы по большей стпени.


"Google развивает средства создания высокопроизводительных An..."
Отправлено ДругойАноним , 03-Май-15 19:36 
Все руби программисты давно уже ушли в node/io.js или в тот же Rust.
Ну и собственно, Оракул, По поводу Rust, мне вот не очевидно что он взлетит, докажи обратное!

"Google развивает средства создания высокопроизводительных An..."
Отправлено Aleks Revo , 17-Май-15 09:02 
> Все руби программисты давно уже ушли в node/io.js или в тот же
> Rust.
> Ну и собственно, Оракул, По поводу Rust, мне вот не очевидно что
> он взлетит, докажи обратное!

Зачем доказывать, что он не взлетит, если он взлетит? )))


"Google развивает средства создания высокопроизводительных An..."
Отправлено Crazy Alex , 03-Май-15 12:43 
И опять "загружать приложения с веба" - да нехай они сдохнут с таким подходом.

"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 03-Май-15 13:58 
io.js уже можно на ARM рапускать ;)

"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 03-Май-15 14:02 
> нить для обработки интерфейса выполняется отдельно от нити приложения

И что она будет выводить, эта "нить для обработки интерфейса", если она сама по себе, а приложение само по себе? Как в том анекдоте, "я печатаю со скоростью 300 знаков в минуту, получается абсолютная фигня".


"Google развивает средства создания высокопроизводительных An..."
Отправлено XXasd , 03-Май-15 14:33 
А зачем вообще нужна эта анимация?

"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 03-Май-15 16:31 
Perl, Python, Java, C#, Dart, Go, Rust, ...

Но почему нельзя использовать только C/C++, которые самые массово используемые языки для создания прикладного софта, и к тому же продолжают активно развиваться? Вот зачем, неужели так важно какая именно компания создала язык, что все компании начинают клепать свои языки, причём в случае Google их даже сразу несколько.


"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 03-Май-15 19:18 
деточка C вообще для прикладного софта мало подходит. С++ да можно нафигачить но гемору это поддерживать и рефакторить просто ужас.

"Google развивает средства создания высокопроизводительных An..."
Отправлено Black_Ru , 03-Май-15 19:36 
> Perl, Python, Java, C#, Dart, Go, Rust, ...
> Но почему нельзя использовать только C/C++, которые самые массово используемые языки для
> создания прикладного софта, и к тому же продолжают активно развиваться? Вот
> зачем, неужели так важно какая именно компания создала язык, что все
> компании начинают клепать свои языки, причём в случае Google их даже
> сразу несколько.

А Пых? Только без ООП конечно


"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 03-Май-15 20:06 
Ну да, PHP и Ruby забыты в списке ненужных языков.

"Google развивает средства создания высокопроизводительных An..."
Отправлено lucentcode , 03-Май-15 19:56 
В некоторых случаях C/C++ использовать - то же самое что палить из пушки по воробьям. Как раз веб-сервисы на Perl/Python писать удобно, высоко нагруженные сервисы на Java или C# пишут, в последнее время Node.Js и Go с их асинхронным подходом очень популярны. Перспективы Rust пока выглядят туманными, в частности не ясна сфера применения ЯП(для GUI есть C++/Java/C#, для веб-приложений Perl/PHP/Python/Java и т.п.). В общем, на одних плюсах далеко не уедешь. Ваш вопрос можно перефразировать: зачем нужны C/C++ когда есть ассемблер?  

"Google развивает средства создания высокопроизводительных An..."
Отправлено arzeth , 03-Май-15 21:14 
> Перспективы 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


"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 04-Май-15 19:32 
helloworld под elf можно на сях скоплять под elf где то в 83 байта, точно размер уже не помню но там тупо один вызовы ядра дергается.

"Google развивает средства создания высокопроизводительных An..."
Отправлено абвгдейка , 04-Май-15 13:51 
C/C++ в браузере? Ну-ну :) А вообще был такой проект и даже не один из них - от гугла. Оба мертвы. Предлагаю найти в сети причины :)

"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 03-Май-15 16:54 
> Для борьбы с "заиканием" графики и притормаживанием интерфейса, Sky
> изначально построен на исключающей блокировки архитектуре - нить для
> обработки интерфейса выполняется отдельно от нити приложения, что
> позволяет сохранить быстрый и отзывчивый интерфейс даже во время
> интенсивных вычислений.

Охренеть новизна подхода. А как-то там проверяется, что нить для обработки интерфейса именно обрабатывает интерфейс? Любителей пихать весь код приложения в коллбэки нажатия на кнопочки нисколько не убавилось.


"Google развивает средства создания высокопроизводительных An..."
Отправлено Piter_Ring , 03-Май-15 17:38 
звучит как: Гугл развивает газообразные металлы высокой твердости для использования в качестве жидкости.

"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 03-Май-15 19:16 
ох лучше бы свою инплементацию swift под андройд написали.

"Google развивает средства создания высокопроизводительных An..."
Отправлено vitalif , 03-Май-15 19:25 
лучше бы UI фреймворк на сях переписали и биндинги сделали ко ВСЕМУ

больше не вставало бы вопросов, все бы писали на том, что им нравится)


"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 04-Май-15 12:56 
Люто, неистово плюсую!

"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 03-Май-15 19:43 
Будем посмотреть. Пока все ждали mir и wayland, Google выкатил freon без шума и пыли.

>Sky изначально построен на исключающей блокировки архитектуре - нить для обработки интерфейса выполняется отдельно от нити приложения, что позволяет сохранить быстрый и отзывчивый интерфейс даже во время интенсивных вычислений.

Хочу такое на десктоп!


"Google развивает средства создания высокопроизводительных An..."
Отправлено Xasd , 04-Май-15 13:45 
> Хочу такое на десктоп!

а ни кто и не запрещает программистам на Desktop -- делать в своих программах несколько нитей!

и такой подход даже поощряется...

...а вот когда делают несколько нитей и при этом устраивают "Состояние гонки" -- такое мало кому нравится :)


"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 03-Май-15 21:33 
Android? Sky?

"Google развивает средства создания высокопроизводительных An..."
Отправлено Ph0zzy , 03-Май-15 21:41 
Sky engine для Net-приложений? sky.net?

"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 04-Май-15 04:54 
Дартисты!

"Google развивает средства создания высокопроизводительных An..."
Отправлено Тутаевский район , 04-Май-15 10:27 
Дартисты-баристы! (обслуга, короче :))

"Google развивает средства создания высокопроизводительных An..."
Отправлено manster , 04-Май-15 11:46 
т.е. типа нашли причину почему тормозит и лагает

"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 05-Май-15 22:57 
Да это мы вобще побырому решили все вопросы.

"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 04-Май-15 14:06 
А язык GO Google похоронил, у него нет будущего и учить его нет смысла?

"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 04-Май-15 14:17 
Его ведь можно было довести до ума, добавить скорости работы, посмотреть чего люди и компании хотят и чего они будут хотеть в будущем, добавить всё это из коробки, добавить ООП из коробки, устранить бардак в библиотеках, добавить GUIшечек на все случаи жизни и библиотек для них, всё структурировать, довести до ума IDE, добавить в неё мощную систему выявления ошибок, и сделать, чтобы он занял то место в Android/Linux, какое занимают языки платформы .NET в Windows.

Но ничего этого нет, и похоже уже не будет.

Я за фундаментальное изменение языка.


Dart проще GO, но приложения на нём будут ещё тормознее.


"Google развивает средства создания высокопроизводительных An..."
Отправлено manster , 05-Май-15 15:11 
Интересный и перспективный язык, но что-то в нём настораживает.

"Google развивает средства создания высокопроизводительных An..."
Отправлено нектобы , 06-Май-15 00:36 
> А язык GO Google похоронил, у него нет будущего и учить его нет смысла?

Прогресс слишком ускорился, сейчас ничего нет смысла учить.

Выпускают что-нибудь дедоделанное для "непродвинутых пользователей", и через два релиза выкидывают и заменяют чем-нибудь абсолютно другим.

На собеседованиях не попросят спроектировать наскоро архитектурку какого-нибудь сервиса, но точно спросят, как будет вести себя тот или иной код в каждой из поддерживаемых версий php.

Вместо того, чтоб написать свою библиотеку для реализации какого-то функционала, заставят найти существующую, прочитать описание двух апи-вызовов и использовать. И вместо понимающего человека получается экономически эффективный "непродвинутый пользователь", способный лишь набрать две буквы и стрелочками выбрать из выпавшего списка нужную строку автодополнения.

В такой среде даже если ты знаешь больше других, нужен ну ОЧЕНЬ понимающий работодатель, чтобы твоё "могу написать это с нуля и оптимизировать" ценилось выше чьего-то "зачем писать самому, если в гугле можно найти библиотеку, а потом докупить серверов, если что".


"Google развивает средства создания высокопроизводительных An..."
Отправлено нектобы , 06-Май-15 00:47 
> дедоделанное

недоделанное


"Google развивает средства создания высокопроизводительных An..."
Отправлено Аноним , 07-Май-15 16:36 
>> ...создания высокопроизводительных Android-приложений...

Всегда терялся в догадках о том, что за зверюка такая это "высокопроизводительное приложение" и чем она отличается от "не высокопроизводительного приложения" :)