Slashdot Mirror
Immortal Code
ziani writes ""... Sometimes a piece of code is so elegant, so evolved, that it outlasts everything else." Nice article at Wired wondering how much great (and lousy) code is lost due to business failures."
← Back to Stories (view on slashdot.org)
Code that lasts 'forever' and gets passed along, like DNA? How unusual!
That might be the case. I once had a BBS utility out there in the bad world but I never released the source code as it, frankly, embarrassed me.
It's Christmas everyday with BitTorrent.
How can you tell if something is written elegantly if you cant see the source? Elegant code does not imply well working code and well working code doesnt mean that it is written elegantly. You can have a program that works great and never crashes but is written poorly and does not use the system efficiently. You can also have very buggy code that is written beautifully.
Come on guys this is not a story at all. Good code gets bought and reused. Thats not news thats anti-news (it would be news if people didn't do it). So thanks for alerting me to another article that doesn't matter about anti-news.
No way the code from busted companies gets lost. I'd bet that most if not all coders get themself copies of their code and keep it in their own portfolio to reuse and recycle it.
And of course you don't destroy your copies just because another dot bomb has gone off.
Imho that article is a nice myth...
One of the true beauties OSS is its immortality. Given the "deep" copying of source code from OSS projects (there're many many repositories), it's hard to believe that we will ever lose any software developed in this way. In addition, good, useful OSS is iterated over and over. Just look at Emacs for example. I like to think that Science and OSS work the same way: result/programs are published and reviewed over and over by other scientists/programmers. Some projects will achieve amazing level of perfection, just as some theories, like quantum mechanics, are exceptionally accurate and useful. It took many iterations to get that theory right, as it takes many iterations to create perfect code.
Also in open source, I find that if I write something someone else may have a mod that they want in it or they may make their mod on the code and then ask me to include it. I then review thier mod and determine the best way to include it in my code. They may also review my code and offer suggestions on how to improve the code. This does not happen all the time at corporations. I can't speak for all companies, but some that I have worked for, it is more important (read moneywise) to get the code done and to the client than to do it right and nicely. (Code review, by someone trying to modify it or by the owner?)
Lastly in open source, developers are more likely to rewrite code and drop bad API's (gtk1.0 -> 1.2 -> 2.0 just look at the text widget, notebook and a few more) and do it right the second time around no matter how long it takes than private companies. (Rewrites and screw the client they'll get over it!). I think that this is becase in windows it has traditionally been much harder to have multiple copies of similar dlls than UNIX (not impossible, just more difficult, IMHO). Glibc is a good example of shared libs that you can have many versions of. M$ has a tendancy to wrap its API's on top of each other and keep old baggage around so you have no idea of what you are actually calling, or to change the API and then not tell you.
Only 'flamers' flame!
I think it has to do with pressure of business that causes cruddy code. Often in my company we're asked to write full projects in 60 days or less -- that kind of tight schedule doesn't produce great code. Let's also not forget that open source code "matures", whereas in the corporate environment we rarely touch working code unless it's to add a new feature (in a day or two). It's a crying shame (and I frequently find myself crying), but we are just not allowed the time to go back and make the code "good".
Rev 1.0 of any software is not as elegant as it could be; even in OpenSource. OpenSource has the luxury of not needing to move on to the next project ASAP to be profitable.
I don't think they talked to many coders. Who doesn't keep a copy of their work, especially if it is good?
Good code get reused, but in a more organic way...
"You can also have very buggy code that is written beautifully."
I guess it depends on your definition of beautiful code. For me beauty is not in the formatting or the intricacy... but in simplicity. The same aesthetic that favors art with clean flowing lines that is punctuated with edges and corners or melodies and harmonies that smoothly slide in and out of each other applies to beautiful software. There are, believe it or not, beautiful pieces of Fortran IV out there --
they do the job cleanly and efficiently while being easy to read and follow -- elegant. Elegant code tends to be less buggy because you can see what it's doing.
//TODO: Think of witty sig statement
Sent from my ASR33 using ASCII
It shows no examples of immortal code. The closest thing they mention is that when Scour got bought, the new company archived the code, but never used it.
That's hardly immortal, that's entombed.
Examples of immortality would be things like
* Bits of BIOS still in use from the original IBM PC through today's pentiums
* Bits of Multiplan that percolated through Excel
* Bits of CP/M still floating through Linux
The article makes a bigger point on how transient software is, and how 99% of what's created is tossed out. How many times, when asked to fix code, do you just rewrite it anyway?
Design for Use, not Construction!
Is it just me, or is that story just unbelievably depressing? The writer didn't really acknowledge this - those two people who spent their lives working on Dragon Dictate wound up completely hosed, and can't hack on their lifes' work anymore. I mean, *ouch*!
The code escapes on floppies and CD-Rs. Developers are always swiping copies of good code to take home. Whether they wrote it or not. Good code resurrects itself again and again.
We all know it happens. Many of us do it. We take code with us and "massage" it for the next job... or a job two years later.
In they eyes of the law and in the eyes of society, it is wrong. To me and most developers I know, it is right. Nothing will ever stop this practice.
Wonder how much well-designed assembler and punch-card code there is out there. While due to being platform-specific most would not be immediately usable, it would be nice to be able to read snippets to explore specific computer platforms for curiousity's sake.
Michel
Fedora Project Contribut
Perhaps we should look at it that way: If all good code would and could be reused, more than the half of all software engineers would be ou of duty soon
In that case, a "software engineer" would be someone dedicated to designing and building systems by putting together building blocks of code, instead of writing code from scratch. Software would start to resemble other engineering disciplines.
See charts for twitter trends on Trendistic
In my other response I omitted the cache manipulation stuff. That really rocks if you get it right. Assembly will seldom beat a good optimiser these days, but a good knowledge of disassembled code will help you write C/C+ code in such a way as to make life easy for the optimiser, whilst still maintaining a degree of portability to your code.
Modest doubt is called the beacon of the wise. - William Shakespeare
> d) Lose that f***ing % operator, which will do a lovely job of stalling the integer pipelines while it computes the modulo. ( count & 0x03) does the same thing much quicker.
Or lose whatever compiler won't optimize "% 8" into "& 7" for you. Certainly any one written in the last 20 years will do that (at least if you have optimization enabled)
M$ has a tendancy to wrap its API's on top of each other and keep old baggage around
Granted, but the 'have no idea of what you are actually calling' part would only be applicable for someone who doesn't read documentation.
or to change the API and then not tell you
I call BS. Can you give an example?
--Jeremy
Jesus was a liberal
That must make you feel conflicted - giving your best for something that will not see the light of day.
I feel that alot of coders *don't* give their all - for fear that their nuggets will be tied up and misused for profiteering via patent/copyright enfringment cases. They hold back their best work for open source or private projects - hence the blecherous state of most code bases. I earnestly pray that is the case, because it is more distressing to think of the alternative...
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
I don't agree with the premise that DNA is "the program that operates the brain." DNA is the hardware; my personality, what makes me who I am, is built over that. A gene in my family that predisposes me to alcoholism doesn't automatically make me an alcoholic--it simply means there's an exploit in my OS which may be exploited through excessive alcohol use. The final decision on who I am, however, rests with me.
True, some people are content to be nothing more than their DNA or their background dictates. But we can reprogram our brains, just as we can reprogram any other computer.
!#@%*)anks for hanging up the phone, dear.
I think if you look at a typical closed-source driver written by a hardware manufacturer based on this code you will see some really bad stuff. While open-source Linux drivers, even if based on sample code for other drivers, is a lot better. Closed-source linux drivers seem to be as bad as non-MicroSoft Windows drivers and crash a lot.