[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)
 
web link (www.forth.org)
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)