Regardless of the safety constructs or lack thereof in a programming language/environment, our job as software engineers is to construct programs that perform as per their dataflow requirements. That is the only kind of safety I"m concerned with.
That can be accomplished for most software projects in most programming environments and their languages, to more or less extent within their limitations, given a proper amount of hard graft to choose the proper constructs and then brutally test them.
Power, on the other hand, must be dependent on what is required to wring safety out of the limitations, weaknesses, and pitfalls of the chosen implementation tooling. Power can include speed of development, speed of execution, amount of concurrency, fault tolerance, and so on. Regardless, power must be built upon safe software constructs, safe in the sense that the resulting system performs as intended.
A civil engineer will know that a specific kind of bridge constructed out of certain materials using certain techniques will be able to withstand certain events like an earthquake of a certain magnitude and will be able to perform at a certain level, such as tons of traffic at a time or somesuch. As well, they will have a pretty good idea of how long it will take to build it. Such is the maturity (and relative simplicity!) of bridge building.
We have no such framework in our industry. Focusing on programming languages shows the immaturity of our industry, which is the most difficult we have yet undertaken as a technological civilization. The proof of that statement is that all our technologies depend on software systems.
It doesn’t help that the customer asks us for a bridge for a bicyclist, uses it as a highway for semi trucks, and refuses to perform scheduled maintenance on it while attackers shoot rockets at the foundation.
There are many parts of our discipline that are immature, in addition to the implementation bits.
> For one thing, our specifications, themselves, are sorely lacking in specifications!
you cannot ask a customer of a building to specify what strength concrete needs to be used.
They specify the color of their kitchen, how much sunlight they want, and how many rooms. And as a demanding customer, it makes sense to want to change their minds.
I don't see the lack of specification, nor the lack of adherance to it, a problem. You, as an engineer, is responsible for solving these problems - including telling them they've forgotten to think about XYZ. You're not a human language to code translator.
That would indeed be the way if they would pay for all of that; often it also has to be cheap and fast. It happens with buildings and bridges too, but somewhat less as broken software feels less urgent (as it normally doesn't cause immediate death).
> you cannot ask a customer of a building to specify what strength concrete needs to be used.
Indirectly, you can. They'll specify how many floors there needs to be, and combined with automatically-specified things like gravity and local weather phenomena, you can derive what building materials you can safely use.
If only I could upvote this comment more. The software engineering industry has a loooong way to go, and we'd be much better served if more people actually got it and thought like you instead of wasting time on things like language wars. That's not to say we shouldn't continually strive for better languages, just as we continually strive for better materials to build bridges with, but proselytizing for a language is a complete waste of time when half of the so-called engineers in this so-called engineering discipline do not even realize that engineering is not mere programming. It'd be analogous to the civil engineering discipline spending thousands of hours debating which materials are better before even figuring out how to actually construct a bridge, out of any material consistently and within boundary conditions.
The fact that we call software engineering "engineering" is still a complete joke in the majority of cases (there are exceptions of course) at this point in time.
Well, to a point. It feels like some engineers are proposing to start building bridges out of wood, and others want to keep building them out of spoons and toothpaste, just like their pappy did.
I have a hard time understanding why programmers so much want to be called software engineers. Lawyers don't want to be called contract engineers. Writers don't want to be called text engineers. Film directors don't want to be called movie engineers. The industry has a long way to go for sure, but maybe it's not to become better engineers but to better understand that they aren't engineers after all.
Why do civil engineers want to be called engineers? They don't work with engines.
Computing is full of metaphors. There are also software architects, who don't design buildings, but "software designer" is not the term the industry settled on. Nobody would care if it did, it just didn't.
Some software is engineered but not all of it by a long shot, IMO. I'm not an engineer, I'm a programmer.
Engineering is all about certifications and contracts and laws and codes of conducts. Engineers don't build the bridges themselves, there are many layers of delegations to the guy who actually operates the crane or puts in the rivets.
Most programming done today is craftsmanship not engineering. We have the freedom to implement the same thing in multiple wildly different ways, there are famous "masters" with lots of opinions, on the job programming is still taught in an apprenticeship kind of way, there are consultancies that act effectively like studios or workshops, I type my own code with my own hands, etc. Software is basically still in the artisan era.
I for one much prefer the current state and would probably do something else if software was fully professionalized. I would hate to just design some high level spec out of well-known reusable parts, with massive legal and contractual requirements, to be implemented by massive teams of contractors.
This perspective is pretty pervasive from what I have seen. However, I think the analogy should be taken to its logical conclusion. There are many, many examples of long lived structures built by carpenters and other craftspeople (in England there are residential dwellings dating back 1,000 years). The materials and maintenance have proved themselves and show that it does not take the large legal framework of engineering to design a structure fit for purpose. However, craftspeople and apprentice style training are not acceptable for the design and certification needed for modern skyscrapers, large format factories, bridges, or transportation infrastructure.
I am more than willing to use, support, and even participate in software that is not critical and think a more-bright line separation should exist to delimit the arena for which craft scale software is appropriate. The other side of that is I am willing to acknowledge the existence of arenas not suited to less than formal and legal requirements for the design and ‘construction’ of software artifacts.
Controversially, I think societally we use software in too integrated and too many areas that are better left sequestered and siloed. There really is no reason that a general computing device should be used for both untrusted internet connectivity and storing and accessing banking or medical information. The ubiquity of protected purpose built hardware should have been a goal, with a more general open computing hardware environment used by informed choice.
I'm getting pretty tired of hearing about "safe" rust. And I love Rust. The language's promoters are pushing a vision of a world that's just not true. And while memory bugs are an important class of issues, logic bugs are even larger.
No argument there. Rust is the first language that checks all the boxes for me — memory safe, compiled to machine code, open source, widely used, ergonomic — but if you told me you’ve been doing all that in Haskell, righteous! Rust didn’t invent any of those.
sadly ADA never got the kind of love rust does. people say its hard to write code in but I don't see how its worse than rust. Rust just came at a time where the requirements and stakes for writing high performant and correct software became high enough that prioritizing it into the language design became valued. ADA was a little too early for its time.
I think one of the reasons why someone might think it's hard to write code in Ada is its Pascal-style syntax and verbosity, which might give the false impression that it's an "outdated legacy language". I've written a few hobbyist projects in Ada (SPARK to be specific) during my spare time and now I greatly enjoy the language, but my very first impression of it wasn't enthusiastic (coming from a C background). I don't fully understand why Ada lacks popularity compared to Rust, outside of Rust having a more vibrant community.
Nim (https://nim-lang.org also mentioned elsethread) was largely inspired by trying to make a more concise Ada with Python-like lexical sensibilities/ergonomics and support for first class meta-programming. Compilers for Nim are sadly not as mature as things like say the gnat Ada compiler.
I cut my teeth in the industry on the test side at MS; it was a bit adversarial with the dev side. And there was a third side to get us both on documentation.
It was frustrating but, I think we made Good Stuff (NT4, Win2k).
Yes, this was another boring shill article for Haskell/Rust. The hard part of software engineering is correctly understanding and modeling the domain. Most other issues are trivially resolved by good practices. This only solves issues for codebases that have a train ran on them by interns and junior devs, which is great if you're in that situation, but is unbelievable frustrating for people that don't have that issue
That can be accomplished for most software projects in most programming environments and their languages, to more or less extent within their limitations, given a proper amount of hard graft to choose the proper constructs and then brutally test them.
Power, on the other hand, must be dependent on what is required to wring safety out of the limitations, weaknesses, and pitfalls of the chosen implementation tooling. Power can include speed of development, speed of execution, amount of concurrency, fault tolerance, and so on. Regardless, power must be built upon safe software constructs, safe in the sense that the resulting system performs as intended.
A civil engineer will know that a specific kind of bridge constructed out of certain materials using certain techniques will be able to withstand certain events like an earthquake of a certain magnitude and will be able to perform at a certain level, such as tons of traffic at a time or somesuch. As well, they will have a pretty good idea of how long it will take to build it. Such is the maturity (and relative simplicity!) of bridge building.
We have no such framework in our industry. Focusing on programming languages shows the immaturity of our industry, which is the most difficult we have yet undertaken as a technological civilization. The proof of that statement is that all our technologies depend on software systems.