Hacker News new | past | comments | ask | show | jobs | submit login
Programming a Problem-Oriented Language (1970) (colorforth.com)
51 points by _qc3o on Sept 30, 2014 | hide | past | favorite | 13 comments



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


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


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.


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


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


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.


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.


Moore seems to have a very different conceptualization of what good software is compared to the common wisdom.


... of which decade?

Dijkstra's considered harmful was published in 1968.


Of this decade. He still seem to have unconventional opinions on software (maybe not on global variables in particular any more, though).


He does have unconventional opinions on software. Just consider the programming language that eventually grew out of the thoughts laid out in this essay: It's untyped, point-free, syntax-free, and lacks local variables (at least in most versions).


PDF version: http://www.forth.org/POL.pdf

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


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.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: