What can be learned from studying long gone development practices? • Hacker News Board

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

#101

Post by oblio » Mon, Aug 16, 2021, 12:20 PM UTC

1vuio0pswjnm7 wrote: post #59

wtallis wrote: post #56

Earlier quoted context omitted.

> But of course aesthetics is subjective. (The term "subjective" here means what looks good to you might not look good to me, and vice versa.) Bullshit. There's so much that objectively deficient about that piece of code that I'm having trouble taking you seriously. If that comes at all close to being a representative sample of someone trying to make clear, readable code in that language, then the language was clearl…

"output" is a keyword, cannot change it (I guess one could recompile the interpreter and define it as something else) semicolons separate statements. Dont like them at the beginning, move them to the end. Dont like the label names. Rename them to whatever suits you. The thing that you may be misunderstanding is that this is written for me, not you. It is written to please my sense of aesthetics, not yours. I am not e…

> Honest question. Why are there so many different languages. Whats behind that.

1. Personal pride.

2. Personal or corporate need for control

3. Personal or corporate need for visibility/fame.

4. Licensing unfit for desired use.

5. Technical or social impossibility to extend existing language to fit target space.

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

#102

Post by lmm » Mon, Aug 16, 2021, 12:32 PM UTC

m_mueller wrote: post #74

lmm wrote: post #72

Earlier quoted context omitted.

> You can easily emulate a state machine with a while loop, a switch case and one more level of if-branches. You can easily emulate GOTO much the same way.

obviously, as long as the language is turing complete, but you just converted an unstructured program to a structured one.

To the same extent, and in the same way, as you did when you converted a state machine the same way? I still don't get what distinction you're drawing between state machine style and GOTO style.

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

#103

Post by kqr » Mon, Aug 16, 2021, 12:39 PM UTC

urthor wrote: post #79

kqr wrote: post #53

I disagree strongly with the authors assessment of the state of software development a few decades ago. By the late 1960s, we had realised software development was hard. We put some good brains on the problem. Discussions between leading experts brought up several very important points, that we struggle with to this day: - Naming things, - Low coupling and high cohesion, - Communication between developers, - Communic…

Honestly there is a bit more than that. The idea of mass development with large, open ended access to code is actually a surprisingly recent idea. Plus of course Stackoverflow has significantly changed the approach. Concurrent programming is also significantly different to its 1960s iteration. COBAL and Fortran did not even attempt to do such a thing, the handling of all those asyncs was not around . Many many other…

Maybe the nature of our concurrency problems has significantly changed, but from what little I remember, I don't think so. More people attempt to design for concurrency now, but shared memory, actors, barriers etc have been around at least since the early--mid '70s.

Do you really think branch prediction has significantly reduced the difficulties in developing software, or altered the way software developers work? Bringing up things that have changed behind a compatibility layer that makes us program against an emulated PDP-11 sounds to me like support of my thesis, if anything: the only changes to the way we work are faster computers and higher level languages.

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

#104

Post by mathattack » Mon, Aug 16, 2021, 12:43 PM UTC

The overwhelming attitude in a pre-agile world with a shortage of programmers was:

1) Create a division of labor so that tasks could be pushed to the cheapest person available.

2) Create a waterfall with documented buy in each step of the way.

3) Train an army of smart people for 6-8 weeks and cut them loose in specialized role. (Either a process person writing requirements or a tech person coding them or a tester confirming the code does what’s needed or change person teaching users)

4) Design and conceptual integrity of the whole were frequently missing.

5) The system buckled when requirements were wrong or changed.

6) Terms like “software factory” were used. When they’re used to today they reflect this mindset.

7) The best programmers were trapped in a system that wouldn’t promote them beyond a certain point because they weren’t generating revenue or managing a large group of people.

8) The sum of this was an industry notorious for overdue and over budget projects.

8.5) People prayed for their overdue projects to get cancelled before their portion would be blamed.

Software development isn’t perfect today but we are in a much better place.

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

#105

Post by zbentley » Mon, Aug 16, 2021, 1:34 PM UTC

oblio wrote: post #101

1vuio0pswjnm7 wrote: post #59

Earlier quoted context omitted.

"output" is a keyword, cannot change it (I guess one could recompile the interpreter and define it as something else) semicolons separate statements. Dont like them at the beginning, move them to the end. Dont like the label names. Rename them to whatever suits you. The thing that you may be misunderstanding is that this is written for me, not you. It is written to please my sense of aesthetics, not yours. I am not e…

> Honest question. Why are there so many different languages. Whats behind that. 1. Personal pride. 2. Personal or corporate need for control 3. Personal or corporate need for visibility/fame. 4. Licensing unfit for desired use. 5. Technical or social impossibility to extend existing language to fit target space.

And plain old ... personal/group preference?

Some people like different tools for reasons other than pride, ambition, need for control, etc.

Some things are more enjoyable for some people. Chocolate vs vanilla kind of thing.

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

#106

Post by lelanthran » Mon, Aug 16, 2021, 1:53 PM UTC

lisper wrote: post #29

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.

The problem with C is that it doesn't have proper tail recursion, so if you want to use C as a target language for something that does have proper tail recursion, you pretty much have no choice but to make goto soup.

> The problem with C is that it doesn't have proper tail recursion, so if you want to use C as a target language for something that does have proper tail recursion, you pretty much have no choice but to make goto soup.

Or you could, you know, use a normal loop...

Besides, since 2005 or thereabouts gcc with -O2 did proper tail-call optimisation so that the stack doesn't grow on a tail-call recursion.

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

#107

Post by rcxdude » Mon, Aug 16, 2021, 2:35 PM UTC

nitrogen wrote: post #38

bitexploder wrote: post #26

Earlier quoted context omitted.

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.

The reverse is true -- app developers see something "weird" in embedded code and think it must be wrong, but often there is a reason. E.g. the unintended vehicle acceleration scandals, where codebases were criticized for having large numbers of global variables... but it's because there's no allocation permitted, and message passing is more expensive than just setting a bit of memory in a massive cooperative multitas…

I work on embedded software and far more often there's no good reason. (the global variables thing is ambiguous: it could be just counting static variables with well-defined scopes and encapsulation, or it could be describing truely global variables which can be modified by any part of the code at any time. The former is a reasonable technique to seperate modules without allocation. The latter is hair-raisingly reckless software design and also probably the more common approach, even in safety-critical systems). The level of awareness of software engineering concepts in the embedded ecosystem seems far lower than other areas.

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

#108

Post by wtallis » Mon, Aug 16, 2021, 3:11 PM UTC

hnlmorg wrote: post #88

wtallis wrote: post #56

Earlier quoted context omitted.

> But of course aesthetics is subjective. (The term "subjective" here means what looks good to you might not look good to me, and vice versa.) Bullshit. There's so much that objectively deficient about that piece of code that I'm having trouble taking you seriously. If that comes at all close to being a representative sample of someone trying to make clear, readable code in that language, then the language was clearl…

> Bullshit. There's so much that objectively deficient about that piece of code I don't agree the GPs code is more aesthetically pleasing but he's right that it is subjective. All the counterarguments you've given are subjective to you (eg you know what tokens do in over languages, spent zero time learning the tokens of this language and thus you're clearly not going to know what a colon does in this language just by…

> All the counterarguments you've given are subjective to you (eg you know what tokens do in over languages, spent zero time learning the tokens of this language and thus you're clearly not going to know what a colon does in this language just by looking at it).

I tried very hard to only bring up problems that were at least somewhat objective. Counting the number of superfluous symbols in the code is not purely subjective. Noting the similarity between "x01" and "x01a" is not purely subjective. Measuring the distance between a conditional test and its consequences is not purely subjective.

And I did figure out what a colon does in this language just by inspecting this code. It's semicolons that serve no apparent purpose in this snippet, and even with the outside knowledge that they serve the same statement separator purpose as in C and many other languages, it's still an objective fact that they are largely redundant. The character count could have been a lot lower if the language made it the default for new lines to start new statements and used a special character for continuing a statement on another line.

Subjective would have been if I complained about the semicolons being at the beginning of the line instead of at the end. That's almost purely a matter of taste driven by prior experience with other languages.

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

#109

Post by regularfry » Mon, Aug 16, 2021, 3:12 PM UTC

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…

> each procedure must be in its own source file.

Funnily enough, this is how GNU libc is organised.

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

#110

Post by dhosek » Mon, Aug 16, 2021, 3:26 PM UTC

dhosek wrote: post #36

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…

TeX was Knuth's first “real” programming in a few years. His comments on structured programming are a bit eyebrow raising. He had high praise for it and said that it allowed him to write the whole program without having to test small parts of the program (the book with the exact quote is upstairs and I'm too lazy to go get it). That said, I'm pretty sure that TeX is more than a 1000 lines of code.

Here's the actual quote, which is illuminating:

“TeX was the first faily large program I had written since 1970; so it was my first nontrivial ‘structured program,’ in the sense that I wrote it while consciously applying the methodology I had learned in the early 70s from Dijkstra, Hoare, Dahl, and others. I foudn that structural programming greatly increased my confidence in the correctness of the code, while the code still existed only on paper. Therefore I could wait until the whole program was written, before trying to debug any of it. This saved lots of time, because I din't have to prepare ‘dummy’ versions of nonexistent modules while testing modules that were already written; I could test everything in its final environment.”

That said, there are still 337 instances of goto in tex.web by my quick and dirty count (grep goto tex.web | grep -v '@' | wc -l), which is perhaps an undercount since there are modules that might be included multiple times thanks to how the WEB system builds its Pascal output and I don't have a Pascal reformatter to make analyzing tex.p manageable.¹

1. The choice to "compress" the Pascal output of tangle is one of the most inexplicable choices made in the development of the TeX ecosystem.