Комментарии 37
Я правильно понял, что это обычный float, но вместо 2 используется 10?
Если да, то это шило на мыло.
Нет тут вы не правы. Замена основания экспоненты с 2 на 10 действительно поможет исправить часть проблем связанных с операциями над вещественными числами, да и вывод их существенно упроститься… Но автор, к сожалению, не учел, что делать с такими обыкновенными дробями, как 1/3. Так что мне кажется, что будущее будет за типом fraction(дробь)
fraction не спасет от корней, логарифмов и проч.
А так неплохо, да.
Но лучше бы просто длинную арифметику добавили.
Почему не спасет? Я уверен, что в любых вычислениях мы заранее можем задать требуемую точность(никому ведь, кроме совсем неадекватных, не потребуется вычислить 1 млн или сразу бесконечность знаков числа pi), а если можно задать точность, то становятся применимы и стандартные алгоритмы нахождения корней, логарифмов и т.д. Единственное, что от этого пострадает — это скорость вычислений, но как говорится за все нужно платить…
Да как бы он ничего нового не изобрел такие же методы давно используются в научных вычислениях, где важна высокая точность особенно с большими числами. В многих книгах по алгоритмам поднимается этот вопрос. Я помню сам писал что-то подобное, когда учился. А насчет fraction это хотели в dart реализовать, но вроде потом от идеи отказались. Вообще куда сейчас движется JS так это в сторону Dart, даже ES6 часть конструкций слизал с dart. Все проблемы с JS, что разработчики dart озвучивали еще в 2011 году, сейчас озвучиваются на JS конференциях, и к этому приходят сами разработчики, натыкаясь в работе на ограничения. Я не удивлюсь если, через 10 лет JS разработчики откроют для себя, что пишут код на Dart… Многие вещи, что выдают за изобретения и инновация уже давно изобретены кем-то другим…
Вообще, я впервые вижу, чтобы автор поднимал в своей статье те же проблемы, что появились в виде вопросов и у меня в голове пару месяцев назад. Правда жаль, что между нами более 20 лет разницы…
Хвостовая оптимизация в языке — это, безусловно, хорошо. Но у нее есть один недостаток, затрудряющий отладку: потеря фреймов стека, в результате чего в цепочке вызовов функций A->B->C->D при возникновении исключения в D мы видим в стектрейсе только A и D. Так что мы не имеем никакого понятия, откуда именно была вызвана D.
Когда делаешь интерфейсы с сотней items в массиве, то может показаться забавным, что алгоритмы по изменению массивов с данными о пикселях с применением цикла for могут дать ну очень существенный прирост. Так к примеру на минимальном разрешении 1024х768 массив имеет длину в 786432 элементов, а итераций для изменения может достигать тоже очень много. поэтому заявления что for это ошибка, ошибочно! Ну а использовать рекурсию вместо циклов, если даже рекурсию сделают по скорости выполнения равной циклам, то лично мне было ну очень сложно начать программировать с использованием рекурсий. К слову, кто-нибудь замерял скорость хвостовых рекурсий vs циклы?
И я думаю что не у меня одного так, но у меня не бывает ошибок с this. Да когда-то были, но из-за отсутствия статической типизации ошибки, опечатки и прочее бывают до сих пор. Поэтому this ну не самая страшная ошибка.
И я думаю что не у меня одного так, но у меня не бывает ошибок с this. Да когда-то были, но из-за отсутствия статической типизации ошибки, опечатки и прочее бывают до сих пор. Поэтому this ну не самая страшная ошибка.
Он не говорит, что for — это ошибка. Он утверждает, что for для JS перешел в разряд deprecated… Да и в С++, использование for является вынужденной мерой, т.к. конструкции for_each и (…: ...) появились в нем совсем недавно и не позваляют разгуляться в полной мере…
Это получается что учить js друзьям не советовать? Если такие разговоры пошли, то лет через пять, после внедрения wasm js просто уйдет в небытия, ведь на любом языке можно будет писать программы для браузера и самое главное, что это будет легально и более того, знать нативный js, как в случаи с препроцессорами, уже не нужно. Кто тогда лидирует, c#?
Я думаю, что небольшие страницы по прежнему будут писать на JS, но когда дело будет доходить до крупных сайтов с тысячами посетителей в день, там уже будет использоваться другие языки(хотя мне до сих пор не понятно, как они собираются взамодействовать с html). Это как сравнивать python и С… У каждого есть свои преимущества и недостатки…
Может не дать прироста на последних версиях VM. Сейчас во многих виртуальных машинах JIT оптимизирует код нереально круто и прощает ошибки. А вот в старых браузерах и виртуальных машинах может быть реальный затык… Приходится делать сложные бенчмарки, чтобы jit не оптимизировал и делал реальный тест, вместо гоняния воздуха туда-сюда, и мерить производительность на критичных участках программы…
Самый большой прирост дают дают typed arrays… while будет быстрее for, если запуск цикла один, а потом jit оптимизирует for…
Самый большой прирост дают дают typed arrays… while будет быстрее for, если запуск цикла один, а потом jit оптимизирует for…
Но оказывается, что писать хорошие программы на JavaScript не только невозможно, но и не нужно.
Одна из сильнейших сторон javascript.
Писать можно. Но по сравнению с нормальными языками типа C++, Java, C#, python, приходится много писать костылей, чтобы реализовать банальные вещи, которые делаются в других языках очень просто и легко. Ну и многие действия бьют сильно по производительности кода. JS — язык написания костылей… Имхо изначально архитектура языка не совсем удачная и все развитие языка идет к прикручиванию костылей к языку… Преимущество языка — он простой и легкий вход в него, по сравнению например с dart, который больше подходит для крупных проектов…
Есть же даже теория о том, что чем проще(для написания сложных вещей) язык, тем проще на нем писать короткие программы, но при разрастании кода, простота играет злую шутку…
Во времена создания JavaScript и С системы были не слишком новороченными, поэтому создатели не подумали о том, что произойдет с их детищем в будущем.
Во времена создания JavaScript и С системы были не слишком новороченными, поэтому создатели не подумали о том, что произойдет с их детищем в будущем.
Реально здраво мыслящий человек, жаль такие редко проектируют языки.
А где ссылка на оригинал?
У меня есть подозрение, что
вместо создания обратной последовательности вызова компилятор генерирует скачок
это не совсем то, что хотел сказать автор.
По существу:
Крокфорд, конечно, голова — но в данном докладе он кое-где гонит :)
- Разве Алан Кей придумал C++, а не Smalltalk?
- Pascal сюда зачем-то сюда приплел в контексте "начала объектно-ориентированного программирования". Почему не тот же Smaltalk? Да даже C++, если верить википедии, был создан раньше, чем Object Pascal (не путаем с оригинальным Pascal, в котором объектов не было
- Консервативность в принятии новых языков разработчиками. Имхо вопрос больше в аппаратных возможностях. Высокие абстракции, как правило, требуют больше аппаратных ресурсов. Когда производительность стала позволять, разработчики стали переключаться на более высокоуровневые инструменты.
Я не использую for each. В ES5 мы получили object .keys(object). Эта конструкция дает вам хороший массив строк. И он не включает в себя вещи из цепочки прототипов, поэтому вам не нужно фильтровать результаты. Очень приятно, что я могу взять массив и выполнить for each таким образом, это действительно выразительный способ.
Douglas Crockford в видео ясно говорит "for each", но судя по контексту, он имел ввиду, что не использует "for in". Думаю, он оговорился.
Пассаж про WeakMap тоже непонятен, т.к. есть еще Map, без "слабого" названия. Что означает Weak в названии он не объяснил, только запутав слушателей.
P.S. это не претензии к переводу, просто мысли в слух.
В 1980 он наконец был опубликован. И это был лучший из разработанных языков программирования в истории — С++. Алан Кей взял идеи Simula, не совсем понял их, но перевел на C.
Что за бред? Речь явно про Smalltalk, но какое отношение он имеет к С?
Религиозная ажиотация зашкаливает. Так подпитываются холивары.
«Лямбды появились в языке под названием Squeak в MIT в начале семидесятых.»
Lisp? Нет, не слышал…
Lisp? Нет, не слышал…
Похоже, скоро будет пересечение. Я не могу предсказать, когда это произойдет. Но Google может. Согласно прогнозам Google Trends это произойдет в этом году (2015 — прим. ред.). JSON наконец станет официально более интересным, чем XML.Совсем немного ошибся: пересечение двух технологий и перевес JSON зафиксированы в апреле 2016 г.
В начале объектно-ориентированного программирования мы стартовали с идеи, реализованной в Pascal, согласно которой у нас есть запись, а затем мы связываем с этой записью функции, которые являются методами, действующими на элементы записи.
Похоже, это про Оберон, а не про Паскаль. Не помню, чтобы в классическом Паскале вообще ООП было, а вот в Обероне Вирт именно так сделал.
И кстати, в Go эта идея из Оберона перетекла, Пайк где-то упоминал.
"… Одна из вещей, которая затрудняет ее решение — this. Если у вас есть this в методе, оно привязывается к списку событий объекта (это хорошо и необходимо). Но если вы вызываете тот же метод в качестве функции, this привязывается к глобальному объекту ..."
Плиз, знающие люди, объясните этот момент подробнее. Можно примером.
Плиз, знающие люди, объясните этот момент подробнее. Можно примером.
Чтобы понять, запустите в консоли браузера.
const obj = {};
obj['foo'] = function () {
console.log(this === obj);
console.log(this === window);
};
obj.foo(); // => true, false
const fn = obj.foo;
fn(); // => false, trueПолучается, что
равноценно
Здесь наверное имелось ввиду, что контекст теряется при передаче метода из объекта в другой объект?
const fn = obj.foo;
fn();
равноценно
const window.fn = obj.foo;
window.fn();
Здесь наверное имелось ввиду, что контекст теряется при передаче метода из объекта в другой объект?
Нет, не равноценно. fn — локальное, оно видно только внутри блока, в котором объявленно. В случае консоли, оно, конечно, будет глобальным. Вот пример с локальной областью видимости.
(function() {
const localFoo = obj.foo;
localFoo(); // => false, true
})();
console.log(window.localFoo); // => undefinedС this все плохо, оно определяется способом вызова (про связанные функции не будем вспоминать)
Хм… для
localFoo(); // => false, true
(function() {
...
})();
Тут все еще несколько хитрее. Глобальная область видимости — это поля глобального объекта, в данном случае window. Однако же localFoo не принадлежит window, это просто локально объявленная константа. Вот пример того, как мы радостно дали эту функцию другому объекту (это ровно одна и та же функция, нужно заметить), а this снова поменялся.
const obj2 = { otherFoo: obj.foo };
obj2.otherFoo(); // => false, falsethis внутри функции сам по себе по умолчанию не привязан к определенному объекту, а определяется способом вызова.
Т.е. если мы вызываем функцию как метод (obj.foo()), то this будет определен как объект, содержащий поле. Но если мы вызываем функцию как функцию, то такого объекта, очевидно, нет. Но javascript в данном случае нам просто радостно подставляет глобальный объект. Это особенно раздражает в случае если передавать метод как callback. Но напрямую это сделать нельзя (this потеряется), его нужно каким-то образом привязать к правильному объекту.
С другой стороны это позволяет делать многие вещи, которые напрямую невозможны в других языках. Например, мы можем передать функцию, которая затем будет вызвана как метод другого объекта (на этом половина jQuery построена).
ошибся уровнем
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
The Better Parts: доклад Дугласа Крокфорда о JavaScript и языках программирования будущего с конференции .concat() 2015