Newsgroups: rec.arts.int-fiction
Path: nntp.gmd.de!newsserver.jvnc.net!raffles.technet.sg!pith.uoregon.edu!cliffs.rs.itd.umich.edu!howland.erols.net!worldnet.att.net!ix.netcom.com!netcom.com!erkyrath
From: erkyrath@netcom.com (Andrew Plotkin)
Subject: Re: Questionable Languages & Compilers
Message-ID: <erkyrathE2sy7z.KuH@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
X-Newsreader: TIN [version 1.2 PL1]
References: <32b72f97@beachyhd.demon.co.uk> <1996Dec19.165314.307@wcc.govt.nz> <59cimp$2hf@life.ai.mit.edu> <32ba50f5.4005680@news.worldonline.nl> <59fnpk$l9c@life.ai.mit.edu>
Date: Sun, 22 Dec 1996 06:33:35 GMT
Lines: 145
Sender: erkyrath@netcom3.netcom.com

David Baggett (dmb@lf.ai.mit.edu) wrote:
> In article <32ba50f5.4005680@news.worldonline.nl>,
> Marnix Klooster <marnix@worldonline.nl> wrote:

> >What features should an IF implementation language have, in your
> >opinion?

> [I sent this note to Marnix, but decided to post it as well, in slightly
> edited form.]

> It's not so much features; if anything, it's that these languages have too
> many features that ought to be in libraries, not hard-wired into the
> language.  As a consequence, the features are not very extensible, and you
> have to spend lots of time learning special, bizarre syntax to be able to
> use them or read other people's code.

I dance around, sprinkling saffron and holy oil upon your brow, as you 
utter these holy words.

> My feeling is that a language should provide only the primitives you need,
> and that everything else should be defined in terms of those primitives.
> The designer should ensure that these primitves can be combined in such a
> way that a compiler can perform useful optimizations, and the compiler
> writer should ensure that the compiler takes advantage of the good design.
> Neither of these things is by any means easy, which is why so many people
> who "roll their own" languages screw them up.

> As I've said before, 

...around the time I was trying to decide to do for the competition, for 
example...

> I think Scheme is a really good base language to build
> an IF system around.  It has very few primitives, but the primitives are
> extremely powerful in combination.  There are well-known optimizations that
> work well on Scheme code.  And you can do things in Scheme that you can't
> do easily in most other languages.  Here are two examples:

> 1) 1st class functions.

> 2) Continuations.

[explanations snipped]

I certainly like features like these in languages. (SML, which I whine 
for occasionally without doing anything about it, is pretty much made of 
the idea of first-class functions, together with the Sexiest Type System 
in the Universe. On the other hand, I still can't think in continuations. 
Maybe someday I'll figure them out.) 

However, on the *third* hand, Inform (being C-like) supports function 
pointers (in its own icky typeless way), so you can do many of the tricks 
you want to use first-class functions for. You could easily write an 
iterator function like you describe, which takes (among other arguments) 
a function pointer. The compiler doesn't keep you type-safe, but we C 
recidivists know how to be careful, so we *do* get features like this 
when we want them.

And the Z-machine has an exception mechanism which, unless I'm very much 
mistaken, is essentially limited (one-use) continuations. (I've seen 
sketchy Scheme implementations which had limited continuations like 
this. They suffice for the loop-bailing example you gave.) 

(None of this helps programming newbies, however.)

> These are the kinds of features that are *good* to put in a language.
> They're powerful, very general-purpose, and (though it's not obvious at
> first) combine very efficiently, and without obscuring optimzation
> opportunities.

> If these examples seem esoteric, well, remember this: programming languages
> train you not to want power they don't provide.  Once you're used to
> working with things like 1st class functions and continuations, you can't
> stand writing code without them.

Now I will give the argument for the defense: C is, uh, not that bad. 
I've used a bunch of languages, including Scheme, SML, C, C++, and Java. 
(Java is an awful compromise of a language, BTW. I *really* miss 
first-class functions when I use it. I understand they're being hacked 
into the next version, which is good, I guess, except that it means that 
Java is firmly on the path to becoming an awful bloated monstrosity of a 
language -- like C++ is.)

Sorry -- tangent. The point is, I always wind up back at C. It's dumb
enough that I can get it to do what I want. If I need it to iterate on an
arbitrary function, I hack that together -- it's neither the hard part of
my programming day nor a major source of bugs. If I need a small amount 
of OO behavior, I hack *that* together. If I need a large amount of OO 
behavior, I switch to C++ and keep very tight limits on what C++ features 
I use, and where, so that the program is essentially C in the easy 
sections. 

So C is great for hotshot geeks like me. Contrariwise, however, C isn't so
bad for beginners either. (I hear you sharpening your machetes out there
-- hold on -- I'm going to qualify that.) The original "language for 
beginners" was BASIC. Idiots can demonstratably learn BASIC. Imperative 
programming where numbers are the only first-class objects is really easy 
for people. The problem is, BASIC causes inoperable brain tumors, because 
it doesn't give you the tools to figure out recursion and modular design. 

C is BASIC plus recursion and a certain amount of modularity. And the 
roof is lopped off, so that you can write anything and everything in it, 
if you're willing to become a hotshot geek about halfway through. This is 
why it's so popular. Idiots can get started in it, and once they develop 
a clue (which I have, I hope you don't mind me claiming) they (we) don't 
have to leave.

(You may just say that I've developed a more advanced form of inoperable 
brain cancer. This may be.)

(The hard part about getting started in C is traditionally strings, and 
pointers, and other aspects of dynamic memory management. Note that these 
are exactly the bits that were left out of TADS and Inform (except as 
very advanced features, and then they're provided in a fairly idiot-proof 
way, not like C at all.) So this is not an argument about C-like IF 
languages.)

People *can* get started in TADS and Inform. I really believe that Scheme 
(and SML) would be much harder for beginners, because of their purely 
functional style. People had *trouble* with "Lists and Lists".

After typing all this, my feeling is that the real solution is an
imperative-looking language which contains Scheme-like features. So that
people can jump to it from BASIC, but not get stuck inventing their own
high-level features like I do. You say Dylan is this, and I've heard
something about a language called Haskell, too; I've never looked at
either of them. 

If Inform 7 went this way, I wouldn't mind a bit. It might, however, be 
too much for one person. (Kernighan and Ritchie didn't write Dylan. I 
don't know how many people that took.) (On the other hand, I've heard 
Scheme is pretty damn easy to implement. :-) Which makes a certain amount 
of hash out of my point.)

It's late. I was going to talk about Phil Goetz's Prolog work, but I have 
to go. (The summary is "Don't talk to be about Phil, man. I think he's in 
the process of inventing a genre as different from Infocom-style IF as IF 
was from Space Invaders.")

--Z

-- 

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
