Re: A language idea: Elle

[Sundar Narasimhan <address@hidden>]

   > Building on Java and J2EE maybe good, going from weak to
   > strong typing through type inferensing, sounds interesting.
   > (I prefer "dynamic vs static" to "weak vs strong", each is
   > strong or weak in its own way.)  Automatic XML processing
   > seems interesting, are you heading toward web services?

   Not towards Web Services... I'm not trying to take something people are
   already doing, namely writing web applications with Java, and feeling
   around for a part of the "market" that is underserviced.

Your choice of market and problem statement are great. This is a
market that is IMO still exploring several alternatives, and has not
settled on any one. (i.e. consider Asp.net, Zope, JSP +
Struts/Maverick etc. and countless others such as Curl,
Javascript+Java applets, Flash etc. etc.)

Note I'm not talking pure HTML web-apps here. I'm sure any one of a
hundred frameworks will work there. I'm talking about web-apps that
provide-for semantically rich, high-bandwidth client interaction.

   IMO, the current state of the Java art is just like the "market"
   serviced by cable excavators: big, huge, bureaucratic. Companies that
   want every buzzword. In fact, I am using a certain well-known J2EE tool
   on a project right now, and it is obvious to me that the people who buy
   this tool don't actually use it.

   But here's this "edge case": smaller projects, smaller teams. For
   whatever reason, they want to stay in touch with the J2EE world, but
   they're the kind of people that consider Google their tech support
   resource. So they're using Tomcat, Struts, and maybe even MySQL for
   really small deployments.

This is why I think that Christiansen's analogy doesn't really apply
here. If you yourself state that the big J2EE tools are not being
used, then they hardly resemble cable excavators -- which were after
all solving their problem incredibly well (i.e. people were actually
using them), until hydraulics came along. Christiansen has another
important arc wrt. product evolution that I think is more important
wrt. web applications than his ideas wrt. innovation. He states that
products often migrate from "functionality" _ "convenience" _ "price"
etc.

If you look at that argument of his (which is very debatable btw), and
look at the state of web applications, one has to really be impressed
by the fact that none of the existing solutions really do the job
well, which is why people are still trying and retrying all of them
(and jumping to the next proposal when one comes along -- remember the
XML hype?). This is perhaps why J2EE marketing succeeded against
ColdFusion (remember them?) or why .Net is making a run at J2EE.
 
   A lot of those folks are sighing at how useful the LAMP ("Linux, Apache,
   MySQL, Perl") architecture is. So how do you make something that easy,
   but still keep it buzzword-compatible?

It does not need to be buzzword compatible. It just has to solve the
problems that real web application developers face. 

Today .. providing a sophisticated client gui (i.e. one that exploits
the desktop in a way that users have come to expect) coupled w/ HTML
and a robust server architecture on the back-end (i.e. even if you
assume you are write a single two-tiered system as opposed to an
n-tiered one) is *still* a challenge.

- lightweight languages seem to be great for scripting "other"
  systems, so perhaps there is a way of innovatively combining client
  interfaces and back-end server processes?

(ps. you can perhaps sense where I'm going -- drop the buzzwords,
Java/XML etc. concentrate on the problem.. solve that, and the rest
will follow :)

   Warm regards...

   --
   Reginald Braithwaite-Lee <http://www.braithwaite-lee.com/>
   (416) 82-REG-88

   "Unzip (to) /v./ simple yet spectacular way to remove protection."