Programming as Art

While on the subject of style... A while back I wrote an article about the relationship between programming and art, and the aspects of programming that could be considered artistic. Now, I think it's time to share it with the world.

Writing computer code is an act of communication. As such, the thoughts and feelings that drive the act are comparable to the impulses the motivate painters, writers and musicians. Programming is an attempt to take an idea that does not have a concrete existence and express it. Along the way, programmers are required to make thousands of choices, many of which will have an aesthetic impact on their code. The emotions a programmer brings to her work will shape the code. In the end, the source code that gives life to the programmer’s abstract ideas can be elegant or inventive or it can be ugly and spaghetti-like.

Is it possible to call a piece of code "beautiful" or "artistic"? While we may never see sheets of source code hanging in the Louvre, I believe the answer is yes.

More...

Coding Style: I've Finally Succumbed to Peer Pressure

I've always thought code looks more elegant and symmetrical in the old C Style, where the open curly brace has it's own line. Such as...

void main()
{
  printf("Hello world");
  if(x == true)
  {
    doSomething();
  }
  exit();
}

In the last few years, it seems like just about everyone has switched to putting the brace on the same line as the function declaration or if statement. And I'm just tired of my code sticking out. So I've finally accepted that this is the way of the world, and I've started to write my code with the open brace on the same line.

void main(){
... etc.

I{
  hope{
    you're{
        all{
            happy!{
}}}}}

MovieClip & TextField Added to Flash Beta Docs

Originally I was just going to post the machine-created docs, and be done with it. But I've had quite a bit of fun digging into the new features. Judging by the increased traffic on my site, and by the number of demos popping up on the net, I'm not alone in my excitement about Flash 8. So I've started to go into the source .as files by hand and add more comments. Today, I posted a big update based on my work. Most notable is the addition of MovieClip and TextField classes. (Note that I'm only posting the new methods and proprties.)

As there is now a greater Human Element involved in creating the doc files, the possibility of errors increases. So if you encounter any mistakes or bugs, please don't hesitate to contact me.

Updating Flash 8 Docs: DropShadowFilter Example

The Flash 8 Docs I've posted seem to be pretty popular, so I thought I'd devote some time updating the docs with explanations and examples. Unfortunately, my FAME was not very cooperative this morning, so I didn't get as far as I wanted to in experimenting and building examples. Still, I did manage to add some comments to the DropShadowFilter class page. (The example is down near the bottom of the page, under the constructor.)

In the future, I'd like to also post some tutorials and compiled examples. So keep checking back at PASZ.COM!

Updated Flash 8 Docs

A new 'std' directory has been posted for MTASC. I've parsed the new files updated my docs. You might need to clear your cache to see the latest updates.

Flash vs. Ajax 2 - Summary of Existing Articles

Before I write much more on this topic, I thought it might be a good idea to take a look at what's already been written.

Mark, from O'Reilly Radar writes about the Macromedia presentation at this year's Ajax conference in SF, and the ensuing debate. It sounds like he had much the same reaction to this presentation as I did to the presentation at Flash Forward: Macromedia was trying to pitch Flash as a part of AJAX, but the subtext was that AJAX was potentially a threat. Key point: "The Ajax model makes Flash (and Java, and ActiveX) unnecessary for some kinds of interface models. When I first wanted to make, say, a dynamically updating table, Java was the only choice; later, Flash was a much more pleasing choice. Now, Ajax/JavaScript offers a number of advantages over Flash: faster load time, consistent interface with the rest of the browser, a standard/free HTTP server backend, and broader development tool support."

JonathanBoutelle.com has a post the pros and cons of both platforms. He feels that the technologies complement each other, and can co-exist. This is, I think, one of the first articles that was posted on the issue.

JD on MX has only a brief post, but it spawns an interesting debate in the comments.

Mary Jo at Microsoft Watch discusses Microsoft's interest in Ajax. They could be the 500 poind gorilla that changes the shape of the playing field. IE7 comes out later this year. I predict much of the future of the Ajax Movement may turn on the success or failure of this browser.

Flash vs. Ajax

In early July, I attended the Flash Forward Conference in New York, and it was interesting to see how the AJAX Movement was having an impact on the mindset of Flash Developers, and of Macromedia. (Note that I feel it is more apt to describe AJAX as a movement, because it is not really a new technology, but rather a new approach for using existing technologies.) AJAX was mentioned several times in Macromedia's Keynote Address, in their Q&A session, and in a presentation on the Flash/Javascript Integration Kit.

Obviously Macromedia wants to stay on top of trends in web development, but is there also some fear on their part that AJAX techniques could supplant Flash? As a developer who works extensively Flash, and who has started to explore the possibilities with AJAX, I thought I would share some of my own thoughts on this question in a series of posts.

From a technological standpoint, at the moment, Flash doesn't have much to fear from the AJAX Movement. Flash is still miles ahead of DHTML in terms of what it can do on the client. And Flash is likely to stay ahead due JavaScript's dependency on old browsers. For now, the sites that end up using AJAX instead of Flash will mainly feature relatively simple UIs and functionality. Sure there will be some Big Budget AJAX apps coming out, like Google Maps, but for the most part developers will decide that the headaches of working in client-side JavaScript are not worth it. And even Google Maps is a sort of exception that proves the rule. I imagine Google has business reasons for not wanting to be reliant on Macromedia/Adobe, but one has to wonder whether their image caching and loading functionality wouldn't have been smoother, and easier for them to implement in Flash.

From a P.R. standpoint, I think Macromedia has a bit more to be worried about. Flash has always had a certain stigma about it that goes back to the backlash to against annoying animated intros. One of Flash's greatest strengths -- ease of development -- is also a weakness. Because it is so easy to build UIs and animations in Flash, it allows for the Lowest Common Denominator to rise to the top. There have been several other missteps by Macromedia, which have slowed Flash's acceptance as a serious development environment:
1. The absence (until recently) of strict programming and design standards.
2. Performance issues and buggy-ness of their pre-built components.
3. Lack of complete HTML and CSS support.
4. Text rendering issues.
The future of Flash has a lot riding on the upcoming "8 Ball" release. If Macromedia can address the issues that have held back the adoption of the Flash Platform, they can stave off the assault on their dominance by AJAX. The strategy they adopted at Flash Forward of pitching Flash as a tool that can co-exist with technologies like AJAX is probably not enough. They will also have to state more boldly, and in more detail why Flash is better than the alternatives.