Re: Industry versus academia

[Sundar Narasimhan <address@hidden>]

Apologies if this is a resend. Mailer died as it was going out..

--
   Yes, I agree that it doesn't have to be this way.  One approach is to 
   provide tools
   that take care of a lot of "plumbing" and "boilerplate".  This (I hope 
   you won't think
   this is supposed to be a plug) is what the BEA Weblogic Workshop (WLW) 
   product is
   trying to do for Web Services in a J2EE environment.  It's also one of 
   the things
   Visual Basic is about. You could say that WLW is trying to make Java and 
   J2EE
   "lightweight", in some senses in which the word "lightweight" has been 
   used around
   here, by providing tools rather than by changing the langauge.

IMO, Weblogic and the current crop of web services tools 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 -- 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.

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. 

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

Put these together and I think you'll get a sense of the problems and
questions I find interesting.  They have less to do with technology
than with business, the current economic climate, oh.. those wizards
everyone keeps talking about, and what the next crop of innovative
value propositions (in languages/tools/frameworks/platforms) might
look like.

   I think a lot of discussion here has impinged on the point that just as 
   you miss a lot
   of you consider a language without considering its libraries, you also 
   can miss a lot
   when you consider a language without considering its tools.  The main 
   answer that
   real Lisp people will give to the "what about all those parentheses" 
   question usually
   includes some mention of text editing tools that help with the parens 
   and turn them
   to your advantage.  That's one example.

Hey, I completely understand the point behind tools. That's why we are
currently trying to evaluate Scott McKay's code and getting it run on
PC's on Franz because it will give us a way to hedge our current
dev. environment which is Symbolics boards running on Suns -- tools
that we still develop with :)

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.

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 led to them seeking to do it all
themselves (remember Statice?, or CLIM?, 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.

   Anyway, if you have other approaches to solving the below-mentioned 
   problem, you
   may have something that will interest big commercial consumers of 
   software such as
   financial and telecomm companies.

It's already happening in the insurance and financial industries to
some extent. Don't know much telecom, so I can't say.