Re: An Observation

Stephen J. Bevan wrote:
John Doty <jpd@xxxxxxxxxxxxxxxxxxxxxxx> writes:
Stephen J. Bevan wrote:
John Doty <jpd@xxxxxxxxxxxxxxxxxxxxxxx> writes:
In my experience it's a matter of finding the right factors. But maybe
this is different. It doesn't sound like anything LSE (either 16 or 64
bit) has ever been used for. There are no universal solutions.

Now if you're interested in measuring how fast asteroids rotate. Or
testing x-ray optics...
I'm not. The real-world problems I have to solve seem not to be the
type that were considered in the design of LSE64.
Well, that's our cultural divide, isn't it? I wouldn't call parsing
SIP datagrams much of a real-world problem.

Ah, I see then when, back in October, you were pointing out the lack
of Standard Forth libraries to manipulate FITS images then although it
was a "not made up toy-problem" (to quote you) it wasn't a "real-world"
problem either? If it was "real world" then how is manpulating FITS
"real world" and processing SIP is not?

Well, first of all FITS files generally contain actual physical measurements. But I think most FITS users consider the facilities to read and write FITS files "systems" programming in support of their application.

So what languages have FITS support available? FITS is designed for Fortran 66, but these days there's not much of that around. There's the ubiquitous C, of course, but more interestingly there's also support for application languages like IDL, Python, and Mathematica. These are definitely *not* languages you'd choose for decoding FITS files: they have FITS support because they are languages people use for image processing. It's the *application* that matters, not the bits.

These languages are all C-based, so the tricky problem of managing an 8/16/32 bit format is handled by "factors" in C, pretty much like I'd do it in a simple C-based Forth like LSE64.

So, for your SIP problem what matters is the language's suitability for *applications* that need SIP, not for SIP itself.

If it is not "real world"
then that's fine I have no issue with describing processing SIP as a
"not made up toy-problem" and we can just substitute "not made up
toy-problem" for "real world problem" and get back to the issue of
whether LSE can actually solve this "not made up toy-problem" in a way
that is at least as efficient as "Standard Forth".

Parsing SIP isn't a made up toy problem, but it's not an application. It is systems programming in support of a class of applications. It isn't a good test of the suitability of a language for applications.



I'm unconvinced that LSE couldn't solve your problem. I was always
amazed by what we could tackle with a 2 MHz 1802 in the days of 16 bit
LSE.

I've explained the problem and why LSE is slower than "Standard
Forth".

Is C slower than Standard Forth? LSE64 can use C factors, and therefore can be as fast as C. For a full application, I expect LSE64 can be faster than straight C, because you avoid much clumsiness by choosing factors that match the needs of the application: C's functions aren't so good here.

It's not any different from the old days of CODE definitions (except C is portable). The trick was to find a few simple factors to relieve the bottlenecks, not to write the whole application in CODE.

If you are unconvinced then please point out the error in
what I wrote. Alternately you could argue that performance isn't
everything and that the benefits of LSE outweights the performance
loss -- same type of argument that is used to use Forth instead of
assembly. That's going to be a tough sell to *me* since other than
always compiling (which I'm neutral on) the other features of LSE
strike me as negative rather than positive. You'd have a much better
chance of convicing me to use Scheme or O'Caml since with those
languages I can see how the cost/benefit tradeoff can be worth it for
some applications.


I know there is no facility right now. However, there is no
fundamental reason why there could not be, it is just a design choice
which you can choose to make, or not, which ties in with ...
What top level application requirement might be served by changing
this design choice?

You've repeately complained that "Standard Forth" has too many words
built in. It is hard to have less words than a single one: "load".
Once you go above that, everything is is a judgement call and open to
question if that word is not needed for a particular application. For
example, given your comments about "Standard Forth" I expected LSE to
have a minimal set of words and yet LSE64 has floats and IO built in.
Thus it is subject to a similar criticism as you made of "Standard
Forth".

LSE64 has a *lot* less vocabulary bloat than Standard Forth. And some of it will go away next round. Will any words *ever* be removed from Standard Forth?



Standard Forth has driven away nearly everyone who might benefit from
Forth technique. The problem isn't just one feature: it's the
"write-only language for overspecialized programmers" culture that its
totality represents. Out in the real world, Forth's reputation
stinks. This is a shame, because the Forth *idea* represents a
great way to design and organize software.

Proponents of APL, Lisp, Prolog and Smalltalk will say the same thing.
Each of those has a reputation problem which clearly can't be blamed
on Standard Forth.

No, but they suffer from similar design problems, fundamentally a lack of attention to *human* communication.

Contrast them with Mathematica, whose fundamental "FullForm" is very Lispy and not very usable by humans, but which can translate expressions to/from a variety of forms either more writable or readable. Mathematica can be a great tool for human communication, even if the readers of the code don't know it very well. A direction for a 21st century Forth to go, perhaps?

So, it it just possible that there is a reason
other than "Standard Forth" that explains why Forth also a niche
language? If not, and it is simply "Standard Forth" then presumably
LSE64 will supplant "Standard Forth" and grow in use in the "real world".

Where does Forth belong in the 21st century software picture? From where I sit, it looks pretty close to extinct...

--
John Doty, Noqsi Aerospace, Ltd.
--
Specialization is for robots.
.

Relevant Pages

  • Re: An Observation
    ... LSE isn't intended for narrow specialists. ... invisible to users who write standard code. ... very narrow area of the programming universe. ...
    (comp.lang.forth)
  • Re: An Observation
    ... It doesn't sound like anything LSE (either 16 or 64 ... that is at least as efficient as "Standard Forth". ... fundamental reason why there could not be, it is just a design choice ... "write-only language for overspecialized programmers" culture that its ...
    (comp.lang.forth)
  • Re: An Observation
    ... invisible to users who write standard code. ... portability issues off of the language users' plates onto the language ... but John isn't considering LSE an end-point. ... Note that Mathematica is kind of an umbilical system, ...
    (comp.lang.forth)
  • Re: An Observation
    ... I wouldn't call parsing SIP datagrams much of a real-world problem: it's systems programming, deep in the Platonic artificial world of the computer. ... is no requirement that LSE64 has to be able to solve my problems. ... LSE64 has remained true to Forth's roots, while Standard Forth has evolved away from real-world applications toward the comfort zone of programmers troubled by the reality outside the computer. ... I'm unconvinced that LSE couldn't solve your problem. ...
    (comp.lang.forth)
  • Re: State of Forth 200x
    ... This is a simple, straightforward concept that all languages share, and in my experience students have no trouble with it. ... LSE> char X char Y 2 put iterate ... But this possibility has been a greatly admired feature of LSE by its users. ... similar only in that they involve an ASCII code for a single character. ...
    (comp.lang.forth)