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

Re: LFM + LFSP = LFE?



On Fri, Jun 13, 2003 at 06:20:10PM -0700, Avi Bryant wrote:
> It's a bit like asking why someone hasn't come
> up with a punch card syntax for Python - it's possible that you could ease
> adoption for people that were used to programming that way, but would it
> really not be easier just to teach them to use an interactive text editor?

That analogy doesn't fit.

Smalltalk's immersive code browser may be the best invention since fire,
but in ~30 years, the only environments to use it are Smalltalk and its
descendants.  The vast majority of the industry is quite happy to use
1960's era technology to develop software: Lisp's REPL, or files of
source code with text editors, compilers and interpreters.

Although file-oriented software development is "inferior" to interactive
code browser, it's the dominant paradigm for software development -- as
measured by the number of langauges that support it or the number of
developers who use it.  The real issue isn't that the Smalltalk paradigm
is superior and more productive, but that writing source code in text
files isn't fundementally broken as a development model.

Creating a text-based syntax for Smalltalk isn't *anything* like creating
a punch card syntax for Python.  In fact, I could argue that Ruby is a
text-based syntax for Smalltalk programs, and it is in fact becoming quite
popular.

> If such a system existed (either punch card input for Python, or text file
> input for Smalltalk), would anyone actually use it for more than a day
> or two before figuring out that there was a better way of doing things?

If the Ruby analogy is valid, the answer is most certainly yes.

While file-based language environments may be inferior to the code browser,
they have certain beneficial side effects.  Batch-oriented software is
both well studied and easy to write -- in terms of compilers,
pre-processors, reusable search utilities, software configuration
management, archiving, aggregation, and so on.

Smalltalk environments may supply all of these features, but they also
bring along extra baggage in the form of system images.  Perhaps most
people avoid Smalltalk and its code browser because it's too foreign and
requires learning how to use the tool (i.e. They are Dumb).  Perhaps they
are avoiding Smalltalk because (1) they're already quite productive with
emacs and batch oriented development, and/or (2) the productivity
differential isn't great enough to justify the time to switch environments
(especially when you can just write a code browser and increase
productivity).

Z.