Как стать автором
Обновить

Комментарии 30

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

я бы перевел так — выберите 2, но так чтоб одно из них было 'Корректно'
А не всё-равно?
учитывая что корректно уже занято — озночает что надо выбрать оставшиеся 2 варианта
Конечно нет.
В первом варианте мне показалось, что надо выбрать оба оставшихся (плюс к уже выбранному «корректно»).
(буду, буду читать каменты!)
НЛО прилетело и опубликовало эту надпись здесь
Ага, «цвет автомобиля может быть любым, при условии, что он чёрный».
А что Вы думаете о будущем компиляции 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%!
Человек имел в виду время исполнения, а не скорость (т. е. обратную величину). Непонятно, за что все на него накинулись.
О, спасибо, что объяснил, а то я сижу и не понимаю, за что меня вообще минусуют!

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

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

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

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

Публикации

Истории