Re: Forth and Unix -- history

mhx@xxxxxx (Marcel Hendrix) writes:

Aleksej Saushev <asau@xxxxxxxx> wrote: Re: Forth and Unix -- history

[..]

Even those who are admired by Forth elegance, after more investigation
come to the same conclusion, that Forth is a bad choice to solve problems.

Because...

I've heard that from completely independent source, and it was said then,
"I would learn PERL better, it is horrible, but it works, there's CPAN,
it is horrible inside, but I don't need to do everything from scratch."
Python was not spread wide enough then.

Well, that settles the matter for once and for all, it must be true,
Forth is dead :-)

Forth, as a language, gives you all the building blocks. A complete
Meccano set (http://en.wikipedia.org/wiki/Meccano) with every possible
basic nut and bolt you'll ever need. It's guaranteed that you will be able
to build anything conceivable (through the build-in assembler, that in itself
you can extend for all hardware you'll ever own). It's guaranteed that you
will be able to keep up with all the programming fads du jour (because you
can extend the compiler and the syntax if you want). It's interactive, so that
you can debug literally every byte of code you'll ever write. It's so simple
that in the past people have complained that a language that can be learned
in an evening from a comicbook will never get any academic credit. And, oh
yeah, it's an ANS/ISO standard. You can pick up a Forth for all the platforms
you'll ever want to work on. You will never be painted in a corner by a vendor
or a CPU manufacturer. If needs be, you can port your own Forth (there's
certainly no dearth of libraries for *that* particular purpose :-)

Up to here, the description is generic. Even the lowest free Forth will give
you all of the above.

So does FORTRAN, so does C, so does PERL, so does Python.

But: with any FORTRAN you get almost everything from netlib,
and you have GAMS to ease the search, with any C you get GSL and
all the stuff, from numeric algorithms till XML processors and
parser generators, with PERL and Python you get package
management and interface to any kind of FORTRAN or C library
above. All that is free and easy enough to comprehend,
in Forth all the corresponding stuff is available at high cost
either in money, and that's the sign, that the language itself
is overly complex to use, and in time, because information is
hard to find, there's very small community, which is almost
closed and devoted to rather narrow field. Of course, you can
bring your proof-of-concept solutions, but they don't work most
of the time, since they don't support many useful standard
features, which people want. Investing more time in learning
how to finish half-done work is far below in wish-list.

Now you start some serious work and, indeed, quickly find that all that freedom
and elegance comes at a cost.

All the freedom and elegance of Forth comes at very high cost,
Python isn't less elegant, and given the usability superiority
no wonder it attracts more users.

I think you don't mind solving your main research problem (you will even insist
on that), but hate the idea of having to write stuff that you feel (or know) is
already available in some form. What to do?

Out of research you are less free in language choice,
and there Python is absolute winner in Python v. Forth.

If you have *no* idea of how you'd solve the problem yourself, you may be
sympathetic to buying a solution, or contract somebody to do it for you. So ask
your vendor, or choose a Forth that has the stuff you need to begin with.
It diminishes some of the good things I mentioned above, but life is full
of these compromises, and this one is not Forth specific.

Look, Python comes with much of free and good quality code, and
that's clear sign that it's better than Forth: easier and more powerful.

If you feel that you could easily solve the problem yourself, your expectation
might be that you should be able to get the pre-written code for free somewhere.
Maybe you'll expect this code to be present with your Forth, as a convenience.
(Many of the commercial Forths cater for this.) If it's not, you'll probably decide
to interface to some free library written in whatever language.

Look, Python interfaces with any free usable library, that's a
clear sign interfacing is easy. What about Forth FFI abilities?
Latest Gforth is 0.6.2, which is 4 years old (copyright notice
at start shows that year), it has undocumented 2 or 3 kinds of FFI,
which depend on compile time options and can't be used simultaneously.
In addition, there's no way to get access to global variables,
and that is frequent way to pass error codes in C.
SP-Forth FFI is even more low-level, and it's more horrible.
Why this is so bad? Obviously, Forth is bad at interfacing
other libraries for practical reasons.

In addition, why no new version of GNU Forth for 4 years?
Obviously, project is mostly abandoned due to lack of manpower,
which is not enough to fit language complexities.

The only thing I can imagine going wrong here is that the Forth you have chosen
does NOT allow you to dynamically link to foreign code.

That's not the problem, there _is_ a way to get out of the bottle,
if you've got there, though the price may be too high.

Another nuisance could be
that the Forth is extremely barren -- it is no fun to link to external C code every
time you want to use an 8-bit byte or a double-precision complex number, or for the
most trivial of extensions (listing a system directory, using a Poisson cumulative
distribution function, etc.).

If it's easy to reimplement it in Forth, why we don't see it?
Even proof-of-concept toys do not exist. Not even copyrighted ones,
though this kind of stuff should be in public domain.
Look into GNU awk info, and you find limited reimplementations
of other common utilities, like wc et al.

So my feeling is that a serious professional user of Forth will have no problems,
but s/he may still complain that some of the stuff s/he needs, ought to be
a) build-in,
b) a pre-written interface to outside code.

The problems you mention fall under point b), and I think it is unreasonable to
grumble about them (for professional users).

The complaint in this thread seems to be that in *other* languages b) is not a
problem, because they have more things build-in (i.e. a)) and many more *free*
interfaces are available.

Although building-in more functionality is easy for the vendor, the users may
opt more for b). Ok, now we have a point: Why is there no standard foreign
function interface for Forth? It isn't even in Forth-20xx ...

Do you suggest that I'd write the proposal? Thanks, no.
It contradicts my habits not to standardise anything before its usage been
proved successful in some experimental stuff at least. My point here,
that this is pointless because nobody writes code, compared to Python
or PERL. Or even TCL.

And even when there is no standard FFI, why do the Forth users not publish their
interface code to all those external goodies? I have tried with the iTools (sockets)
package. It is not very difficult to support the main Forths for something like that,
but after receiving zero response on my effort, I'm certainly not going to push any
more dead horses like these. I must conclude that Forth users find this issue not
important at all.

As far as I remember, you wrote that for your own Forth, which
is not accessible, since it's closed, it's for Linux-only.
I can't comment it, since I am NetBSD user, and I don't want to
mess with Linux just to check a single closed Forth, even when
it claims to be the fastest, even when it is really the fastest.

I've managed to make Gforth socket interface work under Cygwin
and under NetBSD, that's enough to me. I'd like to look at that,
but still it's hopeless, because even 2 men can't do much.

To the expert, almost everything is a toy problem.

I don't think that that man being expert would like to
reimplement even simple band matrix eigenvalue solver in Forth.

Why in Forth? Use the Lapack one.

Of course, one would use LAPACK in right mind, but reimplementation
in Forth seems to be useful only for trivial problems, like simple
data preparation, reshuffling, or input/output. And there're still
no either standard dynamic strings, nor regular expressions, nor
string formatting tools.

It's a waste of time. When given some problem he would stay
with PERL,

.. and solve band matrix eigenvalue problems with double complex regular
expressions?

... Python or any other _real_, _practical_ programming
language. Or he'd choose two languages, one for numeric part,
one for gluing. No place for Forth still.

I object to your use of _real_ and _practical_ in this way.
And of course I don't agree with Forth not being useful for gluing.

My execve+fork code wasn't met enthusiastically too.
Either Forth programmers don't do that, or they are so bad that
don't know how system(3) works on POSIX systems and likes.
In both cases it's a bad sign.

To use Forth you have to be expert in your domain, in programming,
and in software engineering, since you have to reuse other code.

There's no logic in this sentence? Didn't you mean to write:

If, as in expert in your domain, you want to use Forth, you have
to have knowledge in programming and in software engineering.

I distinguish programming (algorithmics &c) and software engineering,
because I frequently meet examples of good enough programmers, but
bad system designers and packagers.

There's big problem in Forth to reuse someone's code and make
your code reusable. This problem is mostly unsolved.

And I sure hope that expert has. But s/he can start by choosing a
good Forth, and farm out the drudge to John Doty.

I'm afraid that when expert starts choosing good Forth, he ends
with Python or even more high-level tool, like Mathematica, Matlab,
Maple, SPSS, Stata, or at least, Octave or R.

So experts don't choose Forth.

It doesn't follow automatically.

It is, here and now. And as it is, the same problems of 20 years
past do exist still.


--
CKOPO CE3OH...
.

Relevant Pages

  • Recommend an E-book Meeting the Following Criteria (Newbie, Long)
    ... I know several programming languages namely Java, Perl and C in this order ... Now I'm wondering which Python book I should get as there are so many out ... I'd like to mostly concentrate on language features but some pointers ...
    (comp.lang.python)
  • Re: Python or PHP?
    ... If it's one of the things for which Python ... every language here and there more ways to do something. ... you make Perl more complicated than it is:-D. ... Not the programmer. ...
    (comp.lang.python)
  • Re: Ruby vs. PHP
    ... done is checked out which versions of Perl, Python, YARV, Ruby, jRuby ... dynamic language to the seconds for the benchmark with gcc. ... YARV, Python, Perl and PHP have fairly close medians and the boxes are ...
    (comp.lang.ruby)
  • Re: Forth and Unix -- history
    ... "I would learn PERL better, it is horrible, but it works, there's CPAN, ... Forth, as a language, gives you all the building blocks. ... to interface to some free library written in whatever language. ... reimplement even simple band matrix eigenvalue solver in Forth. ...
    (comp.lang.forth)
  • Re: Python vs. Perl
    ... I would say that the real difference between python and ... To help aid in this discussion, the following Python and Perl ... While Guido originally intended Python to be a second language ...
    (comp.lang.python)
Quantcast