Кстати вот не понятно, что на картинке 1973. Там какая то ошибка. Если имелся в виду мобильный телефон и Мартин Купер, то почему там не его фото и телефон. Если именно похожий телефон — то год неправильный.
Прозрачные дисплеи от самсунга это не пленки. Это ЖК панели. А там где квадратики — это просто квадратные дисплеи комбинированные с витринами такого же размера.
Поразила машинка с проекцией — там где из черной стала красной. Это не фейк? Может машинку переставили? Все проекции бледные, а эта очень яркая. Что-то нереальное.
Не мешало бы проверять, что рисуемая частица существует. Оно, конечно понятно, что скорее всего будут удаляться частицы из начала списка, но теоретически возможно, что удалится последняя и программа вылетит с ошибкой.
Я говорил об универсальном? Наоборот специализированная ось или API для управления бытовой техникой.
Почему iPad превратился в бесполезное железо? На нем перестали работать какие-то функции? его нельзя починить в случае поломки?
Почему бесполезное?
Если вы о моральном устаревании железа, то скорее всего для бытовой техники этот процесс будет медленнее. А кроме того она не перестанет выполнять свои функции из-за морального устаревания. Новые функции могут перестать появляться это да, но с традиционной техникой у вас нет даже надежды на новые функции сразу после покупки.
И будет он потом спамить: «помидоры не опознаны!», «переложи молоко на 2ю полочку». :-)
В категорях холодильников будет — количество камер (имеется в виду видео). Одна на дверце в бюджетных вариантах. И на каждой полочке по 3 в премиум.
Так можно было бы сделать наоборот устройства без интерфейса. Особый класс устройств — HeadLess. Как сейчас есть встраиваемая техника — без корпуса. А эти управлялись бы с планшета или телефона. Не знаю нужен ли там андроид. пользовательский интерфейс там не нужен, нужна некая виртуальная машина со стандартными интерфейсами для управления железом. Впрочем даже если туда ставить андроид с экранчиком все равно нужен стандарт на управление железом.
В районе экватора, тропиков. За полярным кругом летом вообще лететь не надо :-), если не выдвигать требование чтобы солнце было все время на одном и том же азимуте.
Насчет легковесных нитей ничего не понял. Зачем их ложить поверх setTimeout?
Я не собираюсь повторять Erlang, зачем мне что-то показывать?
Термин IPC включает в себя Inter Process Communication. Обмен сообщениями вполне себе коммуникация. Что он там включает в реализации Erlang совершенно не важно для самого термина. Переподключение, например, в некоторых реализациях вообще может не иметь смысла.
Там целый список ограничений. «Хорошее решение» для чего?
Первые два согласен, причем первое вытекает из второго. Но lightweight-threads придется осваивать отдельно — аутсорс не получится.
А multi-node IPC вообще нигде не проблема. На вскидку — ZMQ и вперед.
Я не понял, где я путал язык и реализацию? Ни NodeJS, ни V8 это не язык.
Erlang может и победит в специфичных многопоточных задачах, а реализация JS на нем не факт. (4й раз, прошу заметить!).
На С++ есть куча реализаций JS. Это не делает их автоматически супербыстрыми, даже на простых задачах. Они все очень разные.
JS по природе не многопоточен. Зачем в него это пихать? Если использовать фишки Erlang в JS — изоляцию процессов, неизменяемость переменных, а только так можно добиться чудесного эффекта — это будет уже не JS. И писать на нем будет так же сложно как на Elang и ваша мечта об аутсорсе не сбудется.
С++ быстрее чем Java и Erlang и для С++ о чудо! есть NodeJS :-)
Это я к чему: 3 раз намекаю — не факт что реализация JS на Erlang будет быстрее чего-либо.
Ну да легко решается, но если вы реализуете интерпретатор JavaScript(по спецификации) на Erlang вы эту проблему в JavaScript не решите, а в производительности потеряете 100%. Если это будет не по спецификации — то это будет уже не JavaScript.
Про cluster я вообще ни словом не упоминал. Да и он тоже позволяет запускать параллельную обработку. Есть и другие способы.
Если так нравится Erlang и все на нем легко и просто, почему бы просто на нем не писать? Зачем там JavaScript?
Сколько копий уже сломали — однопоточность в данном случае не недостаток, а достоинство. Надо параллельную обработку — запускай еще одну копию движка. А сделать многопоточность пойдут те же проблемы с синхронизацией, блокировками и т.д. И причем тут Erlang? Там совсем другой подход. И если поверх него городить JS то будет действительно плохо — особенно с производительностью.
Делал свой Event Loop в приложении использующем MS Active Scripting.Поскольку были планы использовать сторонние JS библиотеки то пришлось реализовывать setTimeout setInterval.
Делал давно пошел посмотреть, как у меня там устроено — нашел ошибку. А всегда считал что правильно — работало вроде без проблем.
Поразила машинка с проекцией — там где из черной стала красной. Это не фейк? Может машинку переставили? Все проекции бледные, а эта очень яркая. Что-то нереальное.
Почему iPad превратился в бесполезное железо? На нем перестали работать какие-то функции? его нельзя починить в случае поломки?
Почему бесполезное?
Если вы о моральном устаревании железа, то скорее всего для бытовой техники этот процесс будет медленнее. А кроме того она не перестанет выполнять свои функции из-за морального устаревания. Новые функции могут перестать появляться это да, но с традиционной техникой у вас нет даже надежды на новые функции сразу после покупки.
В категорях холодильников будет — количество камер (имеется в виду видео). Одна на дверце в бюджетных вариантах. И на каждой полочке по 3 в премиум.
2. Как собираетесь зачищать устаревшие файлы?
Я не собираюсь повторять Erlang, зачем мне что-то показывать?
Термин IPC включает в себя Inter Process Communication. Обмен сообщениями вполне себе коммуникация. Что он там включает в реализации Erlang совершенно не важно для самого термина. Переподключение, например, в некоторых реализациях вообще может не иметь смысла.
Первые два согласен, причем первое вытекает из второго. Но lightweight-threads придется осваивать отдельно — аутсорс не получится.
А multi-node IPC вообще нигде не проблема. На вскидку — ZMQ и вперед.
Erlang может и победит в специфичных многопоточных задачах, а реализация JS на нем не факт. (4й раз, прошу заметить!).
На С++ есть куча реализаций JS. Это не делает их автоматически супербыстрыми, даже на простых задачах. Они все очень разные.
JS по природе не многопоточен. Зачем в него это пихать? Если использовать фишки Erlang в JS — изоляцию процессов, неизменяемость переменных, а только так можно добиться чудесного эффекта — это будет уже не JS. И писать на нем будет так же сложно как на Elang и ваша мечта об аутсорсе не сбудется.
Это я к чему: 3 раз намекаю — не факт что реализация JS на Erlang будет быстрее чего-либо.
Про cluster я вообще ни словом не упоминал. Да и он тоже позволяет запускать параллельную обработку. Есть и другие способы.
Если так нравится Erlang и все на нем легко и просто, почему бы просто на нем не писать? Зачем там JavaScript?
Делал давно пошел посмотреть, как у меня там устроено — нашел ошибку. А всегда считал что правильно — работало вроде без проблем.
это компенсируется весом батареек для двигателя.