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

41–50 of 142 posts

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

#41

Post by _moof »

bitexploder wrote: post #26
kevin_thibedeau wrote: post #25

Earlier quoted context omitted.

> I can't remember the last time I saw a program with a complicated control flow done by gotos. I've run across this in C demo code for a chip designed within the last 10 years. It was all goto soup in a god function.

Some embedded developers just never got the memo about control flow constructs. You can find some truly bizarre and concerning development practices in the embedded world.

Yes, well, some of us are working with barely more than what a Commodore VIC-20 had to offer. (And we like it!)

;)

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

#42

Post by anyfoo »

mamcx wrote: post #39
anyfoo wrote: post #13

The article says: > Today, structured programming appears remarkably simplistic, great for writing tiny programs (it has an academic pedigree), but not for anything larger than a thousand lines. Curious. I rather think that structured programming became so ultra-pervasive in any high level programming language younger than 50 years old or so[1], that we've lost the extra name for it. Practically every programming lan…

"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 Harmful" and some debate around that.

The structured program theorem is also about specific control structures, essentially proving that they are Turing complete by themselves. I remember that we had to prove in university that as a result, you can transform any program into a program with one big while loop. (I think that's equivalent to "μ-recursion", whereas the simpler "LOOP" statement only implements "primitive recursion" which is not Turing complete, but it's been a while.)

What you talk about sounds like it could be "modular programming", of which Wikipedia states: "Modular programming per se, with a goal of modularity, developed in the late 1960s and 1970s, as a larger-scale analog of the concept of structured programming (1960s)."

Of course, Wikipedia is not a good source, I wasn't there when it started, and it's entirely possible that structured programming meant more back then than it seems to mean today, or meant different things in different circles. A quick Google search seems to confirm that nowadays structured programming primarily seems to be the use of control structures, though maybe that's just what survived?

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

#43

Post by 1vuio0pswjnm7 »

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

Earlier quoted context omitted.

"... I can't remember the last time I saw a program with a complicated control flow done by gotos." Perhaps not "complicated" enough, but here's a fizzbuzz in spitbol (a fast SNOBOL interpreter). This is an unstructured, goto based language for non-numeric computation developed at Bell Labs. Would love to see a faster version in some popular, "structured" scripting language in the same number of characters. I find I…

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.

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

#44

Post by gwbas1c »

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

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

#46

Post by fiddlerwoaroof »

anyfoo wrote: post #18
ardit33 wrote: post #5

Earlier quoted context omitted.

It was actually an interesting read. TLDR: Whatever software building methodology/process you are using now, is probably crap, and made up by people that don't really know any better and just making things on the go. Eg. He mentioned 'structured programing' was a fad at the time. Now it is Agile, and its offshoots. Best way to deliver software is to have a handful of capable people and pay them well and get out of th…

"Structured programming" was 100% successful, and we're all still using it, all the time. It was so successful, that we don't even talk about it anymore. With few exceptions, it's just how programming is now. Does not invalidate your actual point, though.

Yeah, the nearly-complete absence of GOTO in the programming languages people actually use is proof of this.

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

#48

Post by jay_kyburz »

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

I've been learning lua, and loops don't have a continue or a break. You can use a goto to jump out. I tried it but didn't like it. Might just be prejudices. :)

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

#50

Post by mianos »

aetherspawn wrote: post #27

> 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 > There is one technique for producing a software system that rarely gets mentioned: keep paying for development until something good enough…

I honestly think this is still true. Good people getting stuff done is still hidden, now behind some wagile (waterfall agile) in larger companies where the incompetent have been promoted to one step above their ability (the 'Peter Principle'), and the people who do the real work keep doing it.
Post reply on HN