Re: What is a lightweight language

[Dan Weinreb <address@hidden>]

   Date: Tue, 11 Dec 2001 17:27:10 -0500 (EST)
   From: Shriram Krishnamurthi <sk@cs.brown.edu>

   You're saying that working stiffs will (a) rarely learn new languages,
   or (b) learn one if it solves their job.  They encounter a problem,
   which "in all known languages can only be expressed poorly", so they
   search the Web or browse their bookstore for a cookbook.  

Well, if I went to my boss and said that the problem I was working on
could "only be expressed poorly" in Java, and suggested that we
consider rewriting the whole product in a different language, I think
he might rightly respond that the benefit of "clearer expression"
might not be worth the costs of the rewrite.

I think our main practical reasons for sticking with Java have to do
with network effects much more than anything else.  "Running with the
herd" has a lot of practical benefits.

I play the other side of this same game in my (here I am really
speaking for my co-workers) capacity as a vendor of object-oriented
database systems.  For a potential customer who wants to store data
and cares about things like transactional consistency, incremental
updates, indexes searches, and so on, there are very strong
network-effect reasons to go with relational database technology.  We
have to adopt the motto: "If you can solve your problem with a
relational database, then we aren't even going to try to sell to you."
To overcome the network effect, we have to demonstrate some kind of
very strong proposition, e.g. there just isn't any way you can meet
your engineering goals with an RDBMS, but you can with our ODBMS.

So justification of a language with less of the network-effect benefit
needs to be justified with something stronger than "it can express
what I want to do more clearly".  For example, sometimes in Java we
have to define a method to return a little "struct" with a few values,
because there's no way to do multiple-value return.  It's sort of
inconvenient and awkward and it causes some extra consing.  But it's
just not going to justify switching to another language.

I would need a much stronger case, where I can show that there just
isn't any acceptable way of achiveing engineering goals using Java,
but there is using, say, Scheme.  

		  they put them down because the documents don't say
   anything about *how to use Scheme to solve problems*.

Unfortunately, what you really need is "how to use Scheme to solve
problems that cannot acceptably be solved in more-popular langauges"
and realize that people in industry might be willing to "accept" a lot
in order to get the benefits of the network effect.

As you and I discussed at the workshop, though, the important thing
may not be trying to convert industry to use Scheme.  Rather, the
important thing is to educate so many people about Scheme that when
the next to-become-big langauge is being created, the team will
include enough people who appreciate the ideas of Scheme that they'll
naturally design the new language to incorporate those ideas.  I think
this kind of thing clearly happened with Java to some substantial extent.