:
:Yes, I had a look at it. You didn't use postix if at all, that I could see.
Um .... postix? Is that a typo, or have I just been programming in
shell too long? :-)
:> Do you want big languages and little programs or vice versa?
:
:I want little languages and little programs. I don't believe you can't
:get there (watch out, he's got something under his coat! Oh no! He's got
:a Forth interpreter! Run!) from here...
Peter, be aware that the common man has neither the time for nor any
appreciation of your spartan minimalism. In fact, he in general has no
time for programming languages at all. He's not looking for beauty in his
code -- I'm quite certain that he couldn't care less about its aesthetic
appeal. He's just trying to get stuff done. Why is it, do you suppose,
that languages like BASIC, sh, awk, perl, tcl, REXX, and Visual BASIC have
enjoyed the popularity they have? It's really very simple: they're easy
to use for someone who hasn't had the questionable good fortune of
having done graduate work in programming languages.
Period.
To a large extent, most people design computer languages the "wrong" way.
They make them beautiful gems, with subtle properties, like deep binding,
first classness of arbitrary objects, dynamic vs lexical variables,
multiple inheritance of potentially overloaded methods, etc. These tiny,
balanced, sparkling works are some computer scientists' pride and joy, but
their subtleties escape the junior high school graduate trying to put
together a quick application.
Truth and beauty may make you feel good, but realize that your truths,
your beauties, mean nothing to the vast majority of the computer *user*
out there. Sure, you can communicate in a spoken language with 300 words,
but you're reduced to cumbersome circumlocutions. Having 5000 words --
some of which mean nearly the same thing as each other -- yield
much greater freedom of expression.
You're suffering from delusions of clinically committable magnitude if you
begin to think for one moment that anything as counterintuitive to the kid
off the street as Forth -- or Lisp for that matter -- has a chance of
actually gaining sufficient acceptance and widespread use to become a the
cyber lingua franca you're looking for. Even RMS in his guise as the
Avatar of the Lisp God has realized the severe limits of raw Lisp's
accessibility to the masses; be not quick to discard Richard's notions in
that particular area.
The problem is, you see, is that quite simply, you're designing the wrong
languages for the wrong crowd. Ousterhout is more right about the Law
than most in their Ivory Towers here seem to care to admit: the people will use
gleefully only that which comes easy to them, and these languages will
drive out the others. If you force something strange down their throats,
they'll choke; witness how many high school students use Scheme instead of
BASIC. John's also right that while we would-be scholars casually sit
here debating the number of angels who might dance upon the head of a pin,
we're on the verge of being overrun by marauding Mongols whose monetary
and thus marketing might constitute a force with which we cannot begin to
reckon: that is, Microsoft -- and Visual BASIC -- are coming.
Before you start redesigning languages that many, many people find
perfectly acceptable and proven utility, you would do well to better
remember these uncounted multitudes out there who are already using to
their satisfaction those extension languages you are so quick to
discredit. These people are even less apt to grab up gnuscript than
someone with a dozen years of strictly BSD sysadmin experience has of
cheerfully downgrading from SunOs to Solaris. Whether it's good or bad
is immaterial; it's different, and all stable systems resist change.
Furthermore, you cannot in some miraculous wink of an eye catch up to the
hundreds of thousands of manhours of testing and refinement that those
languages which you (or more properly RMS, I should probably say) hope to
supplant have undergone. You must commit a commensurate investment of
time and trauma to reach a similar level of sophistication. And even
thought this should be done, nevertheless it will inevitably suffer from a
sinister onus of mistrust analogous to that suffered in the initial
releases of Solaris, one which to a not inconsiderable extent persists
still, irrespective of any measure of its technical merit.
I note that to this day, it's still faster to run s2p on a complex sed
script and send it through perl than it is to send it through GNU sed.
One cannot but wonder what ramifications that this small data
point might well portend for gnuscript.
Mind you, it is not my intent to suggest that one blithely foist off some
shoddy language on the world just so that the whole world might find
itself sufficiently technically astute (that is, barely at all) to make
use it. I don't believe that having a language sufficiently
straightforward that anyone can program in it after nothing but a few
simple hours of intruction necessarily precludes its potential as a
fundamentally solid work lending itself to the necessary goals of
reliability, extensibility, and eventual optimization. You can permit a
longer learning curve if you want to attain those lofty goals so cherished
by computer language theorists, but you MUST make it perfectly usable for
those willing to travel never more a short way along that path .
:> I guess all we need is a elisp-to-perl (or is that scheme-to-perl)
:> translator now and even rms will be happy. :-) (Someone else reports
:> working on a tcl-to-perl translator already, but progress is slow.)
:I don't think that you're going to get a good translator from any of these
:data-driven languages to a procedural language any time soon. Run-time
:manipulation of code is too much a part of what makes them interesting.
:And it's also too much a part of what makes them useful extension
:languages.
I disbelieve. While it's true that the intensely lexical nature of tcl
present interesting challenges for the person trying to generate cold,
frozen machine code, that doesn't stop them from working on it. But I was
never talking about such a thing. I'm perfectly content to interpret data
as code from perl. In fact, I've had highly successful experiences
writing and using programs whose extension and configuration language was
in fact perl (albeit with certain per-program conventions, of course).
[See the "clip" program, just to name one.]
But perhaps you can I have a different idea of just what precisely
constitutes a data-driven language or program.
When it comes to lisp or tcl, while the extensive run-time nature of
those languages make machine language generation (at least of certain
constructs) difficult, compiling them into native perl (probably
with a run-time emulator library) should in theory present no insurmountable
hurdles. I'm not necessarily saying it's worth doing: just that I fail to
understand your reasoning for discounting its likelihood and technical
feasibility in what would otherwise appear to be an out-of-hand and
little considered fashion.
--tom
-- Tom Christiansen Perl Consultant, Gamer, Hiker tchrist@mox.perl.com "Umm, square root of two? Ouch!" --The guy who blew a hole in the Pythagoreans' assertion that all numbers can be represented as a ratio of two integers, so they killed him