What is software engineering anyway? I've heard this term for almost 40 years, and still wonder what it really means since everyone has a different idea.
... software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot."
[0] https://en.wikipedia.org/wiki/Software_engineering#Controver...
The fact is, nobody can program, not when programming means building complex systems (pretty much anything bigger than 30kLoC) absolutely correctly. Not I, not you, not the late Prof. Dr. Dijkstra — nobody. We can't.
But we need to build these systems nonetheless. So, "how to program if you cannot" becomes an essential area of study.
Yes, it can be abused, but can so nearly every other programming construct. There are places where goto makes sense, such as error handling or breaking out of nested loops. I hate seeing a Boolean flag(s) being tracked for whether or not break out of nested loops. It's more typing and confuses the intent. Just goto the label following the nested loop.
Also, nearly any looping construct can be implented using a conditional goto, and if you go down to assembly, they almost universally are. Jumps are goto's by another name. I've seen exceptions used for control flow. Awful. It's about knowing the appropriate construct for the problem at hand.
I've seen do{...}while(false) used with conditional breaks to avoid use of goto in error handling and it's confusing as you're reading through an unfamiliar codebase to see abuse like that. As I'm reading through the code, I see the 'do' and I expect the code to loop, only to continue reading and find out it doesn't loop. Frustrating.
Dijkstra certainly wasn't arguing you should use trick like do{...}while(false) to avoid using the GOTO keyword.
The basic details of the system are described in a book called "System design from provably correct constructs: the beginnings of true software engineering" by James Martin (he mentions Hamilton in the references.)
In modern terms you work directly with an AST and the UI only permits modifications by operations that preserve the correctness of the AST. It eliminates all sources of bugs, and it was simple enough to teach normal people to use it with just some coaching.
Anyhow, that's "software engineering". The rest of us are just pushing text around in buffers and hoping it isn't broken. There are a few people using math to make software, and it works out really well (E.g. https://www.categoricaldata.net/), but mostly "software engineering" as it is usually used is an oxymoron.
Static analysis and safe refactoring tools are great, but they are certainly not going to protect you from implementing the wrong thing because you misunderstood the requirements or the environment; that's not possible even in principle. At best you can check for consistency (for example, consistency between a specification and its implementation).
With the caveat up front that I know nothing about this beyond what you have written: wouldn't this just catch compilation bugs? The compiler tells me if the blob of text I gave it is incorrect in terms of any syntax errors. Business logic bugs and accounting for bogus data seem more important to me.
You could still use it to write correct programs that did the wrong thing. In other words, it couldn't catch bugs that occur "between the keyboard and the chair".
FWIW the tech has a bit of a Wikipedia page now: https://en.wikipedia.org/wiki/Universal_Systems_Language but it doesn't seem very informative to me. YMMV
> It eliminates all sources of bugs,
My problem is I've been trying to get traction on this for years and no one is interested. (Although type-checking is finally getting some love. It's not all doom and gloom out there.)
Most bugs could be prevented or eliminated automatically.† If we're not doing that then in what sense are we entitled to call ourselves "engineers"? (Just to bring it back around to the topic.) I mean, our bridges collapse all the time. This is not science?
†See Alice Pascal https://www.templetons.com/brad/alice.html
> In a syntax directed editor, you edit a program, not a piece of text. The editor works directly on the program as a tree -- matching the syntax trees by which the language is structured. The units you work with are not lines and chracters (sic) but terms, expressions, statements and blocks.
This is still just syntactic correctness, you can only enter syntactically-correct Pascal programs, no typos either, but I don't think it did type-checking or anything like that. But it illustrates my point that if you're typing text into an editor and hoping it correctly describes a computer program, you're doing it wrong.
Equating the most trivial kind of errors (which are caught by the compiler anyway) with "all sources of bugs" ignores the kind of bugs which are actually hard to prevent and might slip into production. But these are the kind of bugs developers are actually concerned about. Preventing editors from saving a file with a typo in it is a solution to a non-problem.
If you want to interest people in these ideas, you should show how it can solve real problems.
Consider:
1 + "two"
>>> 1 + "two"
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'
>> 1 + "two"
"1two"
(But that also worked with Lisp+Emacs!
> programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.
> The overwhelming impression is that the authors have had more experience than education.
Yes, Hamilton worked on the software which literally put a man on the moon. But apparently this is worthless to Dijkstra since they doesn't use the correct academic jargon.
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...
- - - -
You found Dijkstra's review. I'm a fan of his but the guy was hugely arrogant. IMO he craps on them pretty harshly.
I can kind of see where he's coming from, but "he doesn't get it" IMO. He misses the point (or maybe HOS sucked compared to what was later described in Martin's book...)
- - - -
FWIW, James Martin went on to write "System Design from Provably Correct Constructs: The Beginnings of True Software Engineering" which is where I learned about all this. I don't actually know much about HOS specifically, only what's in that book. If you're interested that's the thing to read.
- - - -
> So how does this prevent any bugs which aren't already prevented by the language?
The UI would not let the user enter syntactically nor semantically incorrect "trees".
In modern terms, if you had a syntax-oriented editor (like Alice Pascal) for a language with good type-checking I think you would have most of what HOS et. al. was or did. At the time of Apollo 11 (circa 1969), type-checking was barely a thing:
> In 1969 J. Roger Hindley extended this work and proved that their algorithm always inferred the most general type.
https://en.wikipedia.org/wiki/Type_inference#Hindley%E2%80%9...
- - - -
> Equating the most trivial kind of errors (which are caught by the compiler anyway) with "all sources of bugs" ignores the kind of bugs which are actually hard to prevent and might slip into production.
Yes, I know, sorry. I admitted that "all sources of bugs" was hyperbole. I was going for rhetorical effect.
> caught by the compiler anyway
First, why wait? If the errors cannot be committed in the first place surely that's better than detecting them only at compile-time?
Second, compilers didn't catch those errors back in the day. The whole reason Dr. Hamilton made up this stuff was because existing methods, tools, and technology would have crashed her spaceship.
> ignores the kind of bugs which are actually hard to prevent and might slip into production
Every moment saved by the machine is a moment the humans can use to prevent or detect the errors the machine can't detect automatically.
Here we are back to Dijksra. You know he only got a physical computer when his colleagues forced him to get a Mac so they could email him, eh?
He held, and I agree, that the kind of errors you're talking about do not happen while typing in the software. They occur "between the keyboard and the chair". If I may wiggle a little, I think of "bugs" as glitches in the machine, while the kind of errors you're talking about I think of as just "errors". But I know that's idiosyncratic, and that most people lump them together as just "bugs".
The only thing you can do about them is think clearly.
- - - -
The original question of this subthread was, "What is software engineering, anyway?"
My answer is, "What Margaret Hamilton did."
My point is that we have had tools that systematically eliminate sources of error. All automatically preventable bugs should be prevented (modulus economic consideration, but here costs would be trivial for automation of error prevention and the benefits and cost saving would be pretty high.)
Otherwise, calling ourselves "engineers" is pretty lame. IMO.
- - - -
> If you want to interest people in these ideas, you should show how it can solve real problems.
Real problems, eh? :-) Sending a spaceship to the moon? And getting it back? And no one died?
https://en.wikipedia.org/wiki/Apollo_Guidance_Computer#PGNCS...
To be fair, I don't know to what degree J. Halcombe Laning's software was influenced by Hamilton. She's pictured next to the "software" section of the Apollo Guidance Computer Wikipedia article, but not mentioned.
> The design principles developed for the AGC by MIT Instrumentation Laboratory, directed in late 1960s by Charles Draper, became foundational to software engineering—particularly for the design of more reliable systems that relied on asynchronous software, priority scheduling, testing, and human-in-the-loop decision capability.[14] When the design requirements for the AGC were defined, necessary software and programming techniques did not exist so it had to be designed from scratch.
https://en.wikipedia.org/wiki/Apollo_Guidance_Computer#Softw...
- - - -
FWIW I suspect that these folks are going to be the coming cutting edge (of true software engineering): https://www.categoricaldata.net/ ... fallout from Applied Category Theory http://www.appliedcategorytheory.org/
So I guess this part of the vision have come to fruition. It is a solved problem. Great!
I just fundamentally disagree with your terminology. Calling syntax errors "bugs", and redefining actual bugs to "errors" does not help anybody. The bottom line is that the major challenges facing software development is not a prevalence of syntax errors.
Complexity in software proliferates faster than in any other discipline precisely because it is so easy to create and change. The difficulty is not in writing or editing a line of code, but in understanding how that line of code interacts with all the other code in the program. The essence of software engineering is building large systems in such a way that they are as easy to understand as possible.
I think after the 80s, engineering lost its meaning in computers because people could abstract the machine away and hodge-podge a lot of systems.
No need to carefully encode data, precompile addresses, state etc which would be similar to the dimensioning computations in physical systems.
ps: to extend the story, most engineered things have very carefully defined dimensions and limits which drives most things in the design. Max Wattage in your PSU will reflect in the gauge of wires, size of capacitors etc. A bit like choosing an arch when compiling.
I remember some threads in 2000s boards where some guys did talk about jobs like these in computing. They had said space and said cycles to work with, with that they could see what algorithm could compute the needs back against the limits. I found it especially interesting brain wise because you could "think" in hard figures, instead of glueing things without any idea what was really going on.
In the US, where engineer isn't as controlled a term as elsewhere, we use the term engineer for all kinds of roles. In, say, Canada, engineer means a professional engineer in one of the legally protected categories. You can't use engineer as a job title outside of those.
So if you're trying to talk about software engineering, imagine something horrible has happened with a system you were involved in designing (say, Therac-25). What what you need to know and do to be able to say that this failure should legally qualify as an "act of god"?
The controversy is due to human biases and stupidities.
–Russ Cox, GopherCon Singapore 2018
Designing/creating software.
This included classes such as: Calculus, Linear Algebra, Physics, Chemistry etc.
There were two required CS courses (one in the first semester of first year and one in the second) The first semester course was "Intro to programming and algorithms" which began by assuming no one had any prior programming experience and started with the very basics "This is a variable", "This is a function" "This is a conditional statement", "This is a loop" that sort of thing. Eventually it covered algorithms like quicksort, bubblesort etc and really helped get you into the mindset of "This is how you use programming to solve a problem" For example I remember writing code to solve simultaneous equations (i.e Linear Programming), finding line of best fit through a series of discrete points things like that.
In the second semester the required class was "Intro to software engineering" I remember the course covering things like Object oriented programming - classes/inheritance public/private members and all that stuff, this was a component on unit testing. There was also an essay component to the course I can remember having to write an essay about the Ariane 5 explosion. I really didn't enjoy this course and the impression I got was not a lot of my friends did either.
I can understand the intent of making us sit through the course but in some ways I think it did more harm then good pretty much everyone came out of that class at the end loathing "object oriented" programming. At the time it was kind of a struggle to see the relevance behind the topics covered and even now with 15 years of engineering experience working in manufacturing what we learnt in that classroom is very divorced from what goes on in the real world. When I write code I am, typically speaking, not writing complex software that has multiple reusable components that talk to each other most of the code I write is trying to solve some type of problem. When I write code I'm usually thinking in terms of mathematics and problem solving rather than classes + objects and unit tests, my code tends to be a lot more in the style that was taught in the algorithms course rather than in the software engineering course I suspect quite a lot of "research code" would be similar.
The project was to define a course scheduling system. Had to be able to define which rooms had which equipment, capacity, etc. Then professors would be able to enter their needs of time and equipment, then we'd have to allocate the classes accordingly.
It was written by one or two people, for one or two people to use, once or twice.
Professional engineers in disciplines have to sign their name to their designs in fields such as electrical, mechanical, structural and civil engineering, and can be held personally liable, monetarily, losing their license, and perhaps at the extreme end, criminally liable.
Software "engineers" are not.
Licensed Professional Engineers are also bound by a code of ethics by the appropriate industrial organization. e.g. for electrical engineers, you're bound by the IEEE code of ethics, even if you dont practice in the field.
I'm a licensed electrical engineering intern (I've been a licensed EE intern for 16 years now), but work entirely with software; I've never worked as an EE, nor have I met the professional requirements to take the PE exam. I'm still professionally bound by the IEEE code of ethics. I have objected to certain "projects" over the years because of potential violations. I almost quit one job because I was being pressured to violate the code, but my boss was fired and the pressure disappeared.
Such a licensing and accountability doesn't exist in software "engineering".
That said, I do refer to myself as an engineer and not a developer, because, well, I am an engineer. I follow different practices than web developers because I work in finance and theres billions of dollars on the line if I fuck up. I also work at a firm that requires disclosure of any professional licenses and an attestation that you are in good standing with the governing body (which I am). Professional Engineer (Intern) its not on the list of options, so I always have to type it in, they're mostly looking for CPA types.
Physicians practiced medicine long before there were formal licenses (and long after for that matter...see 3rd world discount medical/dental).
> Such a licensing and accountability doesn't exist in software "engineering".
That's not 100% true. There's Cisco certification, PCI certification. There's no HIPAA certification, but violations can and do cost millions.
Nor is it true that other engineering disciplines always require certifications. You can be a happily employed mechanical engineer without sitting for the PE exam.
I digress...the whole thing is a red herring. The definition of a discipline exists independent of the whatever accreditation procedures happen to exist.