Re: An Observation

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: it's systems programming, deep in the Platonic artificial world of the computer. Not that systems programming is a bad thing by itself: it's been my job description on occasion. But it doesn't give you much real-world perspective.

That's fine, there
is no requirement that LSE64 has to be able to solve my problems. But
it does mean that I find it hard to read messages about the simplicity
of the LSE64 approach over Forth when, at present, LSE64 cannot solve
the problems but Forth can.

ARRGGH! LSE64 is a Forth dialect. "Standard Forth" is another Forth dialect. LSE64 has remained true to Forth's roots (what was the first Forth application?), 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. I was always amazed by what we could tackle with a 2 MHz 1802 in the days of 16 bit LSE.



"load" loads LSE source. There's no facility to output compiled LSE to
a .so, so "loadmod" only loads C binaries or perhaps other binaries
with C calling conventions (never tried that, though). So in general,
you "load" a package which then gets any needed primitives via
"loadmod".

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?


A different model. More work. Can I find a customer who'll pay for it?
Maybe. But more importantly, can I find a customer who'll pay for it
and not distract me with higher priority science and engineering
issues? Not likely. Unfortunately for LSE, software is a sideline for
Noqsi Aerospace...

That's perfectly reasonable; you might consider the same reason when
you next comment/complain about some feature 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. Too bad the Standard Forth community has forgotten it...

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

Relevant Pages

  • 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: Toward a Forth thats easier to learn
    ... overloaded operations so the results come out smooth? ... So people who write in LSE aren't locked ... LSE64 is released under GPL and works on several flavors of Linux and MacOSX platforms, ... It would be nice to have lots of standard code for jobs like this, and a community to support them, but in the end LSE64 isn't my product, it's more a tool for building tools. ...
    (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)