Slashdot Mirror
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?"
First, making software more 'intuitive' for developers will reduce bugs
Feels right.
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.
"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.)
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.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
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.
I'd say that with buzz-speak like that, she's going to make some CIO very happy someday.
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.
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!
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.
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.
No Comment.
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.
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.
I've made up my mind and now I've got to lie in it.
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.
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.
Karma: Contrapositive
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.
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.
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
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
...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....
Lately democracy seems to be based on the skybox, the Happy Meal box, the X-box, and the idiot box.
"....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.....
"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
mp3's are only for those with bad memories
"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.
"I am Heisenborg. You will probably be assimilated"
Right now I am in a Computer Science program. I have had the pleasure to see:
I don't think the whole proper education thing is going to happen any time soon.
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.
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
Well.. some interesting ideas in there mainly flawed.
.Net ae eliminating may of those issues.
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
In short, a bad simplistic article which will probably cause more harm than good.
putting the 'B' in LGBTQ+
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.
I appear to have a blog. Odd.
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?
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....
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.
Two wrongs don't make a right, but three lefts do.
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.
Table-ized A.I.
- 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.
"Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
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.
I don't care if it's 90,000 hectares. That lake was not my doing.
Dijkstra has a few things to say on the topic as well:
On Education, Specifically:
And then on Computer Science in general:
Thanks,
--
Matt
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.
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...
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?!
...richie - It is a good day to code.
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.
She's the real story here. I think I'm in love.
In all matters of opinion, our adversaries are insane. -Oscar Wilde
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.
...richie - It is a good day to code.
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.
Slashdot. It's Not For Common Sense
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!
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.
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.
No.
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.
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.
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.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.
As with many (all?) other skills, I think two things probably dominate developer ability:
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. :-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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!).