Re: Forth and Unix -- history



John Doty <jpd@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Andrew Haley wrote:

It's not a popularity contest between Standard Forth and LSE64: I
have no delusions that either will ever be popular in its present
form. But the popularity of the Forth *approach* does matter, in the
sense that its 21st century unfamiliarity makes it difficult to
introduce into new projects. I wish that *some* Forth dialect would
become popular, but I see none that has much of a prospect right
now.

You don't get to have it both ways: either it's a popularity contest
or it isn't.

Oh, quit your sophistry. I said popularity matters, I never said it
was a contest.

You denied my comparison of the popularity of LSE64 and Forth because
"it's not a popularity contest." If popularity comparisons between
Forth and LSE64 are irrelevant, so are such comparisons between Forth
and anything else.

Is there a popularity contest between C and Python? Not as far as
I'm concerned: both are familiar enough in the wide technical world
to be usable in projects on their merits. They're both in the
toolkit. But Forth isn't in most toolkits any more.

Forth needs to handle these different data types to be a reasonably
complete language for programming a machine. However, you
apparently insist that Forth is to handle these types we must add a
type system and all that involves; yet, at the same time, you
complain about Standard Forth being bloated. I guess this is good
bloat not bad bloat ...

It seems to me that a type system would be less bloat that a
confusing matrix of typed cells and operators. Certainly less
perceptual load. Think of it as factoring, although of a kind alien
to Forth's traditional relentless proceduralism. It allows you to
separate data representation from algorithm (or not, as needed).

I don't think it would be less bloated. Handling a type system in a
language like Forth would be really complicated.

Not to the user. Think application, not implementation.

No. Both are important. The fact that the implementation is easily
understood, and simple, is of substantial value and indeed is one of
Forth's special features. The fact that every user can understand how
the whole system works gives tremendous power to the user. Besides, I
don't think that strongly typed Forth really would necessarily be
easier for the user. Some things would be easier, but some things
wouldn't.

The days when the compiler had to sit on a 4k target are over. Self
hosting is rarely an advantage anymore. And for the few cases where
it is, a nice stripped-down Forth is fine. One size does not fit
all.

It's about the space in people's heads, not the space in the computer.
Simple systems are better because they're easier to understand and
more reliable. Forth has never been about black boxes. If you're
looking for a black box language, it might be a good idea to look
somewhere else.

It's possible to generate an arbitrary number of words of different
types on the stack at runtime, so it would be very hard
(impossible?) to do type inference statically without greatly
restricting the language.

Apparently not: StrongForth is proof of principle here.

I don't think so. I doubt very much that StrongForth can do it
either, because I don't think it's possible. As a rather contrived
example, what is the type of

random 1 and if 2 else 2.0e0 then

?

You'd have to massively restrict the subset of allowable Forth
programs to make static typing work. You'd have to disallow many
perfectly reasonable Forth programs if the type inference engine
couldn't figure out the types.

Also, it would be very un-Forth in that it would be doing a lot
"under the table": operators like + would do different things
depending on context. This is a big conceptual shift for Forth,
and (IMO) it loses one of Forth's great advantages.

While I am not a fan of operator overloading willy-nilly (as in bad
C++ code), it seems unreasonable to have to keep track of data
encoding details in an algorithm, especially if the code is intended
to be portable/reusable. In any case, the world has gone to types
and overloading: anything else is user-hostile these days.

It also depends on what you mean by "different".

Different depending on type.

What "+" does in any computer language is different from what it
does in the real number system. In most Forth dialects, the details
of what "+" does depends on the hardware, so it already does
"different things depending on context". On the other hand, 1 1 + 2
= is generally true regardless of data encoding.

If you were really concerned about the language doing "different
things depending on context", you'd be as adamantly opposed to the
text interpreter as I am.

No, I wouldn't be. The text interpreter is a program, as is the
compiler. Each program processes a text and does something as a
result. These results are different because the programs do different
things. I don't see what's wrong with that, as I've said before.

However, I am opposed to the interpreter doing different things
depending on STATE. This is a hangover from early Forths which the
standard didn't obsolete.

The text interpreter creates a very user-unfriendly set of
differences depending on context. Overloading isn't nearly as bad:
decades of experience with other languages show that ordinary
overloading of arithmetic operators is well understood by users as
long as it's done fairly conservatively.

Sure, but it's a very different approach to that of Forth, where the
type is attached to the operation, not the data. You are describing
something like a reverse polish ALGOL, which might have its merits,
but it's a very different kind of animal.

I suspect that such a language wouldn't satisfy anyone. Those who
like strongly typed ALGOLs wouldn't use it because it's reverse
polish, and those who like Forth wouldn't like it because it's strongly
typed. I suspect the overlap, people who did like it, would be very
small.

The last I looked, gforth's documented vocabulary exceeded 1000 words.
That's just plain too much for most people who have problems to focus on.

No argument there either; gforth is an example of a "maxi" Forth
system. There have always been small and large Forths. Extremely
small Forths can't be standard, because even just the core has too
many words for them. There's nothing wrong with them because of that.

The trouble is, the standard encourages this bloat by having the
vocabulary. Other languages get their power from libraries, which
reduces the perceptual overload on the user and encourages library
development.

What's the perceptual difference between a vocabulary (a set of words)
and a library? I don't get it.

People don't discuss the things you'd like to see discussed in the
way you'd like to see, so they must be brainwashed; after all, if
they had not been brainwashed they would be discussing the things
you'd like to see discussed. Obviously.

No, they appear brainwashed because they trot out the same tired old
falsehoods in denial of the sorry situation.

That's just a restatement of the same thing: they disagree with you,
so what they are saying must be falsehoods and in denial.

In any case, I don't think that's true. We have spent ages here
discussing nonstandard language ideas. There's nothing wrong with
that.

It would really help if you would consistently use "Standard Forth" to
refer to that specifically, and "Forth" to refer to the wider Forth
world.

I admit that I have been a bit inconsistent about this, but I'm not
going to extend "Forth" in my postings to languages not called Forth.
I'll include all the ancestors of Standard Forth, polyFORTH,
fig-FORTH, but not STOIC, PostScript, etc, because they are too
different in implementation and in language. Not every reverse polish
language is Forth.

Part of Forth's problem is the misidentification of the badly flawed
standard with the valuable Forth technique.

There is no doubt that, if there were no attempt at backwards
compatibility, Standard Forth would be a cleaner and better language;
I don't think anyone would dispute that. It's probably true of every
programming language standard. For example, ISO C has implicit int
and non-prototype function declarations. Everyone has old baggage.

Yes, but C has a good reason: there are billions of lines of
published code, widely used.

I rather suspect that people have plenty of lines of Forth, too.
People like Elizabeth and Steve Pelc have told you so, lots of times,
but rather than accept their answers you just assumed they were lying
to you. Whether this code is published or not is a complete red
herring.

Andrew.
.



Relevant Pages

  • Re: Forth and Unix -- history
    ... Oddly, this doesn't seem to work, and Standard Forth remains more ... so it isn't a popularity contest. ... language like Forth would be really complicated. ...
    (comp.lang.forth)
  • Re: Forth and Unix -- history
    ... But the popularity of the Forth *approach* does matter, ... language like Forth would be really complicated. ... In Standard Forth, you're not supposed to do things in ways that depend on the implementation, remember? ... Other languages get their power from libraries, which reduces the perceptual overload on the user and encourages library development. ...
    (comp.lang.forth)
  • Re: How did C++ beat the competition?
    ... those tools is paramount to the success of a language. ... > other open source products. ... you need to write a killer (i.e ... popularity to open source and the KAP principle. ...
    (comp.lang.cpp)
  • Re: Forth and Unix -- history
    ... I said popularity matters, I never said it was a contest. ... complain about Standard Forth being bloated. ... language like Forth would be really complicated. ... Overloading isn't nearly as bad: decades of experience with other languages show that ordinary overloading of arithmetic operators is well understood by users as long as it's done fairly conservatively. ...
    (comp.lang.forth)
  • Re: Why forth is not popular
    ... > Sure, this method for estimating popularity is not perfect, nor are ... more like those of most other language newsgroups. ... Today people don't read John Dvorak's rants about Forth but some come ...
    (comp.lang.forth)