Slashdot Mirror
Has Software Development Improved?
earnest_deyoung asks: "Twenty-five years ago Frederick Brooks laid out a vision of the future of software engineering in "No Silver Bullet." At the time he thought improvements in the process of software creation were most likely to come from object-oriented programming, of-the-shelf components, rapid prototyping, and cultivation of truly great designers. I've found postings on /. where people tout all sorts of design tools, from languages like Java, Perl, Python, Ruby, and Smalltalk to design aids and processes like UML and eXtreme Programming. I'm in a Computer Science degree program, and I keep wondering what "improvements" over the last quarter century have actually brought progress to the key issue: more quickly and more inexpensively developing software that's more reliable?"
Not too sure if it an improvement, but I know some people use languages in which programs can be proven to work like ML. Of course if you actually want to write a program which *does* something it is probably not for you.
I don't think there are any magic bullets. Software development (unlike most other engineering disciplines) is a build-it-yourself from the ground up everytime experience. Go read http://www.reciprocality.org/Reciprocality/r0/ (mentioned in the past on /.) to see a different view on what makes some folks way more productive than others.
Programs that assist programmers in the development process by handling who changes what when, etc - are - IMHO - a huge improvement.
I seriously doubt that a program like Linux could flourish without programs like CVS.
furthermore - many of the programs that do this sort of thing can be used for any programming language... you could even use it for simple documents.
While I'm only in my mid 20's and I'm no veteran by any stretch, it seems like there have been huge leaps in programmer productivity made possible by things like OOP and off-the-shelf components.
However, I think they're equally balanced out by huger demands on programmers. Once it's realized that a programmer can do 2, 3, or 10 times as much work by using more efficient methods management is quick to pile on 2, 3, or 10 times as much work!
This isn't really unique to programming either. I think it's universally applicable to any area where technology permits greater productivity.
For example, look at all those ads from the 50's. Things like the microwave, the vaccuum, and the dishwasher were supposed to usher in a new era of leisure. Do we have more leisure? No, we have less, as those luxuries become necessities and we cram in more activities in out new-found time in order to stay competitive.
OtakuBooty.com: Smart, funny, sexy nerds.
more quickly and more inexpensively developing software that's more reliable
Based on the last 20 years either working in or supporting government efforts, I'd say yes. However (there is always a however), it depends on the sophistication of the developing organization. The cowboy shops still suck. Those who have embraced more formal processes have become more reliable. It is a 2-way street though and requires the customer to be more sophisticated as well. It doesn't do a damn thing to have a development shop at CMM-5 if the client doesn't understand the need for process and doesn't understand the software development challenges.
The invention of pencil and paper.
The question of whether a computer can think is no more interesting than the question of whether a submarine can swim.
but HTML and Perl have probably set us back 15-20 years.
What's a sig?
Silver bullets still do not exist. New technologies and methodologies are often hyped as such and naturally fail to live up to the hype. However, that does not mean they are useless.
These technologies and methodologies have allowed us to keep pace with Moore's law. The amount of software we develop today would simply be impossible using the state of the art in 1970. We routinely poor out millions of lines of code in mammoth projects that take sever hundreds or thousands of man-years to complete. The only reason we are able to do so is because of improvements in development methodologies and technology.
The (huge) research field that studies these technologies and approaches is called software engineering.
Jilles
High quality, reliable C and C++ compilers have emerged as defacto standards on major platforms.
Now you wouldn't think of developing on UNIX with anything but GCC and the associated build tools.
In 1990 you were stuck with whatever C compiler your vendor shipped, and there were more than a few dodgy compilers out there. Modern compilers with useful error messages have done more than anything else to make debugging and development faster and easier for me.
The focus has definitely shifted away from algorithms and toward abstraction. This was supposed to make things easier, by letting the software do what it does best and keep track of bookkeeping, while we concentrate on building models and governing interations between them.
Some of it actually makes sense - the object oriented paridigm, component models, virtual machines. (VM's, by the way, go back at least 20 years in the literature -- I studied them in college in the late 80's. However, like Pascal, they were originally considered as an instructional tool, and nobody at the time thought that anyone would be damn fool enough to actually try and *implement* such a thing!)
But just like letting grade-school students use calculators for their arithmetic, I'm not certain these things are best for students. Sure, you get usable code out quickly, but without an understanding of the underlying algorithms and logic. I doubt many modern 'c0derz' could properly knock out a simple quick-sort, let alone a fully ACID SQL DBMS.
"Lawyers are for sucks."
- Doug McKenzie
I've always believed that one day some bright college kid is going to come up with a completely different style of computer language and interface, and when that happens we will all slap our heads and go "D'oh! So that's how we should be doing it! Obvious!"
Like the web and P2P, the most influential ideas are often quite simple, and "obvious".
NO.
The project management keeps moving the target. The customer still says "I don't know what I really want, but keep coding and I'll let you know when you get it." Analysts can't analyze, designers can't design, coders can't code, testers don't test (enough), ad nauseam.
Methodologies and philosophies of software development can only make up for so much. Sometimes, they are counterproductive. They "lower the bar", leading management to believe that the methodology can fill in for cheaping-out on hiring good developers. But we /.ers know the truth, don't we: Quality software comes only from quality developers--people, not methods or schools of thought or books by really smart people. Since quality developers are rare (like Leonardo DaVinci rare), quality software is correspondingly rare.
Welcome to the Panopticon. Used to be a prison, now it's your home.
Let's say you're trying to improve the work of a painter. Give him a better brush, his strokes look nicer. Give him better paint, his colors look brighter. Give him a CAD system with a robotic painting arm, his paintings look crisper. However, nothing you've done can change the fact that he's still doing velvet Elvis's. Not that there is anything wrong with that, but he isn't churning out a Mona Lisa anytime soon, or ever. You haven't been able to affect the input to the process - his brain. You know the adage, garbage in, garbage out. Well that is the fundamental rule in software.
The big improvement in software productivity will come when we are able to successfully clone human beings. Corporations will create a stable of uber-programmers who they will then clone to be able to mass produce software. In the future, the open source war will be about peoples' genes, the software will be just a downstream product.
There are definite improvements to programming. Tools, concepts, etc. have evolved. There are no true silver bullets, but we've got a good selection of choices out there.
The problem, however, is threefold:
One of the real challenges for IT professionals today is to find the good tools and ideas out there, the ones that really have improved programming, and then actually get them into use. A good IT person is a good researcher and good at justifying their ideas to people.
"The Sage treasures Unity and measures all things by it" - Lao Tzu
Think about it. 25 years ago, it was extremely limited. How many people did you know, in 1977 with a net account? I remember coding on a C64 in my cousin's basement for days on end just because we had scrounged enough money to get into town and buy some new books/magazines that helped us overcome some bug. Now, if you're being bitten by the same bug, whaddya do? Hit the net! Some of the responses above, like the sharing of source through GPL wouldn't be as viable an option without the access we have today. The biggest aid to programmers today. Net Access.
Don't park drunk, accidents cause people.
I can't say that Java is a significant programming advantage over C -- it's the Java libraries that beat the snot out of calling the raw Windows/Mac/X APIs.
That's not the only one: The depth of CPAN, the Python library, even MFC/ATL are worlds ahead of hand-coding the guts of an app.
When I started programming, the Mac SDK had to be handled raw, and GDI was brand spankin' new. APIs such as DEC's FMS were considered heaven-sent(talk about dead ends!). Shortly after, class libraries were available, but expensive for an amateur. With Java and Perl, it's part of the (free) package.
I'm sure there's garbage code in those libraries -- there's always going to be bugs. But they're going to be relatively smooth to use, and they're already written, letting me focus on the business logic, instead of the presentation.
Design for Use, not Construction!
Now I am not saying that you still don't need to have a good understanding of the language, or use good design, implementation, testing, etc. But I have worked at SEI CMM level 3, level 2, and am currently going through the process of evaluation where I work now, for level 2. But being at that level doesn't guarantee that your software will be good. It seems almost like we are attempting to fit the creation of software into the old engineering mold, because it kind of fits.
So to answer the question - I don't think that there have been any great improvements to obtain the goals you stated. Software relys on hardware, which seems to contstantly be changing. A bridge is a bridge, but the very idea of what software can do has been changing constantly over the last 25 years.
If you want reliability, look at what NASA has produced. Those are some engineers. Ahh, but you said 'quickly', didn't you? :-) If you want something rock solid, you can't have it tomorrow, if you want it to do anything remotely complex. I think one of the big things we as an industry has to realize is that our product (software) can be simple and fast to market, or more complex and take more time. And all of the variations in between. I haven't been convinced that what we do is engineering, but I haven't been convinced that it isn't. After all, it is a pretty young profession, compared to others. Imagine trying to explain to someone from 100 years ago what a software engineer does.
All that being said, I think that the obvious Slashdot answer is that the GPL and free software have been a huge force, but only in recent years. I think the two biggest forces in software development were the PC and the internet.
My beliefs do not require that you agree with them.
IMHO, one of the keys to writing good software is to not write very much software. Class libraries like the one in Java are almost invariably more feature-complete, more reliable, and better tested than roll-your-own libraries. Using existing libraries means you don't have to worry about off-by-one errors in your linked list implementation, or figuring out a good hash key for your string. While I think that all coders should know how to solve these problems, they shouldn't have to as part of their daily life. It's busywork, and giant class libraries do a wonderful job of making life easier. They let you concentrate on the important stuff - the algorithms, and marketing's feature of the week.
Yes, libraries have been around for more than a decade. The STL and Java both showed up in the mid 90's, though, and I'd argue they've made a huge difference since then. Yes, they have bugs. Yes, there have been other advances. Yes, there are special cases where standard libraries aren't appropriate. There's no silver bullet, but standard libraries are a huge advance.
According to Brooks Good and Fast never happen together. If you think they can be accomplished at the expense of cost (by perhaps adding more programmers), then you haven't read "The Mythical Man Month" (the book which spawned the TINSB chapter). On the other hand it may be possible to find or train programmers good enough to accomplish "good" and hopefully "fast".
The answer is finish that degree and hope your institution teaches you enough about these principles: effective design, KISS, machine states, and proper error handling.
After a few years in the field I've found that these, paired with knowledge of a language and it's libraries is as close as you are going to get (although I'm still working on perfecting the second one)
All the problems with software today aren't a result of poor engineering, but rather of poor software development management.
;) But most business orientated software is bug-ridden, and that's just fine. It's the accepted risk for getting the software out the door as cheaply and quickly as possible.
I can't count the number of times last minute feature requests are required to be in a build. As software developers, we just deal with it. But quality suffers because of it. And the engineers get the bad wrap.
Do you think Intel management requires last minute features to the Pentium core, and tries to push them out the door with no testing? Do you think people building cars for Toyota decide to swap engines at the last minute, becuase GM just put a turbo charger on it's standard Prizm?
It's ludicrous the stuff that gets requested of software engineers.
My brother is an contract electrical engineer. He was complaining one time of a 'last minute feature request'. His project still had a year of development time left! I laughed so hard I almost puked.
Granted, given all that, the current model for software works. When software is required to be bug-free, it can be. Lots of software is bug free. You just don't hear about it, because it works. Look at NASA, the AIN telephone network, or Windows.
I don't have a sig...Do you??
Here is my take on the best environments available today (in order of best first) - I only include stuff that I use:
- Cincom VisualWorks Smalltalk - a really fast coding environment with support for SOAP/WSDL/UDDI/all possible database connectivity, built in web development tools, huge class library so often new applications are very little new code
- Microsoft VisualStudio.Net - I almost hate to include this one, but I am trying to be honest here
:-). Last year when I was writing a J2EE (Java Enterprise) book, I took a good look at the competition and liked C# and .Net.
- Java with light weight web services - I am a HUGE fan of Java on the server side, done light. By light I mean that I like to just use servlets and JSPs, etc. and only use heavy weight J2EE stuff when I really need transaction support, etc. that EJBs provide
- Common Lisp - lots of great commercial tools from Xanalys and Franz, and lots of great free tools like CLisp, CMULisp, OpenMCL, etc.
- Python - Love it for small projects, munging text, etc.
- C++ - only use it when I must - great runtime perfromance, but a pain to code in
It seems like so much work today requires deploying web services so I appreciate tools that make it easy to develop basic application logic separately from any user interface, get it working, then write web and/or standalone GUI interfaces.-Mark
Warnng: I am blogging now: http://radio.weblogs.com/0115954/
I think any programmer who sees the benifts of CVS would understand where im going with this concept. We all have functions we use again and again - and realizing that there is a potential flaw in a given function at one point is always followed by exasperation because one realizes that the function needs to be changes in X number of programs.
You don't need a new version control tool, you need a refactoring tool.
Brooks, in the "No Silver Bullet" essay referenced above, stated that there is both essential and accidential complexity in software development, and because of that there never would be a "silver bullet" to slay the software "monster". However, there are fundamental practices that increase the likelihood of success and fundamental pitfalls that every project faces. And, in the end, the root causes of most failed IT projects are human factors; in fact, you could just cite the "seven deadly sins"--pride, envy, gluttony, lust, anger, greed, sloth--and probably hit the nail on the head.
In conjuction with that, far, far too many practitioners in the IT field lack one or more of the following:
To quote George Santayana (who is often misquoted):
Software engineering is hard enough--with all the human issues--without further handicapping ourselves with ignorance of all that has been already discovered and documented. Yet that is exactly what most IT workers do. Until we find a way to solve _that_ problem, the failure rate for IT projects will remain high indeed. ..bruce..
Bruce F. Webster (brucefwebster.com)
From the article:
The most a high-level language can do is to furnish all the constructs that the programmer imagines in the abstract program.
A-men. But if it does that well, then it makes the job a lot easier. That's why going from C to Java or Perl was sheer relief. Actual strings? Real associative arrays? Whoohoo! And less memory management grief. Not to mention the component libraries available for things I hadn't even thought of yet. CPAN...
To be sure, the level of our thinking about data structures, data types, and operations is steadily rising, but at an ever decreasing rate. And language development approaches closer and closer to the sophistication of users.
True... but the user sophistication is increasing to. It seems highly apparent to me that with more experience and more shoulders to stand on, language and component developers are able to concieve of more and more useful abstractions. And because of the internet, they're more easily available for sharing, commentary, and change.
To sum up, I am much, much happier with the readily available toolsets I have access to now than the ones I had 15 years ago, or even eight years ago. They make developing much easier and much more fun.
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
We don't know enough to do software engineering yet. If materials in the physical world were as poorly understood, and changed as fast as they do in the software world they couldn't do it there either.
If requirements were as poorly understood and changed as fast in the physical world as they do in the software world construction would cost a fortune and most big buildings would never get finished (or would never be fit for purpose).
People who say things like "Make sure the requirements don't change" are living in a fantasy world where they want to blame their inability to deliver on someone else.
The rules haven't changed, get a high quality small team, get good access to a user who knows what they want and grow a system from small beginnings, checking at each stage that it all works and that quality is high.
Its all there in Brooks.
Its no surprise that the guys pushing the agile methodologies were all very succesful designers and developers anyway.
I notice the original post mentions several things that could influence the development time of a software project. I will address a few of these below:
1) Object Oriented Programming :)
This is one of the bigger Silver Bullets to be unleased upon the programming world. I don't think it entirely lived up to the hype. Most OOP is just for local project design, and heaven help you if you have to reuse code somewhere else. It isn't just a case of bad design. Problems like software design are actually ambiguous. The design process is not algorithmic; rather, it's heuristic. You use "templates" and "patterns" to represent your ideas. Trying to shoehorn real-world complexities into these cookie-cutter styles is difficult at best. Trying to further take those styles and integrate them with each other in a very large scale product is a hair-tearing nightmare. I think Tablizer would agree with me on this...
2) Reusable components ;)
The most visible place reusable components come into play is GUI programming. It's very, VERY simple to use a visual-based system (like Visual Basic, C++ Builder, Delphi, etc.) to create a GUI simply by dragging the desired components onto the blank form window. If anything has been sped up significantly in the past several years, it has been the GUI development.
Components are, of course, used in a variety of other places, particularly in run-time libraries of various programming languages. However, learning to use these components effectively takes more time and dedication than one might suspect as the syntax tends to be rather cryptic looking.
3) Java
Don't get me started. I am currently employed as a Java developer. I don't really like it a lot. The file scoping rules bug me. (Similarly, I don't like Python because of the way it enforces indentation.) Also, the Java IDE sucks. Whoever thought the entire GUI needed to actually be written in Java needs to be taken out and beaten with a stick. A large stick.
4) The Internet (and OSS) ;)
One thing I noticed that you hadn't mentioned is the Internet. I have never been exposed to so many programming concepts and new languages. There is an astounding variety of tools, and thanks to Open Source and researchers at various universities, you can try your hand at as many of them as you have disk space for. The 'Net can be a wonderful place, after all.
My advice to any new programmer would be to get online and start reading. Download and try out new languages, especially ones in different paradigms, like functional programming. The tools you need (such as compilers, editors, databases, GUI component libraries, etc.) are ALL there, free for the taking. The only real "silver bullet" is to make yourself the best programmer you can be.
bytesmythe
Hypocrisy is the resin that holds the plywood of society together.
-- Scott Meyer
Good, Fast, and Cheap can happen, even in software. If the aircraft industry can pull it off, so can the software industry. Read up on the Lockheed Skunk Works. They did incredible stuff with very few engineers in a very short amount of time. The key is people. You need a top-notch staff and more often than not a world-class leader. Such a team is hard to come by, but when they do get together they can pull off some amazing stuff.
I've often thought over the last few years that we've made too little progress in making programmers more productive. I largely blame that on Microsoft, simply because it drives more software development with it's tools than any other entity. One language I've categorically made a decision to avoid is Visual Basic. I have always felt it was basically (sorry) a waste of brain cells. It has certainly done nothing to advance the state of the art.
In my opinion, one of the best things to come along in a long time is Java. The gentle reader may recall earlier posts along those lines. I enjoy C, and have spent the majority of my career doing C and C++. However, I have also spent _way_ too much time tracking down memory-related bugs. Often, they were in third party code. That is no way to run a railroad.
Java addresses almost all of the glaring deficiencies of C++, both in language design and in runtime safety. In my opinion, the best programming tools will be those that enable single programmers to tackle larger and larger projects.
Compared with C++, Java enables me to tackle much more ambitious projects with confidence. A team approach can never attain the efficiency of a single programmer approach. The "sweet spot" of software engineering efficiency is the largest project one person can tackle. Extreme programming is a useful hybrid that attempts to turn two programmers into one programmer. ;-) (Also teams can be nearly as efficient as single programmers if the system is properly decomposed into subsystems separated by simple interfaces. This rarely happens smoothly, in my experience. It takes a top notch group of people.)
One last note on Java - performance is now almost completely on par with C++. On my most recent round of benchmarks, Java (JDK 1.4.1_01) on both Linux and Windows outperformed C++ (gcc 3 and VC 6) on most tests. Dynamic compilation and aggressive inlining are that effective. The VM also soundly spanked the gcj ahead of time compiler in gcc 3. It thoroughly rocks to have truly cross-platform code that runs faster than native! Think how many religous wars would be avoided if 99%+ of software was available on all OS platforms...and think how much it would help Linux! :-)
If you want to see what's out there for Java, download either the NetBeans IDE project, or the Eclipse IDE. Both are free and each has its strong points. NetBeans is a Swing app and includes a Swing GUI designer. Eclipse uses a new open source "native widget wrapper" library from IBM called SWT which has it's interesting points. You'll also need a Java VM (there are also others available from IBM etc.).
One last thought - wouldn't it be cool if web browsers had support for something like Java? I mean, you could deploy apps just by putting them on a web page! It wouldn't matter what the target platform was! What a great idea! (This paragraph was sarcasm in case you were wondering.)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
... Lisp development environments in 1980? If Visual Studio is an example of progress in the last 20 years, I'm impressed... NOT. Every one of those features was in every commercial Lisp development system of the era (Symbolics, LMI, Xerox), along with lots more. And, they live on in the ilisp development environment, which gives them to many Common Lisp and Scheme implementations.
Yes, this is flamebait. Yes, I'm bitter and curmudgeonly. Perceptive of you to notice...
To a Lisp hacker, XML is S-expressions in drag.
I wrote my first computer program in 1974 or 75 and have been a professional programmer (meaning that I got paid to write code) since '79 or so. School was mainframes and an early Wang desktop system (Basic and punched cards, oh yeah, baby!) I later moved into minis, mainframes, and I've been working with desktop systems since CP/M and the S-100 bus, so I guess I've seen a little of the history, anyway.
In my experience, the actual process of coding has greatly improved over time but the process of developing software hasn't improved as much. As other posters have pointed out, object-oriented tools, technologies and techniques (among other factors) have greatly facilitated the generation of code but the management of the process; deciding what gets coded, when, by whom, etc. is little better now in actual practice than it was in the late 70's or early 80's. In fact, in my opinion the situation is in some respects worse.
Management of software development today makes the same mistakes and operates under many of the same misguided assumptions as it did back when I spent my day in front of a dumb terminal. Adding outsiders unfamiliar with the details of a project makes the project later, not earlier, etc.: all the platitudes we know and love are still with us, still the butt of Dilbert jokes.
Technology may change; people aren't quite so amenable to upgrades, I think.
The idea of course being that good modular design, and good use of classes can increase reuseability ad infinitum, so that eventually there will be no task and no problem that cannot be assembled lego-like from blocks of premade reuseable code. The marvelous technology in Douglas Coupland's Microserfs ( called Goop wasn't it ? ) was really the epitome of this concept, a totally reuseable code system that was so generalized, so modularized that anyone with no more experience in programming than a child could assemble working programs for just about any purpose in a drag-and-drop virtual lego-building reality.
Any student of the history of science and science forecasting should begin to smirk at this point. Is it any surprise that these visions have not materialized? The hard truth, IMHO, is that logic is inherently not conducive to such high degrees of abstraction and modularity. For given tasks which are fixed and well defined with completely known and understood parameters and requirements than yes, abstraction and modularization can be a great boon in optimizing design and improving the development cycle. We can see the great advantages that this has yielded in some areas where the requirements are fixed and the applications are mostly derivative of each other. GUI design is a great example, and there are a multitude of GUI building toolkits & development environments that take great advantage of this.
However the whole thing breaks down when you move from the known to the unknown. When you try to extend this principle from fixed tasks to hypothetical ones in which the basic requirements are not envisioned. I would argue that there is a basic lack of understanding among some of the proponents of these techniques that at a fundamental level logic cannot be generalized out across all possible tasks, and all possible configurations. This was similar to the revelations of Godel's theorem in mathematics already in the 1930's - that any axiomatic system could be consistent but never complete. In reality adapting one set of code to a purpose other than that for which it was designed, or with parameters other than those originally envisioned usually is more trouble than it is worth, and often you would be better served by building new objects from scratch. You will always need intelligent educated people to design these things; there is no such thing as logical lego.
Unfortunately it seems to me that many have not gotten this message yet. Sun and Microsoft are still actively humping that dream of infinite modularity and drag-and-drop programming design. In my experience with both Java and .Net, I have found that I always run into blocks where the established object model is too constraining and has too many built-in assumptions about what you're going to be using the classes for, and so I have ended by coding new versions from scratch. Of course it may simply be the nature of the applications I'm working on, and your mileage may vary. Ultimately I think that for derivative applications this kind of abstraction and generalization is definitely an improvement, but when you come to applications that move beyond those fixed tasks it actually becomes an impediment not an advantage.
There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie -Noel Godin
Software is at best a cottage industry of craftmen that have widely different abilities. At worst, it is a cottery of alchemists that promote their own secret snake oil recipes and only succeed by sheer luck.
And I am a developer that calls himself a software engineer, so this is not a flame.
Why craftmen? Because we develop with tricks and recipes, often called "processes". But neither of these are scientific processes. They cannot predict the outcome of a software project within a definite set of constraints. They cannot be disproved. And they cannot explain failures. So they aren't science, they are rules of thumbs. The guy who makes a living by applying rules of thumbs and learned tricks is a craftmen.
Why alchemists? Because scientists publish their methods and their results. To the contrary, the software industry hides its customer references and does not publish its source code (with the notable exception of Open Source, with remains the exception in large-scale software projects). This is how alchemists and "savants" worked in the Renaissance. They hid their trade secrets, they had confidential relationships with rich patrons, and they feared full disclosure.
On top of that, each subbranch of computing has its own lingo and redefines as many words as possible. Mathematicians who specialize in field theory topology may not understand number theory, but at least, they use distinct, well-defined jargons. In computing, terms like "record", "field", "server", "link" are so overloaded that they are just noise.
About 60% of all software projects are cancelled or written-off as failures. I don't think civil engineering or, say, aeronautics have such a abysmal track record.
I hope that some day, we'll practice and teach Computer Science as, well, a science, not as a craft.
--
Mad science! Robots! Underwear! Cute girls! Full comic online! http://www.girlgeniusonline.com/