Gosling speaks out on AJAX

Discussions

News: Gosling speaks out on AJAX

  1. Gosling speaks out on AJAX (171 messages)

    In an interview with eWeek, James Gosling speaks out on efforts at Sun to support AJAX. The interview goes deeper in that it explores more of the history of Sun’s adventures with software and James’s views on Sun’s blunders as well as successes in software.

    In the discussion on Javascript, James outlines the difficulties of developing AJAX frameworks.
    Creating them is extremely hard. Not because programming JavaScript is hard, but because all these flavors of JavaScript are ever so slightly different. You have to build your components so that they're adaptable to all the different browsers that you care about. And you have to figure out how to test them. None of the browsers has decent debugging hooks. We could build little things for people where they could test these components.
    In a more candid moment, James reflects on the cost of integrating Berkley Unix with System V. That move marked the end of SunOS and the beginning of the more successful Solaris. James speculated that the move set back the development of the operating system by about 2 years. However Solaris is also praised by James as being the more successful software released by Sun (aside from Java).

    Threaded Messages (171)

  2. Gosling speaks out on AJAX[ Go to top ]

    candied moment
    mmmmmmmm, candied moment.
  3. AJAX and Web 2.0[ Go to top ]

    Some people do and some people talk.

    While you are talking and endless discuss persistent mechanisms and new frameworks Microsoft releases something like Microsoft CRM 3.0 (.NET/C# Web version).

    Why don't you go there and learn?

    You reminds me of Tolstoy’s story about when the "promising violinist turn-to-critics" met the real professional.

    Best regards
    Rolf Tollerud
  4. AJAX and Web 2.0[ Go to top ]

    Some people do and some people talk. While you are talking and endless discuss persistent mechanisms and new frameworks Microsoft releases something like Microsoft CRM 3.0 (.NET/C# Web version).Why don't you go there and learn?You reminds me of Tolstoy’s story about when the "promising violinist turn-to-critics" met the real professional.Best regardsRolf Tollerud

    Hi Rolf !

    How are you ? Good to hear you there. You know what ? I was wondering when you would jump in and give interesting comments. I was sadly thinking you had left TSS forever, but you just prooved me wrong !

    You jumped-in with all the pedagogy we know you are capable and proud of, because being unnecessary pedant is absolutely not your style, as you know that from a pedagogic point-of-view it absolutely disserve one's speech, and only demonstrate the need for the speaker to advertise his supposed superiority, which in turn reveals his low self-confidence (psychology 101 here, you must have some author's reference somewhere in your books, but Dr Freud must have written something somewhere...).

    What a good teacher you must be, your students are certainly hearing your lectures as the sound of a true world class violonist, i wish i could work with you each and everyday it would for sure be enjoyable (to the first, second and any level...) ;o)

    Keep on the good job of making us laugh ! Hopefully it is on purpose... :o)))

    Cheers,

    Christian

    PS : Can you tell us which litterary figure i used to answer here ? 10 more points for you if you do, i do not feel like looking for its name myself ;o)
  5. On the contrary Christian. It is you (the Java community) that make us laugh. The discrepancy between all the high level "computer scientific" lingo in this forum and the look and feel and functionality of a typical Java elephant EJB web application is comical don't you think?

    I beg forgiveness if I was not pedagogical enough I guess I was into the "one picture say more than a thousand word" kind of thing. Maybe you haven't actually seen the application? Observed the beautiful design, elegant in its simplicity and clarity + the fact that the user (with permission) can add, edit or delete fields on almost all the forms as well as construct ad hoc queries? (that little thing would break 90% of all Java frameworks ).

    The novelette I referred to is about a young man that degrade to writing about music instead of doing if what he was talented for. He is quite good at his new profession his speciallity is to rip performers to pieces and make people laugh.

    But the years pass by and one day the little village is visited by a truly word famous violinist. After the concert he goes home and hangs himself.

    I can only hope that the same thing will not happen to you! :)
  6. The novelette I referred to is about a young man that degrade to writing about music instead of doing if what he was talented for. He is quite good at his new profession his speciallity is to rip performers to pieces and make people laugh.But the years pass by and one day the little village is visited by a truly word famous violinist. After the concert he goes home and hangs himself.I can only hope that the same thing will not happen to you! :)
    After reading the title of your post, I must igree with you Rolf: we'd all want to hang ourselves after seeing a MS product! But that's old news... :)

    BTW, welcome back old friend, keep making us laugh!
  7. On the contrary Christian. It is you (the Java community) that make us laugh.
    No worry, i am not the "Java community" ! :o)
    The discrepancy between all the high level "computer scientific" lingo in this forum and the look and feel and functionality of a typical Java elephant EJB web application is comical don't you think?
    Nobody is perfect :o)
    I beg forgiveness
    You are forgiven as far as you continue to make me laugh, and you do, really :o)
    if I was not pedagogical enough I guess I was into the "one picture say more than a thousand word" kind of thing.
    Really depends on the picture...
    Maybe you haven't actually seen the application? Observed the beautiful design, elegant in its simplicity and clarity + the fact that the user (with permission) can add, edit or delete fields on almost all the forms as well as construct ad hoc queries? (that little thing would break 90% of all Java frameworks ).
    This would not break MY framework or the robust ones, and no rocket science in CRUD in Java and .NET, believe me, i wrote a web app template engine using some technologies/tools such as WindowsNT/SQLServer/IIS/ISAPIFIlters/ISAPIDlls/ NetscapeEnterpriseServer/NSApi/ODBC/ C++/STL/HTML/Java/Javascript and PERL for database batch update (no chetaing...), to produce web sites used by mainstream end users back in 1997/1998, to name a relevant experience here, and i have others. .NET is nowhere more advanced then Java for most if not all usage, both are copycat-ing the other's advantage, and .NET has one drawkback (for me and for now) : it is only available on Windows OS, and has very few server side market penetration where i do work... Hence i still stick to Java if possible.
    The novelette I referred to is about a young man that degrade to writing about music instead of doing if what he was talented for. He is quite good at his new profession his speciallity is to rip performers to pieces and make people laugh.But the years pass by and one day the little village is visited by a truly word famous violinist. After the concert he goes home and hangs himself.I can only hope that the same thing will not happen to you! :)
    If i sometime criticise my and others work, these critics are either constructive or jokes. I spend 99% of my working time building robust mission critical server side distributed applications.

    So regarding the self hanging reference don't bet on that, i am not a sarcastic lost young man and i do not play violin (just guitar and drums, and a bit of singing too), which make my daughters believe i am a star in addition to be a computer genius :o)))

    But please Rolf, don't degrade yourself too much up to the point of this poor guy, we would miss you here, at least i would ;o)

    Christian
  8. it is time to wake up[ Go to top ]

    Don't worry about me it is you I am nervous about!

    Have you seen it? (that by the way has 180 000 installations already and is biting Siebel real hard).

    In some months it may be different but right now Microsoft 3.0 CRM application is the state of the art of what is possible to do "over the Web". But I am sure that 99% of the Java consultants have not seen it.

    It is as in the street of the little polish town that Isaac Bashevis Singer mention in one of his books "Where rows upon rows of people spent all their days with mathematical research without reading international magazines and not having any contact whatsoever with other mathematicians in the world".

    Don’t shoot me I am only the messenger. And BTW I was bashed to death the last time I suggested here in TSS that it should be natural and obvious to give the users as much power as possible. Allow the user to change the database structure? Never! "Ad hoc queris?" no no horrible, securuty, security!

    Regards
    Rolf Tollerud
  9. it is time to wake up[ Go to top ]

    Don't worry about me it is you I am nervous about!

    Too kind somebody is worried about me in this world :o)
    Have you seen it? (that by the way has 180 000 installations already and is biting Siebel real hard).In some months it may be different but right now Microsoft 3.0 CRM application is the state of the art of what is possible to do "over the Web". But I am sure that 99% of the Java consultants have not seen it.

    I have not, but will check, thanks for the info :o)
    It is as in the street of the little polish town that Isaac Bashevis Singer mention in one of his books "Where rows upon rows of people spent all their days with mathematical research without reading international magazines and not having any contact whatsoever with other mathematicians in the world".Don’t shoot me I am only the messenger. And BTW I was bashed to death the last time I suggested here in TSS that it should be natural and obvious to give the users as much power as possible. Allow the user to change the database structure? Never! "Ad hoc queris?" no no horrible, securuty, security! RegardsRolf Tollerud

    I don't live in the world of this Isaac guy. And come on, how could i shoot you ? You make me laugh, remember ? :o)
  10. On the contrary Christian. It is you (the Java community) that make us laugh.
    By "us", do you mean the voices in your head? :)
  11. Browser scripting[ Go to top ]

    Javascript is a big hurdle to building rich clients in browsers - it's such an awful language. I played with OpenLazslo recently and it is good but really hamstrung by its use of javascript.

    When are we going to see browser support for better scripting languages? I would kill to see Ruby.
  12. Pluggable client-side scripting languages ... yummm

    ... it would also go a long way to reducing the 'browser differences' problem, since support for the differences would likely drift up into the scipting language implementations themselves, rather than forcing the app developer to deal with them. And it would enable developers to use what they want (JavaScript, Ruby, Python, etc.)

    ... so all we need is a Java-based BSF-style shell that can be installed on any browser, and of course the languages to host under it ... sounds like enough bulk that it would have to be included with the browser distros ... don't want to confront the end-users with having to download languages ...

    At least it's an idea ...
  13. flash-back?[ Go to top ]

    This discussion gives me a flash-back :)

    hint: the one from Adobe/Macromedia
  14. Pluggable client-side scripting languages ... yummm... it would also go a long way to reducing the 'browser differences' problem, since support for the differences would likely drift up into the scipting language implementations themselves, rather than forcing the app developer to deal with them. And it would enable developers to use what they want (JavaScript, Ruby, Python, etc.)... so all we need is a Java-based BSF-style shell that can be installed on any browser, and of course the languages to host under it ... sounds like enough bulk that it would have to be included with the browser distros ... don't want to confront the end-users with having to download languages ...At least it's an idea ...

    It is a good idea, it could also be installable w/o going thru the browser itself (i.e separately downloadble CAB or JAR). But browsers for along time have had the ability install end-user software, code signed and all. As you alude to, they don't like the honking big download, they also don't want to have to trust you in some cases just to run the latest and greatest. And security will be something of a hurdle with regards to how much control they have.

    Alphaworks awhile back had this technology called Direct DOM which allowed you to do browser DOM manipulating via Java
  15. manipulate DOM, and I believe do other Java things as well.
  16. Javascript is a big hurdle to building rich clients in browsers - it's such an awful language. I played with OpenLazslo recently and it is good but really hamstrung by its use of javascript.When are we going to see browser support for better scripting languages? I would kill to see Ruby.
    Let's face it the whole "web app" thing is a horrible kludge. We all know it. At the time it was invented everyone was infected by web fever and busy chasing $$$. The browser wars were not unlike a turf war between rival drug gangs.

    The sad thing is that internet 'application' delivery calls out for a late bound architecture where code (objects) is just another media format replicated, downloaded and shared over the net. Never mind client wars, for this to work we need bit compatible VMs on both client and server, something that will never be achieved based on a paper spec (we are just as capable of producing incompatible implementations of Ruby as we are with javaScript).

    IMO the current state of affairs is an inditement on our industry. Alan Kays says that there is no Software Engineering today and no Computer Science either. Anyone from outer space looking at what passes as web apps today would have to agree.


    The real sad thing is that late binding was delivered in Lisp over 50 years ago and late bound encapsulated objects building upon the ideas in Lisp was delivered with Smalltalk over 30 years ago. Fortunately not everyone is happy to settle for the current status quo. Alan Kay and his gang are busy inventing the future based on the past:

    www.opencroquet.org

    There is an old demo video of Croquet which is pretty impressive, but what is more telling than Croquet itself is what Alan has to say about the last 20-30 years of software history. If you have the time it is well worth watching:

    http://video.google.com/videoplay?docid=-3163738949450782327&q=Croquet

    When are we going to see past short-termism and get a handle on the bigger picture?

    Paul.

    BTW: Croquet is now at release 1.0 and available for download. It's stable and it works so why not check it out.
  17. Gosling speaks out on AJAX[ Go to top ]

    I think it shows yet again that James is really out of touch with what's going on in the technical world.

    The difficulty with AJAX is no longer the various Javascript or browser flavors, which were encapsulated in low-level libraries a looooong time ago. We have moved even further up the stack, with frameworks allowing you to use AJAX without ever seeing a line of JavaScript or even XML (see the various Ruby, PHP, Python and even Java AJAX frameworks).

    The challenge has become, again, user interfaces. AJAX gives a tremendous amount of power to developers, but so far, usability has been very elusive to most of the AJAX-powered Web sites that I visited.

    --
    Cedric
  18. Gosling speaks out on AJAX[ Go to top ]

    Hi Cedric,
    The challenge has become, again, user interfaces.

    I thought this challenged had been solved years ago by Apple...

    The user interface, its look and feel, beauty and usability, greatly depends on the underlying library used to build it, appart from the designer artistic and ergonomic skills of course. I personaly believe that Java Swing library could have provided a more than decent desktop abstraction on top of its widgets, if only Sun would have put to work some talentuous GUI designers at it.

    Why do most java applications do not appear as smooth as proper Windows applications ? As a user, i find both Netbeans and Eclipse to be kind of ugly on my screen, even though more than useful technically speaking.

    It reminds me of my early days of programming, when i designed some pacman style action games : my friends would appreciate to play with them at the begining, but the ugly sprites that i designed myself would move them away after a while. They would prefer to play strip poker programs, maybe for the reward at the end...

    HTML based Ajax success relies partly on the fact that the browser (i.e. Internet Explorer for most people) would render fonts and tables and images perfectly. If java would offer the same ease to use good looking widgets, java applets possibly wired with some scripting language like Groovy or any other, could have taken over HTML + javascript, could'n it ?

    How can someone think of javascript to build a web client or a word processor, while Java would with no doubt offer so much more powerful interaction than HTML + javascript + CSS ? What about GMail in plain java instead of javascript ? But maybe Google engineers are already secretly working on it by now. Sun main target are developers who are/were used to "green screens", while Google customers are more concerned by the attractivity of their screen.

    One of my friends is a talented website and GUI designer at Microsoft, i will suggest him to send a resume to Sun and Eclipse executives :o)

    Christian
  19. Gosling speaks out on AJAX[ Go to top ]

    Why do most java applications do not appear as smooth as proper Windows applications ? As a user, i find both Netbeans and Eclipse to be kind of ugly on my screen

    I don't follow you.
    Eclipse *is* a "proper Windows Application" on your screen.
    The host OS widgets are rendered.

    http://www.eclipse.org/swt/

    -----
    Gustavo.
  20. Gosling speaks out on AJAX[ Go to top ]

    Why do most java applications do not appear as smooth as proper Windows applications ? As a user, i find both Netbeans and Eclipse to be kind of ugly on my screen
    I don't follow you.Eclipse *is* a "proper Windows Application" on your screen.The host OS widgets are rendered.http://www.eclipse.org/swt/-----Gustavo.
    Hi Gustavo,

    I know the difference between Swing and SWT, you just proove my point : you don't see the difference between Eclipse on Windows and Excel on Windows, but believe me the boss assitant does, and i do not even compare with a proper Macintosh application. It is a matter of font choice and size, default colors themes, icons expressiveness, and not having 20+ menu items when i right click on a GUI object. 20+ is really against any ergonomy rule, whatever powerful the software looks like because of the richness of its features.

    I am not a designer, i am a developer, but even though i believe there is a lack of GUI design skills that did and still does count against java, as well as Linux, for mass adoption, to say the least. You will for sure find nice java and linux applications, but this is more often the exception than the rule, at least in my close environment.

    If you do not agree, then maybe you could explain why we see so few applets, and so many Flash applications ? There is no single reason of course, but look at the design of Flash apps, they are absolutely awesome, even for simple form based apps, not talking about the cartoons. Of course Flash framework is very powerful, but so is java. Flash developers usually have very decent design skills (my design skills are close to zero...), which is why they go to Flash and not to java, because they give importance to the picture on the screen. And if you want to attract eyeballs from everyday people, you have to give them appealing look and feel. I am talking about the difference between reading a PDF document and reading a raw text output...

    But if you do not agree with this, i am willing to discuss. Because when i see how uggly javacript + HTML can be, i really think it is a shame that java has not made it to the desktop yet. Even though it is slowly making its way, thanks to Sun and Eclipse/IBM, see the IMB Workplace initiative based on Eclipse :o)

    Christian
  21. Gosling speaks out on AJAX[ Go to top ]

    It is a matter of font choice and size, default colors themes, icons expressiveness, and not having 20+ menu items when i right click on a GUI object. 20+ is really against any ergonomy rule, whatever powerful the software looks like because of the richness of its features.

    I see your point.
    But I don't think it's related to Eclipse being coded in Java and Excel in VC++.
    maybe you could explain why we see so few applets, and so many Flash applications ?

    IMO, it's only becouse of the size of the JRE compared to Flash plugin. You can do wathever Flash do and more with Java2D.

    -----
    Gustavo.
  22. Gosling speaks out on AJAX[ Go to top ]

    You will for sure find nice java and linux applications, but this is more often the exception than the rule, at least in my close environment.
    Agreed again. Linux is another great example of a UI that has been failing for 20 years now.

    I have been using KDE, Gnome, Ubuntu and others for more than two years now, and they all look equally horrible compared to Windows and MacOS. It's not even close.

    Horrible fonts, bad scrolling, painful anti-aliasing, pathetic opaque scrolling, xterms slow as mollasses, mysterious failures even in the main control panels, non-existent possibilities for customization, cryptic CORBA error messages for innocuous GUI operations such as right-clicks, etc...

    Linux on the desktop is just a joke.

    --
    Cedric
  23. Gosling speaks out on AJAX[ Go to top ]

    Linux is another great example of a UI that has been failing for 20 years now.
    Original version of Linx (an *operating system* and not a GUI) was available in 1992-1993. I make that 12-13 yrs of existence. Failing ? define succes and define failure in the context of an operating system
    I have been using KDE, Gnome, Ubuntu and others for more than two years now, and they all look equally horrible compared to Windows and MacOS.
    I've been using KDE for the last 7 yrs and find Windows horrible to work with and look at.
    It's not even close. Horrible fonts, bad scrolling, painful anti-aliasing, pathetic opaque scrolling, xterms slow as mollasses, mysterious failures even in the main control panels, non-existent possibilities for customization, cryptic CORBA error messages for innocuous GUI operations such as right-clicks, etc..
    Referring to GOME/GTK issues I think. Antialiasing works perfect on my KDE setup. Scrolling is fine. Fonts have no problem (other than Windows corporate fonts are not available out of the box, but you can soon import them), and I have no CORBA errors since it's GNOME that gives those out. None of this is anything related to Linux as such, and more to your particular choice of distro and options.
    Linux on the desktop is just a joke
    Linux is an OS. You're referring to primarily GNOME, which has improved much in its most recent version, but KDE has always been way ahead of it. Again many people will totally disagree with you, and I know *many* in that category
  24. Linux Desktop[ Go to top ]

    Horrible fonts, bad scrolling, painful anti-aliasing, pathetic opaque scrolling, xterms slow as mollasses, mysterious failures even in the main control panels, non-existent possibilities for customization, cryptic CORBA error messages for innocuous GUI operations such as right-clicks, etc...

    Maybe it's time for a different distro.
  25. Linux Desktop[ Go to top ]

    Horrible fonts, bad scrolling, painful anti-aliasing, pathetic opaque scrolling, xterms slow as mollasses, mysterious failures even in the main control panels, non-existent possibilities for customization, cryptic CORBA error messages for innocuous GUI operations such as right-clicks, etc...
    Maybe it's time for a different distro.

    But what I don't understand, he said he uses Ubuntu and I have never gotten this sort of problems. GNOME has made a lot of progress in the last years. I switched to Linux 3 months ago and I was a bit afraid of missing some parts of Windows but honestly the UI is way better then Windows and I don't miss it at all.
  26. Linux Desktop[ Go to top ]

    Maybe it's time for a different distro.
    I've been hearing this argument for 15+ years now, although when I started using Linux around 1990, it was "time for a different kernel".

    I say "time for a different OS" :-)

    --
    Cedric
  27. Linux Desktop[ Go to top ]

    I've been hearing this argument for 15+ years now, although when I started using Linux around 1990
    In which case all we do is bow down to your foresight since it was only ever published in its Minix form in Aug 1991. Yesterday it was 20+ yrs, today it's 15+ yrs, ...
  28. nitpicking[ Go to top ]

    you do realize javier, that this is the guy who built weblogic's ejb engine, right? remind me again, what have you built?
  29. nitpicking[ Go to top ]

    you do realize javier, that this is the guy who built weblogic's ejb engine, right? remind me again, what have you built?

    Which makes him an expert on usability? :)
  30. nitpicking[ Go to top ]

    you do realize javier, that this is the guy who built weblogic's ejb engine, right? remind me again, what have you built?
    Which makes him an expert on usability? :)
    I do have a few usability credentials, but let's leave that aside for now. Why don't you address what I wrote instead of focusing on me?

    --
    Cedric
  31. nitpicking[ Go to top ]

    you do realize javier, that this is the guy who built weblogic's ejb engine, right? remind me again, what have you built?
    Which makes him an expert on usability? :)
    I do have a few usability credentials, but let's leave that aside for now. Why don't you address what I wrote instead of focusing on me?-- Cedric

    I addressed the remark that other guy made about you having built an ejb engine. Which has nothing to do with whether you are an expert on the field of usability. I'm sure you have usability credentials. I have none.

    One thing I'm wondering is whether the usability experts out there are really aligned? Usability/ user interface design seems to be just as heaviliy debated as for instance programming language paradigms. What in your opinion is an example of an application/ (OS?) that totally gets it right?
  32. nitpicking[ Go to top ]

    I do have a few usability credentials, but let's leave that aside for now. Why don't you address what I wrote instead of focusing on me?-- Cedric

    Hi Cedrix,

    Because this thread is a water-cooler ;o)

    By the way, have you moved to Google ?

    Cheers,

    Christian
  33. Linux Desktop[ Go to top ]

    I've been hearing this argument for 15+ years now, although when I started using Linux around 1990
    In which case all we do is bow down to your foresight since it was only ever published in its Minix form in Aug 1991. Yesterday it was 20+ yrs, today it's 15+ yrs, ...
    Ooh, I was off one year, I humbly apologize.

    Back then, I was helping fix bugs in the NFS drivers which, would you believe it, were corrupting random bytes here and there.

    Am I forgiven?

    --
    Cedric
    who used Minix as well (on floppy disks!)
  34. Gosling speaks out on AJAX[ Go to top ]

    Flash-based user interfaces do look better, but I haven't seen a single website where it is done right. For some reason, Flash developers think very differently on usability. Just flashy graphics and nice looking pages are not necessarily usable, so by considering the end result, I would consider a Flash-based UI to be as bad as an Applet-based.

    Peace.
  35. Gosling speaks out on AJAX[ Go to top ]

    Flash-based user interfaces do look better, but I haven't seen a single website where it is done right. For some reason, Flash developers think very differently on usability. Just flashy graphics and nice looking pages are not necessarily usable, so by considering the end result, I would consider a Flash-based UI to be as bad as an Applet-based.Peace.

    Technology aside-- the medium of the web does require you to simplify things a bit, which results in simpler/easier to use interfaces. So, in the case of AJAX use, either you can start to do hidden, flyout, drop down menus w/ combo buttons and really "interesting" interactions, *or* simply enhance the responsiveness of familiar interactions.

    Maybe it's just that the HTML medium is abstract and obtuse in a developer's hands such that familiarity and simplicity can get thrown out the window fairly easily with these new technologies. I think technologies like XUL would be more suited since their semantic foundation already matches what's found in most desktops-- but the danger is always there that developers will shoot for the sky in a frankenstein attempt at making something 'flashy'.
  36. Gosling speaks out on AJAX[ Go to top ]

    Flash-based user interfaces do look better, but I haven't seen a single website where it is done right. For some reason, Flash developers think very differently on usability. Just flashy graphics and nice looking pages are not necessarily usable, so by considering the end result, I would consider a Flash-based UI to be as bad as an Applet-based.Peace.
    Technology aside-- the medium of the web does require you to simplify things a bit, which results in simpler/easier to use interfaces. So, in the case of AJAX use, either you can start to do hidden, flyout, drop down menus w/ combo buttons and really "interesting" interactions, *or* simply enhance the responsiveness of familiar interactions.Maybe it's just that the HTML medium is abstract and obtuse in a developer's hands such that familiarity and simplicity can get thrown out the window fairly easily with these new technologies. I think technologies like XUL would be more suited since their semantic foundation already matches what's found in most desktops-- but the danger is always there that developers will shoot for the sky in a frankenstein attempt at making something 'flashy'.

    Well the main problem is, that people expect the interactivity of a rich client app in a webapp, and often especially with people who do not know the limits of the medium they do not except a no. I will give you an example a customer wants a very complex calendar, you offer him something with roundtrips, he demands that the calendar must be fully interactive, you offer him applets or flash, he demands it you have to deliver it in html because it must be a browser at all costs, you say no, he says that he has seen that it is possible on google.

    You sometimes are not in the position to say no, because you are not a decision maker.
    You have the option either drop out of the project or say yes and end up in a hell you never wanted to enter. In the end mostly the customer is dissatisfied, because the control has to mess around with the dom hugely and even if it works as standalone, they try to press it in a complicated layout and it ends up messing up parts of the layout or vice versa. You are almost freaking out because going through this DHTML cross browser hell is dreadful and the calendar does only parts of what google does.

    Sure there maybe options to buy such a thing but often it has to be that much customized that you either end up doing it yourself or you have to start from an opensource base, which eases things but does not relieve you from this hell.

    This is not something abstract happening, you can see that happen in projects every day, where someone is the poor guy having to do such things because the so called deicision makers do not listen to sane arguments from people who know the technology in and out.
  37. Gosling speaks out on AJAX[ Go to top ]

    Flash-based user interfaces do look better, but I haven't seen a single website where it is done right. For some reason, Flash developers think very differently on usability. Just flashy graphics and nice looking pages are not necessarily usable, so by considering the end result, I would consider a Flash-based UI to be as bad as an Applet-based.Peace.

    i agree with you, at first it looks nice but soon it gets annoying to wait for moving stuff. I think the richness of the widgets is not so important. Response time and component based approach are. eg Tree widgets seem sophisticated but they are not. Trees are bad , flat view and searching is OK. The eclipse configuration screen is a perfect example of how great it is to search flat and have the result presented as a tree. For all i care they ditch the whole tree as well. Just give me a search box and a resulting listview and i am happy. As a programmer though i love to make very deeply nested tree structures, the deeper the better, look ma without any effort i just need to know the parent, it is in a way still magic. I think that is a problem we should be aware of. Programmers like complex widgets, end-users love simplicity.
  38. Gosling speaks out on AJAX[ Go to top ]

    Programmers like complex widgets, end-users love simplicity.

    Dennis,

    We finally agree ! Alleluhia !

    By the way i am a programer, have been for the past 15+ yeras, sono offense for programers here. Just my sense of humour :o)

    Cheers,

    Christian
  39. flash uber alles[ Go to top ]

    Just flashy graphics and nice looking pages are not necessarily usable, so by considering the end result, I would consider a Flash-based UI to be as bad as an Applet-based.Peace.

    too bad you're not "most" people...nice flashy graphics sells. end of story.

    this thinking in java land is what got applets languishing in the desktop.

    and if sun doesn't watch it, flash could make the same inroads in small devices.
  40. flash uber alles[ Go to top ]

    Just flashy graphics and nice looking pages are not necessarily usable, so by considering the end result, I would consider a Flash-based UI to be as bad as an Applet-based.Peace.
    too bad you're not "most" people...nice flashy graphics sells. end of story.this thinking in java land is what got applets languishing in the desktop.and if sun doesn't watch it, flash could make the same inroads in small devices.

    I don't agree. Flashy make people try and take a look at the product. Usability and ergonomy make them stick with it.
  41. Gosling speaks out on AJAX[ Go to top ]

    ...then maybe you could explain why we see so few applets, and so many Flash applications ? There is no single reason of course...

    Well I'd say 99% of it is that you don't have to code much to make a really nice Flash application. Macromedia put a ton of effort into making an IDE that an art student could work with but still made Flash powerful enough so that you could do almost anything you wanted with the scripting language.

    Yeah, I'm sure you could do the same thing with Java 2D or any other low-level graphics library but not nearly as fast or easy.
                           
    Even if some sane person decided you don't need the entire JDK to run applets and put out a browser-friendly-JVM it would still be a ton of boilerplate code just to render a simple form.

    Of course it would be fun to see IntelliJ's take on the graphical design interface.
  42. Gosling speaks out on AJAX[ Go to top ]

    Hi George,
    Well I'd say 99% of it is that you don't have to code much to make a really nice Flash application. Macromedia put a ton of effort into making an IDE that an art student could work with but still made Flash powerful enough so that you could do almost anything you wanted with the scripting language.

    Agreed, and hopefully we will see Sun and IBM/Eclipse put more effort towards client side java, which includes nice library of smooth widget as well as nice IDE builder such as Matisse.

    Cheers,

    Christian
  43. Gosling speaks out on AJAX[ Go to top ]

    Hi Cedric,
    The challenge has become, again, user interfaces.
    I thought this challenged had been solved years ago by Apple...
    Apple makes pretty interfaces, but they're not significantly more usable than Windows or others.
    The user interface, its look and feel, beauty and usability, greatly depends on the underlying library used to build it, appart from the designer artistic and ergonomic skills of course. I personaly believe that Java Swing library could have provided a more than decent desktop abstraction on top of its widgets, if only Sun would have put to work some talentuous GUI designers at it.
    Agreed.

    I think Swing's philosophy (reimplementing the look and feel in Java) is also to blame and is the reason why Swing applications always stand out, and not in a good way. Do they still have this bug where RETURN and ESC still can't be used to dismiss dialogs? How many years did it take to fix it?
    Why do most java applications do not appear as smooth as proper Windows applications ? As a user, i find both Netbeans and Eclipse to be kind of ugly on my screen, even though more than useful technically speaking.
    Agreed again, but be prepared to get flamed for saying that :-)

    --
    Cedric
  44. I dont see the point about the eclipse or netbeans UI. As you say, they are both "more than useful technically speaking".

    What I require in addition is that they enable me to create slick, perfectly OS-integrated applications for end-users (if that is my target audience). Eclipse/SWT gets me pretty far on that way.
    I am sure your friend can find a better challenge for his GUI skills than getting in the way of a bunch of developers
  45. I dont see the point about the eclipse or netbeans UI. As you say, they are both "more than useful technically speaking". What I require in addition is that they enable me to create slick, perfectly OS-integrated applications for end-users (if that is my target audience). Eclipse/SWT gets me pretty far on that way. I am sure your friend can find a better challenge for his GUI skills than getting in the way of a bunch of developers

    Christian,

    Look and feel is of course a matter of feeling, but i when i right click on an eclipse resource and have a drop down menu of more than 20 elements, more than half of them not applicable to this element, i believe it is bad design, i am talking here from an ergonomy point of view. Why is the "Run as/Rnu as Applet" contextual menu available where in no way i am designing and Applet ? Ok, i can dismiss it, but it would not be there i would not have to dismiss it. This is all what ergonomy is.

    For this particular reason, i am giving a try to Netbeans, hopefully i will be more productive event when i am tired at the end of a hard working day.

    I do also have another example : Microsoft OutlookExpress versus Mozilla Thunderbird. I tried to have my ex wife switch from OutlookExpress to Thunderbird, she could not hold it for more than a few minutes and got back to OutlookExpress. Even though Thunderbird functionnalities are way more powerful as she admitted, as she liked the abstract folders for instance, she still prefers to use OutlookExpress for its smooth appareance on the screen, believe it or not. And don't say it is because she is my ex wife ;o)

    Ergonomy and graphical design are real disciplines, and skilled persons need to work on software GUI to make it appealing to everyday people.

    But as a matter of fact, things are getting better, only too slowly from my point of view.

    Cheers,

    Christian
  46. Christian,Look and feel is of course a matter of feeling, but i when i right click on an eclipse resource and have a drop down menu of more than 20 elements, more than half of them not applicable to this element, i believe it is bad design
    Actually, the general agreement is that showing greyed out items is better than the alternative (not showing them) because then, the menus look like they are constantly changing and you can no longer rely on the item you need to be physically located at the same place.

    If you're not convinced, try turning on Windows "smart menus", which shuffle the menu items around based on how often you use them, and I guarantee that after ten minutes, you will want to throw your mouse out of the window (which is a bad idea, unless it's wireless).
    Ergonomy and graphical design are real disciplines, and skilled persons need to work on software GUI to make it appealing to everyday people.
    Exactly. And this is why Linux's various window managers have always been, and still are, a joke.

    --
    Cedric
    TestNG
  47. If you're not convinced, try turning on Windows "smart menus", which shuffle the menu items around based on how often you use them, and I guarantee that after ten minutes, you will want to throw your mouse out of the window (which is a bad idea, unless it's wireless).

    Cedric,

    I do have smart menus turned on, and i am happy with it. After a while (more than 10 minutes), your menus do not shuffle around that much ;o)

    Anyway, there is some research on next generation of window managers, and i remember one without windows (page oriented one could say) that really amazed me. I try to find the reference and post it back here.

    Part of the beauty was in the color scheme and the fonts default choice :o)

    Cheers,

    Christian
  48. I dont see the point about the eclipse or netbeans UI. As you say, they are both "more than useful technically speaking". What I require in addition is that they enable me to create slick, perfectly OS-integrated applications for end-users (if that is my target audience). Eclipse/SWT gets me pretty far on that way. I am sure your friend can find a better challenge for his GUI skills than getting in the way of a bunch of developers
    Christian,Look and feel is of course a matter of feeling, but i when i right click on an eclipse resource and have a drop down menu of more than 20 elements, more than half of them not applicable to this element, i believe it is bad design, i am talking here from an ergonomy point of view. Why is the "Run as/Rnu as Applet" contextual menu available where in no way i am designing and Applet ?

    Isn't this one of Eclipse strongness and the concept behind perspective? If you had said Word, I would have agreed, the menu are so long but Eclipse ? Really I don't understand what you are talking about.
  49. Isn't this one of Eclipse strongness and the concept behind perspective? If you had said Word, I would have agreed, the menu are so long but Eclipse ? Really I don't understand what you are talking about.

    Hi Alexandre,

    Are we using the same Eclipse distribution ? I am talking about the java perspective, when you are right-clicking on a class or file resource. How many items do you have ?

    Anyway if 20+ contextual menu items is ok for you, it is not for me, nor for the majority of people out there using a computer. And i really insist about the importance of ergonomy.

    Cheers,

    Christian
  50. Isn't this one of Eclipse strongness and the concept behind perspective? If you had said Word, I would have agreed, the menu are so long but Eclipse ? Really I don't understand what you are talking about.
    Hi Alexandre,Are we using the same Eclipse distribution ? I am talking about the java perspective, when you are right-clicking on a class or file resource. How many items do you have ?Anyway if 20+ contextual menu items is ok for you, it is not for me, nor for the majority of people out there using a computer. And i really insist about the importance of ergonomy.Cheers,Christian

    Hi

    If they all relate to what I am doing at the moment and they disable the one I can't use at a given time, yes I really like it. If it doesn't relate to what I do, I hate it. For instance, I don't like how Word hides what he thinks you will rarely use, really annoys me to no end even if it is configurable. Having been obliged to work with some other IDEs in the past which I won't mention to not start a flame war (it wasn't IDEA of course) where I had to deal with version control, ant, java, db, ... all at the same time, I can say I am enjoying Eclipse right now.

    I prefer the perspective concept which change the menu and the toolbar based upon the type of task you are doing and not a *stupid* popularity algorithm. If you look at Eclipse populary I am probably not the only one but I think usually people really LOVE or totally HATE Eclipse. From what I remember Eclipse is the realization of severals years of researches on UI but I could be wrong.

    And where I work, the *UI guy* (I think he's really great in ergonomy but that's a personal opinion) which has absoluty no knowledge in Java and in programming in general totally love the perspective concept and use Eclipse to edit his CSS. Well honestly I was surprised when he said he liked the tool I was using to program. Just yesterday, he told me he had gone to a conference on UI design patterns in Montreal last weekend and all people were really praising the Eclipse perspective concept. Anyway I guess it is just a personal preference. But I was surprised to read your complaint against Eclipse because usually those are refered as being its strongnesses.
  51. Alexandre,

    I have been using Eclipse sometimes 10 hours a day for the last 2 years, and the perspective concept is brilliant for sure. I appreciate the concept 200%.

    What i am complaining about is the contextual right-click menu with 20+ items in the java perspective, the one i use most, but maybe you are not using this right click menu, or you are satisfied with it. I am not, and i will very seriously take a look at netbeans over the next months.

    As a sample, i would prefer the "Run" and "Debug" contextual menus disappear, i can still use keyboard shortcut to run or debug. It would save some items on this menu.

    Cheers,

    Christian
  52. Alexandre,I have been using Eclipse sometimes 10 hours a day for the last 2 years, and the perspective concept is brilliant for sure. I appreciate the concept 200%.What i am complaining about is the contextual right-click menu with 20+ items in the java perspective, the one i use most, but maybe you are not using this right click menu, or you are satisfied with it. I am not, and i will very seriously take a look at netbeans over the next months.As a sample, i would prefer the "Run" and "Debug" contextual menus disappear, i can still use keyboard shortcut to run or debug. It would save some items on this menu.Cheers,Christian

    I see then. I guess maybe I don't use the contextual menu that much but I think I use it. I also use the standards menus quite a lot. I haven't had a problem with it except maybe the run menu like you said but it is just one bad case in a very good UI if you ask me.

    Well I didn't get that you were only speaking about contextual menus, I thought you were giving more of an example. By the way, isn't it configurable?
  53. I see then. I guess maybe I don't use the contextual menu that much but I think I use it. I also use the standards menus quite a lot. I haven't had a problem with it except maybe the run menu like you said but it is just one bad case in a very good UI if you ask me. Well I didn't get that you were only speaking about contextual menus, I thought you were giving more of an example. By the way, isn't it configurable?

    Yes the contextual menu is just an example, but considering that i do use the right click action as much as i can in any application it is more than annoying me, it really slows me down in my everyday work. Personal experience of course, i believe tight click is the best invention in GUI after the window concept itself, it saves me from reading the user manual :o)

    You are right, i will take a look at the possible configurations, maybe it is easily customisable.

    Cheers,

    Christian
  54. I am sure your friend can find a better challenge for his GUI skills than getting in the way of a bunch of developers

    My friend is very successful at designing websites and applications professionally speaking, maybe some people do see interest in appealing desktop applications :o)

    By the way he has been a competent C,C++ and java developer working for Boeing before doing fulltime GUI design as he has impressive design skills, and by now prefers this discipline to coding. He is never "in the way of developers", they are working altogether, and are very happy about the mutual cooperation...

    Cheers,

    Cristian
  55. Gosling speaks out on AJAX[ Go to top ]

    Why do most java applications do not appear as smooth as proper Windows applications ? As a user, i find both Netbeans and Eclipse to be kind of ugly on my screen, even though more than useful technically speaking.

    hehe Christian, I should introduce you to Idea, a better programming environment :o)

    Ok, the splash screen is not as sexy as it used to be :o(

    a++ Cedric
  56. Gosling speaks out on AJAX[ Go to top ]

    hehe Christian, I should introduce you to Idea, a better programming environment :o)Ok, the splash screen is not as sexy as it used to be :o(a++ Cedric

    Hi Cedric,

    For the relaxing sexy screen i prefer my girlfriend's picture as a wallpaper :o)

    I think i will begin to write my own code generator based on my personal framework, so i can stick with JEdit foerever as classes should always be readable/maintainable with this simple powerful tool ;o)

    Cheers,

    Christian

    PS : How many French engineers in Google ? Still hiring ? :o)
  57. Gosling speaks out on AJAX[ Go to top ]

    hehe Christian, I should introduce you to Idea, a better programming environment :o)Ok, the splash screen is not as sexy as it used to be :o(a++ Cedric
    Hi Cedric,For the relaxing sexy screen i prefer my girlfriend's picture as a wallpaper :o)I think i will begin to write my own code generator based on my personal framework, so i can stick with JEdit foerever as classes should always be readable/maintainable with this simple powerful tool ;o)Cheers,ChristianPS : How many French engineers in Google ? Still hiring ? :o)
    Actually, this message came from a different Cedric...

    --
    Cedric
  58. Gosling speaks out on AJAX[ Go to top ]

    Why do most java applications do not appear as smooth as proper Windows applications ? As a user, i find both Netbeans and Eclipse to be kind of ugly on my screen, even though more than useful technically speaking.
    hehe Christian, I should introduce you to Idea, a better programming environment :o)Ok, the splash screen is not as sexy as it used to be :o(a++ Cedric

    Salut Cédric !

    Comment vas-tu ? Bon on déjeune ensemble un de ces midis ? ;o)

    For the other Cedric : Désolé, un homonyme avec qui j'ai eu le loisir de travailler :o)

    Cheers,

    Christian
  59. Gosling speaks out on AJAX[ Go to top ]

    I think it shows yet again that James is really out of touch with what's going on in the technical world.The difficulty with AJAX is no longer the various Javascript or browser flavors, which were encapsulated in low-level libraries a looooong time ago. We have moved even further up the stack, with frameworks allowing you to use AJAX without ever seeing a line of JavaScript or even XML (see the various Ruby, PHP, Python and even Java AJAX frameworks).The challenge has become, again, user interfaces. AJAX gives a tremendous amount of power to developers, but so far, usability has been very elusive to most of the AJAX-powered Web sites that I visited.-- Cedric

    Actually Goslin is not out of touch, the libraries even some of the constant problems you have with browser, the main problems are still there, the reason is, the libraries cannot cover every ground which is broken and from time to time you have to do your own stuff and you cannot rely on libs.
    Javascript DHTML programming still is something straight invented in hell, if you ask me. But it seems to be the way of the world that always the worst technologies are adapted for mass use.
    It happend with dos, Windows, HTML and now Javascript/DHTML for user interfaces.
  60. Gosling speaks out on AJAX[ Go to top ]

    Actually Goslin is not out of touch, the libraries even some of the constant problems you have with browser, the main problems are still there, the reason is, the libraries cannot cover every ground which is broken and from time to time you have to do your own stuff and you cannot rely on libs.Javascript DHTML programming still is something straight invented in hell, if you ask me. But it seems to be the way of the world that always the worst technologies are adapted for mass use.It happend with dos, Windows, HTML and now Javascript/DHTML for user interfaces.

    whether James Gosling is out of touch or not is not my thing, but the rest of this post deserves a +1 imo. this covers a lot the day to day problems of a developer/html producer.

    .. and linux is not a window manager ... very disapointing.

    roman sykora
  61. Gosling speaks out on AJAX[ Go to top ]

    I think it shows yet again that James is really out of touch with what's going on in the technical world.The difficulty with AJAX is no longer the various Javascript or browser flavors, which were encapsulated in low-level libraries a looooong time ago. We have moved even further up the stack, with frameworks allowing you to use AJAX without ever seeing a line of JavaScript or even XML (see the various Ruby, PHP, Python and even Java AJAX frameworks).The challenge has become, again, user interfaces. AJAX gives a tremendous amount of power to developers, but so far, usability has been very elusive to most of the AJAX-powered Web sites that I visited.-- Cedric
    Actually Goslin is not out of touch, the libraries even some of the constant problems you have with browser, the main problems are still there, the reason is, the libraries cannot cover every ground which is broken and from time to time you have to do your own stuff and you cannot rely on libs.Javascript DHTML programming still is something straight invented in hell, if you ask me. But it seems to be the way of the world that always the worst technologies are adapted for mass use.It happend with dos, Windows, HTML and now Javascript/DHTML for user interfaces.
    I agree. A lot of web sites are not correctly working if you are not using Internet Explorer, due to Javascript problems. If libraries can help,
    the problem remains.
    Regarding Ajax, I have been using Gmail and other Google stuff for a while and I have noticed that this technology is not mature : sometimes everything seems blocked (even with a high speed connection) and some stuff don't work with my Internet Explorer or our firewall settings. Ajax is very interesting and allow developpers to do stuffs they were dreaming. But it has to evolve. Maybe a new generation of browsers?
  62. Gosling speaks out on AJAX[ Go to top ]

    I think it shows yet again that James is really out of touch with what's going on in the technical world.The difficulty with AJAX is no longer the various Javascript or browser flavors, which were encapsulated in low-level libraries a looooong time ago. We have moved even further up the stack, with frameworks allowing you to use AJAX without ever seeing a line of JavaScript or even XML (see the various Ruby, PHP, Python and even Java AJAX frameworks).The challenge has become, again, user interfaces. AJAX gives a tremendous amount of power to developers, but so far, usability has been very elusive to most of the AJAX-powered Web sites that I visited.-- Cedric
    Actually Goslin is not out of touch, the libraries even some of the constant problems you have with browser, the main problems are still there, the reason is, the libraries cannot cover every ground which is broken and from time to time you have to do your own stuff and you cannot rely on libs.Javascript DHTML programming still is something straight invented in hell, if you ask me. But it seems to be the way of the world that always the worst technologies are adapted for mass use.It happend with dos, Windows, HTML and now Javascript/DHTML for user interfaces.

    Agreed!
    That's the only thing I am looking forward about Microsoft XAML : push forward XUL integration which would be much much better then AJAX. Honestly, XUL is such a beautiful technology that has been around for a couple of years now and we are still stuck using Javascript/DHTML...

    And component-oriented frameworks like JSF, Tapestry or Wicket, allow you to support seamlessly XUL and XHTML quite easily. Even if I don't buy the marketing stuff saying you use the same exact page for both, you still only have to make two set of pages while you can leverage the same UI components throught different renderers.
  63. Client UI using SVG[ Go to top ]

    The challenge has become, again, user interfaces. AJAX gives a tremendous amount of power to developers, but so far, usability has been very elusive to most of the AJAX-powered Web sites that I visited.-- Cedric

    I'd like to see a UI toolkit that renders using SVG. That would give specialist UI designers much more freedom to create really usable interfaces, and good-looking too, rather than being confined to the lowest common denominator grey dialog components the whole time.

    Maybe base it on XUL, with CSS to style, then convert to SVG using pluggable component transformations, so eg. a <button> could be rendered using standard grey, pink oval, or some random freehand shape, with fancy behaviour to match.

    And all running in the browser. I believe the Adobe SVG Viewer plugin has (or maybe will soon have) pluggable scripting language support.

    Kit
  64. I suppose it depends on your design goals, but Wicket does an awful lot transparently. It pushes AJAX behind the scenes by supporting seamless, batched, partial component updates without a single line of JavaScript for the end-user. Check out some running examples with source code:

    http://www.wicket-library.com/wicket-examples/ajax

    And if all your AJAX component does is redraw after processing an event on the server side (the most common case), that is JavaScript-free too.
  65. Would be neat if there was a tiny plugin (small download) that was a stripped down VM (KVM? J2ME?) for client side DOM stuff. It would sub for JavaScript and abstract the DOM and events and objects in an API like AWT. That would be a neat trick because you could code AJAX in pure Java and stop thinking about JavaScript entirely. Yucky project but could be a neat thing for Sun.

    In general, it seems to me that using JavaScript for much more than plumbing like updating components in Wicket is going to be a total nightmare no matter how much work you sink into some generic "framework".
  66. Just the beginning...[ Go to top ]

    I think we’ve just started to see the beginning of rich web interfaces so things now are more flashy and do not really add a lot of value in terms of being more productive.

    We’ve used Ajax to re-implement what were previously fat client apps built 20 years ago for one of the French Ministries. A simple thing like having three pageable, sortable lists on the same web page is a lot easier with Ajax than if you refresh the whole page(and all three lists) every time you sort one of the lists. This for me is a typical example of web2.0 type interface whereas a web1.0 interface would have had one list per web page which would increase the number of clicks to see the same amount of information.

    My blog for more thoughts on this :) (http://leespot.blogspot.com)
  67. Gosling speaks out on AJAX[ Go to top ]

    Really, I'm surprised anybody actually listens to this guy anymore, I mean this guy couldn't even understand Uniform Access when he designed Java.
  68. Gosling speaks out on AJAX[ Go to top ]

    You just lost about 99% of your credibility. You seriously think James /didn't understand/ this? Yes, he chose not to do it. But that's different from not understanding it. There are all kinds of compromises necessary in doing anything significant like Java. James was well-known before Java (Emacs, NeWS and more). Java may not be perfect, but it changed the world. Fancy handwaving aside, what exactly have you done that's so great?
  69. AJAX = Workaround[ Go to top ]

    It will always be dificult to create AJAX frameworks. AJAX will always be a workaround for the lack of support and standarization for Rich Internet Apps (RIAs) with the current web tech trinity (Browser/HTML/HTTP).

    The time and effort to give more and more support to AJAX should better be focused on bringing the next standard for RIAs. I guess the best start point is XUL or XAML...

    The browser at the end should not be used to launch a RIA although they could support the new standard.
  70. AJAX = Workaround[ Go to top ]

    It will always be dificult to create AJAX frameworks. AJAX will always be a workaround for the lack of support and standarization for Rich Internet Apps (RIAs) with the current web tech trinity (Browser/HTML/HTTP). The time and effort to give more and more support to AJAX should better be focused on bringing the next standard for RIAs. I guess the best start point is XUL or XAML... The browser at the end should not be used to launch a RIA although they could support the new standard.

    I agree with you here, we need something saner than dhtml. But the main problem always comes down to browsers.

    We have had a good rich internet client technology for years, we have had now for years xul, and we have had svg as open standard for vector graphics and animation. Now we have an opera which does not support xul, we have an ie, where Microsoft does not have any intention ever to support xul and svg, in both cases they forked the standards put their stuff in and broke them deliberately.

    And we have applets and flash which everyone hates, although applets would be the ideal platform for rich client user interfaces, but Microsoft managed sucessfully to torpedo java in the client arena.

    So what are we going to end with. For now, dhtml is the most cross browserable solution we have, although it is severely broken by lots of issues, one being huge incompatibilites in several key areas.
    We have xul which runs on mozilla only, we will get xaml which will be a patent plastered Microsoft fork of xul, and we will end up with what opera khtml and others will come up with on their side.
    So what are we going to end up with in the long run will be again, bridging frameworks, like we have them today (Qt is the perfect example) which try to iron out the incompatibilities.
    If you think that action oriented page centrics are the frameworks are the future in the long run forget it. The whole www just currently follows the transition which desktop applications did in the early eighties, and it seems that the same mistakes are made again, where money and market influence destroys the first chance in a long time to unify all this stuff towards something sane. In the end this will be a lot of jobs for people for decades who have to work on ironing out all this which never should be introduced at all upfront, but while the 80s split of user interfaces was due to different technologies and platforms, the 2000s split of html user interface technologies is just out of pure greed where the world will have to pay the price for in the long run.
  71. flash, not microsoft[ Go to top ]

    And we have applets and flash which everyone hates, although applets would be the ideal platform for rich client user interfaces, but Microsoft managed sucessfully to torpedo java in the client arena.

    sun and flash helped stop the spread of good applets...microsoft just helped. just comparing the startup of applets and flash one can see that the flash experience is better...plus, sun forgot to target website designers, who steamrolled flash into the mainstream.
  72. flash, not microsoft[ Go to top ]

    And we have applets and flash which everyone hates, although applets would be the ideal platform for rich client user interfaces, but Microsoft managed sucessfully to torpedo java in the client arena.
    sun and flash helped stop the spread of good applets...microsoft just helped. just comparing the startup of applets and flash one can see that the flash experience is better...plus, sun forgot to target website designers, who steamrolled flash into the mainstream.

    I agree to an extent-- we can do all of this marvelous stuff with AJAX and DHTML, but Flash and Swing are a whole different ballpark. The problem with Flash is that aside from Flex, developing customized components is still done like you are editing a movie, a major drawback in programmer adoption for application development.
  73. flash, not microsoft[ Go to top ]

    And we have applets and flash which everyone hates, although applets would be the ideal platform for rich client user interfaces, but Microsoft managed sucessfully to torpedo java in the client arena.
    sun and flash helped stop the spread of good applets...microsoft just helped. just comparing the startup of applets and flash one can see that the flash experience is better...plus, sun forgot to target website designers, who steamrolled flash into the mainstream.
    I agree to an extent-- we can do all of this marvelous stuff with AJAX and DHTML, but Flash and Swing are a whole different ballpark. The problem with Flash is that aside from Flex, developing customized components is still done like you are editing a movie, a major drawback in programmer adoption for application development.

    The main hurdle for Applets was the main hurdle for every other plugin outside of flash. It was not bundled with Windows in a proper way, sure there was the MicrosoftVM, which was stuck at the level of 1997 and getting the users to have java on their machines gave it the rest.
    Add to that inherent problems with the java plugin up until now (crashing browsers even in 2005, startup failures) and the somewhat inherent long loading times of java as is and you have the reasons why the generally excellent concepts of applets never took off. The role of Microsoft in this cannot be underestimated, they basically worked actively against this nasty thing which could shake their monopoly, as much as they worked against a unified html dom whatever. They are one of the core reasons why we all are in this mess, while on paper everything looks bright and happy.
  74. flash, not microsoft[ Go to top ]

    And we have applets and flash which everyone hates, although applets would be the ideal platform for rich client user interfaces, but Microsoft managed sucessfully to torpedo java in the client arena.
    sun and flash helped stop the spread of good applets...microsoft just helped. just comparing the startup of applets and flash one can see that the flash experience is better...plus, sun forgot to target website designers, who steamrolled flash into the mainstream.
    I agree to an extent-- we can do all of this marvelous stuff with AJAX and DHTML, but Flash and Swing are a whole different ballpark. The problem with Flash is that aside from Flex, developing customized components is still done like you are editing a movie, a major drawback in programmer adoption for application development.

    I dont think that Ajax and DHTML are marvellous, they are as usual with most web stuff broken designs driven mainly by marketing. Ajax is nice, but it ends with its asynchronoty once the request is back. Javascript is broken by design due to its lack of threading which for real rich clients is mandatory. DOMs is broken due to various browser incompatibilities, and the whole DHTML design is broken in and out for real user interfaces due to its kludge design which omits the experiences gathered on how to program user interfaces since the the good old smalltalk days.
    It is a wonder perse that with the current state of affairs something is possible at all.
  75. Java wasn't up to the Job[ Go to top ]

    It is a wonder perse that with the current state of affairs something is possible at all.
    Ditto.

    Someone mentioned applets before. The Engineers at Sun knew that Java wasn't up to late bound distributed objects. They wanted to fix the problems but the marketing guys wouldn't let them, Java was out the door.

    So what happens when you use a language designed for toasters as the backbone for distributed internet applications? It doesn't work. Even if Java was up to the job (which it isn't because it lacks late binding), basing JVM implementations on a paper spec is a sure fire way to create incompatiblities. I remember that early versions of the JVM from Sun where incompatible with each other (platform specific threading) never mind achieving bit compatibility with JVM implementations from other vendors.

    BTW. What happend to JINI and JavaSpaces? I think Java self imploded here too.

    It's all wrong, all rushed, all short-term, and all driven by marketing.

    Paul.
  76. Java wasn't up to the Job[ Go to top ]

    It is a wonder perse that with the current state of affairs something is possible at all.
    Ditto.Someone mentioned applets before. The Engineers at Sun knew that Java wasn't up to late bound distributed objects. They wanted to fix the problems but the marketing guys wouldn't let them, Java was out the door.So what happens when you use a language designed for toasters as the backbone for distributed internet applications? It doesn't work. Even if Java was up to the job (which it isn't because it lacks late binding), basing JVM implementations on a paper spec is a sure fire way to create incompatiblities. I remember that early versions of the JVM from Sun where incompatible with each other (platform specific threading) never mind achieving bit compatibility with JVM implementations from other vendors.BTW. What happend to JINI and JavaSpaces? I think Java self imploded here too.It's all wrong, all rushed, all short-term, and all driven by marketing.Paul.

    Actually I do not see it that radically java in itself is a wonderful language it was definitely a refreshing breeze going through the C++ language stack.

    And I think it scales tremendously given that it originally was planned as an embedded language. One clear case onn how good the original design really was. Sure this view depends on from which language side of things you come, if you came from Smalltalk it probably was a dissapointment, but if you came from C++, ObjectiveC or most scripting languages of that era it definitely was heavens sent.

    That we nowadays in some areas have a total framework overkill and that it does not scale into every area it is embedded in, are totally different issues and do not have anything to do with the original language.
    That applets failed was part due to political reasons and due to problematic plugin implementations, but not because of java itself.
    And besides applets I do not see that many areas where java has not succeeded.
  77. Java wasn't up to the Job[ Go to top ]

    That applets failed was part due to political reasons and due to problematic plugin implementations, but not because of java itself.And besides applets I do not see that many areas where java has not succeeded.
  78. Java wasn't up to the Job[ Go to top ]

    That applets failed was part due to political reasons and due to problematic plugin implementations, but not because of java itself.And besides applets I do not see that many areas where java has not succeeded.

    I do agree with you in part and I don't want to make this a language thing. Client side Web technology JavaScript, DHTML, AJAX etc is woefully poor and applets could have been a great improvement.

    The problem with the web is that the nature of the client platform is not known at the server. I tried to implement Applets and in the end it meant me downloading a shed load of jars to the client just to get anything remotely complex (more than a couple simple buttons) to work. This just isn't feasible (takes too long) and is pretty problematic. The end result is that we have chosen to dumb down the end-user experience setting back human computer interfaces over 2o years.

    Java webstart seems promising to me but it still requires a pretty hefty download. As I pointed out before the web is crying out for a late bound component architecture. No major players are promoting the use of late bound technology.

    I'm not sure what Sun were thinking of when they morphed Self into JavaScript, but at least javaScript is dynamic and facilitates late-binding.

    The issue with using a static language for mobile objects is that you need to be pretty certain of the interfaces of the client objects that your mobile object will depend upon. Should the interface change (e.g new methods) then references by existing mobile objects will break (ClassCastException).

    For example imagine if the DOM interface on IE was statically typed. Any changes to the interface would break existing scripts (mobile objects). This is probably why Sun and Netscape dreamt up JavaScript instead of using Java.

    JINI and JavaSpaces where meant to deliver mobile code too. Clients that would dynamically discover remote services and load mobile objects as required. Why didn't Sun persue this approach? My guess is that they knew that the lack of late-binding in Java just made such an approach too problematic.

    Java is a much better C++ and suited to environments where you are sure that all interfaces will remain the same (static) forever. This constraint delivers performance similar to C++ whilst achieving platform independence at runtime and improved productivity. For mobile objects IMO you need an approach that is a little more dynamic.

    Paul.
  79. Java wasn't up to the Job[ Go to top ]

    I tried to implement Applets and in the end it meant me downloading a shed load of jars to the client just to get anything remotely complex (more than a couple simple buttons) to work. This just isn't feasible (takes too long) and is pretty problematic.

    I think things are changing, especially with mass broadband use - a multi-megabyte download is far less of an issue.
    The issue with using a static language for mobile objects is that you need to be pretty certain of the interfaces of the client objects that your mobile object will depend upon. Should the interface change (e.g new methods) then references by existing mobile objects will break (ClassCastException).

    You see, I think of this as a good thing! I want to be certain of such things. I don't want things dynamically changing without my knowledge.
    Java is a much better C++ and suited to environments where you are sure that all interfaces will remain the same (static) forever.

    I think the alternatives have a lot of danger.
  80. Java wasn't up to the Job[ Go to top ]

    The issue with using a static language for mobile objects is that you need to be pretty certain of the interfaces of the client objects that your mobile object will depend upon. Should the interface change (e.g new methods) then references by existing mobile objects will break (ClassCastException).
    You see, I think of this as a good thing! I want to be certain of such things. I don't want things dynamically changing without my knowledge.

    So you choose to extend your DOM on the client, and you actually want to break all the existing web apps out there that don't make use of your new DOM feature?

    I was an early Java adopter and there was a lot of promises made with regards to the internet. We were promised a sea of mobie objects that would distribute themselves across the net, replicate and federate as needed on any machine that contained a JVM. In practice though the technology proved not to be up to the job.

    Things like RMI, Applets, JINI and JavaSpaces just haven't taken off in the ubiquitous way promised. Instead we are left with HTTP, XML, SOAP, DHTML, JavaScript, AJAX, CSS etc. These technologies are pretty weak for sure, but the advantage they have over the former ones is at least they don't break everytime someone makes a minor change to an interface. So my question is what happened to the mobile objects we were promised?

    Paul.
  81. Java wasn't up to the Job[ Go to top ]

    So you choose to extend your DOM on the client, and you actually want to break all the existing web apps out there that don't make use of your new DOM feature?

    We are talking about objects, not data.
    In practice though the technology proved not to be up to the job.

    I disagree. I know this is a harsh view, but I think it is because developers really aren't used to working like that. Distributed coding is hard no matter what language you use.
    Things like RMI, Applets, JINI and JavaSpaces just haven't taken off in the ubiquitous way promised.

    Just because others have not used these, there is nothing to stop you using them. They are good technologies.
    Instead we are left with HTTP, XML, SOAP, DHTML, JavaScript, AJAX, CSS etc. These technologies are pretty weak for sure, but the advantage they have over the former ones is at least they don't break everytime someone makes a minor change to an interface.


    You are confusing markup with objects in the majority of cases.

    Also to label all of these important technologies as 'pretty weak' is a vast and unhelpful simplification. I don't know of anyone who understand the technology well who would call XML 'pretty weak'.

    Personally, I want things to break with I make a change in an interface. The idea of unfettered objects with unverifiable signatures doing arbitrary things is rather troubling.
    So my question is what happened to the mobile objects we were promised?Paul.

    You can use them all you want, but not just in the free-for-all way you would like; at least not in Java.
  82. Objects vs Markup[ Go to top ]

    You are confusing markup with objects in the majority of cases.

    Hi Steve,

    I'm not confused, I'm just expressing a preference. Markup (XML, DHTML etc) is used to distribute data. When it comes to distribute behaviour across a network things get a little tricky with Markup (JavaScript, CSS and AJAX).

    Late bound mobile objects on the other hand can be used to encapsulate and distibute both state (data) and behaviour, hence my preference for objects.

    Paul.
  83. Objects vs Markup[ Go to top ]

    You are confusing markup with objects in the majority of cases.
    Hi Steve,I'm not confused, I'm just expressing a preference. Markup (XML, DHTML etc) is used to distribute data. When it comes to distribute behaviour across a network things get a little tricky with Markup (JavaScript, CSS and AJAX). Late bound mobile objects on the other hand can be used to encapsulate and distibute both state (data) and behaviour, hence my preference for objects.Paul.

    Why do you keep going on about late binding? This is not a requirement for distributing behaviour. It is only a requirement if you want to distribute new behaviour when a program is actually running. I can't see this as being a significant requirement for the vast majority of web applications.
  84. Objects vs Markup[ Go to top ]

    Why do you keep going on about late binding? This is not a requirement for distributing behaviour. It is only a requirement if you want to distribute new behaviour when a program is actually running. I can't see this as being a significant requirement for the vast majority of web applications.
    I'm glad you asked this question. If I've got object A which needs to talk to object B, I can bind the two objects together early at compile time. This has benefits, I can hard code a memory reference in A that points to B. This early binding delivers great performance (I just have to reference a pointer and jump to an address) at the expense of flexibility.

    What happens if I want to change the context of object B. I want B to run at a different memory location or on a different machine? The static memory reference in A is no longer valid. What I could is get A to ask some infrastructure code for a reference to B and rely on the infrastructure to deliver an appropriate reference and pass it back to A at runtime. This is my understanding of late-binding.

    A good example is XWindows. I can display the same XWindows application either locally or remotely. My application binds to the windowing system at runtime. The Applicaion could be running on platform X and displayed on platform Y. The binding between the application and the window occurs as late as possible, at runtime with no platform (hardware and OS) dependencies.

    So why is this important to "internet" applications? Well if the objects you want to bind to aren't available at compile time, (they are remote) then you will need to rely on late binding at runtime.

    Static languages like C aren't designed for late-binding and rely on OS infrastructure to achieve it. The classic appraoch is shared dynamic libraries as used in Unix and DLLs on Windows (sorry for the pedestrian explanation, but I want to be clear).

    So what happens if you want to perform late-binding in a small grained way. Instead of linking to DLL's you want to link to individual objects? You may want to do this because you just want to download over the web just a few objects and rely on a common library of objects on the client. As Christian points out COM allows for this by allowing your dowloaded objects to talk to DLLs.


    Dynamic languages have late-binding built into the VM, so all object interactions go through the VM and all method calls can be intercepted and re-directed as needed. To do this these languages maintain more meta data at runtime so that function calls are replaced by message sends. The sender selects the method it want to call by sending a message to the reciever (a selector) rather than relying on some memory offset in a shared DLL.

    Personally I've become convinced that the dynamic language approach to late-binding is more robust and flexible than the static language approach. Alan Kay talks about it all the time, and after spending some time programming Croquet in Smalltalk I'm convinced that he is right.

    Paul.
  85. Objects vs Markup[ Go to top ]

    If I've got object A which needs to talk to object B, I can bind the two objects together early at compile time. This has benefits, I can hard code a memory reference in A that points to B. This early binding delivers great performance (I just have to reference a pointer and jump to an address) at the expense of flexibility.What happens if I want to change the context of object B. I want B to run at a different memory location or on a different machine?

    Yes, but you still have not answered why you need to change this situation while an application is actually running.
    The static memory reference in A is no longer valid. What I could is get A to ask some infrastructure code for a reference to B and rely on the infrastructure to deliver an appropriate reference and pass it back to A at runtime. This is my understanding of late-binding.A good example is XWindows. I can display the same XWindows application either locally or remotely. My application binds to the windowing system at runtime. The Applicaion could be running on platform X and displayed on platform Y. The binding between the application and the window occurs as late as possible, at runtime with no platform (hardware and OS) dependencies.So why is this important to "internet" applications? Well if the objects you want to bind to aren't available at compile time, (they are remote) then you will need to rely on late binding at runtime. Static languages like C aren't designed for late-binding and rely on OS infrastructure to achieve it. The classic appraoch is shared dynamic libraries as used in Unix and DLLs on Windows (sorry for the pedestrian explanation, but I want to be clear).So what happens if you want to perform late-binding in a small grained way. Instead of linking to DLL's you want to link to individual objects? You may want to do this because you just want to download over the web just a few objects and rely on a common library of objects on the client. As Christian points out COM allows for this by allowing your dowloaded objects to talk to DLLs.Dynamic languages have late-binding built into the VM, so all object interactions go through the VM and all method calls can be intercepted and re-directed as needed. To do this these languages maintain more meta data at runtime so that function calls are replaced by message sends. The sender selects the method it want to call by sending a message to the reciever (a selector) rather than relying on some memory offset in a shared DLL. Personally I've become convinced that the dynamic language approach to late-binding is more robust and flexible than the static language approach. Alan Kay talks about it all the time, and after spending some time programming Croquet in Smalltalk I'm convinced that he is right.Paul.

    Welcome to Java, where you can dynamically load individual classes over the network during execution time. Also, take a look Java's dynamic proxy classes ("A dynamic proxy class is a class that implements a list of interfaces specified at runtime"). Both these methods are very fine-grained, and allow functionality to be added at execution time. What Java is not good at (yet?) is allowing individual classes, once downloaded, to be changed during execution. But is that a major disadvantage for this type of application?
  86. Objects vs Markup[ Go to top ]

    Welcome to Java, where you can dynamically load individual classes over the network during execution time


    See Christians description of the problems people have experienced with COM. I've had similar experiences with RMI. The Java language doesn't provide the messaging and the versioning he describes out the box, and I'm not aware of any Java frameworks that do (RMI doesn't IMO).
     
    What Java is not good at (yet?) is allowing individual classes, once downloaded, to be changed during execution. But is that a major disadvantage for this type of application?

    I agree, I don't think this facility is needed for distribution. I have conceeded that robust distribution of objects should be possible with Java, but I agree with Christian that it hasn't been successfully implemented yet.

    Personally I believe that distribution is easier to implement with a dynamic language, but that is just my view.

    Paul.
  87. Objects vs Markup[ Go to top ]

    Welcome to Java, where you can dynamically load individual classes over the network during execution time
    See Christians description of the problems people have experienced with COM. I've had similar experiences with RMI. The Java language doesn't provide the messaging and the versioning he describes out the box, and I'm not aware of any Java frameworks that do (RMI doesn't IMO).&nbsp;

    I think you have missed the point here. I was not talking about messaging or remoting. I was talking about dynamically loading bytecode in the form of classes over the network via a ClassLoader. This can be done for arbitary classes dynamically.
    What Java is not good at (yet?) is allowing individual classes, once downloaded, to be changed during execution. But is that a major disadvantage for this type of application?
    I agree, I don't think this facility is needed for distribution. I have conceeded that robust distribution of objects should be possible with Java, but I agree with Christian that it hasn't been successfully implemented yet.

    Yet again I was not talking about distribution of functionality or remoting via messaging, but about distribution of code; we have been talking at cross-purposes. Distribution of classes is, of course, extremely robust.
  88. Objects vs Markup[ Go to top ]

    Yet again I was not talking about distribution of functionality or remoting via messaging, but about distribution of code; we have been talking at cross-purposes. Distribution of classes is, of course, extremely robust.
    Perhaps, my original point was about mobile code. Treating code just like another media type and having it move around a network and execute where ever needed.

    My concern is how the code interacts with other code (objects) when it gets to a remote site. I agree that mechanisms for getting the code there in the first place exist and are robust in Java (if this is what you mean).

    Paul.
  89. In Java I'm only forced to do compile-time binding to an interface. The only difference here between dynamic and static languages is that in Java you explicitly bind to an interface, and in dynamic languages you implicitly bind to it. That fact that the object must implement the interface doesn't change.

    Of course, if you don't specify interfaces, or you explicitly specify classes in your code, then you are binding to an implementation. And admittedly it's a pain to create/maintain interfaces for all important classes, but it's up to the programmer. Java is by no means forcing early binding to an implementation.

    As for address spaces, I believe Sun's JVM implements references as handles, not raw pointers (the hanles contain raw pointers). It would be possible to implement a JVM capable of moving objects through different physical address spaces in a manner that's transparent to the programmer. In fact, I think such a JVM exists, but I can't remember what it's called at the moment. The point is the JVM abstracts away the hardware enough that this is possible.

    Here's a paper on it:
    (link to paper)

    The difference between Java and dynamic languages is that in Java the binding to an interface is explicit while in dynamic languages is it implicit. Being explicit is more work, and often times requires more thought. It also makes it to the compiler can do some validation on your code. It's safer.
  90. Hi Erik,

    Good post. I was waiting for someone to make these points. See my response:
    In Java I'm only forced to do compile-time binding to an interface. The only difference here between dynamic and static languages is that in Java you explicitly bind to an interface, and in dynamic languages you implicitly bind to it. That fact that the object must implement the interface doesn't change.Of course,
    Java is a bit of a hybrid. Interfaces are an attempt at late binding within the Java language and they have been quite successful, but they don't go all the way. For example if I extend my interface then I have a new interface, all references to the old interface break (without recompiling). This is pretty poor considering that the old code will not use the extensions (by definition). This behaviour goes against the open-closed principle (objects should be open for extension, but closed for modification). Your point about dynamic languages using an implicit interface isn't quite right IMO either. Dynamic languages interface to individual messages. Either the object supports a specific message or it doesn't. It doesn't need to support a given interface (collection of pre-canned messages) explicitly or implicitly. It only needs to answer to the messages sent by clients.
    if you don't specify interfaces, or you explicitly specify classes in your code, then you are binding to an implementation. And admittedly it's a pain to create/maintain interfaces for all important classes, but it's up to the programmer.
    OK. But this is like the virtual function in C++. You need to know ahead of time that you will want to late-bind to a specific interface. Just like in C++ you need to know that you intend to override a method in the future so to make it virtual. I for one can't tell the future. Having everything virtual by default and "interfaced" by default means that I do not need to guess ahead of time.
    Java is by no means forcing early binding to an implementation.As for address spaces, I believe Sun's JVM implements references as handles, not raw pointers (the hanles contain raw pointers). It would be possible to implement a JVM capable of moving objects through different physical address spaces in a manner that's transparent to the programmer. In fact, I think such a JVM exists, but I can't remember what it's called at the moment. The point is the JVM abstracts away the hardware enough that this is possible.Here's a paper on it:(link)The difference between Java and dynamic languages is that in Java the binding to an interface is explicit while in dynamic languages is it implicit. Being explicit is more work, and often times requires more thought. It also makes it to the compiler can do some validation on your code.
    I need to read the paper, but I don't agree with your central assertion. Java replaces dependencies on Classes (implementation) on occasion with a dependency on an Interface. If the Interface changes in a benign way (gets extended) then dependent code breaks. Also Java forces you to make design decision very early. I need to know a head of time where to put my interfaces, this is an improvement on C++, but not the same as not having to worry about Class (implementation) and Interface (type) dependencies at all.
    It's safer.
    Also I fail to see how the validation by the compiler makes things any safer. The majority of objects in most Java applications are held in collections untyped. The only way to detect that your dynamic casts are safe is to execute the code. Likewise this is the only way to ensure that objects aren't null at specific times. Runtime exceptions are just as prevalent in Java as they are in dynamic languages. The only difference being "object does not understand message" exceptions.

    I'll read the paper, and you make some intelligent points. I've thought about these issues quite a lot recently, and I've been using both static and dynamic languages side by side. My experience has been that many of the points made in theory aren't actually born out in practice. To me dynamic languages seem more natural and tend to model the real world more acurately. Very few things in the real world fit neatly into pre-defined and fixed types.

    Paul.
  91. Java is a bit of a hybrid. Interfaces are an attempt at late binding within the Java language and they have been quite successful, but they don't go all the way.

    No, interfaces are not an attempt at late binding within the Java language. They are an alternative to multiple inheritance. You can, of course, dynamically generate classes that conform to an interface at runtime. You can also dynamically load classes that conform to a superclass at runtume.
    Also I fail to see how the validation by the compiler makes things any safer. The majority of objects in most Java applications are held in collections untyped. The only way to detect that your dynamic casts are safe is to execute the code.

    No, it need not be like this. I use generics in Java 1.5 to remove the need for such casts.

    The majority of objects in my Java applications are held in typed collections. This has been a major benefit in my experience.
    Runtime exceptions are just as prevalent in Java as they are in dynamic languages.

    No, they really aren't, due to type safety. I have considerable experience of both Java and dynamic languages and I strongly disagree with you here.
    My experience has been that many of the points made in theory aren't actually born out in practice. To me dynamic languages seem more natural and tend to model the real world more acurately. Very few things in the real world fit neatly into pre-defined and fixed types.Paul.

    Fortunately, in development, we can constrain things, and don't have to have the chaotic mess of the real world in our applications :)
  92. Fortunately, in development, we can constrain things, and don't have to have the chaotic mess of the real world in our applications :)Yes, and possibly end up with brittle applications that break everytime something in the real world changes.

    I get your point, and I do feel more "secure" when declarng types all over the place. You tend to know where you are. With dynamic languages I find that I'm always running snippets of code and using inspectors just to verify what things do.

    Is this a better way of programming? Like we've both said before this debate will run and run.

    Cheers,

    Paul.
  93. Formatting...
    Fortunately, in development, we can constrain things, and don't have to have the chaotic mess of the real world in our applications :)
    Yes, and possibly end up with brittle applications that break everytime something in the real world changes.

    I get your point, and I do feel more "secure" when declarng types all over the place. You tend to know where you are. With dynamic languages I find that I'm always running snippets of code and using inspectors just to verify what things do.Is this a better way of programming? Like we've both said before this debate will run and run.

    Cheers,

    Paul.
  94. Implicit Interfaces[ Go to top ]

    Your point about dynamic languages using an implicit interface isn't quite right IMO either. Dynamic languages interface to individual messages. Either the object supports a specific message or it doesn't. It doesn't need to support a given interface (collection of pre-canned messages) explicitly or implicitly. It only needs to answer to the messages sent by clients.

    Python calls them protocols rather than interfaces in order to distinguish them from the Java concept of interfaces. Perhaps my labelling of them as implicit interfaces is incorrect, because saying they are "implicit" implies that the compiler/interpreter is actually aware of them, and it is not.

    What I meant was tacit interfaces, meaning they are in your head. You write a method that requires a given protocol and you pass an object into it that implements that protocol. It's not really any different from a network protocol. The implementations at each end can be completely different, but they both must implement the same protocol for communication to work.
    If the Interface changes in a benign way (gets extended) then dependent code breaks.

    I've never heard it put that way before, but you statement makes the intuitive appeal of a dynamic language make complete sense. With a staticly typed languages a benign change in an interface can break a client (well, require a recompile of client code, that's not as bad as breaking), because all it knows is that the interfaces no longer match. With dynamic languages a benign change doesn't break client code (or require a recompile), but the only way you can tell the difference between a benign and a destructive change is to do thorough testing. The difference is, when a person makes a benign change, he doesn't want the computer to report a bunch of "non-problems."
  95. Java replaces dependencies on Classes (implementation) on occasion with a dependency on an Interface. If the Interface changes in a benign way (gets extended) then dependent code breaks.
    This has nothing to do with late binding, and is easily solved by only publishing immutable interfaces, a practice that COM introduced and that is now being used widely even in Java (see the Eclipse API and even Swing and AWT).

    --
    Cedric
  96. Objects vs Markup[ Go to top ]

    Hi Paul,

    I find it interesting that you campaign hard for late-bindings language, yet in this very message, you give two good examples of technologies that use either type of bindings (static or late) and still achieve the same flexibility you are looking for (X Window and COM).

    Not only does COM work fine with static bindings, it actually supports *any* kind of bindings. Either you bind to a static IDL definition, or you can query interfaces and discover the capabilities of the objects at runtime, regardless of the language they were written in...

    Don't get me wrong: I like the quick-and-dirty nature of late binding for little projects, but I fail to see the advantage that such languages give me for "Internet applications"...

    --
    Cedric
  97. Objects vs Markup[ Go to top ]

    Not only does COM work fine with static bindings, it actually supports *any* kind of bindings. Either you bind to a static IDL definition, or you can query interfaces and discover the capabilities of the objects at runtime, regardless of the language they were written in...Don't get me wrong: I like the quick-and-dirty nature of late binding for little projects, but I fail to see the advantage that such languages give me for "Internet applications"...-- Cedric
    Hi Cedric,

    I have no experience with COM, and I've found all the positive comments on COM in this thread a pleasent surprise. My experience of static languages, objects and late-binding is that they don't work that well (OpenDoc, DSOM, CORBA, RMI etc).

    I'm just talking about the stuff I've seen work well. My feeling is that simple things are hard to get working and complex things are impossible. All the the static language object component models I know of are big and complex. Hence I'm not surprised that there is not yet a robust implementation providing the facilities Christian has described (intelligent messaging, and versioning).

    I've never used it, but I've heard and read about GemStone/S a Smalltalk distributed object application server. The design and the programming interface just seems so much simpler than something like COM, and to me simplicity normally means robust and reliable.

    I'm happy to be corrected. Personally I would like to use mobile objects with Java rather than using JavaScript, DHTML and AJAX.

    Paul.
  98. Java wasn't up to the Job[ Go to top ]

    It's all wrong, all rushed, all short-term, and all driven by marketing.Paul.

    And as a consequence it has been one of the most successful languages in the history of computing. It has brought true portability and decent memory management in a mass-use high performance language. Marketing is not always a bad thing. It can lead to solutions that actually get used by millions of developers, and not interesting and idealistic ideas and languages that may be influential, but never get widely used.
  99. Java wasn't up to the Job[ Go to top ]

    It's all wrong, all rushed, all short-term, and all driven by marketing.Paul.
    And as a consequence it has been one of the most successful languages in the history of computing. It has brought true portability and decent memory management in a mass-use high performance language. Marketing is not always a bad thing. It can lead to solutions that actually get used by millions of developers, and not interesting and idealistic ideas and languages that may be influential, but never get widely used.

    We are talking about client side web technology. JavaScript and DHTML is woeful, so where Applets IMO. JINI and JavaSpaces never got off the ground. Things like Flash are a fair attempt to bring some life to an intractible problem, but should we have gone down this road in the first place?

    My criticism isn't of Java as a language. Like I've said several times for the right application it's great (sorry about the pun about being designed for toasters, but that is just historical fact).

    The context here is distributed client side objects delivered over the web. For this purpose Java has several significant limitations which in my opinion led in part to the failure of applets.

    Paul.
  100. Java wasn't up to the Job[ Go to top ]

    The context here is distributed client side objects delivered over the web. For this purpose Java has several significant limitations which in my opinion led in part to the failure of applets.Paul.

    As has been pointed out earlier in this thread, there were very specific reasons why applets where not highly successful, such as Microsoft's tactics.
  101. Java wasn't up to the Job[ Go to top ]

    The context here is distributed client side objects delivered over the web. For this purpose Java has several significant limitations which in my opinion led in part to the failure of applets.Paul.
    As has been pointed out earlier in this thread, there were very specific reasons why applets where not highly successful, such as Microsoft's tactics.
    Ah come on, Steve, that's a bit simplistic.

    The reasons why Java never worked on the desktop are well-known:

    * Rigid security manager that doesn't let the applet do anything interesting.
    * Discrepancy between the current JDK's and the ones used inside browser.
    * UI blindness: applets are a black box with their own navigation and focus rules.
    * Long start-up time.
    * Isolation: applets know nothing about their environment (DOM and browser).

    Microsoft has nothing to do with that.

    --
    Cedric
  102. Java wasn't up to the Job[ Go to top ]

    The context here is distributed client side objects delivered over the web. For this purpose Java has several significant limitations which in my opinion led in part to the failure of applets.Paul.
    As has been pointed out earlier in this thread, there were very specific reasons why applets where not highly successful, such as Microsoft's tactics.
    Ah come on, Steve, that's a bit simplistic.The reasons why Java never worked on the desktop are well-known:* Rigid security manager that doesn't let the applet do anything interesting.* Discrepancy between the current JDK's and the ones used inside browser.* UI blindness: applets are a black box with their own navigation and focus rules.* Long start-up time.* Isolation: applets know nothing about their environment (DOM and browser).Microsoft has nothing to do with that.-- Cedric

    Actually the security was not more rigid than ajaxs, the dom accessability was nasty but could be done.
    The startup times and the flakeyness of the sun plugin were huge reasons, but the biggest one was, that Microsoft stopped bundeling newer jdks and delivered only theirs, which was not really a nice experience if you wanted to deliver compex uis.
  103. Java wasn't up to the Job[ Go to top ]

    Actually the security was not more rigid than ajaxs, the dom accessability was nasty but could be done.The startup times and the flakeyness of the sun plugin were huge reasons, but the biggest one was, that Microsoft stopped bundeling newer jdks and delivered only theirs, which was not really a nice experience if you wanted to deliver compex uis.

    Werner,

    200% agreed. What if back in 1998 :
    -we had java GUI designer as easy to use as VisualBasic (possibly for free, or as cheap as VisualBasic)
    -we had java Widgets as handsome as VisualBasic/COM
    -we had scripting languague such as Groovy built-in java (as easy to use as... VisualBasic !!!)
    -the java garbage collector was more efficient from scratch (at this time java could incredibly eat-up a bunch of memory and completely freeze while garbage collecting...)

    Then, developers would have produced a bunch of nice visually appealing applets. Which would have trigger some warning light into the heads of Sun and IBM executives. And we would have had Matisse plus Swing or AWT libraries way sooner. And we would see Web 2.0 as java based, and not javascript based.

    Java on the desktop can be appealing. If you take a look at SwingSet2 demo, you realise that the java window based GUI was early anticipated by Sun. I used this package for a couple of client application projects, using internal frames, menus, pop-up contextual menus, navigation trees... Basically i built my own framework called... "BasicDestop", no cheating ! The customers were really impressed, they did not know that such nice rendering and usability was achievable in Java. Unfortunately it was only some kind of foundation for visually browse some object space, "perspective" based, not a full desktop abstraction. I wanted to extend it, but could not get the time for it.

    I also developped a simple desktop abstraction for my 8 years old daughter, she liked it, much more usable for her than plain WindowsXP. She liked it a lot, but her opinion may be biased ;o)

    The point is that most java developers have been busy doing serverside java stuff (my occupation for the past 7 years), and we were not that focused on client side java. Of course customers were only asking for 3-tiers html-http based implementations. Hence, we do not have a decent good looking desktop abstraction in standard JRE. But i believe/hope this will change, according to the actual interest of desktop java, at least with IBM's new initiative on this field.

    But again, i think things are changing, as we can see IBM trying to get back to desktop application in java via Eclipse RCA framework, at least in big corporations. IF they succeed there, than the libraries and tools will be there for developping mainstream applications 100% java.

    Cheers,

    Christian
  104. Java wasn't up to the Job[ Go to top ]

    Hi Christian,

    You make some good points, and I kind of agree, other than despite the politics and browser wars Sun still hadn't tackled the difficult issues with mobile code.

    Distributed software components are difficult. Eclipse does a good job at being a container for java based components, but even with Eclipse you still need to restart the application every time you add a new plugin.

    Groovy sounds more promising, but using a static language to build mobile components is really hard. Do you remember OpenDoc and DSOM amongst others?

    Also Sun had a browser of their own back then (can't remember what it was called) and Applets didn't work that well with it either from what I can remember.

    Microsoft didn't help, but even without Microsoft, I'm pretty sure that Applets would have run into many technical issues of it's own making. This is probably why Sun chose to switch the focus onto Servlets.

    Paul
  105. Java wasn't up to the Job[ Go to top ]

    Hi Paul,
    Hi Christian,You make some good points, and I kind of agree, other than despite the politics and browser wars Sun still hadn't tackled the difficult issues with mobile code. Distributed software components are difficult. Eclipse does a good job at being a container for java based components, but even with Eclipse you still need to restart the application every time you add a new plugin.

    I do not think the distribution is an issue of its own. The whole idea with applets and ActiveX is that distribution is transparent and it works quite well. I can download a new java game to my mobile phone without having to reboot it, even though i have a few time to play these days :o) I can download new version of AcrobatReader as an ActiveX without having to reboot everytime ( ok i might have to reboot InternetExplorer for some ActiveX, but Windows really did improve a lot is this field). And JavaWebStart seems efficient enough, although the ergonomy is bad, once again...
    Groovy sounds more promising, but using a static language to build mobile components is really hard. Microsoft didn't help, but even without Microsoft, I'm pretty sure that Applets would have run into many technical issues of it's own making. This is probably why Sun chose to switch the focus onto Servlets.Paul

    Groovy sounds really promising, i agree with you there, more accurate syntax for scripting then full java code.

    I do not understand why using static language is of any burden, particularly that now we have good java introspection. As an example, even when using C++ or C to code you can "late bind" on Windows, i.e. invoke a COM service as long as this COM service is properly registered in the registry. Just use some message based underlying mechanism for inter component communication to avoid threading issued and you have a very robust distributed components framework (i kind of work in this field). The whole idea would be to have one single applet hosting this desktop abstraction, then loading services on demand. Eclipse is going this way, although it is a shame you have to "reboot" Eclipse when you install a new plugin. This should not be necessary, unless the core eclipse would have changed in between.

    This very same mechanism can be easily reproduced in java, as far as a standard desktop abstraction with proper registry is available. Why did nobody from the java field "cut and paste" what Microsoft did achieve not so bad on the client ? Microsoft is king on "cut and paste" other's ideas, and this has proved to be not such a bad strategy ! IBM and Sun had the resources plus opportunity (money plus developers) to do it. Maybe the shooting window (i.e. large bandwith to easily distribute "heavy" components in order to compete with pre-installed Windows OS + IE) was not there ? But i believe it was not their main matter for a very simple reason : they do their money on the server side, not on the desktop side. They tried to launch thin client but they lacked what Windows has built : a proper desktop operating system (or desktop abstraction framework here) plus some standard component libraries, such as DLL32 where you can find anything to build a GUI based application, plus some mainstream applications (OpenOffice still has some way to go, at least from a look and feel point of view, and i don't understand why Sun did not invest more on enhancing this part of the product...). And of course Microsoft did not help them either ! But things are moving i believe.

    And finally maybe the main reason i see for a change in desktop and mainstream applications such as MS Office is this one : 99% of people only need a big maximum of 10% of their funtionnalities, if not less. Better multiple applications task oriented, than a big buggy one with incredibly complex menus. And on the contrary, those 90% of extrafunctionnality has turn office into a huge beast, thaht can be defeated by smaller dedicated tools.

    This is the reason why i wrote this java desktop for my daughter on top of windows : windows is way to complex for a child who will not turn into a geek, not even talking about my 60+ YO father ! So i designed full screen java application, with really BIG icons customisable with personal pictures, family photos for instance, and 12 icons per tab maximum. Tabs are used to group applications and documents just like folders. She enjoyed it a lot, as now she can pretend to work just like daddy when she laucnhes one of her games or educational CDRoms, and even her mother appreciated the GUI :o)
    Do you remember OpenDoc and DSOM amongst others?Also Sun had a browser of their own back then (can't remember what it was called) and Applets didn't work that well with it either from what I can remember.
    Ah, the promise of a full java browser... Too bad it did not catch up !

    Quite a long post, i might go back to work now... :o)

    Cheers,

    Christian
  106. Java wasn't up to the Job[ Go to top ]

    Thanks for the post. I think you've got me convinced. It does sound like the issue isn't the language, but poor (or non-exisitent) client container implementations.

    You mention COM as a component infrastructure. From what i've heard it was a configuration nightmare (incompatible DLLs). This is my concern with static languages and late-binding. It sounds like you've got a fair amount of experience getting this stuff to work hence I'm happy to differ to your judgement on this.

    BTW I agree that the "application" paridigm is a bad idea that should have been killed off long ago. Why have a barrier around all the components/objects that you want to work together, forcing you to place everything inside one big application, knowing that only 10% of the code will be used?

    With a late bound object model people could download/install just the objects they needed, i.e just 10%. The interface between these objects and the desktop should be seamless IMO. I believe NextStep achieved something like this using Objective-C.

    You have some good ideas, unfortunately not much lateral thinking goes on knowadays. I don't know why. I guess it's the inertia created by the currently incumbent client technology base (IE and Windows mostly).

    Paul.
  107. Java wasn't up to the Job[ Go to top ]

    Thanks for the post. I think you've got me convinced.

    Thanks for the thanks, TSS is more famous for its flaming than for this particular word :o)
    It does sound like the issue isn't the language, but poor (or non-exisitent) client container implementations.

    Definitely what i think. Whatever language you are using, in the end you have it translated into machine code, so language is never an issue unless the language does not implement some domain needed concept such as multi-threading and object-locking, for instance. But something is really more important than the language : the libraries and framworks that are available to the developer. Java success is partly (if not mostly) due to all the standard packages available out of Java JDK. Unfortunately java was poor on the graphic components side.
    You mention COM as a component infrastructure. From what i've heard it was a configuration nightmare (incompatible DLLs). This is my concern with static languages and late-binding.

    DLL hell was mainly due to uncompatbile versions (ever used an american application with a French DLL32 supposedly same version ???) of the DLL32 and others everywhere on the system with inexistant classpath management, plus the lack of versioning of DLLS. And additionally, a DLL is not a component, it is just what is used to implement a component.

    But in Windows, COMponents were very tightly coupled by RPC style invocation, which lead to memory management, threading issues and GPFs for instance crashing the whole system. Replace RPC by intelligent messaging with built-in version control (i.e. component isolation plus "intelligent" communication channel), and you have much less trouble.
    It sounds like you've got a fair amount of experience getting this stuff to work hence I'm happy to differ to your judgement on this.

    Unfortunately experience comes as years are flying "at the speed of light", to quote Bill "Business at the speed of light" Gates. I think this guy deserves this title :o)
    BTW I agree that the "application" paridigm is a bad idea that should have been killed off long ago. Why have a barrier around all the components/objects that you want to work together, forcing you to place everything inside one big application, knowing that only 10% of the code will be used?With a late bound object model people could download/install just the objects they needed, i.e just 10%. The interface between these objects and the desktop should be seamless IMO. I believe NextStep achieved something like this using Objective-C.You have some good ideas, unfortunately not much lateral thinking goes on knowadays. I don't know why. I guess it's the inertia created by the currently incumbent client technology base (IE and Windows mostly).Paul.

    IBM and Sun are selling hardware and services to professionals, they do little money on the mainstream desktop if at all. IBM abandoned the idea of a replacement for Windows (where is OS/2 ?), Sun could never get big money from thin clients. I believe servlets with overly verbose HTTP protocole and HTML page description helped them sell more servers, routers, multiplexers, dedicated hardware to marshall/unmarshall XML... The more complicated things are, the more money they make, isn't it wonderful ? :o)

    And additionally nobody expects Bill Gates to give away his milk cow, why waste money trying to attack him on the tehcnical and sales field ? Better pay some lawyers to win some anti-trust trial !

    So the (r)evolution is coming from individual developers who are targeting the mainstream customer. Web 1.0 was all about searching/reading the appropriate information. Web 1.5 is information aggregation via personal portals and content syndication (ok i just invented it i believe :o). Web 2.0 if more about mainstream customers producing this information, so the GUI must be reactive/interactive. Google applications ? So easy to use, so powerful. Blogs ? The same. Webmails ? My father can (slowly) use them. Wikis ? Fisher-Price (at lest for the simplest of them) !

    The path is there, but i can not help but thinking : Java was the perfect plateform for these services, but now we have to deal with (i really can not stand it anymore, sorry...) overly complex DHTML + DOM + CSS + Javascript, none having been designed for rich user interaction. Bill gates still has an highway open with nobody on his left trying to bounce him out. Can you imagine the difference in GUI an usage when, while we will be playing/fighting with HTML + Javascript, Microsoft will release a bunch of standard AciveX/Graphics Controls dedicated to this and that (they already have these components...), everything glued with proper ActiveScripting (oh no ! only compatible with IE 7 ?!?!?), for true Web desktop ? And this time free for the customer (well, it is paid by Windows + Office licences anyway). The mass of developers will still pay the (small) feer for their developer kit, believe me, and i might give my fee if a customer asks for such an interface, as i used to when i was developing using VisualStudio years ago.

    So let us hope that "Web 3.0" will be partly java based, for Web 2.0 it is dead i am afraid !

    Cheers,

    Christian
  108. Java wasn't up to the Job[ Go to top ]

    DLL hell was mainly due to uncompatbile versions (ever used an american application with a French DLL32 supposedly same version ???) of the DLL32 and others everywhere on the system with inexistant classpath management, plus the lack of versioning of DLLS. And additionally, a DLL is not a component, it is just what is used to implement a component.But in Windows, COMponents were very tightly coupled by RPC style invocation, which lead to memory management, threading issues and GPFs for instance crashing the whole system. Replace RPC by intelligent messaging with built-in version control (i.e. component isolation plus "intelligent" communication channel), and you have much less trouble.
    Yeah, this was my point. Your solution to the problem sounds pretty similar to sender/receiver messaging sending between objects as implemented in Smalltalk and other dynamic languages. Having this stuff built into the VM and available to every object for free is a big bonus IMO (see my earlier post).
    So let us hope that "Web 3.0" will be partly java based, for Web 2.0 it is dead i am afraid !Cheers,Christian

    Well your wish could happen sooner than you think. Have you heard of the movie "The Matrix"? Well check out this demo video:

    http://video.google.com/videoplay?docid=-3163738949450782327&q=Croquet

    Alan Kay and his team are busy re-inventing the Operating System and the World Wide Web all at once. This stuff is stable, open source and available for down load now:

    http://www.opencroquet.org

    The video is old, and Croquet has now reached release 1.0Beta. Work is in progress to allow you to program Croquet in other languages other than Smalltalk, such as Python and even JavaScript. They are also working on end-user scripting. Sadly Java support will only be partial due to the lack of late binding built into the Java language.


    Paul
  109. Java wasn't up to the Job[ Go to top ]

    Hi Paul,
    Yeah, this was my point. Your solution to the problem sounds pretty similar to sender/receiver messaging sending between objects as implemented in Smalltalk and other dynamic languages. Having this stuff built into the VM and available to every object for free is a big bonus IMO (see my earlier post).

    In my opinion going down to each and every object is not necessary, i prefer to talk about component/services, which are built upon onject instances. Object instances as part of an elementary unit called component or service do not need to be visible from the outer world (i.e. the desktop abstraction), and can be implemented using any technique/language/framework.

    But in order to build an application or a compplete desktop, all these components need to be wired together, i.e. Swing/Jini/Windows registry based component assembler, they need to communicate (i.e. robust version aware messaging system), and their interaction can be quite complex (i.e. event based scripting language). But nothing new here, as Microsoft implemented all this stuff years ago, even though in some quite complicated manner, largely due to speed/memory optmisation attemps, and because message based communication was not of a fashion at these times.
    Well your wish could happen sooner than you think. Have you heard of the movie "The Matrix"? Well check out this demo video:http://video.google.com/videoplay?docid=-3163738949450782327&q=CroquetAlan Kay and his team are busy re-inventing the Operating System and the World Wide Web all at once. This stuff is stable, open source and available for down load now:http://www.opencroquet.orgThe video is old, and Croquet has now reached release 1.0Beta. Work is in progress to allow you to program Croquet in other languages other than Smalltalk, such as Python and even JavaScript. They are also working on end-user scripting. Sadly Java support will only be partial due to the lack of late binding built into the Java language.Paul

    Thanks for the link to the Croquet project. The "language" seems a bit obfuscated to me but this will hopefully change, or i need to change ! And the concept seems very promising, certainly some very creative collaborative cyberworld will come out of it :o)

    Cheers,

    Christian
  110. Java wasn't up to the Job[ Go to top ]

    You mention COM as a component infrastructure. From what i've heard it was a configuration nightmare (incompatible DLLs).
    COM has nothing to do with DLL.

    It just happens that COM is typically used through shared libraries, but versioning problems in this area are not limited to Windows (you also have a .so hell on UNIX and same in Java with different JAR files).

    COM is a fantastic component model that simply defines the source and binary protocols to be used when two pieces of code are trying to communicate with each other, regardless of the language they are written in. In essence, COM has achieved the old time dream of being able to use whatever language you like to implement a certain task and even made it possible to implement pieces of a same application in different languages if you so choose.

    --
    Cedric
  111. Java wasn't up to the Job[ Go to top ]

    COM has nothing to do with DLL.It just happens that COM is typically used through shared libraries, but versioning problems in this area are not limited to Windows (you also have a .so hell on UNIX and same in Java with different JAR files).COM is a fantastic component model that simply defines the source and binary protocols to be used when two pieces of code are trying to communicate with each other, regardless of the language they are written in. In essence, COM has achieved the old time dream of being able to use whatever language you like to implement a certain task and even made it possible to implement pieces of a same application in different languages if you so choose.-- Cedric

    COM was for sure an architectural success, despite its weaknesses (threading model, memory management, Corba-like symtoms...). One had to really be an expert to properly understand all the pitfalls, and books were written on this single matter.

    I believe Gnome was inspired in trying to implement COM for Linux using Corba Orb (Mico ?), but not using Linux as a desktop i don't know if this has been largely used for Linux componentisation/automation. Do you know ?

    Cheers,

    Christian
  112. Java wasn't up to the Job[ Go to top ]

    You mention COM as a component infrastructure. From what i've heard it was a configuration nightmare (incompatible DLLs).
    COM has nothing to do with DLL.It just happens that COM is typically used through shared libraries, but versioning problems in this area are not limited to Windows (you also have a .so hell on UNIX and same in Java with different JAR files).COM is a fantastic component model that simply defines the source and binary protocols to be used when two pieces of code are trying to communicate with each other, regardless of the language they are written in. In essence, COM has achieved the old time dream of being able to use whatever language you like to implement a certain task and even made it possible to implement pieces of a same application in different languages if you so choose.-- Cedric

    Sorry I cannot share your opinion regarding being com as a phantastic component model, it has good ideas, but lacks totally in implementation. Instead of giving a clean and mean programming model, you have to go through all the C layer hoops, registry registration via uuid etc... etc...
    It is funny that you need several hundred lines of code in com while you can achieve the same in 4 lines of code in DCOP and basically also in a handful of lines in Openstep/Cocoa.
    The trick is all of those do not go through configuration hell and do not try to press program paradigms into languages not suitable for it (they provide interface hooks however)

    For me having hundreds of lines of code for something achievable by using better tools in 4 lines of code is not a sign of excellence!
  113. Java wasn't up to the Job[ Go to top ]

    You mention COM as a component infrastructure. From what i've heard it was a configuration nightmare (incompatible DLLs).
    COM has nothing to do with DLL.It just happens that COM is typically used through shared libraries, but versioning problems in this area are not limited to Windows (you also have a .so hell on UNIX and same in Java with different JAR files).COM is a fantastic component model that simply defines the source and binary protocols to be used when two pieces of code are trying to communicate with each other, regardless of the language they are written in. In essence, COM has achieved the old time dream of being able to use whatever language you like to implement a certain task and even made it possible to implement pieces of a same application in different languages if you so choose.-- Cedric
    Sorry I cannot share your opinion regarding being com as a phantastic component model, it has good ideas, but lacks totally in implementation. Instead of giving a clean and mean programming model, you have to go through all the C layer hoops, registry registration via uuid etc... etc...It is funny that you need several hundred lines of code in com while you can achieve the same in 4 lines of code in DCOP and basically also in a handful of lines in Openstep/Cocoa.The trick is all of those do not go through configuration hell and do not try to press program paradigms into languages not suitable for it (they provide interface hooks however)For me having hundreds of lines of code for something achievable by using better tools in 4 lines of code is not a sign of excellence!
    +1

    Cedric,

    You asked why I've lost faith with static languages when it comes to late-binding. Well this post makes the point well. The sad thing is that late binding has been available in Lisp since the 50's yet we still insist on trying to implement it with inappropriate langauges primarily for marketing reasons (this or that language is currently top of the pops so we must use it).

    What did they say about the man who built his house upon the sand?

    Paul.
  114. Java wasn't up to the Job[ Go to top ]

    The sad thing is that late binding has been available in Lisp since the 50's yet we still insist on trying to implement it with inappropriate langauges primarily for marketing reasons (this or that language is currently top of the pops so we must use it).What did they say about the man who built his house upon the sand?Paul.

    Yet again, I really don't think Java was successful for 'marketing reasons', and to imply it was does kind of suggest that a large number of developers can't make sensible judgments about what to use. (This may be true, but it is still harsh!). Show me an alternative language that is portable, high-performance, OOP, safe, and has the range of multi-vendor support for the language and range of tools that Java has and I'll gladly consider it for general development.

    Years ago, I felt I had built my 'development house' on sand by working with Smalltalk, after having to constantly review which dialect of the language I was using as various versions changed hands, were obsoleted, or priced out of my range, leaving me eventually with the choice of poor performance open source versions or losing the ability to deploy cross-platform.

    Now we Java developers are often pointed at Python or Ruby as examples of better development languages. Great languages for some purposes, but their development teams plan future versions which could well break compatibility with existing code.

    There are plenty of languages that have foundations of sand. Java isn't one of them.
  115. The right tool for the job[ Go to top ]

    The sad thing is that late binding has been available in Lisp since the 50's yet we still insist on trying to implement it with inappropriate langauges primarily for marketing reasons (this or that language is currently top of the pops so we must use it).What did they say about the man who built his house upon the sand?Paul.
    Yet again, I really don't think Java was successful for 'marketing reasons', and to imply it was does kind of suggest that a large number of developers can't make sensible judgments about what to use. (This may be true, but it is still harsh!). Show me an alternative language that is portable, high-performance, OOP, safe, and has the range of multi-vendor support for the language and range of tools that Java has and I'll gladly consider it for general development.Years ago, I felt I had built my 'development house' on sand by working with Smalltalk, after having to constantly review which dialect of the language I was using as various versions changed hands, were obsoleted, or priced out of my range, leaving me eventually with the choice of poor performance open source versions or losing the ability to deploy cross-platform. Now we Java developers are often pointed at Python or Ruby as examples of better development languages. Great languages for some purposes, but their development teams plan future versions which could well break compatibility with existing code.There are plenty of languages that have foundations of sand. Java isn't one of them.

    Hi Steve,

    You are an intelligent guy, I can tell. But you are allowing your over zealous defence of Java to blind you to the startlingly obvious.

    The post I was supporting was with regards to OpenStep/Cocoa versus COM. Java wasn't mentioned anywhere. If Java adopted language features that suited the kind of things we are talking about then it would be the right tool for the job.

    The whole discussion is not about language, it is about computer science and software engineering. I fail to see how you can robustly support early binding and compiler type checking in one breath, and be happy to live with typless DHTML, CSS, CGI and JavaScript in another. These technologies have no components, no true objects, no type checking (neither static or dynamic), infact everything is a string.

    What I'm advocating is web technology based on mobile code, treating mobile code as just another media type, and my question is what are the best tools for that job?

    Look beyond language A versus language B and think through the big picture.

    Paul.
  116. The right tool for the job[ Go to top ]

    Hi Steve,You are an intelligent guy, I can tell. But you are allowing your over zealous defence of Java to blind you to the startlingly obvious.The post I was supporting was with regards to OpenStep/Cocoa versus COM. Java wasn't mentioned anywhere.

    So Java is not a static language then? As in 'I've lost faith with static languages when it comes to late-binding'?

    And isn't Java currently the 'top of the pops' language :) ?

    (Actually, I really don't consider myself a zealous defender of Java as such. What I consider myself is a battle-scarred veteran user of other languages and techniques that are regularly (and in my view, often naively) promoted as the 'right way' or 'next big thing'. If any other language had the same level of support, tools and features as Java I'm sure I would feel as comfortable as that. I am more against certain things than totally for Java).
    If Java adopted language features that suited the kind of things we are talking about then it would be the right tool for the job.The whole discussion is not about language, it is about computer science and software engineering.

    The two are inseparable.
    I fail to see how you can robustly support early binding and compiler type checking in one breath, and be happy to live with typless DHTML, CSS, CGI and JavaScript in another.

    I am not completely happy to live with them, and never said I was. I would far prefer some technology equivalent to applets.
    These technologies have no components, no true objects, no type checking (neither static or dynamic), infact everything is a string.

    Yes, but that does not matter to me. I use them to render my server-side components. To me they are a presentation method, not a way of coding objects. I care about them as a development language about as much as I would care about postcript as a development language.
    What I'm advocating is web technology based on mobile code, treating mobile code as just another media type, and my question is what are the best tools for that job?Look beyond language A versus language B and think through the big picture.Paul.

    You can't look beyond language, or at least language has to be a key part of any discussion because language imposes constraints.
  117. The right tool for the job[ Go to top ]

    I could pick holes in your response (like since when has end-user presentation been no more worthy of atention than postscript?), but I won't.

    On a substantive point, when I adopted Java I wasn't that taken by applets (the limitations seemed obvious to me), and I thought that server based web apps (HTTP/HTML etc) was a horrible kludge (I still do).

    I sat through a Java enterprise architecture presentation at Valtech, and what convinced me that Java had legs for the future was the description of JINI and JavaSpaces, technologoes that were imminent back in 97/98.

    As I've mention before, the vision was of a sea of mobile objects moving across the net and enabled by the ubiquitous JVM. Applets and Web Apps were meant to be a short term foot in the door, the long term plan was to realise Sun's vision: "The Network is the Computer".

    So what has happend in the consequent years? Well applets died a death, we are still kludging web apps and talk is abound about extending the kludge to machine-to-machine transactions (WebServices).

    My simple substantive question that I have asked several times on this forum and still haven't had answered in a substantive way is what happend to JINI and JavaSapces? And why isn't it the ubiquitous success that was envisioned back in 98?

    Paul.
  118. The right tool for the job[ Go to top ]

    I could pick holes in your response (like since when has end-user presentation been no more worthy of atention than postscript?), but I won't.

    You are misrepresenting me. Of course end-user presentation matters. My point of view is that I am not particularly concerned how it is implemented in terms of markup (HTML, CSS, SVG, display postscript etc.). I don't care if I implement my components server-side or client side. All that matters to me is a reasonable event-based component model. Things would be easier if the web was more stateful, so things like dialogs could be simpler to implement, but that is another matter.
    On a substantive point, when I adopted Java I wasn't that taken by applets (the limitations seemed obvious to me), and I thought that server based web apps (HTTP/HTML etc) was a horrible kludge (I still do).I sat through a Java enterprise architecture presentation at Valtech, and what convinced me that Java had legs for the future was the description of JINI and JavaSpaces, technologoes that were imminent back in 97/98.As I've mention before, the vision was of a sea of mobile objects moving across the net and enabled by the ubiquitous JVM. Applets and Web Apps were meant to be a short term foot in the door, the long term plan was to realise Sun's vision: "The Network is the Computer".So what has happend in the consequent years? Well applets died a death, we are still kludging web apps and talk is abound about extending the kludge to machine-to-machine transactions (WebServices).My simple substantive question that I have asked several times on this forum and still haven't had answered in a substantive way is what happend to JINI and JavaSapces? And why isn't it the ubiquitous success that was envisioned back in 98?Paul.

    My view is that it is because that form of distributed development has never been truly popular. The development community is pretty reactionary as a whole; it took a very long time for OOP to be generally accepted as a useful approach. The same is true for distributed development, I believe. I can remember doing distributed numeric coding as part of my research work in the 80s - dynamically distributing code and farming out work over networks of processors - it was hard enough to get things to work, but then there was a barrier to publishing the results, as many did not understand the process - they were still stuck with serial processing techniques used on legacy supercomputer architectures. In the same way, I believe that the development of truly distributed code will take a long time to catch on; not because the facilities aren't there - systems like JavaSpaces are up to the task - but because it is such an unfamiliar way of working.

    However, some developers really are making 'the network the computer'. Check out what Tangosol is doing - their Data Grid system looks like it will be awesome.
  119. The Java Vision[ Go to top ]

    Hi Steve,

    I've got a bit of a bee in my bonnet. It appears that I seem to be the only person with a clear recollection of history. Just to prove to my self that I weren’t making it all up I've done a bit of digging around. Javaworld has a number of articles on JINI and JavaSpaces that make it quite clear that JINI was Suns' inital vision for Java. This particular article has an interview with the great man him self Bill Joy:

    http://www.javaworld.com/javaworld/jw-08-1999/jw-08-jiniology.html

    It is a long read, but it makes Sun's intentions at the time very clear.

    I wasn't the only one taken in by the vision. Alan Kay says quite openly that back when they where thinking about doing Croquet, back in 98 they wanted to use Java.

    Alan is a bit more knowlegeable about these things than I and he goes on to say that he quickly realised that Java wasn't going to be up to the job (incompatible VMs, no meta-data, no late-binding etc) and they were forced to re-implement Smalltalk (Squeak) based on some old code they got from Apple.

    Six years later they were finally able to start on Croquet in earnest. So what happened at Sun? Alan Kay's take, and he claims to know key insiders, is that the Engineers wanted to make the changes needed to enable the vision (mobile objects) and the Marketing people wouldn't let them.

    This sounds plausible to me. One day all the talk was about OO, JINI and JavaSpaces, the next the focus was on App Servers and EJB's. It sounds like the Engineers lost out to marketing, but of course this is just speculation.

    Either way doesn't it bother you that "modern" web apps are not that dissimilar in to green screen terminal applications of the 1960's and 70's (read-evaluate-write)? It bugs me.

    In the same time there has been perhaps over 20 turns of moore's law in hardware terms but software technology has hardly moved on at all! A bit embarrassing don't you think?

    Paul.
  120. The Java Vision[ Go to top ]

    Hi Steve,I've got a bit of a bee in my bonnet.

    I would never have guessed :)
    It appears that I seem to be the only person with a clear recollection of history. Just to prove to my self that I weren’t making it all up I've done a bit of digging around. Javaworld has a number of articles on JINI and JavaSpaces that make it quite clear that JINI was Suns' inital vision for Java. This particular article has an interview with the great man him self Bill Joy:http://www.javaworld.com/javaworld/jw-08-1999/jw-08-jiniology.htmlIt is a long read, but it makes Sun's intentions at the time very clear.I wasn't the only one taken in by the vision. Alan Kay says quite openly that back when they where thinking about doing Croquet, back in 98 they wanted to use Java. Alan is a bit more knowlegeable about these things than I and he goes on to say that he quickly realised that Java wasn't going to be up to the job (incompatible VMs, no meta-data, no late-binding etc) and they were forced to re-implement Smalltalk (Squeak) based on some old code they got from Apple.Six years later they were finally able to start on Croquet in earnest. So what happened at Sun? Alan Kay's take, and he claims to know key insiders, is that the Engineers wanted to make the changes needed to enable the vision (mobile objects) and the Marketing people wouldn't let them.This sounds plausible to me. One day all the talk was about OO, JINI and JavaSpaces, the next the focus was on App Servers and EJB's. It sounds like the Engineers lost out to marketing, but of course this is just speculation.Either way doesn't it bother you that "modern" web apps are not that dissimilar in to green screen terminal applications of the 1960's and 70's (read-evaluate-write)? It bugs me. In the same time there has been perhaps over 20 turns of moore's law in hardware terms but software technology has hardly moved on at all! A bit embarrassing don't you think?Paul.

    Of course it bugs me, but I think you are mixing up all kinds of things into one argument. The web is the way it is because Applets (to put it simply) failed. Applets didn't fail because of the presence or absence of JINI or JavaSpaces. If decent JVMs had been bundled with most PCs, and kept up to date (this is the incompatible VMs issue), I believe applets would have become a major way to deliver decent functionality to desktops.

    How these applets would then have interacted with servers is another matter, but completely irrelevant in terms of the current 'green screen' (or whatever) nature of the current web.

    So, putting aside the GUI aspects for now, what is stopping you from making use of JavaSpaces right now?
  121. The Java Vision[ Go to top ]

    So, putting aside the GUI aspects for now, what is stopping you from making use of JavaSpaces right now?

    Hi Steve,

    I've calm down a bit. Good point. I could be spotting a conspiracy where there isn't one. I'll give JINI and JavaSpaces a whirl.

    Paul.
  122. The Java Vision[ Go to top ]

    If decent JVMs had been bundled with most PCs, and kept up to date (this is the incompatible VMs issue), I believe applets would have become a major way to deliver decent functionality to desktops.

    Hi Steve,

    Alan Kays concerns about VM compatibility is based on the way the Java VM is licensed. Sun licensed other vendors to produce VMs that are compatible with the JVM Specification. Alan Kays concern is that if you are going to rely on replicated objects running on a range of platforms, then your code needs to run bit identical on each.

    The only way to guarantee this in his opinion is to use a common VM implementation on each platform. Squeak achieves this (across Linux, OSX and Windows XP) by writing the Squeak VM in itself. The Squeak VM is written in "pigeon" Squeak. This is compiled to C, then gcc is use to compile it to the target platforms.

    Croquet relies on object replication across VMs. Alan claims that bit identical behaviour across VMs is crucial for this. Who am I to disagree?

    So there is some reason to question whether Java can ever forfil it's original vision, but I do need to understand a bit more about JINI and JavaSpaces before pronouncing a final judgement :^).

    Paul.
  123. The Java Vision[ Go to top ]

    Paul,
    I've got a bit of a bee in my bonnet. It appears that I seem to be the only person with a clear recollection of history. Just to prove to my self that I weren’t making it all up I've done a bit of digging around. Javaworld has a number of articles on JINI and JavaSpaces that make it quite clear that JINI was Suns' inital vision for Java.
    Your recollection is correct but I disagree with your interpretation.

    Based on what you write, you seem to ascribe the failure of Jini and JavaSpaces to the fact that they were built in Java, which doesn't support late-binding. There are so many inaccuracies in this statement that I don't know where to start :-)

    First of all, Sun has this tendency to embrace a brand new vision every year, and this vision is usually "whatever comes out of the mouth of whatever personality has the spotlight that year". Bill Joy held the torch for a few years, and it appears that Jonathan Schwartz has been replacing him quite effectively these past years. And by "effectively", I mean that he comes up with a lot of visions, not that these visions work (because they haven't, so far).

    Jini, JavaSpaces, JXTA are all interesting academic experiments that have no applications in the real world, so it's not really surprising to see that they failed to gain any significant momentum in the industry. I don't think Java had anything to do with these failures, and I still firmly believe that Java has the potential to solve 99% of the software problems we encounter these days.

    --
    Cedric
  124. The Java Vision[ Go to top ]

    Paul,
    I've got a bit of a bee in my bonnet. It appears that I seem to be the only person with a clear recollection of history. Just to prove to my self that I weren’t making it all up I've done a bit of digging around. Javaworld has a number of articles on JINI and JavaSpaces that make it quite clear that JINI was Suns' inital vision for Java.
    Your recollection is correct but I disagree with your interpretation.Based on what you write, you seem to ascribe the failure of Jini and JavaSpaces to the fact that they were built in Java, which doesn't support late-binding. There are so many inaccuracies in this statement that I don't know where to start :-)First of all, Sun has this tendency to embrace a brand new vision every year, and this vision is usually "whatever comes out of the mouth of whatever personality has the spotlight that year". Bill Joy held the torch for a few years, and it appears that Jonathan Schwartz has been replacing him quite effectively these past years. And by "effectively", I mean that he comes up with a lot of visions, not that these visions work (because they haven't, so far).Jini, JavaSpaces, JXTA are all interesting academic experiments that have no applications in the real world, so it's not really surprising to see that they failed to gain any significant momentum in the industry. I don't think Java had anything to do with these failures, and I still firmly believe that Java has the potential to solve 99% of the software problems we encounter these days.-- Cedric
    Hi Cedric,
    Thanks for enlightening me. From what I know about how big corporations work, your explanation sounds about right :^)

    So I won't waste my time investigating JINI then.

    In short, you're right. I don't know why software technology is as bad as it is today. From an Agile perspective dynamic languages do offer a number of advantages, but even these languages are based on ideas that are over 30 years old. So my question is why hasn't any significant occured in software in the last say 20 years?

    I really do think that current web apps are an indictment on our industry, and if AJAX is all we've got to look forward to, then perhaps I should start looking for another job (setting up a bar on a beach somewhere sounds nice) :^).

    What is your take?

    Paul.
  125. The Java Vision[ Go to top ]

    Paul,
    I've got a bit of a bee in my bonnet. It appears that I seem to be the only person with a clear recollection of history. Just to prove to my self that I weren’t making it all up I've done a bit of digging around. Javaworld has a number of articles on JINI and JavaSpaces that make it quite clear that JINI was Suns' inital vision for Java.
    Your recollection is correct but I disagree with your interpretation.Based on what you write, you seem to ascribe the failure of Jini and JavaSpaces to the fact that they were built in Java, which doesn't support late-binding. There are so many inaccuracies in this statement that I don't know where to start :-)First of all, Sun has this tendency to embrace a brand new vision every year, and this vision is usually "whatever comes out of the mouth of whatever personality has the spotlight that year". Bill Joy held the torch for a few years, and it appears that Jonathan Schwartz has been replacing him quite effectively these past years. And by "effectively", I mean that he comes up with a lot of visions, not that these visions work (because they haven't, so far).Jini, JavaSpaces, JXTA are all interesting academic experiments that have no applications in the real world, so it's not really surprising to see that they failed to gain any significant momentum in the industry. I don't think Java had anything to do with these failures, and I still firmly believe that Java has the potential to solve 99% of the software problems we encounter these days.-- Cedric
    Hi Cedric,Thanks for enlightening me. From what I know about how big corporations work, your explanation sounds about right :^)So I won't waste my time investigating JINI then.In short, you're right. I don't know why software technology is as bad as it is today. From an Agile perspective dynamic languages do offer a number of advantages, but even these languages are based on ideas that are over 30 years old. So my question is why hasn't any significant occured in software in the last say 20 years?I really do think that current web apps are an indictment on our industry, and if AJAX is all we've got to look forward to, then perhaps I should start looking for another job (setting up a bar on a beach somewhere sounds nice) :^). What is your take?Paul.
    If there are good scuba diving spots around, count me in.

    Seriously, though, I don't share your pessimism. I think software engineering has made tremendous progress these past ten years, and I am saying this from my narrow Java perspective, which doesn't cover the Windows world.

    Between the advent of universal testing, dependency injection, Spring, EJB3, Java5, agile and XP, and so many other innovative products and ideas, it's hard to see what's not to be excited about...

    --
    Cedric
  126. The Java Vision[ Go to top ]

    Jini, JavaSpaces, JXTA are all interesting academic experiments that have no applications in the real world, so it's not really surprising to see that they failed to gain any significant momentum in the industry.
    Uh, sorry, this is false. Take a look at this thread for some real world uses of Jini, and a discussion about why the technology hasn't taken off:
    http://www.theserverside.com/news/thread.tss?thread_id=39931

    One great example of Jini/JavaSpaces in action is GigaSpaces (http://www.gigaspaces.com/), take a look at their case studies and customers list.
  127. The Java Vision[ Go to top ]

    Jini, JavaSpaces, JXTA are all interesting academic experiments that have no applications in the real world, so it's not really surprising to see that they failed to gain any significant momentum in the industry.
    Uh, sorry, this is false. Take a look at this thread for some real world uses of Jini, and a discussion about why the technology hasn't taken off:http://www.theserverside.com/news/thread.tss?thread_id=39931One great example of Jini/JavaSpaces in action is GigaSpaces (http://www.gigaspaces.com/), take a look at their case studies and customers list.
    Hi Henrique,

    Read through skimmed through the thread. Two points struct me.

    1. Everyone who has used JINI had good things to say about it.
    2. JINI and J2EE (App Servers and EJB) are some how seen as competing technologies.

    So Sun Markets the hell out of J2EE and stays pretty silent about JINI dispite the positive responses form its use community.

    Cedric, says that he has reasons to be positive about the current state of the software industry. There are postives. I agree that Agile development is making/has made a radical change in mindset within the developer community and is spreading to the business community. What I also see aligned with this is developers taking more responsiblity for their own futures by developing there own tools and software infrastructure open source.

    It is amazing to see what Alan Kay and a few friends have achieved open source (Squeak and Croquet) in contrast to what Microsoft, Sun, IBM et al have achieved over a much longer period and with huge "research and development" budgets. I've got stong opinions on why this is the case, but this post is too long as it is.

    Paul.
  128. The Java Vision[ Go to top ]

    So Sun Markets the hell out of J2EE and stays pretty silent about JINI dispite the positive responses form its use community.

    Sorry - Sun stays pretty silent about JINI? Is this silent:

    http://www.sun.com/software/jini/

    or this:

    http://java.sun.com/othertech/

    If you keep track of content on javasoft.com and java.net, JINI regularly makes an appearance.
    What I also see aligned with this is developers taking more responsiblity for their own futures by developing there own tools and software infrastructure open source.

    What I see as an important way forward is open source combining with good standards. JBoss+Tomcat and J2EE. Hibernate (and many others) with EJB 3. JPOX and JDO 2.0. Myfaces (and others) and JSF.
    It is amazing to see what Alan Kay and a few friends have achieved open source (Squeak and Croquet) in contrast to what Microsoft, Sun, IBM et al have achieved over a much longer period and with huge "research and development" budgets. I've got stong opinions on why this is the case, but this post is too long as it is.Paul.

    Interesting things have been done with dynamic languages for years. What matters with these things is to deliver a usable and pratical product, with security, performance and stability.

    There are plenty of projects which illustrate concepts, and provide a look at what the future may provide. Whether or not they are pratical solutions for everyday use is another matter. The croquet website says:

    "The Croquet SDK is intended for experienced self-sufficient software developers who are comfortable working with unsupported software with minimal documentation. You should be prepared for the possibility that parts of the system may not work, and that programming interfaces and the software structure may change as the system evolves."

    Hardly encouraging, is it? This sums up too much of the state of open source development.

    Also, you still haven't provided a convincing argument (to me at least) about why such things could not be done in Java. I think they can:

    http://savannah.nongnu.org/projects/bang/

    "Large Distributed Shared Persistent 3D Space (bangSpace) using Jini/JavaSpaces"

    (Probably just as poorly documented and incomplete, but perhaps illustrates the possibilities).
  129. Hi Steve,

    I mentioned in my post Agile values and principles changing the mindset of developers and business people alike. I once saw things much as you do. Having experienced Agile development, working along side some of the leading proponents in the UK (like Racheal Davies), I started to question a lot of my long held asssumptions.

    There is no guarantee that such an experiene would have the same effect on yourself, but it is an experience I would recommend to anyone. You've expressed an interest in Agile Development, if you live in London, UK, then there is a group that meets weekly:

    http://www.xpdeveloper.com/xpdwiki/Wiki.jsp?page=XtC

    Otherwise there is sure to be a group near you. Meet and discuss these issues with them. Better still pair program with them for a while, and you may find yourself questioning your assumption too.


    Paul.
  130. Hi Steve,I mentioned in my post Agile values and principles changing the mindset of developers and business people alike. Better still pair program with them for a while, and you may find yourself questioning your assumption too.Paul.

    I believe that you are assuming that I am not already a user of agile development techniques - a false assumption. My expression was that I was concerned that I was not using it enough.

    [I am not entirely sure how to respond to your concern for my software development education. Perhaps a polite 'thanks' is the best way].

    I don't mean this to sound like I am being deliberately contrary, but I used to think like you! For a very long time I was a strong supporter of dynamic languages. I have written major projects in Smalltalk, and have been using it on-and-off for more than 15 years. My criticisms of early Java implementations are on record in various mailing lists and newsgroups.

    But in, the end, I found that they simply did not deliver for general purpose use, especially for someone like me who works on a wide range of types of projects, from financial work to high-performance numerics, although I still use them for small aspects of my work (I wait eagerly for JRuby to mature). I was having to make too many compromises to justify my choice of main development language.

    But anyway, this is irrelevant to the matter being discussed, which is the history of web interfaces and the quality of approaches you are proposing as better ideas (such as Croquet).
  131. Hi Steve,

    I didn't mean to sound condescending. And I genuinely hoped that you wouldn't have taken my words that way. To me you feel like an old friend, and it is clear that we have different perspectives. The same mountain can look very different depending on the perspective you take.

    In life there is many ways to look at things. I think I understand where you are comming from (I developed like that for around 10 years). From the questions you ask and the way you pose them, I'm not sure that you are that familiar with my perspective. If you are and have chosen to reject it then fine. If not and you are interested in exploring it further (which was my assumption based on your continued contribution to this forum), then why not try out others who I believe share my perspective?

    A good place is the yahoo forums. You can talk to people like Kent Beck and Ron Jefferies directly. BTW it is not education, it is discussion and exchange of ideas and experiences. I don't think anyone in the Agile community claims to have the definative answers for all scenarios. Infact that is one aspect of Agile values and thinking that differentiates it from the main stream.

    Anyway, here are some links where you can get broader (Agile) opinions:

    http://groups.yahoo.com/group/scrumdevelopment/
    http://groups.yahoo.com/group/extremeprogramming/

    I'm sure you will make valuable contributions and prompt useful discussion. I'll be looking out for you.


    Paul.
  132. Hi Steve,I didn't mean to sound condescending. And I genuinely hoped that you wouldn't have taken my words that way. To me you feel like an old friend, and it is clear that we have different perspectives.

    Well, it did sound condescending, but I knew it was not meant that way!
     
    The same mountain can look very different depending on the perspective you take.In life there is many ways to look at things. I think I understand where you are comming from (I developed like that for around 10 years). From the questions you ask and the way you pose them, I'm not sure that you are that familiar with my perspective. If you are and have chosen to reject it then fine.

    But the thing is, I don't think you did develop like I am doing. You say that with Java you had considerable (and bad) experience with pre EJB-3.0 versions of J2EE, and were obviously and understandably put off by the experience.

    Well, I have always been a user of agile approaches in Java. I require fast test-driven development, so I use products and APIs that allow edit/test cycles of no more than a few seconds, even on J2EE. I use JSF/facelets, JDO, etc. These, to me, are agile approaches. I can tweak my facelets pages and get immediate feedback. I can change my JDO object model and a few seconds later I have a new database schema based on that model loaded with test data. This is still not quite agile enough for me - I would love to be able to reload changed JSF backing beans within an active J2EE application for example - but it is pretty good.

    I think that where we differ is in our attitude to static typing and the relative rigidity of languages such a Java. After decades of use of both static and dynamic languages, I have come to really value compile-time type checking, and you keep pointing out areas (such as client-side GUIs - back to the topic!) where you imply that not just late binding, but a total absence of interterfaces, is important. I remain unconvinced.
  133. Hi Steve,I didn't mean to sound condescending. And I genuinely hoped that you wouldn't have taken my words that way. To me you feel like an old friend, and it is clear that we have different perspectives.
    Well, it did sound condescending, but I knew it was not meant that way!&nbsp;
    The same mountain can look very different depending on the perspective you take.In life there is many ways to look at things. I think I understand where you are comming from (I developed like that for around 10 years). From the questions you ask and the way you pose them, I'm not sure that you are that familiar with my perspective. If you are and have chosen to reject it then fine.
    But the thing is, I don't think you did develop like I am doing. You say that with Java you had considerable (and bad) experience with pre EJB-3.0 versions of J2EE, and were obviously and understandably put off by the experience.Well, I have always been a user of agile approaches in Java. I require fast test-driven development, so I use products and APIs that allow edit/test cycles of no more than a few seconds, even on J2EE. I use JSF/facelets, JDO, etc. These, to me, are agile approaches. I can tweak my facelets pages and get immediate feedback. I can change my JDO object model and a few seconds later I have a new database schema based on that model loaded with test data. This is still not quite agile enough for me - I would love to be able to reload changed JSF backing beans within an active J2EE application for example - but it is pretty good.I think that where we differ is in our attitude to static typing and the relative rigidity of languages such a Java. After decades of use of both static and dynamic languages, I have come to really value compile-time type checking, and you keep pointing out areas (such as client-side GUIs - back to the topic!) where you imply that not just late binding, but a total absence of interterfaces, is important. I remain unconvinced.

    So you do see my perspective. If you've ever done TDD in Smalltalk and been given the ability to implement non existing methods during your test, within the debugger and then are able to continue execution, to the next test failure, then you must of thought to yourself "boy you can't get TDD development cycles shorter than this".

    As for the applicablity of dynamic languages on remote clients, I find Croquet convincing. I also find the arguments put forward by Alan Kay in justification of their design decisions pretty convincing too. In contrast to your assertions I have found Croquet very stable, well documented and well supported. In contrast to some, Alan Kay would rather play down "work in progress" software rather than make inflated claims for software that is still half backed (like many vendors do), hence the discliamer you found on the Croquet site. Download it and try it before forming your opinion, you will be surprised.

    I do not know how the open source Java system you make reference to performs, but I do know that Sun isn't exactly backing JINI (they've just given it away to apache, where it will either sink or swim on its own).

    You seem to think that there is a right way and a wrong way and a right language and a wrong language. My point is that there is neither, there are just horses for courses. You seem to want to cling on to a general purpose tool for everything. To me this is not Agile thinking. I prefer to value people over tools and processes and I work to coach and develop my team so that we are capable of using a multitude of tools and able to select the right tool for the job at hand. I haven't come across a developer who has a problem with this.

    In some instances this will be Java, in others it will be a shell script, in a next it may be Ruby. The most important ingredient being the person/people behind the keyboard. If the tools commercially available do not meet our needs, then we either write our own, or share tools written by teams that work in a similar way to ourselves open source. We do not fit ourselves around "standards" and standard tools. We find/create tools that fit us and our problems. Like I said if you get onto the Agile forums you will come across a whole bunch of people that see things pretty much the same way. I'm not that unusual.

    Paul.
  134. So you do see my perspective. If you've ever done TDD in Smalltalk and been given the ability to implement non existing methods during your test, within the debugger and then are able to continue execution, to the next test failure, then you must of thought to yourself "boy you can't get TDD development cycles shorter than this".

    Yes - it is simply fantastic. I have never found anything to match the phenomental power and speed of development of the Smalltalk debugger. I miss it hugely.

    But I don't see the point in doing very fast development in a language that is inadequate for so many of my requirements.
    In contrast to your assertions I have found Croquet very stable, well documented and well supported. In contrast to some, Alan Kay would rather play down "work in progress" software rather than make inflated claims for software that is still half backed (like many vendors do), hence the discliamer you found on the Croquet site.

    Sure, but I am looking for software that I can use to run high-reliability commercial systems and websites. Croquet may be interesting for research or education, but I am not going to use it to handle credit card payments.
    You seem to think that there is a right way and a wrong way and a right language and a wrong language. My point is that there is neither, there are just horses for courses. You seem to want to cling on to a general purpose tool for everything. To me this is not Agile thinking.

    I think you are over-emphasising my point. I am not saying that there is a right language for everything; just that leaping lightly from language to language is not a productive way to work when you are a small team trying to build up repositories of code, skills and templates. I am currently using facelets. I picked it up very fast, and my way of working is far more agile because I use it. Why did I pick it up fast? Because another member of my team already had the expertise. If I had decided to use PHP, I could not have used his skills both in the technology itself, and in the use of a range of JSF components. Lightly switching between languages can mean you don't build up deep knowledge and experience of them. There is enough to keep up with and learn in Java alone....

    My view is that a team should pick their general purpose language and stick with for most development where possible. If they decide it is Ruby, or Smalltalk, fine. I have chosen Java because I have requirements for very high performance work. I have had a lot of experience where the initial scoping of a project did not reveal later much higher demand for scalability and processing power.
    I prefer to value people over tools and processes and I work to coach and develop my team so that we are capable of using a multitude of tools and able to select the right tool for the job at hand. I haven't come across a developer who has a problem with this.

    I have! I have seen projects degrade into a real mess because developers skilled in one technology have decided that there was a better tool for the job, and re-written substantial codebases in systems they turned out to be unfamiliar with, also abandoning valuable libaries in the original languague.
    In some instances this will be Java, in others it will be a shell script, in a next it may be Ruby. The most important ingredient being the person/people behind the keyboard. If the tools commercially available do not meet our needs, then we either write our own, or share tools written by teams that work in a similar way to ourselves open source. We do not fit ourselves around "standards" and standard tools. We find/create tools that fit us and our problems. Like I said if you get onto the Agile forums you will come across a whole bunch of people that see things pretty much the same way. I'm not that unusual.Paul.

    The most important ingredient is often not the person behind the keyboard - it is the team, and the skills and code that the team has built up over possibly years of working together. If you neglect such stores of skill and code you are being highly wasteful. I also strongly feel (based on considerable experience) that if you don't use standards and common tools you are also neglecting far larger stores of skill and code. The Not Invented Here syndrome is very common in IT and can be a huge waster of time and resources. I know - because I used to be guilty of it! It was fun to develop my own solutions. Fortunately, I now eagerly seek out products that solve problems for me.

    Standards are important in other ways. If you don't use them, you are taking a risk. You may be lucky, and your choice of product may be like Hibernate, and become wildly successful. Or you may not be, and support for your product may be dropped. With standards you can switch easily to alternatives - which is something I have found vital in recent projects.

    Being Agile has nothing to do with abandoning standards.
  135. In some instances this will be Java, in others it will be a shell script, in a next it may be Ruby. The most important ingredient being the person/people behind the keyboard. If the tools commercially available do not meet our needs, then we either write our own, or share tools written by teams that work in a similar way to ourselves open source. We do not fit ourselves around "standards" and standard tools. We find/create tools that fit us and our problems. Like I said if you get onto the Agile forums you will come across a whole bunch of people that see things pretty much the same way. I'm not that unusual.Paul.
    The most important ingredient is often not the person behind the keyboard - it is the team, and the skills and code that the team has built up over possibly years of working together. If you neglect such stores of skill and code you are being highly wasteful. I also strongly feel (based on considerable experience) that if you don't use standards and common tools you are also neglecting far larger stores of skill and code. The Not Invented Here syndrome is very common in IT and can be a huge waster of time and resources. I know - because I used to be guilty of it! It was fun to develop my own solutions. Fortunately, I now eagerly seek out products that solve problems for me.Standards are important in other ways. If you don't use them, you are taking a risk. You may be lucky, and your choice of product may be like Hibernate, and become wildly successful. Or you may not be, and support for your product may be dropped. With standards you can switch easily to alternatives - which is something I have found vital in recent projects.Being Agile has nothing to do with abandoning standards.
    This is the crux of the difference. Valuing people to me means making the people the crucible of your technical advantage, not the tools or some arcane repository of out dated code from the past.

    Many companies try to manage risk by "out sourcing" technology decision making to vendors. They feel that they will be "safe" by using "standard" tools and hiring readily available "skills" in the market. Is this really valuing their people?

    How about building teams of people that have a track record of delivering, and trusting in them to choose their own tools? You asume that development teams need to be protected from themselves, I too have seen this scenario, but doesn't that mean that you haven't developed/hired the right people?

    At the centre must be the people. There is no "God" inside your Java compiler. When programming, the developer is God, he/she can create a mess or a masterpiece.

    The intelligence is in the people. They need to be empowered to act creatively. We work very closely as a team, pair programming, and communicating daily at stand-up meetings. We do this to spread best practice. We like to think that we are as strong as our strongest link in any given area of expertise, rather than being limited by our weakest link, which is so often the case in traditional waterfall teams.

    We encourage creative thinking and finding novel and creative ways to solve problems. We communicate and share experiences and ideas with the Agile community at large with a view to adopting best practices and achieving continuous improvements in our performance.

    It is a completely diferent premise, and it leads to different decision making, and ultimately IMO different technology choices.

    Paul.
  136. Formatting again...
    In some instances this will be Java, in others it will be a shell script, in a next it may be Ruby. The most important ingredient being the person/people behind the keyboard. If the tools commercially available do not meet our needs, then we either write our own, or share tools written by teams that work in a similar way to ourselves open source. We do not fit ourselves around "standards" and standard tools. We find/create tools that fit us and our problems. Like I said if you get onto the Agile forums you will come across a whole bunch of people that see things pretty much the same way. I'm not that unusual.Paul.
    The most important ingredient is often not the person behind the keyboard - it is the team, and the skills and code that the team has built up over possibly years of working together. If you neglect such stores of skill and code you are being highly wasteful. I also strongly feel (based on considerable experience) that if you don't use standards and common tools you are also neglecting far larger stores of skill and code. The Not Invented Here syndrome is very common in IT and can be a huge waster of time and resources. I know - because I used to be guilty of it! It was fun to develop my own solutions. Fortunately, I now eagerly seek out products that solve problems for me.Standards are important in other ways. If you don't use them, you are taking a risk. You may be lucky, and your choice of product may be like Hibernate, and become wildly successful. Or you may not be, and support for your product may be dropped. With standards you can switch easily to alternatives - which is something I have found vital in recent projects.Being Agile has nothing to do with abandoning standards.

    This is the crux of the difference. Valuing people to me means making the people the crucible of your technical advantage, not the tools or some arcane repository of out dated code from the past. Many companies try to manage risk by "out sourcing" technology decision making to vendors. They feel that they will be "safe" by using "standard" tools and hiring readily available "skills" in the market. Is this really valuing their people?

    How about building teams of people that have a track record of delivering, and trusting in them to choose their own tools? You asume that development teams need to be protected from themselves, I too have seen this scenario, but doesn't that mean that you haven't developed/hired the right people?At the centre must be the people. There is no "God" inside your Java compiler. When programming, the developer is God, he/she can create a mess or a masterpiece.

    The intelligence is in the people. They need to be empowered to act creatively. We work very closely as a team, pair programming, and communicating daily at stand-up meetings. We do this to spread best practice. We like to think that we are as strong as our strongest link in any given area of expertise, rather than being limited by our weakest link, which is so often the case in traditional waterfall teams. We encourage creative thinking and finding novel and creative ways to solve problems. We communicate and share experiences and ideas with the Agile community at large with a view to adopting best practices and achieving continuous improvements in our performance.

    It is a completely diferent premise, and it leads to different decision making, and ultimately IMO different technology choices.

    Paul.
  137. This is the crux of the difference. Valuing people to me means making the people the crucible of your technical advantage, not the tools or some arcane repository of out dated code from the past. Many companies try to manage risk by "out sourcing" technology decision making to vendors. They feel that they will be "safe" by using "standard" tools and hiring readily available "skills" in the market. Is this really valuing their people?

    Of course you value people! For me, allowing workers to build up skills and experience, and allowing them to re-use that experience shows that you value them. Using standards and standard tools is nothing whatsoever to do with whether or not you are going to outsource or hire. It allows your people to get a sense of contributing to the worth of the company when their code becomes part of a valuable repository.

    Also, your comment about 'outdated code and arcade repository' means that I am probably not communicating well what I mean. For many purposes, 'legacy' code (which can mean code even from very recent projects) is certainly not outdated or arcade - this code is tested, optimised and debugged and its use can save vast amounts of time for future projects. Even if the code can't be used directly, it can be used as a templates for future design - you have worked examples of use cases.

    Remember Smalltalk? One of the key ideas about Smalltalk development is supposed to be code reuse - don't reinivent; search the huge class library for what you need, and re-use existin - refactor it, subclass it, do what you like, but don't start from scratch and re-invent things. Do this with your code as well.

    Two examples: first, numeric work. Any development team in this area that did not build up a repository of quality code should be considered extremely incompetent, and to re-implement this code in multiple development languages is supremely wasteful. Major parts of future projects can be implemented through re-use.

    Second example: graphics work. I occasionally write software that does image processing. I have built up a libary of code and techniques that uses Java Advanced Imaging. To decide in a future project to use, say, Delphi, would not make sense, as this code could not be used, and entire new techniques and libraries would have to be researched and implemented - a pointless and self-indulgent exercise.
    The intelligence is in the people. They need to be empowered to act creatively. We work very closely as a team, pair programming, and communicating daily at stand-up meetings.

    You should see the way I work - communication only daily is a rare thing - usually restricted to days that are supposed to be vacation times!
    We do this to spread best practice. We like to think that we are as strong as our strongest link in any given area of expertise, rather than being limited by our weakest link, which is so often the case in traditional waterfall teams. We encourage creative thinking and finding novel and creative ways to solve problems.

    We do too, but we don't consider that using standards in anyway compromises creativity - it actually encourages and focuses it, because it prevents so much 're-inventing of the wheel' and allows creativity to focus on other things. You are finding novel and create ways to solve the problems that actually need to be solved, and not solving problems that someone else has already solved for you. This is best practice - choosing the right standards.

    Valuing people and valuing repositories of code and techniques build up over years is not mutually exclusive, you know!
    It is a completely diferent premise, and it leads to different decision making, and ultimately IMO different technology choices.

    You say this, but then you have also often said that you have not evaluated many of the technology choices that I use on a daily basis - JDO, JSF etc. I am not sure what your choices and decision making are different from.... but I don't think you can be sure you would make different choices from a large number of Java developers like me unless you have seriously tried out the tools and we are using. I believe you may find that we are not that different from you!
  138. Hi Steve,

    I've read what you've said, and in general you seem to wnt to make a lot of decisions ahead of time. Why not trust in your team to make the right decisions on a case by case basis?
    Of course you value people! For me, allowing workers to build up skills and experience, and allowing them to re-use that experience shows that you value them. Using standards and standard tools is nothing whatsoever to do with whether or not you are going to outsource or hire. It allows your people to get a sense of contributing to the worth of the company when their code becomes part of a valuable repository.
    You seem to contradict yourself here. Re-using experience has nothing to do with re-use of code. Design patterns are a re-use of shared experience but it doesn't require code. For a lot of companies "standards" have everything to do with how they hire. My team recently recieved a job spec for a "Java Project" within another part of the organisation. The Managers had written the spec including all the standard Java tools (EJB's , JSF, Websphere, etc), it turns out that they didn't know what they were going to build and how they were goign to uild it, yet they wanted us to assess the job spec for applicability? I'm a contractor and such things are not uncommon.


    Also, your comment about 'outdated code and arcade repository' means that I am probably not communicating well what I mean. For many purposes, 'legacy' code (which can mean code even from very recent projects) is certainly not outdated or arcade - this code is tested, optimised and debugged and its use can save vast amounts of time for future projects. Even if the code can't be used directly, it can be used as a templates for future design - you have worked examples of use cases.
    As I've said before, there is a clear distinction between application code and re-useable libraries. Application code is for mere mortals like me. Achieving true re-use is a whole different ball game. I have seen projects falter trying to apply re-use when they could have delivered in a fraction of the time if they had stuck to application coding (writing specifically what they needed). The goal is working production code in the shortest time possible, not re-use.
    Remember Smalltalk? One of the key ideas about Smalltalk development is supposed to be code reuse - don't reinivent; search the huge class library for what you need, and re-use existin - refactor it, subclass it, do what you like, but don't start from scratch and re-invent things. Do this with your code as well.Two examples: first, numeric work. Any development team in this area that did not build up a repository of quality code should be considered extremely incompetent, and to re-implement this code in multiple development languages is supremely wasteful. Major parts of future projects can be implemented through re-use.
    The Smalltalk class library was evolved and developed over 15 years of research. I have never worked on a 15 year project. Good class libraries emerge over time, and hence aren't feasible in the time frame of most projects. Library design is hard, as application developers we are better off sticking to "off the shelf" libraries like the Smalltalk class lbrary, rather than tring to create such things ourselves. Doing so is just wasting time.
    I believe you may find that we are not that different from you!
    The difference is that Agile organisations trust their teams and judge them on their results. The team decides whether using a standard is the best approach on a case by case basis, or whether a non standard open source tool is a better way to go (all things considered). Such decisions are not made ahead of time, by Managers or Chief Architects - they are left to the team that has committed to deliver. The team is judged on its velocity (the rate at whichthe produce working code)and whether that velocity is sustained.

    Paul.
  139. Hi Steve,I've read what you've said, and in general you seem to wnt to make a lot of decisions ahead of time. Why not trust in your team to make the right decisions on a case by case basis?

    Actually I don't have 'a team' - I have colleagues and we all work together. As I state below, you are profoundly mistaken if you thing we don't evaluate things on a case-by-case basis. Sorry, but it seems to me that you are making a lot of assumptions about me and the way I work simply on the basis of the fact that I disagree with you, and have different opinions.

    By the way, more about trust in another post!
    You seem to contradict yourself here. Re-using experience has nothing to do with re-use of code. Design patterns are a re-use of shared experience but it doesn't require code.

    I am not talking about design patterns. I am talking about repositories consisting of hundreds of thousands of lines and tried and tested libraries.
    As I've said before, there is a clear distinction between application code and re-useable libraries. Application code is for mere mortals like me.

    Not for me - we work in different areas.
    Achieving true re-use is a whole different ball game. I have seen projects falter trying to apply re-use when they could have delivered in a fraction of the time if they had stuck to application coding (writing specifically what they needed). The goal is working production code in the shortest time possible, not re-use.

    Precisely. And I have seen projects falter because they did not re-use code - they could have delivered projects in a fraction of the time if they had stuck to reuse, writing specifically only what they needed rather than trying to re-invent things.
    Remember Smalltalk? One of the key ideas about Smalltalk development is supposed to be code reuse - don't reinivent; search the huge class library for what you need, and re-use existin - refactor it, subclass it, do what you like, but don't start from scratch and re-invent things. Do this with your code as well.Two examples: first, numeric work. Any development team in this area that did not build up a repository of quality code should be considered extremely incompetent, and to re-implement this code in multiple development languages is supremely wasteful. Major parts of future projects can be implemented through re-use.
    The Smalltalk class library was evolved and developed over 15 years of research. I have never worked on a 15 year project.
    Precisely! And this is the critical difference between us. I have worked on projects which have been on-going over more than decade.
    Good class libraries emerge over time, and hence aren't feasible in the time frame of most projects. Library design is hard, as application developers we are better off sticking to "off the shelf" libraries like the Smalltalk class lbrary, rather than tring to create such things ourselves.

    Exactly. I have worked on long-term projects (and groups of projects) where good libraries have emerged over a very long time. And you are contradicting yourself. You don't want to stick to standards, would rather create things yourself, but standards allow you to use "off the shelf" libraries and concentrate on application code.
    The difference is that Agile organisations trust their teams and judge them on their results. The team decides whether using a standard is the best approach on a case by case basis, or whether a non standard open source tool is a better way to go (all things considered). Such decisions are not made ahead of time, by Managers or Chief Architects - they are left to the team that has committed to deliver. The team is judged on its velocity (the rate at whichthe produce working code)and whether that velocity is sustained.Paul.

    Why do you think we are not doing this? Of course we evaluate the best tools each time! However, having a repository of skills and libraries and experience means that we increasingly come to the same (Java + standards).
  140. Missed out a bit...
    How about building teams of people that have a track record of delivering, and trusting in them to choose their own tools? You asume that development teams need to be protected from themselves, I too have seen this scenario, but doesn't that mean that you haven't developed/hired the right people?

    You don't seem to understand what I am saying. For the majority of where I work, as a team, we have chosen Java together. They share my view of the language and its strengths. This is not imposed.
    At the centre must be the people. There is no "God" inside your Java compiler. When programming, the developer is God, he/she can create a mess or a masterpiece.

    This is just plain wrong (apart from the religous bit). Of course developers need to be protected from themselves. I need to be protected from my own coding! To assume that a developer can make an equal mess in any language is to simply ignore the harsh lessons from more than 50 years of language development. We are all human and make mistakes, but those mistakes have far, far worse consequences in a language like C++ than Java, for example. Furthermore, in a language like Java, you almost always get an automatic performance and scalability advantage over many other languages. I have personal experience of situations where a poor-performing and inadequate piece of software has become a 'masterpiece' that efficiently delivers results just by porting to a different language. This is not a matter of poor quality development - the first language simply was not capable.

    So, sorry, but I fundamentally disagree with you about this.
  141. Missed out a bit...
    How about building teams of people that have a track record of delivering, and trusting in them to choose their own tools? You asume that development teams need to be protected from themselves, I too have seen this scenario, but doesn't that mean that you haven't developed/hired the right people?
    You don't seem to understand what I am saying. For the majority of where I work, as a team, we have chosen Java together. They share my view of the language and its strengths. This is not imposed.

    Everyone in the team has exactly the same view? And everyone's view remains the same despite the nature of the project? I find this hard to believe. You seem to have quite a strong personality. Try listening to your team members and you may find that some of them have all kinds of interesting ideas very different to your own. I'm not knocking you, I'm just talking from personal experience. When you go in next week get the team to brainstorm a list of technologies and approches that they think could improve the teams performance. Sit back and say nothing, you may be surprised at what you hear.

     
    At the centre must be the people. There is no "God" inside your Java compiler. When programming, the developer is God, he/she can create a mess or a masterpiece.
    This is just plain wrong (apart from the religous bit). Of course developers need to be protected from themselves. I need to be protected from my own coding! To assume that a developer can make an equal mess in any language is to simply ignore the harsh lessons from more than 50 years of language development. We are all human and make mistakes, but those mistakes have far, far worse consequences in a language like C++ than Java, for example. Furthermore, in a language like Java, you almost always get an automatic performance and scalability advantage over many other languages. I have personal experience of situations where a poor-performing and inadequate piece of software has become a 'masterpiece' that efficiently delivers results just by porting to a different language. This is not a matter of poor quality development - the first language simply was not capable.

    I believe the best flight booking software out there for a long time was written in assembler in the 1960's. Now I'm not advocating assembly programming :^), but it just goes to show that good programmers are a lot more important than the chosen programming language.

    Most programmers today do not appreciate the strengths and weaknesses of various programming languages, never mind how best to exploit any given language. I think the focus on technology is all wrong, and has largely been lead by vendors who's sole aim is to sell technology to Managers and strategests. Agile values and agile thinking is all about bringing the focus back to where it belongs, on people and their abilities. Programming is an intellectual exercise and good programmers will choose the right tools for the job.
    So, sorry, but I fundamentally disagree with you about this.

    All I can say is don't knock it until you've tried it. I was skeptical too, until I experienced it working in practice.

    If you get a chance to work on a full blown Agile team, self organised, with short iterations, pair programming, a product backlog, monitoring of team velocity, regular releases, retrospectives etc. then give it a go.

    As I've said before I've done it both ways. At the moment we are using Java for production code, shell scripts for project automation and Ruby for Testing. None of our code is a mess, and I would never go back to working the way you describe.

    Paul.
  142. Everyone in the team has exactly the same view? And everyone's view remains the same despite the nature of the project?

    Of course they don't! I never said that. We come to agreements after much discussion and debate.
    I find this hard to believe. You seem to have quite a strong personality.

    Not as strong as others on the team!
    Try listening to your team members and you may find that some of them have all kinds of interesting ideas very different to your own. I'm not knocking you, I'm just talking from personal experience.

    How on Earth do you come to the conclusion that we don't do this all the time? You are in no position to know how I work or what my 'team' thinks.
    When you go in next week get the team to brainstorm a list of technologies and approches that they think could improve the teams performance.

    Please see response to previous statement.
    I believe the best flight booking software out there for a long time was written in assembler in the 1960's. Now I'm not advocating assembly programming :^), but it just goes to show that good programmers are a lot more important than the chosen programming language.

    Sorry, but this simply does not follow. Just because good programmers can tolerate developing in assembler does not mean by any stretch of the imagination that choice of language is not very important.
    Most programmers today do not appreciate the strengths and weaknesses of various programming languages, never mind how best to exploit any given language.

    Exactly. Which fully backs my point that flipping from language to language is silly. Developers need time to build up expertise. Only through long-term use can a team find out how best to use a language.
    I think the focus on technology is all wrong, and has largely been lead by vendors who's sole aim is to sell technology to Managers and strategests.

    You are contradicting yourself here. A huge amount of Java use is not imposed by managers and strategists, but chosen by developers who like the language. Why don't you trust the developer teams to make this judgement?

    In fact one of the most important ways that programming languages get adopted is through their initial use by students and amateurs, who then encourage their use in later employment. Java, like almost all highly successful languages, was adopted from the ground up, not imposed by management or marketing. It was the fact that it was free and anyone could play with it.
    All I can say is don't knock it until you've tried it. I was skeptical too, until I experienced it working in practice.If you get a chance to work on a full blown Agile team, self organised, with short iterations, pair programming, a product backlog, monitoring of team velocity, regular releases, retrospectives etc. then give it a go.

    You keep implying that I don't work like this in most respects. I don't know why.
    As I've said before I've done it both ways. At the moment we are using Java for production code, shell scripts for project automation and Ruby for Testing. None of our code is a mess, and I would never go back to working the way you describe.Paul.

    Firstly - I use ruby for part of my testing was well! (JRuby, actually).

    Secondly, you need to understand that I work on significantly different projects that you - projects that have years (or even more than a decade) of history, projects that have hundreds of thousands of lines of valuable code and tools. Such projects have fundamentally different considerations, as you are writing code that is expected to still be in place for years (or even more than a decade) in the future (I am still supporting Smalltalk code I wrote in the early 90s!). The idea of sitting down at a meeting and suddenly deciding to write the next major bit of the project in Ruby is simply ludicrous, or to suddenly switch a major part of the development to PHP because a new team member thinks it is neat, when all other parts are in J2EE/JDO, is also ridiculous. Even though these things are ridiculous, I have seen this kind of thing happen!

    But even with all this legacy and long-term planning, it is, of course, still easy to work in an agile way, with constant review, strategy meetings, frequent client-reviewed releases, test driven development etc.
  143. Hi Steve,

    Yes you are quite right. I did make a lot of assumptions, but the points I made apply to a lot of organisations. I apologise since your set of circumstances do sound quite unique.

    In fact this is my point. Every development team is unique, and I could acuse you of making a lot of assumptions about me too. If we all face diferent problems in different environmens how can we all do things the same way using the same language and tools?

    As you can tell I hate rules, and I truly believe they are anti-Agile. Then again I would not want to be 100% Agile in all circumstances. The degree of "Agility" should fit the organisation and the business need. In some situations change is less of a constant and longer term thinking is more important.

    I agree with you, and I hope you can see the sense in the general points I was trying to make:

    1. The people/team are more important than the tools/language.
    2. if enabled the people/team will find a way to solve their own problems the best way they see fit.
    3. Imposing "standard" solutions from outside the team for what ever reason is a bad idea.

    I can see that what you and your "colleagues" are doing is not inconsistent with these principles. We just work in different environments, and hence make different choices.

    Paul.
  144. Hi Steve,Yes you are quite right. I did make a lot of assumptions, but the points I made apply to a lot of organisations. I apologise since your set of circumstances do sound quite unique.In fact this is my point. Every development team is unique, and I could acuse you of making a lot of assumptions about me too. If we all face diferent problems in different environmens how can we all do things the same way using the same language and tools?As you can tell I hate rules, and I truly believe they are anti-Agile. Then again I would not want to be 100% Agile in all circumstances. The degree of "Agility" should fit the organisation and the business need. In some situations change is less of a constant and longer term thinking is more important.I agree with you, and I hope you can see the sense in the general points I was trying to make:1. The people/team are more important than the tools/language.2. if enabled the people/team will find a way to solve their own problems the best way they see fit.3. Imposing "standard" solutions from outside the team for what ever reason is a bad idea.I can see that what you and your "colleagues" are doing is not inconsistent with these principles. We just work in different environments, and hence make different choices.Paul.

    Actually, I don't think my circumstances are that unique!

    I enjoy debate, and I would would be happy discussing things further, but I think this off topic, and probably not that interesting for TSS readers. If you would like to continue things by e-mail, you are welcome to contact me at steve(at)parkplatz(dot)net.
  145. Actually, I don't think my circumstances are that unique!

    I think many of us are in the middle...
    I enjoy debate, and I would would be happy discussing things further, but I think this off topic, and probably not that interesting for TSS readers.

    Your bantering has kept me coming back to this thread and others. Keep it up.
  146. Hi Guys,

    I didn't know you were listening in Erik. I'm enjoying the discussion too. I agree with Steve though that this type of debate isn't really that suited to TSS.

    I'm sure Erik could offer some input too. If I sound like I know how we all should be developing software then let me make one thing clear - I don't.

    The Agile community doesn't know either (neither do they claim to know). My guess is that there isn't one way, but questioning and reflecting on how we work can only make us improve.

    If you guys are interested, then why not post questions on any of the Agile forums I mentioned. There are people out there a lot more brighter than me more than happy to debate these ideas.

    http://groups.yahoo.com/group/scrumdevelopment/
    http://groups.yahoo.com/group/extremeprogramming/

    Just let me know when you do.

    BTW. Steve I'll be in touch. Thanks for the e-mail.

    Paul.
  147. My guess is that there isn't one way, but questioning and reflecting on how we work can only make us improve.

    Absolutely. Which is I think that really vigorous discussions like this are so healthy. I have found, over the years, that a great way to learn new things is to put forward a point of view with energy and enthusiasm and then be proved wrong!
    If you guys are interested, then why not post questions on any of the Agile forums I mentioned.

    I think such discussions are better held in a more neutral forum?

    But I will take a look.
  148. The right tool for the job[ Go to top ]

    If Java adopted language features that suited the kind of things we are talking about then it would be the right tool for the job.The whole discussion is not about language, it is about computer science and software engineering.
    The two are inseparable.

    I think all three are separable, and should be separated (well, they're obviously closely related).

    As a computer scientist I think static typing is an annoying kludge that gets in the way of the elegant expression of algorithms.

    As a software engineer I think static typing adds a layer of robustness and validation that enables me to build better, more maintainable systems. That being said, metaprogramming in dynamic languages can reduce code size significantly, increase logic density, and perform domain-sensitive validations. It can also do interface/protocol checking, but the fact that I have to explicitly code in that level of safety is extremely annoying (and hopefully with be fixed in Python 3000). As an engineer I strongly oppose what I'll call "tacit interfaces" (as opposed to implicit) that Paul is advocating.

    As a project manager I think that not all problems require a robust, well engineered solution. Many things are just misinterpretted whims of vice presidents and directors that will fade with changes in the organizational structure. Sometimes Excel or Access is right for the job because having as many developers working on an application as there are users just doesn't make sense.
  149. The right tool for the job[ Go to top ]

    I Agree.

    I'd like to think that I'm pretty pragmatic. Use the right tool for the job and do the simplest thing that possibly work.

    BTW I weren't 'advocating' 'tacit' interfaces as you describe them, I was merely pointing out this 'feature' of dynamic languages.

    Incidently I agree with your description of 'implicit' interfaces as exisiting in the developers mind (at the point when he/she is coding the sender). I guess a 'tacit' interface is what is actually checked by the VM at runtime, which comes back to testing. If you test fully, then as long as you meet your design specification, does it really matter if your mental image isn't exactly the same as what is actually executing? (there are often loads of methods that are part of an objects interface, but I have no interest in, and hence do not form part of my mental picture in this scenario).

    If the difference is significant then one of your tests should fail (or you need to write more tests). As allways I tend to think of things from an XP (TDD) perspective.

    Paul.
  150. BTW I weren't 'advocating' 'tacit' interfaces as you describe them, I was merely pointing out this 'feature' of dynamic languages.

    Since I'm largely making words up, I'll forgive you for misunderstanding me... ;-)

    1. Explicit Interface - what we have in Java, formally defined in the programming language and required
    2. Tacit Interface - aka duck typing, objects must support a protocol, but it's all in the programmer's head (well, it could also be in documentation)
    3. Implicit Interface - I know of no language that supports this, but my idea is that, for example, a method specifies an interface that an object must support (this could possibly be deduced by the compiler rather than being explicitly defined, but that would only work with concrete methods, not abstract ones), but classes don't have to explicitly declare that they implement the interface. The compiler then validates that an object conforms to the interface, and (possibly) generates code to wrap the object in a proxy that explicitly supports the interface.

    So explicit == specified by the programmer everywhere
    Tacit == the compiler knows nothing about it
    Implicit == the compiler intelligently performs validations with minimal explicit type information.

    Clear? If you have any suggestions for better terms (or "official" ones), let me know.
  151. a prime example[ Go to top ]

    Thank you Erik an excellent post!

    You don't mind if I save away this one do you?

    Best regards
    Rolf Tollerud
    ("Subtle sarcastic humor always goes over so well on TSS")
  152. Java wasn't up to the Job[ Go to top ]

    Sorry I cannot share your opinion regarding being com as a phantastic component model, it has good ideas, but lacks totally in implementation. Instead of giving a clean and mean programming model, you have to go through all the C layer hoops, registry registration via uuid etc... etc...It is funny that you need several hundred lines of code in com
    You are mixing up interface and implementation.

    You are right that programming COM in C and C++ is a nightmare, but try in C# or Visual Basic (or even Java!) and it's really, really easy. You instantiate an Excel object in one line and each operation becomes a method call.

    The idea is valid, solid and has been copied many times since then (and to be honest, it's hard to tell who of COM or CORBA inspired the other, but it's probably fair to say they built on each other).

    --
    Cedric
  153. Java wasn't up to the Job[ Go to top ]

    Ah come on, Steve, that's a bit simplistic.The reasons why Java never worked on the desktop are well-known:* Rigid security manager that doesn't let the applet do anything interesting.* Discrepancy between the current JDK's and the ones used inside browser.* UI blindness: applets are a black box with their own navigation and focus rules.* Long start-up time.* Isolation: applets know nothing about their environment (DOM and browser).Microsoft has nothing to do with that.-- Cedric

    Much of this is wrong if you have a decent JRE installed. Since Java 1.2 there has been fine grained control of applet security, so that applets can definitely do interesting things. The long start-up time need not be an issue with modern Java plug-ins, and applets can certainly know about their environment, through APIs LiveConnect, which has been around for a very long time.

    Sorry, but I think Microsoft did have a lot to do with this, because of the discrepancy between modern JDKs and the one pre-installed in a PC - something they have encouraged. With a decent modern JRE installed applets can be a very powerful tool for developing a GUI, but with the very old version that Microsoft shipped, your critisms apply.
  154. AJAX = Workaround[ Go to top ]

    If you want to run a RIA without bookmarking or any kind of hyperlinking, you have to ask yourself whether the browser is the best platform. If all you get is incompatibility grief without the benefits enjoyed from hypertext, maybe we should just put the browser to one side and get on and use something more relevant.

    For self-contained apps, something like XULRunner may be a better bet (when its packaging improves. Too complex, IMO). Even Flash or SVG can be run standalone.

    So why does everything have to be browser based? To conform to some unquestioning herd instinct?

    UI developers of the world, unite! You have nothing to lose but your chains!

    ;)
    Kit
  155. AJAX = Workaround[ Go to top ]

    So why does everything have to be browser based?
    because it is the single most widespread platform in existence today and for some time to come? Because it offers one of the simplest deploy/install/use (from client POV) solutions today?
  156. AJAX = Workaround[ Go to top ]

    So why does everything have to be browser based?
    because it is the single most widespread platform in existence today and for some time to come? Because it offers one of the simplest deploy/install/use (from client POV) solutions today?
    Baaaaaa.
  157. AJAX = Workaround[ Go to top ]

    because it is the single most widespread platform in existence today and for some time to come?
    Please note I was talking about RIAs. Is your comment above really true for them? I thought the problem was with all the incompatibilities. To me that doesn't make it much of a 'platform'.
    Because it offers one of the simplest deploy/install/use (from client POV) solutions today?
    And the first thing that happens when a developer wants to create a RIA is to choose a suitable plugin to run it in. So all the browser is doing is hosting the plugin. It's all a bit daft, IMHO.

    Regards
    Kit
  158. AJAX = Workaround[ Go to top ]

    because it is the single most widespread platform in existence today and for some time to come?
    Please note I was talking about RIAs. Is your comment above really true for them? I thought the problem was with all the incompatibilities. To me that doesn't make it much of a 'platform'.
    Compatibility problems or not, these is a very clear and recognizable set of related technologies in wide use today, so why not label it all a platform? And regarding RIA, see AJAX/web 2.0 (I don't like the names, but it had to be named anyway, so...). Most compatibility problems have been solved a long time ago with the use of such frameworks.
    Because it offers one of the simplest deploy/install/use (from client POV) solutions today?
    And the first thing that happens when a developer wants to create a RIA is to choose a suitable plugin to run it in. So all the browser is doing is hosting the plugin. It's all a bit daft, IMHO.RegardsKit
    Developers can choose from many javascript toolkit in existence today to create RIA without browser plugins, take a look at RICO, DOJO, QOOXDOO and many others available today.
    But If you'd have to host a browser plugin in order to reach RIA, then I igree we should instead go all the way to JWS or other complete deployment solution. But IMO AJAX today fulfills many RIA requirements.
  159. I dont get it, ajax can be implemented with < 25 lines of javascript code that sets the innerHTML of an element. That's all, from the server you can manipulate the document in anyway you like. You need to have some structure on the server that keeps state and your set. Ajax makes webdevelopment an enormous amount easier for me, am i so smart or is everybody else so ....? (the old trainer of amsterdam's footbalclub ajax used to say this). If you do ajax the client way you'r in for big trouble, everybody should stay away from that approach. Javascript is not a bad language, javascript's just has no compiler as any dyn typed language. That is why we should stay on the server, we need compilers to build rock solid systems. Ajax is a blessing for everybody that gets it, if you dont get it (as in you'r a page thinker) your better of with web1.0
  160. hallelujah
  161. hallelujah

    LOOOOOOOOOOL ! Thank you Jakob for my loud laugh of the day, this one is excellent, worth a thousand words and more ! :o))))))))
  162. hmmm at first i did not interpreted jacobs reply as an insult now i suddenly do. thanks
  163. hmmm at first i did not interpreted jacobs reply as an insult now i suddenly do. thanks

    no, it's not an insult, it should be really simple. the problem is that we'll never get to the 'desktop' look and feel without monolithic lock-in, i agree the best approach is to break down the concept of a page into small pieces and use ajax to interact/refresh as needed.
  164. jakob i knew and know that you did not intented to insult me, it is the other guy that gave me that feeling. Thanks for clearing it though, i appreciate that. I am affraid that ajax will get a bad name because of dumb ass frameworks that will drag the thing to the client side. All that should happen in clientside code is change of colors, display none and more strictly view related logic. But still even that can be handled on the server. I have been building my own framework over the last couple of years and am still surprised about how easy things can be solved compared to what i was used to. Funny how the most complex task seems to be to keep things simple.
  165. Dennis,

    To really be clear, i am not saying Ajax in itself is bad, and if it sounded like what i meant than maybe it's a mistake that i made, English is not my mother tongue. Maybe this is why i thought Alleluhia was a joke :o)

    I was more talking about the fact that doing quite complicated things such as word processing software in javascript + dhtml is not the way i want to go. And additionally, i insist on the fact that design and ergonomy should be top priority when we are adressing mainstream needs. This as a sumup of my thoughts for this thread.

    Cheers, and have a nice day,

    Christian
  166. no, it's not an insult

    Sorry guys, i thought Jacob was joking, i misinterpreted, but i like to laugh, really ! And for me a joke is not an insult :o)

    Cheers,

    Christian
  167. Hi Dennis !

    I did not mean to be rude, and this was just a joke. You can joke on me for sure, i hope to have a pretty good sense of humour on myself :o)

    Back to our matter. I believe that you are right DOM HTML + javascript can not be such a problem, apart from browser incompatibilities, that are/will be handled by proper frameworks. Additionnaly, i can appreciate javascript + HTML for displaying stuff or managing forms. I developped a web based mainstream application for Compuserve back in... 1997, no typo, 1997. We directly generated the jabascript from the database metadata and data via C++ IIS C++ server extensions. We did that because at this time bandwith was expensive (56Kb modems were really the exception), and sending compacted javascript instead of verbose html was a time and money saver for the customers.

    But still, talking about Rich applications, how could javascript + html come close to plain java applet, or proper Flash application ? HTML has been designed to display, not to interact.

    Hence, what is the interest of developping pure javascript based word processors, while you could develop an applet to do it more seamlessly, offering much more possibilities to the end user ? These are the applications i am talking about. Portal type of website can be built with Ajax for sure.

    Cheers,

    Christian
  168. Hi Dennis !I did not mean to be rude, and this was just a joke. You can joke on me for sure, i hope to have a pretty good sense of humour on myself :o)
    Hi Christian, unfortunally i sometimes lose my sense of humour and think that everybody is against me, escpecially at the end of the week fighting with controller based frameworks. Sorry for my bad mood.
  169. Hi Dennis !I did not mean to be rude, and this was just a joke. You can joke on me for sure, i hope to have a pretty good sense of humour on myself :o)
    Hi Christian, unfortunally i sometimes lose my sense of humour and think that everybody is against me, escpecially at the end of the week fighting with controller based frameworks. Sorry for my bad mood.
    Hi Dennis,

    No worry, it also happends to me sometimes ! Today is monday, hope you had a good week-end and will have good working week :o)

    Cheers,

    Christian
  170. a-ja-xed[ Go to top ]

    huh.. will my desktop be replaced by ajax?
  171. a-ja-xed[ Go to top ]

    if you set it active it will ;-)
  172. Yep!. Adoption of AJAX is at a fast pace than expected and growing exponentially. With apps like Google Maps, Google Calendar, GMail, etc., it has almost taken out desktop to the internet.


    -Rafiq (Ajax Today)
    http://www.ajaxtoday.com