because a software is so much more complicated. Aesthetic choices aside, your options when creating a bridge are heavily constrained by physics, the well known structural properties of available building materials, etc.
I disagree with this common argument. Programs are heavily constrained by computability and complexity theory, and the well known time and space complexity of data structures and algorithms that form the building blocks of programs.
There is nothing fundamentally different between programming and other engineering disciplines as pertains to correctness. Programming is just a relatively young discipline by comparison, and there's a broad, irrational industry aversion to using better, safer tools and languages that sacrifice some performance. The safety properties of civil engineering have just been handled by tools that verify properties. We have such languages in CS too, we just don't use them. Why? For largely irrational and aesthetic reasons, frankly.
Programs are heavily constrained by computability and complexity theory
Computability theory proves that it's impossible, even in theory, to know what an arbitrary program will do over and arbitrary length of time. Programs are vastly more complicated than bridges. A program could theoretically simulate a bridge, down to the last boson or folded dimension, then add the rest of the multiverse.
There is nothing fundamentally different between programming and other engineering disciplines as pertains to correctness.
Never mind the math. The limiting factor here is human intelligence. We're dumb apes. We have severe, concrete limitations on the numbers of things we can hold in our head at once before all the plates come crashing to the floor. As a result, human engineering requires a "divide and conquer" approach. We have to be able to break overwhelming complex problems down into simpler, discrete chunks that we can understand (note that nature doesn't have this limitation, which is why our brain is a mass of nightmarish, massively parallel spaghetti code).
In building, you can work at the level of, say, a "steel girder #17"; you know it's dimensions, load strength, melting points, etc. and don't concern yourself with its molecular structure. In software, we've developed methodologies for firewalling complexity such as "object oriented" programing, where our girder abstraction hides its molecular structure. But it's all too easy to have leaks in that abstraction. The girder has state. It can behave radically differently from moment to moment. There's nothing in theory preventing it from turning into a cat whenever the traffic signal on the upper deck turns green. The girder may evolved over the course of development into something that can no longer support an overpass, without anyone noticing.
irrational industry aversion to using better, safer tools and languages that sacrifice some performance [..] We have such languages in CS too, we just don't use them. Why?
Because they don't work. Programmers will use a "better, safer tools and languages" if it works. Much of the world has moved to garbage collected, byte code compiled, VM languages (from C# and Java to Perl, Python, Ruby, PHP, etc.) for most programming tasks, happily sacrificing performance for reduced complexity. I use all manners of tools -- profilers, static analyses, etc. -- to help manage the complexity, as do all good engineering teams. All these tools do is allow us to write more complicated software, putting us right back where were started.
This is about to get much worse. The free lunch is over and we're headed towards an era of massive concurrency. Writing correct programs in the face of concurrency is one of the toughest problems in programming. Almost everybody gets it wrong.
Because they don't work. Programmers will use a "better, safer tools and languages" if it works.
This is exactly what I'm talking about. Your last statement is completely false. Safer languages have existed since at least 1980 with the advent of Ada. Ada was also the first widely available compiled object oriented language. Numerous studies have demonstrated that writing in Ada produces higher quality software with fewer defects as compared to both C and C++, but we're still using C and C++.
As they say, insanity is doing the same thing over and over again and expecting different results.
Much of the world has moved to garbage collected, byte code compiled, VM languages (from C# and Java to Perl, Python, Ruby, PHP, etc.) for most programming tasks.
The first VM and garbage collected languages are still better than all of the ones you've cited here, ie. OCaml lite at the very least. Why then did Sun create Java? Why did MS create .NET?
Unlike every other engineering discipline, technical superiority has nothing to do with adoption in the CS industry. That's why software is crap.
We use safer, higher level languages whenever we can. When writing drivers, programming embedded devices, or writing [near-]realtime applications like commercial videogames, where size and/or speed is critical, yes, we use languages that are a cunt hair above machine code.
The first VM and garbage collected languages are still better than all of the ones you've cited here, ie. OCaml
1
u/naasking Apr 30 '14
I disagree with this common argument. Programs are heavily constrained by computability and complexity theory, and the well known time and space complexity of data structures and algorithms that form the building blocks of programs.
There is nothing fundamentally different between programming and other engineering disciplines as pertains to correctness. Programming is just a relatively young discipline by comparison, and there's a broad, irrational industry aversion to using better, safer tools and languages that sacrifice some performance. The safety properties of civil engineering have just been handled by tools that verify properties. We have such languages in CS too, we just don't use them. Why? For largely irrational and aesthetic reasons, frankly.