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

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

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

Thanks for your time. Im going to read that pdf you suggested also.
Good thread. I always wondered about the applet thing also.

> 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.

I agree that we are dealing with "a distributed system and the problem of linking and loading code in a distributed system". That seems obvious to me.

What is unclear to me is what would you like to expose the programmer to if it is not a lower level interface to the process of loading and linking code.

> I agree that we are dealing with "a distributed system and
> the problem of linking and loading code in a distributed
> system". That seems obvious to me.
>
> What is unclear to me is what would you like to expose the
> programmer to if it is not a lower level interface to the
> process of loading and linking code.

Here is how I imagine a small hello world program in a distributed system:

import www.widgets.com/ui/MainWindow;
import www.widgets.com/ui/PushButton;

int main() {
    //create the main window
    MainWindow wnd = new MainWindow();
    wnd.setTitle("Hello world!");
    
    //create the button
    PushButton btn = new PushButton();
    btn.setText("&Quit");
    btn.setOnClick(void(){ wnd.close(); });
    btn.setBitmap(new Bitmap() from www.pictures.com/bitmap1);
    wnd.add(btn);

    //do events
    wnd.doEventLoop();
}

Interesting things to notice:

1) the class MainWindow is imported from the network.
2) the class PushButton is imported from the network.
3) an instance of Bitmap is fetched from the network.

The VM for such a programming language could cache the components locally and only update them if there is a new version of them.

> The VM for such a programming language could cache the
> components locally and only update them if there is a new
> version of them.

What you're asking for is a distributed/federated RDBMS, but for a UI. Been done. Not cheap or easy, and shouldn't be tied to a particular application language. Shouldn't is my opinion, of course.

One has two options:
- make the facility language agnostic, a la the RDBMS approach which ties you to the RDBMS engine (UI server) as controller.
- make the facility datastore/server agnostic, a la JNI/whatever and be tied to a language.

Coders, being language zealots, generally prefer the latter. Data geeks, being language agnostic, prefer the former.

You pays your money, and you takes your choice. Well, there's always CORBA for those who want it both ways.

Achilleas,

That's a pretty good start and you are on the right track...

I would recommend writing in a more applicative style using a combinator library for composing the GUI. What you "import" should only be the concrete dependency you need to inject. The thought of procedurally configuring things inside the main() seems gross to me... Why create an unnecessary Context that your concrete dependencies have to rely on for proper testing. Just supply the final constructed object.

What we do is we abstract away this stuff so it is just a graph of objects you fetch by identity. As you said, caching this is very straight-forward because it is document-oriented.

> Here is how I imagine a small hello world program in a
> distributed system:
>

> import www.widgets.com/ui/MainWindow;
> import www.widgets.com/ui/PushButton;
> 
> int main() {
>     //create the main window
>     MainWindow wnd = new MainWindow();
>     wnd.setTitle("Hello world!");
>     
>     //create the button
>     PushButton btn = new PushButton();
>     btn.setText("&Quit");
>     btn.setOnClick(void(){ wnd.close(); });
> btn.setBitmap(new Bitmap() from
> from www.pictures.com/bitmap1);
>     wnd.add(btn);
> 
>     //do events
>     wnd.doEventLoop();
> }
> 

That's an interesting notation, by the way. So, removing what can probably be inferred, could I write instead:

int main() {
//create the main window
wnd = new MainWindow() from www.widgets.com/ui/MainWindow;;
wnd.setTitle("Hello world!");

//create the button
btn = new PushButton() from www.widgets.com/ui/PushButton;
btn.setText("&Quit");
btn.setOnClick(void(){ wnd.close(); });
btn.setBitmap(new Bitmap() from www.pictures.com/bitmap1);
wnd.add(btn);

//do events
wnd.doEventLoop();
}

> I agree that we are dealing with "a distributed system and
> the problem of linking and loading code in a distributed
> system". That seems obvious to me.
>
> What is unclear to me is what would you like to expose the
> programmer to if it is not a lower level interface to the
> process of loading and linking code.

Service agreements. What to do in response to partial failure.

Very few web applications are well-written, and usually when they are well-written, they get acquired by morons. Look at Zimbra and Yahoo. Yahoo buried Zimbra, which blew away Yahoo Mail. To this day, Yahoo Mail is a complete rathole and embarassment to everyone who works there.

Have you ever seen a presentation by one of the members of the Zimbra team? They understood how to build distributed mail clients. They had a very clearly defined scheme for handling intermittent connectivity and other network disruption issues; they used an object database to persist the client's data to disk until they could re-connect. And the application was partitioned at very logical points from the customer's perspective.

Contrast this to Yahoo today, where their FAQ page for why Yahoo mail sucks basically forces you to take a random ugly error code Yahoo gave you as a page result, look it up, and still wonder what the hell you should do to solve the problem, if anything.

> > The VM for such a programming language could cache the
> > components locally and only update them if there is a
> new
> > version of them.
>
> What you're asking for is a distributed/federated RDBMS,
> but for a UI. Been done. Not cheap or easy, and
> shouldn't be tied to a particular application language.
> Shouldn't is my opinion, of course.
>
> One has two options:
> - make the facility language agnostic, a la the RDBMS
> approach which ties you to the RDBMS engine (UI server) as
> controller.
> - make the facility datastore/server agnostic, a la
> JNI/whatever and be tied to a language.
>
> Coders, being language zealots, generally prefer the
> latter. Data geeks, being language agnostic, prefer the
> former.
>
> You pays your money, and you takes your choice. Well,
> there's always CORBA for those who want it both ways.

Something interesting about William Cook's recent work is that he has recently preferred encapsulating the database technology using standard object-oriented Factories. In my books, the only problem this is that the Factory doesn't necessarily have to explain how you can edit it reflectively, since that would be the wrong place to put the logic for it (it would end up conflating object identity returned by the Factory with editing and replacing the component parts in the object graph).

...The other problem here is security. Cook also has some papers written about stuff on this topic that I care less about, e.g. the Chinese Wall Model for computer security (http://en.wikipedia.org/wiki/Chinese_wall#Computer_security).

John,
Would have never thought you would have said you liked WPF the best as of late.

I think I followed your script kiddie stuff. Never did anything with WPF. Maybe Ill take a look. Usually folks whizz on anything M*crosoft as poorly designed.

Thanks for your response. Started looking at WebSharper too.

Anybody see any future in QT4 ?

Microsoft has a ton of good products right now and a great user community.

My favorite Microsoft products are F#, Excel, .NET and SQL Server.

Design is subjective, and Microsoft has traditionally incorporated very little feedback from customers into their design process. That has changed quite a bit in the past decade, and it takes about that long for a corporate culture to change.

There are some pain points with WPF, but I find that WPF/Silverlight tend to do well at the tasks most people spend their most time on. I was also surprised at the fact that WPF didn't kill off the third party market for software components. I thought companies like Xceed, Telerik, Infragistics, etc. would be in trouble because WPF makes it so easy to prototype new user interface controls. But I was wrong because I misunderstood the needs of the market; people will always want COTS solutions to their problems and even if something takes 10 hours, that is 10 hours they can't afford even if it is "fun".

The third party market not only survived WPF, but they have been innovating thanks to the freedom WPF gives. I mentioned the Xceed data grid for Silverlight earlier, and I think it is fairly innovative. The major difference between a WPF DataGrid and say a Smalltalk Skeleton system or even Sencha's Ext.js Grid is what the differences boil down to. Technically, I really like the Ext.js philosophy of allowing the programmer to provide a post-hoc algorithm for telling the Grid how to crawl a data structure. I find it is more late-bound and flexible than the usual .NET IEnumerable iterator approach where the object encapsulates its data access strategy. Sometimes you need a "Superfold" and/or "Transfold" functional programming pattern to describe data access, and to put that logic inside the object can be a mistake since it binds tightly to the object.

Usually I'm not worried about GUI performance for the software I write, so I like the late-boundness because most of our software is used by financial analysts who need ad-hoc dynamic UI features where you can't possibly define static types at compile time... We actually don't have a notion of "compile time" in our applications, but instead Refresh buttons. At least, I find if you are doing "business intelligence" or "distributed intelligence" or whatever buzzword-compliant-intelligence, then you need late bound functionality. At compile time, the system will always be under-constrained and the analyst has to supply you with choices to allow you to build the UI a certain way...

> Anybody see any future in QT4 ?

If you are developing cross-platform old-school desktop apps, then your options are pretty much GTK+, QT4, or Silverlight/Moonlight. QT4 has a future simply because there are so few competitors. But most applications that were desktop apps probably don't need to be desktop apps... and could go on the Web just as easily.

QT4 and KDE4 both great platforms. Don't know if you used either lately, but for example my friend does real estate here in Boston and I set him up with Kubuntu and he loves it. All he cares about is stability and having a crapton of Firefox plugins. His Firefox is so tricked out it doesn't even look like Firefox... and he loves that. Everything else, like checking email, he does through Gmail.

My former landlord (CEO of a Semiconductor company in Massachussets) would always tell me that the desktop is dead, and he will never go back to Outlook because he can take Gmail anywhere and he doesn't have to worry about losing his data. He's pretty representative of how C-level execs think. I can see why... with Outlook you've always got to partition things into folders if you want fast search for old files. So when the CEO calls you up and asks you about some project he floated four months ago, you can find it before you hang up on the phone. Can't do that in Outlook out-of-the-box. Can do it in Gmail.