Yeah, I’ve long maintained that there are some situations where GOTO is just the right tool for the job… but I’ve come to realize just how rare those situations are.
Let me be clearer. My perspective comes from having been an architect of many large-scale software systems. From that perspective, rules on “how to code good” and the language changes that they produced are of only the most minimal benefit. There’s nothing revolutionary about block-level conditionals compared to the simple conditional GOTOs of FORTRAN IV. Better? Sure. Able to turn a shitty programmer into a good one? Nope! Able to help a software designer build better systems? Absolutely nope!
As a project manager I’ll always take a bright programmer over one well-versed in “structured programming”. This is why CMM came to mind earlier. It’s the same kind of myth about how to cure incompetence. It doesn’t.
“Pythonic” really only refers to the adage that Python should look like Python and not some other language. It’s true that this is an opinion, but it’s not in the same league as other languages that literally think they’ve found the One True Language, and all their approaches are the One True Approach.
For example look at the Ruby community. They’re awful about this, and always have been, and that’s the reason it was something of a shooting star whose only real legacy is Rails (which is wobbling in popularity). It’s a damn shame too. Ruby is a fine language, IMO it could’ve and should’ve outshone Python, but the community is so rife with hubris and groupthink that it’s no longer capable of any real growth. Meanwhile Python is eating its lunch in every important category.
It was revolutionary back in 1968.
Again, you’ve got a bizarre perspective on this. No one is “well-versed in structured programming.” It’s just literally how every language is today, so not knowing structured programming means you’ve been stuck in a time warp for 50 years, or that you have no programming ability of any kind.
That may well be. I can only compare to languages like C++ and Perl, which are distinctly un-opinionated, to the point of making it a virtue. I don’t have any exposure to the Ruby community, so I can’t compare.
I was about to say the same thing. We don’t even talk about “structured programming” anymore because all the useful paradigms imply some sort of structure. It’s like talking about “electronic computers”. You don’t have to say they’re electronic, it’s been implied for quite some time now.
Personally I have not seen a GOTO used anywhere, like even as a joke, in the past 30 years. We no longer talk about whether structured programming is better, we talk about which kind of structured programming is better, and we’re normally arguing about OO vs. functional.
Excellent analogy.
Newer languages make them less useful. For instance, initialization functions are often of the form “try A, on failure goto cleanup; try B, on failure goto cleanup; etc.”. try/except blocks fit this purpose well. But C doesn’t have exceptions and so goto often makes an appearance. The alternative is usually massively nested if blocks, which can get unpleasant. On some environments, they aren’t available under C++ either.
Well, looking back, I think my experience with programming computers goes back about 57 years, professionally about five years less than that, and then gradually moving into larger scale software engineering and system architecture and eventually enterprise consulting in the area of system integration. So forgive me if I object to your characterization of “no programming ability of any kind”.
That wasn’t my point, which was badly stated. My central point as someone who has being doing this for most of his career is that how a particular system module is coded is far less important than how those modules are defined and organized into an operational system, which is absolutely critical to reliability and maintainability. To restate it a different way, as a project manager I’d much rather have a programmer who understands important principles of software design than one who can write good or elegant code. Coding is arguably one of the least important skills in practical software engineering.
Ok. Your programming ability, such as it is, appears to be about 57 years out of date.
And yet many of the most famous software engineers are also fantastic coders. Linus Torvalds. John Carmack. Michael Abrash. Etc.
Quake, Doom, and others could not exist without amazing programming at every level, because they wouldn’t otherwise be performant enough.
Every major software project, even if it could be implemented by shitty coders, at least rests on a massive codebase which was implemented by competent people. The reams and reams of appalling Javascript out there could only exist because of the fantastic work on just-in-time compilers translating it into highly optimized machine code on the fly.
And of course it’s not just about performance. The Linux kernel and the Quake source are also highly readable. It turns out that the ability to reason about difficult problems and the ability to translate those ideas into clear, efficient code are well correlated.
I’m sure that’s true. I remember back in my college days there were all kinds of examples being discussed about fancy super-efficient tricky code snippets that would execute in half the time of “ordinary” straightforward code. On the PDP-10, one technique used by clever coders for small tight loops that had many interations was to put the code in the registers, which were much faster than main memory. Lots of fun, sure, but little relationship to software engineering.
No, that’s around the time of the first program I ever wrote, as a kid. To generate “computer poetry” on an IBM 7040. The first program I ever wrote, not the last. Sure some of my knowledge is out of date. I’ve been retired for some time now. But the ridiculous accusation you made really irks me.
Incidentally, although my direct involvement in programming has tapered off over the years, it wasn’t all that long ago that I was involved in designing the system architecture of a project in which I also did some of the more critical programming. The project was to build a failsafe system for monitoring alarms for emergency services, with an availability goal of something like 99.98% (don’t remember exactly, as the specs changed a bit). We were using ordinary off-the shelf computers, so the high availability had to be achieved through multiple redundant computers, with hardware arbitration between them, and a lot of innovative software techniques that I developed and coded. I must say that I was gratified when I later saw very similar ideas implemented in the voting protocol of the “quorum” system on the DEC VAXcluster. Please don’t tell me that I have “no programming ability of any kind”. It really irks me.
Well, I might have slightly exaggerated my point for effect.
Nevertheless, saying that “structured programming” is “not very useful” really isn’t that far off from saying you don’t trust those newfangled “electronic” computers. It’s just a completely bizarre statement. Aside from hand-crafted assembly, all programming is structured (with minor deviations here and there). And even modern assembly code is still semi-structured!
Your implication that the only thing that matters is the highest-level architecture, and that everything below that is almost irrelevant, is also offensive (and untrue). If some enterprise architect tried to dump a programmer in my group that didn’t know what a function call was, they’d be an enemy for life.
It would seem productive to agree that we’re all speaking to our own specific strengths and experience here. In the grand scheme of a distributed enterprise architecture, code structure is not the level of abstraction you need to worry about. In a high-performance piece of consumer software, there’s little and possibly no distributed architecture, you’re talking about modular and/or OO architecture at that point.
But in both cases, code is the glue that holds it all together. It’s important that it be structured in a way where it’s easy to understand the intent of the code, as well as the flow of execution. It’s equally important to get clean encapsulation so that different modules can vary independently so it’s not fragile to change. Good coding style is essential to all this, it’s the most granular dimension of architecture if you think about it.
I wanted a fight. But fine. I’ll just say that at the level of enterprise architecture, the language itself is below the scale of detail you care about. And yet the very topic of this thread is the difference between languages.
That’s a good and valid point. Back in my working days, smart consumer appliances weren’t really a thing. PCs were, and it was clear that Microsoft had lots of smart coders, much like Bill Gates himself, and it was also clear that they had no concept of what software architecture was. So their software was, and mostly remains, shit. The importance of good software design has applicability way beyond just the enterprise space.
That’s just silly hyperbole. Subroutine and function calls have existed since I wrote my first program ~57 years ago, and long before that.
You’re the one that said structured programming is not very useful, not me. Subroutines are one of the components of structured programming. Not every element appeared in every language at the same time, and most preceded the label of structured programming. Nevertheless, they all fall under the same umbrella.
That shirt was definitely created for python geeks.
Each of those has its purpose. I do hardware and software design for industrial control. We don’t allow python anywhere near the actual plant controllers. If the plant operators and engineers want to hack together some python scripts on the operator consoles, I have no problem with that. Python is a great way to quickly put together things like that. But that has no place in the machine that is actually controlling thousands of tons of molten steel or the flow of chemicals that all end in “ene” through pipes (why is it that everything that ends in “ene” is a really nasty chemical?).
Controller code needs to be compact, fast, and deterministic. It’s in C and assembly code for a reason. In an industrial controller, C++ with typical OOP classes/methods/etc. is just asking for memory leaks and indeterminism. If it needs to happen every 10th of a second, it needs to happen EXACTLY every 10th of a second. It’s not uncommon for our machines to run 24/7/365 for years between shutdowns. Any memory leak is fatal. And for things like Java, pausing for half a second to do trash collection and cleanup means you didn’t hit your schedule which just triggered the safety systems and shut down the plant.
On the other hand, if I were writing a game, C++ would probably be my preference (assuming you’re not just using someone else’s game engine and scripting language).
If I were doing typical internet or app type programming, I’d probably want either Java or Python. I don’t do much of that type of programming though, so I can’t say which is best for what.
There is no one best tool. Different tools for different jobs. Different programming styles, too.
What would Pascal be on that shirt? I learned it high school (early 90s) then never saw or heard of it since.
It’s possible to write highly deterministic C++. You have to be careful, and limit yourself to some constructs, but it has some advantages over C in that environment. For instance, a class that is only used with RAII does not have to allocate memory from the heap or even the stack, but can ensure that some events always happen at an entry and exit point. For instance, suppose you need to set a GPIO pin to high while some other bits are twiddled, and then set back low again at function exit. RAII can ensure that always happens, no matter what the control flow.
Not that there’s anything wrong with C, either. But C++ isn’t doing any magical background stuff (unlike Java). Things only happen when you ask for them. It’s possible to totally avoid the complicated stuff.
For Pascal, add fencing sword of some time - a foil, perhaps, or an epee.
Blunted tip, dull edge, useful for learning the craft but not so hot for actually getting the job done.
That’s Standard Pascal, basically. Most dialects, such as e.g. Turbo Pascal made it possible to write programs that people would want to use actively rather that just learn from, so those would have a sharper edge to them.
I seem to recall that structured programming included other rules in addition to just control-flow constructs. For example, rather than than using return statements, a function should only have a single exit point.
For God’s sake, do not look at INTERCAL.