For those of you who don’t know, haXe is an ECMAScript-based programming language with awesome features. Its compiler is fast; it targets Flash, JavaScript, PHP, nekoVM (a speedy virtual machine like Flash or Java that is extensible) and native platforms. You can even write functions in it that change the way your haXe code is compiled.

Understandably, people who are new to haXe spend a lot of time using it the way they’d use the languages they’re used to. The haXe 2 Beginner’s Guide covers all the usual things people are familiar with, but then it guides the reader steadily through the trickier concepts. Good thing too, because that’s where the fun is.

haXe code needs to be understood on several levels- the way it compiles and the way it behaves when it is run on each target. That’s a lot of ground to cover, and this book does a good job at it. It reads like a college textbook, though, which is good and bad. A professor who wanted to could teach a basic programming course with haXe and this book, but that’s because basic programming courses tend to cover mundane things like reading and writing to files. They cover client targets like Flash and JS, but only enough to put info onscreen that verifies a connection to the server.

And that’s really what this book is about, after the basic haXe syntax stuff is covered- server stuff. That SPOD thing with relational databases, the haXe templating API (which might have changed a little since the book’s publication; it can be tough to publish guides for an evolving language) and file stream exercises all seem to point to an unspoken expectation that the reader can figure out the presentation layer things themselves. In my opinion, working in the presentation layer is the most difficult challenge in haXe, and apart from the promising NME project, there’s no clear, common solution. haXe has no common graphics API, while it does have a common API for all the things that this book covers, so it’s really no fault of the author. Maybe another part of the reason for omitting graphics stuff is because that subject could fill a whole other book. It would be exciting to see a follow-up publication regarding haXe as a language for developing games and other rich clients for multiple targets.

The book comes with lots of homework, which I did not do, but might eventually. I have more fun integrating lessons into my own projects than completing assignments, but if I decide to take up SPOD, for instance, I’d go with this book.

Overall, this beginner’s guide is a useful resource even for people who think they know haXe inside and out. It’s the best book on haXe I’ve ever read… It’s also the only book on haXe I’ve ever read– there’s not a lot of haXe literature printed nowadays, which makes it just as important to have this book on your shelf. (Or e-shelf.)

haXe 2 Beginner’s Guide – Benjamin Dasnois

Since July of last year, I picked up Flex, haXe, a bit of JavaScript, and a new project called Scourge.

And an apartment in Brooklyn. And a short-lived relationship.

And a new job in a new town. I’ve been a bit busy. There’s been no time to post things so that the two or three people who visit this site with any regularity can have something to return to. However, I do intend to post more frequently again. Here goes!

If you read that last post, you know about Tyro. Since I designed Tyro to be able to handle clipboard events, I expected it to respond to my cut, copy and paste keystrokes when I put it in an AIR application. It didn’t work. Can you think of why?

If you guessed it had something to do with menus, you’re correct. You seem pretty clever; maybe you want to follow along and try this project at home? Clipboard commands are usually provided through the Edit menu of an application, such as a web browser. Most people have learned through experience to rely upon the common keyboard shortcuts that software developers commonly bind to the clipboard commands, but know this: if your browser’s developer didn’t think to include that overlooked Edit menu, all your absent-minded key tapping would do nothing.

The first issue, then, is to include an Edit menu in your AIR application, and to fill it with NativeMenuItems that represent the standard Cut, Copy and Paste operations. I’ll wait while you do that. Don’t forget those keyboard shortcuts! (You might also want to stick in the Select All command, but remember, it doesn’t fit in the same category as the clipboard commands, so you should insert a separator to keep it apart from the other menu items.)

Now, what’s next? Remember, our goal here is to reproduce the chain of events that cause clipboard events to work in the Flash Player. We’ll want to dispatch events that use the Event.CUT, Event.COPY, Event.PASTE and Event.SELECT_ALL types. And we’ll want to dispatch them from the current stage focus. You might listen for Event.SELECT typed events from your Edit menu items, and respond in a fashion similar to this:

var clipboardEventType:String;
switch (event.currentTarget) {
case myCutMenuItem: clipboardEventType = Event.CUT; break;
case myCopyMenuItem: clipboardEventType = Event.COPY; break;
case myPasteMenuItem: clipboardEventType = Event.PASTE; break;
case mySelectAllMenuItem: clipboardEventType = Event.SELECT_ALL; break;
}
if (stage.focus && clipboardEventType) stage.focus.dispatchEvent(new Event(clipboardEventType));


That ought to do the trick! If you want to be thorough, you can listen for FocusEvent.FOCUS_IN events on the Stage to determine whether there currently is a clipboard-friendly object in focus, and what kind of object it is; that way, if it’s not something you wish to use with the clipboard, you can disable the Edit menu. This whole method should work for any InteractiveObject that has been carefully written to receive stage focus and handle clipboard events.

Wait, what’s that you say? You say you aren’t using the Tyro class as your text system? You’re using TextFields, the way they taught you in school? And they aren’t responding to your events, even when they have focus?

Well then it sucks to be you, doesn’t it? Don’t sweat it, I’m sure you can work out the copy and paste routines yourself. Have fun!

No, wait. I mean 2007, not 2008. You know, when Adobe showed us a sneak peek of Flash Player 10, and Peter Elst’s posted video coverage gave his blog a bazillion hits as Flashmongers everywhere watched Emmy Huang spin a MovieClip in 3D. “Whoop dee doo”, you might say with hindsight-equipped eyes. It’s 2010 and all those new tricks are now old hat, right?

Not exactly. While the novelty of 2.5D and IK handles may have faded away, one of Flash Player 10′s new features– the advanced text engine– has lagged behind the rest. That’s because the text engine is very low-level, and wasn’t exposed to designers in the Flash Professional authoring environment. Until CS5 was released this past April, only developers had access to the FTE. That’s kind of ridiculous, and Adobe knew that. And so began the efforts (by many different people) to bring TextField-like usability and new text functionality to the Flash platform.

Since the release of Flash Player 10, a team at Adobe has been hard at work to create a higher level framework for using the new text features. It’s called the Text Layout Framework; in Flash CS5, it’s the “TLF Text” option in the Properties panel. The TLF exposes all those neat new tricks to designers, but ironically it’s almost entirely inaccessible to developers, which almost defeats the purpose. Plus it’s riddled with memory issues and quirks; if you want to read more angst directed at the TLF, read Grant Skinner’s recent article and the comments that follow it. The TLF team has released the code to the framework as they work toward their 2.0 release, but still, there’s some demand for text systems that out-TLF the TLF.

…Er, well not entirely. The TLF tries to cover a lot of bases; most projects don’t need all that functionality, so they’d benefit from smaller text layout systems that have lesser overhead than the TLF. That might sound like a tall order to give to an ActionScript 3 developer, but that’s only because historically, we weren’t able to directly manipulate text this way. It’s outside of our comfort zone, but ActionScript developers have produced more complicated libraries in the past. So while gearing up the Wireworld player for an Android port, I decided to redesign the view, and while doing that I decided to utilize the new text engine. I wasn’t looking for any bells or whistles, just the ability to select and possibly edit text within a single-line field. So I started implementing Tyro.

Tyro’s not exactly finished yet– it hasn’t been commented, for instance– but if you want it, go ahead and use it. It doesn’t try to be everything, but it does have some pretty complicated selecting behaviors that roughly match the behavior of rich text on OS X. It feels natural when you use it. It supports cut, copy and paste, and most of the other features available in the TextField. It just also happens to benefit from some of the new text features. And just as long as you don’t expect bidirectionality, HTML+CSS or muliple lines, it’s a hell of a lot simpler than the TLF.

A huge resource I benefitted from while I built Tyro was a guy in a chair named Paul Taylor. He’s working on a project called TinyTLF, and unlike Tyro, it does intend to do most of the things the TLF does, only with a better architecture and a smaller footprint.

In most other cases, if someone tried to implement something that Adobe already went out of their way to implement themselves, you might think they’d be wasting their time. But even if we set aside the recent complaints that the TLF isn’t up to snuff, I feel that high-level text functionality is simply not the sort of thing you can effectively implement once. Not when its general use case includes support for every language, on any Flash-supported device. Not when it’s responsible for rendering that visual information that millions of designers slave over for hours on end, nudging each character this way and that. Text composition is a real beast. So shouldering the burden of rendering text for a project that you care about doesn’t seem very unreasonable to me.

Besides, the more text layout systems there are in the wild, the better. They’ll increase developers’ general understanding of text, just like the Great Tween Engine Craze increased our understanding of programmatic motion. We’re all more competent programmers as a result.

So if you need Tyro, pick it up and use it, it’s yours. If you need it to support Hebrew, don’t hesitate to get your hands dirty; the Flash text engine’s API is fully documented. Just be sure to show me טירון once you’re done with it.

Many of Steve’s criticisms are legitimate, but most of them have a valid counterargument that should be presented before the Grubers and Pogues of the world do their dance of exaltation.

Update: Apparently Steve’s triggered an impromptu Flash apologist essay writing contest. Here’s one of the more extensive responses.

Flash is “free” and “open”, just not Free and Open Source Software

The Flash platform is more than one technology. It consists of several systems, some of which Adobe licenses from other companies. Most of the code governing the parts of the player that are not licensed in this way was made available in Project Tamarin, the second largest code contribution ever made to the Mozilla Foundation. Understandably, Adobe cannot release all their player’s source code, because they do not have the right to do so.

Does this really hurt anyone? If the Flash platform’s proprietary technology hindered anyone, there’s hardly any indication of it. The player’s ubiquitous– it’s on every general purpose computer, and it was on a billion mobile devices before the iPhone made its debut. Flash content can be made for free by anyone on any Mac or PC. Flash may be proprietary, but it definitely isn’t restrictive.

A restrictive technology would be something like Cocoa Touch. Correct me if I’m wrong, but here’s the list of things you need to do to make a program available for an iPhone user:

• Buy an iPhone. Obviously.
• Pay Apple $99 per year for the right to develop for their platform.
• Sign an agreement limiting what you can say and do on iPhones
• Learn Objective-C. This step is a bit like chewing on sand.
• Learn Cocoa Touch. (Not Cocoa, as jwz pointed out. These are separate frameworks.)
• Design, and develop and test your app, obviously.
• Submit it to Apple for their approval. They can reject your app for all sorts of reasons, and the approval process can take months regardless of the outcome. Furthermore, they can put a hold on your app’s approval until you agree to make a change, such as dropping any mention of competitors’ platforms.
• Now your app is available to everyone. No, not just that one guy, not just your friends. To release your app on the iPhone App Store, you need to be comfortable giving it to everyone.
• …Though Apple might not be comfortable with your app, and may take it down at any time.

That’s ridiculous, and that’s the status quo on the iPhone. It’s the Walmartization of the application development process. And of course it works for Apple, because just as everyone wants their products available at Walmart, developers are clambering to put their software on these unique devices.

Flash developers don’t clamber. The Flash Platform does not support clambering. So while it may be proprietary, it’s nothing to be concerned about in this context.

But according to Steve (and many, many others), there is a free and open source alternative to Flash that is not hindered the way iPhone development is. We call it HTML5, but really, let’s just call it the fifth major version of

HTML

HTML’s great. But people who think it can currently replace Flash are fooling themselves.

When HTML innovates, it does it slowly and carefully. This is the backbone technology of the web, and it has got to work. Any change must be very carefully considered before it’s committed to the spec.

What happens when HTML cannot be used to express something, as was the case in 1996 when Flash made its debut? Then and now, the solution is to write a plugin that can support your expression. Plugins can provide experiences not supported by the browser, and can be easily disabled or removed. They fill the cracks in the web.

Flash used to be this way. But very early on, Flash gained ubiquity via dealings with Netscape and Microsoft, and it was updated faster than web technologies were. Before people were even contemplating HTML5, there was no question that Flash was an essential part of the web, because it provided experiences that couldn’t be replicated with HTML.

HTML5 is a major improvement of the spec, but it is nowhere near perfect. It will take years for browser implementations to reach a consensus on how the stuff is rendered. In the meantime, Flash renders the same way on every computer and will continue to fill in whatever gaps there are in the web. That is its niche.

There is no adequate HTML5 tooling. Steve himself implies this, when he encourages Adobe to provide those tools. In all likelihood, Adobe’s HTML5 tooling will be Flash Professional, which already has a timeline paradigm and the ability to work with Photoshop, Illustrator and InDesign. (And possibly Soundbooth?)

Most of the HTML5 examples we see online aren’t impressive until you hear that they are implemented in HTML5. That’s a bad sign. People are impressed that web tech is catching up with Flash, not because it’s doing anything particularly new. Flash developers see tons of these examples, and let me tell you, we’re not at all wowed.

HTML5 is a subset of HTML. Flash developers will use it, because we already use HTML. But it’s important to recognize it for what it is: the latest version of HTML, a slowly updated technology that appears different in different browsers. Don’t compare that to Flash. More importantly, maintain perspective: like any other technology, use its various features in the specific cases where those features make sense.

All the trimmings
In rapid fire, here are some of the other things Jobs said that are disagreeable or downright wrong:

• H.264 is a battery-friendly alternative to Flash video. Most Flash video is in H.264 format. The reason why H.264 even took off was because Flash supported it; otherwise it would have ended up like the other codecs. As long as plugins are given access to Apple’s H.264 hardware, Flash video won’t drain your battery any more or any less than a Cocoa Touch app. We’re all damn lucky that Flash supports H.264, otherwise there’d be no fallback implementation for the HTML5 video tag.
• Flash has poor reliability, security and performance. This more directly applies to Flash content. Since any dolt can make Flash content, there’s a wide variation to the quality of what’s out there. On the iPhone, none of this matters; for better or for worse, the application approval process should weed out bad apps. On more open platforms, bad Flash content is usually in the form of ads, and it can be ignored or turned off; at its worst, it’s a nuisance. But consider what would happen if the same content were to be created in HTML. Suddenly the browser makers would be responsible (as they always are) for “properly” rendering bad web markup. HTML5 has no advertisement tag. We’re in for a nasty shock when HTML ads hit the scene. Also, Steve, quoting Symantec about Flash is like quoting Hugo Chavez about the United States.
• Flash content was designed for PCs, not for touch devices. Three years ago, basically all content was designed for mouse interaction and not touch. Making the transition is not a chore, and it’s something everyone has to do when they target touch devices. This is a terrible excuse to philander Flash. Frankly, I think Jobs already knows the flaw in that argument. Why he’s making it anyway is a mystery to me.
• Flash is an abstraction layer of the iPhone SDK I agree that Flash’s purpose on a mobile device is different from its aforementioned filling-the-cracks role on the web. Flash isn’t doing anything special on mobile devices. What it is doing is providing support for an existing code base. If I have an app that runs on ten devices and I add a feature to it, it doesn’t always make sense to have to implement that feature ten times, once for each device. Similarities in those devices should be exploitable; I should be able to target multiple devices when I make an update to my code base. As it currently stands, every app on the iPhone is a separate product from any other offering their developer provides. I think that promotes feature lag, where the app with fewer users will lag behind in updates. The major strength of Flash is its consistent experience, and I think it has a lot to bring to the mobile arena.

I left some stuff out, but frankly, I’m beat. But I have one more point to make. Before Jobs posted his essay, everyone already knew his stance. They knew his reasons, some of which are still left out of his post. That it took this long for him to open up about Flash indicates that he’s not ready or looking forward to a counterargument. He doesn’t want this to be a discussion; he’s made his decision, and won’t change his mind. Posting his opinion can only do two things– it can change Apple’s carefully designed public image, and it can demonstrate how Apple has moved away from its idealistic roots. This company is no longer the beacon of light it used to be, and every statement it makes reinforces that.

Most people forget that Flash can do native 3D, and when they see it in use usually they think it’s “innovative”. Frankly it’s not; Flash has had a 3D API since late 2008, but there are reasons why most people don’t see much of it:

• Most designers and developers aren’t taught much about 3D transformations, or even 3D aesthetics.
• The tools Adobe’s released to design 3D Flash content are in their first lifecycle, and are only in one product (Flash CS4), which has a ton of other new features too, competing for user’s attention.
• There are plenty of classic techniques for producing 3D media that does not require Flash’s 3D API
• Perspective projection of objects means that a 3D object has to be redrawn each time it is moved in 2D space, unlike a 2D object

And the sneaky one which I’ll be talking about,

• Flash’s beautiful vector graphics may become fuzzy or pixelated when you transform them in 3D.

Thus a skilled and determined designer-developer team who find themselves in the right scenario could end up producing 3D Flash content. But if they ignore the last issue, their output might have a lower visual quality than what they’d like. Let’s look at why that is.

Along with the 3D API, Flash Player 10 introduced some enhancements and additions to its 2D API, most notably the Graphics.drawTriangles() method. This function accepts a series of triangles to draw in 2D, along with an optional series of texture coordinates for mapping an image onto those triangles. Whatever low-level code underlies the drawTriangles() function, it is also responsible for drawing 3D objects in the display list; when you transform a 2D DisplayObject in 3D, its bounding box’s corners are transformed in space, projected onto the screen and passed to the triangle drawing system. Those points are joined into two 2D triangles drawn onscreen.

Next comes the texture. The original 2D object is drawn to a bitmap the size of its bounding box, and the texture coordinates given to the triangle drawing system are the four corners of the bitmap. This rasterization– drawing your graphics to a bitmap the size of its local bounds– is where your graphic quality is capped; like any other bitmap, your graphics’ resolution is limited by the number of pixels in the texture, and if that texture is drawn to triangles with greater area, the resulting image will be blurry or pixelated.

If you’re only transforming one object in 3d, there is a simple solution, which I call the CrisperDrawer. It’s a subclass of Sprite with “child” and “resolution” properties. It only takes one child display object; when you assign it a resolution, it scales the child up by that amount in the X and Y dimensions, and scales itself down the same amount as well. You then transform the CripserDrawer in 3D.

The reason why this works is, by scaling up the 2D object, it is drawn to a larger bitmap than it normally would be. That bitmap is then used to texture the same projected triangles as before, because they will be derived from the bounding box of the CrisperDrawer, which is the same as the original bounding box. Usually you won’t need a resolution much higher than 3, but if your resolution is too high Flash won’t be able to represent the 2D graphic as a bitmap. You can also use the CrisperDrawer to lower the resolution of your graphics, if that’s your cuppa joe.

There are two limitations to the CrisperDrawer system. First, it only works on one 2D graphic; the DisplayObject you passed into it. That means for each 2D graphic with resolution issues in your application, you will need to work with a separate CrisperDrawer. You may write some handy recursive functions for making CrisperDrawers from existing 3D display lists, but that’s something you would typically wish to program on a per-project basis.

The other limitation is that bitmap filters you use in your 2D graphics will need to be tweaked when you use a CrisperDrawer. Adjusting the scaleX and scaleY of a 2D object that has filters applied to it will not affect the filter’s properties; for instance, a circle with a 10-pixel horizontal blur will look less blurry when you double its size. You will want to change the filter’s horizontal blur to 20 pixels, in that case. But as long as your 2D graphic stays in the CrisperDrawer and you don’t adjust its resolution, you’ll only need to modify your filters once.

Here’s a link to that CrisperDrawer class. Look it over, and if you use it, fantastic.

It turns out that mxmlc, the Flash compiler, employs several “font managers” for taking embedded font files and “transcoding” them into Flash fonts. The primary manager relies on a Java library called Batik to convert the letterforms of the font file into Flash-friendly curves. I’m not sure why this was the case, but Batik was flummoxed by some of the faces in M+, specifically with the capital ‘O’ letterform.

I mean, you could trace a big O by hand if you wanted to. It’s cake. I can’t imagine why M+’s ‘O’ is so difficult to process, but if it can happen with this font, it could happen to any font.

I only managed to get good shaped text with one font manager- the one that also handles transcoding OpenType fonts and such, which uses the new Compact Font Format (CFF) system in Flash 10. (To learn more about this subject, here’s a post about the new CFF embedding system.)

It might seem subtle, but when you compare the text side by side, I think you’ll agree that all this CFF stuff I had to do was worth it. Below is the same SWF, one with M+ text imported with Batik, the other with CFF.

batik_test_font_bad.swf

batik_test_font_good.swf

In the same project, I’m using SVGs whenever I can to represent artwork. Again, this is because I want to support as many other developers’ workflows as I can. It doesn’t make sense to stick art in a FLA if you’re going to open the source to a project.

Anyway, embedding SVG files with an [Embed] tag is pretty straightforward– the only parameter you need to give is the file path to your SVG document. Unfortunately, Flash’s SVG transcoder apparently doesn’t handle things like the cap style on strokes. Again, it’s just my personal preference, but that’s kind of a deal breaker for me. A quick Google search pointed me to as3svgrendererlib, whose title is self-explanatory if you put spaces in the right spots. In a nutshell, it’s a runtime SVG interpreter, which is excellent; I can not only avoid the faulty SVG transcoder in the compiler, but I could potentially script the interpreter do handle SVGs however I want. But the [Embed] syntax still made sense for throwing the SVGs into my SWF as plain text. Doing that doesn’t take much – just remember to set its mimeType to “application/octet-stream”, and it’ll become a ByteArrayAsset:

[Embed(source="./vector_shape.svg", mimeType="application/octet-stream")]
const VectorShape:Class;
var VectorShapeSVG:XML = XML((new VectorShape).toString());

Like before, here are the bad and good SWFs side-by-side:

batik_test_svg_bad.swf

batik_test_svg_good.swf

batik_test_svg_better.swf (after editing the SVG parser to not use pixel hinting)

At this point I developed suspicion. Here are two situations where vector data is being transcoded, and where the results are suboptimal. Batik is not just a Java library for font management; it’s a full-blown SVG toolkit. Might it be used by mxmlc to transcode SVGs as well as simple font files?

There’s one easy way to find out. Batik resides within the “lib” directory in the Flex SDK. It’s easy to drop it to temporarily into another directory. I did this and recompiled all four SWFs you see here, and the two SWFs whose transcoders produced bad vector graphics both failed, verbosely. Both of them relied on Batik.

So! While something may be wrong with Batik, it is much more likely that the Batik toolkit is not being properly used in the Flex SDK. It may be possible to manually replace the Batik toolkit in the SDK with a newer version, but I would not recommend it, as I’ve demonstrated that there are easy ways to circumvent the problem. Embed your fonts as CFF, parse your SVG files at runtime and you’ll be in vector heaven.

update: I think I should point out that the default cap style for SVG is flat, while the default cap style for Flash is round. If you explicitly state in your SVG file what the cap style is for your lines, the built-in SVG system is probably fine. However, apps that export to SVG can’t be expected to handle every discrepancy between Flash’s default graphics configuration and the SVG spec’s, so you’ll be adding cap style properties to your SVG markup by hand. Personally, I’d go with the as3 SVG lib.

In October ’09 I started taking my site’s design and navigation more seriously, in the hopes of making it a more successful site and increasing my motivation to write posts.

Before then, rezmason.net pointed to my portfolio site. My blog was accessible only by entering its URL; there was no link to it, because it was ugly and off-brand, and wasn’t updated frequently.

By throwing everything into WordPress pages and making a custom theme, I can now direct visitors straight to the blog. My portfolio was redesigned to fit in with the rest of the site, though it can still stand on its own.

I’m now much happier with the way things are. I think October was a turning point.

A lot of programmers new to AS3 reach a point, as I did, when they get very jumpy about their projects’ memory usage. It’s kind of a rite of passage, and during mine, I discovered that a set of animated buttons I incorporated into a GUI were spewing out gobs of display list garbage. (Display list garbage consists of DisplayObject instances, whose references to parents and children make them difficult for the garbage collector to quickly eliminate, kind of like digesting cellulose. For more on garbage collection, I’d suggest you conduct a hexosearch.)

Imagine your Flash animator friend makes you a MovieClip that represents a flashing bulb. She has probably made it go on and off by having a blank keyframe (lightbulb off) and a filled keyframe (lightbulb on) in a top layer in the Flash timeline, with the lightbulb outline in a bottom layer. Because the timeline is short, it will loop frequently, causing the bulb to flicker.

Now, let’s consider what happens in the Flash Player with this MovieClip. When the lightbulb goes on, a display object is instantiated and added to the display list. When the bulb goes off, that display object is removed from the display list and discarded. The lightbulb outline in the background stays put. This is the procedure specified by the Flash timeline that the MovieClip follows each time it loops– and it loops very frequently. The result is a small animation that has produced a heaping pile of display list garbage.

One might think of this and say, “Well, why can’t the MovieClip timeline cache these display list objects? It could clearly benefit from reusing them.” Caching does seem like a good idea, but only for short, looping animations. If every animation on Newgrounds cached the display objects created on the timeline, you’d end up with a ton of cached display objects that do not need to be reused, because the animation doesn’t loop. The timeline has no way to determine by itself whether it should cache its animated contents or not.

But as authors, we know when a timeline should cache its contents. My feature request calls for a Boolean property on the MovieClip class (similar to cacheAsBitmap on DisplayObject) that allows developers and animators to explicitly set the behavior of MovieClip timelines for the purpose of conserving memory. If you agree that it matters, why don’t you vote for it.

Too bad that the people implementing our standards are Apple, Mozilla, Nokia and Microsoft. Inevitably these companies would start making power plays, but I didn’t expect any type of fallout this early in HTML5′s life cycle.

I don’t know much about standards or software politics– I write apps for a proprietary platform that just about everybody has– but I feel that whatever “takes out” Flash, as some people have been hoping HTML5 would, will not come from this peanut gallery of power-hungry industry giants. After all, <video> and <audio> are only two of several new “rich web” features of HTML5. Can we count on these bozos to agree on the <canvas> tag? HTML5 won’t compete with Flash if there is any discrepancy there. And what about local data storage for web apps? I doubt Nokia and Opera will agree on one implementation for that.

This bickering is only temporary, I’m sure. Markets swing, giants shift their weight and standards get worked out. But in the meantime, Flash implements all of these features in the same way across all browsers today (mostly) with very little competition, and is already delivering even richer web content that certainly won’t make it to HTML5 for at least a decade. For pete’s sake.

Flash exists because it can deliver an experience today that cannot be delivered with standard web technologies. If the standard web expands on what it can deliver (and it will), then so will Flash (and it will!). Audio, video and simple animation may soon be HTML based, but it will take longer for the HTML standard to implement 3D graphics, sound manipulation and pixel shading. There will always be a richer experience than HTML, and Flash will exist for as long as it can deliver that experience.

And another thing! Say the committee in charge of JavaScript puts together a draft for a standard system for in-browser audio manipulation, as mentioned above. With today’s way of going about things, that system would need to be separately implemented in each web browser on the market, wouldn’t it? So a future justification to choose one browser over another may be that the one has better sound manipulation than the other. But the reverse may be true for some other element of the user’s web experience, like 3D graphics.

Browser wars are good, I think– the competition keeps the browsers relatively fast and bug-free. But on how many fronts can you fight a war? Would we tolerate a browser war where 3D graphics aficionados swarm to one contender, while audiophiles follow another, with no middle ground? And what if something goes wrong, again, and we end up with substantially different variations on the standard implementation?

“Welcome to my site! Requires Internet Explorer, or your ears will pop.” Not pretty.

It would be better, in this future scenario, for browsers to support plugins that specialize in a part of the experience and compete with one another in that niche. That way, browsers can compete against other browsers, while sound plugins can compete against other sound plugins and 3D plugins can compete against other 3D plugins.

I’m calling it right here: The future web will be delivered by a mash-up of third party plugins that each deliver their little part of the whole enchilada. And there will always be plugins that deliver something not presently standardized (the role Flash has had for the past thirteen years), because somebody somewhere will always be thinking ahead of the curve.

Do gotoAndPlay() and gotoAndStop() ring any bells, anyone? Dijkstra’s commentary on how a dynamic, running process can be conceptually connected to static source code essentially describes the same relationship between a Flash animation and its keyframes. And old Flash code that uses gotoAndPlay() extensively experiences the exact same pitfalls that old programs did that extensively used GOTO.

In fact, I completely agree with EWD- that although these functions are extremely useful, the quality of a Flash program generally correlates with the frequency of gotoAndPlay() and gotoAndStop() in its source code. I know this from personal experience; it wasn’t until I expanded my knowledge of ActionScript and began using structured code that I could really achieve anything in the medium.

I’ll even go one step further and say that the reason why most people look down their noses at ActionScript is because more often than not, ActionScript programmers will hack together a system that relies on gotoAndPlay(). Had we been less dependent on that function earlier on, perhaps Flash would have been more generally adopted as an application platform.

That said, I know for a fact that there are elegant ways to code with gotoAndPlay(). Jared Tarbell’s ActionScript 2.0 projects at levitated.net are perfect examples of how timeline dependence can be a weird type of art form. There is something physical about using GOTO; it gives code an intricacy, because it reduces readability.

EWD was a highly analytical computer scientist; I wonder if he’d have been willing to see source code as a kind of art. I really wish I could have had that discussion.

GOTO is understandably bad from a present-day perspective; it allows a thread to jump to basically anywhere in a process, and even in situations where it is used respectfully, it is difficult for the programmer to indicate so in his or her source code. But GOTO did something that lots of people could appreciate; it allowed an inner loop to break out of an outer loop. It essentially allowed a complex iterative process to end before the iteration could be completed, without any nutty boolean flags.

Nineteen years after Dijkstra’s rant against GOTOs, a guy named Rubin wrote a counterargument. (This was in 1987, about the time I was born.) By then, GOTO-independence was almost a religious (read: irrational) doctrine. Rubin’s rebuttal reinitialized dialogue about GOTOs. Most people involved in the discussion pointed out that the strength of GOTO could be inherited by some sort of more restrained flow control successor, one that couldn’t just jump around the process. [It should be noted that the formulation of our most common present-day flow control statements were highly influenced by EWD. -Ed.] Rubin’s stance was that at the time, code that used GOTO properly was less cluttered and more readable than code written to deliberately avoid GOTO, and that therefore EWD’s 1968 proposal to eradicate GOTO had a harmful effect on programming efforts.

Dijkstra replied, and here’s what gets me; he noted some errors in Rubin’s code– mostly failures to comply with an orthodox writing style– lambasted him for being an amateur, used computer science to achieve a difficult-to-read solution to Rubin’s example problem, and basically called the man and the other contributors to the conversation “unprofessional”.

It’s too bad the discussion didn’t take place yesterday, or I’d troll him on a message board somewhere.

I believe and can understand that Dijkstra was coming from a different perspective- a highly technically informed one. He was in the middle of a major movement attempting to bridge programming with highly abstract mathematics. But programmers typically will not pour over algorithms to produce code, mainly because it reduces the reader’s comprehension, a principle ironically similar to EWD’s original incentive to ban GOTO in the first place! Wouldn’t it be better to write code that can be understood by those responsible for maintaining it?

This is what the creators of ActionScript 3 had done. [Apparently this language element was inherited from Java. -Ed.] In a situation where code in an inner scope needs to break from an outer scope, the “break” statement can refer to the name of a scope that it is nested within. The following code uses this principle to report the index of the first row composed only of zeros in a 2D matrix of integers:

You see? Comprehensible, expressive. Powerful. Anyone who is familiar with C syntax would have no trouble understanding this. Even Python users would be fine with it (though I’d take the curly braces out first, the pansies).

In conclusion: GOTO had serious problems, and it’s good that it’s gone. And Dijkstra’s contribution to computer science and programming has been invaluable. But his rebuttal was far less sensible than his original proposal; his personal attack on Rubin did nothing to inform the readers on the problems surrounding GOTO, but instead revealed his intolerance for programmers who were more down-to-earth than he is.

References!

[-1] “GOTO considered harmful”, EWD
[0] “‘GOTO considered harmful’ considered harmful”, Rubin
[1]“‘”GOTO considered harmful” considered harmful’ considered harmful?”
[2]“On a somewhat disappointing correspondence”, ugh, EWD

http://www.playauditorium.com/

Now if only this sort of thing showed up more often.

The eighties weren’t so bad.

I expect to typically talk about current projects outside of work, general discoveries and ramblings, all typically centered on Flash and ActionScript. I’ll be opinionated but not very personal. And hopefully, as I get used to WordPress, I’ll set up some lessons or video tutorials to help people get a grip on the Flash platform, or what have you.

For now, I’m bringing over some thoughts I’ve put on Posterous in the past, and just generally checking the rigging. It’ll take a while to make this site what I want it to be, so until then, a little patience please.

Thanks for dropping by.