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

91–100 of 142 posts

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

#91

Post by rightbyte »

andi999 wrote: post #73
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. :)

It is a prejudice. Knuth and Torvalds think goto is valuable. See https://pic.plover.com/knuth-GOTO.pdf https://news.ycombinator.com/item?id=8760518 (Somewhere on the internet is a discussion when somebody suggested to remove all gotos in the kernel with structured programming, the answers were entertaining and insightful; I cannot find it right now though)

Knuths paper is interesting.

If it were not for being autorejected in code reviews I would use goto:s alot more.

Even if I want to break out of nested for:s there is always whining about jumps.

In some cases it makes the code more readable as Knuth shows. Dogmatism is a bane of programming.

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

#92

Post by hnlmorg »

pracer wrote: post #81
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…

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

Devils advocate:

GP might work for a company working on a niche application (be it software or hardware) that requires code to be written like the aforementioned and anyone who specialises in that field is already adept in reading and writing code like that.

I'm not going to defend that choice of programming style for everywhere but software development is a broad industry where you do get pockets of people working on code that looks totally alien to others who are used to see C or ALGOL derived languages. Take LISP for example, there is LISP code in half of all European TVs shipped in the 90s. Forth is used in loads of places, even FreeBSD's bootloader is written in Forth. Machine code is almost completely unreadable for humans yet a massive chunk of software in the 80s was written using it.

My point is the industry might have standardised on a subset of syntax styles that seem readable to the lowest common denominator of developers but it's a massive industry with developers using all sorts of exotic languages effectively. Let's not go down the rabbit hole of saying they're doing it wrong because their code looks alien to you before you've understood the field in which that code is running in.

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

#93

Post by zozbot234 »

oaw-bct-ar-bamf wrote: post #90
TeMPOraL wrote: post #71

Earlier quoted context omitted.

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

> Returning a function is nothing else as returning a pointer to a memory location.

That depends. If the language supports proper first-class functions, it's basically an instruction pointer plus a record of the variable bindings the function code is "closed over" (i.e. parameterized on). Many languages do support this nowadays.

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

#94

Post by gonzo41 »

a_imho wrote: post #89
BrissyCoder wrote: post #75

Earlier quoted context omitted.

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

Individuals and interactions over processes and tools?

You mean Jira right

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

#95

Post by otabdeveloper4 »

googamooga wrote: post #62
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.

It's not really "anarchy".

Setting goals and delegating responsibility is how things are supposed to be led.

Substituting that with project management is a pathology.

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

#96

Post by regularfry »

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…

"Structured programming" has a very specific meaning. Or at least, it did in Dijkstra's goto paper. It's not that all uses of goto are terrible, it's that if you restrict goto's uses to specific types of control flow, you can make provable statements about the behaviour of the code, which other uses blow up.

The goto's you've used here are within the set of allowable uses, so can be mapped directly onto structured constructs. There's literally no advantage either way, other than introducing the possibility to the reader that there could be something weird going on in your code.

> Would love to see a faster version in some popular, "structured" scripting language in the same number of characters.

How's this?

    #include 

    void main(){
      for(int a=1; a
Same technique, give or take some unimportant details. Not particularly golfed. 240 characters to your 312. I have no idea if it's faster because I don't know how good the spitbol interpreter is, but I do know that because I've used "structured programming" structures, the compiler (or interpreter, whichever you prefer) can in principle make more safe optimisations to my code than to yours.

If C doesn't meet the "scripting language" constraint (which I find arbitrary, but not insurmountable), I'd throw Julia or FORTH at it and probably shave a considerable number of bytes off.

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

#97

Post by theodorethomas »

nine_k wrote: post #55
dhosek wrote: post #36

Earlier quoted context omitted.

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…

> If you have a `then` clause, you know it will only run when the `if` condition is true.

Can someone please tell the clang compiler folks?

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

#98

Post by maskros »

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.

And gained nothing except more verbose syntax. The goto spaghetti is still spaghetti whether you use "goto" or "switch".

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

#99

Post by andi999 »

pwdisswordfish8 wrote: post #77
andi999 wrote: post #73

Earlier quoted context omitted.

It is a prejudice. Knuth and Torvalds think goto is valuable. See https://pic.plover.com/knuth-GOTO.pdf https://news.ycombinator.com/item?id=8760518 (Somewhere on the internet is a discussion when somebody suggested to remove all gotos in the kernel with structured programming, the answers were entertaining and insightful; I cannot find it right now though)

Have you read Knuth’s article? It is a bit more nuanced than a wholesale defence of GOTO in preference to structured programming. It surveys various control flow structures that are not easily expressed in terms of IF conditions and WHILE loops (what structured programming advocates of the time argued to replace GOTO with), but more easily expressed with GOTO, and it argues that, since we don’t know which of those co…

Yes, I read it and I agree with your text. My point was just that goto is not evil, sometimes it is your best option (like in the parent if loops do not have break).

On a side one could argue that early returns, while often used, are not structured programming and a goto in disguise.

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

#100

Post by Joker_vD »

pwdisswordfish8 wrote: post #77
andi999 wrote: post #73

Earlier quoted context omitted.

It is a prejudice. Knuth and Torvalds think goto is valuable. See https://pic.plover.com/knuth-GOTO.pdf https://news.ycombinator.com/item?id=8760518 (Somewhere on the internet is a discussion when somebody suggested to remove all gotos in the kernel with structured programming, the answers were entertaining and insightful; I cannot find it right now though)

Have you read Knuth’s article? It is a bit more nuanced than a wholesale defence of GOTO in preference to structured programming. It surveys various control flow structures that are not easily expressed in terms of IF conditions and WHILE loops (what structured programming advocates of the time argued to replace GOTO with), but more easily expressed with GOTO, and it argues that, since we don’t know which of those co…

Well, it's slightly more powerful that pattern-matching Result because in case of nested loops you can short-circuit right to the very top loop.

Writing corresponding nested maps/folds is generally quite unsightly. Plus the resulting code may be non-tail-recursive which means that the sentinel EarlyExit value will get checked and re-returned for every function in the call stack on such exit.

This loop construct, however, basically introduces locally scoped continuations that you can directly return to. Of course, it's possible to optimize nested maps/folds down to this form, but it requires very heavy inlining — Haskell does it because it's semantics allow deforestation, but does Rust do it?

Post reply on HN