> One can argue that Applets were that attempt, and their
> failure was due not to technical reasons, but Sun's
> inability or unwillingness to make the infrastructure
> robust enough.

Somebody on the FONC mailing list (Alan Kay's project) recently linked me to some fascinating discussion on the history of Java's AWT and Swing products. Basically, I don't think it was unwillingness. Rather, it was a bureaucratic shame carried through to political perfection.

In short, the AWT team at Sun ended up getting control over Swing due to mergers and acquisitions and deadline pressure. The AWT team were by and large horrible GUI programmers.

And AWT itself was built in 1 month.

So as Gerry Weinberg says, "Things are the way they are because they got that way ... one logical step at a time".

I wouldn't worry about the Google Wave thing, per se.

GWT is used by lots of people and has lots of commercial vendor support.

I think there are indeed some architectural flaws in GWT, but most people don't care or understand why I consider them flaws. For most people, GWT is good enough. Unless you've got safety critical interaction design requirements, GWT probably works fine for you (assuming you know Java).

If you don't know Java, then the only real alternative you might consider that is a direct competitor (in an indirect way) would be F# and WebSharper. WebSharper is IMHO better, but still not nirvana. It shares a lot of the same architectural defects. WebSharper is a little bit nicer in that its form construction is based on Phil Wadler's programming language work on Links, and so all form construction follows rigid matematical rules for abstraction; this means you can't do stupid shit and the compiler will statically prevent you from writing dumb code (more or less true).

I don't think most people understand distributed programming, and even fewer believe/understand that GUIs are distributed programming endpoints. Believing/understanding that requires understanding that partial failure is a primary technical requirement.

I actually debated the design of a feature of GWT on the programming web log Lambda the Ultimate, and the designers of GWT weighed in. I was not impressed by their feedback to me, and gave a very strong rebuttal as to why I think they missed the point.

Bottom line: GWT is "good enough" software, but I don't think it will be how we are writing web apps in 10 years. At least it is better than ABC's Tea Servlets.

> Good day John,
> Your response energized my curiosity and wanted to
> ed to know if you wouldnt mind elaborating on your seven
> points.
> Specifically what languages represent each point.

1) High-level shading languages have been around for awhile now. The first major one was called Cg and developed by NVIDIA, but OpenGL and DirectX 9 (HLSL) both have APIs for it.

2) Well, I've kind of learned about different ways to do layout in a mostly organic fashion. I don't think there is any widely used language that lets you directly write physics-based layout today; my first exposure to this idea was from Microsoft Beijing researcher Sean McDirmid (who worked on the Scala IDE in his post-doc work). But the big picture is the difference between physics-based layout, general purpose constraint layouts that use solvers, and other forms of layout which are basically all variants of linear constraints: fixed, stack, grid. The value add behind physics-based layout is more naturalistic UI and responsiveness. Think multi-touch technologies. When you touch something, tactile responsiveness should be 'as if' it were the real thing. Think even further into the future when we have holographic tactile devices that use wind to create the illusion of 3D that you can not just see but feel; these were displayed at SIGGRAPH not long ago and one has to wonder if in another 30-40 years they will hit the mainstream market place.

(3) These are extremely important for some Operations software, like building plans and the ability to see schematics of buildings in real-time. Basically, the stuff you saw in Season 8 of the TV show 24? We can do that today. And you can also do other cool stuff like simulate pipeline flows for sewage, oil, etc. Again, I think it is inaccurate to speak of a particular language. WPF appears to be the best tool for the job in this area. The main reason is that a lot of legacy software is written in Win32 and WPF has pretty good interop/legacy support, and so WPF allows old stuff to be combined with the new hotness. That, and the resolution-independence feature combine for a no brainer as far as I'm concerned when writing 3D desktop apps. IBM calls these "Workstation apps", because IBM needs a different name for everything.

(4) You should really play with the Smalltalk Skeleton system. Or at least look at vid caps. Words cannot do its design brilliance justice. As I understand from a comment Alan Kay made on the FONC mailing list a number of months ago, something similar was built for the CIA in the 1980s as a top secret project, and was the first ever "object-oriented spreadsheet", where objects could be manipulated as first-class values on the screen e.g. a Chart would ask data points if they were positive or negative, rather than decide for the data points what color they should be. This change in viewpoint is very cool. Silverlight has a cool data grid from Xceed, but it is not as composable as even the Ext.js data grid, because you have to provide the type information ahead of time in order to guide execution. In ext.js, types don't influence computation. In Silverlight's Xceed DataGrid, they do. The freedom of not depending on types foe execution semantics means you can easily do late binding, and sometimes this is necessary for highly reflective code. If you're using this feature and worried about performance, you don't understand what it can be used for.

(5) Resolution-independence; geeze, this covers everything from g11n (i18n/L10n) to figuring out what you should display when the underlying media screen type changes; is this a monitor, wide screen monitor? Is it a projector? Is it a phone? etc.

(6) Actors are the one theory on this list that are truly language independent, and do not depend on a language to implement. They pretty much work equally well in a language or library. The benefit to providing actors in a language directly is for mathematical proofs about the computation. Invariably, languages that incorporate actors directly into the language rather than as a library do it in such a way as to make writing proofs difficult; this isn't want Carl Hewitt intended as far as I can tell. The gist of why Actors are good for GUIs is that actors have this feature called acquaintances which basically covers how you systematically update an environment's values, and the rules work even in a distributed setting. Most so-called "Web Services" e.g. ones that use RPC everywhere and are really the IBM Marketing-misunderstanding of Web Services can't actually gaurantee a user interface is consistent. E.g. if two tabs are loaded using different connections, what happens if I delete an item in one tab but not the other? I've seen silly heuristics people use to model their way around this design issue, which use a lot of buzzwords like Domain Driven Design and Command/Query Responsibility Separation. I think that those heuristics are super awesome and demonstrate that human beings have a deep, visceral feel for laws of Nature even when they can't put their finger on the mathematical argument for why they work.

(7) Dataflow diagrams are just plain cool and have the property that editing a node in a dataflow diagram is an atomic operation. Therefore, if you want to build reflective capabilities into your interface, like the ones in Symbolics Genera OS and the Garnet GUI, then dataflow diagrams are the best way to do it because you are guaranteed basic serialization/deserialization properties. That means you can store the configuration of your UI separate from your code. Dataflow diagrams are like WPF XAML on steroids, and what WPF should've been based on. Instead WPF has a bunch of garbage like Freezable's and the dreaded object Clone operation on Freezables. Cloning is really bad in object-oriented applications, because cloning breaks object invariants (identity invariants).

> Which gui tool do you enjoy the most as of late.

Easily WPF / Silverlight. However, I have developed what I believe to be safe coding patterns that avoid the too-clever-by-half stuff in WPF. For the most part, Silverlight is just a better WPF, but lacks some of the heavy artillery WPF has for 3D graphics.

When working in WPF, I just try to avoid what I call the "script kiddie" features. Stuff that relies on ambient authority to decide what to do:

(1) In WPF/Silverlight, you can't mock the dependency management subsystem, and so it is really easy for junior programmers to write code with a lot of implicit constraints that are easy to violate when you swap out views. WPF is especially gross because they have this thing called "Themes" that have no corresponding object model. It is just hardwired code that searches some ambient resource for data. Theming in WPF is not first-class. In Silverlight, they simply got rid of it because the idea of Themes is pretty much a bogus pretense and needless complexity. When you have the requirements of Silverlight, such as fitting the CLR in 4GB of runtime size, all the stupid frills in WPF have to drop out.

(2) I find that WPF wants to do too much work for me, and that the cost for letting it do this work is too high. I am left wondering why WPF just didn't use a COTS dependency injection framework. Stuff like the FindResource method, DataTemplate.DataType attribute, etc. are simply not necessary. All you need is a DataTemplateSelector. You supply the Control with information on how it should visualize itself, and the Control simply manages its internal event loop; a Control should simply manage its own control and nothing else, including its Look. This sort of "Lookless Control" paradigm takes some time getting used to but once you do, unit testing becomes a breeze and you can actually mock complex subsystems and isolate them from one another. I would go so far as to recommend using CQL (Code QUery Language) and write assertions that check for use of FindResource and DataTemplate.DataType uses in WPF code. In Silverlight, there isn't even a DataTemplate.DataType, because the whole notion of it is ass-backwards.

(3) Most people find WPF complicated, but I'm convinced its all this noise creatd by poor abstraction. The stuff I mention above just forces your eyes to see unnecessary things. The WPF people should've had a Feng Shui master on the design team. Have you ever cleaned your room and hid a bunch of objects and then noticed what a relief it feels once they are out of plain sight? I have. Programming API design is the same way... the less concepts we have to manage, the lighter, faster, better things feel. Most of WPF has that bad J2EE feel, though. You just have to use discipline and avoid the script kiddie stuff.

(4) WPF team keeps adding horrible APIs to the product, and I am not sure how much longer it can last. Win32 lasted 15 years, though. The latest example of a horrible API is the built-in spellchecking API, which is supposed to make your life easier, but is another demonstration of a script kiddie API targeted toward moron programmers. It uses a concrete object for spellchecking and you have no way to mock the behavior for testing, or write your own spellchecker. You also can't therefore write a context-sensitive spellchecking algorithm, which are considered some of the best spellchecking algorithms around. If you don't believe me, search Google Video about this and you'll see engineers at Google talk about how they improve spellchecking.

(5) Silverlight on the Win7 Phone OS is the equivalent to Cocoa for the iPhone. Silverlight is all you get right now on Win7 Phones.

> And how was the Curl programming ? They were from MIT
> originally right ?

Curl was one of the two projects to come out of MIT when they were exploring the idea of the Web. The other was a little old thing called the W3C. Curl was spun out of MIT and founded by a bunch of MIT Media Lab people, and has mostly been in an abysmal existence due to bizarre licensing models and ineffective software bundling strategies. Curl itself didn't allow you to extend everything about the machine easily, and in some respects was a closed box (the licensing feature is only the tip of the iceberg in terms of shrinkwrapped design decisions). Overall, I am glad Curl is not popular. I simply wish Flash had a similar failure.


> Thanks for your time. Im going to read that pdf you
> suggested also.

Thanks for not being afraid to ask questions.

> Good thread. I always wondered about the applet thing also.