Programming a Problem-Oriented Language (1970) [pdf] | Hacker News Reader

Programming a Problem-Oriented Language (1970) [pdf]

forth.org

69 pointstosh9 comments

This is a good read, I liked the philosophy behind

Do not put code in your program that might be used. Do not leave hooks on which you can hang extensions. The things you might want to do are infinite; that means that each one has 0 probability of realization. If you need an extension later, you can code it later - and probably do a better job than if you did it now. And if someone else adds the extension, will they notice the hooks you left? Will you document that aspect of your program?

Which then and now generally people don't agree with.

>The things you might want to do are infinite; that means that each one has 0 probability of realization.

That does not follow.

>If you need an extension later, you can code it later - and probably do a better job than if you did it now.

Not if it requires intimate knowledge of the internals. Then you'll need weeks just to get reacquainted and then you might still not know enough to do a good job of it.

Just today I was implementing a feature that I chose not to do initially. Now I was burdened with an incomplete view of the system and also had to deal with a lot of other code that was written in a certain way because the feature didn't exist at the time. I'm sure it would have been better if I had done it in the beginning.

I agree with the sentiment, but disagree with the arguments. In the end it is a judgement call as any.

Of course, and it only works well in certain situations, like you do have a complete view of a Forth system because it is small and you write it yourself, and it doesn't take weeks. I recommend reading it, just as a different point of view.

Programming a Problem-Oriented-Language (1970) - https://news.ycombinator.com/item?id=18756990 - Dec 2018 (4 comments)

Programming a Problem-Oriented Language (1970) - https://news.ycombinator.com/item?id=8387120 - Sept 2014 (13 comments)

Charles H. Moore – PROGRAMMING a PROBLEM-ORIENTED-LANGUAGE [~1970] - https://news.ycombinator.com/item?id=8323235 - Sept 2014 (1 comment)

I'm playing around with prolog at the moment and I think it's a great problem oriented language.

For many problems I want to create a specification about my problem space and then reason about it.

I feel that prolog is closer to asking a computer for a solution rather than telling it what to do.

Reading old IBM documentation for System/360 and 370, from the 70s and 80s, I thought it was interesting that what we today would probably call "business logic", back then IBM apparently used to call "problem code" or "problem program".

I don't know if this is coincidence, or if that term was more widespread at the time.

It's clearly meant to mean "the code that solves the actual problem", but it still sounds a bit unfortunate.

> But suppose everyone wrote their own subroutines? Isn't that a step backward; away from the millenium when our programs are machine independent, when we all write in the same language, maybe even on the same computer? Let me take a stand: I can't solve the problems of the world. With luck, I can write a good program.

This is fascinating to read. Also, if I work with you and you adopt that philosophy, I while fight you do the death.

The old school formatting of this document makes it hard to read. I might re-format it as a way to force myself to read it.

Oh nevermind, this link was to a very old bad copy of the document. There are newer nicer copies of the same book laying around the internet.

Reply on news.ycombinator.com