Intuitive Bug-less Software?

Starlover writes "In the latest java.sun.com feature at Sun's Java site, Victoria Livschitz takes on some ideas of Jaron Lanier on how to make software less buggy. She makes a couple of interesting points. First, making software more 'intuitive' for developers will reduce bugs. Second, software should more closely simulate the real world, so we should be expanding the pure object-oriented paradigm to allow for a richer set of basic abstractions -- like processes and conditions. The simple division of structures into hierarchies and collections in software too simple for our needs according to Livschitz. She offers a set of ideas explaining how to get 'there' from here. Comments?"

Comments

What you need for bugless code

[Anonymous Coward]

Is bug spray.

I found it to be interesting

[MysteriousMystery]

I found it to be fairly interesting but is it just me or were there a few too many shameless plugs for Java in her "interview"?

Re:I found it to be interesting

[ajs]

Lots of shameless plugs, yes, but look at what's being advocated:

* More intuitive
* More inclusive
* Pattern recognition vs. "yes/no" type logic

Ah... ok, let's turn those 90 degrees:

* More context-aware
* There's more than one way to do it
* Logic using higher order comparison such as regular expressions and grammars

Hmmm... Perl anyone? ;-)

Perl is universally panned by people who don't use it for being "opaque", and yet that opacity is the result of all three of the above, and CPAN is a monumental testiment to the value of those features in terms of large-scale software engineering.

If your opinion of dollar-signs is so valuable to you that you can't see the value in 4GB of source code sitting at your fingertips, then I direct you to the nearest Java tutorial....

Re:I found it to be interesting

[hikerhat]

Not sure how you got modded up to +5 insighful, given that there were no sameless java plugs at all. I went to the article and searched for the word java.

The first two hits in the article point out that java was architected with security in mind. This is simply true, and hardly a shameless plug.

The next hit is in the question "How well do you think modern programming languages, particularly the Java language, have been able to help developers hide complexity?"

The answer starts with the word "Unfortunately" and goes on to explain that not even OO languages reduce complexity enough when an app gets big enough. The word "Java" isn't used once in the answer. That certainly isn't a plug.

The final hit is in the question "Do you have any concrete advice for Java developers? And are you optimistic about the direction software is headed?"

Note some good general purpose advice is given in the answer, and the term "Java" isn't used once in the answer.

Re:I found it to be interesting

[Paradox]

It was probably modded funny because it's such blatent Perl-first-ism. Perl doesn't hold a monopoly on these things, perl does have a problem with readability, and perl does have many surprising flaws. It's really not the point here anyways. Perl doesn't really satisfy any of the (reasonably good) points made in the article, at least not in an acceptable fashion.

I thought it was pretty funny anyways.

Re:I found it to be interesting

[Adartse.Liminality]

Perl? brrr!! thanks but no thanks, POOP==Ruby && ruby==perl.upgarde.

perls has its place, I've tried to learn perl no big deal until you start to see "perlisms" AKA hacks, and then it becomes unreadable, I preffer perl's prettier and younger sis, Ruby, OOP done if not right at least a lot better, mmmh how to avoid bugs? typing less helps ;-) a very readable sintax does too, intuitive language design and POLS avoid bugs even more.

And POOP stands for Pure Object Oriented Programming.

Re:I found it to be interesting

[ajs]

Perl's OO model isn't.

That's not to say it's bad, but it simply isn't. Perl provides you with all of the tools you need to build a GREAT OO system, but that's not an OO system.

This is one of those things that Larry does that's just unfathomable to the rest of the world. He didn't really grok OO back 10 years ago when P5 was in the works. He understood it well enough to program in the large in C++, but he didn't quite have his head fully around the implications, so when he added OO to Perl 5, he did so in such a way that all of the various ways of approaching code from an OO standpoint could be accomodated.

This means that writing OO code in Perl kind of sucks, but if you want to design an OO model for a programming language, no tool (other than a parser generator) will be more powerful.

Come Perl 6, Larry finally feels that he gets it enough to tell all of the people who are going to have to use his language how to do it. He doesn't take that responsibility lightly, and the fact that SO MANY other language designers do should worry you.

That said, if you want to write medium-sized programs that are heavily OO-dependent, I suggest Ruby or Python or even Java. If you are writing small tools, OO vs non-OO won't matter that much.

If you are building huge systems, then you don't care because the amount of work required to lay out how you will use OO in Perl is insignificant next to the architecture that you have to lay out for the rest of your app. It's just noise in your timeline, and you can fully re-use that policy in every other project that your company tackles.

What's amazing is how Perl lets all of these OO models interact. I'm always stunned by this, and frankly it's a tribute to the language and its designer.

As for your comment about typing less... I don't think that languages with the level of abstraction of Ruby or Perl really need to have line-count contests. Dynamic typing, run-time data structure definition and garbage collection make programming SO much easier that Perl and Ruby are in the same order of magnitude, and I don't see a reason to quibble over the details.

Re:I found it to be interesting

[vt0asta]

I fear your comment is going to get lost in the crowd of people who don't understand Perl. The people who don't see that Perl maps exceptionally well to many problem spaces.

Groking Perl seems to be like groking pointers in C. Some people seem to be simply born without the part of the brain that understands them.

Perl is context-aware/intuitive. It understands the need to be able to easily take data from any source, chop it up, mangle it, and then easily spit it back out. There isn't much to learning Perl syntax, but it will insist that you memorize some traditional things, like operator precidence, syntax, and the basic perl functions. Not hard at all when you get down to it.

Perl is inclusive. There is definitely more than one way to do it. This is a "good thing", because one way that works, might not be best way. Similiar problems, sometimes require a slightly different solution. Perl has online documentation out the wahzoo. perldoc rocks, and you have a list of up to date books that rival O'Reilly's (many times by the same authors). Perl modules have built in unit testing. Perl is a language and a culture that values and facilitates "testing".

Pattern recognition, is something Perl excels at. Especially the type of pattern recognition and logic handling that is required for most applications. Need something fancier? Like fuzzy? Neural Net? Look to CPAN. Using regular expressions in Perl takes one line of code, no need to worry about making a regex struct or object, then compiling the syntax, and then running the match, and then deallocating the regex struct.

You're right, the same people who pan Perl for being opaque are typically the same that use method overloading, polymorphism, and other abstraction and obfuscation techniques and then claim their code is more readable, and easier to understand. They also tend to be the same people who believe Perl is only good for one off scripts and hacks. To which I say that is only the beginning of what Perl is great at.

Re:I found it to be interesting

[hotpotato]

Perl is very good at certain things, and terrible at others. CPAN is an excellent example of what Perl is incredibly good at: A huge collection of relatively small components that perform very specific tasks.

Perl fails, however, when it comes to scalability: Lack of compile-time type-safety, encapsulation and other mechanisms. It generally has a very exposed and ad-hoc OO model make creating large, complex structures exceedingly difficult. Not to mention the nightmare of trying to maintain an existing piece of code that is longer than a couple of tens of thousands of lines.

Don't get me wrong: I love Perl. It is my first choice when writing tools that aid me in development or tie up some loose ends from several systems. But it pales when compared with Java for creating large systems.

Re:I found it to be interesting

[whittrash]

The syntax of all mainstream programming languages is rather esoteric. Mathematicians, who feel comfortable with purely abstract syntax, spend years of intense study mastering certain skills. But unlike mathematicians, programmers are taught to think not in terms of absolute proof, but in terms of working metaphors. To understand how a system works, a programmer doesn't build a system of mathematical equations, but comes up with real-life metaphor correctness which she or he can "feel" as a human being. Programmers are "average" folks; they have to be, since programming is a profession of millions of people, many without college degrees. Esoteric software doesn't scale to millions, not in people, and not in lines of code.

In the article, her solution to error is to increase the tolerance for error, making direct mistakes unlikely or impossible because there is plenty of 'slop' in the system and you can't get a wrong answer. Theoretically, this lowers precision and increases overhead of the system. Her solution to the difficulty in understanding programming is making it so any idiot can understand it.

To make an analogy, a programmer is like a bucket. Her solution to filling a bucket (writing code) is to submerge it inside a larger pool. In that situation, any old bucket will do, the bucket will always be full when placed in a pool; but you will then have to carry the entire pool if you want it to move. The question then becomes how much you can carry, not the performance of the bucket.

She may well be right about intuitive programming, being easier to use, and that making programming more like regular language with intuitive syntax could be beneficial (more like programming a Star Trek AI computer than what we have now). But this would also shift the nature of the problem from design and architecture to performance and underlying stability issues. Any fool could write code without knowing how it worked. Some shortcuts may be appropriate in certain cases, but to rely on these kinds of methodologies in critical situations could lead to disaster and has a built in unreliability factor. If some company thinks they can buy this system and then expect bullet proof security, reliability and high performance, they are probably in for a rude awakening. They should expect 'good enough' performance, which is what they are getting already.

The only way to do exceptionally good work in a complex situation is to have the knowledge and experience for what you are doing at all levels and the ability to execute. Allowing programmers to be ignorant of how a computer works doesn't seem like a solution to me. The real problem with crappy software is companies that don't care and consumers who don't know any better.

Re:I found it to be interesting

[Adartse.Liminality]

Yes I did RTA, but is Java OO the absolute best OO implementation?, OOP is not the solution to all. do I really want to create a full class method for a simple task, NO, "OO paradigm could have limitations", is not "could" but "HAS", OOP is a step ahead of functional programming IN certain situations, speed is not OO forte, but reuse of code/refactoring,encapsulation,etc is.
I don't really need someone telling OO has limitations, I already know and you should, a programmer should be limited by his ability to use his/her tools and not by knowing only a single lang or a single programming paradigm
What I want to point out is that:

• There should be less filler in the code to keep interpreters/compilers happy, how Java or any lang rates in this point?

• High level language, the more you have to type the more errors/bugs that you can make, but HLL or VHLL has its place as low level also does.

• Simple logical grammar of said lang, with time even perlisms become easier to read ;-) but if is readable at the very first minutes? if is already familiar? type some code and does what you expected? Intuitive is the word but is relative to one's experience.

• AFAIK there's no lang that does all and does very good and is also fast, easy, multiplataform and maintenable. If so please inform me.

Besides I was answering to the proposition of using perl instead of java ;-), looking ahead? fine with me, but giving Java as an exemplar OO lang is not, neither as easier to use.
Her proposition of a notch more to OO looks quite nebulous and ungraspable, I think she should research more languages.

I'd rather have...

[American AC in Paris]

Frankly, I think the better approach would be to make software developers less buggy. Educate them properly!

So long as you allow developers to do such things as basic arithmetic and variable assignment, you're gonna have to deal with buggy code written by self-recursive sphincter-spelunkers.

Re:I'd rather have...

[pompousjerk]

Heh heh, yeah, right.

Right now I am in a Computer Science program. I have had the pleasure to see:

• Students brag about their 400+ line recursive routine that they finally got working
• Students that hate Linux/BSD/Solaris because "you have to use the command line"
• Students exclaim, "It compiles!", as if it was a significant milestone in the development of the program (which, to them, I guess it is)
• Students get confused when '.' is not in their $PATH
• Professors taking advantage of having '.' in their $PATH
• Students that love Visual Basic because you can "just drag and drop!"

I don't think the whole proper education thing is going to happen any time soon.

Re:I'd rather have...

[Jeremi]

Don't forget

• Slightly more experienced CS students acting condescending and superior to the newbies, because their own newbie days are 18 months behind them.

Re:I'd rather have...

[MattRog]

Scatological reference aside, I do agree. Not only that, but educate them *properly*. Most higher education these days is a sham. They 'teach' products and not processes, cook-book approaches and not critical thinking.

Dijkstra has a few things to say on the topic as well:

On Education, Specifically:

The ongoing process of becoming more and more an a-mathematical society is more an American specialty than anything else (It is also a tragic accident of history).

The idea of a formal design discipline is often rejected on account of vague cultural/philosophical condemnations such as "stifling creativity"; this is more pronounced in the Anglo-Saxon world where a romantic vision of "the humanities" in fact idealizes technical incompetence. Another aspect of that same trait is the cult of iterative design.

Industry suffers from the managerial dogma that for the sake of stability and continuity, the company should be independent of the competence of individual employees. Hence industry rejects any methodological proposal that can be viewed as making intellectual demands on its work force. Since in the US the influence of industry is more pervasive than elsewhere, the above dogma hurts American computing science most. The moral of this sad part of the story is that as long as the computing science is not allowed to save the computer industry, we had better see to it that the computer industry does not kill computing science.

And then on Computer Science in general:

"I hope very much that computing science at large will become more mature, as I am annoyed by two phenomena that both strike me as symptoms of immaturity.

The one is the widespread sensitivity to fads and fashions, and the wholesale adoption of buzzwords and even buzz notes. Write a paper promising salvation, make it a "structured" something or a "virtual" something, or "abstract", "distributed" or "higher-order" or "applicative" and you can almost be certain of having started a new cult.

The other one is the sensitivity to the market place, the unchallenged assumption that industrial products, just because they are there, become by their mere existence a topic worthy of scientific attention, no matter how grave the mistakes they embody. In the sixties the battle that was needed to prevent computing science from degenerating to "how to live with the 360" has been won, and "courses" -- usually "in depth"!-- about MVS or what have you are now confined to the not so respectable subculture of the commercial training circuit. But now we hear that the advent of the microprocessors is going to revolutionize computing science! I don't believe that, unless the chasing of dayflies is confused with doing research. A similar battle may be needed."
--Edsger W. Dijkstra, My Hopes Of Computing Science, 1979

Re:I'd rather have...

[American AC in Paris]

You misinterpret what I've written.

I'm not suggesting that we do away with basic arithmetic or variable assignment. You can't do that and still have a programming language. The very idea of writing a program of any complexity that doesn't incorporate basic arithmetic or variable assignment is just plain silly.

Rather, I'm saying that so long as programmers can use such essential and basic functionality, the bad ones will find ways of producing buggy code. Inaccurate formulae. Hard-to-maintain code. Inefficient design. Poorly formed logic. Bad algorithm selection. You just can't 'fix' bad programmers with better languages.

There's just no way to teach a compiler to recognize bad code design, and there's no way to tell a programming language, "do as I mean you to do, not as I say you to do." Yes, things like garbage collection and bounds-checking help prevent some bugs, but the really nasty ones--the ones that take ages to fix--are the result of good ol'-fashioned bad design and programming.

As for the troll remark, go ahead and dig through my user info page. I may be snide at times, but I'm no troll.

Re:I'd rather have...

[E_elven]

I must disagree on one part: CS has suffered from left-brainers for too long. The right-brainers are a useful bunch, and the best results come from mixing the two.

The perceived problems are actually caused by the no-brainers.

Well...

[bobbinFrapples]

First, making software more 'intuitive' for developers will reduce bugs

Feels right.

Re:Well...

[RocketScientist]

Man I hate this.

How many times do we have to have fundamental truths reiterated?

"Premature optimization is the root of all evil"

I'd submit that nearly every bit of non-intuitive code is written because it "should be faster" than the intuitive of equivalent function. Just stop. Write the code the way it needs to be written. Decide if it's fast enough (Not "as fast as it could be" but "Fast enough") and then optimize if necessary.

Re:Well...

[cybermace5]

I once had a teacher whose recurring theme, loudly stated in every applicable situation plus several more, was that "INTUITION SUCKS!!!"

I never did get around to asking him how he knew that, or if it was kind of a gut feeling he had.

Re:Well...

[dubious9]

Perhaps he was refering to the adage that the only intuitive interface is the nipple. Nipple=intuition. What does one do on nipple? Suck. Therefore intuition sucks. Or maybe he was a boob man.

Re:Well...

[AeroIllini]

I never did get around to asking him how he knew that, or if it was kind of a gut feeling he had.

It must have been intuition.

But in all seriousness, "intuitive" is a synonym for "personal preference" when it comes to abtract concepts like computing. After watching highly successful, highly intelligent professors (with PhDs, mind you) struggle with the basic concepts of computers, such as installing software, creating shortcuts, transferring files between two computers, etc., it became abundantly clear to me that "intuitive" is only what the creater of the "intuitive" system preferred. In fact, I know several professors who still write their highly complex numerical simulation code in FORTRAN, because "it's more like English than other languages." FORTRAN is highly counter-intuitive, but it's a damn fast number crunching language (rivaled only by C, if I remember my benchmarks correctly).

Computers are obtuse, and rightfully so. Turning millions of micropulses of electricity flowing through tiny bits of various metals into a 2-dimensional dancing paperclip boggles the mind. In order to write complex applications with millions of lines of code, and have that code run at a reasonable speed and/or efficiency, the programmer is going to need some knowledge of how the computer works. That will require that s/he has access to things like memory locations as s/he codes, and also be fairly intelligent. If all you need to write is a little macro for inserting customer records into Excel, then efficiency is not really a factor and "dumbed-down" development environments like Visual Basic are just fine for the purpose.

I'm all for making computers easy to use, but "intuitive development environments" are an Eldorado. Let's focus instead on creating programming languages that are not only stable, but secure, cross-platform, robust, *consistent*, and above all, efficient. Even if they are a little obtuse: steep learning curves are not the problem.

Re:Well...

[mattgreen]

Wrong. If you are optimizing without the guidance of a profiler you are wasting your time. Unless you knowingly put a bottleneck in you are merely shooting in the dark. And don't confuse choosing proper algorithms and data structures with optimization, either.

Objects

[tsanth]

I would love to use a C/C++/Java-like language that utilizes pure objects, versus the mish-mashy hybrid typing that exists in most languages that I've used. To me, Livschitz's observation about how programmers work in metaphors, while mathematicians work in pure syntax, is very true: I breeze through all my programming and software engineering classes, but struggle mightily with math courses (save boolean algebra, but I digress).

I, for one, would like software writing to resemble (really resemble) building structures with Legos.

Re:Objects

[weston]

Livschitz's observation about how programmers work in metaphors, while mathematicians work in pure syntax

It's an interesting thought, but it's not necessarily true at all. Mathematics is metaphors, even though they're often very abstract. But it's more like working with somebody else's codebase, most of the time. Unless you're striking out and creating your own formal system, you are working with metaphors that someone else has come up with (and rather abstract ones at that).

The good news is that most mathemeticians have an aesthetic where they try to make things... as clean and orthogonal as possible.

The bad news is that terseness is also one of the aesthetics. :)

Re:Objects

[be-fan]

See: Lisp, Dylan, Scheme, Ruby, Python, Smalltalk, among others. These languages are all "objects all the way down" though Dylan, Ruby, and Python are more-so than Lisp and Scheme.

Re:Objects

[Coryoth]

There is a distinction between metaphor and definition. If I say a function is a machine for turning elements of the input set into elements of the output set, then this is a metaphor in which I have used the word machine to describe a function. I suspect that what you are arguing is that the word function itself is a metaphor. This is incorrect. The word function has a defintion. A function f:X->Y is a subset of XxY such that for every x in X there is a unique y in Y such that (x,y) is in the subset. This is not a metaphor.

Which doesn't mean mathematicians don't use metaphor a lot. The catch is that they like to have solid rigorous definitions to tie things back to. Often when doing mathematics you will think in terms of the metaphors to percieve a way to proceed, and then try and explain the process you just considered in terms of definitions.

If you want a metaphor for that: Published mathematics tends to be assembly code: low level with strong static typing, and everything very explicit. That doesn't mean that mathematicians don't write it in their heads in Python or Java and compile it. Think of research mathematicans as powerful metaphor compilers as well as programmers.

Jedidiah.

Re:Objects

[jonadab]

> I would love to use a C/C++/Java-like language that utilizes pure objects

If it had a good object system, wouldn't that make it totally unlike C, C++,
or Java? At least, semantically it would. I suppose the syntax could be
C-like. Inform for example has C-like syntax, but the object system is so
much more advanced than the one used by C++ that there is no comparison.
(Inform, however, is not a general-purpose language. It doesn't have the
I/O capabilities to be general-purpose. This is mostly due to the virtual
machine it's designed to compile to, which for portability reasons doesn't
support such things as a filesystem per se. But it's a great language for
its intended problem space.)

I'm sure...

[lukewarmfusion]

"software should more closely simulate the real world"

Because the real world doesn't have bugs, right? Our company doesn't have project management software yet - but we're working on it. Personally, I don't think it's worth it until we fix the real world project management issues that this software is supposed to help with. Maybe that's not quite the point, but it raised my eyebrows. (Which I'm thinking about shaving off.)

Re:I'm sure...

[Xenographic]

The real world has software bugs!?

You been experiencing a few too many glitches in the Matrix lately, or something? ;]

Re:I'm sure...

[Carnildo]

Because the real world doesn't have bugs, right?

The first rule of programming is to realize that all input is intended to crash your program, so code accordingly.

Jaron Lanier?

[jjohnson]

Someone please explain to me why anyone listens to this guy. I've read his essays; they're pedantic and hand-wavey. The term "Virtual Reality pioneer" should be enough to disqualify him from serious discourse.

Somebody, please point me to something significant he's done so I'll know whether or not I should pay attention to him because, from everything I've seen so far, I shouldn't.

Not a good idea...

[Leffe]

Writing bugless code is not a good idea, in my opinion, think about it: Debugging is the art of removing bugs, therefore programming is the art of adding bugs.

Writing bugless code would throw the universe upside down and could possibly mean the end of the world!

Moderation Guideline: +3 Funny.

Comments?

[jayhawk88]

I'd say that with buzz-speak like that, she's going to make some CIO very happy someday.

Re:Three-choice system of logic

[PD]

Better yet, let's move to a system of logic where there is one state for each possible answer. This woman is asking if we're fundamentally making improper assumptions about programming, and that's why we're making crap programs. My proposed machine would fix that, because it has an output state for every possible answer. All that would be required is to select the desired output answer, then map it back to the input state. Bingo! We've now got the right question to ask.

(Or in other non-silly words, adding more states to a computer logical system doesn't make it more useful).

Not my problem anymore.

[Anonymous Coward]

This type of stuff is not a problem for me to worry about anymore. It's India's. Direct me to the nearest auto-mechanic school please. It's time to learn how to fix problems that can put money in my pocket.

Re:Not my problem anymore.

[Tablizer]

This is life in a global economy. Live with it. If you want to love what you do for a living, be willing to accept less money for it

They usually don't give you that option. How many offshored developers were asked, "You can go, or get 25K a year". Nor are there many programmer job postings for 25K.

A truly global economy would let people shift around as easily as the jobs do. Instead we are limiting the variety of jobs available in the US, which is a security concern if you ask me. If we are cut off in a disaster or attack, all the marketers and managers here are not going to know how to do anything real. Other countries do all the real work now.

Ugh, more abstraction.

[Telastyn]

It might be me, but I've seen more bugs created because of assumptions made about abstractions, or because someone was used to a pre-made abstraction and didn't learn how things actually worked.

Want to make better software? How about actually scheduling enough QA time to test it? When development time runs over schedule, push the damned ship date back!

Re:Ugh, more abstraction.

[Fizzog]

The problem is that people see some kind of pattern they recognise in the initial requirement and immediately decide there is an abstraction to be made.

An abstraction is a pattern you find in something that exists, not a pattern you decide on for something you are going to do.

Write it to do what it is supposed to do, and then look for abstractions.

Re:Ugh, more abstraction.

[kvn]

I agree completely. Whether a developer uses a functional language or an object oriented language doesn't matter. What does matter MORE THAN ANYTHING is understanding the process that the software is supposed to support. If it's hospital management software, you have to know how hospitals are managed. If it's banking software, you have to understand banking.

And testing, testing, testing. Because people aren't perfect. Nor would we want them to be... Too much money to be made in support contracts. :)

Re:Ugh, more abstraction.

[robbkidd]

Want to make better software? How about actually scheduling enough QA time to test it? When development time runs over schedule, push the damned ship date back!

And mandate unit testing be integrated with coding.

Re:Ugh, more abstraction.

[boomgopher]

True, but good abstraction skills are really important.

Some of the guys I work with think that "tons of classes == object-oriented", and their code designs are f-cking unreadable and opaque. Whereas a few, thoughtfully designed classes that best model the problem would be magnitudes better.

Re:Ugh, more abstraction.

[Greyfox]

All the process and buzzwords in the world will not help you if your programmers don't understand your needs.

Want to make better software? Make sure your programmers understand what you're trying to do and make sure that enough people have "the big picture" of how all the system components interact that your vision can be driven to completion. It also helps if you have enough people on hand that losing one or two won't result in terminal brain drain.

Recently management seems to be of the opinion that people are pluggable resources who can be interchangably swapped in and out of projects. Try explaining to management that they can't get rid of the contracting company that wrote a single vital component of your system becauase no one else really understands how it works. They won't get it and you'll end up with a black box that no one really knows how to fix if it ever breaks.

Re:Ugh, more abstraction.

[BinxBolling]

When development time runs over schedule, push the damned ship date back!

Not gonna happen. The vast majority of the time, the economic penalty associated with being late is much greater than the economic penalty associated with being buggy.

Re:Ugh, more abstraction.

[AeroIllini]

Want to make better software? Make sure your programmers understand what you're trying to do and make sure that enough people have "the big picture" of how all the system components interact that your vision can be driven to completion.

Well said. It's an extension of the "cubicle nature" of the working world. Here's your cubicle: you are part of the whole, but you're by yourself, and can't really see what's going on around you. Here's your project: it's a compenent of a larger piece of software, but you don't really need to know how the other pieces work. Just code your part and be happy.

I'm not saying we shoud ditch the cubicle (where else would we hang our Dilbert clippings?) but we should certainly ditch the cubicle atmosphere surrounding technical projects. Let everyone in. Big Picture, people.

Functional Programming et al.

[pc-0x90]

She misuses the term functional programming. I'm assuming she meant imperative languages. A lot of the problems could be solved with true functional languages (Haskell, OCaml, etc) but the learning curve is too high. Especially when you can get a team of second rate VB coders for the price of one haskell coder (if you can find one) But really, do you want working code now? Or perfect code in 10 years? That's where the problem is. Time.

Re:Functional Programming et al.

[Tailhook]

A lot of the problems could be solved with true functional languages (Haskell, OCaml, etc) but the learning curve is too high.

A lot of problems are solved with functional languages. Functional advocates claim to have the answer to software correctness and they decry the present state of imperative logic programming. What I think they fail to realize is that functional programming is ubiquitous, solving problems on a scale that contemporary imperative tools will never approach.

Microsoft Excel is, in essence, a functional programming language. It is utilized by non-"programmers" planet wide every day to quickly, accurately and cheaply "solve" millions of problems. It has, effectively, no learning curve relative to typical coding. I have found it to be an invaluable software development tool. I take it a bit further than the typical spreadsheet task by using to model software systems.

It is especially helpful with business logic problems. I recently implemented a relatively complex web-based product configurator. I know that if I can model the complete problem in a stateless manner using a spreadsheet, writing bug-free, efficient client and server side imperative code becomes a simple matter of translation. For any given state of a collection of inputs there is exactly one atomic result. In this case the result is a (possibly lengthy) structured document computed dynamically from a collection of input forms, both on the client (because page refreshes suck) and on the server (because validation must not depend on an honest client.) Both independent implementations (in different languages) are "obviously" correct in the sense that they are derived from a clear, functional model, built in a spreadsheet.

You may substitute any contemporary spreadsheet product in place of Excel; I have no love of Excel specifically. It's just what I've happened to have handy in all cases. The fact is that modeling most software problems requires very little of what any reasonablely competent spreadsheet can accommodate. Feel free to lecture me on precisely why it is blasphemous to suggest that a spreadsheet qualifies for the designation "functional programming." I know the difference because I've studied LISP and used Scheme. The subset of true functional programming that provides the most value is clearly represented by the common spreadsheet.

Re:Functional Programming et al.

[dirt_puppy]

I think both parent posters are just right, functional programming is a great way to encounter problems, and excel spreadsheets are too.

The big advantage of FP is its clearness and rigidness. To an experiences functional Programmer, its exactly clear what a piece of Haskell Code means, since the code is half general functions that are easy to understand (map, zip, fold et.al.) and half problem-specific functions that are about as easy. The solution is built from simple bricks everywhere, other than in imperative Programming.

Another thing is, we're talking about functions aren't we? And shouldnt the First Class Citizens of our Language be functions then?

Besides, Functional Programs are very much easier to prove, and thats a thing that will be very important in some time in the future (or so I pray... or everyone in IT buisiness will go nuts over the giant pile of bugs that accumulates). For a little introduction into the theory behind this check this document about The Curry Howard isomorphism (at the very Bottom of the page). Besides, this is a fundamental link between programming and philosophy (intuitionistic reasoning)

"Excel" type spreadsheets are very useful too, maybe not for everyday programming but for short and programs intended for quick use by non-programming coworkers. In fact Excel is the one Program that tells me that not everyone in Microsoft can be a moron.

Re:Functional Programming et al.

[shammahau]

While you are correct about the power of concurrent dataflow programming (ie excel ;), you are mistaken to suggest that this is not recognised by the FP community. A quick search for 'spreadsheet programming' on citeseer uncovered this: Domain-Specific Languages: An Annotated Bibliography http://citeseer.nj.nec.com/396896.html Haxcel: A Spreadsheet Interface to Haskell http://citeseer.nj.nec.com/lisper02haxcel.html Uncovering Effects of Programming Paradigms: Errors in Two Spreadsheet Systems http://citeseer.nj.nec.com/tukiainen00uncovering.h tml Spreadsheet Model for Programming http://citeseer.nj.nec.com/ambravaneswaran00spread sheet.html Unfortunately spreadsheets as they currently exist exhibit a striking level of bugs as they attempt to scale to larger systems[tukiainen00], the limitations are well know. Fortunately there is active research into addressing these issues (I've lost the citation, but I remember finding the papers on citeseer). Yes spreadsheets are a powerful FP mechanism; but there is still a lot of work left to do before they could be considered a candidate silver bullet.

Re:Functional Programming et al.

[daniel_yokomiso]

Especially when you can get a team of second rate VB coders for the price of one haskell coder (if you can find one)
This is an exaggeration. Let's you'll pay US$ 15.00 per hour of a "second rate VB coder" and pay US$ 60.00 per hour for a "haskell coder". So it's better to have 4 lousy coders that will miss all of your deadlines, deliver low-quality, unmaintanable code or have one good programmer that'll ship the product earlier? I don't think this comparison holds.

But really, do you want working code now? Or perfect code in 10 years? That's where the problem is. Time.
Hmm, IME functional programming languages uses less lines of code, are faster to deliver bug-free code and are easier to maintain. So with FPLs you'll have near-perfect code now, against crappy code after several missing deadlines.

Re:Three-choice system of logic

[GeckoX]

It is called ternary computing, as opposed to binary computing.

There is a ton of information out there on this, and this is in no way a new idea. (Google it, lotsa reading for ya)

Currently, the only way to utilize this is to process ternary logic in software, as at this point there is no ternary circuitry in general use.
For this to actually be useful we would need a platform that can execute ternary code natively.
Lots of work has been done in this area too (not only with ternary, but with multi-state transistors with more than 3 states as well)

For those of us not at the bleeding edge of research in these areas though, we'll just have to wait until there is hardware to support this kind of thing, and then likely some tools to start with.

Test?

[JohnGrahamCumming]

I find it enlightening that this article does not include the word "test" once. Rather than spending a lot of time hoping that the purest use of OO technology or some other fancy boondoggle is going to make software better actually writing tests that describe the expected behaviour of the program is a damn fine way to make sure that it actually works.

Picking just one program from my experience, POPFile: intially we had no test suite, it quickly became apparent that the entire project was unmanageable without one and I stopped all development to write from scratch a test suite for 100% of the code (currently stands around 98% code coverage). It's particularly apparent when you don't have all day to spend fixing bugs because the project is "in your spare time" that it's vital to have fully automatic testing. You simply don't have time to waste fixing bugs (of course if you are being paid for it then you do :-)

If you want to be really extreme then write the tests first and then write the program that stops the tests from breaking.

John.

Re:Test?

[ziggy_travesty]

I agree. From the disposition of her interview, it seems like testing is beneath her; programs should will themselves to work flawlessly. Just like NASA's reflector tests on the Hubble...right. This is definitely hand-waving. She whines about how modern OO languages aren't intuitive for certain relationships and offers no concrete (or abstract) solution for these shortcomings. The bottom line is: software has bugs because it is complex. Deal with it. It's very hard to write large, qualtiy applications. We need more skilled and better educated engineers, not more language constructs. Launching a space shuttle or writing a weapons targeting system will never be an intuitive process. Also, intuition and simplicity will never be a substitute for testing. What malarkey. -AZ Strengths: whining and moaning Weaknesses: independent thought

Re:Test?

[Cranx]

I agree everyone should try it. Rather than argue about whether it saves time or wastes time, everyone should start writing unit tests for every project before you begin coding it, give it a couple years, then decide whether it's worth it or not.

Re:Test?

[tyroney]

• If you want to be really extreme then write the tests first and then write the program that stops the tests from breaking.

That, to me, is a very good way of thinking. In the same vein is paranoid programming. Remember murphy's law. You get the idea.

Unfortunately, such things take far more time than making a few assumptions, and hoping for best practice.

Re:Test?

[JohnGrahamCumming]

> This is the old way of thinking. When you see the answer, I'm sure you'll jump on board.

I did a PhD at Oxford in the Programming Research Group and studied Z, CSP and all that stuff. My thesis even includes a program written in Occam proven via an algebra to meet a security specification.

Believe me, I'm aware of what the world could be like, but it is not practical to write real software this way yet. Hence we still need to test, and not enough people write tests today. Unit and system testing are best practices for the industry today, sure, there's a better theoretical way to do things, but I need to code in 2004 not 2054.

John.

Re:Test?

[rwa2]

There are two ways to assure quality work, both in manufacturing & software.

One is to have inspectors look at everything and make sure they're right. QA or "testing"

The other is to actually fix the broken machines / processes that are stamping out broken widgets / buggy software in the first place. I think she's after this path.

Of course, you still need both.

The two big reasons software is buggy!

[irhtfp]

This is all well and good, but I think there are two primary reasons software continues to be buggy:

The first is the intense pressure to get the product to market. This is especially true for custom code, written specifically for one client. They want it fast and cheap and in order to satisfy this desire, code invariably gets released/installed before it's ready. Then the "month of hell" starts as the client starts complaining about bugs, "bugs" and other problems and we bend over backwards to get it right.

As a ISV, we have no choice but to do it this way. If we don't quote the project with this in mind, the client will hire somebody else with a better "can-do attitude".

The second big reason software is buggy is because all the underlying tools (e.g. code bases, code objects, .dlls, etc.) are buggy as hell. I spend more time working around inherent bugs than I do debugging my own code.

Most programmers are perfectly capable of making their own code solid, given enough time.

Re:The two big reasons software is buggy!

[FreshFunk510]

I like to compare it to civil engineering.

Civil engineering is superior for 2 reasons. 1) Time of QA and 2) Dependability of materials.

In short, look at the time it takes to QA a bridge that is built. Not only is there QA done from design to finish, but real load testing is done. Although software does have serious QA, the time spent QAing civil engineering products is far more as a ratio to time spent actually building.

Dependability. The thing with building things is that you can always take it for granted that the nuts, bolts and wires you use have a certain amount of pressure and force they can handle. Why? Because of the distinct same-ness behind every nut, bolt and wire ever built. One nut is the same as the other nut. All nuts are the same.

In software, not all "nuts" are the same. One persons implementation of a string search can widely vary. Yes, we do have libraries that handle this issue, but there is a higher chance of error in software construction because of the ratio of libraries (third-party) used that are not as robust.

Lastly, one reason why software hasn't been addressed with the same urgency is because of the consequences (or lack of). When a bridge is poorly built, people die. Laws go into affect, companies go out of business, and many people pay the price. When software starts failing, a patch is applied until the next piece of it starts failing when another patch is applied. In the end the software becomes a big piece of patched-up piece of crap.

One advantage, though, of software is that a new version can be released with all the patches in mind and redesigned. :) This certainly has been proved by products like Mozilla that were probably crap when first released but definitely has matured into a solid product (imho).

Re:The two big reasons software is buggy!

[Slak]

The zero-th reason software is buggy is the state of requirements. I've seen so many requirements documents that lack any form of internal consistency.

These issues don't seem to be addressed until the rubber hits the road - when code starts compiling and demos are given. The pressure to market builds, as these issues are being resolved. Unfortunately, that's when The Law of Unintended Consequences strikes, scrapping much of the existing codebase.

How can a programmer make "their own code solid" when the work it is supposed to perform is not clearly defined?

Cheers,
Slak

Re:The two big reasons software is buggy!

[irhtfp]

While I agree with most of what you said, I do see one difference to the "bridge" analogy and that is fault tolerance.

Bridges are built to be extremely fault tolerant. MechEs and CivEs use safety factors - big ones. Multiple bolts must fail before the structure becomes critical. Adding safety factors in mechanical structures is relatively cheap and easy.

In most software, nearly everything is critical in some way due to the logical step-by-step nature of code execution. It's possible to write good fault tolerant software (i.e. w/ exception handlers) but that's one of the first things to suffer under the deadline as it's very expensive. I've never done a study but I would guess that at least 70% of good code writing is designing for all the non-standard cases!

I think software is a bit closer to a chain than it is to a bridge.

Re:The two big reasons software is buggy!

[ojQj]

Exactly.

There are too many Marketing droids talking about the solution they visualize without ever clearly formulating the use case.

A lot of people can make feature suggestions. Without a clear picture of what the user actually wants to accomplish, the feature suggestions can't be evaluated for usefulness, nor can better suggestions be made to solve the user's problem. Varying solutions also can't be compared on their merits. And so it gets down to an "I have more contact with the customer so I must have some magical ability to divine the best solution is for his as-of-yet unspecified task" pissing contest.

If marketing departments would start doing their jobs -- gathering use cases to make requirements out of -- then software development groups would be able to make more high quality feature suggestions and would have more fun implementing them.

Re:The two big reasons software is buggy!

[TigerNut]

Go read some of Henry Petroski's books (their titles escape me right now - there is one that opens with the failure of the hotel skybridge in Kansas City), and you'll see that civil engineering occasionally still has big gaps between the designer's intent and what actually gets screwed together. On the software front, you are correct. Software eventually rots because it is usually "maintained" by continually applying patches as opposed to periodically taking a whole chunk and rewriting it to fit the new extended requirements.

Even when the latter happens, in a lot of cases the overall soundness of the implementation is compromised by the perceived need to maintain backwards compatability (e.g. why does the Borland Builder compiler use the 80386 instruction set by default, when almost any executable you are likely to build with it will be larger than the 386 can support?)

That is exactly the wrong approach

[brokeninside]

To produce bugless software we need to start with software designs that are provably correct and then produce code that is provably in line with the design. Using more objects that more closely model the "real world" is an invitation to producing larger number of bugs as the ambiguity of the real world infects the design and implementation of the program.

Re:That is exactly the wrong approach

[e-Motion]

To produce bugless software we need to start with software designs that are provably correct and then produce code that is provably in line with the design. Using more objects that more closely model the "real world" is an invitation to producing larger number of bugs as the ambiguity of the real world infects the design and implementation of the program.

You're absolutely right. Some people think that turning to the "real world" for guidance a good idea, but I've found that it only confuses things. Nobody knows how to model real-world objects and relationships inside a computer in a way that suits all potential uses of that model. I've found that most discussions about software models for the real world in OO projects tend to degrade into analyzing the structure of various English sentences and considering the plethora of ways that a person _could_ understand a relationship. If there are tons of ways to represent the real world, how is the real world supposed to help produce bug-free software? Why should I believe that the answer lies in the real world instead of the software development process itself?

Re:That is exactly the wrong approach

[Jonboy X]

I'm sorry, but I've heard this argument from software design "purists" one too many times. The term "provably correct" as applied to software *design* is laughable. For software development we have unit tests, which take some effort but are well worth the overhead. The only way to prove that a software design matches real-world requirements is to implement the design, and completely test its interaction withing the domain.

Simply put, the proof is in the pudding. You can cleanly define (and test) the interactions between separate software components, but outside the software, there're just too many variables. The real world presents an infinite number of ways to befuddle your code. It is infinitely detailed, and thus so is the problem domain.

Re:That is exactly the wrong approach

[pokeyburro]

A fair point. The trick is to take a much more principled approach to analyzing real-world entities and relationships. This is the field of formal ontology, a branch of philosophy.

Good ontology modelling software would check assumptions about objects such as "if you remove a man's arm, he is still considered the same man" (in business context, yes) and "a company is the same as the people who work in it" (it's not). Basic stuff; people tend to know it intuitively, but that intuition tends not to make it into software, which causes breakage.

Re:Bug-less Software?

[cubic6]

Well, the trick to "anticipating everything a person will do that will inadvertantly blow up your application" is to keep it as simple as possible, specifically by restricting how the user interacts with the app. If the user can only press one of 3 buttons or put a fixed number of characters into a text box, it's not impossible to code for every possibility. In theory, you could build a complex application from lots of very simple (and easy to test and write) parts interacting in a well-defined manner.

In practice, this almost never happens. Most developers are willing to trade perfect code that'll take four months for mostly-perfect code that will be ready for the deadline.

To sum it all up, a properly designed and written program should never choke on user input. If it doesn't, that means you cut corners somewhere. Don't blame it on the user.

The real world is intuitive?

[richmaine]

So she wants to make software more intuitive and wants to make it more like the real world.

Perhaps she should make up her mind. :-)

Re:Three-choice system of logic

[telstar]

"All that would be required is to select the desired output answer, then map it back to the input state. Bingo! We've now got the right question to ask."

• Who knew Alex Trebek read Slashdot?

Re:Three-choice system of logic

[Sique]

The main problem with ternary computing is that it can be directly mapped onto binary computing. So it doesn't change the set of problems we can attack with computing, it just changes the way. But the conversation between binary and ternary logic can be done automatically.

I know of no class of problems in computer science that can be better addressed by ternary computing than by binary computing. There may be some of them out there. But in general ternary computing doesn't change enough to have an impact.

sounds like the perfect politician

[circletimessquare]

avoiding the obvious while promising the impossible

this is an exercise in wish-fulfillment, in suspending disbelief

writing software with less bugs by making things more intuitive and less hierarchical?

i mean, that's funny!

we're talking about telling machines what to do, that is what software writing is

writing software is an extremely hierarchical exercise, the art is giving people want they want

Speaking of mistakes...

[pokeyburro]

...it also seemed like she misstated Java's approach as a "sandbag architecture" as opposed to a "sandbox architecture". I keep trying to visualize programmers writing more and more Java code to stave off the inevitable surge of bugs....

Orthogonal...

[pottymouth]

"....especially because I've always thought that the principles of fuzzy logic should be exploited far more widely in software engineering. Still, my quest for the answer to Jaron's question seems to yield ideas orthogonal to his own. "

I fear people that talk like this. It makes me wonder if they go home at night and plug themselves into something.....

Being sandbagged by java?

[The Slashdolt]

"The constant security-related problems associated with Microsoft's products are due to its fundamental platform architecture. Java technology, in contrast, enjoys exceptional immunity to viruses because of its sandbag architecture."

I think she means sandbox architecture

...and the wheel turns

[GSVNoFixedAbode]

"and more closely simulate and resemble the real world". Hey, I know! How about a COmmon Business-Oriented Language? We could call it COBOL perhaps.

Jaron Who?

[popo]

No really... does anyone care about Jaron Lanier?

I'd put his contributions to technology right up there with Esther Dyson's.

He's another person who calls himself a "visionary" because the specifics of technological development are far beyond his capacity.

He is, always was, and always will be, a non-player.

Re:Jaron Who?

[DangerSteel]

You need to give the man the respect due him. After all, he has a REALLY low ICQ number !

Workflow/StateMachine

[bigattichouse]

Most of my apps have been moving to a "State Machine" based workflow.. Each item of work or task sits in front of you, and only gives you the necessary choices to move it along... Once the engine is in place, you end up doing these simple "OK, lets build the code to show them enough info to make a choice".. and the idea translates well to automated processes, just pop the next item from the queue and work on it.

I agree, somewhat

[Captain Rotundo]

A lot of the article is common sense. But I have been perturbed by the ease with which a lot of people seen to claim that OO is the end all and be all of everything.

Even on simple project I have sometimes found myself designing to fit into Java's OO and not to fit the problem. Its really a language issue when it comes down to it. I am most comfortable in C, so I start writing a Java app and can feel myself being pulled into squeezing round objects into square holes. You have to then step back and realize whats happening before you go to far. I think this is the main source of "design bugs' from myself either ignoring the strengths of a system (not taking advantage of Java's OO) or trying to squeezing a design that is comfortable without billions of objects into some vast OO system, in effect falling into the weakest parts of a language.

Its probably very similar to the ways people screw up a second spoken language, mis-conjugating verbs and whatnot -using the style they are already most familiar with.

So with that its such ridiculusly common sense to say we need an all incompasing uber-language that is completely intuitive, I jsut would like to see someone do it rather than go on about it.

Why not experiment with added every feature to Java that you feel it lacks to see if you can achieve that? because then you end up with perl :)

Seriously programming languages aren't that way by and large because they have to be designed to fight whatever problems exist that they are created to take care of. It a bit foolish to say we need a language that is perfect for everything, instead you look at what your problems are and develope a language to fight those. Invariably you end up with failings in other areas and the incremental process continues.

Re:I agree, somewhat

[NoOneInParticular]

As someone who's programmed OO-style for a long time now, I can't agree more. The problems with a pure OO-style of programming usually become apparent when you take over a program. OO has really managed to replace the spaghetti code of the days before with a macaroni of little bits of code that work together in a completely intransparent way.

Boy, sometimes I do long for managing a C-based project.

It's in the implementation

[mysterious_mark]

I think the current tools exist to produce code that is way less buggy. For instance much of the industrial code I have seen written in Java poorly uses the OO capabilities of Java, and this in itself causes more bugs and maintainability problems. It seems fairly rare that the existent OO languages and tools are well used at least at the application developer level. So I think the problem is really more with the abililty of developers to use proper and well implemented OO methodology. It also seems as though the design process is flawed in that class designs etc., are often done with a priori with insufficient in depth understanding of the process that is being modelled, this is usually because management insist upon having an immutable design before development starts and often before the problem and proceeses the code is being written for is sufficiently understood. Bottom line is you can hand anyone a scapel, but it doesn't make them a surgeon. Skilled developers with a good understanding of the underlying process they are coding for will produce better qualilty and maintainable code. Because it is developer skill that is the issue, not tools the current race-to-the bottom to off shore all devepment to the lowest bidder and lowest developer skill will inherently produce less maintainable, buggier code. The solution to less buggy code is to use skilled programmers wha really understand and can use the available OO techniques (ie NOT offshore, NOT H1-B etc.). I think it also helps if the developers have some understanding of the field for which they code ie medical, financial etc. When you go with the lowest bidder, you get what you pay for /rant) MM

Re:It's in the implementation

[ratboy666]

"ability of developers to use proper and well implemented OO methodology..class designs...a priori with insufficient in depth..."

The reason is that most developers INSIST that class structure should model the application domain. Even if it doesn't make the slightest lick of sense.

Reason? Because of how OO was taught. Concrete to abstract, keeping in line with a problem domain.
(coloured rectangle->rectangle->shape). This certainly makes teaching easier, but doesn't make for sensible class hierarchies.

OO is separate from a class hierarchy. The only reason we HAVE a hierarchy is to allow code to be reused. Therefore, the proper hierarchy is not a taxonomy, it is the one that leverages the code maximally.

As an example - Where to put a Date class?

Smalltalk classifies a Date as a Magnitude -- things that can be compared. So comparisions can be leveraged (eg. =). If it were NOT there, all comparisions need re-implementation.

Also Character should be a Magnitude as well.
Maybe String, but that's a bit shaky (mixins help, it's comparable, but is a collection of Character).

Where to put a class in the hierarchy should be driven by the principle of minimizing code. *NOT* modelling the real world. If you model the "real world" you are probably in a serious "world of hurt". Also, in this case, the OO "paradigm" isn't going to save you much in the way of coding (will save you debugging, hopefully).

Avoidance of bugs...

Stay away from stupid languages. Insist that optimization is the compiler/computers job. The Rosetta Stone is to ask for a factorial function, *without* specifying any details. Code it in the *most* natural way, and then test it with 10,000!

Now, determine how much breakage has occurred (if any).

The answer to LARGE projects is to write code ONCE, and be able to reuse it in any context that needs the same processing. I don't want to have to code the factorial algorythm for small integers, large integers, and really big integers.

I want the code to accomodate the data-type that is needed. If I sort, and use "" ordering, I want that to work across any datatype.

If I have to re-implement, I lose on the previous work.

Class hierarchies can help structure (look at Smalltalk), but are not often used in this way.

Ratboy.

fluff

[plopez]

Well.. some interesting ideas in there mainly flawed.

1) The concept that software should 'feel' right to the developer. First of all this cannot be formalized in any sense of the word. Secondly even if it could be it is focused on the wrong target, it should feel right to the end user/problem domain experts. More about this in point 2.

2) Software tools should model the real world. Well.. duh. Any time you build software you are modeling a small part of the real world. THe next question is: what part of the real world. The reason that OOP has not progressed farther is that the real world is so complex that you can only build some generic general purpose tools and then have a programmer use those tools to solve a particular subset. So the programmer must first know what the problem domain is and what the tool set is capable of.

3) Programmers should be average. Absolutely not. In order to model the real world a good programmer must be able to retrain in an entire new problem domain in a few months. This is what is missing in may cases, most people do not have that level of flexibility, motivation or intelligence and it is difficult to measure or train this skill.

4) Programmers shouldn't have to know math. Wrong again. Programming IS math. And with out a basic understanding of math a programmer really does not understand what is going on. This is like saying engineers shouldn't need to know physics.

5) The term 'bug' is used very loosely. There are at least 3 levels of bugs out there:
a) Requirements/conceptual bugs. If the requirements are wrong based on misunderstanding you can write great software that is still crap because it does not solve the correct problem. This can only be solved by being a problem domain expert, or relying heavily on experts (a good programmer is humble and realize that this reliance must exist).

b) Design flaws. Such as using the wrong search, bad interface, poor secuirty models. This is where education and experience come in.

c) Implementation bugs, such as fence post errors and referencing null pointer. THis can be largely automated. Jave, Perl and .Net ae eliminating may of those issues.

In short, a bad simplistic article which will probably cause more harm than good.

Would much stronger data types help?

[farnz]

I noticed that she touched on strong typing as an aid to avoiding bugs; would a really strong type system help avoid bugs, or would it just introduce bugs into people's data types?

I ask because I'm currently looking into dependent type systems, which aren't currently practical. However, their claim to fame is that the type system is much more expressive; it is possible to define types like "date" or "mp3" in them, and ensure that wrong data cannot be supplied to functions. As I play though, I get the feeling that if the type system is too powerful, people will just create bugs in types, and we'll not improve by as much as we could do.

expanding the pure object-oriented paradigm

[Anonymous Coward]

expanding the pure object-oriented paradigm

1. WTF does that mean? It's all just buzzwords. Woohoo. Another buzzword engineer. Just what the world needs.

2. Making programmers program in an OO paradigm doesn't stop bugs. So why should "expanding the pure object-oriented paradigm" do anything productive?

But is the real world intuitive?

[G4from128k]

Having watched many people struggle with physics, chemistry, and biology courses, I'm not sure that the real world is all that inituitive. Even in the non-scientific informal world, many people have incorrect intuitive models for how things work. For example, many people think that increasing the setting on the thermostat will make the room warm up faster (vs. warming at a constant rate, but reaching a higher temperature eventually). And my wife still thinks that turning off the TV will disrupt the functioning of the VCR.

Another problem is that the real world is both analog and approximate, while the digital world calls for hard-edged distinctions. In the real world, close-enough is good enough for many physical activities (driving inside the white lines, parking near a destination, cooking food long enough). In contrast, if I am moving or removing files from a file system, I need an algorithm that clearly distinguishes between those in the selection set and those outside it.

I like the idea of intuitive programming, but suspect that computers are grounded in logic and that logic is not an intuitive concept.

"Intuitive" is subjective

[Tablizer]

After many debates and fights over paradigms and languages, it appears that everyone simply thinks differently. The variety is endless. There is no universal model that fits everyone's mind well.

As far as "modeling the real world", my domain tends to deal with intellectual property and "concepts" rather than physical things. Thus, there often is no real world to directly emulate. Thus, the Simula-67 approach, which gave birth to OOP, does not extrapolate very well.

Plus, the real world is often limiting. Many of the existing manual processes have stuff in place to work around real-world limitations that a computer version would not need. It is sometimes said that if automation always tried to model the real world, airplanes would have wings that flap instead of propellers and jets. (Do jets model farting birds?)

For one, it is now possible to search, sort, filter, and group things easily by multiple criteria with computers. Real-world things tend to lack this ability because they can only be in one place at a time (at least above the atomic level). Physical models tend to try to find the One Right Way to group or position rather than take full advantage of virtual, ad-hoc abstractions and grouping offered by databases and indexing systems.

A Programmer's Credo

[Dirtside]

- I accept that humans are fallible, and as long as software is produced by humans, or by anything humans create to produce software for them, the software will have bugs.

- I accept that there is no magic bullet to programming, no simple, easy way to create bug-free software.

- I will not add unrelated features to programs that do something else. A program should concentrate on one thing and one thing only. If I want a program to do something unrelated, I will write a different program.

- I will design the structure of the program, and freeze its feature set, before I begin coding. Once coding has begun, new features will not be added to the design. Only when the program is finished will I think about adding new features to the next version. Anyone who demands new features be added after coding has begun will be savagely beaten.

- A program is only finished when the time and effort it would take to squash the remaining obscure bugs exceeds the value of adding new features... by a factor of at least two.

- If I find that the design of my program creates significant problems down the line, I will not kludge something into place. I will redesign the program.

- I will document everything thoroughly, including the function and intent of all data structures.

- I will wish for a pony, as that will be about as useful as wishing that people would follow the above rules. :)

Tools

[tsanth]

That brings up a very good point: why limit yourself to using one tool for every kind of software development? Just as assembly, C, Perl, and even VB have their uses in programming, industry, and science, there exist programming environments where it'd be useful to deal only with abstractions.

To wit: many of my peers in CS came into CS because they wanted to program--boy, were they in for a rude awakening! It's true: there will always be a need for Lego-builders, but I think that it's useful to have languages specifically targeted toward "Lego builders," and others specifically targeted at "builders who use Legos."

Smalltalk and Ruby have been recommended to me already; perhaps one of those is more along the lines of a language that's more targeted at builders-who-use-Legos?

Ternary Logic is Used in GIS

[subrosas]

A form of ternary logic is used to establish whether two lines/arcs intersect in some GIS implementations. This was introduced several decades ago. Usually its called Fuzzy Tolerance. So actually, ternary logic is useful and in use.

Try NakedObjects: behaviourally completalicious

[MCRocker]

Many of the problems with the currently popular software design antipatterns like MVC are that they throw out all of the advantages of true Object Orientation in their zeal to re-invent the 1970's style data processing in OO languages. The NakedObjects folks have an approach that makes it much easier to code in a truely object oriented fashion. This results in more natural, behaviourly complete, objects that are easier to understand, test and refactor. Although this doesn't solve all of the problems that Livschitz mentions, it definitely mitigates the common problems that developers who use OO languages experience and reduces bugs for some of the same reasons that Livschitz cites because it solves the same problems.

It's 2004, and we've still not cracked this nut

[scorp1us]

I was thinking about the same axact thing the other day. It's 2004, where are our common primatives?

glibc is 'it' but it still gets updates, bug fixes, etc. It is not used on every platform. Yet it gets recreated over and over again.

Then I thought about .Net. Finally any language an interface to any other language's compiled objects. So we're getting closer.

But I think the biggest problem is the lack of software engineering from flow-charting. As mentioned, flowcharts allow us to map out or learn the most complicated software.

I think we can accomplish all she describes inside an OOP language, be it Java or C++ or Python. The master-slave relationship is easily done. The cooler thing that I would like to see more of is the state.

Rather than a process starting off in main(), and ini code run in constructors, each process and object need to have a state associated with it. This state is actually a stack, and not a variable.

my_process {

resister state handler 'begin' as 'init'
resiter state hander 'end' as 'exit'
state change to begin
}

init() {
do_something();
register handler condition (x=1, y=1, z=1) as 'all_are_one'
}

all_are_one() { // special state
state change to 'in_special_case'
do_something_else();

pop state
if (exit_condidtion) exit()
}

exit(){
while (state_stack.length) pop state
}

What I'm tring to do is model the logical process with the execution of code, but in an asyncrounous manner. Sort of like a message pump, but its been extended to take process stages and custom events.

Re:Test for NULL pointers

[MrBlint]

And only declare a symbol once! A number of so called 'engineers' where I work put external function declarations in C source files because they've C&Pd some code and can't be arsed to find for the appropriate header file (or don't know how to change the make file to include it). Worse still are people who call a function without even declaring it at all - because "It only takes int params so there's no neeed". Idiots!

I recently got management to launche a campaign to reduce the number of warnings caused by this sort of idiocy (we get about 5000 from a full rebuild). What do I find now? "#pragma nowarn", etc... give me strength!

Sorry, but I hate Perl

[Anonymous Coward]

I have tried to learn Perl, and I simply do not like it as a programmer. (I do not like it, which is why I choose not to use it, but that doesn't mean that it doesn't work others... if you like it, then great. I don't want to start a flame war)

As a programmer, I prefer C/C++ because things are pretty explicit, ie. you need to define your variables explicitly before you use them, and there is no guessing involved.

However, with Perl, there are so many things that if they aren't present, they are assumed. It is very "hacky" and makes it very hard to read. When things are assumed, to me as a programmer, it just means it creates uncertainty, and this inevitably leads to bugs.

The same goes with most scripting languages, like PHP. I use PHP because it is very easy to use, but it also suffers from similar bugs (ie. being able to use variables before explicitly declaring them, etc).

Like I said, if you love Perl, that's great, and a good Perl programmer will know all this, and will probably make very few bugs, just like a good C programmer will make very few bugs in their code. My point is that for the lesser Perl programmers, it is very easy to write code that is simply horrible.

Re:Sorry, but I hate Perl

[Anonymous Coward]

I felt the same way when I first started learning Perl. After I got to know it then man oh man everything snapped into place. Very fast development.

Not much different than the first time you saw any significantly different programming language.

Although C and C++ are certainly fine languages, to truely become a programming master then you should at least understand the benefits of other systems. Learn a functional language like Erlang or Haskel. Learn Lisp. Learn a very high level scripting language like Perl and/or Python. Learn a 100% pure OO language like Smalltalk.

They all have their own advantages.

Too bad no one has combined the good features into a master programming language. All of the things mentioned in the article are available in certain languages but no one has put them together into something useful.

Re:Sorry, but I hate Perl

[ajs]

Believe me, I understand you completely (other than the pejorative use of the ill-defined term "scripting").

I used to feel the same way after having programmed in C for many years. Some yahoo made me work with Perl, so I treated it like any other language that I had to pick up... and I hated it. It was full of little special cases and everything broke the rules in at least 3 ways. Most languages strove to remain as context-free as possible, but Perl was awash in as much context-senstivity as Larry Wall could mamage to make his C-compiler-stress-test of a tokenizer handle!

So, why am I a staunch Perl advocate many years later?

1. Because I can think in Perl better than any other language
2. Because Perl favors human beings who have to program, not compilers and interpreters that have to parse the code
3. Because I got orders of magnitude more work done in Perl than C, C++, awk, Java, LISP, or any other language I could find.

"However, with Perl, there are so many things that if they aren't present, they are assumed. It is very "hacky" and makes it very hard to read. When things are assumed, to me as a programmer, it just means it creates uncertainty, and this inevitably leads to bugs."

That's the theory... and that's what I was taught in school... It seems to make sense.

And yet, there is this massive body of good code written in Perl. There is also a ton of BAD code written in Perl. Just check out bugzilla if you want to see the worst case scenario.

But then ask yourself... is that Perl's fault any more than bad C++ code (and man I've seen some amazingly bad, impossible to debug C++) C++'s fault? I judge a programming language on the basis of what good programmers can do with it. If you want bondage languages that force bad programs to be minimally debuggable, use Python, but don't expect to be as productive in a language that forces you to think in some particular way about your problem.

Re:Sorry, but I hate Perl

[Rick and Roll]

Master Programming Language??? There are conflicting ideas that prevent this from happening. How are you going to have fast and light on storage UTF-8 when your strings are lists of integers? How are you going to combine the idea of assigning types to variables with having all types be pointers to any type of object? Don't work.

Re:Sorry, but I hate Perl

[undef24]

#!/usr/bin/perl -w
use strict; ..... problem solved.

Re:Sorry, but I hate Perl

[eraserewind]

I judge a programming language on the basis of what good programmers can do with it.

Unfortunately that is the exact opposite of what Software Engineering is all about. Any manager or architect worth his salt will judge a language by what bad programmers can do with it. Relying on having good programmers available is a crazy risk to take :-)

Re:Sorry, but I hate Perl

[jonadab]

> I prefer C/C++ because things are pretty explicit, ie. you need to define
> your variables explicitly before you use them

You can fix this in Perl. Just put the following line at the top of each file:
use strict;

> However, with Perl, there are so many things that if they aren't present,
> they are assumed. It is very "hacky" and makes it very hard to read.

Only when you're very new to the language. Once you've learned it, the
terseness makes it possible to see whole functions -- indeed, whole entire
algorithms -- on the screen at one time in a clear, easy-to-follow layout.
(Pay no attention to my signature; that's that way on purpose, and if you
think C is immune to obfuscation, google for IOCCC sometime.)

Having all that superfluous redundant stuff written out just turns simple
functions that ought to be ten lines (half of that comments) into multi-page
monstrosities that require several minutes to read and understand. Bleah.

If you don't like Perl, try Python. It's more strict about a lot of stuff,
so you might like it better, if you're into that sort of thing. However, it
shares with Perl certain very critical features that every language ought to
have, such as built-in memory management. (No more buffer overflows EVER :-)

Personally, I tried Python, didn't care for it, and went back to Perl.

Re:Sorry, but I hate Perl

[smoking2000]

If you want bondage languages that force bad programs to be minimally debuggable, use Python, but don't expect to be as productive in a language that forces you to think in some particular way about your problem.

I tried to use Python, but perl complained:

Can't locate Python.pm in @INC (@INC contains: /usr/local/lib/perl/5.6.1 /usr/local/share/perl/5.6.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.6.1 /usr/share/perl/5.6.1 /usr/local/lib/site_perl .) at -e line 1. BEGIN failed--compilation aborted at -e line 1.

Re:Sorry, but I hate Perl

[eraserewind]

Did I say I recommended hiring bad programmers? Did all those companies that have ever hired bad programmers deliberately do it?

Sorry, but unless you plan on not growing at all, and not having any turnover of staff, then the profile of your employees will tend towards average over time. A mix, of a few very good, a few more very bad, and a rump of fairly mediocre programmers.

That's why startups are so attractive for many people. There is a somewhat better chance of having a high %age of great programmers, and doing some innovative work in powerful languages. All other companies have to deal with the unfortunate reality that most of their programmers do not fall into the excellent category, and have to plan accordingly.

Or do you have some incredible HR process not thought of by any other company in existance that ensures everyone hired by you will be excellent?

Why's it so difficult? Duh...

[Cereal Box]

Why is it so difficult, if not impossible, to write bug-free programs that contain more than 20 to 30 million lines of code?

Maybe because the programs contain 20 to 30 million lines of code.

Look, I understand that a lot of people are yearning for the good old days when software was less buggy. You know what? I suppose that if your entire application consists of something like 4000 assembly code instructions, you might just be able to make the program bug-free.

But it's not 1983 anymore and programs are on the order of millions of lines of code. Of course it's not feasible to go over the entire program manually and root out every single bug. The stuff I work with every day is considered extremely small and yet it depends on all sorts of external libraries, each of which may have dependencies, etc. It all adds up to amazingly large amounts of code. But, it requires large amounts of code to do extremely complicated things. Is this a surprise to her or something? I don't think there's any "paradigm shift" in the field of programming that's going to change the fact that:

* Doing complicated things requires lots of code.
* The more code you write, the higher the chance of bugs.

I reiterate: duh...

Budgets and schedules

[richieb]

She says:

It is widely known that few significant development projects, if any, finish successfully, on time, and within budget.

What bothers me about statements like this, is that no one is suggesting that perhaps our estimation and budgeting methods are off.

What if someone scheduled one week and allocate $100 for design and construction of a skyscraper, and when the engineers failed to deliver, who should be blamed? The engineers?!

Re:Budgets and schedules

[dutky]

richieb wrote

She says:

It is widely known that few significant development projects, if any, finish successfully, on time, and within budget.

What bothers me about statements like this, is that no one is suggesting that perhaps our estimation and budgeting methods are off.

What if someone scheduled one week and allocate $100 for design and construction of a skyscraper, and when the engineers failed to deliver, who should be blamed? The engineers?!

First, there are lots of folks who have been saying, for a long time, that our estimation and budgeting methods are inadequate: Fred Brooks and Tom DeMarco are just two of the best known advocates of this position. It seems, unfortunately, that it is not a message that many folk like to hear. It is, I guess, easier (and more expedient) to blame the tools or the craftspeople than to figure out what really went wrong.

Second, your example would be more apt if the building materials (steel and concrete) or the blueprints and construction tools were being blamed for cost overruns and schedule slips. No one would suggest that building skyscrapers would be easier and more reliable if the bricks and jackhammers were more intuitive.

What she is saying smacks of silver bullets (see Fred Brooks Mythical Man-Month, chapter 16: No Silver Bullets - Essence and Accident in Software Engineering (and succeeding chapters in the 20th Anniversary Edition)) and just can't be taken seriously. To summarize Brooks:

There is simply no way to take the programming and software engineering tasks and make them easy: they are difficult by their very essence, not by the accident of what tools we use.

While we may be able to devise languages and environments that make the creation of quality software by talented experts easier, we will never be able to make the creation of quality software easy and certain when undertaken by talentless hacks, amatures and diletants. Unfortunately, the later is what is desired by most by managers, becuase it would mean that the cost of labor could be greatly reduced (by hiring cheaper or fewer warm bodies). It also happens to be the largest market, at least in the past two decades, for new development tools: think of the target markets for VisualBASIC, dBASE IV, Hypercard and most spreadsheets.

Is software engineering a form of engineering?

[brokeninside]

If I follow your train of thought to its natural conclusions, I should arrive at the idea that when building a bridge, it is not necessary to prove that the finished construction will be able to withstand the load that it bears. Would you agree with that assessment?

As for cost, given the high rate of failure in the current system and the astronomical costs of bugs in current software products, I don't think that cost considerations support your argument.

Further, virtually every software text in existence states that more time spent in design reduces defects and yet very few projects spend sufficient time in the design state. Proper design is currently the path not chosen, so its costs are unknown. One cannot reasonably argue that an unknown cost is higher than a known cost prior to the unknown cost being known.

Lastly, your request for a proof exemplifies my point. You cannot offer such a proof and that is why Apache has to be patched. If Apache had been properly designed and constructed from the beginning, the only updates to Apache would be for new features. The cost of all the bugfixing that has gone into Apache over the years was unnecessary.

Unfortunately, computer science is still in its relative infancy. It is currently more akin to a skilled trade than a science. Also, our system of education (at least in the US) is geared toward producing artisans of computers rather than computer scientists. One hopes that this will continue to change over time.

Re:Is software engineering a form of engineering?

[richieb]

If I follow your train of thought to its natural conclusions, I should arrive at the idea that when building a bridge, it is not necessary to prove that the finished construction will be able to withstand the load that it bears. Would you agree with that assessment?

No. But you can only use the science you know to help you proving that the thing will stand up. Furthermore, spec for briges tend to be pretty clear.

In any case, if you look into history of bridge building you'll find that for the longest time the formula for the strength of cantilever beam was wrong (this guy Galileo got it wrong). So when the engineers building bridges reduced the safety factor (to speed up construction and reduce cost) bridges started falling down.

In 19th centuary England a lot of iron bridges collapsed, despite the fact that it was "proved" that they were strong enough. Metal fatigue was not understood then.

Lastly, your request for a proof exemplifies my point. You cannot offer such a proof and that is why Apache has to be patched.

Why not? At least you have a spec for a HTTP protocol, which is pretty precise as such spec go. If you cannot offer a proof in the case where a precise spec exists, what hope is there for other software?

Finally at most you can prove with a program that the program works according to its specification. But what about the correctness of the specification itself?

Unfortunately, computer science is still in its relative infancy

Exactly. But what we are talking about is software engineering. Engineers are paid to build things that work. They are free to use whatever helps them in their tasks, if there is good science they use it. If there is no science they have to hack.

Try telling your next customer that implementing his system will take 50 years, because the science of translating his imprecise requirements into software hasn't been invented yet.

Re:Is software engineering a form of engineering?

[richieb]

Yes it is a lot of paperwork, but then another reason why bridges in the 19th century fell down was to do with the fact that the materials being used were not being monitored correctly.

But there was a good reason. At that time we didn't know what to monitor for, never mind that tools to find the problems did not exist (eg. X-rays).

But the bottom line is that bridges had to be build - without the knowledge of materials we have today.

Agreed, but for this reason...

[DumbSwede]

I write bug free code, but then put in a bug or two that only I know about, so as not to be an affront to the glory and perfection of Allah.

Re:Three-choice system of logic

[GeckoX]

I don't believe I've advocated anything in my posts...I was continuing a thought process.

Actually, the very fact that we live in a binary world kinda makes your post redundant, we ended up here for a reason. However, does that mean we are not allowed to think outside of this paradigm? Can we not discuss things like this? Or shall we stay confined to our little box at all times?

Test-Driven Development

[spikeham]

I have been a software developer for more than 15 years. Currently employed as a Senior Software Engineer.

I've only come across one way to write code that is close to bug-free: Test-Driven Development (TDD.)

In TDD, you never write a line of code unless there is a unit test in place to check the results.

I have seen very complex systems get built from scratch with virtually no bugs when TDD is followed.

There are lots of online resources about TDD. It is one of the foundations of XP (Extreme Programming.)

Mod parent up!

[PatSmarty]

Great point! I wondered about this, too. Could anybody with more knowledge comment?

• I've got some ideas about making software less buggy and faster+easier to program. If somebody reads this, maybe he could comment?
  
  - A lot of time is spent trying to get the syntax right. By moving software development away from pure-text writing and towards a more humane form (like dragging widgets together), the head could be freed up so that we don't have to think about adding ; at every line end and focus more on the problem.
  - The form of source code (text) today doesn't reflect the complexity of the problem behind it. Surely there are tools that overcome some of these problems, but since they still work on the basis of a text document, they are error prone and won't free our heads. A good example for this is CVS: it compares *lines*, but it should compare the syntax - so it sees differences where there are none.
  
  I feel that programming is held back in the era of the "command line" while all other fields have long moved to some sort of GUI.
  
  I've got a list of dozens of ways to improve programming and making it humane without changing the syntax/language... does anybody know if there is research / finished products in this field? What have others already tried out?
  
  Thank you for any suggestions!

Re:Mod parent up!

[Greyfox]

Eventually the syntax becomes instinctive(ish).

IDEs hide what's really going on in the development process. Once you learn your environment, the command line is still the fastest and the easiest to isolate build problems in.

The problem, as I see it, as a lot of programmers don't want to have to understand how to program or the problem that they're coding to, becuase that's hard. Understand what's going on, write higher quality code. That's all there is to it.

Now if we were talking about Joe Sixpack banging together an application to track his baseball cards and not some professional IT developer, I could see a less complex environment being useful to him. I was banging out dbase III procedures for my dad's office back when I was a boy, and it didn't have to be the most complex environment in the world for them to get their job done. They still had a solid idea of what they wanted the machine to do though. They just gave me the requirements, I implemented them, presented them them and let them come back with changes until we had a report they liked.

Controversial claims

[Tablizer]

There are some controversial claims being made in that article:

The preventive measures attempt to ensure that bugs are not possible in the first place. A lot of progress has been made in the last twenty years along these lines. Such programming practices as strong typing that allows compile-time assignment safety checking, garbage collectors that automatically manage memory, and exception mechanisms that trap and propagate errors in traceable and recoverable matter do make programming safer.

Fans of "dynamic" languages will surely balk. There is no evidence that strong/static typing makes programmers more productive or reduces total errors. Static/strong typing is not a free lunch: it adds more formality to the code, making it larger, and more code often means more bugs, partly due to slowing the reading of code. ("Static" typing and "strong" typing are generally different concepts, but tend to go hand-in-hand in practice.) There are also nifty things that can be done with dynamic evaluation that are hard or code-intensive to emulate with compiled languages. Often the same Java program rewritten in Python is 1/3 the size.

However, it is sometimes said that the best programmers are best with dynamic languages and mediocre-ones best with strong/static typing.

Further, some feel Java's error handling mechanisms are unnecessarily complex and "glorified goto's" or "glorified IF statements".

In regard to recovery, I can't think of a recent technological breakthrough. Polymorphism and inheritance help developers write new classes without affecting the rest of the program.

It appears to be a trade-off. Polymorphism and inheritance assume a certain "shape" to future changes. If the future fits those change patterns, then change effort and scope is smaller. However, many feel that such change patterns are artificial or limited to certain domains. For example, adding new operations to multiple "subtypes" often requires more "visit points" under polymorphism. It would be a single new function in a procedural version, and other code need not be touched. It is the classic "verb changes" versus "noun changes" fight that always breaks out when OO and procedural fans meet and fight over code being more "change friendly".

Object-oriented programming allowed developers to create industrial software that is far more complex than what functional programming allowed.

I think she means "procedural", not "functional". But there is no evidence that either is the case. There is no evidence that well-done procedural (usually with a RDBMS) systems are more buggy or costly than OO. Management satisfaction surveys by Ed Yourdon put them pretty much even.

Let's not Ignore the Livschitz.

[barryfandango]

"Livschitz grew up in Lithuania, where she was the women's chess champion and a National Chess Master in 1988 -- the same year in which she won the prestigious Russian national junior mathematical competition."

She's the real story here. I think I'm in love.

Try Objective-C maybe?

[Paradox]

There is a language like that. In fact, both C++ and Java borrowed several ideas from it. It's called Smalltalk. :) In Smalltalk, everything is an object. Objects talk to each other via methods. Smalltalk has a limited form of closures, can handle exceptions, and has double-dispatch.

As languages go, it's pretty awesome. It was well ahead of its time, anyways. Ruby (as another poster mentioned) also does some of this.

Smalltalk and Ruby are great if you're just working with components and assembling them lego style, sure. But what'd be really nice is to use a language that can do both high level coding and systems programming. Someone else thought of it. Brad Cox came up with Objective-C, which NeXT later expanded upon.

Apple is using Objective-C with the old OpenStep library as their primary development environment for awhile now. It's very nice, supports a lot of full features, has explicit memory management that is very flexible but also circumventable and tunable (using reference counting, but people have made mark-and-sweep extensions, both are not implicit like java though).

Objective-C supports late binding, weak typing, strong typing, static typing and dynamic typing, all in the same program. It can directly use C, so if you know C you're already 3/4 of the way there. The message syntax is slightly odd, but works out. Unfortunately, Objective-C doesn't have closures. David Stes developed a meta-compiler that turns Objective-C with closures into regular C (called the Portable Object Compiler) which might get you some distance if your work demands them.

ObjC can either use C-style functions, smalltalk style message passing, or a hybrid of both. It's a very interesting language. Apple added C++ extensions, so now in most cases you can even use C++ code (however C++ classes are not quite ObjC classes, and there are some caveats).

If you're looking for a language that splits the difference between Ruby/Python and C/C++, Objective-C might be your best bet. It's pretty hard to find an easy-to-use language that also provides a lot of performance.

Re:Try Objective-C maybe?

[Paradox]

People still use smalltalk. I wouldn't say that in this current world Pascal is much more popular than Smalltalk, although you could argue more lines are in deployment.

When you get down to it, the concepts pioneered by Smalltalk are still ahead of their time. How can I say such a thing? Well, watch our modern languages evovle. People keep taking stuff from Smalltalk, and languages are slowly glomming on more and more parts of it. Of course, the same could be said of CLOS. This is the path to language elitism, which no language currently deserves.

A safer statement to make is that the concepts these languages used were advanced, although the particular instance might not have been.

People don't keep digging up these languages out of pure stubborness. They keep turning back to them because they were good ideas, and they worked well.

objects, conditions, and processes

[ahdeoz]

Oh my! In going beyond Object Oriented Programming, she has managed to re-invent constructs that OOP was meant to replace. Subroutines, and even lowly "if" statements have a place in programming. And what's more, they need to be constructs even more heavyweight than objects. Sun really is trying to sell hardware! I can't wait for the next advanced programming abstraction of registers and gates. I'm sure there will be a market for distributed, clustered, logic servers, and several competing (standard) XML schemas for ANDsm OSs, XORs, NOTs, and MAYBENOTs. I can't wait for version 1.5, where goto jumps will be implemented via Inversion of Control in an Aspect Oriented Framework! Seriously, what bugs

The goal is not bugless, but good enough, software

[BrittPark]

Because of human nature and because of the extreme complexity of the ideas we attempt to encapsulate in non-trivial software, buglessness is not an achievable goal, regardless of the methodology of the day. The interviewee seems to think that there is some magic bullet waiting (in new tools or methodologies I guess). This shows a fundamental rift between her and reality, and makes her opinions fundamentally suspect.

The goal in any real software project is to meet customer's (and I use that in the broadest sense) expectations adequately. What is adequate? That depends on the software. A user of a word processor for instance is likely to not mind a handful of UI bugs or an occasional crash. A sales organization is going to expect 24/7 performance from their Sales Automation Software.

The canny programmer (or programming group) should aim herself to produce software that is "good enough" for the target audience, with, perhaps, a little extra for safety's sake (and programmer pride).

Of course their are real differences among the tools and methodologies used in getting the most "enough" per programmer hour. Among the one's I've come to believe are:

1. Use the most obvious implementation of any module unless performance requirements prohibit.

2. Have regular code-reviews, preferably before every check-in. I've been amazed at how this simple policy reduces the initial bug load of code. Having to explain one's code to another programmer has a very salutary effect on code quality.

3. Hire a small number of first class programmers rather than a larger number of lesser programmers. In my experience 10% of the programmers tend to do 90% of the useful work in large software projects.

4. Try to get the technical staff doing as much programming as possible. Don't bog them down with micromanagement, frequent meetings, complex coding conventions, arbitrary documentation rules, and anything else that slows them down.

5. Test, test, test!

A good idea

[namidim]

I think that the author makes some very good points about the high-level problems of OOP and I think the same also applies to AOP (aspect oriented programming). Both approaches force you to take a design that consists of many different, well understood paradigms and then force it into a language that supports only one or two of them. AOP gets people excited because it means you have two paradigms to work with instead of one. This is great, but it misses the point. We should be putting a whole set of different design paradigms into the next generation of languages not just (last language)+1 of them.
I think part of the reason that this broader problem is not fully realized is that you don't run into it until you have to update existing code with essentially new features and even then hindsight is 20/20. It shows up there because you have to now take the constrained language, look at it in terms of the many design paradigms you started with, add a new one, and then squish it all back in again. The result of this process may be very close to what you had before (this is when it's easy) or may be very different(this is often when we see a group scrap it all). Unfortunately it's all to easy to just say "well if I'd implemented it THIS way then the change would have been small" which ends up being almost as helpful as realizing you should have played the OTHER lottery number.
The other reason I think we don't see any movement in this direction is that, much as with functional programming before it, once you have spent the last 5,10,50 years thinking of everything in terms of OOP it is very hard to see where it's letting you down.

Re:Test for NULL pointers

[dasmegabyte]

Actually, from what I remember from my Java larnin' days, there was a big fight at Sun over the + operator and strings. It was left in for convenience. Personally, I never use it, not even in .NET, because it implies an activity that isn't going on, that is to say it implies you're APPENDING string A to string B.

Since strings are immutable, it's actually creating a new string based on the content of strings a and b. So

String newString = "this" + " language " + "sucks";

is actually

StringBuffer sb = new StringBuffer("this".length + " language ".length + "sucks".length); sb.Append("this"); sb.Apprend(" language "); sb.Append("sucks"); String newString = sb.toString(); sb = null;

.

A lot of bloat just for plus sign. eh? The first thing you learn when tuning Java is to avoid using that + sign at all costs. It's only there for learners. .NET has an even cooler functionality in its Formatter classes...

String.Format("{0} {1} {2}", "this", "language", "rocks");

...cooler, because it's fairly efficient and has functionality to reformat popularly displayed datatypes (dates, numbers, etc). Sort of like iostreams, only at a higher level of programming.

Re:Three-choice system of logic

[dasmegabyte]

Eckel's Design Principle #1: Don't be astonishing.

I find True, False or Maybe to be fairly astonishing. Does maybe mean quit? Does it mean give me more options? Does it mean the same as True or False (it would if my wife coded it, oh!)?

All the third option gives us is more questions. Which defeats Echel's sixth principle: Simplicity before generality.

Star Trek

[Unnngh!]

When I see something like this, I am inevitably reminded of Star Trek. Their computers just work. They don't have problems unless they are acted upon by some outside force, generally resulting in physical damage. They are intuitive for the users.

Even the tech gurus on Star Trek can reprogram most computer problems in minutes, or at the outside, in a day or two. This would appear to be functional programming, as mentioned earlier in the article. I've never heard Jordi complain about referencing a null pointer anywhere.

In short, the answer is Star Trek. Sun, Microsoft, IBM, and the rest just needs to get off their asses and deliver whatever programming language was used on the Enterprise! Damn the bureaucrats, damn them all!

Old ideas....

[FoFi]

I couldn't stop thinking of existing theories and/or implementations of her ideas...

Modeling processes out of the OO paradigm (opposite to what Design patterns started to sacralize for example) is precisly the subjet of so-called business rules. But BR people are close to relationnal model of data, that is too quickly assimilated with SQL DBMS(*), so OO oriented people don't buy it (see the almighty impedance mismatch).

Data-structures other than trees and collections are already genericaly implementable in any modern OO language. See Eiffel for example which can perfectly do that for 15 years (parametric classes, with full type safety). May be the java generics will help to build highly reusable data structure... I doubt that, anchored type is missing (ie the possibility to declare the type of a variable as equal to another type, nearly mandatory when dealing with inheritance of generics).

Tom.

(*) I warmly recommend the writings of Chris Date and Fabian Pascal to really see how the relationnal model of data is different from SQL databases...see DBDebunk for references.

Bugless code!?!?

[marco0009]

There is truly no such thing as bugless software. No matter how well or how stupid proof a program is coded, a user will find some way to do something to it which was not intended. If they keep this up, eventually it will cause something to go wrong in your program.
Even if, by some miracle, all programs were immune to user errors, there are infinitly many hardware/OS/software combinations that some conflict with code will eventually surface. IMO, this ideal of bugless code is just that, an ideal.

The lost art of modelling.

[ninejaguar]

From the post:
"software should more closely simulate the real world"

From the article: "It's not the prevention of bugs but the recovery -- the ability to gracefully exterminate them -- that counts."

While the need to gracefully recover your design from bugs (bugs come from design, or lack of, not code) is laudable. The proper technique is to design without bugs in the first place. Assuming that you're actually meeting the business requirements or functional specifications, there is a straightforward method to flattening bugs before they become fruitfully overripe and multiply.

Once you have obtained the proper requirements (your goals), and after you've properly atomized it to its smallest component parts, you need to model those parts. Once you've modeled those parts, you need to test the model. This works in single process design, but it really shines in concurrency where anyone can truly screw up.

Get a good book on design. Then get a good book on modelling, mechanically analyzing, and testing those designed processes before commiting to code.

= 9J =

halting problem means prefect code isn't possible

[swframe]

If you can't determine if an arbirary program halts on arbirary input then you can't tell if that program has a bug.
If want a language without bugs, you have to use a language that does not interesting problems.

Your describing why I dont want to be a programmer

[T-Ranger]

Anyone can call themselves a programmer, or even a software engineer. Someone who graduates from a BCS program is required[1] to do zero practical work in the field before they get their degree - which is the height of their qualifications.

Engineers may graduate, but they require at least a few years of work before they can be licensed. Lawyers have to pass tests beyond those based in the fantasy world of academia. Medical doctors require years of on the job training under close supervision before they are turned loose. All of these professions are self-governed and discipline their members if - nay, when - one of them screws up. Potentially they can loose their license.

The IT world has no such professional designation. The IT world has no such self-governing body. Given companies/individuals in the IT world can consistently produce almost criminally negligent code, and provided they bid low, will survive.

MDs, PEngs (and even lawyers) can always refuse to do something if it is clearly dangerous, unsafe, or illegal. Their clients cant really go anywhere else to get that task done as all professionals will be bound by the same rules.

Even trades: plumbers, carpenters, electricians, pipe fitters..... have some non-academic certification process. Most, beyond a (say) two year school program have to have years of apprentice work before they can be qualified. They are required by law to build things to some safety standard, building code, electrical code, fire code....

Anyone can call themselves a programmer.

The closest thing that the IT world has is various certs from for-profit companies. But they are generally for variations on systems administration, rather then programming. While, so far as I know, they cant be revoked for cause, they do all expire after some finite time.

What the IT world needs is the equivalent of a PEng professional 'grade' designation for, ie 4 year BCS level of schooled people. And also a trades grade designation for 2 year community collage types. Implicitly from there you get higher quality product, because the people designing the product (PEng grade types), and the people implementing it (trade grade type) have higher obligations then just to the customer. They would have professional responsibilities, violation of which could cause them to loose their respective licenses. This would solve most of the bugs caused by cutting corners to save on cost, releasing before its done, etc. By no means all, but a lot.

[1] yes, some schools have Co-Op programs. But I know of none that are requirements.

Types of bugs and how to prevent them

[Dominic_Mazzoni]

The article doesn't seem to address all of the different types of bugs, nor how to best address them. Anyone care to add to or refine this list?

1. Algorithmic bugs - you have a function with well-defined input and output, and it does the wrong thing (may include giving the wrong answer, looping forever, leaking memory, or taking too long to return). Can be avoided with a combination of code review, unit tests, and correctness proofs when possible.
2. Interface bugs - this includes validating input, both from the user and over the network or other ways in which your program gets input data. These bugs include buffer overruns, GUI bugs caused by an unanticipated sequence of clicks, etc. These bugs are mostly found by testing, but sometimes also with automatic code checkers or memory debuggers that highlight potential problems.
3. Bugs in the operating system or in sublibraries - any large project depends on large volumes of operating system code and usually lots of other libraries. These systems almost certainly have bugs or at the very least undocumented or inconsistent behavior. The only way to avoid this is to validate all OS responses and do lots of testing.
4. Cross-platform bugs - a program could work perfectly on one system, but not on another. Best way to address this is to abstract all of the parts of your program that are specific to the environment, but mostly this just requires lots of testing and porting.
5. Complexity bugs - bugs that start to appear when a program or part of a program gets too complicated, such that changing any one piece causes so many unintended side-effects that it becomes impossible to keep track of them. This is one of the few areas where good object-oriented design will probably help.
6. Poor specifications - these are not even necessarily bugs, just cases where a program doesn't behave as expected because the specifications were wrong or ambiguous. The way to avoid this is to make sure that the specifications are always clear. Resolve any potential ambiguities in the specs before finishing the code.

My overall feeling is that there are so many different types of bugs in a real-world programming project, and any one technique (like object-oriented design) only helps address one type of bug.

Re:The secret to bug free code...

[HD Webdev]

is to _test_ your code.

...against the business requirements.

True. It's always going to be some sort of combination of 'need it yesterday', 'soon', 'works pretty good', or 'handles fatal exceptions exceptionally well'.

OO is a one hit wonder

[waveman]

OO has one paradigm which is make everything objects. This is absurd.

If you look through the Java libraries there are numerous examples where things are stretched to make them objects. You see the same thing in Java applications.

Example: colors. Is a color an object or an attribute of a point on a surface? Apart from anything else Java having colors as objects means you have to create millions of objects or build a color object cache if you have large numbers of colors.

Example: bignum. A number is a stage in a computation not an object. Again, tons of garbage and impossibly slow code.

I agree with the lady that we need extra concepts but I disagree that we need a fixed set of concepts hard wired into the language. We need a powerful enough language where you can add concepts that you need.

Just as OO was added to Lisp without changing the base language, so can other concepts. Try that in Java.

Java is better than the original 3GLs like Fortran 58 and COBOL 60 but not by an order of magnitude.

Computer Aided Programming

[thinkerdreamer]

Programming is littered with complexities for there not to be bugs. You have to define something just right and not misspell anything or put something just "so" or there is a bug. I know there is a reason for all these things. But in the future I see Computer Aided Programming (CAP). The processing power of the PC will be used so that the computer will know what you are programming while you are programming it. The Artificial Intelligence will make suggestions and even write some of the code for you. The AI will keep you from making disasterous mistakes by analyzing every bit of recent code in comparison with all past code looking for conflicts. He will even suggest that you put something just "so" or not do it. The AI in essence will be your companion, debugging as you go. This will produce huge programming projects with no bugs whatsoever.

Intuition or Cumulative Knowledge databases?

[fractaltiger]

I like the idea of intuitive programming, but suspect that computers are grounded in logic and that logic is not an intuitive concept.

Slightly OT:
This is indeed hitting the nail on the head. My father and I have lots of disagreement on the issue of "common sense." I am very smart and he is so too, but tends to fall behind when it comes to explaining ... or rather, just ACCEPTING unknowns and their repercussion in logic. Say, If I withhold a fact in an argument but claim to be "right," he will say there is just NO way of winning the argument --and then I produce the "new evidence." He sometimes recoils thinking his logic models cannot be blown away by my (normal logic + hidden evidence).

Whenever he says that I should know something because it's intuitive, I bring up example after example of why he's mistaken to expect all logical conclusions to be == to his. We saw a lady in a TV contest who had to see words hidden behind her husband and make him guess the , through signs and gestures she made for him. She stumbled upon "otorrino," (this TV show is in spanish) which is short for otolaringologyst, and said that she didn't know the word. Well, I won't get into more complex translation details. Suffice to say that she didn't know what it was and had to skip to the next thing. My father was outraged:

1. She speaks 7 languages.
   
2. The word is pretty simple latin and her 7 languages MUST therefore encompass latin.
   
3. Young children and thus, anyone raising them, should be familiar with this doctor because he deals with "ubiquitous" eye problems, ear infections and nose issues.
   
4. Besides being familiar with the doctor, must know the exact name of the doctorate which is literally "ottorhinolaryngologyst."
   
5. Her job in Europe is with a law firm TRANSLATING legal documents.
   
6. Any hispanic woman speaking 7 languages must have gone through enough 'education' to have seen the word, if she cannot derive it from latin
   
7. Only my father, by (5) can decide whether you should or shouldn't KNOW a word, concept or whatever, just based on your "expected" life experience

I asked my dad why he rationalizes which concepts she SHOULD know rather than why she just DIDN'T know what he's 100% sure she already grasps. Moreover, he's always too shocked to see through his own failure at accepting that common sense doesn't exist, and instead trying to verbally fix something that is has proven false before his own eyes. But some people think they already know what is and isn't IMPOSSIBLE.

I can list three other languages besides english and spanish that I can understand, so I speak 5 languages, right? No. This is an example of misinformation and generalization: If she says she speaks 7, it doesn't mean her job has made her command them all --even if you 'knew' as many languages as the Pope and had to work in New York City's linguistic melting pot, you will never exert more than 3 language roles in your official capacity, and your "other 4 languages" will be pet languages, specially if you're only 35. But sometimes dad waves off my facts as crazy talk of today's young and naive offspring. Too bad. Sometimes he's surprised at how lucky I am when my "wrong logic" can get him so many nice surprises when his ways should be the only solution to my "poor common sense." You can tell I deal with control freak parents eh?

Great slashdot discussion

[master_p]

This slashdot discussion about software engineering is one the best I've ever read. It should be almost mantatory for students of computing to study. Lot's of posters have raised very significant points about why it seems impossible to write bugless software.

Let me add my 2 cents: the problem is that computer programs represent the 'how' instead of 'what'. In other words, a program is a series of commands that describes how things are done, instead of describing what is to be done. A direct consequence of this is that they are allowed manipulate state in a manner that makes complexity skyrocket.

What did object orientation really do for humans ? it forced them to reduce management of state...it minimized the domain that a certain set of operations can address. Before OO, there was structured programming: people were not disciplined (or good) enough to define domains that are 100% indepentent of each other...there was a high degree of interdepentencies between various parts of a program. As the application got larger, the complexity reached a state that it was unmanagable.

All todays tools are about reducing state management. For example, garbage collection is there to reduce memory management: memory is at a specific state at each given point in time, and in manual memory management systems, the handling of this state is left to the programmer.

But there is no real progress in the computing field! both OO, garbage collection, aspect oriented programming and all other conventional programming techniques are about reducing management of state; in other words, they help answer the 'how' question, but not the 'what' question.

Here is an example of 'how' vs 'what': a form that takes input and stores in a database. The 'what' is that 'we need to input the person's first name, last name, e-mail address, user name and password'. The 'how' is that 'we need a textbox there, a label there, a combobox there, a database connection, etc'. If we simply answered 'what' instead of 'how', there would be no bug!!! instead, by directly manipulating the state, we introduce state dependencies that are the cause of bugs.

Functional programming languages claim to have solved this problem, but they are not widely used, because their syntax is weird for the average programmer (their designers want to keep it as close to mathematics as ever), they are interpreted, etc. The average person that wants to program does not have a clue, the society goes away from mathematics day by day, so functional languages are not used.

The posted article of course sidesteps all these issues and keeps mumbling about 'intuitive programming' without actually giving any hint towards a solution.

For bug-free code, look at home building

[dmhayden]

To see how software development could be made less bug-prone, all you have to do is look at a more mature industry. Take home-building for example.

First of all, homes are build from standard components. Lots of standard components. If software development, if you want a linked list, you have, at most, a handful of choices. When building a home, if you want a nail, you have dozens or hundreds of choices. There are roofing nails, framing nails, finish nails, decking nails, galvanized nails, nails with ribs, nails with spiral grooves and all available in a variety of sizes.

The point is, if you need a nail, you can walk into home depot and get *exactly* the nail that you want. In software, you have to make do with what's available.

You could argue that one can create whatever custom list behavior is needed from the building blocks available. That's true. You can also make whatever nail you want from steal wire. But we don't do that because it's error prone and you might not get exactly the right kind of nail necessary for the job. It's better to get one off the shelf because you can be pretty sure that someone has thought of all the issues related to the problem it's designed to solve and taken care of them.

Next, look at who builds a home and compare it to who builds software. If we build houses the way we build software, you'd bring 150 people to the job site and say "you there, do the framing; you over there, you're on plumbing; you two in the back have electrical work. After all, builders are builders, right? Of course not. There are specialized skills involved in each step and you need the expertise to do them. You wouldn't want your plumber doing the roof work any more than you'd want an excavator doing the plumbing. To build a complex system, you need lots of people with very specific skills.

Standards and interfaces. So how is it that you can walk into Sears and buy a blender that interfaces so perfectly with the electricity in your house? Because there are standards, of course. The standards specify the voltage and frequency on the line, the exact shape of the plug that you use, how long the cord should be, what sort of insulation it has and probably a lot of other stuff. Software systems need the same sort of standardized interfaces for their basic properties. We've started this with things like constructors, destructors and I/O operators.

Basically, I see software development as a very young science. As the standards evolve, the quality and reliability will grow also.

"Good" and "bad" programmers

[Anonymous Brave Guy]

As with many (all?) other skills, I think two things probably dominate developer ability:

• Developer potential follows a curve, starting with many people having little or no aptitude for programming, and tailing off with few programmers being able to be Really, Really Good. Most people at the bottom end don't work as developers, or don't get hired much.
• How close any given developer gets to his maximum potential is a combination of attitude and exposure to opportunities to learn.

Please note the key distinction there: one of these factors relates to a developer's potential, the other to what he can actually achieve in reality.

To determine a good strategy for building a team of developers, you then have to consider the relative work rates of developers of different abilities, and the nature of the work. For example, most code is developed from relatively straightforward design and programming tasks, but often you have small areas that require much more skill to design and implement effectively. These areas require a more able developer/team, but OTOH we also know that such people can be anything up to 10x as productive as a "typical" developer on the more mundane work. Of course, employing such people also costs rather more.

So what does this suggest about our choice of programming language? Well, if your development task is going to require any complex design or implementation work, you're going to need a sufficient number of top end people to do it, and you're going to need suitably powerful and flexible tools to help them.

For the remainder of the work, highly skilled developers will still be happy using those powerful, flexible tools, but they may be in short supply, and chances are most of your team will be more average in ability, and thus more average in their ability to avoid mistakes. Thus you may need a tool that reduces the possibility or impact of those mistakes, even at the expense of some power and flexibility (which those developers will rarely if ever use anyway).

Strangely enough, this has always been one of the reasons I've liked C++ as a practical, real-world language. While it has plenty of theoretical flaws, it does combine both raw power and flexibility with a decent set of abstraction tools to keep routine development away from the most dangerous areas. You can have your top developers write subsystems using all the cunning tricks they need, but keep everyone else using only clearly defined interfaces. Given a little basic training (sadly a lacking commodity in the C++ programming world, but not beyond any competent manager to arrange -- this is the second factor above) the vast majority of "typical" developers can avoid the really dangerous programming practices, and take advantage of the neat stuff the top guys made for them. When those top guys have finished developing really neat stuff, they can just become super-efficient people doing the mundane stuff using the same tool.

Bottom line: for most real world projects, you need to judge a language by both what it's capable of when used by a really good guy and how well it looks after Joe Developer. If one language isn't enough to do both and your project needs them, maybe you need more than one language and some good glue, but that's a whole different topic. :-)

You are wrong!

[sorbits]

Bad code arise when the requirements change and the code needs to be updated to these.

Bad code arise when the beautiful algorithm needs to deal with real-world constraints.

Bad code arise when the program grows over a certain size and too many modules depend on each other (this is often not avoidable).

Bad code arise for many reasons -- premature optimizations is not a problem I face often (in my 15 years of programming), and I have worked with a lot of bad code, much of it my own, which did not start out to suck, but most successful projects will grow to a complexity that affect the code badly.

Try to work with some "hard" problems and I bet your code will not look intuitive, like an arithmetic encoder, C++ parser, GIF decoder or a HTML parser which is compatible with the HTML on the net (as the users expect it to be!).

Rich Waters did something like this in the 80s.

[voodoo1man]

It was called the Programmer's Apprentice, and sat on top of Interlisp. I think that PA built on top of a lot of features already came with Interlisp, like spelling correction (DWIM - Do What I Mean), versioning tools, undoable assignment, and a program cross-referencing/refactoring tool called Masterscope. What it added was an AI-enabled layer for error detection and source generation. This is kind of neat, but although I've never tried it I don't think this is all that useful of a tool (I can't help but think that anything that deals out programming advice at such a high level will get in the way more often than it helps). Do a google or citeseer search on it - there are about a dozen papers on the project.

I think in the end the lower-level techniques of such a system prove more useful to a programmer. At the very least they have had a higher rate of succesful adoption. Most modern programming languages use Lisp's ideas of uniform object referencing and automatic memory management, and stuff like quasiquoting pre-processors has started popping up for other languages in the past couple of years. Concepts a little higher-level, like AOP and refactoring, go a very long way toward the intelligent programmer's apprentice. Of course, if nothing else all this stuff makes making programming apprentices much easier - just try to imagine building one to deal with C's pointer referencing!

Avoiding "bad code"

[Anonymous Brave Guy]

I agree with you completely that bad code often arises through innocent intentions. I disagree, however, that it's often not avoidable. It's almost always avoidable: if you wrote the same code from scratch, knowing what you know after writing it the first time, you would produce a much better result.

The problem is just that complete rewrites are very expensive, and most development teams/managers are too stubborn to do minor rewrites when they should, preferring to add hacks or workarounds instead of maintaining a relatively clean design. Sooner or later, that usually results in the need for a much more expensive major rewrite instead.

Keep it simple, stupid!

[c0d3h4x0r]

Nearly all software and engineering problems I see are due to unnecessary complexity. The more complex the system, the more prone it is to error, and the more difficult it is to fix. Since we cannot easily *prove* large programs correct, the best we can do is try to intuit our way through the program's structure and flow to spot problems and try to ensure correctness. So making code as understandable and simple as possible is the best way to reduce flaws, since the human brain is the last line of defense/validation as to the program's correctness.

I've been a developer on a major Microsoft product for 5 years. The source for this application is very large and it requires a team of roughly 30 developers to work on it for each release. Even when you become an expert on one area, you still know nothing about other areas, because there's just so much code.

There are areas of our code that are considered very touchy. They are expensive areas to work in because they are difficult to understand, are architected poorly, and break in unexpected ways nearly every time someone makes a change. This is directly due to the code not being as intuitive or as simple as it should be.

There are other areas of our code that are very readable, smartly commented, and intuitively architected. These areas are pretty inexpensive to work in, and they tend not to have many bugs. These areas do some very complex work, and are sometimes optimized in ways that don't make a lot of sense at first glance, but because the code is commented and architected cleanly, it is still quite understandable even to a newcomer.

When people start building houses of cards just because they can, instead of it actually being necessary to get the job done, that's when you end up with a mess on your hands. I've seen plenty of code (not at my job, but on my own time) written by "kiddies" who had just discovered recursive functions, and they do their damndest to try to tackle everything using recursion. I've seen the same thing with people who have just discovered C++ classes -- everything is over-encapsulated as a class, just because they think classes are cool, rather than using classes to aid in organizing things in any sane fashion.