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

51–60 of 142 posts

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

#51

Post by darek »

jay_kyburz wrote: post #48
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. :)

If I remember correctly there is a break keyword, but continue is missing. At least in Lua 5.1 which is still the most popular one.

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

#52

Post by bitexploder »

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 get it. I’ve done enough systems program and reversed many more embedded systems, bug hunting for customers. There are still a lot of bad practices in the embedded world. It often exists outside of normal best practices. Many choices embedded devs make are just plain bad. Using outdated libraries and binaries from a decade or more ago, etc. it doesn’t have to be so bad. I haven’t found many embedded systems that weren’t really bad from a security perspective.

The way these systems get developed is a huge part of the problem. One team building hardware, another building the software no one communicating. Everyone hoping for the best. Frantic cleanup in software to make it all work on top of hardware thet can no longer change. I am sympathetic to the embedded developers position, but they still seem to exist in a different universe from modern software dev.

As a security practitioner I don’t blame the devs. I like to ask questions about how things got to be this way. How we can make it better. But make no mistake. A decade will pass and some embedded developer will still be linking some ancient binary or throwing together a bunch of sketchy CGI files that let an attacker scribble everywhere in memory. Embedded is like, the final frontier of software security :)

That’s my lens anyway :)

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

#53

Post by kqr »

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,

- Communication with customers,

- Evolving prototypes,

- Avoiding the planning fallacy,

- Estimation,

- Support and understanding from upper management,

- and much, much more.

These are problems we struggle with today, but it's also the problems identified by and worked on by the experts of the late '60s into the mid '70s. We can learn a lot from what they discovered. (I sure have -- and I keep learning more!)

In fact, if I'm being a bit uncharitable, only three things truly seem to have changed since the late '60s:

- We have faster computers.

- We have virtual computers.

- We have higher level languages.

- We have version control.

Other than those four things, all advances in how to build software I've seen the last few decades are, in some sense, a rehash of what they found out early on.

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

#54

Post by jay_kyburz »

darek wrote: post #51
jay_kyburz wrote: post #48

Earlier quoted context omitted.

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

If I remember correctly there is a break keyword, but continue is missing. At least in Lua 5.1 which is still the most popular one.

You're right, apologies. I'm on LUA JIT.

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

#55

Post by nine_k »

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.

Often functional tests provide more bang for the buck than unit tests. Concentrating on functional tests allows to move faster.

This is because most modern languages allow you to write in structural style which is impossible to get wrong without noticing. If you have a loop, you know it repeats for its condition, and does not otherwise. If you have a `then` clause, you know it will only run when the `if` condition is true. If you have a function, you know it's only computed when called.

Compare it to pre-structural languages like Fortran IV or Basic, where you can freely jump into the middle of the loop, inside of what constitutes an undelimited `then` clause, or even into the middle of a function, without "calling" it properly.

This allows for potentially very clever code that saves every last byte and cycle. It also allows for totally mind-boggling, insidious bugs in code we'd now consider plain and foolproof to write.

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

#56

Post by wtallis »

1vuio0pswjnm7 wrote: post #35
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 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…

> 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 clearly deliberately designed to have an excess of visual noise. But I suspect you're not actually trying to make that code look as clean as the language allows.

The semicolons serve no apparent purpose. Having labels like x01 and x01a with no functional relationship between those lines is outright hostile to the reader. Using x as the prefix for almost all of your label names and as one of your variables is mildly confusing, especially when most of those lines don't relate to the variable x and don't appear to need labels at all. "output" seems to be a magic variable for which assignment has side effects, but nothing in the syntax differentiates it from any other variable. Grouping all the conditionals together, then grouping all their consequences together forces the reader to jump back and forth between lines more than if you put the consequence of each conditional immediately after the corresponding test (in this instance, your way does have the advantage of making the conditional fall-through pattern more readily apparent, but on the other hand that wouldn't be as necessary if you could use more than one line of code to write a single line of output).

You can claim all you want that aesthetics is subjective, but at the very least you must recognize that visual noise you've trained yourself to ignore is objectively different from code which doesn't have those distractions in the first place.

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

#57

Post by Galanwe »

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.

Would that really happen though? I don't think I would actually release recursive code.

I find recursion to be very simple and elegant for prototyping algos, but I would instinctively rewrite it with an iterative/queue form as soon as the "toy" stage is over.

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

#58

Post by dgb23 »

jay_kyburz wrote: post #48
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. :)

Return works within loops right?

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

#59

Post by 1vuio0pswjnm7 »

wtallis wrote: post #56
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…

> 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 employed to write programs for other users or to be read by programmers. Every user is different.

You probably could not write a program I would use. I would find "deficiencies" and reject it for something else.

If programming is objective then why are there thousands of different languages, and the number is constantly increasing. All of them are basically doing the same things.

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

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

#60

Post by shakna »

jay_kyburz wrote: post #54
darek wrote: post #51

Earlier quoted context omitted.

If I remember correctly there is a break keyword, but continue is missing. At least in Lua 5.1 which is still the most popular one.

You're right, apologies. I'm on LUA JIT.

Luajit should have the break statement (Compatibility is Lua 5.1 with some backports from 5.2, and a couple extensions).
Post reply on HN