Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What can be learned from studying long gone development practices?

shape-of-code.coding-guidelines.com

Post reply on HN
Print view View original

61–70 of 142 posts

Re: What can be learned from studying long gone development practices?

#61

Post by thaumasiotes »

1vuio0pswjnm7 wrote: post #43
thaumasiotes wrote: post #40

Earlier quoted context omitted.

Aesthetically, it bothers me that you compute x by calling remdr two extra times, as opposed to computing it as the sum of y and z... or the bitwise OR of y and z... What's the difference between :(label) / :s(label) / :f(label) / :s(label1)f(label2) ?

s and f are different conditions s=success f=failure default is unconditional Is bitwise OR a built-in or would it require writing a separate function.

Based on the documentation, there do not appear to be any bitwise operations available in SNOBOL.

It looks like computing x as remdr(3) + remdr(5) is a pure mistake. You only care about the case where remdr(15) is 0, and it's true that remdr(3) + remdr(5) is 0 if and only if remdr(15) is 0. But you're calling remdr twice where you should only be calling it once.

(Or, really, you can keep the weird calculation of remdr(3) + remdr(5), which is conceptually incorrect but correct in every case that matters, but stop computing it with two extra calls to remdr. You're already calculating those values and storing them in the variables y and z; compute x as y + z, which must be much faster than calling remdr two additional times.)

As a side note, why do you want to use "a language for non-numeric computation" for this purely numeric problem?

Re: What can be learned from studying long gone development practices?

#62

Post by googamooga »

gwbas1c wrote: post #44

> I think the best management technique for successfully developing a software system in the 1970s and 1980s (and perhaps in the following decades), is based on being lucky enough to have a few very capable people, and then providing them with what is needed to get the job done while maintaining the fiction to upper management that the agreed bureaucratic plan is being followed. Surprisingly, very little has changed.

This management practice called “programmers anarchy”. It worked very well in my professional life too.

Re: What can be learned from studying long gone development practices?

#64

Post by howenterprisey »

anyfoo wrote: post #42
mamcx wrote: post #39

Earlier quoted context omitted.

"structured programming" is not the use of flow-control but a way to design programs. Even if most language have structured flow-control, a lot of people NOT do structured programming. This is how I remember it back in the day and how I do it (curiously, much better on Rust, where it match better how was done on Pascal! ie: Not OOP, big on structs, functions, enums) and is a mix of: - Define the major components of t…

But then you (and the author?) talk about different things than the Wikipedia entry that the author linked to, because that entry (and what I remember about structured programming--but I was very young, so might have missed a lot) specifically talks about "making extensive use of the structured control flow constructs [...], block structures, and subroutines", also mentioning Dijkstra's "Go To Statement Considered Ha…

As a Wikipedia editor who's poked around in our articles on programming paradigms, there's a decent amount of strange stuff going on -- and I'm not sure how much of that writing I'd take as authoritative, if you catch my drift.

Re: What can be learned from studying long gone development practices?

#65

Post by anyfoo »

howenterprisey wrote: post #64
anyfoo wrote: post #42

Earlier quoted context omitted.

But then you (and the author?) talk about different things than the Wikipedia entry that the author linked to, because that entry (and what I remember about structured programming--but I was very young, so might have missed a lot) specifically talks about "making extensive use of the structured control flow constructs [...], block structures, and subroutines", also mentioning Dijkstra's "Go To Statement Considered Ha…

As a Wikipedia editor who's poked around in our articles on programming paradigms, there's a decent amount of strange stuff going on -- and I'm not sure how much of that writing I'd take as authoritative, if you catch my drift.

I get it, but if the author means a different thing, then they should link to a source that actually defines what they mean (and that I myself could not find, except for the mention of modular programming), instead of to the Wikipedia article that refers to what we have been talking about here.

As it stands, what they link to, and what most seem to understand as structured programming, was not a fad at all.

Re: What can be learned from studying long gone development practices?

#66

Post by 1vuio0pswjnm7 »

thaumasiotes wrote: post #61
1vuio0pswjnm7 wrote: post #43

Earlier quoted context omitted.

s and f are different conditions s=success f=failure default is unconditional Is bitwise OR a built-in or would it require writing a separate function.

Based on the documentation, there do not appear to be any bitwise operations available in SNOBOL. It looks like computing x as remdr(3) + remdr(5) is a pure mistake. You only care about the case where remdr(15) is 0, and it's true that remdr(3) + remdr(5) is 0 if and only if remdr(15) is 0. But you're calling remdr twice where you should only be calling it once. (Or, really, you can keep the weird calculation of remd…

I think the term "non-numeric" probably refers to another popular language of the era from which SNOBOL comes called FORTRAN. The purpose of fizzbuzz as I understand it is to test a person's aptitude for programming, but not necessarily a person's ability to select the "right" programming language.

If the purpose of fizbuzz is to test for programming language selection, and fizzbuzz is a "purely numeric problem", then should the proper choice be FORTRAN.

Re: What can be learned from studying long gone development practices?

#67

Post by lmm »

johnaspden wrote: post #10

I'm not sure you can call structured programming a fad! An awful lot of languages (I'd say all commonly used ones) use if/then/else, do..while, for..next, and so on, but I can't remember the last time I saw a program with a complicated control flow done by gotos. Such things were common in the 1970s, in fact the first professional program I ever read did it that way, and it took me ages to work out what was going on.…

State machines and actors are occasionally cited as good ideas here, and they seem like much the same kind of unstructured programming IME.

Re: What can be learned from studying long gone development practices?

#68

Post by tsss »

johnaspden wrote: post #10

I'm not sure you can call structured programming a fad! An awful lot of languages (I'd say all commonly used ones) use if/then/else, do..while, for..next, and so on, but I can't remember the last time I saw a program with a complicated control flow done by gotos. Such things were common in the 1970s, in fact the first professional program I ever read did it that way, and it took me ages to work out what was going on.…

There are things beyond for-loops and gotos, namely recursion schemes. It's been a long long time the last time I wrote a for-loop and I don't miss them.

Re: What can be learned from studying long gone development practices?

#69

Post by lmm »

flir wrote: post #32
vincent-manis wrote: post #23

`Structured programming' is actually used to refer to two different things: reducing or eliminating the number of gotos, and top-down programming. The former is universally understood to be generally a good thing (though there are still some good uses for gotos); the latter was the fad. The 1970s was the time of HIPO (hierarchy/input/process/output) charts. An early-1980s research project I was acquainted with at the…

Top-down/procedural fits really nicely with the unix command line philosophy. Loose coupling and pipes. You can understand why it was the de facto One True Way before GUIs.

> Top-down/procedural fits really nicely with the unix command line philosophy. Loose coupling and pipes.

I don't think that follows at all. Unix shell programming is very much a bottom-up philosophy where you write a bunch of generic tools and then string them together to solve your actual problem at the last minute.

Re: What can be learned from studying long gone development practices?

#70

Post by m_mueller »

lmm wrote: post #67
johnaspden wrote: post #10

I'm not sure you can call structured programming a fad! An awful lot of languages (I'd say all commonly used ones) use if/then/else, do..while, for..next, and so on, but I can't remember the last time I saw a program with a complicated control flow done by gotos. Such things were common in the 1970s, in fact the first professional program I ever read did it that way, and it took me ages to work out what was going on.…

State machines and actors are occasionally cited as good ideas here, and they seem like much the same kind of unstructured programming IME.

Why? You can easily emulate a state machine with a while loop, a switch case and one more level of if-branches. Abstracting those in a framework doesn't make it unstructured IMO.
Post reply on HN