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