>> Передача прав наследникам — величайшая глупость.
Т.е. передача наследникам дела, дома, машины, яхты, земли и счёта в банке, к которым они не имеют никакого отношения, — это не глупость, а передача права на произведения, которое позволит наследникам получать стабильный доход, почему-то глупость.
>> Есть большое количество записей, ныне уже не защищенных копирайтом, но через несколько лет закон опять исправят (вы ведь помните, сколько раз меняли закон о продлении срока копирайта?)
Существует куча открытых программ. Или, например, Википедия. Все попытки на них наехать заканчиваются ничем. Почему это вдруг купленная сообществом запись вдруг станет вне закона?
Пускай меняют срок копирайта хоть до бесконечности. Сообщество купило музыкальное произведение и в праве распоряжаться как захочет.
>> Теперь я могу переслать вам книгу (через P2P, к примеру), и затраты на это понесем только вы и я. Всё. Никаких посредников.
А книга из воздуха взялась? Никто её не писал, никто не корректировал, никто не делал дизайн книги, никто не делал иллюстраций и т.д.?
>> Для того, чтобы написать книгу, не нужны многомиллионные гонорары (про кино и игры умолчим ;), хотя там тоже встречаются созданные буквально на коленке шедевры).
А сколько должен получать автор? Автор может писать книгу несколько лет. Вправе ли автор получать каждый месяц по 100 тыс. рублей? В год это делает 1.200 тыс рублей. И это только автору. А ведь над книгой работают корректоры, иллюстраторы, дизайнеры, верстальщики. Они ведь тоже деньги хотят получить за свою работу. Так сколько стоит сделать хорошую книгу?
Все эти страдания вокруг копирайта яйца выеденного не стоят. Хотите бесплатную ОС пользуйтесь, например, каким-нибудь дистрибутивом Линукса или Юникса. Хотите бесплатный графический редактор — ГИМП. Музыка — куча сервисом для независимых музыкантов. Книги — идите в блоги или опять же на специализированные ресурсы. Но ведь большинству нужна именно Виндоус, Фотошоп и т.д. Потому что с ними удобней. А удобны они благодаря труду сотрудников Майкрософт и Адоб. Но платить за этот труд многие не хотят.
Точно так же и с музыкой, и с книгами, и с кино. Автору выше дали ссылку на искомое произведение, но в другом исполнении. Но автор нос воротит — исполнение слабое. Нужна именно запись ЭМИ. То, что именно ЭМИ купила эту запись, хранила её, отцифровала и т.д., автора не заботит. Автор статьи хочет именно эту запись и, конечно же, бесплатно.
А Вас не смущает, что магазин, который не производит ни одни из продаваемых товаров, делает наценку? Или чтобы купить запись, надо лично связываться с автором или его наследниками, дабы узнать как им можно заплатить?
Ну если так всё просто, то договоритесь с ORTF, сделайте отцифровку записи и т.д. Но думаю, что Вы этого никогда не сделаете и делать не будете.
Это вопрос и з той же серии, что зачем платить админу? Он же ведь просто действует по руководствам. Зачем платить дворнику? Он же ведь просто махает метлой? Зачем платить платить таксисту? Я и сам могу водить. И т.д., и т.п.
Люди делают отцифровку старых записей, платят отчисления авторам и т.д., и т.п. Естественно, что раз они тратят свои деньги и усилия, то он в праве требовать вознаграждения за свой труд.
Платят не за музыку — она бесплатна, а за исполнение. Отчисления идут исполнителям или их наследникам.
Кстати, борцы с копирастами могут воплотить в жизнь свои идеи по поводу оплаты труда исполнителей. Что мешает объявить сбор денег для музыкантов, которые будут записывать классические произведения и выкладывать их в свободный доступ?
В Новосибирске ВОИС докопалась до местных загсов из-за марша Мендельсона. Так местный филармонический оркестр записал марш Мендельсона и передал запись загсу в безвозмездное пользование. www.philharmonia-nsk.ru/press/filarmoniya-v-presse/novosibirskiy-simfon2
Дело не в том, что делает Adobe, а в том, как он это преподносит.
Зачем они совместили объявление об усилении разработки инструментов для HTML5 с сообщением о прекращении разработки мобильного флэш плеера? Если бы они разнесли бы эти сообщения по времени, разве что-нибудь изменилось бы?
Зачем впихивать в «Вопросы и Ответы» совет переходить на HTML5? Они что всерьёз думают, что флэш-разработчики ломанутся с ActionScript 3.0 на HTML5+JS?
Почему не стали давать внятных подробных ответов?
Ничего серьёзного для флэш плеера не произошло (даже для мобильных устройств, ибо 11-го флэш плеера хватит на несколько лет, а потом них можно будет спокойно запускать десктопную версию), но это было преподнесено так, что завтра Adobe прекращает разработку платформы. Это сравнимо с тем, как если бы в самолёте, который нормально летит, капитан начал рассказывать пассажирам про вероятность падения. Толку никакого, но паника была бы точно.
Ничего против Agile не имею, только за, т.к. упорядочивание процесса — это хорошо. Только вот статья написана в духе «Agile для самых маленьких. С иллюстрациями». Поэтому возникает много вопросов:
1. Agile требует накладных расходов. Например, 5-минутная встреча абсолютно бесполезна, если представляет собой чтение в слух с выражением задач из багтрекера. А любое обсуждение возникших трудностей превращает её в часовой разговор о делах наших скорбных. Всё это требует времени разработчика, за которое платит компания. В итоге это приводит к повышению стоимости разработки, что не есть хорошо, ведь мы заботимся о благе организации.
2. Предполагается, что в проекте идеальная ситуация: один проект, длительный срок, нет просроченных задач и т.д. А теперь представим реальную ситуацию, когда проектов несколько. Переключаться между ними тяжело, а значит обобщить все задачи будет трудно. Или, к примеру, прибегает менеджер с воплем «шеф, усё пропало». Недовольные клиенты штурмуют офис — взяли первый этаж и сбоями продвигаются к кухне. Как быть в этом случае?
3. Прозрачность кода — это хорошо. Но что если в проектной команде каждой твари по паре? Один верстальщик, один flash-разработчик, один js-разработчик, один специалист по базам данных и т.д. Кто и что будет проверять? Кто будет проводить код-ревью и т.д.?
1. Сложнейшая инженерная задача. Если автобус будет левитировать, то колёса ему же не нужны. И тогда автобус превращается из автомобиля в что-то на подобие гибрида самолёта и трамвая. Кто и как это будет внедрять?
Как организовать дозаправку жидким азотом? Он ведь испаряется.
2. Цена. Сверхпроводники — это очень дорого.
3. Безопасность. Если солнце припечёт, сосуды Дьюара с азотом взорвутся.
Кажется, будет Вторая браузерная война. Кстати, в Первую у IE тоже был свой язык VBScript, но от него пришлось отказаться, хотя Internet Explorer победил.
Если начнётся война, то с фантазиями на тему единых открытых стандартов (привет, HTML5) придётся попрощаться. Каждый браузер будет изголяться как может.
Употребление слова «ниггер» не имеет никакого отношения к свободе. В любом языке есть оскорбительные названия тех или иных наций и рас. Я сомневаюсь, что Вы обращаетесь к своим коллегам еврейского происхождения, используя слово «жид». Т.к. это слово в русском языке является оскорбительным, также как и «ниггер» в английском.
Просто у нас в стране из-за неадекватного перевода американский фильмов население не понимает, что в большинстве боевиков ему показывают не нормальных людей, а уголовников, низы общества, урок, гопников и откровенное быдло. Перенимать их язык и манеру общения всё равно, что «ботать по фене».
1. К ActionScript 3 заявления Google имеют мало отношения, т.к. Adobe сильно над ним поработал: классический ООП, статическая типизация и т.д. и т.п.
2. Разница в оптимизациях. Если есть нормальная IDE, то она сама их осуществит. В противном случае программист должен очень хорошо разбираться, как и что отрисовывается. На практике такими оптимизациями в ручную никто заниматься не будет.
2а. При том, что браузеры, которые отрисовывают Canvas, могут переложить расчёт анимации с процессора на видеокарту. Flash Player долгое время это делать не мог — расчёт анимации проводился на процессоре. Это было одним из доводов за отказ от Flash. Но с 10 версии он получил доступ к видеокарте, поэтому нагрузка на процессор значительно снизилась.
2б. При том, что один из доводов против Flash — это огромное количество баннеров, которые тормозят систему. Но если уберут Flash, то получат баннеры на HTML5.
3а. Фреймворк упрощает разработку, но увеличивает расход ресурсов: больше вес, больше нагрузка на процессор и т.д.
3б. Ну, что и требовалось доказать. На 20% пользователей с Flash больше, чем с Canvas. При этом, судя по всему, статистика не учитывает полноту реализации Canvas. Ну и слово «скоро» ничего не говорит о том, когда конкретно это произойдёт. Может завтра, а может через пять лет. Судя по графику за последний год разница не сильно уменьшилась. Сколько лет ждать заказчику?
3в. Конечно-конечно, все игроки на рынке всегда свято следовали стандартам.
От создателей фантастических боевиков «Виндекапец 1: Ярость GNU» и «Виндекапец 2: Восстание Ubuntu» драма «Никто не любит Flash». Смотрите на Хабрахабре последующие два года.
Спор Flash против HTML5 — это спор между реальностью и мечтой. Flash — это давно существующая платформа, на ней много чего уже сделали. У неё есть свои плюсы и минусы. А HTML5 только начинает свою жизнь. На любую критику у сторонников этой технологии есть универсальный ответ: «В будущих версиях браузеров всё исправят, всё что нужно внедрят!» Но вечно так отвечать нельзя. И вот через какое-то время всплывут проблемы в том числе и старые, о которых забыли из-за всеобщей эйфории:
1. Приспособленность к созданию больших приложений. Google, например, начав развитие Dash признал, что HTML5, CSS3, JavaScript для этого не приспособлены.
2. Производительность. Дело ведь в том, что векторная анимацию без графического ускорения и грамотной оптимизации неизбежно будет отжирать ресурсы. Из этого следуют следующие вещи:
а. Уже сейчас во Flash Player-е используются возможности видеокарт. Это сводит к нулю преимущества Canvas.
б. С внедрением HTML5 на нём начнут делать баннеры. При этом делать их будут всё те же «бедные студенты», а значит ни о какой оптимизации речи идти не будет. Эти баннеры будут тормозить не меньше флэшовых.
в. Из-за отсутствия инструментов для создания анимации для Canvas, делать её придётся программно. А это усложняет аппаратное ускорение. Flash тут опять выигрывает.
3. Зоопарк. Различия в браузерах никуда не исчезнут от перехода на HTML5.
а. В любом проекте есть ошибки. В разных проектах они могут быть разные. Значит в случае с HTML5 придётся делать костыли под каждый браузер.
б. На данный момент старые версии браузеров, которые не поддерживают HTML5 составляют где-то 40%. Как быстро они уйдут со сцены? Несколько лет они будут составлять существенную долю, а значит под них придётся делать приложения на Flash. Но тогда не понятно в чём преимущество HTML5, как универсальной платформы?
в. Дробление рынка. Сейчас крупные игроки стремятся сделать свою экосистему. Желательно, чтобы она была не совместима с экосистемой конкурента. Так почему бы не использовать для этого HTML5? Можно, например, сделать несколько иную реализацию нежели в стандарте, добавить новые возможности. Ведь наивно ожидать от компаний, которые ранее не смогли договориться о единой реализации предыдущих версий HTML, что они действительно резко озаботились проблемой кроссбраузерности. С Flash такое не получится — он является сторонней разработкой. У Adobe нет своей операционной системы, своего браузера и т.д., и он не создаёт свою экосистему. В этом смысле он нейтрален. Т.е. Flash является гигантской дырой в стене, которая отделяют любую экосистему от внешнего мира. Поэтому его так невзлюбили Microsoft и Apple.
По мере того, как эти проблемы будут всплывать, о победном шествии HTML5 и гибели Flash будут писать всё меньше и меньше. Но перед этим нас захлестнёт волна статей о светлом будущем с HTML5.
1. В JavaScript реализовано прототипное программирование, которое сильно отличается от классического Java-стиля.
2. В остальном полностью согласен. JavaScript прекрасно справляется с тем, для чего был создан — создание интерактивности на web-страницах. Зачем создавать из него универсальный комбайн, не понятно. Но если уж так хочется, то можно использовать давно существующие языки.
Google говорит, что JavaScript не достаточно мощный для разработки крупных приложений, им нужен язык со статической типизацией и т.д.
Что в этом плане может дать ActionScript:
1. Статическая типизация;
2. Нормальное ООП: соответствующий синтаксис, области видимости, зависимости, интерфейсы и т.д.;
3. Язык основан на EcmaScript, т.е. должен быть прост в изучении для людей с опытом работы на JavaScript;
4. У языка уже есть сообщество: Adobe и флэш-разработчики. Кроме того, уже есть открытый компилятор и среды для разработки (открытые в том числе). Плюс у Mozilla есть некоторый опыт внедрения;
5. Различные плюшки: стандарт E4X, кстати, реализованный Mozilla в SpiderMonkey, векторы и т.д.
Подобного рода оптимизация во флэше осуществляется компилятором на этапе транслирования исходников в байткод. Удаляются неиспользуемые связи, комментарии и т.д.
1. Ситуации бывают разные, иногда необходимо загрузить сразу всё, а потом уже загружать. Но опрос не в этом. Не понятно, как можно сравнивать flash-контейнер и отдельный файл. Есть flash-игрушка, а есть шапка сайта. Как их можно сравнивать по размеру? Это всё равно, что сравнивать мягкое с теплым и придти к выводу, что сладкое лучше.
2. Скомпилировал пустой swf. Размер 523 байта. Это и есть избыточность контейнера swf. Современные сайты подобной избыточности даже не заметят.
1. >>Это тоже хорошо для производительности, потому что отдельные файлы с Flash-контентом значительно больше по размеру (в среднем 58 КБ), чем отдельные файлы с любым другим видом контента.
Не понятно про файлы с Flash-контентом. В swf может быть вшито 10 картинок. Вполне логично, что вес 10 картинок больше веса одной картинки. Более того, в нём содержатся скрипты, которые управляют показом. Автор считает, что если вытащить картинки и скрипты из флэша, то суммарный размер будет меньше?
2. >>Кроме того, существует мало способов оптимизировать Flash.
Сослагательный наклонение прекрасно тем, что оно вообще ни к чему не обязывает. Можно обливать грязью технологию, которая позволила это всё сделать, рассказывая сказки в духе «если бы, да кабы».
Технология, которая позволяет создавать принципиально новый продукт, по определению грёбаной не является.
Т.е. передача наследникам дела, дома, машины, яхты, земли и счёта в банке, к которым они не имеют никакого отношения, — это не глупость, а передача права на произведения, которое позволит наследникам получать стабильный доход, почему-то глупость.
>> Есть большое количество записей, ныне уже не защищенных копирайтом, но через несколько лет закон опять исправят (вы ведь помните, сколько раз меняли закон о продлении срока копирайта?)
Существует куча открытых программ. Или, например, Википедия. Все попытки на них наехать заканчиваются ничем. Почему это вдруг купленная сообществом запись вдруг станет вне закона?
Пускай меняют срок копирайта хоть до бесконечности. Сообщество купило музыкальное произведение и в праве распоряжаться как захочет.
>> Теперь я могу переслать вам книгу (через P2P, к примеру), и затраты на это понесем только вы и я. Всё. Никаких посредников.
А книга из воздуха взялась? Никто её не писал, никто не корректировал, никто не делал дизайн книги, никто не делал иллюстраций и т.д.?
>> Для того, чтобы написать книгу, не нужны многомиллионные гонорары (про кино и игры умолчим ;), хотя там тоже встречаются созданные буквально на коленке шедевры).
А сколько должен получать автор? Автор может писать книгу несколько лет. Вправе ли автор получать каждый месяц по 100 тыс. рублей? В год это делает 1.200 тыс рублей. И это только автору. А ведь над книгой работают корректоры, иллюстраторы, дизайнеры, верстальщики. Они ведь тоже деньги хотят получить за свою работу. Так сколько стоит сделать хорошую книгу?
Все эти страдания вокруг копирайта яйца выеденного не стоят. Хотите бесплатную ОС пользуйтесь, например, каким-нибудь дистрибутивом Линукса или Юникса. Хотите бесплатный графический редактор — ГИМП. Музыка — куча сервисом для независимых музыкантов. Книги — идите в блоги или опять же на специализированные ресурсы. Но ведь большинству нужна именно Виндоус, Фотошоп и т.д. Потому что с ними удобней. А удобны они благодаря труду сотрудников Майкрософт и Адоб. Но платить за этот труд многие не хотят.
Точно так же и с музыкой, и с книгами, и с кино. Автору выше дали ссылку на искомое произведение, но в другом исполнении. Но автор нос воротит — исполнение слабое. Нужна именно запись ЭМИ. То, что именно ЭМИ купила эту запись, хранила её, отцифровала и т.д., автора не заботит. Автор статьи хочет именно эту запись и, конечно же, бесплатно.
Это вопрос и з той же серии, что зачем платить админу? Он же ведь просто действует по руководствам. Зачем платить дворнику? Он же ведь просто махает метлой? Зачем платить платить таксисту? Я и сам могу водить. И т.д., и т.п.
Люди делают отцифровку старых записей, платят отчисления авторам и т.д., и т.п. Естественно, что раз они тратят свои деньги и усилия, то он в праве требовать вознаграждения за свой труд.
Кстати, борцы с копирастами могут воплотить в жизнь свои идеи по поводу оплаты труда исполнителей. Что мешает объявить сбор денег для музыкантов, которые будут записывать классические произведения и выкладывать их в свободный доступ?
В Новосибирске ВОИС докопалась до местных загсов из-за марша Мендельсона. Так местный филармонический оркестр записал марш Мендельсона и передал запись загсу в безвозмездное пользование.
www.philharmonia-nsk.ru/press/filarmoniya-v-presse/novosibirskiy-simfon2
Зачем они совместили объявление об усилении разработки инструментов для HTML5 с сообщением о прекращении разработки мобильного флэш плеера? Если бы они разнесли бы эти сообщения по времени, разве что-нибудь изменилось бы?
Зачем впихивать в «Вопросы и Ответы» совет переходить на HTML5? Они что всерьёз думают, что флэш-разработчики ломанутся с ActionScript 3.0 на HTML5+JS?
Почему не стали давать внятных подробных ответов?
Ничего серьёзного для флэш плеера не произошло (даже для мобильных устройств, ибо 11-го флэш плеера хватит на несколько лет, а потом них можно будет спокойно запускать десктопную версию), но это было преподнесено так, что завтра Adobe прекращает разработку платформы. Это сравнимо с тем, как если бы в самолёте, который нормально летит, капитан начал рассказывать пассажирам про вероятность падения. Толку никакого, но паника была бы точно.
1. Agile требует накладных расходов. Например, 5-минутная встреча абсолютно бесполезна, если представляет собой чтение в слух с выражением задач из багтрекера. А любое обсуждение возникших трудностей превращает её в часовой разговор о делах наших скорбных. Всё это требует времени разработчика, за которое платит компания. В итоге это приводит к повышению стоимости разработки, что не есть хорошо, ведь мы заботимся о благе организации.
2. Предполагается, что в проекте идеальная ситуация: один проект, длительный срок, нет просроченных задач и т.д. А теперь представим реальную ситуацию, когда проектов несколько. Переключаться между ними тяжело, а значит обобщить все задачи будет трудно. Или, к примеру, прибегает менеджер с воплем «шеф, усё пропало». Недовольные клиенты штурмуют офис — взяли первый этаж и сбоями продвигаются к кухне. Как быть в этом случае?
3. Прозрачность кода — это хорошо. Но что если в проектной команде каждой твари по паре? Один верстальщик, один flash-разработчик, один js-разработчик, один специалист по базам данных и т.д. Кто и что будет проверять? Кто будет проводить код-ревью и т.д.?
Как организовать дозаправку жидким азотом? Он ведь испаряется.
2. Цена. Сверхпроводники — это очень дорого.
3. Безопасность. Если солнце припечёт, сосуды Дьюара с азотом взорвутся.
Если начнётся война, то с фантазиями на тему единых открытых стандартов (привет, HTML5) придётся попрощаться. Каждый браузер будет изголяться как может.
Просто у нас в стране из-за неадекватного перевода американский фильмов население не понимает, что в большинстве боевиков ему показывают не нормальных людей, а уголовников, низы общества, урок, гопников и откровенное быдло. Перенимать их язык и манеру общения всё равно, что «ботать по фене».
2. Разница в оптимизациях. Если есть нормальная IDE, то она сама их осуществит. В противном случае программист должен очень хорошо разбираться, как и что отрисовывается. На практике такими оптимизациями в ручную никто заниматься не будет.
2а. При том, что браузеры, которые отрисовывают Canvas, могут переложить расчёт анимации с процессора на видеокарту. Flash Player долгое время это делать не мог — расчёт анимации проводился на процессоре. Это было одним из доводов за отказ от Flash. Но с 10 версии он получил доступ к видеокарте, поэтому нагрузка на процессор значительно снизилась.
2б. При том, что один из доводов против Flash — это огромное количество баннеров, которые тормозят систему. Но если уберут Flash, то получат баннеры на HTML5.
3а. Фреймворк упрощает разработку, но увеличивает расход ресурсов: больше вес, больше нагрузка на процессор и т.д.
3б. Ну, что и требовалось доказать. На 20% пользователей с Flash больше, чем с Canvas. При этом, судя по всему, статистика не учитывает полноту реализации Canvas. Ну и слово «скоро» ничего не говорит о том, когда конкретно это произойдёт. Может завтра, а может через пять лет. Судя по графику за последний год разница не сильно уменьшилась. Сколько лет ждать заказчику?
3в. Конечно-конечно, все игроки на рынке всегда свято следовали стандартам.
Спор Flash против HTML5 — это спор между реальностью и мечтой. Flash — это давно существующая платформа, на ней много чего уже сделали. У неё есть свои плюсы и минусы. А HTML5 только начинает свою жизнь. На любую критику у сторонников этой технологии есть универсальный ответ: «В будущих версиях браузеров всё исправят, всё что нужно внедрят!» Но вечно так отвечать нельзя. И вот через какое-то время всплывут проблемы в том числе и старые, о которых забыли из-за всеобщей эйфории:
1. Приспособленность к созданию больших приложений. Google, например, начав развитие Dash признал, что HTML5, CSS3, JavaScript для этого не приспособлены.
2. Производительность. Дело ведь в том, что векторная анимацию без графического ускорения и грамотной оптимизации неизбежно будет отжирать ресурсы. Из этого следуют следующие вещи:
а. Уже сейчас во Flash Player-е используются возможности видеокарт. Это сводит к нулю преимущества Canvas.
б. С внедрением HTML5 на нём начнут делать баннеры. При этом делать их будут всё те же «бедные студенты», а значит ни о какой оптимизации речи идти не будет. Эти баннеры будут тормозить не меньше флэшовых.
в. Из-за отсутствия инструментов для создания анимации для Canvas, делать её придётся программно. А это усложняет аппаратное ускорение. Flash тут опять выигрывает.
3. Зоопарк. Различия в браузерах никуда не исчезнут от перехода на HTML5.
а. В любом проекте есть ошибки. В разных проектах они могут быть разные. Значит в случае с HTML5 придётся делать костыли под каждый браузер.
б. На данный момент старые версии браузеров, которые не поддерживают HTML5 составляют где-то 40%. Как быстро они уйдут со сцены? Несколько лет они будут составлять существенную долю, а значит под них придётся делать приложения на Flash. Но тогда не понятно в чём преимущество HTML5, как универсальной платформы?
в. Дробление рынка. Сейчас крупные игроки стремятся сделать свою экосистему. Желательно, чтобы она была не совместима с экосистемой конкурента. Так почему бы не использовать для этого HTML5? Можно, например, сделать несколько иную реализацию нежели в стандарте, добавить новые возможности. Ведь наивно ожидать от компаний, которые ранее не смогли договориться о единой реализации предыдущих версий HTML, что они действительно резко озаботились проблемой кроссбраузерности. С Flash такое не получится — он является сторонней разработкой. У Adobe нет своей операционной системы, своего браузера и т.д., и он не создаёт свою экосистему. В этом смысле он нейтрален. Т.е. Flash является гигантской дырой в стене, которая отделяют любую экосистему от внешнего мира. Поэтому его так невзлюбили Microsoft и Apple.
По мере того, как эти проблемы будут всплывать, о победном шествии HTML5 и гибели Flash будут писать всё меньше и меньше. Но перед этим нас захлестнёт волна статей о светлом будущем с HTML5.
2. В остальном полностью согласен. JavaScript прекрасно справляется с тем, для чего был создан — создание интерактивности на web-страницах. Зачем создавать из него универсальный комбайн, не понятно. Но если уж так хочется, то можно использовать давно существующие языки.
Что в этом плане может дать ActionScript:
1. Статическая типизация;
2. Нормальное ООП: соответствующий синтаксис, области видимости, зависимости, интерфейсы и т.д.;
3. Язык основан на EcmaScript, т.е. должен быть прост в изучении для людей с опытом работы на JavaScript;
4. У языка уже есть сообщество: Adobe и флэш-разработчики. Кроме того, уже есть открытый компилятор и среды для разработки (открытые в том числе). Плюс у Mozilla есть некоторый опыт внедрения;
5. Различные плюшки: стандарт E4X, кстати, реализованный Mozilla в SpiderMonkey, векторы и т.д.
Просто для справки. В своё время шли разговоры о том, чтобы сделать нативную поддержку ActionScript 3 в FireFox.
2. Скомпилировал пустой swf. Размер 523 байта. Это и есть избыточность контейнера swf. Современные сайты подобной избыточности даже не заметят.
Не понятно про файлы с Flash-контентом. В swf может быть вшито 10 картинок. Вполне логично, что вес 10 картинок больше веса одной картинки. Более того, в нём содержатся скрипты, которые управляют показом. Автор считает, что если вытащить картинки и скрипты из флэша, то суммарный размер будет меньше?
2. >>Кроме того, существует мало способов оптимизировать Flash.
Что значит оптимизировать флэш?
Технология, которая позволяет создавать принципиально новый продукт, по определению грёбаной не является.