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

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

#121

Post by m_mueller » Mon, Aug 16, 2021, 7:00 PM UTC

maskros wrote: post #98

m_mueller wrote: post #74

Earlier quoted context omitted.

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

Disagree. You eliminate backward gotos except for the while loop, which is much more clearly communicating the way to extend the code (by adding more states or state transitions) to the next person taking over. I‘m not categorically against goto in certain contexts (like C based systems programming), but IMO backwards jumps with goto need to be eliminated.

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

#122

Post by flir » Mon, Aug 16, 2021, 7:43 PM UTC

lmm wrote: post #69

flir wrote: post #32

Earlier quoted context omitted.

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. Loose coupling and pipes. I don't think that follows at all. Unix shell programming is very much a bottom-up philosophy where you write a bunch of generic tools and then string them together to solve your actual problem at the last minute.

But the individual tool itself? It takes a bunch of inputs, does some processing on them, and spits out a bunch of outputs. That doesn't feel like a good fit for procedural to you?

I guess what I'm saying is that the complete input state of the program is known the moment you hit enter.

As opposed to a GUI where a user could flip a switch at any point during the program's lifetime and mess with its internal state, which feels like it maps better to OOP.

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

#123

Post by 1vuio0pswjnm7 » Mon, Aug 16, 2021, 9:04 PM UTC

regularfry wrote: post #96

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…

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

"How's this?"

Unoptimised, it's already roughly 3x faster than the spitbol script.

Moving the "int" specifier out of the for loop allows this to compile under -std=C89. How does one suppress the warning about the non-int return value for main().

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

#124

Post by [deleted] » Mon, Aug 16, 2021, 9:09 PM UTC

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.

[deleted]

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

#125

Post by 1vuio0pswjnm7 » Mon, Aug 16, 2021, 9:18 PM UTC

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.

Check your assumptions. What if someone is not working as a programmer, not working in academia and not sharing programs with others, except in HN comments/submissions.

There was a story that appeared on HN many years ago and I wish I could find it again. It described a gentleman in Japan who did not work in the computer industry but did some sort of (let's call it) "optimisation work" on his own as a hobby. The story told that the work was being used by companies within the computer industry, I think it was hardware manufacturers. If I recall correctly he did not have any formalised education in computer science or mathematics. I am probably getting some details wrong; need to find this story again.

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

#126

Post by oblio » Mon, Aug 16, 2021, 9:23 PM UTC

laumars wrote: post #120

oblio wrote: post #101

Earlier quoted context omitted.

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

You’re way off the mark! 1. Might happen occasionally but rarely would anyone adopt a vanity language 2. Nope 3. Lol this is just a rehash of 1. 4. Languages can’t be licensed, compilers can. And that’s why we often have multiple different compilers. 5. Now you’re getting close. The actual reason is: Trying to solve a different problem Believe it or not, problems can vary massively from one field of IT to another. So…

Ever heard of C#, J#, Typescript, Kotlin, Go?

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

#127

Post by regularfry » Mon, Aug 16, 2021, 9:47 PM UTC

1vuio0pswjnm7 wrote: post #123

regularfry wrote: post #96

Earlier quoted context omitted.

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

"How's this?" Unoptimised, it's already roughly 3x faster than the spitbol script. Moving the "int" specifier out of the for loop allows this to compile under -std=C89. How does one suppress the warning about the non-int return value for main().

The easiest way is to `return 0;`. We've got the character budget for it.

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

#128

Post by lostcolony » Mon, Aug 16, 2021, 10:37 PM UTC

masklinn wrote: post #85

lostcolony wrote: post #34

Earlier quoted context omitted.

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.

I said immutable -> !loops (p implies not q).

You're saying !immutable -/> loops (not p does not imply q)

It's a fair thing to mention, but you're not gainsaying anything I said; I never said anything about mutable languages that don't have loops. In fact, to the topic at hand, you would assume that to be the case, given that structured programming was intended to force loops on languages at the time (mostly mutable) that weren't using them (but instead were using gotos and the like)

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

#129

Post by Galanwe » Tue, Aug 17, 2021, 12:26 AM UTC

int_19h wrote: post #114

Galanwe wrote: post #57

Earlier quoted context omitted.

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.

But why would you do that, if it's simple and elegant? Really the only answer is that it has potentially unbounded stack consumption - but tail recursion solves exactly that problem.

Not all recursive algorithms are tail recursive; not all tail recursive algorithms can be correctly identified & tail optimized.

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

#130

Post by 1vuio0pswjnm7 » Tue, Aug 17, 2021, 1:45 AM UTC

masklinn wrote: post #83

thaumasiotes wrote: post #40

Earlier quoted context omitted.

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.

There is also an "indirect goto" where B is a variable to be appended to string A to compute a label that is defined somewhere else in the program.

   :($('A' B))