推进AS3的发展?

7

你好,我经常使用AS3进行工作,但我的教育背景是Java/C/C++,我认为该语言相当受限。

在AS3的世界中似乎有两个基本阵营:

  • 非技术的创意派,他们希望能够轻松地让事情正常运作,而不需要过多的计算机科学知识
  • 技术派(可能来自于Java/C#等教育领域),他们对使用Flex感兴趣,并习惯于一些比较复杂的语言特性(泛型、方法/操作符重载)。

AS3似乎使这两个阵营都感到沮丧:

主要创意派认为AS3比AS2更费力(他们是正确的),并且当需要获得好处时,他们不明白为什么要转换,因为复杂性增加和学习曲线相对较陡峭。

主要技术派发现AS3存在一种介于Javascript和Java之间的状态,只实现了一半的概念。

我有自己的技术想法,但我认为目前最重要的问题不是在技术方面。因为Adobe为什么要将AS3变得更加技术化呢?它没有被其原始用户的大部分所接受。

那么我的问题是,Adobe和用户社区如何推动AS3向前发展,不仅在技术上,而且作为一个完整的工具,所有用户都会想要采用它呢?

我的一个想法是,AS3应该考虑如何再次成为更加脚本化的语言,但保留类型机制,可能通过类似于Scala中的类型推理实现。 同时,停止跟随Java,好像它是语言设计的顶峰,开始思考典型用户试图解决的问题。


你知道AS3是一个开放规范的完整实现,对吧?我不明白你是想暗示规范应该改变,还是Adobe应该采用不同的规范?(或者Adobe应该只是实现他们自己的规范扩展...呕!) - fenomas
AS3完全符合ECMA4的草案规范,而不是AS3发布后才发布的实际规范。我对它们超出ECMA规范没有太大问题,但这会产生影响,我不反对考虑它们。而“开放”是一个被滥用的术语。我想知道AS3将走向何方,为什么我找不到答案或不能做出贡献,而只能写一些愤怒的博客文章,这已经变得很普遍了。Adobe有自己的议程。他们在打“开放”的牌。我更希望“开放”意味着真正的社区参与,而不是仅仅可以查看源代码。 - BefittingTheorem
公平地说,ES4从未成为一个完整的规范。Adobe正在与Mozilla合作(他们贡献了Tamarin,这导致了TraceMonkey)开发JavaScript的新版本,但当工作组无法就方向达成一致时,Mozilla退出了。因此,在完成之前,ES4被关闭,并将资源转移到ES3.1/ES5(Harmony项目)。他们有一个部分符合规范的参考实现,但我不知道它会发生什么,或者是否会很快进入Flash Player中。 - James Fassett
确实并不是一件容易的事情。如果能听到Adobe关于该语言的总体计划,那将会很好。我认为让社区开发另一种专用于AVM的语言将会非常棒。我还没有尝试过Haxe,但它似乎太多样化了,无法真正取代AS3。 - BefittingTheorem
我一直认为AS是由设计师而不是真正的程序员开发的。原因在于结构。框架没有一致的建立,做相同事情的属性却没有相同的名称等。它经常看起来元素没有很好地开发,严格来说,工作方式相同以消耗学习曲线。时间轴的想法很好,但并不适合构建应用程序。奇怪的“从未见过”的语言构造,异步编程使得做简单的事情变得非常痛苦,你必须等待事件,这会使你的代码变得混乱。 - Codebeat
7个回答

5
我来自第二个阵营,非常喜欢编程...我使用Pascal、后来是Delphi和Java进行了很多编程,但后来我决定女孩和吉他更酷...当我在2006年发现FlashPlayer时,我被它所提供的可能性所吸引,开始使用AS2进行编码...Flash 8更像是一个意外,当涉及到编码时,所以我很快就转向了MTASC和FlashDevelop,并很好地了解了这种语言...从那时起,我与任何严肃使用FlashPlayer平台的人一样面临着同样的挑战...所以这是我的观点:

AS2 vs. AS3

好的,最重要的是:语言 != API …… AS3核心语言是大部分顶层内容,还包括来自flash.utils的以下内容:getDefinitionByNamedescribeType,以及ProxyDictionary和(可以说是)ByteArray(其他任何东西都要么与FlashPlayer接口,要么可以使用核心语言构建)……在AS2中,这几乎是所有JSON值的有效类型(BooleanNumberStringArrayObject),以及FunctionASSetPropFlags……AS3语言和FlashPlayer之间的联系很小……例如mod_actionscript就是尝试将Tamarin VM作为Apache模块使用,当然它有完全不同的API……

比较核心语言,有差异...最终,我会说AS2比AS3更强大...你实际上可以在运行时改变整个语言,它是原型导向的(这是比基于类的继承更强大的功能),允许混入,AOP等等...AS2具有非常清晰和激进的语言设计...很少有人真正理解...AS2遭受了与 JavaScript相同的误解(对我来说,这是AS2的未经分类和不兼容的兄弟)...大多数人喜欢它,因为它如此宽容...例如PHP,除了其广泛的市场渗透率和易安装性外,这是其流行的主要原因...但JS和AS是非常高级,富有表现力和强大的语言,而PHP更像是一个用来肮脏地拼凑一些东西的工具(这不是关于PHP的问题,我只需要另一个宽容的语言进行比较)...问题是,大多数人在AS2(和JS)中使用的是宽容性...我很少看到AS2中基于原型的,函数式的,面向方面的甚至是适当的面向对象编程的使用...>here<我列出了一组真正酷的AS2功能,这些功能要么被糟糕地使用,要么很少被使用...

AS3是Adobe朝着Java的方向迈出的一步...它非常严格,在运行时甚至是静态的,但表现得确实更好...而且它也很苛刻,强迫你变得非常冗长...describeType允许了一个全新的内省级别,Dictionary是一个不错的时间节省器,Proxy是AS2中Object::__resolve的超级变种,弥补了所有已经失去的灵活性...

说到这种语言,我认为AS3实际上是一步后退...在高级语言指数级增长的时代,当Sun决定创建JavaFX Script,许多其他动态语言可以在JVM和CLR上运行时,Adobe决定创建一个新的、更静态的AS2版本和一个适合执行它的虚拟机...有点自相矛盾吧...

在比较API时,AS2和AS3 FlashPlayer API都有优缺点...后者的确更大...当涉及到它们的交集(显示列表、网络、XML处理)时,每种解决方案都有利弊...许多人有点不满,因为所有好的旧回调都消失了,被新的事件模型所取代...但是,如果您使用适当的IDE,就没有区别...但后者更清洁,更强大(还记得一个鼠标输入回调如何完全关闭所有子项吗?)...此外,这并不重要,因为您可以在AS2中重新实现AS3事件模型,也可以在AS2中重新实现AS2回调系统,两者都可以在几天内完成...最终,我会说AS3具有相当更大和更强大的API,在需要的情况下,您可以将其包装起来,以使其更简洁...所以最终,我真的认为AS3 API更好...没有过度简化的必要...

每个人抱怨的点在于需要进行一个巨大的改变... 直到 AS2,语言一步步发展,几乎完全向下兼容之前的版本... 结果是你需要进行彻底的切换,而不是缓慢过渡... 换句话说:选择 AS3 就意味着扔掉任何东西,这让很多人感到厌恶,特别是设计师,因为迁移代码是可行的,但移植 .fla 真的很难,至少是老版本,其中代码分布在无数个影片剪辑中... 但真的并不比 AS2 更困难... 它增加了一些限制,但拥有更多功能,并且解决了许多问题,这些问题实际上在开始使用以前的 ActionScript 版本时每个人都经历过...

尼古拉斯·卡纳斯(Nicolas Cannasse)是Haxe的创造者,曾多次提到此事,他在自己的博客上发表了一些关于此事的想法......当然,他将Haxe作为替代品进行展示有些有偏见......但我认为这是自然的...... Haxe的一个重要观点实际上是成为AS3的替代品,尼古拉斯非常渴望并能够提供一种替代方案,虽然作为主要语言设计师,最终他有自己的想法,决定语言的发展方向......但让我谈谈Haxe作为一种替代品(这可能与尼古拉斯的文章部分重复,但我只是试图总结我的观点)

Haxe作为替代品

我还没有尝试过Haxe,但它似乎是一个全才,无法真正取代AS3。

这是错误的... Nicolas 所在的 Motion-Twin 公司经常使用 Flash ... 实际上,Haxe 生成的 AVM2 字节码比 AS3 更快,并且允许使用 alchemy 操作码,因此,最终,Haxe 允许您编写更高效的 AVM2 解决方案... 作为一种语言,它真的更加丰富... Nicolas 的帖子指出,与 AS3 不同,Haxe 是一种开源语言... 这在实践中意味着,您可以加入社区并提出功能请求,甚至学习 OCaml 并直接做出贡献... FlashDevelop 的主要作者之一 Philippe Elsass 最近也对 Haxe 做了一个不那么积极的总结... 但是给出了一个简要概述... 它还链接到 Nicolas 的一篇帖子,介绍了MTypes的最强语言特性,这是 MotionTwin 在发布和开源之前的内部工作名称...

Haxe比AS3更加表达性......它具有泛型、类型化的一等函数、带参数的枚举等特性,这些在MTypes功能列表中没有列出......using关键字提供了一些重载可能性,但我真的不明白为什么方法重载有意义......对于未来版本,计划多类型,提供类似的功能......操作符重载已经被讨论了很多次,很可能不会被实现,因为它使代码交换变得困难...最后,我认为Haxe是AVM2更好的语言......并且越来越好...一些社区成员在stackoverflow问题中提供了更多学习Haxe的原因......

AS3的未来

我认为AS3不会被过快地推进...Adobe有更好的事情要做...Adobe使用FlashPlayer作为部署Flex应用程序的平台...这些应用程序是用MXML编写的,毫无疑问是一种非常强大的声明性语言,可以转换成AS3...这就是为什么Adobe需要AS3和AVM2快速运行,但并不需要更具表现力...随着Thermo(又名Flash Catalyst)的出现,设计师将被排除在实际编码过程之外,所有东西都将转移到Flex上,使用所有的Flex服务器解决方案...
我不喜欢Flex,坚持使用AS3对我来说不是一个选择...Adobe正在将Flash平台向Java平台移动,我不欣赏这一点...我总是更喜欢Flash而不是Java,因为它是如此轻巧,而ActionScript则是如此高效...我对AS3的新功能非常兴奋,但最终我决定继续前进,因为在我看来,AS3的开发开始停滞不前...
最终,选择你的道路取决于你...现在是MXML(和一点AS3)或Haxe...或者尝试编写一些具有LLVM前端的语言,并使用alchemy将其编译到AVM2中...Objective-C可能是个好主意...
所以无论你选择什么...祝你好运...

附言:我认为当你想表达一种高级、表达力强和动态的语言时,不应该使用“脚本”这个术语……Bash脚本也是一种脚本语言,但它确实与Ruby、Scala或所有ECMA方言完全不同……


感谢back2dos,你的回答非常详细。我将在接下来的几个星期里研究Haxe,它看起来很有趣。我的"样样精通"评论的重点是,它似乎针对太多平台了。总体而言,Haxe的开发比AS3更活跃。我同意AS3处于动态和静态类型之间的奇怪状态,但我总体上认为,完整的AS3系统比AS2设计和实现得更好,但让我担心的是,语言正在向Java迈进。Java社区已经在不断地前进,而Adobe仍然试图成为十年前的Java。 - BefittingTheorem

2
我倾向于不同意,因为我很喜欢这种语言。我们需要认识到的一件事是,技术人员想要的一些功能是虚拟机功能,而不是语言功能(例如线程)。
现在,语言需要面向开发者友好,而不是艺术家友好。Flash已经从网站介绍、矢量卡通、广告横幅和简单游戏中走了很长一段路。在我的日常工作中,它通常被用来构建定制的内部应用程序。这些应用程序具有完全不同的约束条件,并需要AS3引入的语言特性(例如命名空间、强类型)。我曾经参与过由9个或更多开发人员组成的团队。JavaScript并不适合处理如此大规模的开发项目,这就是为什么Google使用GWT来使他们能够编写Java代码并将其编译为JavaScript的原因。

我当然对 ES4 的一些特性感到非常兴奋。例如泛型函数(基本上是方法重载)、参数化类型(基本上是泛型)、生成器(使用 yield)以及 lettypelikeunitwrap 关键字。我很失望它被淘汰,取而代之的是削弱版的 ES3.1/ES5 规范(我认为这更多是出于政治原因而非技术原因)。我希望 Adobe 有足够的远见来实现 AS4。


希望ES4规范能够被实现,我真的觉得AS3陷入了僵局,他们想让你使用强类型(我是支持的,但更喜欢类型推断),但由于各种因素,为了实现优雅的解决方案,你需要诉诸于无类型对象。此外,将函数作为对象,但即使是最简单的类型也能应用,这让我不想使用闭包作为设计模式。 - BefittingTheorem
我不认为AS4会变成Haskell,所以它将在语言高级程度上有一定的限制。但是,如果他们实现了我链接到的ES4白皮书中80%的功能,那么它会成为一种令人敬畏的语言。(内置尾调用优化! 数组推导!我可以继续列举……) - James Fassett
是的,如果能够看到这些功能,那真的会很不错,但我想在Adobe的议程中它可能不是首要任务,考虑到他们在这方面缺乏沟通,很难预测。 - BefittingTheorem

2

也许你应该看一下Haxe

它的目标是FlashPlayer(和其他一些平台),并提供一个比AS3更先进的语言。由于它是开源的,所以在语言和编译器方面肯定有更多的发展。


我目前正在了解Haxe,它确实看起来是一种更高级的编程语言。我必须查看我的工作流程如何变化,并且可以使用哪些工具。FlexBulider已经过时,所以看来TextMate是更好的选择。我们还遇到了使用ANT时mxmlc无法正常工作的问题,因此我很想知道Haxe是否能够与之良好协作,因为我们使用Hudson作为持续构建系统。 - BefittingTheorem

2
所有这些答案的总结如下:
关于Adobe的AS3未来计划,几乎没有任何信息。人们可能认为他们会遵循ECMA规范,但目前该规范本身也处于政治动荡之中,所以我猜Adobe正在等待看看结果如何。
至于语言是否变得更简单易懂,以便于兼职/工具型程序员理解,似乎不太可能发生,因为Flex的目标是吸引Java程序员,因此可以预见AS将继续致力于让Java程序员感到舒适。
通过使用Thermo/Flash Catalyst完全将设计师与代码分离,似乎是Flash开发团队中程序员/设计师关系最有可能的未来方向。
Haxe团队正在尽其所能使与Flash Player的工作更具表现力和更少限制。但据我所知,他们并没有得到Adobe的支持。因此,Adobe似乎并不想看到Flash Player开发者有更多的语言选择。
如果Silverlight能够接近Flash Player插件的市场覆盖面,那么它可能会对Adobe造成相当大的威胁,并迫使其使AS成为更具表现力/专业化的语言。因为Silverlight应用可以在强大的专业化IDE Visual Studio中开发(而不是基本的Flex Builder插件)。并且C#是首选语言,这使得AS3在许多方面看起来相当受限。
总之,Adobe对AS3的未来保持着沉默,并且有关该语言发展的进程都在闭门造车。因此,最终只有Adobe能真正回答“AS3将何去何从”的问题。

1

我认为ActionScript会向C#发展。我这么认为是因为我相信我们会看到更多完全使用Flash/Silverlight制作的大型网站。一旦你有一个真正的团队,由图形艺术家和编码人员共同工作,C#将节省大量资金。在C#中开发和调试更复杂的应用程序有更好的工具和可能性。

你可以通过新的Flash Catalyst / Flash Builder Premium设置看到这一点,其中图形和代码最终被适当地分离,同时仍然允许艺术家“做他们的事情”。

我相信Adobe也会尝试保持设计师的用户群体,让他们拥有一些脚本知识。但是,如果他们愿意,他们仍然可以编写AS2。这可能是他们(据我所知)要保留Flash Professional IDE的原因,而且比Catalyst具有稍微更高级的图形工具。

因此,当AS4出现时,我期望看到像泛型和方法重载之类的东西。但它可能永远不会成为C#。

你可能猜到了,我是技术阵营的一员 ;) 但是作为专业人士,我无法看到同样的人设计和编码的未来。因此,我认为Adobe不应考虑“创意”阵营对ActionScript的意见。你也不会问一个编码人员如何选择颜色;)


希望我们不会看到更多完全使用Flash或Silverlight创建的网站,因为我更喜欢具有定义结构的开放标准。我不希望AS3向C#靠拢,因为那是一个巨大的标准。我喜欢脚本语言的感觉,它们的语法简洁明了。我对AS3的问题是,它正趋向于C#/Java的冗长,但没有相应的功能。对我来说,AS3的优势在于可以快速建立简单的图形应用程序。我基本上想要更多快速、简单和安全的功能,而不是一个试图成为企业平台的脚本语言。 - BefittingTheorem

0
不确定是否能影响Adobe(尽管你可以试试亲爱的Adobe!),但用户社区正在开发一些很好的框架,比如PureMVC。它在某种程度上使AS3更加技术化,并将视觉与逻辑分离,以便设计师可以享受更加“创造性”的体验。

嘿,Ollie,感谢你的评论。我用过PureMVC,说实话并不 impressed。看起来设计者只是为了使用设计模式而使用了一些设计模式。但是为了保持主题,AS3真的没有考虑通过库进行扩展的设计。存在许多编写良好库的现有障碍,例如缺乏泛型和高级OOP功能。随着我变得更有经验,我认为框架是一种腐败因素(在积极方面,它们可以使团队使用共同概念进行通信),而良好的简单OOP设计可以走得很远。 - BefittingTheorem
PureMVC让我印象深刻的是,他们编写了自己的事件框架,而不是使用内置的Flash框架(为了与其他语言中的框架实现进行互操作)。此外,所有主要类的单例模式使得作弊变得太容易了。在一个大型项目中,我们发现了核心功能的漏洞(大约一年前),尽管值得称赞的是,他们很快就修复了这些问题。 - James Fassett
啊,是的,PureMVC 曾经是我喜欢抱怨的话题之一 :) 我们在三个项目中使用了它,一开始由于定义了术语、模型、视图、命令、中介器等,使得团队间的沟通更好。但从长远来看,由于框架引入了大量无意义的冗余代码,理解代码变得更加困难,而且那些荒谬的单例模式几乎让测试变得不可能。我们放弃了 PureMVC,现在使用普通的简单对象和清晰的设计决策,现在代码更加干净、可读性更高,而且可测试性也大大提高了。 - BefittingTheorem

0

我来自第二个阵营,但是我并不沮丧——事实上,我对这门语言的现状感到非常满意。如果有什么让我沮丧的,那就是 Flash 和 AIR 运行时所施加的限制,以及 Flex 和 AIR API 的大小,而不是 ActionScript 语言本身。

当然,有时候我会因为一些“缺失”的东西感到恼火——用户可见的线程支持和方法重载、抽象类、真正的枚举等等都很棒——但总的来说,作为一门语言,我发现 ActionScript 是我用过的最灵活的语言。我确实喜欢我的 C# 和 Java,但相比之下,它们更加死板。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接