Is development of new software tools "moribund"?
I've always enjoyed Philip
Greenspun's take on things; about 50% of what he says goes
straight to the point. Unfortunately the other 50% seems to be
complete crud. (I'm never sure how seriously he's taking himself,
so it's hard to know if he's just trying to be thought-provoking.
Even if not, separating out the gems from the crap is enjoyably
difficult and hence worthwhile.)
His most recent weird post talked
about a fairly simple Perl script to spam friends with
invitations. In the comments, someone tweaked Philip about being
a "Perl whore" despite his lauding of AOLserver, a Tcl-only (well, mostly) Web server. Philip
responded that he had good reasons for liking AOLserver (connection
pooling &c.), and since it happened to use Tcl, he used Tcl himself.
Philip then felt compelled to say that he thought software tools were
moribund, because his friends coding in .NET, his students working
with Java, and people working with PHP weren't as productive as people
who used AOLserver -- a technology designed over 10 years ago.
In the comments, I remarked that whinging about how Web software
development tools haven't moved on since 1992 by citing Tcl, .NET,
Java, and PHP was silly. Why not look at languages that support (and
support well) a variety of techniques? Python (and by
reputation Perl and Ruby) tools have come a loooong way in the last
few years. In Python you can now choose between at
least 5 different frameworks, all of them at least moderately
mature. All of the popular Web programming techniques are represented
between the various frameworks: the object publishing paradigm
(Zope/Quixote), the object-kit templating paradigm (WebWare/CherryPy),
and of course the utility belt that is Twisted.
The real question is, why not use Tcl, PHP, .NET, and Java for Web
programming? It comes down to two conflicting considerations:
- the "each page is a class method" model encouraged by Java is
overwrought for the simple pages that make up 20%-80% of any
Web site (depending on the site, of course); it seems to be great
for more complicated sites, though.
- the "each page is a string of spaghetti code" model encouraged by
Tcl and PHP is great for the simple
pages (20%-80% of any site) but disastrous for more complicated sites.
Or, to put it another way, straight scripting languages are great for
constructing simple pages, while higher-level abstractions are needed
for more complex pages. Most Web sites require both kinds of
pages, but many languages do not support both kinds of programming well.
Python offers a great intermediate: it is a scripting language that
deals well with outputting strings, but which offers nice higher-level
ways of building out a framework. (This is likely true of other
scripting languages that support object-oriented programming, such as
Perl, [incr Tcl], Ruby, OCaml, ... what am I missing? VBA?)
Bas Scheffers pointed out (in the comments, again) that "it's not the
tool, it's the programmer". Well, yes, this is the usual last resort
of any language anti-advocate: heck, they're all identical at
some level of abstraction, right? And you can write spaghetti
code in any language, right? So how dare you say that language A is
better than language B?
Well, my experience tells me (and other people that you
should trust more) that Python is better than both Tcl and
Java for many things. And so the question is, why? I'm sure there
considerations that make sense to people, but one that I haven't
seen mentioned before is that of how examples are coded.
Since most programmers liberally "appropriate" code -- from books,
from open-source programs, and especially from cookbooks and examples
-- the quality of that code has a lot to do with the way they write
programs. It also has a huge effect on the way they learn to
code in the language. And I think this effect is grossly underestimated.
For Python, there's a nice
tutorial, a variety
of books (caveat: most of which I haven't read), and many, many
examples from both the comp.lang.python newsgroup and the Python
cookbook. By and large, the code contained in examples
is clean, simple, short, and documented. It also lives at a
level of abstraction that fits: classes/objects used when appropriate,
and not used when not appropriate. Yes, there's plenty of gunk
in Python, but it's not what you first encounter & it's easy to
find pretty examples.
For other languages, example code is often much
nastier. Spaghetti-code style may not be required by Tcl and PHP, but
most of the example code I've seen can't be classed any other way.
Overwrought object-oriented gunk may not be required by Java, but most
of the example code I've seen certainly fits the description.
It could be that simple: if you write uncomplicated yet useful code
examples, and people learn your language from them, then in the end
your language will be used to write prettier code. And there will be
less unmaintainable spaghetti code, or ugly overcomplex OOgunk,
written in that language. And, if you're lucky & you've figured out
how to grow your language
over time with the help of the community, your language will
continually move towards supporting that kind of coding.
Why Python examples are pretty is a different question, and the
answer may be more sociological than technical. Perhaps it's as
simple as Python fitting
my brain better than other languages do, and it's not true
for everyone else. Or, perhaps it's more than that -- for example,
our beloved BDFL may be
particularly good at designing a certain type of language.
In the end, supporting good mechanisms of abstraction may be necessary
for good programming, but it is obviously not sufficient. It doesn't
do much good to have a language that supports a bunch of mechanisms
that don't cleanly fit into example code. Nor will it do the language
any good in the long run if the example code is poorly constructed.
So, I don't think that the development of software tools is moribund --
but it may be time to move on from Tcl for doing Web programming.
Philip Greenspun's company died a
horrible death several years ago partly because they were trying to
transition a hideously complex mess o' Tcl into Java. I wonder what
would have happened if they'd chosen to use something more scriptable
than Java but a little more supportive of abstraction than Tcl?
p.s. I'm pretty supportive of using Java for other things, such as
GUIs. I'm just not smart enough to make it do data reduction
fast... so I switched to
C++ / FLTK.