Если бы их было бы просто реализовать, то давно бы уже сделали, идея то старая. Но пока все виртуальные очки по качеству очень плохи и на глаза нагрузку дают сильную.
Дело не в их виде, а в голосовом управлении, то же Siri при всей привлекательности не особо используется, потому что болтать с телефоном в общественном месте как то неочень.
Где как, у нас в глубинке я никого с bluetooth гарнитурой давно не видел, разве что в машине :) У меня самого есть например стереогарнитура аж с Bluetooth 4.0, но я ее использую исключительно дома с ноутом.
Имхо его купят разве что редкие гики, ибо девайс сомнительной полезности, а человек с ним выглядит еще глупее, чем постоянно болтающий по bluetooth гарнитуре.
Так и сейчас PS3 вполне мышку и клавиатуру через USB или Bluetooth поддерживает. Но вроде в играх ими управлять нельзя, во всяком случае не во всех. Но например в IL-2 Birds of Prey для PS3 можно подключить PC джойстик через USB и им управлять. Ну и управление с контроллера все равно должно быть хотя бы как опция.
1. Нет он совсем не in-place по определению, существуют простая и in-place версии (посмотрите хотя бы в английской википедии). И сравнивать одно с другим некорректно. То что в хаскелле выдают за quicksort, скорее надо было назвать merge sort. Вообщем этот пример не показательный и это совсем не тот случай, который я имел ввиду, поэтому и пруфы тут какие то приводить и делать из них выводы смысла не имеет. Я с самого начала сказал, что сравнения оптимизированного кода меня не интересуют, а сортировка это уже оптимизированный код. Если вас так уж интересует эта тема вот вам ссылочка на хаскеллевские реализации inplace quicksort'а: www.haskell.org/haskellwiki/Introduction/Direct_Translation
2. Ну хорошо, что вы это выяснили, значит это был некорректный пример, моя ошибка признаю.
C quicksort'ом и статья не нужна и так все понятно. Если вы напишете на С буквально тот же наивный quicksort, что и в Хаскелле, то есть рекурсивный, недеструктивный и с аллокацией объектов в куче и работающий над бесконечными односвязными списками, то он скорее всего сольет хаскелевскому однострочнику. Quicksort на С почему быстрый, потому что он делает сортировку in place, и при этом при операциях с массивами не делаются проверки на выходы за границы (в отличии от большинства высокоуровневых языков) ну и память не выделяется. Все это прекрасно реализуется и на Хаскелле через MArray и при этом имеет близкую скорость, но строго говоря это уже не quicksort и вряд ли вы его сходу напишете не глядя никуда :) То есть тут сравнение тоже некорректно, и программисты на Хаскелле неправы, что постоянно приводят этот пример с quicksort'ом.
Для начала конечно достаточно интуитивного понимания. Можно вообще все писать в монаде IO в императивном стиле. Но идея контроля side effect'ов (и не только) и автоматическое поднятие в монаду в других языках не используется явно. Например в программе на С вы решили, что какая то внутренняя функция может возвращать null и вам надо его вручную проверить на всех уровнях и пробросить дальше, а в haskell'е вы просто делаете liftM и все готово :) То есть поначалу кажется, что монады это костыль, а потом оказывается, что это очень мощный и гибкий инструмент. И контроль side effect'ов это только вершина айсберга. А стрелки еще приятнее :) Конечно можно написать монады и на других языках, только они не дают гарантий чистоты как в хаскелле.
Ну потому хотя бы, что для вывода в хаскеле нужны монады, а в С++ нет :) Можно конечно монады и на пальцах объяснить, но обычно все таки изучающие хаскель изучают хотя бы основы теории категорий. А в С++ как раз ограничиваются интуитивным пониманием «на пальцах». То же и с теорией типов, можно систему типов игнорировать до поры до времени, но для полного погружения в хаскель приходится изучать и ее :)
Ну мне смысла меряться нет, прога то не моя :) Можете померяться с автором, я думаю у него есть аккаунт на хабре. Но тест ваш не показателен, только один алгоритм, только разархивация, только один набор данных и только один прогон. Вот например в этих тестах www.maximumcompression.com/data/summary_mf2.php он занимает первые 3 места.
2. Ну хорошо, что вы это выяснили, значит это был некорректный пример, моя ошибка признаю.