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

[MysteriousMystery]

And yes I do realize it was written in the Java developers section. But it is very possible to improve the development of large projects using existing languages. Which is what the general scope of the interview touched on.

Re:I found it to be interesting

[TheSpoom]

In the latest java.sun.com feature at Sun's Java site...

;^)

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

[glenn1you0]

Why was the parent modded 'Funny'? It is spot on. Do we really need a cluefulness test for moderators? 'Insightful', people, 'Insightful'.

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

[Anonymous Coward]

Yeah, but funny can be insightful inclusive. Some of the funniest people I know are also the most insightful, interesting, and informative wrapped up in one. :-)

Re:I found it to be interesting

[nhorman]

I thought it was a blatant ad for Java, and her argument regarding the need for more intitive languages rather hollow. Of course languages should be more intuative, who would disagree with that? What she forgets to mention is that every effort that has been put forth in developing such a language, including the ones she sites, are either so far removed from the behavior of the hardware as to be prohibitively slow, or are run on interpreters written in more low level languages. Sure its great to make a language that anyone can pick up in a a few days, but no matter how hard you try, your going to need a set of engineers to understand the underlying hardware, and furthermore understand the intricate interaction of the software with that hardware. Without that, nothing else works. Its good to want to create intuative software, but the fact of the matter is, computer systems are complex pieces of equipment, and making software run on them requires that you (or someone) understand how a language executes on them, from the 1's and 0's on up. The closer a language is to describing the workings of the hardware, the more closely you can control the machine. You can remove a language from that closeness to the hardware, but eventually you will give up hardware control to the point that you will need helpp

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

[BDubb]

Anyone who thinks Java is buggy hasn't seen the handiwork of some of my Java programming team. Throw the gauntlet down! they are up to the challenge "intuitive" or not...

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

[Anonvmous Coward]

Parent post is not off-topic.

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

[Adartse.Liminality]

I wasn't talking about being terse or playing golf but about very high level language, a single method does what would take dozens of lines of say c. one liners are cute 'til you read sombody's else.

Re:I found it to be interesting

[Anonymous Coward]

No plugs?

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.

Ha ha ha. You try writing an OS in Java.

Re:I found it to be interesting

[Anonymous Coward]

Seems to me that s.matches("^\\d+") is just about as easy as $s=~/^\d+/ .

Or s.split(",") as split($s, ",").

Or s.replaceAll("\\s+", " ") as $s=~s/\s+/ /g.

Or s.replaceFirst("\\s+", "") as $s=~s/\s+//;

And on and on ....

Re:I found it to be interesting

[wtrmute]

Have you read the article? Ms. Livschitz mentioned that the OO paradigm may have its limitations. Given that, is it appropriate to go about trumpeting the virtues of POOPs to all and sundry?

Not that OO isn't good, it's very good - as much of a step above structured languages as structured languages are above the older non-structured languages. It's just that maybe it's time to look for the next level of abstraction for languages, and that's what the article is all about.

Re:I found it to be interesting

[hikerhat]

Ha ha ha. Oh, wait, here's one and here's another one.

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.

Re:I found it to be interesting

[ajs]

I'm sorry, did I mention on-liners? I was talking about OO models, and you're comparing Ruby to C and dismissing Perl with talk of one-liners... I sense a lack of desire to have a serious conversation here...

Re:I found it to be interesting

[jonadab]

> Perl's OO model isn't.

Agreed. I love Perl to death, but the OO sucks rocks. (But then, I don't
like the OO in C++ any better. I guess Inform's wonderful object system
has be spoiled.) This is getting fixed in Perl6, but of course that's all
in the future at this point. (We haven't even got the Apocalypse article
on objects yet, though we've got quite a lot of information about them
already from the previous articles.)

The thing I like about Perl the most is the multiparadigmatic approach. (Well,
that and the CPAN. CPAN rules. It's like sourceforge and portage all rolled
into one, plus better documentation and better searching facilities.) What
do I mean by "multiparadigmatic approach"? I mean, I can use freely interleave
functional, object, imperative, and contextual styles, using whatever best fits
the problem I'm solving. If it suits my purposes, I can have a global array
of hashrefs, and each hash can hold several closures that share between them
(within that hash, but separate from the others) an object (say, a DBI handle).
Or, if it suits my purposes better, I can have a class of objects that each
retain as one of their properties a closure that holds a private array of
helper objects -- and that's just using the major traditional paradigms
(object, functional, and imperative). Perl also has the contextual paradigm,
which once you get the hang of it is incredibly useful.

And yeah, when I read this slashdot blurb...
> 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.

I immediately thought, "Oh, in other words we should use Perl, or something
a heck of a lot like Perl."

Re:I found it to be interesting

[Adartse.Liminality]

hu? read above "perl has its place"

btw one-liners aren't exclusive to perl(matter of fact I wasn't thinking of perl when i wrote one-liners), I don't like one-liners 'cos thaose are qhacks, perl is useful for certain problems/situations but is not the best for *all*, OO should be as transparent as possible, if I have to "build" my OO in perl is something that I wouldn't have to do in others langs, if I need OO I use and OO lang if a need to do some quick cgi I could use perl.

Ja freedom's good but too much of a good thing... as for the rest read post below #82764000

Re:I found it to be interesting

[rascal1182]

Lots of shameless prlugs, 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? ;-)

To me, this sounds like a job for OCaml! I'm not kidding.

Re:I found it to be interesting

[Anonymous Coward]

> Hmmm... Perl anyone? ;-)

Wan't something more inuitive, higher-level,
and powerful than Perl? ...Shell anyone?

Re:I found it to be interesting

[Anonymous Coward]

Parent Post Is NanoGator's Butt Pirate-In-Arms.

Please Mod Accordingly.

Re:I found it to be interesting

[Trejkaz]

Having heard of Ruby as a "more OO Python", I was fairly interested in learning it. I've hacked together one script (a data migration script, exactly the sort of thing you would usually do in Perl) so far which seemed to work fairly well, I haven't done too much on the OO side yet but the block constructs are a whole lot more intuitive than having to pass around chunks of code with Perl and using 'eval'.

I love the way that it hides the OO nature from the developer if the developer doesn't want to know. Code in the top level of the source file which any other language would consider as normal procedural code ends up in a main method automatically, yet at runtime you can be assured that everything is wrapped in objects (or at least classes.)

It seems like operator overloading in Ruby is part of the point of the language, though I haven't found an excuse to use it yet... maybe I should see how its mathematical performance is and render some fractals, that would give me use of it.

Re:I found it to be interesting

[Anonymous Coward]

I agree. The result of allowing people to become ignorant of how a computer program works is the advent of programming languages which incorporate the keywords "please" and "thankyou", and one-button mice.

Re:I found it to be interesting

[ajs]

"I haven't done too much on the OO side yet but the block constructs are a whole lot more intuitive than having to pass around chunks of code with Perl and using 'eval'."

I'm not a detractor of Ruby's (it's on my list of things to get around to learning some day), but you're way off base with respect to Perl.

Sure, you can pass around strings of code in Perl, e.g.:

foo(q{print "Hello, world!\n"})
sub foo {
my $code = shift;
eval $code;
}

but that's not very efficient. You're much better off passing around closures:

foo(sub {print "Hello, world!\n"});
sub foo {
my $code = shift;
$code->();
}

Why is that more efficient? Well the obvious way is that there's no second parser pass, it's all parsed at initial compile time, and optimized in one pass. Second, you can do somewhat fancier things like:

foo(sub {print @_});
sub foo {
my $code = shift;
$code->("Hello, world!\n");
}

and because you're passing a closure, you can access lexically scoped variables as well:

my $hi = "Hello";
foo(sub {print "$hi, ", @_, "!\n"});
sub foo {
my $code = shift;
$code->("world");
}

As you can see, passing around code is a strength of Perl's. It's so useful in fact that there's a shorthand for it that allows you to write your own functions like the built-in grep and map functions:

sub printit (&@) {
my $transform = shift;
print $_->($transform) foreach @_;
}
printit {uc($_)} "hello world!\n";

Enjoy!

Three-choice system of logic

[Anonymous Coward]

There needs to be a logical system based on 3 possible answers for every question, rather than the YES/NO or 0/1 system we use no.

Maybe -1/0/1 or Maybe/Yes/No, something along those lines perhaps would help computers to mimic the brain a bit more.

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).

Re:Three-choice system of logic

[ivern76]

Overly simplistic. Google for "fuzzy logic" and "open world assumption", this has been the focus of massive research for decades and has honestly not gotten us that far.

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.

Re:Three-choice system of logic

[Anonymous Coward]

Is this in development? Because it sounds a lot faster than what we're using.

I'll take three.

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

[nacturation]

For this to actually be useful we would need a platform that can execute ternary code natively.

All you really need is a simulator. This is easily done with any sort of Virtual Machine which is able to run a ternary instruction set.

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.

Re:Three-choice system of logic

[Anonymous Coward]

In GIS, the concept of fuzzy tolerance for deciding whether lines/arcs on a map cross or not is based on a form of ternary logic.

As this is one of the fundamental problems in representing spatial data in a computer.

This isn't new, by the way: these solutions are DECADES old.

Re:Three-choice system of logic

[GeckoX]

Sorry, I thought I mentioned that option, but it wasn't really clear I guess.

tx

Re:Three-choice system of logic

[GeckoX]

I believe I've read that conclusion before as well.

If my memory serves me correct, there was a bit of a race between the merits of binary vs ternary computing way, _way_ back in the day, and the conclusion was then that yes, there were a few cases where it could be useful, but everything you could do with ternary, you can make work with binary in some way...and it was a heck of a lot easier to build hardware that was only on/off than it was to build hardware that was multi-state.

Re:Three-choice system of logic

[dasmegabyte]

Uh...

Why do we need hardware to do trinary logic? We don't need hardware to perform more complicated logic...in fact, every language I can think of has some form of integral case syntax.

Besides, it's quite rare that I need trinary logic. Actually, it's almost never happened...looking over the codebase I'm looking at right now, there are only four instances in 50,000 lines or so that we looked at three states, and all of them were to process a YES/NO/CANCEL screen. We don't use these screens much...as it turns out, they confuse our users a lot.

Just like trinary logic confuses programmers. I don't know what narcotics the grandparent was injesting when he thought trinary logic was a brilliant programmatic idea. It isn't...in fact, the only reason it's researched at all is that it is possibly more efficient from an electrical standpoint than binary logic. Most probably, the first trinary computers will not have a trinary logic integral to the language -- instead, they'll optimize binary logic using trinary structures.

Re:Three-choice system of logic

[Anonymous Coward]

So, ummm... what if I give it the question of "what plaintext produced this output, given this algorithm and this public key" just how long is your theoretical programming language going to take to get an answer, again?

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?

Re:Three-choice system of logic

[nacturation]

oops, you're right... mea culpa. I should have read it a bit closer. :)

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.

Re:Three-choice system of logic

[E_elven]

Oh yes. Ternary computing will change the world. Turn on the machine. Your GNU/Linux will maybe boot up. Hm, the program crashed because there possibly was a memory violation. Welcome the Probably Blue Screen of Possible Death.

Re:Three-choice system of logic

[Trejkaz]

Which is one step away from Java or any other existing bytecode-based systems. You'd just have to make all the changes to the source code, et voila!

Re:Three-choice system of logic

[Anonymous Coward]

IMO, fuzzy computing would make generally more sense. It's much more intuitive on the whole. The idea is instead of having two or three states, you have a continuum of states, and logic is performed on the coniunua to form a result on another continuum.

To give an example, which of the following three options would you feel comfortable in being asked by a toasted:

Option A. Would you like your toast burned to a crisp, or uncooked?
Option B. Would you like your toast burned to a crisp, uncooked, or medium?
Option C. How cooked would you like your toast?

Surely a system based on Option C would be more useful than either A or B. The downside is that floating point precision is usually required (although you can use integer precision to approximate almost as well, just making 256 choices, which is probably more than enough for toast.)

Test for NULL pointers

[Anonymous Coward]

Any other good ideas?

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!

Re:Test for NULL pointers

[dasmegabyte]

Yeah, here's one:

STOP USING POINTERS!

I love the way Java (and to an extent, .NET) handles these things. There are maybe 10 primitive data types. Everything else is an Object. A variable doesn't represent an object, it represents a pointer to that object. You can't make an object act like a primitive...you can't do IntegerClass + IntegerClass, you have to do IntegerClass.Add(IntegerClass). No overloading operators makes things a bit longer, but you never have to worry about confusing syntaxes or anything.

Which is why I said "to an extent" .NET. .NET makes everything an object...even the primitives...but allows you to overload operators. So occasionally you will see shit like Date + Integer -- or WebSite - User + Browser...

Re:Test for NULL pointers

[Anonymous Coward]

Since Java overloads the "+" operator for strings, I suspect the lack of overloading capability in Java had more to do with simplifying Sun's work than it had to do with any belief that overloading is inherently bad.

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:Test for NULL pointers

[rudiger3d]

I think you're right when you say that you have to be careful with the + operator in java. But your example may not be the best.

According to "Java Performance Tuning (1st ed.)" by Jack Shirazi your example string is actually resolved at compile time (but that's not what the javadoc for StringBuffer says). Eg.

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

is compiled as if it read:

String newString = "this language sucks";

Of course, when an expression involving String concatenation cannot be resolved at compile time, the concatenation must execute at runtime. Eg.

public String languageSucks(String language) {
return "The " + language + " programming language sucks";
}

could be compiled as:

public String languageSucks(String language) {

return (new StringBuffer()).append("The ".append(language).
append(" programming language sucks").toString();

}

Re:Test for NULL pointers

[some guy I know]

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.

It doesn't imply that any more than x+y implies adding y directly to x.
In the expression 4 + 5, I doubt that very many people would imply that to mean that 4 was replaced by 9.
Instead, a third entity receives the 9.
In a similar manner, "hi, " + "planet!" doesn't mean that "hi, " is replaced by "hi, planet!".
Instead, a third entity receives the concatenated string.
Most languages of which I am aware (BASIC, C++ STL, Python, etc., etc.) that use "+" to mean concatenate strings will use it to mean that the concatenation is a new entity.

Now, depending on the language, concatenation may require a memory allocation, but that may also be true for integer addition.
(For example, Python and some versions of LISP will allocate memory for both addition and concatenation, whereas a language like Borland's Object Pascal (Delphi) will not allocate additional memory for either type of operation if short strings are used.)
This type of thing is why it's essential for programmers to know what's going on "under the hood", if they want to write efficient programs.

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...

[Kphrak]

This troll looks hungry and shows no sign of turning to stone, despite the fact that it's daylight. I think I'll feed him.

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.

Of course! If we just made everything drag-and-drop, developers would barely have to know anything at all! You could just make windows that you draw components onto, then the developer just sets the way he wants it to look and pastes in some code from a website.

What?...Microsoft made that?...and it's called Visual Basic? And it sucks because developers who are trained on it never learned how to assign variables, do basic arithmetic, or program things efficiently?

Oh.

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...

[Anonymous Coward]

Anyone who grew up post dos, is ruined to computer programng. They have things too easy.

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...

[Anonymous Coward]

The sad thing about CS is that the required program is often to write the 400+ line recursive routine so getting it to work is all that is required. Or that most CS assignments are simple enough that most likely once it compiles you are done.

In college I hardly ever had to spend more than a couple minutes debugging my programs. It wasn't too unusual for them to compile and work first try.

College is just a way of converting money into a degree. I think they gave up teaching anything long ago.

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...

[Anonymous Coward]

The guy's nick is pompousjerk. What'd you expect?

Re:I'd rather have...

[Viol8]

Variable assignment is one of the fundemental parts of programming a von neuman computer you clueless dork. You cannot get away from the concept of storing a value for later use whether
you use C, assembler, Prolog, ML or 101 other languages. And as for your comment about arithmetic , well , thats just funny. Perhaps YOU should have been educated properly though somehow
I'm not sure your sphincter would be listening.

Re:I'd rather have...

[American AC in Paris]

Dude. I know that. I was using hyperbole to demonstrate a point.

My point isn't "we should have languages where you can't add or assign variables!". That's just silly. That's like making your car safer by removing the axles.

My point is that we can't fix bad programmers by making better languages. So long as a programmer has any degree of control over their code, the bad ones will be able to write bad code.

Re:I'd rather have...

[Molz]

Don't forget the:

• Professors who's own code will not compile without significant revisions.

That is an old favorite of mine...

Re:I'd rather have...

[Rip Van Winkle]

Oh, remember the days. The sad thing is that I was one of those once as well! Now look at me.. On second thought, let's not look at my code!

You've got to admit, at that age it's fun reveling in a freshman's coding troubles!

Re:I'd rather have...

[Anonymous Coward]

What school do you go to?!?!?

Re:I'd rather have...

[pompousjerk]

Hehe. The person who tried to evangelize Visual Basic to me was Junior when I was a lowly Freshman.

But the Prof?!? C'mon, who leaves '.' in their path? (Don't get me started on the admin, who actually allows it.)

As for the rest of the quips, they all happened with people that were in the same course as I was at the time.

The huge recursive routine? It took those two students at least 20 hours between them to get it working accurately. Not once did it occur to them to scrap the damned thing and start over.

Re:I'd rather have...

[Sepper]

I am in a Computer Engineering program and you should just see what kind of people we get....

I think the worse kind are those who never touched a computer prior to university(and yet they chose that field of engineering!!!)...

and those who came into this field 'because it pays' (at least it used to)

I know one guys who told me:
"I don't understand why anyone would use anything else than what is bundled with Windows (Outlook, IE, etc..)"
and:
"Linux is the worse thing I ever had to work with"

How do you change an opinion like that?

Re:I'd rather have...

[ATMAvatar]

I rather enjoyed his quotes:

"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense."

"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC; as potential programmers they are mentally mutilated beyond hope of regeneration."

Re:I'd rather have...

[szilagyi]

You forgot to ground out the recursion:

• Crusty slashdotter condescending to the condescending CS student.
  
• Total loser (me) pointing out the prior condescension.
  
• Total loser pointing out what a loser the last loser is.
  

There, and in tail form, no less.

Now you have to shift to the obvious meta level to point out how I'm wasting everyone's time with this thread. Except maybe the newbie CS students looking for an example of recursion to which they can relate.

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.

Re:I'd rather have...

[jonadab]

> 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.

Well, you *can*... unlambda for example doesn't have *anything* like
variable assignment, nor does it directly include any arithmetic primitives
(though it is possible to do arithmetic indirectly).

> The very idea [...] is just plain silly.

I think unlambda is more scary than silly.

> You just can't 'fix' bad programmers with better languages.

No, of course not. You can remove certain very common and problematic
classes of bugs, though, such as buffer overflows, segfaults, and memory
leaks. But there will always be application-specific logic bugs, and there
are classes of common bugs (e.g., infinite loops) that cannot be easily
solved at the language level (except by crippling the language, which is
unuseful).

Re:I'd rather have...

[Anonymous Coward]

Hey, I've been programming for over ten years, and somtimes *I'm* still happy when it compiles. Particularly when I'm writing C++ which has to work unmodified with several not-quite-compatible compilers...

Re:I'd rather have...

[Anonymous Coward]

C'mon, who leaves '.' in their path

uhhh just about EVERYONE? Also SOME packages actually assume it.

Just because it dorked up some project you worked on does not mean its not usefull.

Let me put it to you this way. Ever have .c files in folders below your main root dir? Want those files to still be able to use the .h files without having to refrence them correctly? What if your on a project and those files could end up ANYWHERE but its all relitive to some other dir? Also 'but you can just edit for yourself and it will work' does not fly in a 20 dev team. Some of the devs will do it others will not. Programmers are inherently lazy, you better get used to it. So you do things so the people who do not quite 'get it' can still contribute, while the others can keep going as well. You learn to let computers do their thing. 'Just edit the file and voila it works' only lasts so long when its the 3 millionth time you have edited the SAME parameter.

While you look down on your fellow students. You have show yourself to be a newb. This is the BEST advice someone ever gave me and I pass it onto you. Do not get mad here. 'Drop the arrogance and be humble you will get more done and everyone assumes your good'. You know what he was right. Your never as good as you think you are. There is always someone WAY better than you can ever dream to be at what you do. Also arrogance breeds hatred, while humility breeds a 'he gets the job done' feeling from everyone. Which would you rather be? The dude everyone dreads that comes around or the dude everyone goes to get something done? I've been both. Trust me you want the second one.

Also I learn something new about programming every day. Today I learned (again) do not assume the order is right. For some reason I need to keep relearning that one.

Re:I'd rather have...

[pompousjerk]

They don't try. They're not there for an education. They're there for a degree. A piece of paper that says give me more money. That's why I have disdain.

Oh, and having '.' in your path is a security risk. Sure, it's less of a security risk at the end of the path. But it's still a security risk!

Re:I'd rather have...

[fizbin]

Let me put it to you this way. Ever have .c files in folders below your main root dir? Want those files to still be able to use the .h files without having to refrence them correctly? What if your on a project and those files could end up ANYWHERE but its all relitive to some other dir?

You are confusing putting "." in your $PATH variable with using relative paths in your compiler's include path (-I) or when explicitly giving the path to some executeable.

And yeah, the many of my coworkers put "." in their $PATH despite me telling them not to (how hard is it to type "./myscript" ?) Then, after having something not work the way they expected (because they named their script the same as some obscure binary in /usr/bin), they move "." to the _start_ of their $PATH....

Re:I'd rather have...

[maysonl]

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. Are you sure? I think there's a product lurking in the bushes here...

Re:I'd rather have...

[ONOIML8]

Good point. And not only will you have bad, sloppy programmers, there will always be programmers without ethics.

Unless anyone has an idea for enforcing ethics via the languages. :)

Re:I'd rather have...

[Trejkaz]

But that's okay, because all you have to do then is find a directory which they left writable by group or other, and drop in a trojan called ls.

Re:I'd rather have...

[Trejkaz]

Jeez, you're such a loser.

Oh, bugger.

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...

[Anonymous Coward]

Your logic is flawed, if intuition==nipple, then a nipple must do the sucking. Your theory implies that the seeker of intuition sucks, not intuition itself.

Re:Well...

[SchroedingersCat]

In my days the idea was to make software more intuitive for end-users, but I guess priorities change.

Re:Well...

[Rick and Roll]

I am sick of seeing this quote. It just comes from a few people that are stuck on their High Academic Horse (TM) and can't seem to get back down to the real world. Not that there isn't some truth to it. But the fact of the matter is, fast code is the code that's likely to get re-used. Look at Mozilla and Expat. Damn right, the Expat devs were thinking about writing fast code when they wrote it.

Re:Well...

[Anonymous Coward]

Feels right

Ship it!

Re:Well...

[Anonymous Coward]

Have you, in fact, ever used Mozilla?

Re:Well...

[Anonymous Coward]

"Premature optimization is the root of all evil" - Unknown

Hear hear! I can't agree more. Actually I think I'd like to refine the quote:

"Optimization is the root of all evil" -Anonymous Coward

Recently I started a project to to write my pet language complete with C-like syntax, a fancy garbage collector, higher order functions (aka closures or blocks) and loose data types. I made a point to avoid optimizing for optimization's sake. After a month's worth of effort, I had a fast, functional (pun intended) language interpreter, but the compiled version (which actually output C and used GCC to build the binary) was shall we say "a little slow" (i.e. not much faster than the interpreter).

It turns out some of my design decisions to avoid optimizations came back to haunt me. So now I'm going back and undoing a lot of elegant code and replacing it with nasty optimizations. Well ok so at least I'm keeping some abstraction by just redefining macros and such, but it's causing me to lose my interest in the project. I'd rather work on a slow/elegant compiler than an optimized/hackish compiler, but I really can't live with the performance of the elegant version. *sigh*

p.s. I need a job!

Re:Well...

[jonadab]

> FORTRAN is highly counter-intuitive, but it's a damn fast number crunching
> language (rivaled only by C, if I remember my benchmarks correctly).

FORTRAN is more than merely *rivaled* by C; when it comes to being highly
counter-intuitive, FORTRAN is utterly *outclassed* by C.

Oh, you meant rivaled in terms of the speed of number cruching? Then, yeah,
as long as the numbers in question are small enough to be represented by C
data types. Otherwise, it's best to stick with FORTRAN for that.

(Please note that I'm not advocating FORTRAN for things *other* than number
crunching. It's utterly worthless for text handling, for example. For that
you use Perl.)

Re:Well...

[sartin]

You know, sitting here as my wife feeds our nine day old baby, I feel obligated to mention: the nipple is not an intuitive interface. It's not as simple as just sucking. Baby's need to learn it.

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.

Re:Well...

[Rick and Roll]

That's why I didn't say Mozilla was so great. I only said that Expat was a kick-ass project.

Re:Well...

[shibboleth]

No, the bad (nonintuitive or broken) code I've seen lately has nothing to do with attempts at improving performance and everything to do with ignorance re: the language and programming.

Re:Well...

[Anonymous Brave Guy]

Wrong. If you are optimizing without the guidance of a profiler you are wasting your time.

I'll just stop passing large objects by const reference in my C++ then, I guess. Passing by value would be much more intuitive, after all.

Please don't mistake a good rule of thumb for an absolute truth. In most fields, there is no such thing.

Re:Well...

[mattgreen]

Thank you for the contrived example all because I neglected to put "probably" in there.

Re:Well...

[Anonymous Brave Guy]

Thank you for the contrived example all because I neglected to put "probably" in there.

My point is precisely that it's not contrived. In many languages, particularly lower-level ones, there are numerous "optimisations" like this that will pretty much always lead to a significant performance boost, or at worst a break-even prospect, and that require negligible effort to use instead of the alternatives. They should, and by experienced developers will, be used routinely, without reference to a profiler.

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

[Anonymous Coward]

Try Smalltalk.

Re:Objects

[CFTM]

I was the same way, but I got so sick of the bullshit math classes and there syntax laiden garbage that I switched to philosophy, now I spend my time studying even more abstract bullshit but at least it's all in metaphors! :)

Re:Objects

[mhesseltine]

My understanding is that Ruby is much like that. Everything is an object. The typing is left to methods inherent in each object.

You might want to give that a try. IANARP,YMMV,HAND

Re:Objects

[dnoyeb]

Of course. Now who builds the Legos?

Often sofware usage resembles building with Legos. When you use a good library you feel this way. MS Visual Basic is strongly this way.

But the design of those pieces can be difficult.

Often people want OO objects to resemble "real world" objects. We take for granted how complicated the physics behind the real world really is.

I found software and math classes to be equally easy. They both require lots of time though.

Re:Objects

[Anonymous Coward]

Pure object orientation is a mistaken reductio ad absurdum of a useful tool.

Java is already ridiculous enough - why the heck do you have to create and instantiate an object just to write a simple procedure with no inputs and no outputs?

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

[dasmegabyte]

How about C#?

Dunno how it works under the hood, but above ground everything's an inheritor of Object. You can declare something as an int but it doesn't become an integer primitive...that's just shorthand for an Integer allowing you to paste in a lot of your pure C code and have it "just work."

Forcing the inheritance from Object adds a few great methods to everything...ToString(), GetType(), Equals() and GetHashCode(), to name the big ones. ToString() is the best...no matter what you have, you can System.out.Write(object) and it'll tell you SOMETHING about it. Even if all it has to say is "This object overrided the ToString() method and now it's laughing at your feeble attempts to investigate it"

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

[Anonymous Coward]

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.

Re:Objects

[Anonymous Coward]

Re: "Pure Objects":
[Yuk. OO is terribly overused. The notion that "everything is an object" is a mistake. And by implication, every language based on this notion is a mistake (Hint: Java). Why are there no competitive object oriented databases? Because OO fails miserably in that domain.]

--Bruce

Re:Objects

[Cthefuture]

Rest assured that pure OO languages are not the answer to everything. This was even mentioned in the article.

They sound neat when you're learning programming or don't have much experience but just wait till you join a new OO project that has 1000's or 10's of thousands of classes. It'll be real fun, trust me. Even the very best designed systems can turn into an OO nightmare. Just trying to read and understand large OO code is often very painful.

Just like with everything in life the answer is most likely moderation. A balance of techniques. OO, functional, <insert new programming model here>, can and probably should be mixed together in a new language that has the best features of all the systems.

Re:Objects

[Anonymous Coward]

bullshet. If everything was an object you could assign null to an int.

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

[Suidae]

why the heck do you have to create and instantiate an object just to write a simple procedure with no inputs and no outputs?

Well, what else are you going to do with a 5GHz 64bit processor?

Besides using it as a space heater that is.

Re:Objects

[NoOneInParticular]

Can't agree more. OO as it is practised is a complete nightmare. I like to compare compare OO programming to the definition of a lexicon, a vocabulary to reason about the problem you're solving. Nouns for the 'objects' that are being processed, and verbs, 'methods' that work with the objects. Whoever thinks that for every application you need to invent thousands of new nouns ('objects') should be taken out and shot in the foot.

Almost any application has room for no more than 10 new words, 10 objects, and that's it. The rest is pure fluff.

Re:Objects

[Anonymous Coward]

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

one word - LabView

it rocks (but costs a lot)

Re:Objects

[SparafucileMan]

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

Haha this pleases me. It is a shame how few mathematicians/programmers do not realize that terseness is a powerless goal. You can never be sure if your short-and-efficient program can ever get shorter-and-or-more-efficient. Math teachers must not cover Godel in class any more!

Re:Objects

[n3k5]

why the heck do you have to create and instantiate an object just to write a simple procedure with no inputs and no outputs?

Well, what else are you going to do with a 5GHz 64bit processor?

You two missed something there: It is true that in Java you can't do anything without defining a class. So, even when you write a trivial 'hello world' program, it would be good to have kind of a clue about what classes and objects are. However, you don't need to instanciate anything to run your method. If you realize that it doesn't make any sense to call that method through an object (which, by the way, is rather unlikely if that method has neither input nor output parameters *g*), then just make it a class method.

Pure object orientation, in the sense of ignoring that there might be other paradigms that could also be helpful, is bad of course. But it has absolutely nothing to do with 5GHz 64bit processors.

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.)

Re: Objects

[gidds]

Mathematics is metaphors

Er, no. Both programming and mathematics tend to be very abstract; the difference is that in programming, the abstractions are often metaphors for real-world objects, whereas in mathematics, they're usually not: you deal with abstract objects for their own sake. Even number is an abstraction, albeit a common and familiar one. But most are much further removed from everyday experience; non-commutative fields, analytic functions, topological spaces, and the like are studied not because they have any direct parallels in the physical world, but because they're intrinsically useful. No metaphor in sight.

Re:Objects

[Anonymous Coward]

Which doesn't mean mathematicians don't use metaphor a lot.

By presenting both a metaphor and a definition of a function I meant to indicate exactly what you just said. In other words, I agree.

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.

Let's take an example. What is the metaphor for a Grassmanian manifold? I know of nothing in common experience that I could use to think of a Grasmanian in terms of. I do have some kind of internal mental representation of what a Grassmanian is. I suppose you might say that my mental image is really a metaphor for the Grassmanian, but I don't think this is a nice use of the word metaphor. At any rate, your post made me think of the following statement on the matter which was made by Einstein in a response he wrote to Hadamard. This is in line with my views on the subject.

The words or the language, as they are written or spoken, do not seem to play any role in my mechanism of thought. The psychical entities which seem to serve as elements in thought are certain signs and more or less clear images which can be "voluntarily" reproduced and combined.

There is, of course, a certain connection between those elements and relevant logical concepts. It is also clear that the desire to arrive finally at logically connected concepts is the emotional basis of this rather vague play with the abovementioned elements. But taken from a psychological viewpoint, this combinatory play seems to be the essential feature in productive thought--before there is any connection with logical construction in words or other kinds of signs which can be communicated to others.

The above mentioned elements are, in my case, of visual and some muscular type. Conventional words or other signs have to be sought for laboriously only in a second stage, when the mentioned associative play is sufficiently established and can be reproduced at will.

Re:Objects

[RevAaron]

But I don't know if those languages are what he was looking for. He didn't just say he wanted an all objects language- of those there are plenty. He mentioned one like C++ or Java, so I am guessing he just wants a Java or C++ clone that ls all objects, retaining syntax and other things.

Out of the languages you list, perhaps Dylan is the closest. Cish syntax, but lisp inside. mmm gewd!

Re:Objects

[Anonymous Coward]

Lego, not Legos. It's one of those words which you don't put an 's' on to pluralise, you illiterate clod!

Re:Objects

[Trejkaz]

What would you suggest instead?

Ruby does it slightly differently. You still create and instantiate an object, but you don't know you're doing it because you're just writing in the top level of the file, or defining what you think is a global method.

Re:Objects

[Trejkaz]

Sorry, typeof() appears to be a global method, and those don't exist in a purely OO system.

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...

[SlashDread]

Dont be fooled; the goal of pms is to have power, not to make "better projects"

Sometimes that works, sometimes not. Useless it is, I'll give you that.

"/Dread"

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.

Re:I'm sure...

[rodentia]

Yah!

There is an important dynamic around process change and programming that it really seems no one would like to talk about. Certainly academic HCI research is well-insulated from these issues.

It is the meatspace bugs that are the hardest to squash.

Re:I'm sure...

[C10H14N2]

I run into more 'bugs' related to forcing program logic to 'simulate the real world,' when the problem is the real world process itself (or the habitual circumvention thereof), than just about anything else.

When HAL started killing people, they blamed the programmer instead of the executives who demanded the program be allowed to lie. That's not a bug. That's human error. It has always been human error. No metaphorical model will change that. If everything is abstracted to behave as it would in the real world, it will take a psychoanalyst instead of an engineer to find the root cause and I don't really want to deal with my computer's abandonment issues to figure out why it isn't correctly compounding interest for the accounting department.

Re:I'm sure...

[dreamchaser]

Please remain where you are. An agent will be with you shortly to deal with your delusions. Please do not spread such alarmist lies, you will propagate further instability in the Matrix.

Re:I'm sure...

[eidechse]

Incorrect. The first rule of programming is you do not talk about programming. ;)

Re:I'm sure...

[JollyFinn]

No not really just one anomaly.

Re:I'm sure...

[bill_mcgonigle]

Maybe that's not quite the point, but it raised my eyebrows. (Which I'm thinking about shaving off.)

A kid in my high school tried this. He thought it was cool until he hit gym class and the sweat ran straight down into his eyes. He learned why they were there in the first place.

Re:I'm sure...

[Tony-A]

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

Hehe. The software has to work effectively in the world it finds itself in. Assuming the software is effective, it will change that world it was in and even if unbuggy in the world it was in, it will now be buggy in the world it now finds itself in.

"All programs have bugs." (with the possible exception of something by Knuth)
This is not an excuse after the fact. It is part of the design requirements. It is necessary that programs not go beserk if fed unexpected input. Execute strings as machine code if too long. Wipe out a database with a bad item description. If a few of these are "exploitable" and the the "exploits" are more spectacular than harmful, you have to wonder "who is the enemy?"

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.

Re:Jaron Lanier?

[Anonymous Coward]

First, let me welcome you to Slashdot. It is a fun community of people exchanging opinions.

I know you must be new here because you are under the mistaken impression that people actually read the article under discussion. A very natural mistake, but please don't make it twice.

Enjoy your stay here and come back often.

Re:Jaron Lanier?

[aricusmaximus]

This is off-topic (myopic?).

While the article casually mentions Jaron, it has nothing to do with his ideas. In fact, Victoria Livschitz essentially says that she has completely different ideas than Jaron.

Re:Jaron Lanier?

[Anonymous Coward]

So you want to know more about Jaron in order to know whether you want to know more about Jaron even though you've already made up your mind that you don't want to know more about Jaron?

Well, apparently Jaron coined the term "virtual reality," and has done some work in, you guessed it, virtual reality. You can read his interview here, in which he talks about coding. However, even if you do, you haven't RTFA because today's article is about an interview with Victoria Livschitz. HTH.

Re:Jaron Lanier?

[jjohnson]

I did read the article, and the article that you linked and that the original article linked is one of the reasons I'm mystified about him; I thought it was empty of insight and little more than a sketch of coding utopia. I was hoping that someone could point to something really seminal he'd done that would justify the hype around him, because I always get this deep feeling of cognitive dissonance whenever I see him mentioned on Edge.org.

Re:Jaron Lanier?

[Trejkaz]

Different ideas, but:

Q: Jaron Lanier has argued that we cannot write big programs with a lot of code without creating many bugs, which he concludes is a sign that something is fundamentally wrong.

A: I agree with Jaron's thesis completely.

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.

Re:Not a good idea...

[pokeyburro]

Moderation Guideline: +3 Funny.

As of this writing, your comment is +5, Funny. See, this is the problem behind buggy code: people just won't follow the guidelines...

Re:Not a good idea...

[rhatcher]

I once heard (and often repeat) that "programming is the art of debugging an empty file". The file starts out empty, and obviously doesn't work thus it needs a series of corrections (debugging) until the point where it does do what one wants.

Re:Not a good idea...

[Anonymous Coward]

yeah right, developers should'nt care or fix bugs, let users test.
Look how they got win95 fixed by releasing win98 and NT fixed by releasing win2k :P

Comments?

[jayhawk88]

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

Re:Comments?

[Anonymous Brave Guy]

It was a bit hyped up, wasn't it? It's a shame. I was just starting to give her some credit, and then she committed the classic "pro in not-so-independent interview" faux-pas of blatant self-promotion, or in this case, Sun-promotion.

One second, Java is much better than its predecessor, C++, because of all these whizzy features (most of which C++ also has, but that's beside the point). The next second, the problem is that objects alone aren't a sufficiently powerful abstraction mechanism, and thus "pure" OO languages won't ever be the solution to the problem of large-scale developments. But that's exactly what many developers have been saying about Java all along -- not least those who are used to having objects, functions, templates and all the other abstraction mechanisms available in C++!

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.

[Mildog]

If I hear one more programmer cry about outsourcing to India, I'm going to scream. 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 (think teaching, being a cop, etc.). If you want to be rich, obtain skills in an area that is paying well. It's that simple:

Choose your rate, choose your fate.

Re:Not my problem anymore.

[be-fan]

But people are *entitled* to do what they love and make a great living off it! I mean, they tell us the procedure to follow (high-school, college, graduate-school) and that's supposed to *guarantee* that our life will be exactly the way we want it in the future! I mean, why would they lie to us about us all being special and *entitled* to anything we want?

Yesh. What has our generation come too? I beginning to sound far too conservative for my taste, but this outsourcing thing is really getting ridiculous...

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.

Re:Not my problem anymore.

[Anonymous Coward]

Yeah! If you didn't want to live in a global economy you shouldn't have voted for it. Oh ... you mean didn't hear about the vote ...

Re:Not my problem anymore.

[Mildog]

Sounds like you have found a business opportunity:
1. Companies looking to outsource are wanting to pay less for programming skills.
2. There are not enough job offerings for programmers at a lower pay scale.

Start a company with programmers that are willing to accept less money and lowball the offshore bids.

Re:Not my problem anymore.

[Mildog]

You don't get a vote in everything. Adapt.

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.

[chromatic]

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

Why not fix the scheduling problems while you're at it?

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.

[Anonymous Coward]

The problem isn't the abstractions, its the exceptions.

While it would be nice to look at everything in nice lofty terms, the real world is simply a mess of exceptions layered upon detail smeared across the 30 second attention span of the Marketing department.

Simple quote from the California DMV:

A motorcycle is any motor vehicle:

Having a seat or saddle for the use of the rider, designed to travel on not more than three wheels in contact with the ground, and weighing less than 1500 pounds. A farm tractor is not a motorcycle.

Exception: A motor vehicle that has four wheels in contact with the ground and two of the wheels are a functional part of a sidecar and weigh less than 1500 pounds is considered a motorcycle.

As long as the real world is complicated, our models used to represent them will also be complicated.

Re:Ugh, more abstraction.

[Anonymous Coward]

I agree with you up to a point, but there's still a lot architecture and design issues that are not application specific. You need to know both the application area and how to implement a software application correctly.

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.

Re:Ugh, more abstraction.

[Telastyn]

Indeed, but if your goal is bugfree software, and not making oodles of cash, you put the ship date back.

Re:Ugh, more abstraction.

[AeroIllini]

>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.

Why? Because customers don't mind paying huge amounts of money for buggy software?

If I'm paying money for a product, I'd rather get it slightly later and have it actually work than get it sooner and lose productivity to poor manufacturing standards. But I guess I'm far too picky to be a consumer.

Re:Ugh, more abstraction.

[DavidHumus]

Too much abstraction away from the problem domain can be deadly.

However, some abstraction solves a more general case which has wider applicability and is more robust than speaking to a too-specific problem. For instance, I could write separate programs for rounding prices to eighths, sixteenths, 32nds, etc. (from back in the Bad Old Days when we had to do this in financial code) and I've seen this done!

--- OR ---

I could write a rounding program that takes an argument of how precisely to round something, e.g. 0.05 to round to nickels, 1 to round to whole numbers, etc. These even survives the transition to decimal prices with no change in the rounding function itself (though, of course, its use changes).

Remember, in theory, theory and practice are the same but, in practice, they're not.

+1 Sad but true

[Anonymous Coward]

+1 Sad but true

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.

[too much tv]

Here, Here. I'd also like to add Communication. I've seen it on all projects I've worked on - assumptions are made and not communicated (What you wanted to parse an XML file instead of a text file?).Most fail to even understand their own business procedures. These same poeple wonder why the message is missed and projects fail?

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.

[ahdeoz]

Do you know Haskell (or Ocaml), or know anybody who does? There sure seem to be alot of people who recommend these (and other) silver bullet oddball languages with no users for it to be hard to find practicioners of them.

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.

[Anonymous Coward]

Yeah, I know Haskell. I also know that the National Labs have a fair amount of people working in zero defect software that use ML.

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:Functional Programming et al.

[GMO]

Simon Peyton Jones (http://research.microsoft.com/Users/simonpj/) recently gave a talk on making Excel more like Haskell. In fact, I have no evidence that that's not who Tailhook is...

Re:Functional Programming et al.

[John Seifarth]

Could you give more information about this technique? (in your journal, maybe) It seems quite interesting, and I don't see any way in Slashdot to contact you directly. Thanks!

Re:Functional Programming et al.

[beelsebob]

Hehe, I was just thinking something similar... I was actually thinking that the replyer dirty_puppy sounded a lot like Colin Runciman. Bob

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?

[Jeremi]

I don't think she is ignoring the value of testing -- rather, her job is to come up with languages that are more intuitive, so that bugs are less likely to be generated in the first place, so that less testing is required. The reason she didn't mention testing is because testing isn't her area of expertise -- you might as well criticize a car-engine designer for not talking about air bags.

Re:Test?

[gnu-generation-one]

"She whines about how modern OO languages aren't intuitive for certain relationships"

Hang on, things like bridges are as object-oriented and real-world as it gets, yet it takes years of work by people paid a lot more than programmers to figure out all the complexities... How is real-world analogy going to help code? In interface world, people have stopped trying to emulate actual devices (bitmaps of the front of a VCR on a video-player for example) when they realised that computers inherently do things much more powerful than their physical equivalents, so they need commands that are more powerful.

Try telling your video recorder you want to copy 20 tapes to a backup area, then you realise why imitating the real-world object isn't any help in computing.

p.s. why does every tutorial on object-oriented programming use the example of dog objects in the animal class and such like? It's seriously distracting if you're trying to use the language to create a map-projection-conversions object, if all the books assume you're trying to describe physical objects.

Re:Test?

[dasmegabyte]

Well, the reason she didn't mention testing, QA, design, etc, is because she wasn't giving an interview on how to deliver quality software overall. She was giving an interview on how to reduce the number of bugs overall.

Certainly you still need to plan, test the code, QA it, etc. She's offering a solution to the problem of increasing code complexity, which is a completely different issue from what you're talking about.

In fact, good unit testing combined with simple, well documented abstractions has been the key to every successful project I've been in.

Of course, the difficulty in an open source project is that without a "charismatic captain," it's hard to get a really great API design before somebody kuldges something together. On the other hand, it's easy and beneficial to create a unit test for a future API...in fact, you may find that if you write the unit one day, the next day the API may have been written for you. Sort of a lock-and-key think...you build the lock, and it becomes a lot easier to build the key that fits.

Incidentally, abstracting conditional logic and processes is EXACTLY what unit testing is. She just didn't say it in so many words.

Re:Test?

[Anonymous Coward]

It's very hard to write large, qualtiy applications.

Sometimes its hard enough just spelling them. sorry i had too.....

Re:Test?

[wildwood]

This is exactly what I was thinking, that she has no understanding of test suites. I thought the following quote was especially telling:

However, most bug fixes require some degree of refactoring, which is always dangerous and unpredictable.

Geez, if refactoring's dangerous, you're probably doing it wrong...

Re:Test?

[Findus Krispy]

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

Testing should not be necessary to any serious degree, and if the program were expressed using a semantically richer language the debugger could just lead you through the possible variations so you could be sure you were happy with them.

The answer, IMO, is to do away with programming as we know it and replace it with a purely declarative language than can be read like a specification.

At Uni we used Z to create a formal specifcation for some program which we then type checked, and later animated using prolog. The specifications were incredibly easy to read (once you knew how to do that) and could be reasoned about very simply.

If I could write all my programs using a language like Z that could be automatically animated then I could create programs in the time it takes to write a solid specification, and with a fraction of the bugs. This would be good.

I graduated in '97 and wanted to do a PHD looking at how we could create an automatic Java skeleton around a Z specification, and a system that would complain as soon as the program had broken the specification. That never happened but I often still work on these types of ideas, and feel there is a real future for something like this.

I am convinced there is a better way. Even if programming needs to be this complex, there must be a way to safely allow re-use; to allow complex programs to be built from well tested building blocks.

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?

[Findus Krispy]

That's really funny. Talk about preaching to the converted!

I just thought you, and someone deeper in the thread were bashing the ideas because they were theoretical rather than practical.

Well anyway, I'm off to eat some humble pie!

Re:Test?

[webster]

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

What a great idea! Maybe we could wrap this up into a new development method. We could call it something like, oh, maybe extreme programming. I think I'll hurry and patent it before someone else beats me to it.

Re:Test?

[scrytch]

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

Any consultant that said this to me would find themselves out on their ear. To reuse the stretched and often improbable bridge analogy, it's like building bridges until you get one that doesn't fall down.

Writing to the test is only as good as the test framework, and usually that's "enter this, expect that". Static, known inputs. All you're made to do is tweak the code until it makes the light turn green, but the stability of the rest of the system is still not necessarily sound. Heck, it might become worse, since XP encourages you to write code now now NOW and measure productivity by "velocity", so you may just throw something in to special-case something for that system just to make the damn light turn green.

Tests are great, they're pretty much the basis of the scientific method, but you have to have good tests, and good tests are something that are systemic, and built in to the compiler. Take HaskellDB for example: the type system won't LET you formulate an invalid query (e.g. joining on fields of different types). That's a test -- it's a pervasive test, done very early, and it's one you didn't even have to write. That's the sort of test that the XP crowd seems to disdain, because it's too much "bureacratic structure" and "overhead".

Hand-written tests are basically hand-waving, and most amount to regression tests which only ensure you won't make the same exact mistake twice.

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.

Re:Test?

[Polo]

I think you're right.

She talks about:
- prevention
- recovery

I would make the list:
- prevention
- detection
- recovery

Re:Test?

[Paradox]

Any consultant that said this to me would find themselves out on their ear. To reuse the stretched and often improbable bridge analogy, it's like building bridges until you get one that doesn't fall down.

Sir, I submit you are turning away potential talent. Test-First development is a very positive trend that is spreading throughout the developer community for a reason.

The whole point of test-first development is to add an extra layer of testing and confidence to the whole system. Test-first should never replace any other part of the software development process.

Writing to the test is only as good as the test framework, and usually that's "enter this, expect that". Static, known inputs. All you're made to do is tweak the code until it makes the light turn green, but the stability of the rest of the system is still not necessarily sound.

If you are testing all your edge cases, and you are testing a decent common case, then it fairly comprehensive. More importantly, this practice forces a developer to consider the method they are about to write very carefully before they write it. Even more importantly though, they are a damn sight better than the common cout << "Debug Message" << _member method that so many people use. Tests may not be as flexible as a human mind, but they can happen fast and they can provide an extra level of checks as you refactor code.

Heck, it might become worse, since XP encourages you to write code now now NOW and measure productivity by "velocity", so you may just throw something in to special-case something for that system just to make the damn light turn green.

I believe you are misinterpreting XP. Considering all the extremist propaganda of both sides, this is a pretty common mistake. XP is not about rushing software. It's about steering the development process and having frequent milestones so the progress can be judged. That way many mistakes will be caught quickly and not allowed to paint the team into a corner later.

Tests are great, they're pretty much the basis of the scientific method, but you have to have good tests, and good tests are something that are systemic, and built in to the compiler. ... That's the sort of test that the XP crowd seems to disdain, because it's too much "bureacratic structure" and "overhead".

Ahh, and if all errors were type errors, I'd agree with you 150%. In my experience working with strong, dynamically typed languages, most errors are not type errors, but logic errors. Maybe they were miskeys, or maybe my brain was fogged, or maybe my design assumptions were bad. Static type checking is a grand thing, but any C++ or Java programmer knows that it will only catch certain classifications of bugs.

The "XP crowd" is so diverse (and fractious) that all I can do is say Kent Beck seems to suggest that good tests (as you go) will tend to reveal type errors early. Part of the reason XP espouses pair programming is to aid in the design of comprehensive tests.

Hand-written tests are basically hand-waving, and most amount to regression tests which only ensure you won't make the same exact mistake twice.

Hand-written tests are not hand-waving. They are just another layer of checking that should go into any project. They assist in refactoring, easy maintenance, help document the system (by showing how a method is meant to be used) in code (which is useful), and they force programmers to really think critically all the time. How can more testing be bad?

By the way, thanks for mentioning the Io language earlier. It's very interesting.

Re:Test?

[globalar]

"We need more skilled and better educated engineers, not more language constructs."

Think about what you are saying - is that what management wants to hear?

Re:Test?

[Anonymous Coward]

> > "We need more skilled and better educated engineers, not more language constructs."

> Think about what you are saying - is that what management wants to hear?

And, most importantly, it is wrong.

Take your skilled "engineers". Give them assembly language, with just the I/O specs of the system and no OS.

Now take a underskilled "engineer" using VB to build a sucky windows business application.

Your underskilled guy will outperform the skilled one both in time and quality of the result. Hence skill is not all.

The paradigms we work with were brilliant 15 years ago. Smalltalk. NeXTstep. Object Oriented stuff.

They enabled another generation of comlexity of software.

But the show their limits. An API of thousands of classes is not the way to handle complexity. System of millions of lines of code are not good. Describing temporal relations with strcutral ones is not a good way either.

Of course, no-one knows what the good way is. And it will not be a silver bullet. Just a way to make some even more complex software.

Re:Test?

[shibboleth]

Is it not yet practical to write real software that way because of all the education the programmer would need, or is it that the process would take too long to complete real programs given current toolsets?

Re:Test?

[renoX]

Sorry but what matters in the end is that the software works, so this means:
a) a language which ease programmers life.
b) a language which simplifies testing, integrates tests.

If you look only at a), you're missing the whole picture..

A language designer should look at both!

It is no surprise that she works at Sun: I was very surprised that Java doesn't include any 'design by contract' aspect like Eiffel, and when I tried to use it, I undestood: sloppy libraries where Sun had everytime a new library to make the coffee but doesn't take the time to fix the numerous bugs in the existing libraries for years, lots of workaround to use..

I think that some people forgets that even with the most intuitive language in the world, you need tests and the language should support it!

Re:Test?

[sjames]

Part of her point (and Jaron's) is that no amount of testing seems to manage to uncover the bugs that exist NOW, much less predict the bizarre interactions that will happen when a seemingly unrelated module is added later.

That's a real problem! Development of complex software is in the process of hitting a wall (hard). The various unplanned bizarre interactions must be better controled, and software must get more resiliant. Currently, it's as brittle as it gets. One change, and bam! the whole house of cards comes down.

Feed an electric motor slightly out of spec power, and it will behave slightly out of spec. The difference may not even be noticable. Feed a function slightly out of spec parameters and it will behave unpredictably.

If there's a lot of hand waving, it's because it's a hard problem with no clear solution. I'll bet that when the idea of stored program was first being proposed, that sounded a lot like hand waving as well (you mean a stored program will turn my english like writing into a stored program? What will you use to make that stored program?).

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!

[stand]

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

Capable? Yes, but willing? Not often enough. I think it's true that programmers are often called upon to produce code too quickly, but even when we get all the time we need, we have a tendency to spend our time thinking of new stuff to add rather than making sure what's already in the code base is rock solid.

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!

[hazzey]

Amen! Being a Civil myself, I know all too well about the testing and safety factors that go into design. This goes back to a thread that I read here a while back about "software engineers" really not being engineers. In the words of one of my professors, "Engineers are paid to not be wrong. If they are only 'kind of' sure about their product, people get hurt; bulidings fall."

Re:The two big reasons software is buggy!

[Suidae]

All nuts are the same.

You've obviously never worked with my coworkers.

Re:The two big reasons software is buggy!

[dasmegabyte]

Word. I spent all last week messing around with a fundamental design flaw in visual inheritance in .NET.

Monday I just rewrote the fucking thing I was inheriting. Took me 13 hours. At that point I could start work on the 24-48 hours worth of implementation I had to have done for Tuesday (guess how much was ready for release? here's a hint: fuck all).

Incidentally, I think it's lack of knowledge that bit my keyster on this one. If I had KNOWN the thing didn't work, I wouldn't have messed with it. I just would have done this another way. There are, after all, a fairly unlimited number of ways to do things...being able to say "this way is bullshit and i'm not wasting my time anymore" is an essential skill.

I've written bulletproof code under the wire. But every time I've done so, it's been a very simple program with a very simple set of inputs and expected outputs. It was something I never expected to extend or turn into a framework. And it was something that I had a concrete vision of. A lot of the time, somebody says to me, "I need you to write a FOOing program." I have never FOO'd, nor do I fully understand the needs of the daily FOOer. So I deliver something that helps a few stages of FOO, that has the language of FOOology interspersed throughout, but which is probably only a fraction of what is needed. So I extend it. And I make it more general. And at the end, it's a damn octopus of different expectations and kludgey function.

Clear vision. That helps me get rid of bugs -- even more so than more time. But more time would help, too.

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!

[schroom5]

I've taught software design and engineer and have used the engineering analogy to software in the past.

There is one big difference between building a bridge and software. When you build a bridge it will have many bolts holding it together, but in software the analogy would be having one bolt holding the bridge together. If I use a string library in my code, it will be the same routines that are run no matter where it is called. If the library fails in one part of the application, given the same inputs it will fail in the same fashion in another part of the code.

This lack of redundency is what makes software are to work with. The one bolt has to hold everything.

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?)

Re:The two big reasons software is buggy!

[Yunzil]

I've seen so many requirements documents that lack any form of internal consistency.

Wait, you've actually had requirements documents? I've been programming for 7 years and I've still never seen one.

Re:The two big reasons software is buggy!

[Anonymous Coward]

One nut is the same as the other nut. All nuts are the same.

Yeah, but how come by left one is lower than my right one?

Re:The two big reasons software is buggy!

[T-Ranger]

The individaul PEngs, and the engineering company as a whole, were fined significantly after the investigation. And they licenses were suspended for some time.

What ramifications are their on programmers and developement shops when their software screws up? None.

Re:The two big reasons software is buggy!

[T-Ranger]

If the bolt fails because it was faulty - not because it was the wrong bolt - then it isnt the bridge Eng's fault. If your string library fails its the fault of the string libraries developer.

If all the bolts in a given bridge come from the same batch, one using week steal say, they may all fail. One failing might put enough strain to cause another to fail, and on and on. If all the bolts are the same, and perfectly functional in their intended use, but are used incorrectly, then the bridge can come down.

So you are wrong: a bridge also has one bolt that has to hold everything.

Re:The two big reasons software is buggy!

[Anonymous Coward]

look at the time it takes to QA a bridge that is built.

I can understand if a person is Querying a bridge, but expecting it to Answer is a little too much

Re:The two big reasons software is buggy!

[egomaniac]

If the bolt fails because it was faulty - not because it was the wrong bolt - then it isnt the bridge Eng's fault. If your string library fails its the fault of the string libraries developer.

Yes, and when I tell my customers "Well, it's not my fault. The bug is actually in Microsoft's code", what do you think they're going to say? "Oh, ok, don't worry about it then. I don't mind that my entire ordering system is offline, because at least it wasn't your fault."

In the real world, it's always your fault. You either didn't QA well enough to find the bug, or you found it but didn't fix it, or (on the off chance it isn't one of those two things) you're stil going to be blamed for it, so buck up and figure out a workaround.

Re:Here's an idea

[Professr3]

Ouch.

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

[richieb]

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.

This is easy to say, but it is impossible in practice, except for a small set of problems (like computing prime numbers).

Furthermore, software engineering is engineering, so you have to produce something within a reasonable cost.

As an exersize please submit a proof that Apache web server implements HTTP correctly.

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:That is exactly the wrong approach

[SLi]

It really escapes me why proving SW correctness for properly designed software should be intractable. While it's true that formal methods for correctness proving may not yet be advanced enough, there's no reason why they couldn't be.

A good design process is of course expensive, but with complex projects I think it might be worth it as you save lots of debugging time. And just think about critical applications where the software just HAS TO work, like just about anything that gets sent to space, medical equipment that people rely their lives on, aeroplane controlling systems, missiles and other military technology and so on. Or just think about the added value for a third party library when you get a precise specification and a guarantee that the library works as specified.

Actually I think that saying "you can never produce provably correct complex software" is a lot like saying "there's no software without bugs". It's easy to say, but saying it doesn't make it so.

Re:That is exactly the wrong approach

[richieb]

It really escapes me why proving SW correctness for properly designed software should be intractable. While it's true that formal methods for correctness proving may not yet be advanced enough, there's no reason why they couldn't be.

I don't have a formal proof, but some strong intuition. First of all to prove software correct means that you have to start with a spec that is precise enough. This eliminates about 99% of all projects.

Secondly, if you have a spec you have to show that the software text you wrote produces results as specified. This feels like proving that two programs are equivalent - which I believe is an undecidable problem.

Finally, if you factor in the interactions with the real world, you wind up with a deterministic but a highly non-linear system. These tend to give rise to chaotic behavior, which while deterministic is not at all predictable.

Re:That is exactly the wrong approach

[Derkec]

I tend to disagree. It would seem to be difficult to impossible to prove the correctness of a fairly large app - for instance Microsoft Word. Particularly when that app has to interact with numerous third party drivers etc. Furthermore, as the article states, the number of people who are really capable of "proving" things conclusively is quite limited.

Also, the article makes the point that we often the code does excactly what the coder wanted it to do - that's just wrong because of wrong or changing requirements. If the definition of "correct" has bugs, there's no hope for proving based on that definition. Furthermore, it requires an absurd level of specification when interacting with a graphical UI. The customer really doesn't want to specify the UI, they just want one that lets them get their work done and is "nice".

Re:That is exactly the wrong approach

[SLi]

While I agree with almost everything you said in your comment, I wouldn't throw out the idea of provably correct designs.

You are right that one cannot prove that a design matches real-world requirements - that's the domain that truly is outside our control. The key thing to realize here is that the domains are recursive - you start by proving that the leaf nodes (i.e. the most low level modules) satisfy some properties, and then you can infer from those properties and higher level design some more properties, and so on. Until at last you can prove some properties of the design of the entire system, which should certainly be useful even in real world.

Re:That is exactly the wrong approach

[SLi]

I agree that 99% of all projects don't have precise enough specification for this. I would even agree with a higher percentage. However, producing that precise specifications isn't very high priority now because they aren't used for correctness proofs in the current world.

Proving two programs are equivalent indeed is undecidable in the general case. However I'd say that for any practical program you have much bigger problems if you can't even reason about it's correctness and conformance to the specification. Humans tend to write easy programs that should be easily proved conformant, probably even by computers. Yet the first step would probably be to create a way for a human to write that proof. Computerized verification of a detailed enough proof certainly shouldn't be intractable for any problem.

I think your third point only emphasizes why proving correctness is important. We tend to make assumptions about how the domain interacts with our program and therefore fail to consider the marginal cases. We should rather aim for a program whose functionality is specified and proved even for the marginal cases so we can at least read a "what would it do if X" report.

Re:That is exactly the wrong approach

[bryane]

Perhaps the problem is not that we don't write bugless code, but that we expect to. Code has to be delivered at a price-point in the market, and the number of remaining defects is only one of the factors required to make money.

After, MS doesn't make bugless code - they make money.

Re:That is exactly the wrong approach

[DynamiteNeon]

That's easy to say, but impractical to implement.

When a software designer releases code, the only math he uses is statistics: he will have some degree of certainty that his code will work under the working conditions he expects. Anything that deviates from his perception of the use cases will introduce uncertainty regarding the reliability of the software.

In theory, you could prove that a piece of software is correct, but in practice, the complexity makes it impractical to do so. The best one can hope for under normal conditions is a percentage.

Re:That is exactly the wrong approach

[NoOneInParticular]

Proving correctness is usually not done because to write the specification for correctness is equivalent to writing the program itself. CS has the nasty habit of biting itself in the tail at so many levels that its sometimes tempted to simply give up.

I remember a class once, where the prof and his assistents where very proud of their formal correctness prover. When a fellow student translated their 'semantic' code to simple lisp and executed it they were not amused.

Re:That is exactly the wrong approach

[Anonymous Coward]

For those interested in programming in an executable language yet also proving that the code written is correct I present the following:

ACL2

Its a semi automated theorem prover that runs on programs using a subset of Common Lisp. Thus it can verify property correctness, such as (reverse (reverse (x))) == x where x is a list.

Its been used to model systems such as AMD's K5 floating point division algorithm, and processors in phones from Motorola.

Re:That is exactly the wrong approach

[Anonymous Coward]

"I remember a class once, where the prof and his assistents where very proud of their formal correctness prover. When a fellow student translated their 'semantic' code to simple lisp and executed it they were not amused."

Huh? Why not? The virtue of a formal proof is that it is known that it WILL do what it is supposed to. Why should the implimentation of that be a cause for displeasure?

Re:That is exactly the wrong approach

[Anonymous Coward]

How do you know that your proof is correct?

From my own experiences with program proving, the proof is usually about four times as complicated as the program, and so even less likely to be correct than the original program. The proof adds a lot more work, but no more assurance of correctness.

Even the mathematicians these days are having trouble believing in their proofs thanks to complexity.

Re:That is exactly the wrong approach

[NoOneInParticular]

The displeasure came when we made an infinite loop in the specificiation language. Now they needed a specification language to formally prove their specification language to be correct... Godel striked again.

It's all about the language...

[Lord Graga]

I do C on GBA. I usually make some crappy bugs, but I have never ever made a bug when I tried to do ARM ASM (that language just rocks). Wierd... and up for a thought, since the faster you can go on, the faster you will have to face bugs.

Re:It's all about the language...

[dasmegabyte]

Well, it's a matter of scale, isn't it?

In ASM, you're dealing with a handful of variables, a handful of registers and a handful of operations. You have to do more typing to anything...so you just don't do it.

In C, you're generally dealing with a lot of variables, a lot of operations, a lot of FILES and dependencies and complex functions. When you call PerformOperation( SOMETHING ), it's probably doing as much in ten lines as you would do in a hundred lines of C.

That's why they call it a high level language. It's the difference between a scalpel and a chainsaw. Good thing you don't use Java...all those objects in that complex, bloated framework...it's like wielding a shotgun full of razorblades.

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:The real world is intuitive?

[Trejkaz]

Woman's Logic [tm]

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....

Re:Speaking of mistakes...

[Sique]

It seemed to me that the interview was done on tape and the person who later typed it misheard it, and it slipped through the proofreading.

Re:Speaking of mistakes...

[rune2]

Hey it works for Microsoft!

Re:Speaking of mistakes...

[TigerNut]

You don't need a Java environment to get caught in that trap. In about half of the bigger software projects I've been parachuted into, there were cases where race conditions, memory leaks, and other manifestations of bad design and/or implementation were "fixed" by writing tons of extra code to deal with all the exceptions, exceptions to the exceptions, and runtime issues caused by the extra code.

The thing that I see most often with 'intuitive' interfaces is, like some others have posted, that the interface will eventually be applied incorrectly, and then the problems that arise are fixed by massive amounts of testing and exception handling, instead of redesigning things properly. In the case of OO languages, that most often applies to people not understanding how to identify which constructs in their software should be treated or defined as objects.

Re:Speaking of mistakes...

[sjames]

I keep trying to visualize programmers writing more and more Java code to stave off the inevitable surge of bugs....

Write a web servlet. Watch your mighty web server go down under the load of 3 users. You now understand the Java sandbag :-)

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

Re:Actually...

[Sique]

Interestingly though Victoria Livshits is from the former Soviet Union. What does that tell us about running gags?

The concept of abstraction

[Nakito]

From the article: So, your basic thesis is that programming constructs should be more intuitive to developers, and more closely simulate and resemble the real world. That would enable developers to write software with fewer bugs, right? Exactly.

But this point is just the application of existing principles. When I began learning C++ and OOP, one of the benefits that I noticed was the level of abstraction that becomes available. Your program becomes less procedural and becomes a closer metaphor to the real-world problem to be solved. This seemed to be a continuation of the trend toward abstraction that becomes apparent from the very beginning as you learn how to program. For example, at the most elementary level, abstraction begins with the simple variable: rather than hard coding specific values, you create a more abstract expression like "rate times distance" which makes your algorithm easy to understand. Then trend continues when you learn how to use functions and subroutines, which become freestanding abstractions for the functions being performed. The trend continues further with objects. As the level of abstraction increases, your program really starts to look like a flow chart of its various components, which maps to its real-world purpose. Isn't that all the author is saying?

...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.

Re:...and the wheel turns

[madpierre]

The only thing you need to model the behavior of senior management
is a coin tossing program. (in BASIC)

Intuitive Bug-less Software?

[Ih8sG8s]

In a word: never

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 !

Re:Jaron Who?

[flashbang]

You know - that guy from Subway - he lost all that weight. Oh, wait, that was Jarod. My bad. I agree - Jaron who?

Re:Jaron Who?

[Anonymous Coward]

I dunno, I thought Moon Patrol was pretty visionary. I mean come on, a tank that shoots up and forward at the same time?

Help!

[Anonymous Coward]

I are have virii on my linux boxen!

A toolkit to construct a brain

[StuWho]

I found the article interesting - other posters have pointed out that a lot of the ideas are not new, but in this interview they are stated concisely and clearly. The arguement that programming needs to be more intuitive seems like a no-brainer to me, and I was fascinated by the idea that the fault with OO programming is the very simplicity of concept which contributed to its growth.

What fascinates me most is this Easter-European prodigy's ideas on next gen languages. They sound like a toolkit capable of building a software representation of the human brain in all its complexity (and malice!).

What with these languages and nanotechnology, I'm beginning to think there's not much point in me paying pension contributions... We're all doomed.

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

[Anonymous Coward]

I agree that too many people believe OO is The One Way, especially as pure OO falls flat on its face the instant you consider interactions between objects. Consider a gravity simulator where Planet instance A at the software level did not know of any other planet's existance, and therefore could not calculate the effects of their gravity on its path. Inevitably this gets solved by creating a Gravity "object" that does nothing but contain every object in the universe for the purpose of iterating them and calculating the gravitational pulls for them. But then, this breaks "interesting" uses of such a simulator, say for instance to see what happens if an antigravity body is introduced, as the calculation is now in the Gravity object instead of the Planet object where it could have been overridden.

Or you could cheat and have a global array (or Vector if you wanted to at least pretend now) of all the Planets which every Planet could access and modify.

Re:I agree, somewhat

[Captain Rotundo]

While a bit specific I completely agree. Of course maybe I am just not wired for OO, because I don't particularly like it.

Re:I agree, somewhat

[Anonymous Coward]

OO seems especially screwy at dealing with many-to-many relationships. You can make each object carry around a list of connections, but that gets really goofy when you want to come from the other direction. Its like the 1960's databases.

Re:I agree, somewhat

[MountainBoiler]

I tire of hearing how everything leads to perl. I've seen it, used it, debugged it - and it aint that great.

Perl's 50,000 ways to do a given thing is not that great. The assumption is that those 50000 ways, like the nuts & bolts in her article, are identical, and no one way (or bolt) is superior to the others. That is wrong.

If you read /., you probably think that the Unix Way (TM) is a Good Thing. What is the Unix Way? It is to have small programs that do one thing and do it well. Those small programs can be chained together to do almost anything. Where in that philosophy does it mention to have 12 programs to do the same thing? It doesn't.

Instead, it relies upon a hand-full of usefull and consistent commands and programs that a person can feel comfortable with. Not the latest fad for completing a task that you forget or change in 6 months. Perl leads to un-maintainable code. All languages do, but some become un-maintainable quicker than others.

Sorry for the rant.

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.

Re:I agree, somewhat

[harmonica]

I don't see this as an OO flaw. You are right that OO is not The One Way. Similarities between classes can be expressed elegantly with OOP (by inheritance), but other than that, OOP isn't a panacea. Your particular problem seems to stem from bad design. I don't think that the inevitably in your statement about that new Gravity class is true.

If the design for the problem is right, the solution can be expressed nicely with OOP, classical imperative programming and probably every other paradigm.

I don't know enough about physics to suggest a good design in this case.

Grammer checker bug

[Erick the Red]

The simple division of structures into hierarchies and collections in software too simple for our needs according to Livschitz.

It looks like there's some bugs in the grammer checker michael uses.

What? Why are you laughing?

Re:Grammer checker bug

[Anonymous Coward]

spelling checker bug.

it is spelt grammar, not grammer :)

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.

Re:It's in the implementation

[chromatic]

Good point inheritance and class hierarchies must serve some psychological need among OO professors and authors. They're certainly not the end goal of good design.

Since you bring up Smalltalk, you might like Traits in Smalltalk, research on alternate mechanisms of polymorphism, behavior, and code reuse.

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.

Re:fluff

[Jeremi]

Secondly even if it could be it is focused on the wrong target, it should feel right to the end user/problem domain experts.

Keep in mind that the programmers ARE the "end user/problem domain experts" of the programming language they are using to do their work. So you and the author actually agree here -- just as Joe Sixpack is more productive with an intuitive toolset, so is Joe Programmer.

Programmers should be average. Absolutely not.

I hate to break it to you, but the average programmer is going to be average, by definition. Barring the invention of brain-steroids, that people aren't going to get much smarter. You can either ignore the reality that people's skills are limited, or you can address the problem by providing them with tools that allow them to make the most of the skills they have. The latter solution will provide the most benefit, even if it does mean potentially lower salaries for the few super-geniuses out there.

Re:fluff

[Tablizer]

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.

I disagree, or perhaps misunderstanding the point. Programming is not math, at least not the kind taught in the typical textbooks. The vast majority of programmers will not need/use any math concept higher than mid-level algebra. Perhaps you mean things like predicate calculus or Boolean algebra?

Re:fluff

[Anonymous Coward]

> 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.

Before making a fool of yourself, did you realize that she was a champion chess player ? I bet she knows a lot more than you about the power of unconscious 'feel' applied to very complex problems.

And, yes, code should feel 'right' to the developer, like music feels right to the composer.

It is obvious that the tool you use are obsolete when the software you write don't look 'right', only like a mess of spaghetti, just because the problem is supposed to be complex.

It should not.

We should have tools/concepts that enables the next generation of coders of writing code that 'feels' right.

Even if you disagree.

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.

Re:Would much stronger data types help?

[drank]

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.

I must not be understanding what you're saying here. Most oo frameworks already include a functionally rich date type. And if I were building an app that managed mp3 files among other file types, I'd certainly create an mp3 class to wrap those files. I guess what I'm saying is that in Java or .Net, you can easily write

public void PlayMp3OnDate(DateTime date, MP3 file) {}

and ensure that you're only passed dates and mp3s. What more do you get from a "dependent type system"?

Re:Would much stronger data types help?

[farnz]

Compile time error checking.

Let's say you're writing a system where date is significant, and is worked with. In your OO framework, a function that tries to construct a DateTime for 2002-02-29 will cause a run-time exception. In dependently typed systems, the compiler can detect that your function can attempt to create a date of 29th February 2002, and stop you; the only need for runtime error checking is thus when you take input from the outside world.

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?

The Perfect Solution!

[Anonymous Coward]

The only way to get rid of buggy software is to get rid of imperfect hu-mans!

Torpor also lifts things if asked nicely!

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.

Re:But is the real world intuitive?

[kurosawdust]

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

However, by the same token the very systems which make us "intuitive" and pattern-oriented are subject to the laws of science which are grounded in logic, no?

I agree with you, but only temporarily - I think it's only a matter of time (more specifically, time to figure out exactly how we do this kind of thing)

Re:But is the real world intuitive?

[mariox19]

Hats off to you! That is "+10 Insightful."

I was impressed...

[calebtucker]

"I envision a programming language that is a notch richer then OO"

I was enjoying the article up to this point, but then I lost total respect for her.

Re:I was impressed...

[Anonymous Coward]

... OO means her rack are real, since only fake OO cost anything.

"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.

it's like that already...

[Anonymous Coward]

IRL most people don't mind bugs unless its in /usr/home. Likewise if a bug doesn't affect my userdir, the admin can go fsck himself for all I care.

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. :)

Re:A Programmer's Credo

[chromatic]

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.

Do you find this at odds with the rule about freezing the design before you start coding? If you find a flaw in the design, will you only implement the redesign in the next version?

Re:A Programmer's Credo

[StrawberryFrog]

I accept that humans are fallible ... I will design the structure of the program, and freeze its feature set, before I begin coding.

Speaking as a programmer, these two rules are in conflict.

Re:A Programmer's Credo

[JoshWurzel]

It sounds to me like most of those need to be accepted my MARKETING people, not the programmers. Its marketing that says "oh, major crash? Just, uh, fix it. Oh by the way, the release date is next tuesday."

Re:A Programmer's Credo

[Dirtside]

There's no rule about freezing the design, only a rule about freezing the feature set.

I Think You Should Be More Explicit in Step Two

[jazman_777]

Bug-free code? Step 2 being "Then a Miracle Occurs." From a Sidney Harris cartoon. (Look here.)

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?

Maintainabilty is number one in my book.

[davidsheckler]

I've changed how I design/write code in the last
few years. I used to be an Object oriented fanatic
but I've found that the increased levels of
complexity it creates also matches an increase
in the effort to maintain said programs. Now,
I'm sure someone will say that I don't know how
to properly design/implement systems but I have
to disagree. I do know how it's done and how's done
is not good enough.

Polymorphism is easy to overuse, use it when you have to, no more. Composition is your friend use it when you can. Try to keep the core logic in
a few main files. Clarity and maintainability should be your second concern after 'make it
work'. Test, test, test is number three.

The rest of my advice would fill a small book but
most things are best learned though trial and
error.

But why do you need to test?

[brokeninside]

Writing test cases is taking the exact same approach using a slightly different tool. You must test every condition only if you don't know whether or not your program design is functionally correct. This akin to attempting to solve an algebraic equation by writings tests to rule out all of the wrong solutions.

The opposite approach should be taken. A design should first be proven to solve the problem. Then the implementation should be proven to implement the design.

Re:But why do you need to test?

[JohnGrahamCumming]

Yes, I agree with that statement, but given that it's impractical for real-world programmers to do a formal proof from a specification to code, I'd rather write tests.

It's true that there's lots of work going on with things like the Z notation and work on getting the specifications right, but real world examples of soup to nuts products of formally specified and proven code are few and far between.

John.

Re:But why do you need to test?

[*weasel]

exactly. unit testing is smiply treating the symptoms instead of treating the disease. it's at the wrong level of their debate.

they want software to be intuitive, with levels of fault, and 'programming' to be done nearly entirely at the design level. When building a house, generally design decisions are the biggest concern. With programming, it's more often the actual construction.

If your roofers botch the shingling you might get a leak, but the result is not catastrophic the way an improperly designed roof woudl be. In software, any construction bug is catastrophic, while any design bug results in more graceful shortcomings.

Now, what these paid-for-pundits are suggesting might not be possible, but that's the level they're holding their discussion on.

They want coding to be done entirely on the design level. Rough carpentry is not done by architects. (Though to extend the analogy, 'materials' coders would certainly still exist to create new building-blocks for designers to use).

Ideally this is what object-oriented and 'visual' programming were both supposed to do for the industry. It seems to me that they're primarily lamenting that even with all the effort invested, no existing paradigm has actually delivered on the root promise.

Of course, this entire discussion is largely moot for actual coders. While they're pontificating form ivory towers, we've got deadlines - and they aren't giving us anything we can use, they're just restating the problem.

Re:But why do you need to test?

[v01d]

Yes, I agree with that statement, but given that it's impractical for real-world programmers to do a formal proof from a specification to code, I'd rather write tests.

Ah, but by the same token it's impractical for real-world programmers to exhaustively unit test, so I'd rather the best possible development methodologies were used. Of course the remainder of the project time frame should be used testing.

I'd rather tell my boss I didn't have time to completely test, than tell my boss the code doesn't exist yet.

Re:But why do you need to test?

[HenryFlower]

they want software to be intuitive, with levels of fault, and 'programming' to be done nearly entirely at the design level. When building a house, generally design decisions are the biggest concern. With programming, it's more often the actual construction.

In software, design *is* construction. There is no theory and standard practice of software construction, the way that there is for engineering, architecture, and construction (and many decisions are made construction-time rather than design-time in those disciplines anyway). Without a workable theory and model, you can't design much anyway.

We are at a stage of software development similar to where construction was thousands of years ago, except that we are trying to build complex skyscrapers and suspension bridges, rather than pyramids, which might be in our abilities.

Re:But why do you need to test?

[chromatic]

I'd rather tell my boss I didn't have time to completely test, than tell my boss the code doesn't exist yet.

"Dear boss, I don't know if it works, but I'm finished. What's my next job?" :)

Re:But why do you need to test?

[JohnGrahamCumming]

> I'd rather tell my boss I didn't have time to completely test, than tell my boss the code doesn't exist yet.

At the company I work for the rule is that code isn't finished until there's a test suite for it. My general experience is that code without tests doesn't work.

John.

Re:But why do you need to test?

[v01d]

the rule is that code isn't finished until there's a test suite for it.

As it should be. Same rule at my company, however when the implementation date has arrived...

Actually the stress on my last post should have been on "exhaustive". It's not possible to test every case and all error handling; there's always something that will be missed. Proper design techniques are seperate from testing techniques, but just as important. Everyone has a favorite, but placing more importance on testing than design (or vice versa) is asking for problems.

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.

And how does she suggest we we do that?

[pla]

so we should be expanding the pure object-oriented paradigm to allow for a richer set of basic abstractions

It takes some fairly fancy code to translate even pure C into something the CPU can use directly.

It takes another layer of fancy code to add on the idea of "Objects".

Then another for the idea of a "Virtual Machine", which regardless of how "clean" it ends up, still has to run on a real machine.

So we should add yet another layer, to make code even more abstracted from the actual underlying hardware?

Ignoring the performance issues involved in such seemingly-noble ideas, it also adds in one more layer where conceptual designs take on a degree of ambiguity, dependant on the translation to the next layer down to make those abstractions more concrete. Each of those layers introduces MORE, not less, potential for serious-yet-difficult-to-track-down bugs.

Will MS's OO++ make the same choices as GOO++? If not, problems will appear. Hell, we don't even have 100% compatible VMs at the moment, yet we should move on to the next level? Somehow, I have to doubt Ms. Livschitz works in the "real" world. A true "Computer Scientist", rather than a "Software Engineer".

In a perfect world, we'd speak to our computers like they do on Star Trek, and the computer would understand our intentions. We do not live in that world (nor will we for quite a while). We live in the world where CPUs do number crunching and nothing but number crunching. They don't interpret, they don't think, they don't "understand" our intent with a given blob of code, unless that code falls into the VERY narrow range of formal imperatives the CPU understands.

Got any GBA ROMs?

[Ayanami Rei]

^_^

Testing could be (slightly) overrated.

[pokeyburro]

One of the drawbacks of testing is that it only tells you whether the code works with the tests you put into the suite; meanwhile, you may have much less confidence in whether the code will always work in every situation in which it will ever be used.

In your case, you developed a very comprehensive suite, and I'd assume from your post that you know what you're doing, so your confidence level would be high anyway. (Namely, about 98%.) The problem is that you had to laboriously develop this suite and ensure that it covered (at least at first) all of the code; and then when/if more code was added, the suite would have to be expanded to cover that, and so on. Building the suite isn't easy; it takes much effort.

One of the holy grails of programming is proving program correctness - if A, B, and C are true, and program P is executed, verify that C, D, and E will always be true afterward. Straightforward enough, until the program gets over about, oh, ten lines. :-) In some cases, though, it feels as if the proof effort could be automated - I often find myself worrying over large stretches of code that is rather boilerplate, just shuffling around Java Collections or simple C structs and such - and if it could, it would mean a large reduction in the amount of test suite I'd have to develop to cover the same amount of code. All I'd need to do is come up with the pre- and post-conditions, which I would've had to do for the test suite anyway.

Later, if the code must be extended, the prover software could theoretically tell me whether the post-conditions will still hold, and if not, when they won't. Then I could either write code to handle the problem cases, or rewrite the post-conditions, and run the prover again. Comparably less effort than extending the test suite.

Correctness proofs aren't Ms. Livschitz' thrust, I admit, but I feel it's the ultimate key to bug-free code, and her promoted ideas of a more strict component architecture and stress on closer adherence between code objects and real-world objects lend themselves to making these proofs more achievable. If we had more universal and strictly defined code constructs for entities such as people, business transactions, chemical reactions, etc., we could be much more confident in the soundness of the programs we build with them.

Re:Testing could be (slightly) overrated.

[JohnGrahamCumming]

I'm with you on the formal methods, they'd be great if they were practical. I was a PhD student at Oxford's Programming Research Group and did study formal methods, but for real-world programming examples writing a good test suite as the pragmatic thing to do today.

I agree that it takes work and it takes work to keep the test suite up to date. It's a discipline to write new code and write the tests to go with it, but I truly believe it's worth it. The number of times I've changed something in POPFile and run the test suite only to find that my new code was wrong, or affected something else, makes me feel that it's worthwhile.

John.

Re:Testing could be (slightly) overrated.

[pokeyburro]

I also feel testing will be around for a good long time, particularly in areas where no one even knows what the pre- and post-conditions should be. In GUI code, for example, one post-condition ought to be that the interface that appears be "user-friendly". Personally, I have no clue how to define that formally...

In any case, there's no arguing with results. While it may not ensure 100% bug-free code, testing certainly gets one a great deal of the way there, and it's indeed too bad that Ms. Livschitz didn't give it more of a nod.

Re:Testing could be (slightly) overrated.

[be-fan]

You know, with languages like Haskell and Clean, where you have tools that can run proofs on the code, you could eliminate many programming errors automatically, and then devote your testing time to other areas.

Re:Testing could be (slightly) overrated.

[madpierre]

Intuitive bug-free software development. Ahh if only.:)

This reminds me of the VIPER Microprocessor project. The goal was to produce a design for a processor for use in critical applications that could be mathematically verified as being bug free. I seem to recall someone proving that such a goal was impossible.

(google on viper microprocessor project) or this link for a brief intro:

www.dcs.gla.ac.uk/~johnson/teaching/safety/repor ts /brian_wichmann.html

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.

Re:Try NakedObjects: behaviourally completalicious

[kin_korn_karn]

The way I originally learned OO was that objects are analogous to what are now called components. That is, objects should be wholly self-contained - every class is its own model, view, and controller - and you hook them together through composition.

Where did this go?

Re:Try NakedObjects: behaviourally completalicious

[Anonymous Coward]

Am I missing something? Aren't there 3 classes here that are hooked together through composition?

Duh.

[blair1q]

This is the sort of thing Niklaus Wirth was on about 40 years ago.

Of course containerism is weak. It's the result of the application of weak programmers to the rich feature set of modern computing architectures.

Tell you what. If you're too dumb to write good code, get a job flipping burgers (or "programming" in java) and stay the pecuniary fuck out of my way.

Video machines...

[Skiron]

Seeing as Java was originally designed for video recorders and washing machine firmware, and still shows that...

Birthday

... I will just say...

... say away from Java. It is really pants. I still can't get over the CPU resource it needs, and also the non-forgiving attitude of it's lameness.

Nick

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.

Better Software Management

[vatsal]

Here's one good article on java.net about a software development team's quest for better software development

What I Want To Know About Your Process

i am glad we follow all this :)

I told you that would happen!

[Anonymous Coward]

You should have installed Windows XP like I told you to.

Gotta go. I just got a new message in Outlook.

TTFN

+5 (Insightful)

[Anonymous Coward]

This man speaks the truth!

Efficiency -vs- Security

[telbij]

This article makes some good points in that OOP as we know it is not rich enough to successfully accomplish what it set out to do. The problem is that an OO language like Java forces everything into rigid tree structures. This works flawlessly for a system like your average GUI, but for so many problems you end up building objects that are really just collections of functions. Furthermore, if you want to optimally re-use your code, you may have to define some really unintuitive object hierarchies. And if anything changes in the design spec you may have to go back and change everything.

Why? Because code reuse in Java is only as good as the original object spec, which is likely to not be as good as the specs on the individual functions. A more flexible way to define objects would be to create sets of atomic functions and data. Forcing objects into a tree means that many times the final solution won't match the description of the problem intuitively.

But if you want the flexibility of object built from atomic functions then you suddenly fling the door open for misuse by novice programmers. That's why languages like Java really are the best solution available for the unwashed programming masses. They don't require the strict discipline that more flexible languages provide, but at the same time they prevent many efficiencies that could otherwise be had.

Soviet Girls

[starshot]

Why are there no coder girls from the US? /contemplating move to russia or india

His hair also grosses me out

[Anonymous Coward]

It would be amusing for someone to shave his head when he is drunk.

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

[Anonymous Coward]

And in PHP:
error_reporting(E_ALL);
Not as potent as "use strict" but at least it'll tell you if you use an undefined (read: misspelled) variable.

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

[ajs]

Bad programmers can make hash out of anything. Good luck with that. At my company we take the startlingly bold approach of not hiring the bad programmers.

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

[Anonymous Coward]

"No more buffer overflows EVER"???

WHY? When any monkey can write some buggy native perlmod? whoops.

...anyway you have *loads* more potential for code injection and suchlike. Don't get me wrong, I like Perl, but frankly, security ain't a good argument for any language. That's what Sun said about Java. And then LSD found you could walk right out the sandbox by replacing .'s with /'s in the classloader. Whoops. (Fixed in 1.4.2, which was "recommended" because it "fixed several bugs". No actual mention of the severity of the situation here, no, you had to go to *bugtraq* for that).

Blah blah. Anyhow, I'm sick of hearing Sun talk. they're very good at talking and making me feel good, but I can't code in a language that resembles a system language but performs like TCL. I'll actually start caring (and auctioning off my organs on eBay) when they *really* deliver.

Thanks for listening, like anyone cared anyhow. :)

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

[Pippity]

"It was full of little special cases and everything broke the rules in at least 3 ways."

Well yeah, there's more than one way to do it. ;-)

Re:Sorry, but I hate Perl

[drgnvale]

Too bad no one has combined the good features into a master programming language.

As you said, learn Lisp. Specifically Common Lisp.

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?

Re:Sorry, but I hate Perl

[ajs]

The latter... but I have no idea why such practices are rare... it's not like having your best programmers vet the new guys is hard.

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

[Anonymous Coward]

Obviously you are not a practitioner of modern project management techniques. Reality should never impinge on a heart felt whim!

Re:Budgets and schedules

[iso]

Sure, but many times it's the engineers/programmers who are involved in the time estimates in the first place. If marketing arbitrarily chooses a date, sure it's not the engineer's fault, but in my experience it's the engineers themselves that quote the 'one week at $100' figure.

Re:Budgets and schedules

[Anonymous Coward]

In reality they are told "Here's what we want, here's when we want it, and here's the resources we'll give you. Now give us an estimate. By the way, we retain the unilateral right to expand the scope of the project up until launch with no concommitant changes to schedule."

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.

Re:Budgets and schedules

[crashthud]

Not to mention the "Oh, we brought them your estimate but they won't pay that much. So we said we can just leave out these couple of features. Oh, and they changed the platform they want it on and could you add just a little web version too?" effect.

Re:Budgets and schedules

[richieb]

Sure, but many times it's the engineers/programmers who are involved in the time estimates in the first place.

I didn't imply that the programmers do any better at estimating.

However, somewhere along the way we forgot the meaning of the word "estimate":

to judge tentatively or approximately

to determine roughly

So if a task is estimated to take 2 weeks, everyone assumes that it will take exactly two weeks.

Furthermore, the earlier the in the project life the estimates are done the more inaccurate they are, as you know little about the obstacles you'll be facing.

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?

[SLi]

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?

You seem to think about it the wrong way. You don't go and write software and then start to think about its correctness. Rather the program must be designed so that it can be proven to be correct. Big difference there.

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?

Well, the point of the (in this case formal) specification is that it's a lot simpler than the implementation. Of course you can never prove that the specified problem is the one that your customers ask you to solve, but a lot more you can. And if the specifications of some SW module are usable as a abstract component in the specification of a larger system, they can be further verified to be consistent with what the larger system is doing, thus drastically reducing the possibility of having specified something that doesn't make any sense.

Abstraction is the key to specification, just as in traditional software design.

Re:Is software engineering a form of engineering?

[richieb]

You seem to think about it the wrong way. You don't go and write software and then start to think about its correctness. Rather the program must be designed so that it can be proven to be correct. Big difference there.

OK then. Given the http spec can write a provably correct web server? :-)

Well, the point of the (in this case formal) specification is that it's a lot simpler than the implementation.

I disagree. I think that formal specs are much harder to write - that's why nobody does it.

In fact, source code is really just a very precise specification of what the computer has to do. It's so precise that it can be translated into an executable form automatically. :-)

Re:Is software engineering a form of engineering?

[SLi]

In fact, source code is really just a very precise specification of what the computer has to do. It's so precise that it can be translated into an executable form automatically. :-)

Yes, that's true. The problem with it is that it cannot easily be split into abstract parts and be thus reasoned about. You can reason about bits and bytes, but that doesn't get you very far.

For example, we could specify (a silly example :-) that f() is a function that always returns a prime number. This can be a very precise specification of the requirements of what f() must do - it must return a prime number. It's about abstraction, we don't specify anything we don't want to specify at this level.

Then we have a lower level specification that satisfies the higher level specification - for example, we specify that the function f() always returns a number from the set {2,3,5}. Then we prove that this satisfies the higher level specification, ie. f() really returns and it returns only prime numbers.

Then we get closer to the real implementation - we specify that f() always returns 3. It's easy to prove that this satisfies the former specification.

Now we write code for a function that always returns 3 and prove that it matches the specification. And suddenly we have an implementation of a function that always returns prime numbers. Other implementations might be possible.

Ok, this is too trivial an example. But a similar thing could be made for, say, a sorting function. We can specify that a function returns its parameters sorted. This way we have split the problem space into smaller parts: We need to prove that the given function works as specified, and then we can use the proved properties as axioms (ie. that the list is sorted and that it contains the same elements as the original list) in the higher level specification.

Re:Is software engineering a form of engineering?

[SLi]

OK then. Given the http spec can write a provably correct web server? :-)

And yes, I argue this can be done. Though with the current level of formal methods, it's quite a heavyweight problem. But it's a developing field. :)

Re:Is software engineering a form of engineering?

[plusser]

As an Electronic Engineer in the Aerospace industry I have to work to certain tightly defined regulations. My job is to ensure that the components used are of a suitable quality that can withstand being mounted next to a highly vibrating jet engine.

The choice of hardware when developing a reliable software system is more important than the software itself. The problem is that some microprocessor systems are unreliable, either due to the operating temperature range or its design. In addition latest microprocessors do not work reliably at altitude (i.e. on an aircraft in flight) either, as the effects of atmospheric radiation interfere with they operation. Many people would see software failures in these situations, and complain to the software vendor, when in fact it is the hardware that is "at fault".

Assuming that you have sorted the hardware out, the next problem come to what operating system to base the software on and what programming language to use. In many situations these decisions are made for political reasons within a company rather than what is actually the best for the application.

Some programming languages and operating systems are inherently unstable as they do not support real time applications correctly. Other programming languages have constructs that can risk memory corruption when registers and variables are transferred between functions as they require the passing of memory locations and stack points (classic example is C). Fortunately OO programming languages prevent this as the variables are transferred in a defined manner, and the compilers can be set up to ensure that correct parameters are passed between functions.

In some respects, true software engineers (I'm not talking about software artists that write code to make Windows look good here) have a harder time than electronic engineers. When an electronic engineer requires a complex function they are more likely to find an off the shelf proven component (such as an Analogue to Digital Converter), that can be qualified to operate in that particular situation. A software engineering may have to write some of the most basic functions themselves, as they may not have a certified piece of code to use.

The bottom line is that is you are looking for code that has the fewest bugs, use reliable hardware, be careful at which operating system and programming language you use, and make sure your documentation is up to date. When this is done, then you can invest time and energy in testing your code to ensure that it meets your customer's specification.

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.

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.

Re:Is software engineering a form of engineering?

[Anonymous Coward]

given the http spec can write a provably correct web server? :

If possible, that's nice, but remember that the spec that matters is the unwritten IE/Netscape/Opera/Mozilla specification.

Re:Is software engineering a form of engineering?

[plusser]

One of the biggest bridge disasters in the UK was the Tay Bridge disaster of 1879 (http://www.tts1.demon.co.uk/tay.html for further information). The board of enquiry after this accident concluded that "The fall of the bridge was occasioned by the insufficiency of the cross bracing and its fastenings to sustain the force of the gale.". In a way this supports some of your arguments that certain factors were unknown at the time of bridge design. However, the use of X-rays in this particular case would not have helped as the design was flawed and inspection of components would not have helped. What I would like to point out is in a real engineering application, the line between hardware and software is very blurred, and they affect each other.

Re:Is software engineering a form of engineering?

[richieb]

The board of enquiry after this accident concluded that "The fall of the bridge was occasioned by the insufficiency of the cross bracing and its fastenings to sustain the force of the gale."

Mistakes are made in construction of bridges and building (i.e. they have bugs too). Sometimes the failures are catastrophic. This is the nature of engineering.

A very enlightining book on this subject is Henry Petroski's "To Engineer is Human".

Reinventing the Wheel

[Anonymous Coward]

The poor woman has never seen Smalltalk.

Intuitive?

[DrPlutoMadre]

Intuitive to whom? Does anyone know what intuitive really means for programmers? I would not mind never seeing another IDE, mysef, but some people find these very intuitive.

Re:Intuitive?

[Anonymous Coward]

It might not be that bad, I am currently tring to switch out of the win32 ide develpment into the linux development model and the only thing holding me back is the lack of a good intuitive text editor (Ie edit from the MsDos days. But maby its just me

What's the point?

[Anonymous Coward]

Unless this article was translated from Hindi, what's the point? As a service to the vast numbers of unemployed Java programmers, here's how to theoretically write more reliable software on that next job you won't be getting!

Why not give us practical information, like strategies for picking winning lottery numbers based on the digits of your unemployment checks.

P.S. Why not a discussion on good second career prospects for programmers. While I have a job, nearly everyone I know is out of work, or about to be. Perhaps the time to prepare is while we still have jobs.

OO cannot model changes in state?

[aricusmaximus]

Very interesting article - her biggest idea seems to be that objects are too rigid to change over time - the lack of intuitive ways to say something changes over time -- for example, you can have a "coffee grounds" object and a "water object", but how do you model the brewing process to make coffee out of those two objects?

"The sequence of the routine itself -- what comes before what under what conditions based on what causality -- simply has no meaningful representation in OO, because OO has no concept of sequencing, or state, or cause."

I'm far from an experienced programming expert, so maybe other Slashdotters care to argue/defend her point?

Re:OO cannot model changes in state?

[Javagator]

how do you model the brewing process to make coffee out of those two objects?

Coffee potOfCoffee = new Coffee(water, coffeeGrounds);

Personally, I have never felt constrained by the Object Oriented model.

Re:OO cannot model changes in state?

[Trejkaz]

We already have interfaces Runnable, Action, and so forth, invented by every API under the Sun, to deal with processes. Then all the process has to do is execute the appropriate sequence of commands, pouring the water over the grounds. Presumably you need a coffee machine to do thing, so:

CoffeePot pot = new CoffeePot();
new CoffeeMachine().brew(grounds, water, pot);

It sure isn't rocket science.

I certainly don't understand how a process isn't an object just like anything else.

Re:OO cannot model changes in state?

[aricusmaximus]

Problems with your model:

1) It's an instantaneous model - it treats brewing as an atomic (all or nothing act), where someone may want to try and model brewing coffee a continuous process that takes time (as it does in real life).

2) There's no obvious way to know that the water and grounds are consumed by the brewing process -- but the pot is not.

3) If the process is interrupted, what is the intermediate state of all the objects? Should we still have separate (and "unconsumed") water and coffee grounds objects? Or are other objects (weakCoffee, partiallyUsedGrounds) created?

Re:OO cannot model changes in state?

[Trejkaz]

And since you're making some kind of apparent attempt to argue, you should finish by saying which of these three deficiencies couldn't be solved by an OO solution, and why.

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.

I to not speak marketing-ese

[Anonymous Coward]

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"

Say What am I in a object-oriented paradigm ?
They told me it was a cube.

Re:I to not speak marketing-ese

[Anonymous Coward]

Paradigm, four nickles. Same same.

The proof of the pudding is in the eating

[brokeninside]

Yes, let's look at this objectively and from an empirical standpoint. What real world examples do you have that I am wrong? What real world examples do you have unit testing will eventually eliminate all bugs prior to putting the product into production?

Also, if the statement that 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 is correct, when combined with the statement that the real world is infinitely detailed, and thus so is the problem domain, the conclusion is that it is not possible to prove that a design properly implements real-world requirements. I reject this conclusion.

Some ideas

[Anonymous Coward]

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!

What's intuitive??

[EmbeddedJanitor]

The only things that are truely intuitive to humans are those things directly linked with survival: sex, food, sex, shelter, sex, defence, sex.

Now I really struggle to see how one can dress up programming to be like any of these though I do admit getting a horn when I see a reaaly good linked list.

Software is inherently chaotic and complex. I think any attempts to say otherwise are just a front for pushing some new case tool or whatever. What sets geeks apart is that they are wired in a non-intuitive way: hence the ability to program and the problem coping with sex.

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.

PHD in Hand Waving

[sadangel]

It seems many people are anxious to criticize and gloss over what they think solutions to these problems are, when in fact, they don't bother with the mundane details that are, in their minds, certain to be trivial.
Intuitive development! What a fabulous idea! All this time we've intentionally been doing everything ass-backwards just for jollies. Say, why not just make a computer that understands speech and does what you tell it to? That's it, all our problems are solved. Now those idiot software engineers can finally do things the right way.

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.

Re:Bug-less Software?

[alan_dershowitz]

This is very dependent on the platform. I've been developing Oracle Forms now for a few years, and there are user actions that the runtime environment simply has no way of preventing.

It's not necessarily right to blame the programmer, either. Sometimes both the user and developer are just stuck on a crappy platform.

Re:Here's an idea

[Anonymous Coward]

Yeah, I heard about you Microsoft moles within Slashdot. You've been specially trained in karma building so you can erode the OSS movement from the inside by relentlessly trolling people to death once you've got excellent karma.

Don't need to have bugs

[Anonymous Coward]

I had an interesting experience with bug free code.
Having been programming for living for a few years I stopped to pursue some other goals. After a couple of years with no programming at all I started a small programming company. The very first product out the door was an accounts payable, then the AR. Much to my amazement neither one of them had any bugs, besides a few typos.
It tought me that it's possible to do inspite of the "everybody knows it cannot be done".
I also realized that the difference was that my challenge was no longer writing code but trying to run my first business. I always need a decent challenge or it get's booring. I had lot of challenge in ensuring money was on the table.
The other difference was we worked in pairs. One designed the flow and the other coded. Having good specs and flows to simply solve each modules problem made it simple.

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.

Psychoanalysis

[ZeroExistenZ]

I think she just wants to accentuate her importance and *intelligence*.

"I come from several generations of mathematicians.
My father, for example, is a world-renowned expert on some areas of functional analysis "

She needs to achieve and keep up with her name, Me thinks.
The pressure...

"When I first became a developer on large, real-world projects at Ford as part of an elite development group."

"Mathematicians, who feel comfortable with purely abstract syntax, spend years of intense study mastering certain skills"

In contrast;
"Programmers are "average" folks; they have to be, since programming is a profession of millions of people"

She cannot grasp the fact someone not having studied as much as her can program at all, it seems.

Actually she's telling us; "Programmers are too stupid to NOT write bugs, it has to be!" and logic fades..

"I'm not an average programmer; I'm L337, F34r M3!"
I know where to look when there's some H4x0r trying to start WWIII to prove him or herself.

How could they forget the most important one !?

[Anonymous Coward]

... don't write it in Java!

I've never heard Java described this way before

[ChiralSoftware]

"Java technology, in contrast, enjoys exceptional immunity to viruses because of its sandbag architecture."

I've never heard of "sandbag architecture". It must be something that Sun came up with to compete with .NET?

----
Create a WAP server

Re:I've never heard Java described this way before

[Mybrid]

Mmm, in bowling (yeah, ok, I admit I use to bowl) sandbagging was basically under-performing, sluffing off, deliberately under-achieving so as to get a handicap. Sounds like Java to me.

Java, quite frankly, isn't prone to viruses because most viruses attach desktop systems and most desktop system don't have a JVM running.
How the heck would the virus spread if in fact only 1% of the desktop computers, if that, at any given time is running Java?

That's sandbagging alright!

-Mybrid

Re:SHE? Pop a kid, dear, not a debugger

[Anonymous Coward]

I would only hope she knows how to give me head ... head and house work, outside of that ... they are useless.

How about

[Cyno]

KISS instead.

If we keep everything simple then maybe it will be easier to read it and program with it.

UNIX is a philosophy about making your environment conform to how you like to work. The commands can be aliased to whatever you feel comfortable with. You can choose what "shell" you prefer to work in. Graphical environments are not any different. And I think programming should be similar. If we had a bunch of easy-to-use and powerful libraries maybe more code would be written faster and with less bugs.

Object Orientation is an excellent way to reuse code and get things organized. Its just like structured programming with a few extra rules/guidelines.

For example if you could create a new window with something like this (Sorry, I like Perl):

use *tk;

my $window = new tk;
$window->title("new window");
$window->menubar(theme => "generic");
$window->toolbar(theme => "generic");
$window->textarea(fixedsize => 800x600,
data => "Hello World.");
$window->display;

It might get more people hacking.

This is a stupid example, but things can look just at least as simple in other languages if we work hard enough at it.

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?

[ahdeoz]

Smalltalk was well ahead of its time. And then the 80s came and went. It's ancient now, and still mostly useless. People still *use* Pascal though.

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.

Re:Try Objective-C maybe?

[scrytch]

Objective C can be, well, Objectionable C sometimes. There's a nice little language called Io that's similar to Self or NewtonScript, that is developed primarily on OSX, and includes an Objective C FFI. This means you can develop the low-level bits in Objective C, then script messages to it in Io. I'm told it does work with GNUStep as well.

Io won't give you bug free software any more than ObjC will, but it will make writing software, bugs and all, a lot more fun :)

Re:Try Objective-C maybe?

[scrytch]

Hm, that seems to need the "www" in front of it, or it gives you the author's homepage. fixed link here.

Re:Try Objective-C maybe?

[RevAaron]

And people still use Smalltalk, too. I wouldn't say that Smalltalk is ancient now, in any way other than age. It is over 30 years old. So sure, it is a lot older than Java, but younger than other languages still in wide use. And as far as the technology behind Smalltalk is concerned, it is still breaking ground, evolving. It is still ahead of its time, doing things in ways that everyone else won't be until another 10, 20 years.

And it isn't useless. The only mostly useless language I have known is PILOT. Smalltalk may not be used everywhere C++ or Java is, but in most of the places those langauges are used it would be a better choice.

Bug less software

[Anonymous Coward]

Company can achieve bugless software if they hire and train more quality software tester. Seems strange that some company spend hundred of millions of dollar in software development and barely can afford a staff of QA to make sure the software is working properly when shipped.

Summary of article:

[funbobby]

1) Programming is hard.
2) Programming shouldn't be hard.
3) A bunch of yammering that never even attempts to answer why 1) and 2) are true or what could be done about it.
4) Java is cool.
5) Assorted other buzzwords.

Don't bother reading it, unless you want to be impressed by how long someone can talk about absolutely nothing.

Domain specific lianguages

[Anonymous Coward]

I've been thinking about this complexity related issue, and one aspect where I think we are heading, and we are already doing this, is to write domain-specific languages.

Thus, the building blocks could be written efficiently, and under the control of professional programmers, while the actual application environment is controlled by a cleaner language syntax suitable for anyone to use.

This is why I think Java tries to be in both camps and is not succeeding. Same with C#. Ditto for Python and Perl.

Javascript is somewhat closer, but more domain-specific languages could make sense long term. Examples:

game development (Jamatic), end user UI development (Hypercard), business (Excel macros), 3d graphics(various modelling languages, VRML)...

--Kent

Ohhh... I get it!

[Anonymous Coward]

1. Create "supposedly" intuitive software development language.
2. ???
3. Profit!

Works for me.

absolute proof, unqualified developers, OO

[Mr. Slippery]

But unlike mathematicians, programmers are taught to think not in terms of absolute proof, but in terms of working metaphors

In the Computer Science cirriculum I studied, we did formal proofs of correctness. We learned mapping abstract data types to concrete implementations. We didn't discuss "working metaphors" at all.

Programmers are "average" folks; they have to be, since programming is a profession of millions of people, many without college degrees.

And that's the problem. Many, if not most, people developing software are simply not qualified to do it. It's like we have the guys working at Jiffy Lube designing cars.

Then object-oriented programming took off. Developers could, for the first time, create programming constructs that resembled elements of the real world -- in name, characteristics, and relationships to other objects

OO techniques have failed exactly because software objects have very little to do with real objects. While OO languages and principles can be useful, most of the gain is simply encapsulation and abstration.

Yuh Huh?

[Greyfox]

That's an excellent idea! For example, on my last project we had a validateFieldData function which, as the first thing it did, called strlen on the field string. That worked great until the field wasn't there and that pointer was a null. Then the program sigsev'd.

Contrast with Java, where we'd have a validateFieldData method in our object which would, as the first thing it would do would be to call fieldData.length() as the first thing it did. Instead of getting a null pointer dereference which would cause the program to crash, we would get a nice NullPointerException which our programmer could then handle thusly:

try { validateFieldData(currentToken); } catch Exception(e) {} // You'll find about 250 of these in his code.

That's obviously a lot better than having the program crash with a sigsegv!

Re:Yuh Huh?

[dasmegabyte]

There's no cure for laziness.

But in the Java world, there's a framework for avoiding it. And whereas I have been known to cover up exceptions, I tend to at the very least log them somewhere. Which helps in debugging, but also prevents non-critical errors from popping the balloon. After all, if your failsafe was INSIDE that validateFieldData method -- and the finally block had you returning false, because a null token is invalid -- your program is debugged without even trying.

In fact, every public method I write in .NET looks like this:

public void Method(){
try{
} catch(Exception ex){
Logger.Log(ex);
//if i don't handle it, i uncomment this :
//throw ex;
}
}

Even if I don't failover, I have some way of knowing why a program crashed. Which also aids in debugging.

Re:Yuh Huh?

[E_elven]

>try { validateFieldData(currentToken); } catch Exception(e) {} // You'll find about 250 of these in his code.

Wow. This is enormously better than:

if (pointer == NULL)
{
return false;
}

Especially since you have to make sure the exception doesn't break anything in the scope.

I hope the team that programmed the original function got fired.

Re:Yuh Huh?

[Greyfox]

Nah that guy's a lifer. It's impossible to fire someone once they get hired in to that company. Every time I see emtpy catch blocks now, my first instinct is that the code is probably horrible and the entire code base should probably be scrapped on general principles.

"if (pointer && strlen(pointer))" is a bit safer than the original validate code, but I ended up deciding that the function was worthless from a validation standpoint anyway and removed all calls to it from the code base. I left it in with a half page comment ending with "NEVER USE THIS FUNCTION IN THE CODE" for documentation purposes. If I'd removed it completely someone probably would have re-implemented it later and I wanted to avoid that. Everyone seemed pretty good about obeying my comments, although one of our junior guys tread in the mystical "/* Don't touch this line unless you REALLY know what you're doing */" lines with disasterous results. He got fired (for something else) before I had a chance to belittle him for not listening to the comments, though.

Re:Yuh Huh?

[Trejkaz]

What would be better sometimes would be a facility for Sane Null Values [tm]. For instance, if the system somehow received a null Integer, then calling intValue() on this mystical object would result in it returning 0.

I think this is called the Null Object design pattern, which you can use for your own objects, but it would be nice if the language protected against nulls by automatically instantiating an appropriate Null Object if one were defined.

Call me skeptical.

[Anonymous Coward]

One of the original goals of OO was to have code that more closely resembled real-world constructs, but several decades later, not only have we not really reached that goal, it isn't even clear that's the right goal to be striving for. Anyone who's worked on real-life OO projects knows that if you just slavishly try to mirror your business domain in objects, your results are going to be suboptimal, both performance-wise and flexibility-wise. That isn't because our langauge of abstractions isn't powerful enough to describe the real world well enough, it's because we want to optimize our design for factors that computers care about (compute speed, memory, code reuse), but that the real world doesn't give a damn about. When you look at most useful OO design patterns (facade, factory, etc.), they're usually introducing entities and structures that don't have intuitive real-world complements, but they make sense for software design reasons.

Bottom-line: code should echo the real world...to a point. Beyond that point, your code *should* be different from what it's modeling because, Hello, your code is *not* the real world. I think the current object/method system of abstractions is powerful enough to get us to that tipping point.

The only way you can really minimize code complexity is by sacrificing performance and flexibility, and I think that's what you'll see in the future with more software written in domain-specific 4GL-type languages. For example, as CPU-cycles become a non-issue, you may see more and more audio apps being written in something like MAX/MSP, which is way more intuitive than writing a software synthesizer in C++. But are we going to see a more intuitive 3GL language that will let us be as fast and flexible as we want, and still dumb down the complexity? Doubt it.

Lines of code a Dead Giveaway to Crap

[snatchitup]

I'm going to spend about 3 hours re-writing a couple beans. Then end product will be about 100 lines, versus 1200 lines.

I can't believe these idiots didn't step back and say... "Gee... I'm doing a lot of cutting and pasting, maybe I could abstract this into something reusable".

At the start of this project, I took a somewhat hands-off approach in areas. This because, the young programmers were cutting thier teeth and needed to learn from their own mistakes.

But, I'm not going to win any popularity tests when I show up for the code review with 100 lines of code that used to be 1200. What's a genius to do? ;->

Re:Lines of code a Dead Giveaway to Crap

[Anonymous Coward]

Insert 1,100 statements of 'x = x % x;'
This is a well accepted method for flushing the stack, and forcing garbage clean up. At least that's what I used to tell interns. If you can muster the straight face, you'd be suprised how many people will buy it. If they resist, cite a paper by some Russian sounding authority and I promise they'll lap it up.

Misleading title! It says nothing about "Bug-less"

[tungwaiyip]

The article is a discussion on progamming and the Java language. It never say anything about producing bug-less software.

Re:And tomorrow we will work on

[Anonymous Coward]

No, this is absolutely right. Bug-free software is only possible in the sense that accident-free highways are possible. To think otherwise is naive. And to say that, "Well, we might not make it perfect, but we'll improve it" falls into another trap. Every "improvement" (OO or safety belts/airbags, etc.), makes possible new bugs/errors (you know the OO errors, consider those associated with safety restraint devices: false sense of security - driver goes faster, seatbelt traps driver in car, airbag kills child, etc.).

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

Sandbag?

[ThomK]

"Java technology, in contrast, enjoys exceptional immunity to viruses because of its sandbag architecture."

Doesn't she mean sandbox architecture?

Re:Sandbag?

[presearch]

Doesn't she mean sandbox architecture?
Not from what I've seen of most Java apps.

Re:Sandbag?

[Trejkaz]

What's the matter, presearch, you have sand in your vagina?

"Sandbag" is not a compliment!

[jtheory]

From the article:
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.

Clearly, she's suggesting that Java is "sandbagging" (moving intentionally and painfully slowly) as a means to escape viruses, which require fast processing to get their bulk mailing done.

I suppose it's effective, after all, but this is by no means a real compliment! Some programmers may desire the levels of performance that a less "secure" platform may offer!

["Sandbag, sandbox - what's the difference? Post the damned article!" -java.sun.com editor]

Re:"Sandbag" is not a compliment!

[E_elven]

Er, a 'sandbag' is usually used to form a blockade or to channel something, not tied to one's back at the 100 metre dash.

Fight the bloat, craft it by hand

[presearch]

Although nobody wants to pay for handcrafted quality any more...

vi > C > sh > make > repeat
is the high art of software development.

Perl and intuitive

[Anonymous Coward]

I can't think of anything more lacking in intuitiveness than perl.

Trek, now that is an intuitive computer

[Tablizer]

"Computer, make me some earl-grade tea, and while you are at it, do my taxes."

Re:Visual Basic

[Anonymous Coward]

OK. You've made your required slam of VB for the month. It has been duly noted. You may consider your programming manliness intact.

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.

The secret to bug free code...

[Anonymous Coward]

is to _test_ your code.

Re:The secret to bug free code...

[ninejaguar]

is to _test_ your code.

...against the business requirements.

= 9J =

Re:The secret to bug free code...

[Anonymous Coward]

Further; more time you spend on monkeying with business requirements and related stuff, less bugs you have. Reason: you have so little time to write any code that there's no room for bugs to hide in!

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'.

Reduce the code Luke!

[Da VinMan]

I agree entirely. Less code = less bugs.

However, I think you missed the point. She's talking about the fact that programming languages need more primitives to support common operations in order to reduce the amount of code.

For example: State machines are a common way of expressing requirements. When done correctly (in the formal sense), a state machine is deterministic and closed loop. Heck, I can go find programs that will allow me to input a state machine and it will generate Java code which expresses that state machine in the usual Java fashion. I can write some Java code to do the same thing. In either case, if my state machine changes, I will need to make the changes by hand so I don't lose any work.

Now, why the heck should I have to do that? Why can't the language take care of it for me? It's easy to imagine a formal computer language that allows expression of state machines. It's easy to imagine how that would save me thousands of lines of code.

It is therefore easy to see that her ideas could help us all write better software.

If the whole top is so "duh" and unoriginal, then why isn't this being done in mainstream software engineering? Given the fact that being a "code monkey" is not a guaranteed ticket to continued employment, everyone should be jumping on these ideas.

Re:Reduce the code Luke!

[Preposterous Coward]

Check out AsmL at Microsoft Research: http://research.microsoft.com/foundations/AsmL/

You understand software project management!

[plopez]

>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?!

No joke, this is in effect the situation I found myself in several times. ANother reason to get out the business while I still can...

full of it

[Anonymous Coward]

This is just another thing like Jason L's career --
all he does is give "big thought" presentations about VR and offer his grand advice about things he knows little from actual hands-on experience.

Sounds like this woman is just trying to ride his coattails -- good luck!

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!

Re:Star Trek

[slothman32]

It's interesting that you know ST but you don't know how Geordi spells his name. Back on topic when the Cold War James Bond movies were being made the people at the DOD, Dept of Defence, often looked at the movies to see if the came up with anything that could really be done. Similarly the movie writers often asked DOD people if anything they were putting in the movie was real and the movie would tip off the Russians. The moral, sometimes something from a movie, even though it is in jest, might actually help humanity.

Re: intuitive? physics vs. catching baseballs

[G4from128k]

However, by the same token the very systems which make us "intuitive" and pattern-oriented are subject to the laws of science which are grounded in logic, no?

Absolutely true! But the issue is that I don't have know the laws of physics to catch a baseball (not that I, as a geek, can catch a baseball). So can I write "intuitive" software that catches baseballs without knowing all those complicated non-intuitive laws of physics, kinematics, control theory, etc? This leads to your second point.

I agree with you, but only temporarily - I think it's only a matter of time (more specifically, time to figure out exactly how we do this kind of thing)

Actually, I agree with you that the gulf betwen binary logic and intuitive analog reasoning is only temporary. Neurons are adaptive nonlinear statistical correlators. As such they are readily replicatable in software. The only ugly issue is efficiency -- it takes too many transistors and too many clock cycle to emulate even a small number of neurons. Thus, although I think we can create computers that emulate meatware and "think" like we do (with enough power), I'm not sure that it represents a very good use of computer power.

Now going back to your first point, even if we have a NeuroPentium processor, we still need to do some serious non-intuitive engineering to create the base hardware that can intuitively interact with our world. And this issue does not even address the fact that so many business world applications (like accounting packages and tax software) represent fundamentally non-intuive problem domains.

Perhaps the deeper problem is that we humans have created a deeply nonintituive "real" world for ourselves. Our complex world of laws, budgets, money, and mass-production has gone too far beyond our old tribal hunter-gatherer origins. Even if we could create intuitive software, we could not create the applications that the current real world calls for.

Hope she doesn't read Slashdot

[Anonymous Coward]

cause this place is tearing her apart :)

(and for good reason.. she seems to have some kind of bug that makes her think she's the Jesus-of-Software or something..)

Only Logic Programming can reduce bugs...

[Anonymous Coward]

because in logic programming you don't write the code - instead you describe the problem ! Once you've properly described the problem, you're finished.

In logic programming, the only bugs are bugs in the specification of the problem. This is exactly what you want: the programmer seeking a clear expression of the problem to be solved.

As a quantum physicist....

[aepervius]

... i certainly concur I *DO NOT* want the real world coming in programmation. Density of probability the algorithm goes OK.... Boolean which can be both false and true. Integer taking a spectrum of value. The horror, the horror...

More object-oriented than thou.

[Latent Heat]

It isn't enough to program with objects; there is a new holiness cult around using objects the divine-ordained way -- aspect-oriented programming, Law of Demeter, MVC bad, and the like.

OK, there is a text string over here which needs to be displayed in a text box over there. But putting the text string in object_a and putting the display code in object_b, and having object_b hold a reference to object_a and call object_a.getTextString(), is now morally evil.

Objects are supposed to be self contained so an object should have a method called renderThyself(). An object shouldn't expose a getTextString() method because, who knows, we might have to render the object in Hittite cuneiform, so the object should use AWT to render itself. Oh, and the A in AWT stands for abstract, so sprinkling calls throughout our program to AWT is a faith practice.

And how does one render unto AWT? Why, through a Graphics object (don't know all the Java class names, but I mean whatever Java object wraps a Windows HDC). And what is a Graphics object but yet another object? So let me get this straight. A view widget to invoke a "get" to pull a string from a model object is a sin. For a model object to poke at a Graphics object to push data into that Graphics object for display is a virtuous act. For example, pushing a string into a Graphics object by calling a "DrawTextatPos" method is OK, although I still don't know how that handles Hittite script.

What I know is that developers are going to populate their software systems with objects, and for software objects to interact there is going to have to be exchange of data across interfaces between objects, and to say that pulling the data in one form will send you to Hell while pushing data across in a different form has divine sanction seems medieval.

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.

Re: intuitive? physics vs. catching baseballs

[kurosawdust]

Good points - I would point out that I think you touched on answering your own concern here though:

Now going back to your first point, even if we have a NeuroPentium processor, we still need to do some serious non-intuitive engineering to create the base hardware that can intuitively interact with our world. And this issue does not even address the fact that so many business world applications (like accounting packages and tax software) represent fundamentally non-intuive problem domains.

What the 'NeuroPentium' would ideally do then is to assign things like accounting and tax functions (the number-crunching parts, at least; if you know any accountants you know that it can be a very creative business as well) to the regular style of computation, which is what you just did when you said "accounting and tax software is non-intuitive"! A processor modeled on the brain would look at that type of problem, say the same thing, and let a number-cruncher chew on it. And that says a lot about the ultimate aim of artificial intelligence: making a machine that amplifies our strengths yet has little or none of our faults.

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.

Re:Actually...

[JollyFinn]

In soviet russia Java creates Liv shits.

Chess has not been around for 4000 years

[DavidHumus]

..as Ms. Livschitz implies; see http://www.tradgames.org.uk/games/Chess.htm.

And this she's a master of?

I think he must have went to...

[Rick and Roll]

Northern Arizona University. What a crappy C. S. program we have.

Re:I think he must have went to...

[SeanAhern]

Please tell me more. I've had one summer student from NAU who royally sucked. And another one years later who was very impressive. Two data points which don't corellate at all. Hard to extrapolate from there.

Re:I think he must have went to...

[Rick and Roll]

The problem is, most of our students these days, aren't really computer enthusiasts, and do the bare minimum, and copy each other's work. And only one or two of the professors really try to change this behavior, but what they end up with, is the idiot still asking for not only exactly how to write the code, but how to change it so the prof won't think their cheating. Students like me, who are just too nice to their fellow man, give them the help, and what we will end up with are a whole lot of stupid grads. So the great student probably was in the situation I'm in, of helping the stupid kids. Or maybe (s)he was smart enough not to waste his time hanging around them in the first place.

Re:I think he must have went to...

[SeanAhern]

Yikes. I would have hoped that the medium-level undergraduate courses would weed out the people who really don't care to do more than the bare minimum.

But if, like you said, there are only a few professors who actively try to change the students' behavior, then this is merely wishful thinking on my part.

In any case, thanks for the info.

Re:I think he must have went to...

[Anonymous Coward]

They're english department ain't so good neither.

Premature optimization is the root of all evil

[DavidHumus]

hence the still-prevalent, misguided preference for compiled over interpreted languages.

OK - I admit - we need both. However, whenever I do have to go back to a compiled language, as I do from time to time, I feel like I'm typing while wearing mittens and a blindfold with only a tiny little hole in it.

Recommendations

[bersl2]

1. 2x4 of Enlightenment
2. ClueBrick
3. Lock them in a room and play "The Free Software Song" ad nauseum.
4. Make them program in assembly.

The brainwashing should clear up in a few days. As for the 400-line recursive function -- there's nothing that can be done about that.

OO is the Emperor's New Clothes

[DavidHumus]

and has been for decades now.

Functional programming, particularly in an interactive environment, is so insanely much more productive than the now "traditional" OO methods that it's absurd that they continue to be so unthinkingly accepted. From what I've seen, OO attempts to patch some minor weaknesses, e.g. the inflexibility of strong-typing (-> overloading), with enormous overhead.

For instance, a friend of mine was working on C++ code that does arbitrage. "Arbitrage" is how you make money when you see, e.g. that someone is offering to buy 100 shares of Motorola in London for a penny more than someone is selling 100 shares in New York; you match these trades up and take the penny; do this millions of times a day and you're talking serious money.

Anyway, my friend was describing her descent through 8 layers of inheritance to get to the nub of the code where the actual work gets done. Did she have handy, interactive, useful tools for tracing through all these levels of inheritance? Well, she had her brain and opaque class descriptions - in other words, no. So, 8 levels of inheritance to solve the problem of comparing 2 numbers to decide if one is more or less than the other - does this sound like vast overkill to you, too?

This is why we need to send more work like this to India - once they get stuck to the tarbaby of OO, we can throw them into the briar patch!

Re:OO is the Emperor's New Clothes

[hippycow]

Ah, the ever popular stawman argument.

You can design and write bad code in any language, even functional languages.

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 =

API design is key

[moocat2]

My personal theory of why code is so buggy is that API design is given such short thrift. I have had to fix way too many bugs where the problem is that the code was using an API incorrectly. I would further say that 80% of the time, the API is so poortly designed that it is next to impossible to use it right.

One of the biggest problems is that too many APIs do not have clear definitions of what their semantics are. The semantics just end up being by products of the engineer who implemented the code. Often times these semantics match what is needed by the first user of the API rather then trying to properly generalize it.

Also, without clear semantics, it becomes impossible to fix a buggy implementation. Since their is no clear definition of what the library is defined to do, callers end up relying on unguaranteed semantics.

Plagiarism, Theft, Misappropriation.

[Abuzar]

Rape and programming in Java are among the 2 bad experiences I've had to go through in life. Java was worse. I just wish no other human has to go through this, and I realize the horrific reality that many do.

I spent 2 years learning and programming in Java. I truly gave it my best. I even used to have Java paraphernalia from the JavaOne conferences. However, I was unable to complete any project (all faif) close to on time, or bearing any reasonable functionality that was promised repeatedly by it's marketing and evangelism outlets. It was always about pounding one way of thinking into me, and endless (endless!) literature to go through, most of which was rife with marketing and long droning tutoring methods.

My desire to use programming as a way of building ideas, structures, and concepts, through innovative forms of expressions was always stunted. My applications were never even close to on time, nor functional to my satisfaction. More importantly, the programming methods I was locked in were nerve racking.

If things didn't work out the way I wanted, it was said to be all my fault: I was doing something "wrong", I wasn't good enough. OO was the only way to go. I was made to feel like I was stupid or something. It was like any innovative form of thought or method was outright blasphemy against Java and I deserved whatever bad happened for not sticking by their rules. Most of these tactics are also used by rapists.

When I turned to faif technologies like PHP, Python, and Perl amongst others, I realized what a scam I had been caught in for so long. This is where I learned that "There is more than one way to do it" from Perl [and it's become my major language since, but not my only language!]. Free technology was where I learnt that multiple ways and creative methods of expressing yourself were not only admirable traits to have, but also valuable traits that contributed to the evolution of building stable and efficient structures that are highly usable by humans.

Having said that, even the free tech cultures do need to be heavily revamped to be welcoming of the diversity that large numbers of people, all coming from different perspectives bring, while equalizing social and technological power dynamics.

What disturbs me about this article is that by not acknowledging the path carved by free technology, they are essentially stealing ideas from the public domain, repackaging it in different terms, and using it to promote their oppressive technology.

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.

variable assignments?

[sleepingsquirrel]

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.

If you want to see how to program without variable assignments, you might want to check into functional programming languages like haskell,ML, or Erlang and declarative languages like prolog or mercury. And, although not really a programming language, you don't do much arithmetic in hardware description languages like verilog.

Too Vague

[Anonymous Coward]

This is too vague and abstract; it can't be refuted nor supported. Thus, it is of no use.

Excellent!

[Anonymous Coward]

Excellent quotes! Your point is valid although not universal.

I'm a CS professor and I completely agree. I constantly challenge my tenured senior colleagues (I'm untenured) about their love affairs with UML, Java, and other tools. I teach undergraduate data structures and algorithms and never write one line of source code on the board -- it is all pseudocode. I don't ask students to use a particularl language for their programming assignments, either. As a result, I don't lecture from a book either. I lecture about topics and employ several books.

The problem as I see it is that it is human nature to get in a routine and not stretch your boundaries. Many profs take the easy way by letting the tools hide their complacency. I don't think they are stupid -- they knew things at one time. But they get lazy and "eat their brain". I hope I never eat mine because it is a great disservice to students and taxpayers.

The article quotes Einstein

[modder]

She quotes Einstein's "simple as possible" bit.

Perhaps it should be:
Everything intuitive should be as fast as possible, but not faster.

It's a valid point

[Anonymous Coward]

Mrs. Livschitz is basing her article on Lanier. It's a valid question.

I agree with the original poster -- what is the big deal about Lanier? He conceptualized VR, maybe built some crap, but other than that he has weird hair. I heard him speak once and it was pathetic. Lots of hand waving and pontificating, but nothing that anyone smoking a doobie couldn't come up with.

What's the big deal?

[Anonymous Coward]

A programmer is asked about programming. Whoop whoop!

She is not bad to look at though. She plays chess and works at Sun, too.

Correction: UTD

[Anonymous Coward]

I was going to say the University of Texas at Dallas... I keep hearing stories about how students that have graduated from here can't get jobs because companies in the area have had such bad experiences with graduates in the past. The staff keeps explaining that it's a situation regarding cheating, but I don't think that's the whole situation at all...

Maybe I'm being picky, but I've had two teachers explain in class that Java/C# are better languages than C because they use Unicode... however, they explain that Unicode is a 16-bit characterset and also make it sound like C is completely incapable of such behaviour (neither have responded after I tried pointing this out in email).

The second even tried to explain to me the other day that Scheme is a (implying purely) functional language so it doesn't have variables and that it doesn't use block structure...

At least I'm on a full scholarship (along with a $1500 stipend per semester) and already have a co-op job so I'll have prior work experience on graduation already (along with work on free software projects in my spare time).

Re[2]: More object-oriented than thou.

[MCRocker]

there is a new holiness cult around using objects the divine-ordained way -- aspect-oriented programming, Law of Demeter, MVC bad, and the like.

It's amazing how any good idea can be discredited/ruined by zealots over doing it. Politics is full of examples of this effect.

Despite this affect, I think that the NakedObjects approach is a practical solution to the temptation to write code in ways that are more likely to be buggy, hard to understand and hard to test.

Besides, the NakedObjects Framework won't satisfy the purists because it can be argued that it is, itself, an MVC framework that is simply hidden from the developer... yet another abstraction, albeit one that allows the developer to ignore the MVC issues and concentrate on the behavioural completeness of the object.

AOP ...

[FonkiE]

Aspect Oriented Programming. In depth information is here.

Today it's implemented in a lot of different langugages, maybe sometime in the future a whole development system is created using this technique.

Don't mistake Pointcuts as the only feature of AOP...

Another long list of links and a comprehensive introduction of the pioneers.

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.

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.

Re:OO is a one hit wonder

[Ben Hutchings]

It's not an either/or situation. A colour is logically both a value and an object (it has attributes of its own). A bignum needn't necessarily be an object but I don't see why it shouldn't be. I suspect what you really dislike is the existence of mutators on some of these classes. I agree that colours and bignums should be immutable values but I don't think that means they shouldn't be objects.

Re:OO is a one hit wonder

[Trejkaz]

Thing is, in Java, Color and BigDecimal are already immutable.

Re:OO is a one hit wonder

[Ben Hutchings]

They are? Then I don't know what the problem is. (The specific problematic class I am aware of is Point.) Maybe it's the fact that you need to call methods to get to the attributes because Java doesn't allow for read-only attributes. Again, that's not a fault of OO but a limitation of Java.

Re:OO is a one hit wonder

[Trejkaz]

Yeah, read-only attributes would be great, but methods work fine. If I had my way, I would have no public attributes whatsoever, and perhaps fake the syntax for simplicity's sake (sort of like Ruby or C# do it.)

Not enough.

[shammahau]

Note that the article is not discussing small programs (where small == 1Mloc). At these levels, premature optimisation dosn't even get you as far as an almost working first version.

We do not know how to manage complexity at these scales. The article is an interesting interview with a very smart and experienced architect who thinks she might have an idea how we might be able to do it.

When you are talking about 10's of millions of lines of code, the answers that survived a 50kloc desktop app break down.

Proving correctness is the only way.

[Anonymous Coward]

Seriously if you want 'bug free' software, the only method is to formally prove the correctness of the code. Of course, since few programming languages specify their own semantics formally, you don't have a chance in hell of doing this with a typical language.

A Programming Language That Is a Notch Richer

[Anonymous Coward]

I envision a programming language that is a notch richer then OO. It would be based on a small number of primitive concepts, intuitively obvious to any mature human being, and tied to well-understood metaphors, such as objects, conditions, and processes. I hope to preserve many features of the object-oriented systems that made them so safe and convenient, such as abstract typing, polymorphism, encapsulation and so on. The work so far has been promising.

Those of us that program in Python know that there is such a language. Python has the necessary features of functional, procedural and object-oriented languages, blended quite well into a truely useful and useable language.

But, just as importantly, one must recognize that one language is not the answer either. One needs a toolkit of languages to draw from. Mine happen to consist mainly of Bash, Python and C/C++ (for Python modules).

What about existing process languages?

[SloktGungadin]

Livshitz commented that "the problem should be addressed at the root by allowing process-specific constructs, such as "before/after", "cause/effect" and, perhaps, "system state" to be a core part of the language." She does not mention them, and I have not yet seen any comments on this topic on process oriented languages such as XPDL, BPML and BPEL, which were developed for workflow and business process management (BPM) systems. See ebpml.org for more on process markup languages. Those of us who use BPM know that relatively bug free applications (business processes) can be delivered in weeks rather than years while achieving the additional tricks of leaving human judgement in the loop while integrating legacy applications. Bug levels are reduced by directly executing intuitive diagrams and declarative statements. This reduces the "impedance mismatch" between business requirements and developer interpretations.

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.

I must disagree with this....

[S1mon_Jester]

Programmer conquer 2 worlds - two distinct area of knowledge.

The first is the area of programming languages - they should know what a statement is, what a class is, an algorithm, a subroutine. In short, they must know how to program.

The second area is that of the business world they are writing the program for. If you are writing a program for Morgages, for example, you need to be using base-10 rather than base-2 for mathmatics. You need to know how to calculate a morgage rate, principle, interest, etc. (You'd better realize that morgages can be bought and sold and how to determine their current values and future values).

Our modeling should match the real world. The closer to the real world the model matches, the easier it will be to relate the program to the business model.

The article is buggy.

[Anonymous Coward]

This is a small article on sun.com and they didn't proof read it and find such a glaring mistake. "sandbag architecture" = J2EE That is where you keep piling on more and more sacks of grit trying to hold back the flood water and mud.

Re:The article is buggy.

[Anonymous Coward]

The article is intelligensia bullshit and she is a dumpy overompensating Eastern European white trash intellectual bigot.

competency at Sun

[ajagci]

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

She means "procedural programming". It's pretty amazing that a "senior IT architect" who makes pronouncements on the future of programming doesn't know the difference between "functional programming" and "procedural programming".

Q: So, your basic thesis is that programming constructs should be more intuitive to developers, and more closely simulate and resemble the real world. That would enable developers to write software with fewer bugs, right? A: Exactly.

What are computers trying to do in the real world? They are trying to solve problems, not simulate problems. The solution to a problem is completely different from its simulation. Yes, the simulation is simpler to implement, but it doesn't solve the problem.

Smalltalk (incidentally, a much better designed language than Java) had the same underlying idea, and it didn't catch on because programming really doesn't work that way. Smalltalk turned out to be a decent programming language but no silver bullet. Unlike Java, Smalltalk was extensible enough that whatever abstractions it was missing in the base language could be added by users.

But expanding the pure object-oriented paradigm to allow for a richer set of basic abstractions -- like processes and conditions -- is only half of the arsenal in the war on complexity.

I see: adding dozens of complex, additional abstractions that can all interact in unpredictable ways is supposed to make programming simpler. PL/I and Ada, here we come.

Enormous productivity gains remain to be uncovered and difficult problems are yet to be solved.

Yes, but evidently not by Sun, since Sun clearly has no idea what they are doing.

Allowing multi paradigm programming

[Anonymous Coward]

Among the modern languages, Python has some of the features that the author talks about. It is inherently object oriented in its internal structure but does not force programmers to only use objects. It allows structured programming, functional programming (like Lisp/Haskell) and also object oriented programming. It allows for aspect oriented programming by providing metaclasses and introspection. It has iterators and generators to allow asynchronous programs. It can scale nicely from a one-line script to hundreds of thousands of lines. The language has minimal clutter, almost no noise characters in its syntax. It is dynamically typed and garbage collected. The programs are very intuitive and readable.It has a huge standard library including Perl compatible regular expressions.People who haven't tried it yet can give it a try at http://www.python.org.

Ruby http://www.ruby-lang.org also shares many of the above features as Python. It's a matter of taste which one looks better between Ruby and Python. I like Python.

Disguised criticism of proprietary software

[Anonymous Coward]

And here's what's really sad -- the overwhelming majority of so-called "successful" development projects produce mediocre software. Take almost any corporate accounting application, and you'll find it poor in quality, unimpressive in capabilities, difficult to extend, misaligned with other enterprise systems, technologically obsolete by the time of release, and functionally identical to dozens of other accounting systems. Hundreds of thousands of dollars are spent on development, and millions afterwards on maintenance -- and for what? From an engineering standpoint, zero innovation and zero incremental value have been produced.

The negative aspects mentioned here seem to be direct results of the proprietary software development process, not really software itself. What it gives you is an tremendous amount of duplicated effort, because a lot of time is wasted playing catch-up with your your competitors. The software is not integrated because you want to differentiate from other software (think splash screens and the Java "metal" look here) to sell your product. The result is tons of wasted effort, and a lack of innovative software that works well together.

Richard M Stallman (and following him, but with entirely different motives, Bill Gates) predicted this a long, long time ago. Apparently, his words are unknown to this author, or she would know why this is the case. That's what sad.

C & Unix

[GNUALMAFUERTE]

If you are willing to "code" a billing software, an odometer, or a software to predict mentruation cicles for your SO, then all this languages that tries to be simple and "resemble real work" will be ok for you, but if you want to actually code, then you will need asm, c or cpp. Other languages are nice for experimenting, or as "Programming For ... "
(As in "ASP: Programming for Webdesigners", or "Clarion: Programming for marketroids"); that's actually not programming.

How to make bugless code.

[Anonymous Coward]

1. Use a simple programming language whose syntax doesn't get extended every week or so.

2. Write code to be reusable and adhere to standards. Write programs using a top-down design approach.

3. Fix bugs faster than you add new features. Add new features when you run out of bugs to fix.

4. Profit.

Never heard of "sandbagging"?

[jtheory]

I'm thinking of the transitive verb (it is slang, I guess), as in "Come on, quit sandbagging! You aren't even trying!"

It's when you do something (i.e., running a race) badly on purpose, often to trick your competitors into overconfidence (or just to get out of working hard).

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?

Mastering complexity

[harmonica]

Victoria Livschitz is right when she talks about the complexity of today's systems being one of the major problems. But when she says that No one can comfortably negotiate a system with thousands of classes., she hasn't pointed out an OO flaw.

Whatever takes thousands of classes (or single components, to get away from OO terminology) will never be of low complexity, no matter what other paradigm you come up with. The task is to split these huge systems into parts which can be mastered and understood by single persons.

The connections (who uses what?) between classes (or packages) must be kept as low as possible, and as high as necessary.

Re:The goal is not bugless, but good enough, softw

[archilocus]

Among the one's I've come to believe are:

Okay, let's look at them...

1. Use the most obvious implementation... - okay, good
2. Have regular code-review - Absolutely !
3. Hire a small number of first class programmers Concur! Small teams are better, Fred Brooks et al
4. Try to get the technical staff doing as much programming as possible. Don't bog them down with [management], [meetings], [conventions]or [documentation]

   URK!!! Whoops, where did this one spring from ? 100% wrong. It's everything else we do that gives a context to coding and tells us whether or not we're writing good code. Coding should be the least important thing a developer does (behind things like understanding the client/problem, analysing the progblem, designing a solution and testing).

5. Test, test, test... - Aha! Now we're back on track...

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.

compiled flowcharts

[Doc Ruby]

Compiled flowcharts are the easiest way to express code, even as we know it today, especially on networks. They even transcend spoken language, so teams can span nations, and even generations. It's writing the documentation first, and then you're already done. And the graph-theoretical operations are far more rigorous than any lexical parsing algorithms. Plus, most microprocessors, virtual machines, and even Perl parse the data into dataflow graphs before processing. The only reason we're still stuck with lexical programming is the sheer momentum of the old paradigm, with the tools, nevermind how inadequate, at least already written and trained. But the first flowchart compiler (and decompiler) tool that's simple and complete will push productivity and clarity out from the hotshots to at least the professionals.

Re: Spreadsheets lose appeal with age and increase

[Anonymous Coward]

I have spent most of this last week debugging a large Excel "work-book". Without going into excessive detail, this one uses look-up tables to match specific Code requirements to equipment ratings for a large family of electrical products. This job requires many "worksheets" for the models involved (each to be readable in one screen and printable on one page). Because of the opacity of the spreadsheet "language"--you can only see the formula "source code" for one cell at a time--it's really hard to keep everything synchronized as new models are added and calculation formulas are copied into the new section. This was a design and debugging nightmare. God help anybody else who has to decipher this "intuitive" piece of software.

LISP

[Anonymous Coward]

LISP

What do you mean?

[Anonymous Coward]

If we stop putting bugs in our programs how we would earn a salary of fixing them? Come on, we all know it would be matter of minutes if we really want to write bugs free programs. Eh... This isn't a public forum, right? Oh damn...

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.

Re:For bug-free code, look at home building

[Javagator]

To a certain extent, I agree with you. Large standard class libraries, like those available in Java or .Net and standards like XML help a lot. However. I live in a 15 year old house. If you go down the street and look at a new house, it is pretty much the same. But the programs we are writing today don't look anything at all like the stuff we wrote 15 years ago. Computer technology evolves so fast that you simply don't do the same kinds of things this year that you did several years ago. This makes developing standard components a lot harder.

Re:For bug-free code, look at home building

[dmhayden]

The code we write today is different from what we wrote 15 years ago, but that's a result of the standardization that I'm advocating. 15 years ago, we still had the same collections and the same algorithms. Knuth is still as relavant today as he was 30 years ago. Excel and Word do the same basic things today that Lotus 123 and Wordstar did in 1983. But back then we didn't have OOP to help organize the code, or things like STL to make collections and algorithms a little easier.

So I think that the problem's we're trying to solve and the general concepts that we have to solve them are mostly constant. What we need are standard tools that implement those concepts

The one thing that has changed over the years is the user interface, both in terms in input and output. I expect that to continue to change over the years to come.

Greenspun's 10th Law of Programming

[Latent Heat]

I am trying to figure out if OO is just trying to reinvent Lisp at some level (http://www.paulgraham.com/icad.html).

My sole exposure to Lisp was half a semester at the U where it was paired with SNOBOL of all things, and this was before the M-Lisp, Common Lisp Golden Age, so I am still trying to understand what Lisp does. Graham has an example

(defun foo (n) (lambda (i) (incf n i)))

which is a function that itself returns a function that takes an initial value n. The returned function increments that stored value of n by i whenever that new function is called, returning the updated value of n.

Graham presents this as an example of how powerful Lisp is compared to everything else, so I will take this as an example of what a Lisp advocate considers a basic operation that you would want Lisp to do.

In OO terms, function foo is a factory that poops out functions customized by the argument value n, and each function it creates has a private field variable along with a function for updating that variable and returning a result. In OO terms, that anonymous function thingy returned by foo is simply a one field variable, one function object.

Yeah, yeah, that is not really an object, an object has inheritance and polymorphism and all that. And the functional programming dudes will say that a closure (function plus state -- is that what Graham's example represents?) is not really properly represented by an object. And Graham is quick to point out that the Lisp example is also an example of generic programming because the type of n and i is not constrained. But the core idea is like that of object instances -- you have one or more "things" with internal state that you can poke at to modify that state and return a result.

So I wonder if, after Greenspun's 10th Law, what OO is reinventing that has already been done in Lisp is creating networks of "things" with state and mutators that can interact with each other. And OO has evolved from the more Lisp-like Smalltalk to the heavy type systems of C++ and Java. Then the question is whether Lisp has a cleaner way of expressing all of this or whether Java is the way to go because it shows that a statically-typed language can express much of the same stuff as a runtime-type language but with the advantages of performance and code readability that static typing is supposed to bring. Or have the Lisp advocates been right all along only we didn't understand what they were talking about?

eh?

[Anonymous Coward]

maybe it's just that many project start
because there's this "thing" we want to improve
automate but it has never been fully discribed,
understood. my acctually sitting at the computer
and trying to make this "phantom" "real" you
suddenly realise that it is way more complex then
you initaly thought and so you cut corners (ta-da!
bug). once the whole beast is complete there's
this "but i wanted that funcionality added" etc.
back to the drawing board.
i disagree. computer programming is not like
cheess(?) at all. it's like painting.
if you think programming is lke cheess(?) then
sit at a typ writer and write your code and then
scan it with a text regognizing program.
i just want to add, that typing a line of
code and then trying compile it isn't the
way to go, but it is easyer if a compiler "AI"
can help you.
nevermind. silly article...

Less buggy?

[Nippoo]

Software, in general, ranges from many subjects. It is impossible to define a set of rules to make software less buggy, however, the only rule that can be said is "Check your program for everything, right down to entering a double decimalled negative number (e.g. -2.5.3) on a Win95 machine..." Obviously, the chances that that will happen are practically zero, but after all, what's the definition of "buggy"? What's the definition of a "bug"? ___________________________ Please visit my site: http://www.nippoo.net ; programmers wishing to make their programs less buggy may like it! Just visit, at least...

Design patterns

[gidds]

Maybe because 'state machine' is a nebulous concept, useful for thinking about code but not directly implementable because there are different things it can do, and different ways of doing it. This state machine; does it have a finite number of states? How are the states identified and described? How are transitions between states triggered? How do you find which state to move to next -- is it deterministic, or do we try lots of states until some other condition is fulfilled? What happens when you get unexpected input? How does you find out the current state -- should it generate events for transitions, or will you query it? Does the state need to be saved for later recall -- if so, how? Should it execute arbitrary code on reaching each state, or on performing each transition -- if so, how is that specified? Do some states have special conditions or restrictions, time limits, &c? And so on, and so on.

Of course, you can write -- or generate -- some code for a SM once you've decided all these points, but you couldn't expect a language to come up with a generic SM without making fixed decisions on these sorts of questions, decisions that will be wrong for some applications.

A state machine is really a design pattern, a way of doing things, even a way of thinking about them, rather than an actual specification. A language or library can provide support for some of the things it might do, but too much depends on the implementation choices.

Maybe what we need is a language to specify code in terms of design patterns and then generate code from them... but even if someone finds a way to do that, it will take an awful lot of work to integrate with current languages.

"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!

It can help.

[autechre]

If you start on the process of implementing project management software, whether you're doing building construction or coding, it can help improve the project process. The main thing is that any reasonably complex piece of software will require people to start keeping track of things. It starts making it easy to see who did what and when, what things made you fall behind schedule, what makes projects go over-budget, etc. You know the saying that a camera does not just capture things because its presence changes what happens?

Think big

[Da VinMan]

Grrr... I had a much better response prepared, but it died when Firefox crashed on me..

Anyway, here's the short version.

State machines are not nebulous when the state machines are complete and closed loop. Imagine a language where the state machine description IS the programming language, and you just let the computer figure out how to get the job done based on the state machine program. Don't believe it can be done? Then check out the Abstract State Machine Language (AsmL) that was pointed to by the other response to my post. It has been done.

A state machine is a specification mechanism, not a design pattern. Common state machines could be abstracted into state machine design patterns though.

Your post indicates that you are still thinking inside the box. Imagine a language where the state machine spec IS the programming language. Or imagine something radical like doing a series of UML specifications for a system, and that IS the program for the system. No code generation. No other intermediate steps except some sort of compiler/execution environment that knows the language and can execute it.

This would force us to produce VERY GOOD specs, because the specs would be the program.

I know this all sounds far fetched, but Java, Perl, or Python would have sounded very far fetched to any programmer 30 years ago. "Whaddya mean I don't need to write my data structures in macro assembler? You just replace these 200 lines of assembler code with that 1 line of Perl?! Why, that's just a stupid waste of memory!" Constraints around software development have changed, there's no excuse to make everyone continue to write software in relatively low level languages like Java when we could do much better.

Even if you don't believe that we can do better, it doesn't pay to believe it. :+) There is no progress where complacency resides.

Round and round we go

[Anonymous Coward]

Hey, software sucks, it has bugs, it crashes, and it's also hard to write. But I get tired of seeing some CS professor tell us that we need "intuitive" programming, or self-creating software or some other nonsense. It's fairly easy to spot the point at which they depart from reality and start daydreaming.

As far as I can tell, we have bugs because people make mistakes, because we don't understand the problem properly, because too many programmers don't even know how to do their jobs well, because there are tight time constraints, and who knows what else. But let's face it, if we would (or could) spend a bit more time thinking hard at the beginning and knowing our tools properly, it'd save endless trouble when things don't work later on.

try lazy functional languages like Haskell

[Anonymous Coward]

Haskell Lazy Functional Language

Re:Your describing why I dont want to be a program

[barks]

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

My three year Computer Programming/Analyst program at Georgian College required you to have 3 co-ops before you could graduate.

Take note I started in '99 where the bubble was still making the IT industry a beautiful and blue-sky world, and finished in '03 where I was lucky to get a job from one of my co-ops...I mention this only b/c if a student couldn't find a co-op for the designated semester they'd still have to pay $250 regardless. Oh, how we would like them apples!

One problem

[Javagator]

Look at what visual development tools like Visual Basic have done to demystify the previously "obscure art of programming" and attract millions of new people to programming

I think I found one of the reasons we have so much bad software. Being able to drag and drop buttons to make a GUI doesn't mean you can handle the other aspects of programming. Some things (like GUI appearence) may have gotten easier, but programming is still an art that requires a certain kind of analytical ability. There are many programmers that can write bad, buggy software, but there is a shortage of programmers that can write good, well crafted software.

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.

Actually the secret to bug free code...

[Trejkaz]

...is to have no features.

Re:Your describing why I dont want to be a program

[Trejkaz]

So I went through BInfTech(Soft.Eng.). I could have alternatively done BE(Soft.Eng.). The end result is the same, and surely not everywhere in the world requires this "license" to operate as an engineer, otherwise you would never get any work due to the massive Catch-22.

Re:Your describing why I dont want to be a program

[T-Ranger]

Not everywhere, no. But on the same side of the coin, me taking my 48 hour first aid course into some 3rd world civl-war torn country, I could be consitered a Doctor, if not a god.

In Canada PEngs get very mad when non licensed types call themselves 'Engineers'. For example, CNE stands for "Certified Novell Engineer" everywhere except for Canada, where CNE stands for "CNE". Im not sure the details, but apparently the definition of a PEng is defined by Parlement, and only Parlemently anoited groups can give out the title 'Engineer'.

While this is slightly elitist, yes, it is to everyones advantage that when someone calles themselves a PEng it means something. Because it does.

More to the point, because anyone can (and does) call themselves a "Programmer" or "Software Engineer" those titles are meaningless.

Re:Here's an idea

[Anonymous Coward]

It wasn't offtopic. It was a comment on the reply above mine.

Interesting but...

[Paradox]

The problem is Io doesn't really fill the niche ObjC fills. ObjC can accomplish both high level glue coding and low level systems programming, and in that capacity it excels. Especially with the addition of C++ stuff, it's really quite good.

Io is very interesting, but it's simply not at the performance level you'd need to attack ObjC's position. The only language I've seen that comes close to the C triplets is OCaml, so far. I'm sure there are others, but OCaml really is disturbingly fast.

Of course, a vertical learning curve and recalcitrant type system kinda make it less than optimal.

note to metamods

[bill_mcgonigle]

the 'offtopic' on this one was part of a mod-bomb.