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

81–90 of 142 posts

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

#81

Post by pracer »

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…

"I am not employed to write programs for other users or to be read by programmers. Every user is different."

Well, unless you are the only programmer that company will ever has, you should write code that others can read and understand. Or if you are working in academia, then you can write as you like, but as a professional, you should write readable code for those coming after you.

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

#83

Post by masklinn »

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) ?

> What's the difference between :(label) / :s(label) / :f(label) / :s(label1)f(label2) ?

Looks like it’s unconditional, conditional (success), and conditional (failure) jumps.

:s(A)f(B) is how you tell it to jump to A on success and B on failure.

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

#84

Post by masklinn »

ufo wrote: post #30
lisper wrote: post #29

Earlier quoted context omitted.

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 C standard doesn't mandate tail-call optimization, but at least GCC and Clang are pretty good at doing it (-foptimize-sibling-calls, which is turned on with -O2)

That it is only an optimisation ensures it will eventually fail to trigger at the least convenient possible moment.

Unless your C implementation has TCE, don’t assume recursion is optimised.

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

#85

Post by masklinn »

lostcolony wrote: post #34
swiley wrote: post #33

Earlier quoted context omitted.

Well puppet doesn't have loops. I hope that's not because the "fad" is ending.

There are plenty of further restrictions (such as immutable languages that don't have loops, because loops require mutation, and so instead rely on recursion), or which eschew being concerned about control flow at all (such as puppet, SQL, Prolog, etc; any declarative language). Certainly, those languages aren't "undoing" structured programming.

> such as immutable languages that don't have loops, because loops require mutation, and so instead rely on recursion

These two are not as intertwined as you make them. OCaml has mutation but not iteration.

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

#86

Post by b0afc375b5 »

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…

> 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

I see off-by-one errors hasn't changed since the '60s.

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

#87

Post by masklinn »

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.

It’s the exact opposite. Unix was if not a reaction at least and antithesis: top-down programming is BDUF, you first decide what the entire thing does, then you go down a level and define / implement what’s supposed to be there.

Unix is about starting from small utilities at the bottom and jury-rigging them until you get something you like.

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

#88

Post by hnlmorg »

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…

> 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 looking at it).

One of the hardest things it seems for a developer to do is accept that their personal opinions are subjective since they spend so much of their career being told there's a correct way of doing things. Your post here is a classic example of that. Arguments about strongly typed and loosely typed languages are another. Debates about functional, stack backed, object orientated, procedural, etc etc... it's all just people like yourself trying to convince others that your subjective view is empirical scientific fact. But it's not, it's just opinions. Some opinions just happen to be more popular.

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

#89

Post by a_imho »

BrissyCoder wrote: post #75
googamooga wrote: post #62

Earlier quoted context omitted.

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

Third this. Process doesn't really matter. Just hire good programmers and let them program.

Individuals and interactions over processes and tools?

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

#90

Post by oaw-bct-ar-bamf »

TeMPOraL wrote: post #71
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.…

> One particularly confusing technique was to goto a computed expression. Leads to all sorts of interesting bugs. Huh. I suppose the modern-day equivalent is commonly done with higher-order functions - in particular, callbacks, CPS and returning functions. I've worked with people who find this confusing (particularly the last one - functions returning functions).

I believe that this confusion comes from the avoidance of low level details. A function is just a location in memory where instructions are stored. Returning a function is nothing else as returning a pointer to a memory location.

In languages like Java that want to hide everything memory related I also was struggling with grasping what a function really is. Is it even allowed to return a function?

Languages that hide memory locations and direct memory access are one of the reasons that some programmers are struggling with functions returning functions.

Post reply on HN