Now that I have been programming in the ActionScript/Flash environment for a few weeks, I thought it might be useful to compare it to the C#/WPF environment.
These are just some impressions, in no particular order:
- Adobe’s documentation is much better than Microsoft’s – better organized and visually more appealing
- Microsoft has better tools – in particular, I like using Visual Studio better than Eclipse
- it is surprising how similar the two frameworks are – MXML and XAML, both use “code-behind”, both C# and ActionScript seem to be clones of Java. I don’t know which one copied the other, but IMHO they are both trying to build applications the wrong way
- Adobe has fewer classes but with higher level functionality – generally, I prefer the Adobe approach
- WPF looks better on Vista – Vista is my development platform, and (not surprisingly), WPF has better looking text and graphics. Of course, Flash is available on other platforms where WPF doen’t run
- Flash seems to load faster – I am amazed at how quickly Vst in Flash loads, both on my system and other Windows XP systems where I have tested it
- WPF has 3D graphics – AFIK, Flash does not support 3D – for the vast majority of applications, it probably doesn’t matter
- WPF has multi-threading – Flash seems to be able to process server requests in the background, so maybe this is not too important. I still don’t know enough about Flash yet to fully understand its capabilities or limitations in this area
Hey – I have been wondering for a while if you were actually at Microsoft or not. this post indicates definitely not. an “about” page would be really helpful. could you post on the who/what/where/why and when please.
Comment by monkchips — February 20, 2007 @ 2:38 pm
I would have thought a fairer comparison would have been Flash and WPF/e but the differences you listed highlight I think, where Flash and other ECMASCRIPT based languages need to address, namely hardware acceleration.
I’d be interested in hearing more on why you believe they’re trying to build applications the wrong way? I’ve looked a little at SmallTalk and like what I see when it comes to metaprogramming(I hope I got that right). The ability to create my own domain specific languages and simple message passing is appealing. There just isn’t the libraries I’d like out there for it. Hence one of the reasons I’m learning Python, C and Javascript and hope to follow that with SmallTalk.
FWIW, Actionscript as I understand it is basically just ECMASCRIPT rev3 aka Mozilla Javascript 1.7.
There’s been talk about threading in the Javascript world recently. See Brendan (Javascript creator) and Neil Mix has more.
While I’m only new to programming, with still a lot to learn, the patterns I’m seeing are heading towards event-driven development using coroutines or a derivative of(python/js generators). As I understand it it’s partly because of the advent of virtual machines and widespread consumer based multiprocessor systems and the difficulty of debugging race conditions with threaded applications but I’m happy to be enlightened otherwise. Am I correct in assuming SmallTalk has these bases covered already?
Comment by Craig — February 20, 2007 @ 3:12 pm
Monkchips,
That is a good suggestion.
FWIW, I live in Gatineau, Quebec, Canada and have been programming since 1969. When I get the time to do a proper site update, I’ll add all the details.
Comment by pfisk — February 20, 2007 @ 5:59 pm
Craig,
The main problem with the Adobe/Microsoft/OpenLaszlo approach is that the UI is statically defined at design time. My view is that the UI should be dynamically adapting to your needs as you are using it – and those needs can’t be known completely beforehand.
Lisp facilitates the creation of “mini-languages” (or DSL’s) which can simplify development if used properly. As for event driven programming, it has been used for a long time in several areas such as user interfaces (the Win32 API is a good example), communications, process instrumentation, etc. You can get race conditions with Smalltalk if you try hard enough – it isn’t a magic solution. Using the full power of multi-core processors depends more on “factoring” the application than the language that is used.
Comment by pfisk — February 20, 2007 @ 6:18 pm
If the UI is “dynamically adapting to your needs” as you put it, this must be defined by the code at some point. I don’t understand how this capability is not achievable in WPF (or the technologies I’m not familiar with). Just because a UI is designed declaratively does not mean it cannot change at runtime, particularly with a technology like WPF where the UI can be driven by data. Above all else you can still generate UI at runtime in code, even parsing and compiling XAML at runtime is a simple task.
Comment by Andrew — February 21, 2007 @ 6:59 am
[...] Comparing Flash and WPF « Microsoft .Net and Smalltalk very nice. this comes from someone with no axe to grind. “Adobe’s documentation is much better than Microsoft’s – better organized and visually more appealing” (tags: Smalltalk Vista Adobe WPF Flash) [...]
Pingback by James Governor’s Monkchips » links for 2007-02-21 — February 21, 2007 @ 7:34 am
Andrew,
I understand what you are saying and you are right that the interface can be manipulated with code – after all, that is what I am doing in Vst.
So, you either “hard code” the interface manipulation (in actionscript or C#) or you read it from some kind of parameter file (XML or other format). And then you will want to add some features to your parameters (repetition, branching, etc) until you have created your own mini-language. I have seen this happen before … many, many times.
It is better just to use a real scripting langauge from the start.
Comment by pfisk — February 21, 2007 @ 3:03 pm
PaperVision is an ongoing 3D project for Flash that has produced some remarkable results: http://blog.papervision3d.org/
Comment by Andrew Muller — February 25, 2007 @ 5:17 am
Andrew,
PaperVision is amazing! Thanks for the link.
Comment by pfisk — February 25, 2007 @ 2:22 pm