Сравнивать абстрактные «аппаратные / сенсорные кнопки(жесты)» безсмысленно. Да, плюсы минусы обоих решений перечислены верно, но существующие минусы сенсорного подхода не означают что нельзя сделать сенсорный интерфейс более удобным чем «кнопочный».
Например, на iPad'e одна аппаратная кнопка «домой», она нужна чтобы выйти из приложения. Понятно что заменять её сенсорной(нарисованной) кнопкой было бы глупо, и поэтому она есть. Но в последней версии iOS добавили жест «щепотка пятью пальцами», и пользоваться им намного удобнее чем кнопкой. Кнопка по сравнению с ним, прямо скажем, сосёт.
Так что сенсорное управление может быть очень удобным, если только не пытаться заставлять пользователя оперировать им так-же как кнопочным.
Утиная и статическая типизации это не антонимы. Язык может поддерживать и статическую и утиную типизации (например go). Я говорил о статической типизации в противовес динамической. Безусловно в языке для веба должен быть тип 'variant' который может хранить что угодно, но в большинстве случаев удобнее понимать с каким типом мы оперируем, чтобы фрукты на слово 'х@у' не умножать.
По поводу скорости я писал выше. Помниться здесь прискакивала статья про порфирование эмулятора x86 на js, там как раз использовалось расширение js — typed array, без которого не то чтобы невозможно было такое написать, но это просто не работало бы с приемлемой скоростью.
Слишком много далеко идущих обобщений, все равно что утверждать: 'затея Ferrari выпустить машину красного цвета кажется безумной — АвтоВАЗ тоже выпускал машины красного цвета и мы все знаем что из этого получилось.'.
Во-первых, странным выглядит сравнение нового языка и старого фреймворка, только на том основании что этот фреймворк тоже использовал один (но, sic! Промежуточный) язык.
Цель дарта, в первую очередь, создать быстрый и удобный в коллективной разработке язык для браузера. Задача оправдана, потому что js a) медленный (и не может быть не медленным) б) не удобен в коллективной разработке (потому что нет никакой возможности указать другим программистам как использовать твой код).Поддерживка северной версии это бонус который удешевляет разработку (с меньшей вероятностью придется искать программиста знающего язык X). Обращаю внимание — это бонус, а не стремление пересадить всех на один язык — если вы понимаете что для вашей задачи на сервере лучше использовать ruby никто не запретит его использовать.
Еще одно замечание насчет скорости: выше более или менее справедливо замечали что самое тормозное это все равно работа с Dom-деревом. Это так потому что никто не осмеливается писать вещи которые будут тормозить и без дом'а. Например модный сейчас canvas ограничен только своим API, т.е. Вы можете менять его содержимое попиксельно, но никто в зравом уме делать этого не будет — медленно.
Сомневаюсь что размер экрана изменится в любой другой версии.
Они очень трепетно относятся к платформе в том числе с точки зрения «книгопечатания». Т.е. для них iPhone это стандарт дисплея в том числе. Так что любой разработчик может быть уверен что его иконка будет размером 1x1 см. Это очень здорово на самом деле. Позволяет легко проектировать очень отточенные с графической точки зрения приложения.
Да, придётся. Но иногда это не критично, а ингда и вовсе не важно.
Не важно, когда исходный массив требуется ровно один раз, например нам нужен массив содержащий квадраты всех чисел от 1 до 5, мы можем записать:
var arr1 = new Array();
for( var i = 1; i <= 5; ++i )
{
arr[i-1] = i*i;
}
// или
var arr2 = Stream.range( 1, 5 ).map( function ( x ) { return x * x } );
// выше, правда, создаётся объект типа range (если я правильно понял)
// но наверное есть способ просто сконвертировать его в массив.
Плюсы такого подхода, как правильно написал smashercosmo: синтаксический сахар и возможность подсунуть свою последовательность алгоритмам, которые принимают на вход массивы.
Такой логический Range можно пихать в алгоритмы, заточенные на приём обычного Range (например массива). В случае с логическим Range нам не нужна память для хранения исходного массива, плюс он может быть бесконечным.
Бесконечность: например бесконечный range задаёт карту высот для некоторой двумерной поверхности в игре, мы можем промотать карту на сколько угодно вправо и влево и отрисовать поверхность, с минимальным расходом памяти.
Да ладно. Концепции, модули, более вменяемая стандартная библиотека очень к месту.
Концепции: // много проще, понятнее и надёжнее написать
class Matrix(T) if( isNumeric!(T) )
{
....
}
чем
class Matrix<>
{
static_assert();
}
class Matrix { ... }
class Matrix { ... }
class Matrix { ... }
... и так далее
Модули:
Pimpl'ы в топку
Объявления friend классов не нужны (внутри модуля все поля доступны)
Просто меньше мороки с парами h/cpp.
Библиотека
кросплатформенно даже создать каталог нельзя. Любой более менее серьёзный проект начинается с создания обёрток над виндовыми и линуксовыми функциями.
На сколько я понимаю это сейчас упомянутые игры стоят 1$ — это чтобы их купили те, кто о них слышал, но не решался покупать.
Но, даже если не так, то всё равно, спрос на такую игру нишевый (и врят ли элластичный). Сомневаюсь что игру купят в два раза больше покупателей, если она будет стоить в два раза дешевле.
Это очень спорно. Пользователи виндоус очень привыкли к возможности свернуть/развернуть экран двойным кликом. Лично меня подбешивает в хроме то, что нужно тянутся к кнопке чтобы свернуть окно.
Хотя по логике, «беззазорный» подход правильнее, но он конфликтует с сформировавшимися привычками. В Опере не спроста добавили пару пикселей сверху, когда стянули «вкладки в заголовке» с хрома.
Например, на iPad'e одна аппаратная кнопка «домой», она нужна чтобы выйти из приложения. Понятно что заменять её сенсорной(нарисованной) кнопкой было бы глупо, и поэтому она есть. Но в последней версии iOS добавили жест «щепотка пятью пальцами», и пользоваться им намного удобнее чем кнопкой. Кнопка по сравнению с ним, прямо скажем, сосёт.
Так что сенсорное управление может быть очень удобным, если только не пытаться заставлять пользователя оперировать им так-же как кнопочным.
И, соответсвенно, фаерволл: чтобы не икать когда о тебе другие думают.
По поводу скорости я писал выше. Помниться здесь прискакивала статья про порфирование эмулятора x86 на js, там как раз использовалось расширение js — typed array, без которого не то чтобы невозможно было такое написать, но это просто не работало бы с приемлемой скоростью.
Во-первых, странным выглядит сравнение нового языка и старого фреймворка, только на том основании что этот фреймворк тоже использовал один (но, sic! Промежуточный) язык.
Цель дарта, в первую очередь, создать быстрый и удобный в коллективной разработке язык для браузера. Задача оправдана, потому что js a) медленный (и не может быть не медленным) б) не удобен в коллективной разработке (потому что нет никакой возможности указать другим программистам как использовать твой код).Поддерживка северной версии это бонус который удешевляет разработку (с меньшей вероятностью придется искать программиста знающего язык X). Обращаю внимание — это бонус, а не стремление пересадить всех на один язык — если вы понимаете что для вашей задачи на сервере лучше использовать ruby никто не запретит его использовать.
Еще одно замечание насчет скорости: выше более или менее справедливо замечали что самое тормозное это все равно работа с Dom-деревом. Это так потому что никто не осмеливается писать вещи которые будут тормозить и без дом'а. Например модный сейчас canvas ограничен только своим API, т.е. Вы можете менять его содержимое попиксельно, но никто в зравом уме делать этого не будет — медленно.
Они очень трепетно относятся к платформе в том числе с точки зрения «книгопечатания». Т.е. для них iPhone это стандарт дисплея в том числе. Так что любой разработчик может быть уверен что его иконка будет размером 1x1 см. Это очень здорово на самом деле. Позволяет легко проектировать очень отточенные с графической точки зрения приложения.
Не важно, когда исходный массив требуется ровно один раз, например нам нужен массив содержащий квадраты всех чисел от 1 до 5, мы можем записать:
var arr1 = new Array();
for( var i = 1; i <= 5; ++i )
{
arr[i-1] = i*i;
}
// или
var arr2 = Stream.range( 1, 5 ).map( function ( x ) { return x * x } );
// выше, правда, создаётся объект типа range (если я правильно понял)
// но наверное есть способ просто сконвертировать его в массив.
Плюсы такого подхода, как правильно написал smashercosmo: синтаксический сахар и возможность подсунуть свою последовательность алгоритмам, которые принимают на вход массивы.
Бесконечность: например бесконечный range задаёт карту высот для некоторой двумерной поверхности в игре, мы можем промотать карту на сколько угодно вправо и влево и отрисовать поверхность, с минимальным расходом памяти.
У меня звука на работе нет, без звука не люблю смотреть.
Ещё остаётся открытым вопрос: можно ли дорисовывать усы на портретах?
Это единственная функцональность, которую я не знаю как можно «толково» перевести на русский язык...
Может «окантовка»?
class Matrix(T) if( isIntegral!(T) ) {}
class Matrix(T) if( isFloating!(T) ) {}
— Понятно что можно сделать тоже через прокси объекты, но мороки сколько, уж не говоря об «удовольствии» чтения такого кода.
Ну и более наглядно чем static_assert внутри класса.
class Matrix<>
{
static_assert();
}
class Matrix<int> { ... }
class Matrix<short> { ... }
class Matrix<unsigned int> { ... }
...
Концепции:
// много проще, понятнее и надёжнее написать
class Matrix(T) if( isNumeric!(T) )
{
....
}
чем
class Matrix<>
{
static_assert();
}
class Matrix { ... }
class Matrix { ... }
class Matrix { ... }
... и так далее
Модули:
Pimpl'ы в топку
Объявления friend классов не нужны (внутри модуля все поля доступны)
Просто меньше мороки с парами h/cpp.
Библиотека
кросплатформенно даже создать каталог нельзя. Любой более менее серьёзный проект начинается с создания обёрток над виндовыми и линуксовыми функциями.
Но, даже если не так, то всё равно, спрос на такую игру нишевый (и врят ли элластичный). Сомневаюсь что игру купят в два раза больше покупателей, если она будет стоить в два раза дешевле.
Хотя по логике поведение Хрома правильнее.
Подозреваю что дело тут в «обманутых ожиданиях» Хром, хоть и сделал, по идее, лучше, поломал привычное поведение.
Хотя по логике, «беззазорный» подход правильнее, но он конфликтует с сформировавшимися привычками. В Опере не спроста добавили пару пикселей сверху, когда стянули «вкладки в заголовке» с хрома.