Есть что-то волшебное в Firefox OS

http://rawkes.com/articles/there-is-something-magical-about-firefox-os
  • Перевод
Последние полтора года я уделял все больше времени работе над новым проектом Mozilla — Firefox OS. За это время я буквально влюбился в него и в его идею, испытав то, чего не испытывал прежде.


Скриншот Firefox OS



Буду откровенен, Firefox OS является началом чего-то невероятного. Это ожидающая своего пробуждения революция. Глоток свежего воздуха. Кульминация новейших технологий. Оно волшебно и оно изменит все.

Что такое Firefox OS?


Для тех, кто не знает о чем я говорю, вот короткое описание.

Firefox OS — это новая мобильная операционная система разработанная Mozilla в рамках проекта Boot to Gecko (B2G). ОС использует ядро Linux и загружается в Gecko — веб-движок, который позволяет пользователям запускать приложения созданные на HTML, JS и любых других Open Web API приложений.
Mozilla Developer Network


Короче говоря, проект Firefox OS собрал в себе все веб-технологии для создания полноценной мобильной операционной системы. Остановитесь на секунду и задумайтесь — это мобильная ОС, созданная на JavaScript!

Для этого был модифицирован Gecko (движок Firefox), который предоставляет набор новых JavaScript APIs, необходимых для создания функционала подобного существующему в современных мобильных ОС. WebTelephony для телефонных звонков, WebSMS для отправки текстовых сообщений и Vibration API для, хм… для того чтобы вибрировать.



Firefox OS — это гораздо больше, чем затея использовать последние веб-технологии так, как этого никто не делал прежде. Это также и сочетание многих других проектов Mozilla как единственное виденье — Web как платформа. Open Web Apps initiative и Persona являются одними из таких проектов, нашим решением в области идентификации и авторизации в интернете (известным под официальным именем «BrowserID»). Удивительно наблюдать, как большое количество проектов от Mozilla сливаются в одно целое.

Я больше не буду вдаваться в мелкие подробности, больше информации вы можете найти на страницах MDN о Firefox OS. Очень рекомендую почитать.

Почему Firefox OS?


Вы наверняка думаете: «Звучит отлично, но почему именно JavaScript?» Это действительно хороший вопрос. Существует множество причин, по которым лучшим решением стала разработка мобильной ОС на JavaScript.

Две основных причины заключаются в том, что Firefox OS заполняет пробел и создает альтернативу текущей проприетарности и ограничениям на рынке мобильных платформ.

Заполнение пробела на рынке мобильных платформ

Ни для кого не секрет, что смартфоны часто просто до смешного дорогие, даже в тех странах, где уровень дохода достаточно высок. Но если вы думаете, что такие цены существуют только в богатых странах, то вы глубоко ошибаетесь. 16GB iPhone 4S в Бразилии стоит около 615 фунтов стерлингов, что на 100 фунтов дороже чем такой же телефон в Англии!

Такие цены в Бразилии обусловлены высоким налогом на импорт. Судя по всему, Apple уже работает над устранением этой проблемы, планируя построить местные производственные линии в стране. Несмотря на это, данный случай прекрасно дает понять, что хороший смартфон многим не по карману. Не говоря уже о том, что в некоторых странах вам лучше не размахивать смартфоном, стоимость которого равна стоимости небольшого автомобиля.

Так что же делать, если вы хотите получить хороший смартфон и при этом не тратить на него огромную сумму? Можете купить дешевый смартфон на Android, но такие, как правило, работают плохо и постоянно тормозят.

К счастью, теперь у нас есть Firefox OS…

Цель Firefox OS заключается не в создании конкуренции high-end устройствам, а в том, чтобы предложить смартфоны начального и среднего уровня по цене обычного мобильного телефона.
Bonnie Cha


Firefox OS прекрасно подходит для этого. Эта ОС может предложить вам полноценный смартфон на основе устройства с низкой производительностью, что сравнимо с Android на устройстве среднего класса. И это не шутка.

Для примера, в настоящее время я тестирую JavaScript игры на телефоне за 50 фунтов. От устройства по такой цене многого ожидать не стоит, но на самом деле эти игры не только работают быстрее, чем на таком же телефоне с Android запущенные в браузере (Firefox или Chrome), но и так же быстро, если не быстрее, чем на Android устройствах цена которых в 4-5 раз больше.

Почему же происходит такой прирост производительности в сравнении с результатами работы в браузере Android на одинаковых устройствах? Секрет в быстром обмене данными между Gecko и железом, что дает возможность JavaScript работать очень быстро.

Высокая производительность JavaScript на дешевых устройствах стала для меня одной из причин, по которой я уверен, что Firefox OS — это начало чего-то огромного.

Должен отметить, что Mozilla не обязательно будет запускать ОС с телефонами стоимостью в 50 фунтов, это устройство мы используем для разработки и тестирования.

Альтернатива и открытая платформа

Вторая причина «Почему Firefox OS?» — это попытка не только создать альтернативную и открытую мобильную платформу, но и противостоять и попытаться повлиять на крупных игроков рынка.

С момента основания Mozilla в 1998 как разработчика ПО и позже как компании и организации, нашей миссией было создание открытых технологий, которые могут соревноваться с доминирующими корпоративными продуктами.
Steve Lohr


Mozilla пытается повторить свой успех с Firefox, который буквально ворвался на рынок браузеров и показал пользователям, что существует альтернатива, что они могут контролировать то, как они используют веб.

Теперь это мобильный веб, который находится под угрозой. И угроза исходит не от Microsoft, но от Apple и Google, производителей ведущих мобильных платформ. Их приложения, закрытые платформы, проприетарные магазины приложений и весьма капризные правила для разработчиков. Apple и Google только усугубляют положение веб-технологии.
Thomas Claburn


Одна из главных областей, которая нуждается в развитии — портативность приложений…

Весь ажиотаж вокруг мобильных приложений, в некотором смысле, есть шаг назад: они приковывают пользователей к определенной ОС и устройствам, что ее поддерживают. Веб эволюционировал и пришел к тому, что на любом железе он может восприниматься одинаково.
Mozilla, создатель веб-браузера Firefox, полна решимости сделать то же самое и для мобильных устройств.
Don Clark


Firefox OS стремится использовать вездесущность веб-технологий, чтобы дать вам возможность пользоваться одними и теми же приложениями на вашем смартфоне, ПК, планшете и любом другом устройстве, имеющем браузер. Разве не хотели бы вы иметь возможность продолжить игру в Angry Birds на десктопе с того места, где закончили ее на своем смартфоне? Я бы очень этого хотел!

Мечта разработчика

Еще одна причина, почему нам нужна Firefox OS — в данный момент не существует ОС, которую можно было бы легко редактировать (можно немного изменить Android, но это сделать не так просто).

Firefox OS построена целиком и полностью на HTML, JavaScript и CSS. Имея базовые навыки веб-разработки, вы можете полностью изменить всю ОС. Редактирование одной строки CSS может повлиять на способ расположения иконок или их форму, или же вы можете изменить JS, который обрабатывает телефонные звонки.

Эта платформа уникальна для разработчиков, и мне очень интересно знать, что они сделают с ней и к чему это приведет.

Удачный момент


Работая вот уже полтора года в Mozilla, я осознал, как мне повезло оказаться здесь именно в момент рождения Firefox OS. Если я все правильно помню, то проект был анонсирован (как Boot to Gecko) в первые несколько недель моей работы в компании.

Все было восхитительно, но со временем стало еще более восхитительно. Firefox OS — приоритет номер один в моей работе на данный момент, и честно говоря, мне это нравится. Это большая честь быть частью такого проекта.

Я много раз задавался вопросом: это восхитительное чувство — похоже ли оно на то, что испытываешь работая в Mozilla во время запуска Firefox? Волнение, страсть, нервозность и неспособность объяснить, насколько все это удивительно, и почему кого-то это должно волновать.

Честно говоря, я не думаю, что многие до конца понимают, что на самом деле значит для всех запуск Firefox OS. Так же, как и Firefox, я полагаю.

В данный момент я счастлив работать в Mozilla, в столь интересный период в жизни компании.

Восхищенные


Люди, которые осознали всю важность этого проекта — разработчики. Они держали в руках демо-устройства сотрудников Mozilla на наших ивентах. И мало что может быть так захватывающе, как возможность наблюдать за этими людьми пока они исследуют устройство и переживают различные эмоции…

  1. Все начинается с легкой растерянности — «Вы дали мне Android? Это очень похоже на Android.»
  2. Далее приходит внезапное осознание того, что это не Android и что система построена на JS.
  3. После небольшой паузы следует что-то вроде «Твою ж мать!»
  4. Еще немного и человек полностью погружается в систему, изучая все ее углы.
  5. Последняя стадия — нежелание расставаться с устройством, когда я прошу его обратно и финальное «Это очень неплохо, я удивлен!»


Вы можете подумать, что я лишь расхваливаю проект, чтобы всем казалось, будто это очень захватывающе. Но на самом деле так реагировали многие. Забавно было за этим наблюдать.

Из того, что я видел, как люди реагировали на Firefox OS, я понял, что она изменит многое. Все настолько восхищены, что, мне кажется, никому ничего и не нужно объяснять.

Проблемы


Было бы несправедливо все время хвалить Firefox OS, не упомянув о некоторых проблемах, которые нам нужно решить.

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

Больше всего меня интересует проблема HTML5 игр на мобильных устройствах — восприятие и производительность, на что разработчики часто жалуются. Эта проблема не принадлежит сугубо Firefox OS (Android и iOS так же плохи в этом), но сейчас я целиком сосредоточен на ней и на проблеме производительности.

Большинство ранее созданных мобильных HTML5 игр работают очень медленно (0—20FPS), или чуть быстрее (20—30FPS). Часто эти игры имеют нестабильный FPS, что заметно ухудшает игровой процесс.

Интересно, что многие проблемы не обязательно связаны с устройством или JavaScript. Есть несколько тяжелых игр, таких как Biolab Disaster. Эта игра идет отлично даже на том же телефоне за 50 фунтов (40—60FPS).

Для меня совершенно ясно, что иногда устройство и платформа могут быть причиной низкой производительности в играх (не так часто, как некоторые думают). Мы можем почерпнуть многое из игр, которые отлично работают на слабых устройствах. Изучить техники и приемы, которые использовали разработчики, и рассказать о них тем, кто собирается работать с HTML5 играми для мобильной платформы.

Я искренне верю, что тяжелые HTML5 игры могут отлично работать на любых устройствах, даже на самых слабых. Почему я так уверен? Потому что люди уже сегодня делают такие игры. Есть две вещи, которым я доверяю больше всего в своей жизни… мои глаза.

Не только мобильные телефоны


Больше всего я взволнован не тем фактом, что Firefox OS будет установлена на мобильном устройстве, которое мы выпустим в следующем году, а тем, что будет в будущем. Я затронул эту тему ранее, когда говорил о «мечте разработчика», как другие могут расширить границы использования ОС.



И это происходит уже сегодня. У нас уже есть Firefox OS портированная на Raspberry Pi и Pandaboard. Они не идеальны, но что круто (я очень старался избежать этого слова), так это то, что все это происходит задолго до первого релиза.

Уже есть возможность опробовать Firefox OS на Mac, Windows и Linux. Конечно же, у вас не будет доступа ко всем функциям, которые есть в смартфоне, но все же вы сможете кое-что попробовать (например, приложения, работающие параллельно). Установка системы довольно проста.

Я могу только представить тот недалекий день, когда Gamepad API появится в Gecko и будет доступен на десктопном клиенте Firefox OS. Что в этом такого? Ну, не так уж сложно представить себе устройство, подключенное к телевизору, с ОС настроенной для работы с геймпадом вместо мыши или сенсора (и это все JavaScript, помните).

Это послужит началом эры консолей для HTML5 игр, и это то, над чем я работаю в свое «свободное» время за пределами Mozilla.

Я хочу сказать, что мы подходим к тому моменту, когда многие устройства смогут работать на тех же технологиях, что мы обычно используем для создания веб-сайтов. Так что же мы можем сделать с миром, полным устройств, работающих на базе технологий, которые везде могут получить доступ и обмениваться данными, используя одни и те же API?

Я отчаянно хочу увидеть этот мир!

Переведено и опубликовано с разрешения автора.

Автор с радостью ответит на все вопросы о Firefox OS. Писать в эту ветку.

Полезные ссылки:
Поделиться публикацией
Похожие публикации
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 297
  • +102
    Такой оптимист этот автор.
    • +36
      Положительно заряженный автор!
      • +26
        Не оптимист, а евангелист.
        • –15
          i.e. врун
          • 0
            Я этого не говорил.
            В данном случае, возможно, скорее зеалот.
            • +6
              По-русски пишется «зелот» от древнегреческого «ζηλωτής».
              • –1
                Zealot?
                • +13
                  Да, есть такое английское слово. Но (я надеюсь) Вы же не пишете «ивэнджелист» вместо «евангелист»? А почему? Да потому, что все вероисповедные термины были заимствованы из греческой речи вот ужé тысячу с лишним лет назад. Так и с зелотами.
                • +6
                  А почему не «зилот»?
                  • +1
                    О да, спасибо, «зилот» даже вероятнее.

                    Но, во всяком случае, не «зеалот».
                      • +1
                        Не путайте Гоголя с Гегелем, Гегеля с Бебелем, Бебеля с Бабелем. :)

                        Обе страницы — и «зелоты», и «зилоты» — объединены перекрёстными ссылками с призывами не путать эти термины. Слово же, лежащее в основе их обоих, одно и то же. Вся тонкость заключена в произношении буквы «η», различающимся для древнегреческого и новогреческого языков.
                        • +1
                          … а кобеля от суки. Сорри, не удержался, анекдот хороший :-)
                          • +1
                            Спасибо! Я догадывался, что кто-нибудь не удержится.
                      • 0
                        Вообще в английской транскрипции "zealot" читается как «зелот», но никак не «зеалот».
          • +13
            Очень интересно, однако все еще осталось недопонимание. Кто будет делать смартфоны под эту ОС? Кто будет делать приложения под эту ОС? Как с портированием на другие платформы, на других осях для доступа к системе чаще всего нужен PhoneGap. Огромный вопрос про гайдлайны, они есть? Все таки, когда каждое приложение выглядит по своему, это печально. И возможно мне показалось, но отзывчивость интерфейса желает желать лучшего.
            • +2
              Пока только TCL Communication Technology (Alcatel) и ZTE. Первый такой телефон будет выпущен в Бразили, в начале следующего года. Приложения можем делать и мы с вами. Здесь список всех устройств, на которых уже сейчас можно запустить Firefox OS. Гайд по портированию. Немного информации о разработке приложений. Гайдов по UI судя по всему пока нету, но думаю, что скоро будут, если уже в следующем году первые устройства будут в продаже.
              • +4
                Вот гайд по UI если что — wiki.mozilla.org/Gaia/Design/BuildingBlocks

                Вообще, большая часть информации о Firefox OS находится в wiki, а не в mdn.
                • 0
                  Отлично, спасибо!
                  • +1
                    Добавьте ссылки в футер статьи, если не сложно.
                    И апдейт про автор ответит на вопросы тоже (можно даже указать начало ветки, чтобы вопросы были сразу видны).
                    • +1
                      Сделано. Спасибо за совет!
              • 0
                А зачем выпускать специальные нелефоны для открытой платформы? Чем вам не хватает продающихся дешевых android смартфонов по 100-300 баксов, родная ось на которых тормозит?
                • +4
                  Обыкновенный пользователь дешевых тормозящих Андроидов никогда не займется самостоятельной переустановкой Адроида на xxxOS, чем бы xxx не был.
                  • +2
                    О, вы, видимо, не слыхали пословицу «все юзеры делятся на яблокофилов, виндофономанов, андроидолюбов и спиководов» (не точно).
                    Соль в том, что Samsung выпустила телефон i5700 Galaxy Spica, 3.5 дюйма экран, туча аппаратных кнопок, andriod 1.4.
                    В телефоне был 800 МГц samsung процессор и даже видеочип, под который, кстати, так дровы и не написал никто, даже производитель.
                    Андроиды развивались, а «спику» продавать было жалко в силу ее удобства и адекватности цены.
                    Тогда начались кастомы. ЧТо народ только ни придумывал, чтобы сделать из спики полноценный девайс на 2.х андроиде. И успехов было много. Но везде были глючки, подвисоны, перезагрузки.
                    Вплоть до того, что одна и та же прошивка на 10 устройствах вела себя по-разному.
                    Это провоцировало пользователей на постоянные перепрошивки всеми известными способами.
                    Сам пол года владел чудо-девайсом, лиш примерно раз в месяц, иногда чаще. В итоге так и не нашел компромисса и продал другу, который шил спику еще чаще, но компромисс таки нашел.

                    Еще хороший пример — HTC HD2, который изначально оснащен WM6.5, но работает как на Andriod, так и на WP7. И некоторые товарищи даже держат по две прошивки одновременно и по настроению пользуются попеременно.
                    • +8
                      Про что вы только что написали этот пост? Если про обычных пользователей, то вы точно ошиблись.
                      • +4
                        Да, как недавно я для себя выяснил, обычные пользователи ходят в салон сотовой связи что бы установить на айфон игрушку, три кнопки на экране им не нажать.
                        • 0
                          Устроились на работу в салон сотовой связи? (:
                      • +2
                        Я купил в свое время Спику, один раз прошил официальной прошивкой от Самсунга на 2.1 и вот уже третий год пользуюсь без нареканий. Я — обычный пользователь или нет?
                      • 0
                        А что до «обычный пользователь», то открытые платформы и обычный пользователь — не слишком рядом.
                        • 0
                          Андроид тоже открытая платформа. И? Вы считаете, что телефоны на Андроиде покупают только и исключительно гики?
                          • +2
                            Андроид я бы назвал максимум условно-открытой.
                            • +1
                              Я к тому что обычному пользователю побарабану. А если вы не обычный пользователь и хотите допиливать — вас не смутит дешевый девайс. Скорее наоборот.
                      • 0
                        С портированием, кстати, всё очень просто. Например, с помощью Appcelerator.
                      • +53
                        В общем стоит с высокой вероятностью ожидать, что они достойно реализуют запатентованную в андроиде технологию динамичного подтормаживания интерфейса.
                        • +10
                          Думаете, Гугл их засудит?
                          • +1
                            Все необходимые патенты уже закуплены :)
                            • +19
                              Как владелец Nexus, могу с уверенностью сказать в 4.1 Google отказался от патента «динамичного подтормаживания интерфейса.». Mozilla может его бесплатно использовать
                              • 0
                                Любопытно, что сторонние сборки, включая известный Cyanogen, продолжают использовать эту популярную технологию, и по какой-то неизвестной причине не могут от неё полностью отказаться. Говорю, как владелец Nexus с CM10.
                                • +1
                                  ArtRoman — так а кто вас заставляет их использовать? Меня ВСЕ устраивает в ванильном 4.1 (лукавлю, все кроме поисковой строки сверху) и даже не нужно Apex и Nova. Тут уж вам решать или рюшечки в виде профилей и тп или стабильность и плавность интерфейса. Я за второе. Поэтому Сток рулит и заруливает))
                                  • 0
                                    Никто не заставляет, и Nova стоит и устраивает. И профили не нужны, но вот одной функции не хватает, которая совсем уж могла бы быть в дефолтном андроиде — переключение треков по долгому нажатию клавиш громкости, это просто очень удобно при прослушивании музыки через проводные наушники.
                                • 0
                                  Как владелец Nexus (7) могу с уверенностью сказать, что в 4.1 действительно отсутствует фича подтормаживания, но в 4.2 они исправили этот досадный баг, и 4.2 (у меня, по крайней мере) тормозит иногда похлеще, чем старенький андроидофон.
                          • +7
                            А эта ОС случайно не нарушает патент Apple на иконку настроек в виде шестерёнки?
                            • +1
                              я больше подумал что круглые иконки нового nano
                              • +3
                                Я вот не уверен в том, что в Бразилии существует патент на значок шестерёнки.
                                • +1
                                  Иск к Фонду Мозиллы в Штатах, правда, теоретически возможен, но на практике породил бы массовую неприязнь к истцу и никакой существенной выгоды.
                                  • +1
                                    Не думаю, что Фонд Мозиллы будет получать прямую прибыль от продаж ОС, следовательно и иск к ним выдвигать не будут
                              • –1
                                Очень странно выглядит привязка телефона именно к цене. Хотелось бы все же увидеть ТТХ этого девайса «за 50 фунтов». Для примера — за такую сумму можно взять андроидофон с 1ГГц процессором и 256 Мб памяти.
                                • НЛО прилетело и опубликовало эту надпись здесь
                                  • +13
                                    Автор сектант.
                                    • +13
                                      Даже на видео видны тормоза интерфейса. А что будет на смартфонах за 50 баксов? Их начнут ненавидеть, как и саму ось.
                                      • +2
                                        Там распери пи.
                                        Кроме того видно что лагает сам скринкастинг.
                                        • +3
                                          Слушайте, а вы не думали, что лагает из-за того, что это тот самый Otoro device за 50 баксов и на нём ОС которой ещё и года нет?
                                          • 0
                                            Ну если сейчас они не заложат аппаратное ускорение графики и JS, то потом это будет сделать невозможно. Вот и первое впечатление можно сильно подпортить.

                                            Причем возможна та проблема, что есть у Андроида, но нет у Айфона — поддержка всего зоопарка оборудования. Тут либо строгая сертификация, либо только одна заточенная платформа. В топике про разработку игр под Андроид видели фотографию стола с сотней девайсов на Андроиде?
                                            • +2
                                              Аппаратное ускорение там и так присутствует, другое дело, что какие другие участки кода не оптимизированы.

                                              Кучу аднроид фонов видел. Только не могу понять причём тут конечный разработчик под FxOS. Вы спокон веков делали сайты под разные мониторы. Responsive Design это не так сложно как кажется.

                                              На счёт сертификации возможно вы правы и вендорам устройств придётся подстраиваться под ту архитектуру, что будет. Но хочу напомнить, что Mozilla это некоммерческая организация, Apple или Google. И всё, что они могут это только сотрудничать с заинтересованными вендорами.
                                        • 0
                                          Текст писал не Стив Джобс? Ну, в смысле, вы поняли. Могут быть проблемы с Apple из за воспевающего стиля описания продукта)
                                          • +4
                                            как то в последнее время в html5 в качестве платформы для мобильных приложений стали разочаровываться… вон, и Цукерберг заявил, что отныне все аппы для фейсбука будут нативными.
                                          • +2
                                            Звучит не плохо, однако не совсем понятно как будет реализована система безопасности firefox OS. Сегодня, это основная проблема как мобильных ОС так и веб. Если они предложат нечто революционное в этой области, то как раз это и будет настоящим прорывом.
                                            • +2
                                              Дайте авторам помечтать, единый DOM на всю систему и возможность подменить из любого скрипта любую функцию системных js-объектов, это ли не торжество гибкости и открытости.
                                              • 0
                                                С документацией о безопасности можно ознакомится здесь.
                                              • +13
                                                ОС должна быть на Си и асме. Точка. И не только ядро, но и гуи.
                                                Хуже яваскрипта в эмбеддед могут быть только системные демоны на питон.
                                                • –7
                                                  Современные джаваскриптовые движки не так уж и уступают Си по скорости.

                                                  А придёт IonMonkey — вообще веселье начнётся.
                                                  • –1
                                                    Я даже больше скажу. В андроиде вон Java. И не тормозит. Браузер в андроиде. На Java. И тоже не тормозит.
                                                    В B2G (уж извините, называю по старинке) Gecko на нативном коде. Почему он должен тормозить?
                                                    • +13
                                                      Браузер в андроиде не на java. Он на webkit который является компонентом системы и выполняется в нативном коде.
                                                      • 0
                                                        Ну в таком случае сорри.

                                                        Но всё равно — если не тормозит webkit на нативном коде, то почему должен тормозить gecko?

                                                        P. S. А огнелис под android тоже на нативном коде?
                                                        • 0
                                                          то почему должен тормозить gecko?

                                                          У них местами движок более тяжелый, необходимо оптимизировать.

                                                          А огнелис под android тоже на нативном коде?

                                                          Насколько знаю да. NDK доступно под Android давненько.

                                                          • 0
                                                            Под Android и FxOS движок Gecko естественно немного другой и очищен от всякого лишнего кода и XUL, так как там нет надобности поддерживать всякие WinXP и древнее.
                                                            • 0
                                                              Ну что касается XUL, я сомневаюсь. Кажется, в Gaia UI было что-то на xul…
                                                              • 0
                                                                Я писал там email приложение для Gaia, нет там никакого XUL. Это на десктопе есть используется XUL window для запуска Gaia, а на FxOS даже иксов не будет.
                                                                • 0
                                                                  Да, сейчас посмотрел, ничего похожего не нашёл.
                                                                  Видимо это и правда в десктопном варианте было :)

                                                                  Зато обнаружил WebGL в галерее).
                                                          • 0
                                                            Конечно в нативном. Не так просто взять и переписать 150Мб кода из c++ в java.
                                                            • 0
                                                              Вы конечно правы, но API ведь везде разное. В win — всякие WinAPI, в маке — это Carbon (для c++).

                                                              И в этих 150 мб нужно было как минимум две трети портировать на новую платформу.
                                                        • 0
                                                          И я также больше скажу: есть средства для компиляции Си и Си++ в JavaScript. Из которых наиболее известен Emscripten.
                                                          • +2
                                                            Ну давайте вы переведёте код на C/C++ в JS и запустите его в IonMonkey, а я скомпиляю его посредством ICC с -O3 IPO и PGO. А потом сравним производительность ;-)
                                                            • 0
                                                              В JS вообще компилится всё, что не лень: Ruby, Python, perl, scala, java, c#, даже lisp и haskell.

                                                              Ну, собственно, ссылка: github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
                                                            • +5
                                                              Не тормозит? Java не тормозит? Ну и шутки у Вас…
                                                              • +1
                                                                Вспомните Томми: иногда и вправду не тормозит.
                                                          • +11
                                                            GUI на C и асме? Что вы курите?
                                                            • –4
                                                              Ничего. МакОС, вынь, кде, гном= гуй си + асм.
                                                              • +7
                                                                В МакОСи Objective-C, который от C и асма достаточно далек.

                                                                KDE — это Qt, который от C и асма тоже весьма и весьма далек (вплоть до аналога GC на подсчете ссылок).

                                                                • +1
                                                                  Гном — гуй на js.
                                                                  • 0
                                                                    Ну будет точнее сказать gnome 3 (gnome shell и gnome classic).

                                                                    Используется gjs, внутри spidermonkey
                                                                  • +3
                                                                    смысл не в языке, а в минимуме прослоек.
                                                                    • –2
                                                                      Эта фраза абсолютно бессмысленна.
                                                                    • 0
                                                                      Ну, всё же подсчёт ссылок — это далеко не GC.
                                                                      • +2
                                                                        Я знаю. Просто в Qt можно делать что-то типа такого:

                                                                        QWidget1 *a = new QWidget1();
                                                                        QWidget2 *b = new QWidget2();
                                                                        QWidget3 *c = new QWidget3();
                                                                        QWidget4 *d = new QWidget4();
                                                                        
                                                                        d -> addWidgets(a,b,c);
                                                                        
                                                                        // и потом вообзе в друго месте
                                                                        
                                                                        delete d;
                                                                        
                                                                        


                                                                        И оппа. Все само собой почистится и, если надо, из памяти удалится :)

                                                                        Я это называю «GC для бедных». Потому что в общем и целом программировани с использованием Qt ничем не отличается от программирования на Java/.NET. Программист по возможности максимально огорожен от каких-либо низкоуровневых действий.

                                                                        Но из-за того, что это С++, у некоторых людей начинаются непроизвольные оргазмы «это же!!! С++!!!» :) Хотя оно работате со скоростью того же дотнета :)
                                                                        • 0
                                                                          В приведенном примере структура напоминает дерево. Если один виджет владеет остальными и может их удалить в деструкторе, то это ни разу не GC. Это как приводить в пример связный список и говорить что это GC.
                                                                          Также, имея С++, можно в нужных местах писать производительный код… + использовать различные библиотеки в местах критичных к производительности тоже надо с умом, тогда все с производительностью будет в лучшем виде.
                                                                          • 0
                                                                            Я и это знаю :) Я веду к тому, что Qt максимально изолирует разработчика от низкоуровневости C++. Код с использованием Qt мало чем отличается от кода, написанного на дотнете, наример. При этом использовать низкоуровневые вещи (да даже и высокоуровневые, типа шаблонов) достаточно опасно, потому что можно порушить всю эту хрупкую красоту.

                                                                            А производительность Qt — ну так, так себе.

                                                                            > использовать различные библиотеки в местах критичных к производительности тоже надо с умом, тогда все с производительностью будет в лучшем виде.

                                                                            Ну так это относится не только к Qt ;) Никто не мешает в критичных к скорости кусках на Ruby/Python/.NET/вставить_свое использовать библиотеки на С/С++ ;)
                                                                            • 0
                                                                              Я просто обычно использую Qt для связи с интерфейсом и т.п., а если в процессе появляется например необходимость обсчитать какую-нибудь рабочую область какого-нибудь невероятного устройства или проложить какой-нибудь хитро-выделанный маршрут на невероятных размеров карте, то создаем обычный класс и, никуда не переключаясь, в C-style пишем все быстро и оптимально. Идеологически это конечно не совсем тру, но «какого черта, мне надо чтобы программа в этом месте выжала максимум из компьютера!» :)
                                                                              На той же яве реализовать такой подход было бы ИМХО труднее.
                                                                              P.S. Использую Qt в исследовательских проектах и для мат. моделирования… вполне встречаются ситуации, когда программе надо даже в виде сишных массивов отожрать гиг-другой памяти и активно его колбасить. Зато если надо что-нибудь сделать с интерфейсом или отображением, или не критичный к производительности алгоритм, то также не напрягаясь можно сделать это используя всю мощь Qt.
                                                                              • 0
                                                                                Ну, то есть, мы по сути достигли с вами консенсуса и взаимопонимания :)
                                                                                • 0
                                                                                  Вполне :) В двух словах: я пытался донести мысль, что при правильном применении, выигрыш в производительности софта при использовании С++ и Qt совсем не мифический.
                                                                          • 0
                                                                            Ну и как этот подсчет ссылок влияет на скорость работы если эти все видгеты разрушаются один раз и одновременно? При закрытии окна приложения еще скорее всего к тому ж.
                                                                            • 0
                                                                              Там помимо подсчета есть много чего другого ;) Собственно сам GUI, сигналы/слоты, сделанные, по сути, на коленке
                                                                            • 0
                                                                              В данном случае это даже не подсчёт ссылок. QObject может иметь родителя и только одного. Родитель знает обо всех своих детях. При собственнос уничтожении, он уничтожает и детей. Логика простая.

                                                                              PS да, я тоже люблю Qt. А ещё COW замечательная штука.
                                                                          • –1
                                                                            в конечном счете — все на асме :-))
                                                                        • –9
                                                                          Меня вообще умиляют всякие вендройд-пейсатели, которые не знают даже, как на ARM'е прибавить к переменной в памяти значение (на асме). Как блеадь можно программить, если ты не знаешь, что происходит с твоим кодом на уровне железа. Не знаю как для вас, но для меня это абсолютный нонсенс.
                                                                          • +7
                                                                            Это может вам не нравиться, но это цель, к которой ведет прогресс в языках программирования.
                                                                            Наращивают уровни абстракции, вытесняя низкоуровневое — когда-то на асме писали все, потом его вытеснили до уровня вставок, сейчас вытеснили почти полностью, причем даже из эмбеддед, на его место пришел «среднеуровневый» С.
                                                                            Даже С++ из прикладного активно вытесняется, добавляя еще один уровень абстракции в виде ВМ — явами, дотнетами, даже теми же питонами.

                                                                            • –1
                                                                              Вытеснили-не вытеснили это я могу поспорить. Берем ffmpeg и какой-нибудь абстрактный MIPS-процессор от всем известного кетайского ноунейма. Девайс — ну пусть будет электронная книжка. И что же мы видим в ffmpeg? Тонны SIMD инструкций на асме, типа конвертации цветов, ресайза и прочего. И так много где в разных девайсах. Вендройд и iOS не беру к рассмотрению, так как относительно первого руки опускаются а относительно второго сорцов нет.

                                                                              Я понимаю, что против течения плыть смысла нет, и если что-то нужно нопейсать на андройде, то выбора особого нет. Но с другой стороны, возможно хорошо, что есть такие как я, которые если видят очередной калькулятор размером в 50 мегабайт, отжирающий для своей работы метров 200 оперативы, у них просто нет слов.
                                                                              • +2
                                                                                >Вендройд и iOS не беру к рассмотрению, так как относительно первого руки опускаются а относительно второго сорцов нет.

                                                                                Это и значит что вытеснили. Количество мест где он остался катастрофически мало — ну да, в кодеках где-то в глубине может остаться. Но количество таких мест сокращается. Не говоря уж о том, что все больше таких жрущих вещей интегрируют на аппаратном уровне в SoC, те же кодеки.

                                                                                >Но с другой стороны, возможно хорошо, что есть такие как я, которые если видят очередной калькулятор размером в 50 мегабайт, отжирающий для своей работы метров 200 оперативы, у них просто нет слов.

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

                                                                                А скорость разработки (и отладки и рефакторинга) сильно падает со снижением уровня языка.
                                                                                • +2
                                                                                  Задачи обработки видео очень специфичные!

                                                                                  Трудно что-то поделать с современной разработкой ПО — уже почти никто не заботится о том, чтобы программа нормально работала на устройстве пользователя, мой любимый пример — разница в скорости работы 2008 и 2010 MS VS. Даже в MS при разработке конечного несистемного продукта не особо думали об экономии, чег ждать от кустарных разработчиков или из них поднявшихся — коих большинство среди Android девелоперов.
                                                                              • +5
                                                                                > Как блеадь можно программить, если ты не знаешь, что происходит с твоим кодом на уровне железа.

                                                                                Ну-ка ну ка. Вы точно знаете, во какие инструкции оптимизирующий компилятор разворачивает ваш код на разных процессорах? На x86? На ARMе? С набором инструкций SSE2? SSE3? С оптимизацией по скорости? С оптимизацией по размеру?

                                                                                Да нифига. Вы даже близко не имеете представления.
                                                                                • –3
                                                                                  А если таки имею представление? На ARMе мало пишу, поэтому тут да, точно не знаю. А вот с x86 могу с вами поспорить. Когда я пишу код на высокоуровневом языке, я имею четкое представление во что он компилируется на асме. И да, я знаю как будет с оптимизацией по скорости или по размеру. Матрицы между собой не множу, поэтому SSE2, SSE3 не использую.
                                                                                  • +1
                                                                                    > А если таки имею представление?

                                                                                    Тогда вы входите в 0.01% разработчиков. Не потому что разработчики тупые, а потому что оптимизирующие компиляторы слишком умные и стандарты слишком огромные.

                                                                                    > Когда я пишу код на высокоуровневом языке, я имею четкое представление во что он компилируется на асме.

                                                                                    Вот насчет четкости я очень сильно сомневаюсь. Хотя, повторю, вы можете входить в 0.01% разработчиков, которые досконально знают стандарт соответствующего ЯВУ и все особенности целевой платформы.

                                                                                    А для использования SSEx и не надо матрицы перемножать.
                                                                                  • +8
                                                                                    Это правда. Но я могу хотя бы примерно примерно оценить сверху скорость выполнения отдельных участков кода БЕЗ профайлера, потому что примерно знаю какой код С++ как реализован. Я точно знаю где происходит аллокация и деаллокация. Я точно знаю это и могу рассматривать детерминированные сценарии использования памяти. Я не боюсь, что в какой-то момент запустится мусоросборщик и всё зависнет.

                                                                                    Наконец, все вот эти вот фразы, что «у нас всё работает не медленнее чем на С или С++» — это как правило значит, что люди серьёзные приложения не сравнивали. Ну быстрее работает неинтерпретированный код. Быстрее. И не только потому, что оптимизирующий С++ компилятор имеет больше времени на оптимизации, чем JIT. Сама структура языка предполагает более детерминистский подход к программированию. Это сложнее, да. Но если этим правильно пользоваться, то будет реально быстрее.

                                                                                    Мне ОЧЕНЬ не хватает нормальной поддержки С++ на Андроиде. Мне будет точно также не хватать её в этой ОС. Я ещё понимаю, если бы скорость девайсов была такая, что интерпретированность не чувствовалась. Так ведь нет же: берут слабую железку, заставляют писать на высокоуровневых и менее эффективных (с точки зрения исполнения) языках. При этом ещё обрубают высокоэффективные средства разработки на С++.

                                                                                    Ну и наконец, вся эта хвалёная стабильность систем на Яве. Всё это на практике виснет, глючит и падает ничуть не меньше, чем нативный код. Программы с утилитами точно также глючат, при этом ещё съедают гораздо больше памяти.

                                                                                    Тогда спрашивается — НАФИГА было затеваться с Явой?
                                                                                    Ну сделайте вы систему открытой. Допилите под неё gcc и прочее. Остальные постепенно подтянутся.
                                                                                    Пусть кто на чём может, тот на том и будет писать. Кто не может или не хочет С++, пусть пишет на Яве, Яваскрипте, да хоть брэйнфаке.

                                                                                    Что это за дурацкие проприетарные ограничения, которые выдаются гигантами за охрененно продвинутый современный подход, которые к тому же плохо себя показывают на практике?
                                                                                    • +4
                                                                                      Вот действительно. У меня недавно умер HTC Inspire 4G, хожу опять со старым HTC Herald под WM 6.5, с 200мгц процессором и 64 мб оперативки. И ничего, все работает достаточно шустро, оперативки хватает на 3-5 приложений, потому что тогда заботились об оптимизации, а сейчас — нет.
                                                                                      • 0
                                                                                        А джаву вообще-то пилили — был такой проект, gcj, так он компилировал джава-код до версии 1.5 в нэйтивы с использованием как раз-таки gcc, как я понимаю. К сожалению, его забросили, а значит это не пользовалось спросом.
                                                                                        А вообще с джавой есть смысл затеваться. Она намного комфортнее и быстрее для разработки, чем любой другой язык старше ее из мне известных. И всем пофигу, что она где-то может быть не так эффективна в исполнении. 5 лет назад, я бы сказал, что на джаве гораздо сложнее сделать критические ошибки, чем на сях. Теперь я думаю, что и джава плохой язык, потому что они тоже зафиксировали стандарт — теперь надо переходить на следующий уровень — котлин, например.
                                                                                        • 0
                                                                                          > люди серьёзные приложения не сравнивали

                                                                                          Что такое «серьезные приложения»?

                                                                                          > Тогда спрашивается — НАФИГА было затеваться с Явой?

                                                                                          Потому что они хотели больше контроля над системой, например?
                                                                                          • +2
                                                                                            Ява даёт больше контроля над системой, чем С++? Я верно понял ваш тезис?
                                                                                            • 0
                                                                                              Ява может дает больше контроля производителю над тем, что понапишут горе-программисты :)
                                                                                              • 0
                                                                                                Что такое «контроль производителя»?
                                                                                                • 0
                                                                                                  Что разработчик не сожрет память, не оставить память течь и т.п.
                                                                                                  • +2
                                                                                                    В С++ при правильном подходе у разработчика также будет изъята возможность устраивать проблемы с памятью (я писал об этом статью в своё время).
                                                                                                    Я также утверждаю, что эти проблемы решить куда проще, чем проблемы многопоточности, проблемы неверной логики работы алгоритмов, проблемы покрытия различных ситуаций (включая нештатные). Ява здесь не решает вообще ничего по сравнению с С++.
                                                                                          • +1
                                                                                            > Но я могу хотя бы примерно примерно оценить сверху скорость выполнения отдельных участков кода БЕЗ профайлера

                                                                                            Аналогично для любого ЯВУ :-\ Потому что на первом месте алгоритмы, а потом уже то, во что оно компилируется. Только вот профайлер потом покажет, что проблема в БД, сети, доступе к диску — и это задолго до того, как начнутся проблемы в нативном/интерпретируемом коде (для большинства прикладных задач).
                                                                                            • +2
                                                                                              Профайлер вам не покажет, что вообще ВСЁ в Яве делается медленнее, чем в С++. Начиная от обращения к переменной, и заканчивая работой с динамической памятью. Вы лишь увидите наиболее относительно медленные участки. Вот только относительно чего? Вы же не уберёте мусоросборщик, не поменяете внутреннюю логику работы с переменными (там где С++ работает со стеком процессора, меняя всего один его регистр).
                                                                                              И здесь я даже не говорю про память. А на этом стоило бы остановиться подробнее.
                                                                                              Но — зачем? Вы пришлю сюда заранее уверенным в том, что Ява может быть не медленнее С++. Нужно ли мне тратить время на разубеждение? Не вижу смысла.
                                                                                              • +1
                                                                                                > Вы пришлю сюда заранее уверенным в том, что Ява может быть не медленнее С++.

                                                                                                Нет. Как всегда, на хабре люди не умеют читать. Вот, что я написал:

                                                                                                Только вот профайлер потом покажет, что проблема в БД, сети, доступе к диску — и это задолго до того, как начнутся проблемы в нативном/интерпретируемом коде (для большинства прикладных задач).


                                                                                                Тут не говорится, что Java быстрее C++.
                                                                                                • 0
                                                                                                  Понимаете, всё это не объясняет, почему вместо хорошего фреймворка С++, потребовалось городить отдельный язык с фреймворком.
                                                                                                  Маркетинговые заголовки типа «решает проблемы с динамической памятью» — потускнели и покрылись трещинами. Из самописных андроидовских программ на яве, дай бог если половина не падает.
                                                                                                  • +3
                                                                                                    Потому же, почему подавляющее большинство энтерпрайз систем не на С++, а на managed-языках типа явы и дотнета.
                                                                                                    Выше скорость разработки, проще поддерживать код, больше ошибок ловится на стадии компилляции.
                                                                                                    • 0
                                                                                                      Если сравнивать Яву с С++ и фремворками образца начала 2000-х, то скорость разработки безусловно выше. С тех пор многое поменялось. Вот не самый свежий пример:
                                                                                                      www.ultimatepp.org/www$uppweb$vsswing$en-us.html
                                                                                                    • +1
                                                                                                      > почему вместо хорошего фреймворка С++, потребовалось городить отдельный язык с фреймворком.

                                                                                                      Вы вообще сейчас про что? Про Яву вообще или только про Андроид.

                                                                                                      Если про Яву вообще, то причины, по которой она создавалась, можно почитать в той же Википедии. Если в общем говорить, не только про Яву, то С++ не позволяет огромное количество вещей. Например, ФП в него надо заколачивать гвоздями, и результат выглядит не просто убого, а сверхубого. И это только вершина айсберга.

                                                                                                      Для большинста прикладных задач хватает любых языков, и С++ там не поможет.
                                                                                                      • 0
                                                                                                        Отлично! Забыли про динамическую память, теперь говорим про ФП.
                                                                                                        Скажите пожалуйста, чем отсутствие ФП в С++ мешает, как вы там выразились, для большинства прикладных задач?
                                                                                                        • 0
                                                                                                          Гы, так linq + ef и спроектирован для enterprise, чтобы писать так:

                                                                                                          var BestCustomer = OrdersDatabase.Orders
                                                                                                            .Where(order => order.IsBonus == false && order.Sum > 10000)
                                                                                                            .GroupBy(order => order.Customer)
                                                                                                            .OrderBy(group => group.Count)
                                                                                                            .Select(group => group.Key)
                                                                                                            .Last();


                                                                                                          Транслируется в 1 sql-запрос, который выберет лучшего клиента (по кол-ву дорогих заказов). Границы между данные в базе и загруженными в память стёрты (хотя можно гибко управлять политиками загрузки, если требуется оптимизация).
                                                                                                          • 0
                                                                                                            Как я говорил выше, подобный уровень удобства давно уже дают фреймворки в С++. И давно уже есть компиляция (compile-time!) на необходимый диалект SQL. Например, вот так.
                                                                                                            • +3
                                                                                                              Это всё дикие костыли. Без поддержки Expression Trees в языке невозможно добавлять свои SQL-функции, специфичные для СУБД, без влезания во фреймворк.
                                                                                                              • 0
                                                                                                                Что значит костыли? Кусок, отодранный из Cω, и добавленный спустя пять лет после разработки основного языка, это не костыли?
                                                                                                                Мы ведь говорим об эффективности, о памяти, об удобстве. Тот пример запроса, что вы привели выше, давно уже компилируется и в С++, я вам привёл пруфлинк. Всё работает стабильно, быстро. И пользоваться удобно.

                                                                                                                Что касается SQL-функций, то имеется в виду PL/pgSQL и что-то подобное? Если да, то это довольно большая специфическая тема, далёкая от обсуждаемого «большинства прикладных задач».
                                                                                                                • 0
                                                                                                                  Нет, пример не работает ))))
                                                                                                                  Это голый SQL. Я хочу полноценную объектную модель, чтобы положить клиенту в список заказов новый заказ, сказать Save и заказ сохранился и привязался к клиенту.

                                                                                                                  Я хочу не писать Join-ы руками, как в ваших примерах,
                                                                                                                  .From(Order)
                                                                                                                  .FullJoin(Customer)
                                                                                                                  .On(COLUMN.Of(Order) == COLUMN1.Of(Customer))
                                                                                                                  .FullJoin(City)
                                                                                                                  .On(COLUMN.Of(City) == COLUMN1.Of(Customer))

                                                                                                                  а тупо сделать .Where(order => order.Customer.City.Name='Москва')
                                                                                                                  А два join-а фреймворк сделал сам. Разница, как между Фортраном и Паскалем.

                                                                                                                  А функции… Например, bin_and(x,y) или «Customer.Name starting with 'Пет' » в Firebird. Имелось ввиду, каких это затащить в синтаксис Where, чтобы пользоваться плюшками СУБД и генератора SQL одновременно
                                                                                                              • +1
                                                                                                                И эти фреймворки будут работать с такой же скоростью, как и аналогичные на не-С++. Чудес не бывает.
                                                                                                                • 0
                                                                                                                  Простите, а вы сколько программ на этих фреймворках написали, чтобы это говорить? )

                                                                                                                  «Эти фреймворки», как вы выразились, работают в 2-3 раза быстрее STL даже на базовых операциях типа работы с динамическими массивами или строками.
                                                                                                                  Компиляция SQL идёт на стадии компиляции программы. То есть, с точки зрения динамических языков, во время выполнения происходят мгновенно.
                                                                                                                  • 0
                                                                                                                    На многих и разных. Конкретно на этом не работал
                                                                                                                    • –1
                                                                                                                      Какая разница, если ещё как минимум две прослойки до СУБД (ODBC-драйвер и TCP/IP, например)
                                                                                                                  • 0
                                                                                                                    Главный недостаток предложенного фреймфорка — это трансляция в голый SQL, когда нормальные ORM умеют мапить объект по нескольким таблицам, поддерживают наследование, lazy-загрузку по ссылкам, поддержку отношений 1-ко-многим и их lazy-загрузку либо генерацию sql по аггрегированным запросам к ним т.п.
                                                                                                                    • 0
                                                                                                                      Да, этого нет. И здесь я бы воспользовался возможностью динамической генерации кода — но без ненужных свистелок вроде мусоросборщика и лишних проверок. Что касается отложенного исполнения — это очень серьёзный вопрос, я бы не стал однозначно высказываться за его наличие в том виде, как оно подаётся сейчас. Мне сейчас недостаёт контроля над отложенными операциями, что критично при закрытии программы или окна, например.

                                                                                                                      Если бы было что-то подобное, локально-динамическое и гибкое для С++ — я бы задумался о переходе. Без огромных виртуальных машин (они могут быть локальные и очень маленькие), без оверхеда по памяти и мусоросбощика и прочего.
                                                                                                                • 0
                                                                                                                  Никто ничего не забыл. Был один из возможных ответов, почему некоторые задачи не решаются фреймворками на C++.

                                                                                                                  C++ — не панацея. Это достаточно неудобный и достаточно низкоуровненвый язык. Он банально не подходит для решения большинства задач.

                                                                                                                  Ява появилась, потому что нужен был язык с гарантией типизации и защитой памяти, которую С++ (особенно на начало 90-х) представить не мог (а благодаря наличию C-style cast не может гарантировать типизацию и сейчас).

                                                                                                                  Другие языки появлялись и будут появляться, потому что С++/Java/C#/вписать_свое не дают решения каких-либо других задач.

                                                                                                                  При этом вздохи «ах, эти все языки медленнее, чем C++» можно смело отправлять в /dev/null, потому что

                                                                                                                  профайлер потом покажет, что проблема в БД, сети, доступе к диску — и это задолго до того, как начнутся проблемы в нативном/интерпретируемом коде (для большинства прикладных задач).
                                                                                                                  • –1
                                                                                                                    1. Защита памяти.
                                                                                                                    И как защита памяти от Явы, спасла? Приложения на Яве — стабильнее нормально написанных на С++? А плохо написанные приложения на Яве — не падают?
                                                                                                                    Я пробовал разные приложения что на чистой Яве, что на Андроиде — и знаете что — они падают. И падают довольно часто. Может, конечно, у меня с Явой что-то не то, не знаю.

                                                                                                                    2. По поводу плюсов и минусов Явы перед С++, в той самой Википедии, на которую вы ссылаетесь, написано следующее.
                                                                                                                    а) Независимость байт-кода от операционки (мы все знаем, что на деле распространяется несколько бинарников для нескольких процессоров, что покрывает 99% пользователей).
                                                                                                                    б) Система безопасности. О ней я писал выше — там всё очень и очень спорно, как минимум.

                                                                                                                    И что же мы получаем за эти неочевидные преимущества:
                                                                                                                    — замедление работы кода в несколько раз
                                                                                                                    — потребление памяти в 10-30 раз больше

                                                                                                                    Заметьте, это не я придумал, это написано в Википедии, на которую вы сами же и ссылаетесь.
                                                                                                                    • +3
                                                                                                                      > И как защита памяти от Явы, спасла? Приложения на Яве — стабильнее нормально написанных на С++?

                                                                                                                      У разработчика средней руки — да.

                                                                                                                      > И что же мы получаем за эти неочевидные преимущества:
                                                                                                                      > — замедление работы кода в несколько раз
                                                                                                                      > — потребление памяти в 10-30 раз больше

                                                                                                                      Боже. Вы научитесь хоть когда-нибудь читать?

                                                                                                                      Для подавляющего большинства прикладного кода это некритично.

                                                                                                                      • +1
                                                                                                                        > Для подавляющего большинства прикладного кода это некритично.

                                                                                                                        Как я говорил выше, против религии аргументы бессильны. Если для вас всё о чём говорилось — некритично, то обсуждать просто нечего.
                                                                                                                        • 0
                                                                                                                          Ну, религия только у вас. Это вы тут считаете С++ и фреймворки на нем панацеей от всего.

                                                                                                                          Например, в GUI C++ не нужен даже даром. Там важно не мифическое «в два-три раза быстрее», а отзывчивость интерфейса. Которое, очень грубо говоря, ограниченно порогом моргания человека (~50ms, емнип), и это обеспечивает любой язык программирования влегкую.

                                                                                                                          В вебе С++ не нужен даже даром, потому что приложение сначала упрется в ограничения (нативной!) базы данных и/или (нативной!) сетке прежде, чем начнутся проблемы собственно с приложением.

                                                                                                                          GUI + Веб сейчас покрывают ~70-90% прикладных направлений.

                                                                                                                          И только для оставшихся, где нужна высокая производительность (низкоуровневое, системное, графика, видео) С++ вполне подойдет.

                                                                                                                          Я же говорю: вы неспособны читать, что вам пишут, ибо С++ застил вам глаза
                                                                                                                          • 0
                                                                                                                            > Это вы тут считаете С++ и фреймворки на нем панацеей от всего.

                                                                                                                            Это вы так читаете, попутно скатываясь к переходам на личности. Что вас не красит.
                                                                                                                            Что касается остального потока сознания в вашем комментарии, я не буду ничего писать по причине, изложенной выше. Предлагаю вам прекратить этот бессмысленный диалог.
                                                                                                                            • 0
                                                                                                                              > Это вы так читаете, попутно скатываясь к переходам на личности. Что вас не красит.

                                                                                                                              Да ну? Кто тут рассказывает сказки про то, что все можно и нужно решать фреймворками на С++? Не я же

                                                                                                                              > Что касается остального потока сознания в вашем комментарии

                                                                                                                              И это человек мне еще говорит о религии :)))
                                                                                                                    • 0
                                                                                                                      А еще потому, что для большинства приложений и профайлер не потребуется запускать — приложение будет работать «достаточно быстро». Ну а там, где будет работать недостаточно быстро, зачастую можно будет докупить/заменить железо, что в итоге выйдет дешевле оптимизации кода.
                                                                                                                      • –1
                                                                                                                        А еще чаще (по вебу знаю) сначала достаточно подтюнить базу данных и дисковую систему, чтобы скорость приложения выросла в разы.

                                                                                                                        Пользуясь случаем: MySQL (натвный, на С!!) — говно :)
                                                                                                                        • +1
                                                                                                                          Или базу, или запросы, да. Что и неудивительно, поскольку огромное число веб-приложений — суть прослойка между гуем и базой.
                                                                                                                • +1
                                                                                                                  Если отвлечься от практики и потеоретизировать, направление на managed-среды в ОСестроительстве давно просматривается (Microsoft чтобы внезапно не оказаться отставшей понемногу тоже пилит).

                                                                                                                  Плюсы понятны: убрать границы между процессами. Убрать оверхед на IPC и переключение адресных пространств. С другой стороны, будут подтягиваться компиляторы и верификаторы программ. В циклах проверка границ будет только для начального и конечного индекса, а не при каждом обращении к массиву и т.п. Это уменьшит тормоза managed-кода. В идеале компилятор научится полностью доказывать корректность алгоритма (сейчас это возможно, но очень затратно вычислительно) и ставить проверки только на входные параметры функции, а программисту давать warnings — «не могу оптимизировать, выкинув проверки, потому что в таких-то входах программа свалится».

                                                                                                                  Но пока в юзер-программах есть хоть строчка native-кода, это остаётся небезопасным.
                                                                                                                  • 0
                                                                                                                    Очень интересно будет посмотреть на производительность этой системы. )
                                                                                                                    А особенно интересно будет, если, как вы предлагаете, всё делать в одной задаче: если вдруг что с виртуальной машиной, то падает вообще весь user space. Напоминает старые времена DOS.
                                                                                                                    Этакий anti-unix way.
                                                                                                                    • 0
                                                                                                                      На всякий случай — это такое заглядывание в далёкое и неизбежное будущее, я не говорю, что сейчас так надо делать.

                                                                                                                      Производительность будет выше, т.к. нет процессов, нет kernel и user, нет IPC, нет классического клипбоарда (любая передача данных — просто ссылка на managed-объект, а все объекты пусть будут read/only, как в чистом лиспе).

                                                                                                                      Падений не будет, т.к. ВЕСЬ код формально верифицирован и доказана правильность выполнения при корректных входных данных. А проверка корректности входа будет выполнятся единожды при передаче на вход алгоритма. Там, где доказательство провалилось, проверки будут как обычно (к слову, постоянный challenge для математиков: если какая-то сортировка не доказывается формально, а интуитивно правильная, это надо исправлять и фиксить «компилятор»)
                                                                                                                      • +1
                                                                                                                        Это вообще несерьезно. С тем же успехом можно сказать «если вдруг что с ядром то падает вообще весь юзерспейс» — что, кстати, весьма частое явление при падении дров. Разумеется, если падает низкий уровень, то отвалится и все остальное, или если у вас ядро выпадет с бсодом или паником, юзерспейс останется живым?)

                                                                                                                        А подобные системы есть, дотнет микрофреймворк допустим.
                                                                                                            • +1
                                                                                                              >Тогда спрашивается — НАФИГА было затеваться с Явой?
                                                                                                              Это вы сейчас про Android? А как быть с зоопарком процессоров? На телефоны ставить gcc, из маркета скачивать исходники и компилировать на месте?
                                                                                                          • 0
                                                                                                            Скажите, а вы точно знаете что происходит в двигателе вашей машины, когда вы включаете зажигание? В каком порядке следуют циклы, без подсматривания в википедию, знаете? Какие сигналы посылает контроллер форсункам? Вам надо это знать чтобы доехать из точки А в точку Б?
                                                                                                            • +4
                                                                                                              Да, я точно знаю что происходит в двигателе моего автомобиля. Начинал с обычного карбюраторного, а сейчас инжектор.Без подсматривания в википедию.
                                                                                                              • 0
                                                                                                                Я поздравляю вас, что вы всё точно знаете )
                                                                                                                Я занимался электротехникой и эектроникой, знаю как работает компьютер на физическом уровне. Я не про команды на ассемблере, а про физическую реализацию логических элементов на основе транзисторов и т.д., конечно. Вы, надеюсь, тоже знаете? Ведь невозможно без этого точно понимать что скрывается за каждой ассемблерной командой. Да что там ассемблерной, мне посчастливилось увлечься машинным кодом, правда недолго. Интерес интересом, но в работе это не нужно.
                                                                                                                Сейчас пишу на языках высокого уровня, а это осталось как хобби. И скажу вам честно, эти знания абсолютно необязательны для программиста на языке высокого уровня.
                                                                                                                Если вы представляете как всё реализованно на несокольких уровнях абстракций, то это даёт вам, разумеется, эстетический самолюбовательный бонус, но не более того. Для практики достаточно знать свой уровень и работать с конкретной предоженной моделью без знания внутренних деталей.
                                                                                                                А ниже электротехники есть ещё физика.
                                                                                                                Вы же не знаете, как взаимодействует материя на уровне квантовой физики? Я вот не знаю, но живу )
                                                                                                                • 0
                                                                                                                  Если этого не требуют Ваши задачи, это не означает что у других все так же.
                                                                                                              • +2
                                                                                                                Всё зависит от задачи.
                                                                                                                Пользователю (а автолюбитель — это максимум уровень продвинутого пользователя) действительно не так важно знать, как оно работает. Уметь хотя бы минимально настраивать — уже хорошо (ну там фильтр воздушный зима-лето, жидкостей подливать когда надо, проверять стёртость колодок и т.п.).

                                                                                                                Программисту (то есть автоконструктору) знать эти вещи обязательно. И, уверяю вас, он их знает без всяких Википедий.
                                                                                                                • +1
                                                                                                                  Знаете, я в корне не согласен, что это нужно знать. Я вот например проектирую средние и большие корпоративные приложения. Несколько БД, сети, GUI на разных языках и платформах. Если бы я вдавался в детали реализации той или иной операции на уровне ассемблера я