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?"
Euro is being adapted by "progressive" nations like North Korea and Iraq...
Way to go, eurotrash.
1975 to 2002 is not 25, it's 27. Unless you were late getting this stat out, and brought in a few 100 to help you out, then it's not that you're count is wrong, just DAMN LATE!
.
Title says it all...
Just figured I'd donate my few thoughts to this matter.
I've been working on a project for nearly 18 months now. It's finally drawing to a happy ending (on my part). And I'm right on schedule.
A bit background. I'm a 20 yo cs student. When the project began last year, I was definately an unexperienced programmer. Hell, I can't claim to be really experienced even now, but boy how much I've learned during this project.
The project specs? It'll be run on Solaris. Use perl. And we want fancy windows. The main purpose of the program has remained constant (I don't want to go public with it, even AC, it's rather spesific), as has the platform (perl on Solaris) but everything else has pretty much changed. I can't blame my superiors, really, because over time things change and everyone learns new things.
I took my first attempts at perl some five years ago. Looking back, I can understand why so many people bash perl for its syntax and the shortcuts & quick hacks it allows. But my humble opinion is that there's nothing in perl that inherently would lead to bad code. None. It might require a bit (ok, admitted, a lot) more self discipline on the programmer than other languages, but when one learns to do it properly, coding it is a bliss.
The project is fairly large (some 5000 lines of perl code plus perhaps another 5000 glade-generated perl, which I don't need to touch) . I'm alone on the project, which help keeping the perl syntax the way I understand it, but there are tools like perltidy (http://perltidy.sf.net/) which can be used. I keep the whole thing in CVS, making sure every change to the sources gets documented, and I follow a rather strict release plan (I wrote it fo r myself).
The main benefit from my point of view is that generating new code is quick and easy. The code behaves the way I'd expect, there are no funny businesses with core dumping, segfaulting or security problems with buffer {under|over}runs. Granted, the code would most probably be faster had it been written in C, but then again, some features MUST be scriptable (OK, embedded perl would've been a possiblity) and the deployment time would have been far longer. Especially given the quick, abrupt and major changes that have taken place during the flow of the project.
My philosophy? Make components (modules or objects, depending on your stance) that have documented interfaces and do what they are told or scream about it and return in a sane internal state. Write tests for them. Obey the OO philosophy and use set and get functions even if you 'could' directly modify the variable. DISCIPLINE.
When that's done, you can easily use them, combine them, even extend them (either by inheriting or whacking the source, but then you must be careful not to break anything).
And the thing of it is? The same code runs on my linux laptop and the big-ass solaris server, with zero modifications. Reliably. As long as I do system-side stuff with perl internal functions (or external modules which support both systems), there's nothing I can do in linux that wouldn't work in solaris. Try that in C or Java. (Sidenote, I've seen 'light' Java applications effectively trash the several-thousand-dollar sun server that run fine on any pentium-class pc. It took the authors (a fortune 500 company) several months to finally fix the issues. So much for drop-in portability of java).
Time for a final conclusion: In my humble opinion, it IS possible and benefical to write professional code in perl. You've got to give in on some perl magic and syntactic sugar, but you still get the (IMO) main benefits of perl programming: (1) quick deployment, (2) easy debugging, (3) the VAST, ENORMOUS, HUGE collection of CPAN and (4) high-level portability to virtually any UNIX box out there.