Pull to refresh

Comments 30

“Быстро, элегантно, корректно. Выберите 2, учитывая, что ‘корректно’ уже занято”
“Fast, Slim, Correct. Pick any two, so long as one is ‘Correct’”

я бы перевел так — выберите 2, но так чтоб одно из них было 'Корректно'
учитывая что корректно уже занято — озночает что надо выбрать оставшиеся 2 варианта
Конечно нет.
В первом варианте мне показалось, что надо выбрать оба оставшихся (плюс к уже выбранному «корректно»).
(буду, буду читать каменты!)
UFO just landed and posted this here
Ага, «цвет автомобиля может быть любым, при условии, что он чёрный».
А что Вы думаете о будущем компиляции Javascript?

Помните, как в фильме «Москва слезам не верит» Родион рассказывал Саше про телевидение? Я бы примерно также сейчас сказал о Javascript. Но с телевидением все случилось не совсем так — посмотрим, как будет с JS.
Я думаю, если JS научится работать на скорости порядка 120% от натива, то можно будет спокойно забить на большинство других языков и писать всё (клиент, сервер, десктоп) на нём. :)
Впрочем, гораздо круче было бы, если бы это был не JS, а, скажем, Ruby.
120%? от натива? В чем может быть секрет такого результата?

Наверно, ближайшее будущее за кросс-компиляцией. Вопрос, насколько удобно отлаживать большие приложения через source-maps? Кто-нибудь практиковал?
120%? от натива? В чем может быть секрет такого результата?


Кабы я знал, был бы ведущим разработчиком Мозиллы или Микрософота какого-нить ;)

Вопрос, насколько удобно отлаживать большие приложения через source-maps? Кто-нибудь практиковал?


Если я правильно понимаю, то это примерно как отлаживать паскалевские программы. Т.е. кто-то должен будет соорудить прозрачный мэппер, чтобы программисту вообще не надо было задумваться, есть там промежуточная компиляция или нет.
Для тех, кто не понял мою мысль:
«120% скорости от натива» означает, что одну и ту же задачу нативный код выполнит за 100 секунд, а JS выполнит за 100*120% = 120 секунд, т.е. под скоростью выполнения я подразумевал время выполнения.
Почему я выразился именно так? Потому что, если тебя спрашивают: «Как быстро выполнится данная программа?», ты отвечаешь: «Секунд за 5», а не «1 500 000 элементарных операций в секунду». Ведь так? Отсюда и путаница в терминах.
Хотя, конечно, я согласен, что с формальной точки зрения термин «скорость» в данном случае использовать не совсем корректно.
«Как быстро» ≠ «с какой скоростью».
Как быстро ездит Ваш автомобиль, уважаемый?
Не очень. Разгоняется до сотни почти 30 секунд =)
Видите, Вы тоже решили нарушить формальность и вместо того, чтобы ответить, «как быстро ездит», рассказали мне, «как быстро набирает скорость».

Вот я выразился примерно по такому же принципу.
А разве набор скорости — это не езда?.. Так-то она ездит по-разному — так, как я хочу, то быстрее, то медленнее. Сейчас, например, вообще стоит.
Но вы правы, я указал недостаточно развёрнуто.
Развёрнуто
Разница в «как быстро выполнится» (через какое время закончится выполнение) VS «как быстро выполняется» (с какой скоростью выполняется). Совершенный вид против несовершенного.
У «как быстро» эта дифференциация есть, у «с какой скоростью» — нет.
Возьмём предложение «Моя машина с турбиной будет ездить со скоростью 120% от нынешней.» — придёт ли вам в голову при прочтении этого предложения, что она будет ездить медленнее?
Разница в «как быстро выполнится» (через какое время закончится выполнение) VS «как быстро выполняется» (с какой скоростью выполняется). Совершенный вид против несовершенного.


Если уж Вам так хочется по-воевать на тему языка, пожалуйста.
«Как быстро выполнится?» — это вопрос о том, что будет, если мы в будущем один раз запустим данную программу.
«Как быстро выполняется?» — может означать два варианта:
1. какое среднее время выполнения программы было зафиксировано после нескольких записей (аналогично Present Indefinite в агнлийском)
2. как много данных обрабатывает программа в единицу времени (аналогично Present Continuous в англ.)

А разве набор скорости — это не езда?.. Так-то она ездит по-разному — так, как я хочу, то быстрее, то медленнее. Сейчас, например, вообще стоит.

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

«Моя машина с турбиной будет ездить со скоростью 120% от нынешней.» — придёт ли вам в голову при прочтении этого предложения, что она будет ездить медленнее?


В отношении машины, аналогичный вопрос должен звучать так:
«С какой скоростью машина доезжает от Москвы до Одинцово?»

Да, такой вопрос звучит несколько коряво, но в принципе так сказать можно.

Хочу обратить Ваше особое внимание:
Я не пытаюсь доказать, что я всё правильно сделал и хорошо сформулировал по поводу 120% скорости, я прекрасно понимаю, почему ко мне претензии по этому поводу, однако я пытаюсь проанализировать и доказать, что я так выразился не от того, что я дурак, а в следствие объективно существующей путаницы с выражением «скорость выполнения программы». В момент написания «скорости порядка 120% от натива» я мыслил в терминах «времени выполнения», а не в терминах «количества операций в секунду». Кстати, нашлись люди, которые меня поняли, это значит, что я не один так могу мыслить.
120%? Маловато будет. Как минимум 146%!
Человек имел в виду время исполнения, а не скорость (т. е. обратную величину). Непонятно, за что все на него накинулись.
О, спасибо, что объяснил, а то я сижу и не понимаю, за что меня вообще минусуют!

… и к августу того же кода Майкрософт уже…
Оставьте эту прекрасную опечатку, оставьте. Она очень мила
UFO just landed and posted this here
UFO just landed and posted this here
Замечательное видео на эту же тему — vimeo.com/67050196
Видео на английском. Рассказывает Allen Wirfs-Brock
Подозрения начали закрадываться на этапе описания компиляторов. И подтвердились после:
Например, в C обычным способом хранения свойств и обращения к свойствам является хэш-таблица. Проблема с хэш-таблицей в том, что поиск по очень большой хэш-таблице может быть очень медленным.

После этого можно уже не читать. Тут сразу несколько ошибок.
Действительно. Подобное:
4. В конце концов байткод проходит через интерпретатор байткода, чтобы получился нативный код.

нельзя списать на издержки простоты описания. Интерпретатор байткода, осмелюсь предположить, байткод интерпретирует, а не транслирует в машинный код.

Хорошие статьи по реализации JavaScript, на мой взгляд, стоит искать туттут).
Можно было догадаться уже с первого же предложения второго абзаца =) Оказывается, SpiderMonkey 1995 года уже был не интерпретатором, а компилятором, да ещё и в нативный машинный код.
Sign up to leave a comment.

Articles