If 80% of software developers are brilliant enough to write better code faster, cheaper, and more efficiently than they can reuse existing code, why does software still suck so much?
Me, I'm wearing my dubious pants.
Software still sucks because our software design abilities do not grow at the same pace as our hardware design abilities. We try new things, we experiment, but "engineer" is certainly not a term that is rightfully applied to programmers. We're some weird amalgam of engineer, artist, and con-artist, all rolled into one. Personally, I suspect that until we get to the point where we can start offering formal proofs that our programs are correct, we're still going to limp along -- though we'll limp faster all the time.
Re:It sucks because ...
gav on 2003-06-07T04:23:21
I suspect that until we get to the point where we can start offering formal proofs that our programs are correct..
From what little I remember of my formal methods classes, it's not possible to prove program correctness. The Halting Problem
I try not to think too hard about formal methods in case I have another Z Notation triggered flashback.
I think the real gains will come from not treating programming as something done in a vaccum and working on better management and user involvement.
Re:It sucks because ...
Ovid on 2003-06-07T16:58:53
There's actually a fair amount of research in functional programming languages such as Haskell about proving program correctness. While granted, there are certain things which cannot be provably correct (as demonstrated by the Halting Problem), the aim of this research is to either develop formal mathematical proof systems for programs, or to calculate programs from mathematically precise specifications. Unfortunately, Gödel had the cheek to prove that any system that contains basic mathematics can lead to statements that are true, but unproveable, thus ensuring that this research cannot be perfect.
I agree that real gains will most likely come from better management and user involvement, but I suspect that in the next couple of decades we're going to see programming systems evolve that are radically different from what we expect today. It may simply be different methods of approaching the existing problem or reformulating the problem itself, but I don't think, in the long run, that trying to continually tweak the existing mechanisms is the way to go. Too often we get issues such as "we have to beat our competitors to the market" or "we don't have sufficient resources" which ensures that taking the time to do things right will often be a secondary consideration.
I think that automated software testing could be one of the new legs of the programming stool (given the caveat that it's been around for a while, but only recently started to hit its stride). While I have this underlying sense that there's a better way to accomplish testing, I am still astounded at the results I get from testing. I used to write spaghetti programs that didn't have a terribly huge numbers of defects. They were pigs to work on, though, and maintenance often added defects. Since I've really gone gung ho in testing, I've started working on an inventory system which is the largest system that I've worked on (well, I've worked on larger, but only as a maintenance programmer). When I check our bug tracking database, almost invariably the issues entered in there are changes to the specification. Actual honest-to-goodness bugs tend to crop up in the presentation layer. This layer, as we all know, is traditionally the hardest to test. Those types of bugs are often caught by the QA team and not the programmer.
Again, I have a sense that the testing that I am doing can be done better -- it still seems pretty ad hoc -- but having clearer specifications up front and a test-first environment has led to far superior code for us. We have a junior programmer whose Perl skills are not up to snuff, but I worked with him to show him how our testing works and he's turning in good, productive code that's better than the code that I've seen more experienced programmers turn in.
haskell again
educated_foo on 2003-06-08T14:49:09
Okay, this is the second comment I've seen here recently mentioning Haskell (in a positive way at that!), in a forum that seems to me to live on the opposite side of the programming language universe. How many of you (a) have heard of the language, and (b) find it promising/interesting/fun?/s
Re:haskell again
Ovid on 2003-06-08T15:10:01
Pardon me for recommending myself
:), but you can check out this thread about functional programming that I started on Perlmonks. I give a couple of brief examples in Haskell, though MJD has some far more interesting comments in the thread. I certainly recommend checking out Haskell. It's an interesting language, though it's not widely used.
Re:haskell again
educated_foo on 2003-06-08T15:56:38
I've actually spent quite a bit of time playing around in Haskell. Paul Hudak's Haskore is a pretty decent MIDI manipulation system, though not as good (IMHO) as CLM. It's conceptually interesting in a sort of Puritan way, and practically interesting (and relevant to Perl 6) in trying to compile laziness efficiently. But to me it's always been one of these academic languages that's more about itself than about getting anything done. It's optimized for writing a sexy, intuitive 1-line quicksort. Want to insert a debug statement? Try restructuring your entire program to avoid becoming entangled in the IO Monad. Want to tune a slow application? Good luck figuring out what's slow.
/s Re:It sucks because ...
jmm on 2003-06-09T15:05:20
While granted, there are certain things which cannot be provably correct (as demonstrated by the Halting Problem), the aim of this research is to either develop formal mathematical proof systems for programs, or to calculate programs from mathematically precise specifications. Unfortunately, Gödel had the cheek to prove that any system that contains basic mathematics can lead to statements that are true, but unproveable, thus ensuring that this research cannot be perfect.While the Halting Problem and Gödel's Theorem are limitations, they are more of a theoretic problem than a practical one. A program that is "true but unproveable" is likely to be a spaghetti code action-at-a-distance confusing mass that is also nearly impossible to maintain even if it is correct, so having the program prover give up is a perfectly useful answer.
Just because you can write programs that are hard to prove or disprove doesn't mean that such programs are ones that are worth writing.
The vast majority of programming tasks do not involve recursive analysis of programs that analyse programs
... The object is to find a way of writing programs that does not tax the reader, or the program prover, so much that it is hard to demonstrate the program's correctness.
Sadly, I can hear this song in my head, right now, and will probably make some feeble attempt to make up the rest of the lyrics.Outstanding objects, and they're developed dirt cheap
Outstanding objects, and they're developed dirt cheap
Functors... serialization... patterns...
Developed dirt cheap
Regex... templates... iterators...
Developed dirt cheap
