Форум Flasher.ru - ActionScript - полная лажа" или "Как не надо делать интерпретаторы"

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)

- ActionScript (http://www.flasher.ru/forum/forumdisplay.php?f=5)

Сказать по правде, я искал в этом топике немного другое. Тут прозвучала пара полезных мыслей, но я не уверен - правильно ли их понял. Давайте попытаемся хоть слегка согреться у костра из этих сломанных копий...

1. Предпочтительнее использовать цифровые индексы массивов перед строковыми. (поправляйте меня, если что не так)

2. Функцию eval() использовать нежелательно (даже не знаю, как я теперь смогу решать некоторые задачи) - может подскажете, что использовать вместо нее...

3. ...

Хм... так и не смог вспомнить больше ничего существенного. Поймите вы наконец, что хорош АС или плох, а деться от него некуда. Так давайте подумаем, как с ним жить дальше. Насчет оптимизации графики и анимации я уж как-нибудь сам. А вот насчет АС - ау, программеры. Сможет кто-нибудь продолжить список?

Отдельное спасибо Морту, который сумел отлично обрисовать положение вещей. Добавить просто нечего.

Господа, а почему все так вцепились в "индексацию массивов"? Я еще раз повторяю - в "настоящих" языках программирования индексы массивов нигде не хранятся! Массив - набор данных, хранящихся сплошняком, начинающийся с определенного адреса, и индекс - число, из корого (с учетом длины одного элемента) вычисляется смещение относительно начала массива, по которому и берется искомый элемент. Однажды я на сях обрабатывал массив из >60.000 элементов, и при переборе их в цикле, невнимательно воспользовался знаковым интом в качестве индекса. При достижении индекса ~32.000 мой инт переваливал в отрицательные значения, и я начинал гулять по памяти, результат был забавнейшим - я убивал и программу, и дос, и кажется добирался до видеопамяти. Такие вещи очень здорово дисциплинируют и наглядно показывают, откуда растут уши.
То же касается вообще имен переменных - при компиляции в код вместо имени переменной вставляется адрес, по которому хранится значение, поэтому на сях можно использовать переменные с именем любой длины, это не повлияет на размер результата. Как следствие, такие финты ухами как eval или a.["b"] там просто не бывают. Уверяю, программить на си-подобном языке было бы комфортно (мне) и КАРДИНАЛЬНО НЕУДОБНО процентам 85 из разработчиков Flash. Не говоря о том, что СКОРОСТЬ от Flash даже близко не требуется - вопреки многократно озвученному мнению автора топика. Учитывая задачи, решаемые флашем и историю продукта, можно смело сказать что скорости AS хватает по уши и раз двадцать столько же сверху. Я до сих пор не видел ни одного фильма, который бы тормозил на программинге, а не на отрисовке изображения, если не считать искусственных примеров.
Хэши - это уже не массив, это "приблуда". К ней и отношение соответствующее. И у хэша с очень большой вероятностью индексы хранятся текстом. Если иной раз они хранятся числом, как у флеша, то это здорово, неожиданно, но не так уж важно. Все равно перебор элемента за элементом. И как там организуют хранение в памяти данных - связным списком ли, просто таблицей ли, не так важно, производительность все равно будет потеряна. Да плевать на скорость! Лишь бы работало правильно. Я не атомную бомбу на флеше рассчитываю, максимум - доморощенный трехмер. Лишь бы на переборе строк не тормозило (а пятерка тормозила страшно, например, при необходимости заменить в строке все < и > на > и <, тормоза на этой операции было видно глазами).

Флаш интерпретирует все, что можно. Например, инкремент или двоичные сдвиги должны работать в сотни раз быстрее чем другие команды - но работают с той же скоростью, т.к. интерпретируются, а не выполняются на уровне процессора. Ей богу, я не вижу смысла убеждаться в тормознутости АС. Мне кажется, это ни к чему не приведет. Гораздо полезнее обсуждать несообразности в командах. Это хоть имеет практическую пользу. Например, меня раздражает дурацкое и НЕОДИНАКОВОЕ поведение команд gotoAndPlay и movie.gotoAndPlay. Вот это - реальная практическая проблема. К тому же, необоснованная, что бесит. Меня удручают оставшиеся в наследство от старой жизни level-ы и сцены. Мне очень понравилось, что в МХ ММ умудрилась исправить массу ошибок и "особенностей", которые, я полагал, останутся для совместимости навсегда. Я могу назвать таких фишек массу. При этом не нарушилась совместимость, т.е. если я публикую в 5, то оно работает так как работало в 5, при публикации в 6 - по-новому. Не вижу, почему бы точно так же не причесать gotoAndPlay. Далее, напротив, я удручен действием команды with, которая в МХ, похоже, стала работать еще хуже чем в 5.

А мы тут ругаемся и обещаем пропустить друг друга через виртуальную машину ФП :):)

Во-во.

Но, "Java - не интерпретирующий(емый, имелся в виду?) язык,... "

Почему? Этот тот же байт-код, который читается интерпретатором.

Интерпретатор и "Интерпретатор байткода" -- совершенно разные понятия.

неудержание :)

ну, может быть и можно сказать, что язык туарегов и русский - совершенно разные понятия :)

Так... Хоть я остался и неуслышан, но уже кое что конструктивное появилось...

2 Смольный:

поподробнее насчет gotoAndPlay() нельзя ли?
единственное, что меня лично смутило, что когда эта команда встречается в потоке, то бывает, что плеер, видимо не успевая ее догрузить, тупо ее пропускает и продолжает отрисовывать следующий кадр (хотя goto должна перевести маркер воспроизведения совсем в другое место). То же самое относится и к stop()

Re: неудержание :)

Цитата:

Оригинал написал(а) Arkady
ну, может быть и можно сказать, что язык туарегов и русский - совершенно разные понятия :)

Точнее будет сказать, что русский и Алгол -- совершенно разные языки. Примерно того же порядка разница между яйцами, что находятся в мужских трусах и теми, что снесла Курочка Ряба.

Объясняю на пальцах:

1. Задачей обычного интерпретатора является анализ синтаксиса языка и исполнение распознанной языковой конструкции.

2. Задачей интерпретатора байткода является исполнение заранее подготовленной последовательности команд, которую создал компилятор байткода.

Принципиальная разница здесь -- в полном отсутствии этапа синтаксического анализа.

рецидив :))

Цитата:

Принципиальная разница здесь --...

ну ладно, сдаюсь :)
хотя эта разница, опять же - не семантическая ("на уровне языка"), а "чисто программерская", т.е. исходит из того, как написан прекомпилятор
т.е. (кгхм.. фантастическая (?) ситуация) если коряво написать прекомпилятор ("не знает языка :)"), то получится нехорошо

(из законов Мэрфи: "...если нет ошибки в программе, ошибка - в компиляторе ")

в общем, мы говорим про разные вещи на разных языках :(

Называйте как хотите, Flash MX и JBuilder оба транслируют кривой Си-подобный код в компактный "байт-код" (тоже, называйте, как хотите). А плагины (Плеер и Вирт. Машина) этот байт-код читают и выполняют. Таким образом, и Флеш и Ява - интерпретаторы одного класса (вида, отряда, семейства).

Если это не так, жду объяснения.

[subway]design
Ну, вообще я в джаве не силен, но насколько помню институтский курс, программа проходит два процесса компиляции - первый в среде разработки до уровня байт-кода, а JVM, работающая на конкретной платформе, докомпилирует его в полноценное приложение и обеспечивает программное окружение, т.е. все-таки это полная компиляция. Я, помнится, все до препода домогался - компилируется или интерпретируется приложение в JVM, он говорил что компилируется. Иначе незачем такие строгости вводить в плане типизации данных, да и арифметика указателей там вроде есть в зачаточном виде. Но я могу ошибаться.

Stary
А че там говорить, эти команды не совместимы по количеству параметров и работают по-разному. Напр. goto работает со сценами, а mc.goto их знать не знает. Есть разница и в нумерации кадров - goto считает их по сценам, mc.goto - сквозняком через весь фильм. goto понимает что метки находятся в разных сценах, для mc.goto нужны уникальные метки через весь фильм, иначе он идет на первую из одинаковых. В общем, сплошные частные случаи...

Цитата:

Оригинал написал(а) Смольный (Smolniy)
Я, помнится, все до препода домогался - компилируется или интерпретируется приложение в JVM, он говорил что компилируется.

Обманул. :)

МОЖЕТ докомпилится. Причем, продвинутые реализации читают байткод, восстанавливают по нему семантическое дерево и заново повторяют этам кодогенерации, но уже для данной платформы. По-дефолту же байткод просто интерпретируется (в отличие от .NET, где поо-дефолту идет докомпиляция), причем он ориентирован именно на режим интерпретации.

BTW, если интересно, то рекомендую поискать материалы про проект Джус -- там основная идея была в том, чтобы вообще не формировать байткод, а просто сериализовать дерево разбора. А уже перед исполнением по этому дереву выполняется нативная кодогенерация. Гадкая Java удушили этот проект... :)

Цитата:

Оригинал написал(а) [subway]design
Таким образом, и Флеш и Ява - интерпретаторы одного класса (вида, отряда, семейства).

У Java две части -- компилирующая и исполняющая -- разделены. У флэша -- смешаны в одну кучу.

оооо ёёёёё.... шире вселеееенооой гооооре моооёёёё.... :)))))))
офигенный все-таки топик =))) настроение поднимает... ууу....

2Смольный
по поводу индексации и проч.: просто изначально тема была начата с частностей, хотя потооом (на пятой странице :)) ) автор-таки сознался что на самом-то следует мыслить глобальными категориями, не зацикливаясь между гоуту и плеями =)) война-фигня, главное - маневры !.. 8)

2Stary
очень спорно =) насчет дизайнеров, королей и капусты =)

2 Смольный

Что-то я не пойму. Какие же могут быть сцены в пределах одного мувика (если применяется mc.gotoAndPlay() )? Или могут? Я никогда не связывался со сценами и вообще нужды в них не вижу.

Давайте условимся. Повторяющийся в 100 процентах случаев глюк - это не глюк, а недокументированная возможность. Нужно только их изучить и помнить, чтобы не наткнуться на проблемы. Вот когда в одном случае срабатывает так, а в другом - эдак - вот это глюк действительно. Чтобы его обойти, нужно вообще отказаться от данного решения и использовать какое-нибудь другое. Именно это, бывает, происходит, например, если в первом кадре написать stop(), а потом пытаться проиграть все в потоке без прелоадера. В одном случае происходит остановка на первом кадре, в другом - нифига. Вот это глюк, я считаю.

оо, дяденька смольный пришел :))

Код:

MovieClip.prototype.gotoAndPlay = function  (frame) {

        tellTarget (this._target) {

            gotoAndPlay (frame);

        };

};

MovieClip.prototype.gotoAndStop = function  (frame) {

        tellTarget (this._target) {

            gotoAndStop (frame);

        };

};

вот так определяются методы anymc.gotoAndStop и anymc.gotoAndPlay самим плейером... при желании можно переопределить под себя )

Спасибо, просветили.

Похоже вторую волну этого топика я пропустил.

чтож, начнем разбор полетов :)
как выяснилось, тормоза АС - это фирменные маркетинговые решения макромедии :D
и все с этим согласились.
сколько не пытался объяснить, что я считаю неудачной *внутреннюю* реализацию
АС и не имею ничего против синтаксиса, все равно никто не понял. ну и ладно :(

2 mort и остальным:
ну и зацепили же вы это приведение типов, хотя я в первую очередь хотел
сказать, что поиск по строковым идентификаторам, это плохо для производительности,
как в индексе массива, так и в идентификации переменной, поскольку переменные
в АС тоже при вычислении определяются по их названию (это доказывает

Код:

var var1="var";

var var2="iable";

var variable="Hello";

trace(eval(var1+var2));

как я НЕОДНОКРАТНО говорил выше.

Цитата:

3. Ну а ежели кто-то желает делать рассчеты траектории движения баллистических ракет в реальном времени, пускай воспользуется ассемблером.

lol хотел бы я посмотреть рассчет движения баллистических ракет на ассемблере :D

Цитата:

В AS сделано все для удобства и быстрого написания прикладного кода без особых заморочек на оптимизацию и прочего.

мда... что тут говорить. оптимизируй - не оптимизируй, а тормозить будет всеравно :(

Цитата:

Прощает твоё "Полная лажа" только исключительная субъективность размышлений отдельных индивидумов.

Спасибо, что простили, меня это ужасно радует :D
кстати я никогда не претендовал на объективность своих рассуждений.

Цитата:

Не нужно гадить на всех со своей колокольни.

А я то думал, что гадят тут только на меня... :(

говорите АС это скрипт для дизайнеров, простой и интуитивно понятный. это
конечно правда, если писать в кадрах только stop() и play(), но как только
надо написать что-то более-менее серьезное, даже у программистов волосы
дыбом становятся от непредсказуемости поведения плеера :(

2 Смольный (Smolniy)

Цитата:

"хранение индекса у массива и поиск по индексу" в принципе не существует. Есть "вычисление адреса в памяти элемента массива в зависимости от индекса", это другая веСТЧЬ.

суть не меняеться, а суть - это перебор строкового списка.

2 Stary
не переживай, используй все как использовал, от тормозов всеравно ты не избавишься :D

2 [subway]Design

Цитата:

2 бесконечность: перечитайте ту мессагу, пожалуйста, и, если я не прав, ясно и четко выскажите свое мнение и то, почему я не прав. Спасибо.

какую мессагу конкретно?

Выводы?
Выводы:
Что ж, может я и ошибся. ActionScript - не полная лажа. Просто лажа, но не
полная :D лажа, процентов эдак на 95 :D :D :D

Что я хотел сказать названием топика, так это то, что АС можно было сделать
ГОРАЗДО лучше и быстрее, при этом его удобность не пострадала, а тут раздулся
такой флейм, хоть и довольно веселый :) похоже ли на театр - врядли, больше
похоже на сессию верховной рады - все говорят, но никто не слушает :) :) :)
Приведу последний пример - perl по функциональности не хуже АС, просто
не привязанн к конкретной программе, но работает ГОРАЗДО быстрее АС.
где, говорите маркетинг? а ламера где?

Весь тред читать ломало, тем более тут больше флейма.
Отвечаю на следующий вопрос: почему доступ к переменным осуществляется через название, а не через адрес.

Очень просто. Вот простой пример.
Допустим, у нас есть 5 мувиклипов, названных button1, button2, button3, button4, button5.

мы может обрабатывать их в цикле:

for (var i=1; i<6; i++)
initButton(_root["button"+i]);

Если бы доступ был по адресу, то такая фишка была бы просто невозможна.

Я пока не дизасмил флеш-плеер, и не знаю: используется у них какая-то оптимизация или нет. Надеюсь, они используют хеш-таблицы для ускорения поиска переменных. По крайней мере в 7-м плеере.

Но одно я знаю точно: строки в байт-коде хранятся один раз в пуле строк, а затем доступ к ним происходит по индексу.
Так что по крайней мере здесь они некоторую оптимизацию выполнили (как по размеру, так и по скорости).

Кстати, причина многих сильных тормозов заключается в том, что скрипт компилируется в байт-код крайне не оптимально.
В Flash MX 2004 некоторые улучшения есть, но их недостаточно.
Поэтому, если вам нужно БЫСТРОЕ выполнение скрипта, то после того, как проект полностью сделан, возьмите Flasm (кто не слышал - это ассемблер/дизассемблер для байт-кода) и подчистите код.

У меня получалось достигнуть ускорения в несколько раз.
Правда, если проект большой, запаритесь оптимизировать на низком уровне.

Цитата:

Оригинал написал(а) Лжеучёный
Если бы доступ был по адресу, то такая фишка была бы просто невозможна.

эээ... какой-то странный аргумент :)

можно было организовать такой цикл путём размещения такого "массива" клипов друг за другом в памяти и перебирать их по адресам. или, скажем, при запуске плеера размешать вообще все уже существующие в линейке клипы в памяти друг за другом... для удобства перебора :)

я не спорю тут ни с чем, да и топик в целом какой-то сомнительный, но аргумент слабоватый получился :)

Ладно, вот другой пример.

var depth = 0;

function attachChild(id) {
var name = id+"_mc"+depth;
_root.attachMovie(id, name, depth);
depth++;
return _root[name];
}

Эта функция динамически создаёт мувиклипы, позволяя не заморачиваться насчёт глубины.
Имена мувиклипов тоже создаются динамически.
Заранее сделать статичный массив с перечнем всех мувиклипов нельзя, так как создаются они только в процессе работы.
Здесь индексация по строкам очень выручает.

(горький вздох)

А вообще, несовершенство не в ActionScript, а в железе.
Вот когда будут процессоры для PC по-настоящему векторными (вместо пародии на векторность в виде MMX и SSE1,2,3), да память станет ассоциативной, тогда поиск элемента по строковому индексу будет не сколь не медленнее индексирования по числу.
А то, что индексирование по строке - это вещь удобная, я думаю, сомнения не вызывает.

Короче, тема должна называться так:
"Intel Architecture 32 - полная лажа" или "Как не надо делать микропроцессоры"

докатились :D

Автор треда! Тебе времени не жалко обсуждает этот жалкий АС? Иди лучше пропиши пару тысяч строк кода в рулезном Си.

Или поработай в Макромедии и сделай, как надо. А не пукай в лужу в больших количествах.

Неее.... это он еще не прочитал слова Лжеучёного.... Мельница должна заработать с новой силой :D

*залил всех из плазмагана*

*собрал оружие и аптечки*

*удаляется*