On Mar 13, 12:18 am, Jonah Thomas <jethom...@[EMAIL PROTECTED]
> wrote:
> Forth would need a chance. A cir***stance where a lot of people would
> try it out. Right now we don't have that, hardly anybody new is giving
> it much thought. I have the idea that of the people who do give it a
> quick look -- which includes a significant number of CS guys -- most of
> them don't give it enough of a look to figure out how to actually do
> stuff with it. Like the discipline to write one- and two-line routines.
> XP guys do that but they don't do it in Forth, and would somebody who
> happened to know about XP carry over his skills to Forth? Or would he
> have to learn all over again what works? The more usual approach might
> be to look it over, see some of the cute tricks, and think that it's
> hard to program in it.
A lot of people are trying to work out where the openings are, and
trying to tailor answers to what they think are the openings. However,
an opening for innovation normally takes most people by surprise.
One response is dogged devotion to a particular answer ... which is
hard on the face of it to contradict, since we know that we don't know
what the answer will be, so filtering out answers that are the wrong
answers is hard. And, indeed, the biggest innovations will often have
been the wrong answers to the question that was being posed twenty or
ten years back, but happen to be good enough and in the right place at
the right time for the question that cir***stances are posing now.
The other response is to spread seeds as widely as possible, and not
worry about the fact that 99% won't take root, but rather focus on
trying to make sure that if any of them do find fertile soil, they
will be able to grow there, and once there to reproduce in turn.
For the second response, instead of looking at the strategies of the
most successful languages and asking how Forth can be just like them,
the task is to look at the strategies of the most successful languages
and ask where they fall down. Not in a sophomoric "how come they are
dominant when they are far from perfect for doing this" ... since we
understand perfectly well that being dominant in one problem area
gives a programming language an added advantage when fighting
for dominance in another, until the biggest programming languages are
seen as useful in some fields primarily because they are the
mainstream. But with awareness that none of us know *which* of those
shortcomings are the bases for a useful opening, but that some of them
certainly will be.
And instead of looking back in history and writing alternate
histories, we have to be scanning across the present and writing
alternate futures. So, when we see that Forth has been adopted
somewhere and it went nowhere ... why not? The example of the MUD is
easy ... while Forth *is* a scripting language, and an excellent
general purpose toolkit for building a problem specific scripting
language, they needed to be able to pick up a problem specific
scripting language that was already close to good enough for their
problem and refine it ... having Forth available to people who have
never designed an effective scripting language and expecting it to
somehow magnetically attract them to setting to work and then
successfully solving all the problems is like handing someone a
canvass, set of brushes, and tubes of oil paint and telling them to
paint a landscape.
Or take the example that came to my mind when discussion turned back
to ForthOSes recently. I was looking at Yet Another Experimental
Operating System, which had some wonderful features promised and
virtually no applications, and it had an implementation of one of the
more minimalist Forth-94 models. The main project author seemed happy
to have it, because when you are writing a new operating system, any
running code contributed to the project is a good thing ... but no
applications written in Forth, just the fact that you could run Forth
and get an "ok".
There was a space were any small suite of ordinary utilitarian
applications that could have been fitted into the experimental
operating system framework would have been happily presented as things
the OS could do. If the experimental operating system had had netcat
and awk and M4 and make and a bash-compatible shell and ... well, a
couple of other *nix tools, the funky little script based browser, and
file manager, and full screen text file viewer from the experimental
muLinux floppy disk Linux distribution would have been welcome.
Now, the basis for the full-screen interactive programs programmed in
*nix shell scripts is a full-screen interactive pager type program
that the author of the muLinux distribution wrote.
And a similar scriptable full screen interactive display in Forth and
for Forth would give substantially more leverage, because it could be
brought up to ex****t usable versions of small applications into a much
wider range of settings on a much shorter toolchain.
That was my idea for ThePanel, and I'll turn to it after the first
version of Niclos is able to stand on its own feet. The last time I
had the time to work on that factoring of the problem, which was kind
of automatic given playing around with muLinux at the same time as
playing around with BMW, I went off on a completely wrong track,
trying to hammer out an objects/methods based API for a virtual
electronic scroll.
But recently, based on some clues dropped by some people here on the
way to saying other things, a much better understanding about how the
WWW works on a low level than I did in the late 90's, and the benefit
of sitting down and working through how Jenny Brien's JenX works, I
got what I think is the simplest possible server client architecture
that fits the problem (as I previously mentioned), and am going to
have a try at it from there. It might be another false start, it might
have legs ... the way to find out is to implement it and see. The
backend code for MF.F and LF.F and the mini-spreadsheet gives plenty
of application client raw material to see how simple the protocol
between client and server can be made before working with it becomes
too ***bersome.
|
