[HN Gopher] Programming a Problem-Oriented Language (1970) [pdf]
___________________________________________________________________
Programming a Problem-Oriented Language (1970) [pdf]
Author : tosh
Score : 39 points
Date : 2022-10-12 18:14 UTC (4 hours ago)
(HTM) web link (www.forth.org)
(TXT) w3m dump (www.forth.org)
| dang wrote:
| Related:
|
| _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)
| anyfoo wrote:
| 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.
| justincormack wrote:
| 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.
| tjoff wrote:
| > _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.
| justincormack wrote:
| 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.
| steve_john wrote:
| JohnDeHope wrote:
| 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.
| JohnDeHope wrote:
| 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.
___________________________________________________________________
(page generated 2022-10-12 23:00 UTC)