Re: An Observation

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? 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".


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". 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".


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. 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".
.

Relevant Pages

  • Re: An Observation
    ... Since users literate in Standard Forth are extremely rare, code in Standard Forth has a negligible maintainability advantage over other dialects. ... This moves many of the compatibility and portability issues off of the language users' plates onto the language developers' plates, ... But I know one physicist who considers LSE the most readable programming language ever. ... Note that Mathematica is kind of an umbilical system, with a GUI front end in a separate process from the kernel, which can be on a different machine, possibly even with a different architecture. ...
    (comp.lang.forth)
  • Re: An Observation
    ... It doesn't sound like anything LSE (either 16 or 64 ... If it was "real world" then how is manpulating FITS ... There's the ubiquitous C, of course, but more interestingly there's also support for application languages like IDL, Python, and Mathematica. ... that is at least as efficient as "Standard Forth". ...
    (comp.lang.forth)
  • 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
    ... 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)