Article Discussion
Journey Through Four Interfaces
Summary: Frank Sommers discusses his journey through four user interfaces HTML, Swing, Ajax, and Flex.
26 posts.
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: January 18, 2011 9:20 AM by John
    Bill
     
    Posts: 409 / Nickname: bv / Registered: January 17, 2002 4:28 PM
    Journey Through Four Interfaces
    December 20, 2010 10:00 PM      
    Frank Sommers discusses his journey through four user interfaces HTML, Swing, Ajax, and Flex.

    http://www.artima.com/articles/journey_through_four_interfaces.html

    What has your user interface journey been?
    • Achilleas
       
      Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
      Re: Journey Through Four Interfaces
      January 10, 2011 7:45 AM      
      My journey has been that all four solutions suck a lot, each one for different reasons.

      1) HTML is a mess.

      2) Applets have the problem that need a Java installation.

      3) I haven't used Ruby On Rails, but from what I've been reading about Ruby, it's super slow.

      4) Flex is proprietary and closed source and does not run in all platforms.

      I am still waiting for the 'Internet O/S'. The first one to create such a product will get all the money ;-).
    • Chris
       
      Posts: 4 / Nickname: chrisd / Registered: September 23, 2009 6:15 PM
      Re: Journey Through Four Interfaces
      December 22, 2010 4:07 AM      
      At our company we are currently doing a rewrite of our configuration programs. They used to be MFC programs and now become a webinterface. We use GWT for that and it is a lot of fun to be able to use a modern GUI library for the web. We have also written user interfaces in HTML and that HTML would be produced by C++ code.

      I think it is great that with GWT we do not have to generate HTML ourselves. I think the whole HTML, CSS and JavaScript stack of languages is basically just a mess because the web evolved far faster then the languages and the languages had trouble keeping up. And now the W3C is trying to sell this pile of lack-of-design as if it were a sound idea to begin with.

      The idea of having separate languages for document structure, layout and automation seems totally backwards. In decent languages one uses a GUI library for all of that and one uses the possibilities that a well-designed language has to separate concerns. So, one can have a class that represents a particular way of organizing a form and then create various child classes of it that represent concrete forms with particular texts and controls. By creating some sensible methods and doing a bit of method chaining the building of concrete forms is just as readable in e.g. Java code as it would have been if it were written in HTML (or more readable, actually). And one can organize it in such a way that adding an input element also makes sure automatically that it communicates with the server in the right way.
      • robert
         
        Posts: 35 / Nickname: funbunny / Registered: September 23, 2003 5:08 AM
        Re: Journey Through Four Interfaces
        December 23, 2010 8:19 AM      
        > I think the whole HTML, CSS and
        > JavaScript stack of languages is basically just a mess
        > because the web evolved far faster then the languages and
        > the languages had trouble keeping up.
        Not quite. HTML was constrained from the beginning. It's explicit design imperative was to display text, and nothing more. It was designed to allow academics to trade their papers, often with embedded tabular data. It *isn't* a language, much less a programming language; just some syntax rules. Same goes for xml, only less. JS was a bandaid, and still is. HTML isn't a basis for an interactive POS input screen; that it is used so isn't evolution of the web, but cost avoidance by the developers; they hacked at what was available to make it contort itself into a Klein Bottle (or Frankenstein Monster) rather than create a bespoke language on the assumption that it would be cheaper in the short run. 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.


        > And now the W3C is
        > trying to sell this pile of lack-of-design as if it were a
        > sound idea to begin with.
        Amen.
        • John
           
          Posts: 62 / Nickname: zbo / Registered: January 20, 2007 9:22 AM
          Re: Journey Through Four Interfaces
          January 4, 2011 2:39 PM      
          > 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".
          • Morgan
             
            Posts: 37 / Nickname: miata71 / Registered: March 29, 2006 6:09 AM
            Re: Journey Through Four Interfaces
            January 4, 2011 5:45 PM      
            It's a shame that Applets failed to gel.

            One Java/AJAX technology similar to GWT, but slightly different, is ZK. (www.zkoss.org) Vincent might want to look into it as well. One uses the client more, the other the server more. I can't remember which is which and don't really care. :-)
      • Vincent
         
        Posts: 40 / Nickname: vincent / Registered: November 13, 2002 7:25 AM
        Re: Journey Through Four Interfaces
        December 31, 2010 5:51 AM      
        > I think it is great that with GWT we do not have to
        > generate HTML ourselves.

        After reading this, I thought that I'd take a look at GWT, since it sounds like it might be just the thing for my next project. So, I went to the GWT home page and from there to the 'examples' page and from there to the 'GWT Gallery' where the 'Featured Project' is Google Wave! And it says this about Google Wave: "Google Wave is a new tool for communication and collaboration on the web, coming later this year.".

        A bit worrying.
        • John
           
          Posts: 62 / Nickname: zbo / Registered: January 20, 2007 9:22 AM
          Re: Journey Through Four Interfaces
          January 4, 2011 2:34 PM      
          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.
          • Chris
             
            Posts: 4 / Nickname: chrisd / Registered: September 23, 2009 6:15 PM
            Re: Journey Through Four Interfaces
            January 5, 2011 2:09 AM      
            > I think there are indeed some architectural flaws in GWT,
            > but most people don't care or understand why I consider
            > them flaws.

            So, what are these flaws?

            > If you don't know Java, ....

            Seems like a rather silly problem to have. I did not know much about java before I started programming in GWT. The solution is to just learn it. I am now reading "Thinking in Java" alongside just starting to program in it. Best way to learn any language, I think.

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

            A link to this?

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

            GWT so much looks like a standard GUI library that I would be tempted to conclude that you think that standard GUI libraries are not going to last 10 years. Is this what you think? Or are you referring to possible problems that come with having part of the code running on the browser and part of the code on the server?
            • John
               
              Posts: 62 / Nickname: zbo / Registered: January 20, 2007 9:22 AM
              Re: Journey Through Four Interfaces
              January 5, 2011 8:39 AM      
              > GWT so much looks like a standard GUI library that I would
              > be tempted to conclude that you think that standard GUI
              > libraries are not going to last 10 years. Is this what you
              > think? Or are you referring to possible problems that come
              > with having part of the code running on the browser and
              > part of the code on the server?

              Both.

              The former is too big of an issue for me to care to delve into here.

              Speaking to the latter, as far as I'm aware, batching code for remote execution is still an open problem (but with a number of solutions); we don't really have a framework for analyzing the trade-offs in designing such a language feature. Related: William Cook wrote a great paper that won a best paper award, analyzing "Web Services versus Distributed Objects: A Case Study of Performance and Interface Design" http://www.cs.utexas.edu/~wcook/Drafts/2006/WSvsDO.pdf -- highly recommended reading.
            • John
               
              Posts: 62 / Nickname: zbo / Registered: January 20, 2007 9:22 AM
              Re: Journey Through Four Interfaces
              January 5, 2011 8:11 AM      
              Chris,

              I didn't link it originally because it is a very long thread and I don't expect most people here have the free time to read it, but here you go: http://lambda-the-ultimate.org/node/3707

              If you want to read just the exchange between me and the GWT architect, go here: http://lambda-the-ultimate.org/node/3707#comment-53190

              In a nutshell, GWT hardwires sequences of collaborations between its loader interface, the browsers request engine, and the application's communication protocol with servers. This ends up subverting a lot of your module design and actually inhibits modularity.

              Some have come up with slight solutions to manage GWT 2.0's poor code splitting API design: http://jcheng.wordpress.com/2010/02/16/elegant-code-splitting-with-gwt/ Not perfect, but a neat hack.

              Cheers,
              Z-Bo
              • Chris
                 
                Posts: 4 / Nickname: chrisd / Registered: September 23, 2009 6:15 PM
                Re: Journey Through Four Interfaces
                January 7, 2011 7:16 AM      
                > In a nutshell, GWT hardwires sequences of collaborations
                > between its loader interface, the browsers request engine,
                > and the application's communication protocol with servers.
                > This ends up subverting a lot of your module design and
                > d actually inhibits modularity.

                Okay, but I would not call these "architectural flaws". It seems more like a problem that could theoretically be solved in between GWT versions 2.3.6 and 2.3.7 by just reimplementing the code import mechanism, exposing a lower level interface in a sensible way and keeping the same higher level interface as a default way of dealing with the lower level one. Or is there a fundamental browser problem that would make this impossible? But if it is a fundamental browser problem, it is not an architectural flaw of GWT but of browsers...
                • John
                   
                  Posts: 62 / Nickname: zbo / Registered: January 20, 2007 9:22 AM
                  Re: Journey Through Four Interfaces
                  January 10, 2011 8:49 AM      
                  > Okay, but I would not call these "architectural flaws". It
                  > seems more like a problem that could theoretically be
                  > solved in between GWT versions 2.3.6 and 2.3.7 by just
                  > reimplementing the code import mechanism, exposing a lower
                  > level interface in a sensible way and keeping the same
                  > higher level interface as a default way of dealing with
                  > the lower level one. Or is there a fundamental browser
                  > problem that would make this impossible? But if it is a
                  > fundamental browser problem, it is not an architectural
                  > flaw of GWT but of browsers...

                  RE: whether these are "architectural flaws"

                  Have to disagree with your definition, in that you refer to the current callback mechanism as high-level. To me, I think I correctly abstracted the problem domain by thinking in terms of a distributed system and the problem of linking and loading code in a distributed system, tied to actual user stories. But everyone's POV will be different.

                  To me, callbacks are a fine *implementation* detail, but do not make sense to expose the programmer to. If the GWT compiler has to compile them to javascript callbacks, then so be it - Javascript is well-suited to use event-loop concurrency and that should probably be how it's done, anyway.
                  • Chris
                     
                    Posts: 4 / Nickname: chrisd / Registered: September 23, 2009 6:15 PM
                    Re: Journey Through Four Interfaces
                    January 14, 2011 1:36 AM      
                    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.
                    • John
                       
                      Posts: 62 / Nickname: zbo / Registered: January 20, 2007 9:22 AM
                      Re: Journey Through Four Interfaces
                      January 14, 2011 10:17 AM      
                      > 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.
                    • Achilleas
                       
                      Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
                      Re: Journey Through Four Interfaces
                      January 14, 2011 4:38 AM      
                      > 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.
                      • John
                         
                        Posts: 62 / Nickname: zbo / Registered: January 20, 2007 9:22 AM
                        Re: Journey Through Four Interfaces
                        January 14, 2011 9:11 AM      
                        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.
                      • John
                         
                        Posts: 62 / Nickname: zbo / Registered: January 20, 2007 9:22 AM
                        Re: Journey Through Four Interfaces
                        January 14, 2011 9:18 AM      
                        > 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();
                        }
                      • robert
                         
                        Posts: 35 / Nickname: funbunny / Registered: September 23, 2003 5:08 AM
                        Re: Journey Through Four Interfaces
                        January 14, 2011 8:56 AM      
                        > 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.
                        • John
                           
                          Posts: 62 / Nickname: zbo / Registered: January 20, 2007 9:22 AM
                          Re: Journey Through Four Interfaces
                          January 14, 2011 11:27 AM      
                          > > 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
       
      Posts: 62 / Nickname: zbo / Registered: January 20, 2007 9:22 AM
      Re: Journey Through Four Interfaces
      December 23, 2010 0:59 PM      
      > What has your user interface journey been?

      I've dabbled in just about every user interface technology available to the mainstream over the past 15 years. Even the most obscure stuff like the Curl VM, I've dabbled with.

      I think Frank should never have wrote this piece. He basically took an eon to say a few simple things.

      Personally, my biggest "wow" moments in my UI learning journey were (1) high-level shading languages (2) physics-based layout (3) true 3D perspective user interfaces (4) data grids that allow you to compose the independent pieces and give the developer control over telling the data grid how to read the data source, such as the Smalltalk Skeleton system and ext Js data grid (5) resolution-independent toolkits like WPF and what a phenomenal time saver that is for freeing you up to focus on just building cool stuff.

      There.

      One paragraph. Or 5 bullet points. However you want to count it.
      • John
         
        Posts: 62 / Nickname: zbo / Registered: January 20, 2007 9:22 AM
        Re: Journey Through Four Interfaces
        December 23, 2010 1:02 PM      
        Actually, I'll add two more:

        1) Using actors to manage the overall orchestration of a front-end GUI to a distributed application
        2) converting the UI description into a dataflow diagram, thus fixing the input-output relation of the system to the history relation of the system, making inplace update of the UI an atomic, cheap, reliable, intercessant operation.
      • C
         
        Posts: 2 / Nickname: easylife / Registered: January 13, 2011 7:44 AM
        Re: Journey Through Four Interfaces
        January 13, 2011 2:01 PM      
        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.
        • John
           
          Posts: 62 / Nickname: zbo / Registered: January 20, 2007 9:22 AM
          Re: Journey Through Four Interfaces
          January 13, 2011 5:03 PM      
          > 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.
          • C
             
            Posts: 2 / Nickname: easylife / Registered: January 13, 2011 7:44 AM
            Re: Journey Through Four Interfaces
            January 18, 2011 5:28 AM      
            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 ?
            • John
               
              Posts: 62 / Nickname: zbo / Registered: January 20, 2007 9:22 AM
              Re: Journey Through Four Interfaces
              January 18, 2011 9:07 AM      
              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...
            • John
               
              Posts: 62 / Nickname: zbo / Registered: January 20, 2007 9:22 AM
              Re: Journey Through Four Interfaces
              January 18, 2011 9:20 AM      
              > 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.