
Programming a Problem-Oriented Language (1970) - _qc3o
http://www.colorforth.com/POL.htm?html
======
btbytes
This is a better typeset version (without the bold font-face and using
monospace for code):

[https://github.com/btbytes/pol/raw/master/POL.pdf](https://github.com/btbytes/pol/raw/master/POL.pdf)

------
marktangotango
>> A problem-oriented-language is a language tailored to a particular
application. To avoid that uniquely clumsy term, I'll usually substitute
application language as synonymous.

Is this equivalent to today's idea of Domain Specific Langauges?

~~~
bunderbunder
Speaking from the armchair, I'm gonna go with "not really". Part of what makes
a good DSL good is that both its semantics _and_ its syntax is well-adapted to
the problem domain. And they don't necessarily have to be built up within the
syntax of some other language. Gherkin comes to mind as an example, or perhaps
Inform.

Whereas what Moore's talking about (I think - I haven't read all of the linked
article just now, of course, but once upon a time I did belong to the Chuck
Moore fan club.) is something closer to just writing well-factored code - you
build up a bunch of small routines to do small problems, and build other
routines on top of those, until you've constructed a library that lets you
speak about the problem succinctly. This isn't really too far off from what
Abelman and Sussman were advocating in SICP. (And personally I like to think
of Forth and Scheme as being two different sides of the same coin.)

They're both useful concepts, but they're useful for different things. DSLs
are great for many tasks, but building a good DSL takes a lot of time, so it
isn't really worthwhile unless you expect it to be used a lot. OTOH, this
"problem-oriented" concept is useful most everywhere, including for writing
one-offs. I'm less certain of the value of using something like Forth's
compiling words or Scheme's macros to do it, though - metaprogramming makes me
feel like a superhero, but it also makes me want to kick myself when I need to
try and make sense of something I wrote two years previously.

~~~
wtetzner
I think what Moore is talking about is what is called an Embedded Domain
Specific Language.

------
earlz
Thus far a lot of what he says seems smart... until I got to this:

"Make variables as GLOBAL as possible. Why not? You can save some space and
clarify your requirements. For instance, how many Is, Js and Ks do you need?
In most cases a single copy in COMMON would suffice (you have to declare them,
remember, and may as well put them in COMMON); you can redefine it locally if
you must; and it is of interest that you must."

Maybe I'm just misunderstanding him, or it's a difference in languages

~~~
astrobe_
You have to remember why globals are considered "evil" today: 1) bad for
modularity 2) bad if you have threads 3) bad for debugging (referential
transparency etc.)

In the seventies, I think that threads simply didn't exist. As for modularity,
it is pretty clear from the rest of the book that Moore doesn't consider it as
something important. He prefers high performance, ad hoc code. This made sense
given the limited power of CPUs at that time, and this still makes sense in
the embedded world, sometimes. Finally, the negative impact of global
variables is probably proportional to the size of the program. He is talking
about programs that could easily fit in the L1 cache of yesterday's Pentiums
(a few dozen of kilobytes max).

Furthermore when one programs in Forth, one problem is that you simply can't
declare local variables: all you have is two stacks. It often simplifies a lot
the functions ("words" in Forth lingo) to "offload" some data into (global)
variables. This actually helps with debugging, given that in older systems one
had very few debugging tools, because one could interrupt the program and look
at the state of those variables in order to guess what's going on.

~~~
wtetzner
There's another problem with global variables, though. They make it harder to
reason about your program. Who knows which of the functions you're calling are
updating which global variables?

Of course, as you said, things are a bit different in Forth.

------
ers35
PDF version: [http://www.forth.org/POL.pdf](http://www.forth.org/POL.pdf)

Edit: Better typeset version by btbytes:
[https://github.com/btbytes/pol/raw/master/POL.pdf](https://github.com/btbytes/pol/raw/master/POL.pdf)

------
tempodox
Although it only uses HTML, that text manages to look as god-awful as can be.
Seriously, everything in _boldface_? No text rendering engine in the universe
can save you from a writer like that.

