[emmericp]

Most "new tech" is engineering, not science.

If you want empiricism try academic papers instead of mailing lists ;) Some numbers: most critical bugs in the Linux kernel are due to memory safety: 40 out of 65 bugs allowing for code execution found in Linux in 2017 could have been prevented by using a memory-safe language [0]. The paper is about Go, but the same logic applies for Rust. Fun fact: 39 out of these 40 bugs were in drivers [1], so I think starting with drivers in Rust is a good idea.

[0] https://www.usenix.org/conference/osdi18/presentation/cutler (really good read!)

[1] https://arxiv.org/pdf/1909.06344.pdf (disclaimer: I'm a co-author of that paper)

[juped]

Do you think engineering is somehow less empirical and more abstract than science?

[phendrenad2]

Ridiculous. Have you met engineers from other disciplines? They employ empiricism constantly. You can't build the golden gate bridge without proving that the steel you want to use can take the strain. "Obviously steel C is better than steel Y" won't cut it.

If anything, software development is sandcastle-building. We all have ideas on how to build it, but at the end of the day we're just amateurs fucking around with plastic shovels.

[kaba0]

Arguably, other disciplines doesn’t have to handle undecidable problems everywhere. Building a bridge can basically be “statically analyzed” completely, in that every requirement is known beforehand and there is a very constrained mutable state there. On the other hand, even the most basic program one can write will have properties not decidable without actually running the program. I would like to see much more rigorous testing/quality control in user-facing apps as well like websites, but lower level tools usually are written with much higher quality. You would be hard pressed to routinely find a bug in eg. the JVM — and writing formally verified programs is infeasible for any significant complexity.

[littlestymaar]

> Building a bridge can basically be “statically analyzed” completely

This. And even then, after the calculations are done the engineer add a “safety margin” (and it's not 10%, more like 500 or 1000%).

[kaba0]

Good point. And also, it is possible to add safety margins to other areas of engineering. One may be able to eg. store an array with padded nulls (actually we sort of do it at an OS level, just not with null but some “magic number”), but if it’s a loop/recursion, non-correct software will blow up either way - here it is more close to mathematics than science or engineering in my opinion.

[ncmncm]

We expect software to work, in places that are engineered. A SpaceX Falcon launch control system that encounters anything undecidable, whether in launch preparation or in flight, has utterly failed.

It was Microsoft that got people used to software failing on a routine basis, and "have you rebooted?". Before, anything that ever crashed, you sent back for a refund, or expected a tech to come out and fix it post-haste. Clearly MS could not make money that way, but getting people with no experience to believe failure was normal was quite cheap to arrange.

[samus]

You are comparing apples and oranges here. Bridge building should be compared to aerospace software engineering, not to the average CRUD app.

Apart from that, I think you are giving too much credit to construction engineering outside of the highly regulated sectors. They mess up just as often, and expensively so. But stakeholders in construction are slighly more aware that their requirements are going to be set in stone, pun fully intended.

What really makes a difference is the malleability of software. This is an invitation for feature creep and last-minute changes. Also, the impact of overengineered, unmaintainable software is not quite in-ya-face as for physical assets. Therefore, in software engineerin project managers need to be religious about these matters. And software engineers must get better at communicating about these concerns.

[sk1459]

Calling programming engineering in the absence of licensure or any standard of performance for the entire industry is kind of silly.

[danhor]

This is a popular argument, but I'd argue isn't really true. Looking at electrical engineering, there is no standard license and no standard of performance. Like programming, it's just too broad across different areas with vastly different requirements. The equivalent of very sloppy web development might be a blinky (non-kids) toy, that fails after a few uses with no particular requirements (other than "make it as cheap as possible"). Or look at how often smartphones and laptops fail electrically (or compound failures) for really obvious reasons, that just weren't important enough to fix.

To address the particular point being made here, lots of things in EE are experience driven, for example which decoupling capacitors to use or to not use 90 degree angels on pcbs. I think many aspects of typical engineering are way more driven by experience and vague rules of thumb than we expect looking in from the outside.

The reason why this is more obvious in software development may be because it's pretty hard to have good measurements and understanding failures is pretty hard and working around them is pretty easy.

[mlindner]

Very few countries in the world have "licensure" for engineers. It's not a protected term of any sort in the US nor in most of Europe. Canada is one of the few places that's strict about it. Occupational licensing is a form of job market restriction that's generally frowned upon.

[_dps]

In the three European countries I've lived in (2 in EU + UK), licensed engineers must sign off on new building construction plans, and take responsibility for the suitability of the design.

[mlindner]

Licensed engineers exist, but the term "engineer" is not protected.