Я пользуюсь MS Natural 4000. И у неё есть два недостатка.
1. Она большая. Когда хочешь нажать [ или ] приходится вытягивать мизинец. То же самое с цифрами.
2. Клавиши надо вдавливать глубоко, пальцы устают.
Есть пара недостатков, свойственных всем стандартным клавиатурам без исключения.
1. Клавиши Control находятся очень далеко. Мизинцами их нажимать невозможно. У меня из-за этого CapsLock замаплен как левый Control, а Enter как правый Control. Помогает.
2. То же самое с Альтами. Большой палец очень сильно надо подгибать.
Не чистые хэши, но одного непрерывного куска памяти за массивом в php нет. В документации так и написано — ordered map. Это даёт возможность бысть перебирать элементы по порядку, но не даёт быстрого доступа по индексу.
Насчёт презентации — не подскажете ссылку на видео?
По измерениям в немного устаревшей версии node и в текущей версии Chrome map быстрее. Ну и я верю, что в джаваскрипте рано или поздно начнут инлайнить функции.
Если бы CoffeeScript выполнялся браузером, а не транслировался в javascript, то смысл делать сравнения, о которых вы говорите, был бы.
А тут такое дело. Мы точно знаем во что компилятор транлирует cubes = (math.cube num for num in list). И знаем во что он мог бы его транслировать для улучшения производительности. И знаем, что причин не делать этой оптимизации нет. Если мне приведут причины не делать этой оптимизации, до меня дойдёт, что я сравнивал совершенно разные вещи.
Причина, которую приводите вы — нужно транслировать for в синтаксически сходную конструкцию. Я считаю, что сохранить синтаксис не важно, так как это не даст ничего — важно сохранить семантику. Она при такой оптимизации сохранится.
Чтобы реализовать всё, что есть в C# на паскале — придётся написать на нём vm и компилятор. И код в основном будет работать с той же скоростью, что С#. Игра не стоит свеч.
Гораздо лучше пример с С и С++. 2 разных языка, один является подмножетсвом другого, но все оптимизации, которые можно сделать для того, чтобы производительность С++ была такой же, как С — обязательно делаются.
Современные языки сложнее старых в том смысле, что в старых многие фичи реализованы только в библиотеках и потому меньше ключевых слов. Но думать там зачастую можно меньше, потому что есть больше гарантий по поводу того, как будет вести себя код.
Сравнение double c float тут некорректно, потому что такую ситуацию нельзя выловить компилятором. А ситуацию из статьи — можно. И приходится помнить, что конструкцию не надо применять, если шаг равен еденице. Это очень неприятно.
То, что вы классифицируете как незнание языка — на самом деле претензия к компилятору, который не оптимизирует ситуацию, которую оптимизировать можно.
Потому, что код, сгенерированный CoffeeScript внутри устроен как reduce. Там есть накопитель, и цикл с его наполнением. map делает массив по размеру равный исходному и потом просто присваивает элементам массива нужные значения. Поэтому логично сравнивать код, сгенерированный CoffeeScript с reduce, а не с map.
Знаете, а я предпочитаю больше думать и меньше писать
История развития языков программирования это история того, как сделать так, чтобы при написании кода можно было меньше думать. Если думать надо больше, то и неверных решений будет принято больше и ошибок значит будет больше.
Если бы у вас был шаг не 1, а 2 (как в моем примере выше) — у вас бы код был аналогичной конструкции.
Если есть способ оптимизировать случай с шагом в 1 — надо это сделать.
Причина не предпочитать паскаль шарпу — поддержка современных платформ, сборщик мусора, concurrency, виртуальная машина со стектрейсами, богатая стандартная библиотека и коммьюнити.
CoffeScript не может сделать ничего, что не может джаваскрипт, соответственно причина выбирать его — простота написания кода и ошибкобезопасность. Я уверен, если сообщить создателям CoffeeScript, что на их языке писать сложнее, чем на джаваскрипте, они ответят, что стремились создать язык, на котором писать проще.
Если при написании кода на CoffeeScript действительно надо думать на порядок больше, то на нём лучше не писать. Весь смысл использования языка, отличного от джаваскрипта в том, чтобы облегчить написание кода, а не усложнить его.
Ну и если есть 2 совершенно разных куска кода, которые используются для достижения одной и той же цели и один кусок быстрее другого, то лучше использовать инструмент, который генерит быстрый код.
Так. Вот тесты для суммирования массивов. У меня в файрфоксе и хроме зеркальная картина. Хром 45-ой версии.
Далее. Нод, на котором я гонял тесты как выяснилось старый. Версии v0.10.40. В новом ноде пока не проверял сам, но друзья кофеманы говорят, что лямбды не рулят. Сейчас немного подумаю и добавлю апдейт с опровержением, или нову статью сделаю с разбором.
При том, что доступ к элементам массива, находящегося в непрерывном куске памяти происходит практически мгновенно. В отличие от хэша.
И да, в джаваскрипте действительно не оговорено как располагать в памяти массив. Но оговорено, то индексы массивов могут быть строками и могут содержать дырки. Что естественным образом приводит к необходимости держать его в хэше. Вследствии чего доступ по индексу мендленный.
В php есть встроенные в язык массивы. Они — хэши. Ещё есть способ разрешить любому объекту весте себя как массив — ArrayAccess. Это как перегрузка оператора []. И есть настоящие массивы фиксированной длины с однотипными элементами.
1. Она большая. Когда хочешь нажать [ или ] приходится вытягивать мизинец. То же самое с цифрами.
2. Клавиши надо вдавливать глубоко, пальцы устают.
Есть пара недостатков, свойственных всем стандартным клавиатурам без исключения.
1. Клавиши Control находятся очень далеко. Мизинцами их нажимать невозможно. У меня из-за этого CapsLock замаплен как левый Control, а Enter как правый Control. Помогает.
2. То же самое с Альтами. Большой палец очень сильно надо подгибать.
И в последних версиях нода и в файрфоксе for быстрее, чем map.
Вся ценность статьи в коментаторах, которые объясняют, что в ней не так.
Насчёт презентации — не подскажете ссылку на видео?
А тут такое дело. Мы точно знаем во что компилятор транлирует cubes = (math.cube num for num in list). И знаем во что он мог бы его транслировать для улучшения производительности. И знаем, что причин не делать этой оптимизации нет. Если мне приведут причины не делать этой оптимизации, до меня дойдёт, что я сравнивал совершенно разные вещи.
Причина, которую приводите вы — нужно транслировать for в синтаксически сходную конструкцию. Я считаю, что сохранить синтаксис не важно, так как это не даст ничего — важно сохранить семантику. Она при такой оптимизации сохранится.
Гораздо лучше пример с С и С++. 2 разных языка, один является подмножетсвом другого, но все оптимизации, которые можно сделать для того, чтобы производительность С++ была такой же, как С — обязательно делаются.
Современные языки сложнее старых в том смысле, что в старых многие фичи реализованы только в библиотеках и потому меньше ключевых слов. Но думать там зачастую можно меньше, потому что есть больше гарантий по поводу того, как будет вести себя код.
Сравнение double c float тут некорректно, потому что такую ситуацию нельзя выловить компилятором. А ситуацию из статьи — можно. И приходится помнить, что конструкцию не надо применять, если шаг равен еденице. Это очень неприятно.
То, что вы классифицируете как незнание языка — на самом деле претензия к компилятору, который не оптимизирует ситуацию, которую оптимизировать можно.
История развития языков программирования это история того, как сделать так, чтобы при написании кода можно было меньше думать. Если думать надо больше, то и неверных решений будет принято больше и ошибок значит будет больше.
Если есть способ оптимизировать случай с шагом в 1 — надо это сделать.
CoffeScript не может сделать ничего, что не может джаваскрипт, соответственно причина выбирать его — простота написания кода и ошибкобезопасность. Я уверен, если сообщить создателям CoffeeScript, что на их языке писать сложнее, чем на джаваскрипте, они ответят, что стремились создать язык, на котором писать проще.
Ну и если есть 2 совершенно разных куска кода, которые используются для достижения одной и той же цели и один кусок быстрее другого, то лучше использовать инструмент, который генерит быстрый код.
Далее. Нод, на котором я гонял тесты как выяснилось старый. Версии v0.10.40. В новом ноде пока не проверял сам, но друзья кофеманы говорят, что лямбды не рулят. Сейчас немного подумаю и добавлю апдейт с опровержением, или нову статью сделаю с разбором.
И да, в джаваскрипте действительно не оговорено как располагать в памяти массив. Но оговорено, то индексы массивов могут быть строками и могут содержать дырки. Что естественным образом приводит к необходимости держать его в хэше. Вследствии чего доступ по индексу мендленный.