ActionScript - полная лажа" или "Как не надо делать интерпретаторы" - Страница 13

Stary · 09.01.2003, 18:29

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

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

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

3. ...

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

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

Смольный (Smolniy) · 10.01.2003, 03:27

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

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

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

[subway]design · 10.01.2003, 10:18

Во-во.

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

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

Crazy · 10.01.2003, 10:53

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

Arkady · 10.01.2003, 13:04

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

Stary · 10.01.2003, 15:13

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

2 Смольный:

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

Crazy · 10.01.2003, 15:27

Цитата:

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

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

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

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

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

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

Arkady · 10.01.2003, 15:44

Цитата:

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

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

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

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

[subway]design · 10.01.2003, 17:29

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

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

Смольный (Smolniy) · 10.01.2003, 17:32

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

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