111–120 of 142 posts
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…
Earlier quoted context omitted.
"structured programming" is not the use of flow-control but a way to design programs. Even if most language have structured flow-control, a lot of people NOT do structured programming. This is how I remember it back in the day and how I do it (curiously, much better on Rust, where it match better how was done on Pascal! ie: Not OOP, big on structs, functions, enums) and is a mix of: - Define the major components of t…
But then you (and the author?) talk about different things than the Wikipedia entry that the author linked to, because that entry (and what I remember about structured programming--but I was very young, so might have missed a lot) specifically talks about "making extensive use of the structured control flow constructs [...], block structures, and subroutines", also mentioning Dijkstra's "Go To Statement Considered Ha…
Also, a lot of good practiques was from books or conferences (mostly sponsored by MS).
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.
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.
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.
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.
A better example might be Clojure, which has mutable variables (opt-in, like OCaml), but no traditional imperative loops - only recursion. However, even then, the syntax for its tail-recursive construct uses "loop" as a keyword.
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…
Loops are sometimes more restricted, but even then, neither C nor Pascal prohibit it (Algol-60 did, curiously), and many languages derived from them that retained goto do the same. Off the top of my head, the only mainstream language I can think of that specifically prohibits goto into inner blocks is C#.
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…
Earlier quoted context omitted.
> 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 subj…
Earlier quoted context omitted.
"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 o…
Sometimes I wonder if the only people who browse this site are JavaScript monkeys and Rust fanboys. There’s a whole spectrum of languages out there that looks nothing like C.
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.
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. Some require low level hardware access, some need mathematical compatibility, others might be optimised for text parsing, and sometimes you just care about developer throughput. There’s macro scripting, web development, games development, server side software, OS development, and firmware. And entire industries using their own specialist tools that most people don’t even know about unless you happen to already work in it.
Some languages are designed to be bullet proof and used in aviation or other domains where failure isn’t an option, some are the electronic equivalent of duct tape designed to allow people to quickly stick operations together.
Programming is such a massive industry that you need different languages for different problems.