[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Industry versus academia

Sundar Narasimhan wrote:

>Apologies if this is a resend. Mailer died as it was going out..
>IMO, Weblogic and the current crop of web services tools
Um, here I have to apologize for BEA's product naming, in which the name 
is slapped on everything.  I was specifically talking about "Weblogic 
Workshop", also
known (at least internally) as WLW, which is the product that came in 
from Adam Bosworth's
Crossgain startup when it was acquired by BEA.  Adam Bosworth is the 
person I have
been referring to as "my boss" in previous email; his title (get this) 
is now "Chief Architect
and Senior Vice President for Advanced Development".  I'm in the little 
"advanced development"

> don't come
>close to solving the problems you are talking about. The problems I
>thought you mentioned were that applications are hard to build,
>maintain, extend, required the services of wizards etc. I just don't
>see how taking care of the plumbing (which btw, is not really true
>either because you still need wizards who understand how say EJB, JCA,
>JMS, JTA, JXB etc. etc. work
But with WLW you can do quite a lot without having to understand much 
about these things.
You don't need to know anything about EJB to speak of.  You have to know 
some things
about configuring JMS, but you never use the JMS API directly because 
it's all hidden inside
a "control".  The JTA stuff is entirely hidden from you.

> -- esp. when things fail -- as the
>Daimler-Chrysler case-study illustrates :). I hope you get the
>point. This is NOT what I'm talking about. (I respect Bosworth & Co
>very much, so undoubtedly WLW is cool stuff.. so don't take what I say
>as a knock on your products).

>The approach I was trying to point out is that application
>construction and managing change can be drastically changed if users
>are given tools with which to do it *themselves* with NO programmer
>intervention required. That's the promise of declarative programming
>and JRules like products. Sure this approach still requires wizards to
>set up, define domain vocabularies etc. but once implemented and
>running .. corporate IT, or "business users" can use the rule builders
>to build the rules (in near English), and deploy changed applications.
>No intervention from integration houses, no customization projects
>etc. needed. Agility for some upfront investment.
Yes, that would all be great, and people have been talking about it as 
long as I've been
around.  There was a group at MIT called the "Automatic Programming" 
group that
was well-established when I showed up in 1976 or so.  It appears to be 
turning out to
be an extremely hard problem to make such a system that is ready for 
prime time.

>You are talking about incrementally reducing (perhaps) the costs
>associated with writing integration code. I'm talking about a
>fundamentally different approach to constructing business applications
>-- if SAP were built that way, you wouldn't need tens of millions
>dollars worth of "customization" efforts at each deployment. 
That sure would be great.  If you had it you could probably make real 
money selling it.
Well, if you wanted to make your own thing that does what SAP does, 
which might
be a fairly large undertaking.

>The other trends I'm trying to point out are that you couple such
>technologies with open source tools and outsourced engineers who cost
>one fifth or one tenth of what engineers cost here in the US -- and
>I'd say the argument becomes even harder for your customer's CFO to
What, the argument that the principles you are talking about might, 
someday, lead to such
a wonderful product?  Or the argument that you actually have such a 
product that Merrill
Lynch can buy tomorrow?  The stuff you're talking about sounds like an 
exciting research
direction, for sure.  But I'm just pointing out that (a) it has been an 
exciting research direction
for around thirty years already, and (b) it is still  not something that 
one can go out and buy.
That said, sure, it sounds great.

>Personally speaking, I'd like to see Lisp, Python and other languages
>embrace or build upon something like the Eclipse framework (mainly
>because -- I know I'm probably going to get flamed for this :) -- it's
>clear to me that language people can't hack good GUI's and good
>GUI/IDE people can't hack languages -- the same can be said of
>databases/network code etc. -- not because of lack of capability mind
>you -- it's just that each of these fields moves sufficiently rapidly
>these days that that staying on top of the state of the art is hard
>and requires a full-time commitment).  I also would like to see
>Eclipse embrace emacs as a true plugin.
Absolutely.  When I first looked at Eclipse last summer I was susprised 
that there was no
Gnu Emacs plugin.  Is there STILL no Gnu Emacs plugin?  That's so weird 
that it makes
me wonder whether there isn't some deeper reason, e.g. maybe the Eclipse 
plug-in story
isn't quite as rosy as they'd have you believe?  But I don't really know 
anything much about it...

>We don't need ten different IDE's for ten different languages.. and I
>also don't buy the "emacs is good enough" argument, even though I use
>it every day. My old complaint about Lisp has been that the NIH
>attitude that the vendors displayed 
Of course you have to remember that back when Symbolics was started, 
there was really
no such thing as cross-vendor code.  No code that ran on a Data General 
machine also ran
on a Digital machine, and the same for Interdata and Wang and Prime. 
 Nothing.  I know that's
hard to believe these days, but that's how it was.  The whole concept of 
"the Unix code base,
which runs on all the Unix machines from many different vendors" didn't 
really start happening
for real until about 1985, at which time Symbolics, as a corporate 
entity, failed to grasp its significance

>led to them seeking to do it all
>themselves (remember Statice?, 
Hey, as soon as my team completed Statice, I told Symbolics management 
in no uncertain
terms that what had to be done was to make it portable.  They were not 
and I quit to co-found Object Design.

>or CLIM?,
CLIM really did run on Common Lisp, hence the name, no?

> and now after all these
>years, a major Lisp vendor is writing a stepper! :) -- which could
>potentially have caused them to divert resources from strategic
>problems that desparately needed addressing either through creative
>partnerships or other leveraging strategies (like distributed
>programming, robust db access layers, a web application framework,
>performance/performance/performance, threading and SMP support
>etc. etc). What's a wizard if he/she doesn't choose wisely as to where
>to perform his/her magic :) I could be wrong about the theory.
In retrospect, of course, yes, that's how it should have been done. 
 Symbolics and Lucid,
for example, really should have merged. But it all looked so different 
back then, inside
our little reality-distortion-field.