Slashdot Mirror
Outstanding Objects (Developed Dirt Cheap)
Mark Leighton Fisher writes "Some readers might be interested in
Outstanding Objects (Developed Dirt Cheap); or "Why Don't Developers Search the Literature?" It seems like I still see a lot of wheel reinvention going on, even with the wealth of code and information now available on the Net."
It's because all us developers think our way is the better way :P
Rick
Making something out of nothing : MD5 ("") = d41d8cd98f00b204e9800998ecf8427e
1) There's no pride in using someone else's code.
2) GPL'd code can't be used in commercial apps (blah blah, technicalities, yeah yeah, just try to get it past your boss)
3) If you're paid by the hour, what's the rush?
I wasn't aware that AC/DC was involved in software development till now.
Looking at myself at least...
Most of us are lazy by nature. It takes a lot of effort to go out and find what source code I need. Why would I do that when I can just write it all?
And of course, my code is better than whatever else I could find. Why would I want to use someone else's?
they all use visual basic!!!!11
In which case they are not inventing anything.
Karma: The shiznight, mostly because I am the Drizzle.
Why search the literature when you can just patent the wheel? A bunch of lawyers will come around and tell you all about the previous ideas, and you avoid doing even a second of research.
The goatse guy for president. Win one for the gaper!
If it's generic enough to be scratch your particular itch, you'll need to do a lot of work to implement the specifics of your case. If it's very highly specialised, you'll need to do a lot of work to adapt it to the specifics of your case.
;)
Given the choice, would you rather work on adapting someone else's code for your situation - or would you rather write your own from scratch?
(it's a rhetorical question
"None are more hopelessly enslaved than those who falsely believe they are free." -- Goethe
It seems like I still see a lot of wheel reinvention going on, even with the wealth of code and information now available on the Net.
SCO
Because it is fun! One of my coworkers once asked me why I would reinvent the wheel, I was doing stuff in Lisp for autocad, and he said that he could proably find the same thing online. I told him that the challenge was fun, and along with that it allowed me to tailor the function to exactly what needed to be done.
ur teh funnay
Generally though, it's not even that I think my code is better, but that my code will get better by having learned the pitfalls the hard way, given that I have enough time to do so without sacrificing sleep, personal hygiene and sanity.
---
I read your email...
Who is John Galt?
I still see a lot of wheel reinvention going on...
Not Invented Here.
StrategyTalk.com, PC Game Forums
some times it's not appreciated. but hopefully people eventually come around.
library uses wrong language
library has the wrong license
library pulls in too many external dependencies
library not threadsafe
But it's worth the search - occasionally you find a real gem.
It's far easier for me to spend time recreating code that exists already than to hunt down what's out there, read the documentation, figure out what drugs the developer was on, and customizing it. I make use of perl modules and bits of code on Usenet, just to save time, but that's the extent of it.
You have enemies? Good. That means you've stood up for something, sometime in your life. --Winston Churchill
I always hit the net before emarking on coding. There's no way I'm gonna spend 6 hours throwing together code that someone else has spent 20 lovingly moulding for me :-) I just too damn lazy... What can I say, Wally is my hero :-)
-- Gaxx
Done Dirt Cheap.
It doesn't matter if the code is available from somewhere "out there", from inside your company, or even from inside your group. The reality is that developers in general don't play well with others. Why? For a number of reasons.
First, it is no fun to use someone elses code. This is why at one time Apple computer (many years ago) had 13 different (yes, I counted them) memory managers being written. It was fun to write a memory manager, to solve the problems involved, etc.
Second, people don't trust one another. How do I know that you have implemented this code correctly? How do I know that you will deliver the modifications that I need? That you will deliver them on time? I can't, so it is better to do it myself.
Bottom line, we don't play well with one another, because we want all the fun for ourselves and because we don't trust the other folks (called flipping the bozo bit in some corners).
Some of it is vanity like the above posts claim, but some of it is common sense. If you can build it faster than it will take for you to look it up, verify it is available and being supported, and determine license restrictions and costs before you even get it approved...well sometimes it's just easier to carve your own wheel. You'll find more reuse inside a company than between a company and the community at large. IP is still a real thing and holding it is important to corporate america regardless of the views of RMS.
Most developers probably don't even know how to search CPAN or install a module from it (or PEAR for PHP). So they roll their own inferior solution. Those who have spent the three minutes reading the docs are getting an incredible benefit.
Much of the time I like to reinvent the wheel. There are several reasons. First, it's a learning exercise, second Iown the code I write and third I do it my way. This may seem petty, but if there are bugs, I'm the only one to blame, and I learn by doing. If I was doing something in the course of my paid work, then I would use the conventional resources.
Stick Men
By your argument, why even use standard APIs? I mean, isn't CPAN just a bunch of domain-specific APIs put on the web?
Yeah, thats a big thing on our team, how much do we test the modules we rely on vs how much do we trust the group that wrote them in the first place.
"You can now flame me, I am full of love,"
We reinvent the wheel because new wheels look sexy, not because they roll any better.
I have absolutely no idea whether there's a point to be proved with that, but it's kinda interesting.
I almost always do a quick search to see if I can find some code snippets that solve a problem I encounter. Spending 10 or 15 minutes to find a solid piece of functional code is a lot lazier IMO than writing everything from scratch.
These people look deep into my soul and assign me a number based on the order I joined.
If your problem is trivial, it's faster to write your own code. If your problem is not that trivial, it takes a lot of time to try to understand someone else's non-trivial solution. More than it would take to write your own code.
2. They are taught the complete spectrum of software development from function to complete program. So they think that they can do it all reallllly well.
3. They don't get in the habit when they start.
4. They get paid by the hour not the thought. (sorry thats an old lawyer joke.)
Quit blaming the excellent code out on CPAN. Blame the idiots who can't properly decompose their programs or even properly install what they find.
I write a program, and part of it needs to simply read a
Do I _REALLY_ want to pull in libpng and libSDL just to do this? What kind of risks does pulling these libraries in add to my project? How much will this bloat my code? Will users be confused from the different versions of these libraries? What if I one day want to port to a platform that these libraries work on?
Turns out it's usually simpler, easier, and less risky to just roll your own.
Let me make an analogy between using someone else's code vs. writing your own and buying a (not custom) PC vs. building one yourself (a few years ago).
First, the PC came with this video card I didn't like, so I went out and bought a different one. The OS that came with this OS don't use, so I have to reformat the hard drive. The case was also ALL plastic and it was hard for me to drill some clean holes into it for my modding. I had to go out and buy a different case. In fact, i spent my time reassembling the whole darn thing just to make it fit my needs. I should have just built it from scratch and save alot of time!
That's why I don't like to use someone else's code. Now, I would LOOK at their code and see how it works, and then write my own to work the same way. If I am lucky, their code is already the exact way I want it, but it's very rare.
Very modular codes however, are useful at times. THe only problem is that it comes with other crap u dont need and takes up coding space, but that's just nitpicking when you dont have any time.
I develop in Delphi and I use a lot of stuff from the net (if you want to learn how to create reusable components, and use already made components, this is THE development environment, and there is even a free linnux version! and it is PAscal, not this joke of a language called C or C++).
anyway, as I work that way (for my company), I then get nailed down by the legal team because most stuff on the net doe not have a licence attached to it, or has a wrong licence, or the company wants to kee 100% copyright on stuff, but we can not contact the authors or something like that.
ie: if you develop for a company, you do not have the choice, you have to re-invent the weel (or hide it from your superior and legal teams). what a shame....
... they could not pretend they invented something and patent it
hehe, i have become quite talented at finding those necessary little nuggets of code which help finish those homeworks due monday morning.. especially at 7am on monday after an eventful college weekend.
:p*
thank you google.
*no plagerism though, that's wrong, so is my spelling
Ever tried to work a library that does something very similar to what you need it to do, but not exactly? You end up writing more code to get it to work with your program than you would have written just implementing it from scratch. That code tends to be bulky, difficult to maintain, and prone to bugs. Sometimes it's better just to start with a clean slate.
Why not use publicly available code?
Its a matter of opportunity costs. Basically, instead of looking and using the free code, you can be developing your own code. Which is better is really a comparison of the 2 costs, where the unknowns of free code can make it unviable. "Free" code is not really free. It has liscensing restrictions sure, but thats not what the big problem is. There are time costs associated with using "free" code. There is a cost to searching for code that may be of use. There is a cost to figuring out wether the code is appropriate or not. There is a cost to learning how to use the code. There is a potential cost to discovering after much work that the code was not appropriate or has bugs or has a liscensing problem you were unaware of. These costs are very hard to estimate up front. Doing the code yourself on the other hand is easy to estimate and in most cases is much lower than the potential costs of using even "free" code.
The project im working on at work is customizing a non-free web reporting package. If we run into a bug we can not fix, or an issue we cant work around, there is a chance of wasting years worth of development hours. Its a huge risk and one that there was much debate about. It remains to be seen if using the web reporting package was a good idea or not. The cost of the package is not the deciding factor in these decisions. Its the potential time costs and time to market costs that dominate the decision.
PS. I am not an economist. please forgive my 2 econ college course knowledge
... then to find a wheel, see whether the documentation states how many spokes it has, give up and count the spokes, determine what the rights status of the wheel is and, if it's not open source, what the royalty agreement is, convince your boss to license the wheel, compile the wheel, fix the compile errors due to your compiler vendor not implementing the language standard properly, build an adapter to allow the metric wheel to fix on your U. S. Customary hub, test the wheel, discover that it vibrates dangerously at 16.5 mph, try to balance the wheel, and finally give up and build a wheel.
"How to Do Nothing," kids activities, back in print!
That's why patterns are all the rage. It's much more efficient to code within a pattern than it is to hunt down, examine and adapt code written by someone else.
And of course, as others have pointed out, the Not Invented Here syndrome is quite prevalent. It's always more fun to code your own stuff, and it's a learning experience.
Easy. Just because something is "already out there" doesn't mean you can't do it for your own purpose. This is where innovation comes from. People see what others have done, implement it themselves, and add something the original programmer hadn't thought of.
Try to rewrite LWP or DBI yourself with no peeking. If you have something even 50% as good as these modules in two months of full time coding I will be amazed.
Its exactly the best coders who make heavy use of CPAN.
Tout it all you want, but look closely at all those perl modules and c libraries around.
Most of them are under the GPL.
GPL = Can't use in a commercial product.
(err- a commercial product that you don't want someone else to steal)
I *really* think the LGPL should be known as the "Library GPL"
I browse at +5 Flamebait- moderation for all or moderation for none.
I write my own code because, generally, I'm the one left maintaining it. If some minor requirement changes, it's much easier to open up the code and find the necessary changes in code I wrote (since, theoretically, I understand it better than anyone else) than to wade through someone else's code. In the case of libraries, I can make my one little change and be done rather than have to crack open the library, or worse find a replacement and rewrite whole blocks of code to use the new library.
;)
At least, that's what it's about to me.
Obviously this will vary depending upon how complex the stuff is. But for a lot of simple stuff that's why. Those of you who haven't had the joy of debugging someone else's code might not realize what poorly commented code really is like. It can be a nightmare to support, let alone get integrated.
Yeah if it is very modular and has a good API this isn't a big deal. And for people who can't look up general algorythms they are great. But for a lot of things a little research combined with a little invention is better.
The other problem frankly is the GPL. But that really depends upon what your code is going to be used for. We resell libraries so touching the GPL is a no-no.
A lot of my projects are AI and/or web based. Web based apps are too damn terse to be bothered. (Anything more sophisticated than a pretty database query ought to simply message pass to something beefier.) AI programmers think that every project require writing their own custom database engine. I generally sift out the schemas and try to re-engineer the idea to use something conventional like TCL and MySQL. (As opposed to Fred's programming language and an ANSI text flat database.)
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
Code reuse is a great idea. In theory. Where everyone wants to live, cause everything works in Theory.
Quite often it is easy to pull in someone elses library to work with your code. Though note, libraries. Libraries are designed to have some reuse to them. But the library has to have a static API that isn't going to change, which isn't always a safe assumption.
Another aspect is refactoring. Here at my current job I have spent the last month refactoring one of our applications. I used a lot of concepts from the original code, yet the implementation was not what we needed now. Originally the code was used for batch processing. However, the new code which does the same thing is built for a thread safe and high speed processing. The data structures it used originally had a different use.
So, one of the reasons to write your own code is for your own specific purpose. I like to look at other code before I write something, but rarely does someone else's implementation fit the mold for what I need.
Norris/Palin 2012
Fact: We deserve leaders who can kick your ass and field dress your carcass.
I would say that about 30% of the code in use in my organization is from freely available sources, and used with total disregard to any license it was available under.
Congratulations then. It's something that should be done. I wasn't the one who said people fail to use the resources they have; it was the article.
I was just stating what I felt was the general answer. Take your average support message board. You see the same question come up over and over again because people don't do a quick search to see if the question has been answered again. They think it is easier just to ask the question again, rather than to check other peoples, when in reality, it probably takes more work to type out the question.
The time it takes to fully understand other code is often as large as the time to create code in-house. For code created internally, there's someone who understands everything about the module being used. Because of this, if there's a bug in internally developed code, it can often be easier to find and fix than third party code.
...is Monday morning quarterbacking, then doing things your own, "better" way. The other half is having someone pay you to do this.
Well, I would RTFA if I could RTFA, but I'll try to give you an answer anyway.
The problem is granularity. I interpret from the title (and nothing else, since I can't RTFA) that they want to reuse individual classes rather than entire projects.
I _hate_ the fact that every UML diagram begins with a blank sheet of paper and that individual classes are almost never reused.
Individual classes, however, are even harder to reuse than whole libraries. In theory you could take somebody's generic model of, say, a Person, and extend it with the extra things you need. As long as Person were well-written it might actually be reusable.
But in practice, it won't extend the classes you need it to extend, and it'll probably be tied in to a vast array of other classes that you simply don't need, making your life very complicated. Since requirements gathering is far harder than code writing, people who have to gather their own requirements generally just end up writing the code to match, since it's a trivial effort.
You lose a lot when that happens: you can't reuse a lot of other processing code that you want. However, how long will it take to find that code? Days, plus the time it takes to adapt? How long would it take you to write it yourself?
The lower the granularity, the harder reuse is. I'd like to see better, but with present programming languages it's not going to happen.
I do, however, try to find those libraries before reinventing the wheel. Occassionally I do find one that will work, and then I'll be faced with integrating it into the project. At that point, I've always found it beneficial to go through and edit the source, for two reasons: 1) a consistent coding style throughout the project makes it easier to maintain, and 2) I tend to learn a hell of a lot by actually trying to understand what I'm editing. Then, maybe, next time I can reinvent the wheel all by myself.
Case in point: I spent a week searching for C++ source code for a math expression parser (put in x+5*y, get result). I found ZIPPO, except for 3rd party libraries, and ONE crappy C code from 1997 and ONE C++ code written in German that has a ton of subtile bugs.
So unless the code is EASILY FINDABLE, WELL DOCUMENTED, and USEABLE, then it's MUCH faster to do it yourself.
The intro implies that only OOP can make reusable components. I don't want to start yet another paradigm war, just point out that there are non-OOP component solutions to a lot of things. I used to use extensive math and graphics FORTRAN libraries as an intern long long ago. They were surprisingly useful and easy-to-use in most cases. I am not promoting FORTRAN here in any way, for there are a lot of nasty things about it; but it still allowed extensive component usage before OOP was the thing.
Table-ized A.I.
I'm not sure I that the 3 reasons Mark Fisher gives for lack of code-reuse are the main issue. Usually I think programmers are just too lazy to search. I had one predecessor that I always suspected had this disease. I've noticed in myself at times too. Usually you think that if you (re)write it, it'll be easier than trying to understand someone else's code (often but not always, you are wrong. :).
That said, let me pass on a little practical story. Having built solutions myself that were quick and dirty, for version 2.0 of a recent project I worked on, I decided to dump most of my code and try building on an existing, well-known open source project in my area. I've spent 4-6 weeks trying to take a well-known piece of open source code that performs a similar function better than my quick&dirty approach. I'm not finished, but with the deadline past and with significant obstacles remaining, I'm really questioning my well-intentioned attempt at re-use.
So let me toss out some more reasons why developers may not "search the literature":
1) the (time)-cost of doing the search,
2) the cost of figuring out the implementation details of what you do find so that you can effectively use it (which can be anything from understanding perl module documentation to understanding the concepts behind lex/yac or some protocol),
3) the time/development-cost of integrating the open source codebase into your codebase; this includes porting or handling dependency chains
4) the risk that, because of some detail that you won't understand until you fully invest in #2 (above), it may end up that this tool you are reusing actually doesn't solve your problems for some unexpected underlying implementation reason (something you can avoid if you fully develop your own solution with methods you *know* will work)
5) the risk of choosing the wrong alternative (e.g. picking one templating system out of the dozen alternatives that then gets orphaned)
I'd like to reuse code more, but rationally there are a bunch of reasons why I don't do more. These need to be addressed more satisfactorily for more code sharing to flourish.
--LP
Firestone, Goodyear, Michelin, Continental etc all redesign the wheel every year. They try new designs with varied rubber thickness, sidewall materials, traction depth, doping materials. There are plastic wheels that prevent shopping carts from leaving the parking lot, airless rubber wheels in public bicycles in Prauge, castor wheels that come in pairs and run on carpet. There are wheel bearings in the axles of your car, wheels used to roll the drum in your drier, wheels that hampsters like to play in. Wheels are turning in the pully being used to haul furnature to the 4th floor, they turn in the CD player running in the 4th floor apartment, and they will be used to roll the refridgerator into its final position where the wheels in the compressor will turn to cool food.
I'll wrap this up before this tirade degrades into "The Kentucky Fried Movie." The fact of the matter is when people say "re-invent the wheel," they almost always mean "redesign the wheel" or "re-implement the wheel," both of which happens every day in our wheel-obsessed society.
Balance that perspective.
The ______ Agenda
I think there's also the perception that looking for a library to do what you need isn't work, while writing a solution is.
If you've solved it by finding a library that does it, but it took you a while to find the right library and figure it out, you may find yourself in the hole. Your dept manager may ask "Why aren't you finished? You didn't have to write that component..." and be unhappy with the (accurate) reply of "Well, no, but it took me a while to evaluate the libraries available..."
I'm blessed to be avoiding these at my current position though, so I'm thankful.
-Zipwow
I don't know which is more depressing, that 2/3 didn't care enough to vote, or that 1/2 of those that did are crazy.
Back in 1990 I worked for a small company that built
graphics boards and my first task was to debug
the "polygon fill" routine in their firmware.
It turns out they use their own "home brewed"
algorithm that was slow, memory hungry, and didn't
handle degenerate cases correctly. If anyone in
the company would have taken the time to pull
any one of the graphics textbooks off their shelf
(e.g., Foley, van Dam) they would find a much better
solution.
I ended up rewriting the module myself using
the classic solution -- it was faster, used little memory,
and handled degenerate cases reasonably.
It was my experience that everything was a badly
reinvented wheel when I worked there.
FOR THE LOVE OF GOD, let's all take a deep breath and remember that ACCOUNTABILITY IS AN OPT-IN PROCESS.
That's right: while it is interesting to see everyone getting so indignant about people that have identified someone they think is wrong in their lives (which you can rightfully argue about, but they have made a choice that this is something that they want to work to remove from their lives) and which they are trying to weed out. This is an opt-in choice. No one is forcing a person to sign-up for this service or to receive the reports. This is a free choice between consenting adults.
I don't know about the rest of you, but I know that I have behaviors that I would like to see changed. For some of us these are addictions (sex, porn, alcohol, drugs), for others it is a desire to improve ourselves (spend time with significant people in our lives, exercise, control our tempers better). As various 12 Step programs have shown, and as others knew before them, one of the best ways to do this is to build accountability into our lives.
All this is a high tech version of what happens at an AA meeting or in prayer groups in many churches. People are confessing their "sins" to one another and being encouraged to go out into the world and continue to pursue what they believe is right.
I don't know about the rest of you, but I know that I am not perfect. I am far from it. It would like to see change in my life for the better. I would like to be more regular in working out, focus more attention on my children, give my wife my time, be more attentive to friends, to not procrastinate, etc. I have folks that are my accountability partners. Do I use a system like this? No. But can I see the benefit to some? Yes. If it isn't meaningful or helpful to you, then pass on it. But if it works for the folks in question, then respect them as consenting adults doing something in the privacy of their relationships.
If the source code is freely available (or if the code comes from a reputable company/source), then code re-use is great, otherwise it can be too much of a risk for a project:
1) How buggy is the code? If there are problems in your software as a result of it, how can you fix things (can you even?). Debugging your own code due to your own mistakes is one thing, finding other people's mistakes is another. And if fixing it is out of your control, what do you tell *your* customer when things go wrong?
2) How supported is the code? Will the author be supporting this thing 2 years from now? Or will he/she move onto something more "fun".
3) How stable is the code? Will the interfaces change every release because the owner wants to do things differently and can't be bothered to support older methods (regardless of how many people that screws)?
4) How appropriate is the code? Do you have to bend over backwards in your own code just to use it properly (hopefully you've at least put a wrapper around it)? Reusing code just for the sake of reuse ain't generally a good thing.
Software sucks, and developers know it; of course, *their* code doesn't suck, it's everyone else's that does. Part of that problem is that anyone can pick up a book on programming and start to write software (it's too easy to do, although much harder to do right).
But, *knowing* all of this, it's of course much better to write your own. Besides, developers complain less that way (rarely do people complain that their own code sucks -- even if it does -- so there's less negativity: usually if your own code sucks, it's the end-user's fault).
I have been involved in software reuse since the mid-1980s and possibly even earlier. There has been lots of energy expended on the problem of making existing implementations extensible, one of the strengths of OO technology, though not requiring OO. The big piece that has always been missing has been a major concerted effort focused on facilitation matching a developer's needs with existing software.
... I have long felt that CASE tools, yup those tools that are totally out of vogue right now, would be of greatest value if they had a dual function. Their primary function would continue to be as a means of describing architecture, design, or code, but a secondary function would be to, in the background, perform a continuous search of existing work looking for matches. I have never seen a tool that does this, yet this seems a tremendously valuable function.
There are many mechanisms that can assist such as:
1 - technical reviews. When these happen, you get a number of co-workers together to review your work. Not only does this assist in ensuring that direct work (architecture, design, code) is correct, but it also provides an opportunity for all those involved in the review to search their knowledge of pre-existing "parts", be they architectural, design, or actual code, and to suggest you investigate them. Of course, if you're like me, then actual review meetings where a number of people sit down and examine your work just do not happen any more. Thus this form of identifying existing work that can be reused no longer functions.
2 - CASE tools
3 - personal memory - only works for those items you already are familiar with, which frequently gets voided when changing jobs.
4 - institutional memory - this is similar to the technical review mechanism, yet is less well defined. The real question here is HOW does an individual tap into an institutional memory? Documentation search? This is far less than perfect even if all work was well documented. Code search? Even worse at turning up matches to needs.
So... the bottom line is that it truly is VERY difficult to match up needs of a software development effort with the existing software that is available.
Once case in point... I worked on a very large project for an FAA (Federal Aviation Administration) contract. One mechanism I needed was a circular buffer/queue. These seem very straight forward to implement, and an obvious place to use an existing piece of design/code. Well, even after extensive search and review I could not find such a part and built my own. Later, I discovered there were at least six independent implementations of a circular buffer/queue in this single project team. All of them were general enough to meet the other implementation's needs, yet somehow none of us knew of the others' overlapping work. If we couldn't coordinate the reuse of these six independent efforts (and that means we all built the same basic algorithm, found the same set of bugs... and yes, using our code management tool I was able to see the same bugs being fixed in each implementation... and thus a total and unnecessary duplication of effort), how in the world will we ever solve the problem of reusing work outside the single project team, or outside a company?
There are some examples of wild success with reuse... though they seem to me to be more success though definition. All of those shell scripts that are built from individual command line tools are examples of reuse, where each command line tool represents a unit of software available for reuse. But, I think we all think of reuse more at the code module level... a function, or class, or small library. And it is at this level that I think we fail miserably, and it is my contention that we fail because we can't easily find the candidates for reuse.
Some or all of these things happen:
The library is under a license other than the MPL or LGPL.
We try to make the library work for hours, only to find it doesn't do exactly what we need, or is horribly broken.
We try to use the library, but it's broken, and the developer lives in France and only responds to emails while we're asleep.
It would be faster for us to write our own then to decipher someone else's code.
The only real third party library we use mostly does the job, but we had to wrap it and implement all of the features it didn't. In the end, we should have just created our own library. The way I see it, it's just one more thing we can sell.
Yes, I'm paid by the hour, but I also care about the quality of that hour. If the problem is interesting, I tend to research other solutions (to scope out the pitfalls and features I might not have thought of), then I'll often implement my own solution, because learning someone else's code tend to be pretty high on the tedium scale.
If the problem is NOT interesting, I have a lot more motivation to find someone else's code that I can use; if I find a quality solution, I can plug it in, spend hopefully minimal time debugging and testing it, and move on.
And there CAN be pride in using someone else's code, actually; I really get a kick out of using libraries and sending back elegant enhancements or bugfixes back to the authors ("Your library was excellent. I improved it.").
Also, if the code you found is really good stuff, it might help you to finish up a complex feature in record time, which also feels nice ("Oh, I almost forgot to mention it, but that new report we scoped out yesterday is out on the test server").
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
I spent a fun week exploring through the computer graphics repositories of the time (it was some years ago), but I finally decided I'd had enough fooling around, so I hacked out some quick C and converted the files.
The converter I wrote and debugged in a couple of hours was virtually guaranteed to crash and burn on any WTK NFF files but those, but I didn't care. What I needed was those files in Inventor so I could get on with the job of lighting and animating them.
That's the problem with the Booch Components and a good percentage of the things I see out there in the repositories today: they solve the general problem with such elegance that they're really optimally useful only for people who want to understand the general problem instead of knowing exactly enough to solve the specific problem they have.
Well, here's a news flash: a good part of the time I'm to busy to learn how to solve the general problem. What's more, I know I'll never need this knowledge I acquire again, so a quick in-and-out of my brain is all I need.
--
The end
My grandfather was a Tool and Die maker. If GM mechanics were having problems tightning down the distributer cap after adjusting the timing, GM would send him a car, explain the problem, he would take a look, make a couple of different wrenches along the idea of what he thought would do the job, then send back the wrench that did the job best.
.NET tool set, that you have personal reasons for not using (can't stand msft, can't afford .NET, can't follow the msft licence requirements, don't like that Craftsman sold someone's pattented idea to Snap-On without paying royalties to the inventor) and so you make your own tool to do what ammounts to the same job.
The knowledge required to get the wrench to work best required understanding several mechanical principles that he was particularly good at, and I am sure that there are others these days as well, mostly working directly for the automotive companies. (Either that or they have much better engine designers who have made it simple to get to all nuts and bolts without special tools. Looked under your hood lately? Which do you think is most likely.)
In any case, the common idea is that if you are going to make something that fits a custom need, you are unlikely to be able to do it with off the shelf components and tools. Occasionally there may be a nice general tool that would suffice for the job, in software it might be a component of MSfts
That's my thought, I could be wrong.
-Rusty
You never know...
I just don't buy it.
Have you ever seen hundreds of mailing lists where lawyers congregate to offer whatever advice they can?
Free modules everywhere? Documentation on hundreds of concepts and ideas published and given freely for the legal profession?
Infact I can hardly think of another profession comperable to supporting it's peers than development.
I personally am firmly against object reuse. Unless it's really plain simple objects like smart pointers.
Unfortunately, I am working right now, and can't go in depth about what I think of this... if you wanna flame me, go ahead, maybe it'll summon up the courage in me to explain better. If on the other hand you know what I'm talking about, please explain to the rest of the world on my behalf... =)
Cute. Taking one of my replies from a totally different discussion) and posting it without attribution and as an anonymous post. Very fun. Of course, I am the only person that got the joke....
Did I do something to upset you? Sorry if I did.
1) Coders enjoy coding.
2) Liability
The Kruger Dunning explains most post on
Because you're just as smart as that other guy, right? And your code will always be better than his is.
Not necessarily. But if I wrote it, I got a pretty good idea of how good/poor it is. If I have to go through his code to find out whether it is good or poor, that'll probably take me just as long.
Kjella
Live today, because you never know what tomorrow brings
And that's not saying much!
Every time I need a nonstandard windows control (currency edit, picture buttons, resizable dialog box, etc), I hit sites like http://www.codeproject.com or
http://www.codeguru.com
I've used tons of code from these sites, and would encourage windows developers to check them out instead of re-inventing the wheel.
Slashdot: come for the pedantry, stay for the condescension.
Sure, it's frustrating to re-invent the wheel and create a custom library of classes when something perfectly useful already exists. However, if it's documented at all, most of the 'free' code I've come across out there looks like: /**
* Fubar formatter.
*
* @param param1 param1
* @param param2 param2
* @return int
*/
public int fubarFormatter(int param1, String param2)
{ [highly obfuscated code to prove I'm a R0x0rz coder dude!!!!]
}
Sure, it LOOKS like it MAY provide what I need, but I couldn't be bothered to figure out if it covers all of the possible exceptions which may be thrown or even if it consistently does what I require of it. Much easier to just design the proper solution and implement it in a manner which is internally reusable.
One of the biggest problems I usually run into that no one has mentioned yet is this: when searching the literature, I don't know what terms/keywords I should be searching for to find the code to solve the problem.
For example, one project I worked on was an interactive calendar application that would dynamically place multi-day events across the days on which they occurred. Well, I needed those event bars to be as compact as possible, so I searched for an algorithm to figure this out... After 3 days of searching and finding nothing, I asked a Computer Science professor at the local university and he couldn't come up with anything either. I know there is code to solve this type of problem, but I simply couldn't find the keywords to use to locate the code.
And just to chime in about what everyone else has mentioned:
My top reason for not using public code is the lack of quality documentation. If I didn't write it, it's really hard for me to understand it and make use of code without putting in considerable time studying the code, which is more time than I have.
-Adam
IMHO, finding pre-built functionality out there that does what I want, the way I want it, with an appropriate license and tolerable side effects that does not require me to make me own code dependent on the third party implementation is very difficult. I don't think the state of the art of component abstraction methodologies (class libraries, VMs, languages) are mature, complete and interoperable enough at the present time to reduce the amount of integration effort required for third party code to the point where using many components from different vendors in a single system is cost effective.
While functionality that you build can be an asset if you can effectively package it for re-use, integration code that you write to work third party components into your own application can become a liability, as it absorbs maintenance effort as the third party libraries evolve.
Third party code that has well defined interfaces, and would be very hard to implement yourself tends to be better suited for integration as the cost of integration over time needs to be less than the cost of building it yourself.
In my experience, it is easy to underestimate the amount of integration effort required for third party code due to vendors' incentive to promote their products. Some commercial vendors get you way past the point of no return before you find the 'issues'. Once you pass the event horizon, you may be doomed to have your time and money sucked into the black hole of repeated workaround and upgrade.
Open source is better that way- at least you can -see- what you are getting into before you decide to commit the integration time.
It is very hard to predict how much it will really cost to integrate with something you don't fully understand. If you do fully understand it, it may be less expensive to build it yourself.
Sorry, no one can hear you. You'll have to yell louder.
Now that you mentioned it, ever notice how many new wheel designs the car people put out every year? Maybe we'd better ask them why.
Well, you see, it was because I was running late on one of my programming projects and so I decided to um...reuse code I found online. Found a site of someone calling himself the BOFH which seemed like a catchy acronym so I dug around for some of his code snippets.
He went on about how it was great to put comments on code (which was something our instructor told us was a good thing(TM) so instant credibility!!!)
So I proceeded to borrow his comments too -- even though I wasn't sure how rm -rf * was supposed to mean "remark."
Aaaand this is why I don't borrow source code anymore.
I totally agree to some degree. :)
If every company wrote their own web server, that'd be stupid. But when a solution needs to be written due to a technical requirement or a business requirement, that will be more likely unique.
Lets take, something like.. the Java API. CPAN is quite huge and has all the tools that perl has. But someone came along and said, "We need a business language, that we can make money off of [ 2) ???? ] and fulfill a bunhc of things, like OOP and such." Thus, java was born.
Now you ahve two tools that can do the same thing, near line-by-line if you want them to. Yes, there are things you can do in one language, and not in others, but it can be done.
Now I want to start a company that sells ERP software. It's been done before, but I think I can provide something that other people can't. THAT is what is unique and why the wheel is reinvented. My software does something better, or at all, fulfilling a requirement.
Problem is, you can't strip out my "better stuff" and paste it on. That'd be like, using word for some things, wordperfect for others, and finally, use abiword for finishing touches. It'd either be economically stupid or impossible.
-
ping -f 255.255.255.255 # if only
Now. Do you know what an interface is?
I'll give you a hint: in C++, it's defined using pure virtual functions, that is:
void myFunction() = 0;
If you say C++ is for 'st00p1d' people... then try and instantiate an 'interface' (with no supporting class) in java. Tell me when it works.
Interfaces are not implementations. Interfaces are not code.
In many cases, at least in my experience, the time it takes to find an existing solution and learn to use it is often greater than the time it takes to reinvent it.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
Let's look at that differently. Consider recipes, another functional work.
Yes, the ingredients are the same, and maybe even the process for combining the ingredients is the same. But the way it is written affects the way it is read; the way it is read affects the way it is used - and therefore the way it is written affects the end product.
Looked at differently, look at books. How many books seem to have the same mechanics? The plot, the characters, and so on. Yet each book is different. Each author writes differently. And different readers like different authors.
I often don't reuse for reasons described very well by other posters, but I wanted to mention some cases where I either did reuse or wanted to.
Two years ago I was developing online courseware for a company that trained/certified future medical transcriptionists. We needed to develop a typing test. Now, a typing test is all about doing two things -- (1) noting when someone types something the shouldn't be there and (2) noting when someone doesn't type something that should. So you're comparing for absensces or additions between a given text and a key. Sound like anything else? My first thought was 'diff'. My second thought was Perl (after all, this is text slinging). My third thought was CPAN. And sure enough, Mark Jason-Dominus' excellent Algorithm::Diff saved me at least days of time and quite possibly weeks.
Now, this was possible in part because I was working as a contractor, and so was probably trusted a bit more, and also, in part because my supervisor/contact with the company was pretty savvy. I can contrast this with some other experiences. Like the company I worked for that wanted a webserver log file analysis package. Again, lots of text slinging, but perl or any other scripting language was out because we wanted the source as closed as possible. Nope, it had to be in C, and I was discouraged from trying to find a regex library to use. I essentially ended writing my own regex engine. It was buggy. It needed optimization. The syntax was less powerful . The stats package itself was good, especially for 1997 (it could do things I've only seen other log analyzers do in the last two years), but because it all ran on top of this flaky regex engine, it couldn't fly. I think it got canned after I left... nobody wanted to touch it. I seriously think I lost months of my life on this, and the company lost a good product. All from trying to reinvent the wheel...
Tweet, tweet.
That's why scripting and other languages were invented. Easy to write, easy to debug, easy to change. Build up a global library and pull what you need, customize accordingly. And has anyone figured out how much NIH actually costs worldwide? "Fun" can be costly, both monetarily and other metrics (lives lost due to buggy code)
Here at CMU's engineering department we have a relevant comic about this:
MOM: Glad to see you back home from engineering school, son. By the way, can you fix our toaster?
SON: Er...no. But I could design a new one!!!
SON: (later) I wonder how useful this engineering degree really is.
Practice Kind Randomness and Beautiful Acts of Nonsense.
Pascal is a girly-man's language...strong typing is for people with weak minds. If I want to shoot myself in the foot, I don't want my language telling me I can't shoot myself in the foot, dammit! :-)
20 January 2017: the End of an Error.
Unlike books, code is easier to write than to read. And that's even when it's commented properly.
"It's not your information. It's information about you" - John Ford, Vice President, Equifax
anyone else have the 'dirty deeds, done dirt cheap' song just pop into their head? :)
I'm finding that there is a lot of reuse going on in academics. I talk to professors who see the same papers over and over...
My company uses M$ SQL Server for our DB (yes we are a microsoft shop ) The server can be configured to send email using Outlook or any MAPI client, or can be configured to use SQL MAIL, which expose extended stored procedures such as xp_Sendmail. But no one looked into it so someone wrote their own sp_Sendmail, that connects to CDO using objects in the stored proc.
I think the failure to understand the capabilities of your tools and configure them is the main reason that people reinvent the wheel. (Outside of general the general "that's good but this way is better" pride we all have.)
I am so creative, look at my cry for attention in my sig.
Why don't we use more available code? Leaky abstractions for one. And look at the DLL and .so hell we're in now, where we have libraries that depend on libraries which depend on libraries...yik...all that to save a tiny bit of work, ain't worth it. Write your own.
I may be wrong, but isn't it just a matter of your truck wheel simply not fitting on my sports car, and vice versa?
-- B.
This sig does in fact not have the property it claims not to have.
Most of these boil down to time, time taken to work around the issue. If the amount of time saved is bigger than the amount of time to make free code work, it's worth it.
Each programmer has to determine, on a case-by-case basis, whether re-using code will work. This depends on the skill of the programmer, too; for some, time spent programming is far more productive than time spent trawling sourceforge for usable code.
People are never as simple as their stereotypes. This applies equally to Christians, Muslims, and Emacs-lovers.
The point of C is that sooner or later a programmer gets good enough to stop shooting himself in the foot. If he's not there yet, best to stay in the shallow end.
One of my biggest problem with "reusable" code is that it truly isn't reusable. A lot of libraries out there were obviously ripped straight out of a some other project and the interface reflects that. You end up spending as much time jumping through hoops to call the library as you would to rewrite it. And plus in that case, the places where the code meets is hard to maintain.
If engineers really want their code to be reusable, they really need to spend some time thinking about the interface. What are the exact semantics of each call. When an error occurs, who is the caller or the library responsible for cleaning up any partially finished events. How will the caller provide data; if the caller has data in a different format, how hard is to convert.
Until people start really thinking about interface/API design, reusability will never come to be.
Quite often, the act of comprehending what a bit of "reusable" code is doing exactly takes nearly exactly as long as writing a working example oneself from specification...
And usually, you DO have to comprehend what it does, even when it's supposed to be "opaque"... If only to understand the caveats of performance of the code in question. (Memory use most commonly.)
Hey F$%& U!!! - anonomous developer
And yet people expect OSS to take off.
I think one of the most important reasons it doesn't happen is because of the issue of encapsulation.
.NET), which is usually available to any application or object running on the OS. The fact that the OS supports these standard objects causes people to abandon their proprietary solutions and use the MS versions.
Most source code libraries are not sufficiently encapsulated to prevent other developers mucking with them. Many have seen that the binary component approach has achieved much better encapsulation, and therefore has been more successful when it comes to code reuse.
I have to say here, that the *nix/oss community has underwhelmed me with their support for binary components. Yes, there are java beans, and yes there is CORBA, but I've never known CORBA to be successfully used much (usually just part of an overly-designed from-scratch system), and java has some limitations I can't stand, but I do think it is the right approach in general.
This is really the area where COM has led the way (as much as I'm sure you hate to hear this). Think about the way that MS continues to provide more and more functionality through COM objects (and now through
I see this as a sort of mediation process. Everyone wants reusable objects, but noone wants to spend the extra time to implement generic interfaces that they don't need, or to even think about other people's problems. MS comes in here and provides objects that bridge the gap between these proprietary solutions, vastly reducing code bloat (since we're talking about binary components), and vastly increasing development ease and speed in some cases.
I'm sure many of you have never gotten into the nitty gritty of Windows programming, but I can tell you, binary components get reused. ActiveX controls get reused. Think about how different this is from the situation of open source libraries -- you drag and drop a browser control into your program and start displaying web pages... Load up media player behind the scenes and start playing mp3s...
I think that if the open source community really wants to promote reuse, they should begin to think like MS. Have the people putting together the distributions take the initiative to develop suites of binary components, and get a development environment that makes them easy to drop in. If this exists and I'm ignorant of it, let me know, but it seems to me that most open source development is not geared towards what I'm talking about...
OK think a moment. How long would it take for you to code up a linked list data structure? An hour? For me, prob 1 hr + 3 hrs debugging. It'd be a pretty simple module, right? Right.
Now take a look at the linked list implementation in the STL. Or the JFC. Much more complex, right? I bet those weren't built in 4 hours!
That homebrewed linked list you built may work for you, because you know its limitations and instinctively avoid them, but I don't. So I'd rather build my own linked list.
Oh, I suppose I can use the STL's linked list, but it makes the compiler sooooooo slooooooowwww.
Practice Kind Randomness and Beautiful Acts of Nonsense.
Now I understand why you can't even fill the gas tank on a GM without a special tool -- it's all your grandfather's fault! GM vehicles are notorious for needing special tools for any repair or even ordinary maintenance functions.
Most people don't reinvent the wheel the way you think of somebody working hard to come up with the idea of a circular object that rolls.
The correct way to think of coding items very similar to what is already out there is a tire company. You have different treads, sizes, applications, etc... but they are all "wheels". And nobody tries to tell a tire company it is constantly reinventing the wheel...
- I love animals. I try to eat at least one a day.
And where there's enough need for something to create a market big enough to generate enough revenue to pay for developing such code, it gets done. See "Rogue Wave", STL, MFC, libc, etc.
That's the fallacy of code reuse - the "if we start reusing code we can spend less on development" theory doesn't work unless the code you develop for reuse is really sound, well documented, and well supported.
I search the web for reusable code regularly.
There isn't a good single place to find code
that I've seen, except perhaps sourceforge.
Your link is slashdotted, but it's pointed to
a perl web site. I personally have been very
unimpressed with perl and with the quality of
programming I've seen in it. The concept of
maintainability and testing seems to have been
missed. You could do good code in perl but
I've seen little of it.
I think this also misses the concept of reducing
dependencies to increase software reliability.
-- Programming with boost is like building a house with lego. It's a cool but I wouldn't want to live in it
I use libraries (or modules). However, I don't think I've ever used available source code as a starting point for anything.
Reason 1: Most free source code is crappy. When looking for C code, for instance, you'll hardly ever find any that bothers to check the return value of malloc() and other functions that might fail.
Reason 2: Even when the code isn't crappy, it's usually not adequately commented.
Reason 3: Even if you find that rare piece of code which is both well-written and adequately commented, chances are it's not documented.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
I'll be honest - I never read the top link. I wasn't slagging CPAN or refering to Perl in particular.
I find it best to try to solve a problem myself, if I can't then I find someone elseâ(TM)s solution. Then I take their solution, study it, test it, and rebuild the whole thing. Seems stupid but it pays off in experience. If I solve a problem once I KNOW how to do it again. For me understanding what I'm doing is very important, it also makes debugging a whole lot easier and in the future I can reuse my own code and understand it immediately.
-Tim Louden
I'm the worlds greatest programmer, what the hell does anyone else have to teach me? I can write code much faster than anyone else, and have it finished before google even returns a result. Just look at me go!
... ... ... ... } }
for(i=0;i<4;i++) {
switch(i) {
case 0:
case 1:
case 2:
case 3:
Beep beep.
I think I made it clear: it's a job of system architects (or technology evangelists) to study the sources, to look for patterns, to evaluate patterns, using pattern knowledge to evaluate the source code, and, working very closely with software requirements, design and specs, to decide that some code is good to be reused or not.
Decision to reuse the code requires another style of thinking than most of coders have. Don't assign such job to coders unless coder's and architect's skills are combined in the same brains.
Less is more !
"There are some examples of wild success with reuse... though they seem to me to be more success though definition. All of those shell scripts that are built from individual command line tools are examples of reuse, where each command line tool represents a unit of software available for reuse. But, I think we all think of reuse more at the code module level... a function, or class, or small library. And it is at this level that I think we fail miserably, and it is my contention that we fail because we can't easily find the candidates for reuse."
And how does one describe software well enough that a machine can have the same level of understanding that people do?
BTW would you say that interpreted languages lend themsleves more to code reuse than compiled?
and it is PAscal, not this joke of a language called C or C++)
Someone mod this down as flamebait... Seriously... Pascal? Yuck. And I'd only say Delphi is loosely based on Pascal anyway, it sure isn't ISO or ANSI Pascal.
You don't know C++.
;)
;)
This is probably offtopic, but oh well...
I'm a programmer by profession, I've used Delphi since the betas of the first 16-bit version. I've also used C++ for years, and C for even more years, both of these on multiple platforms.
C++ is by far superior to Delphi as a general purpose language, as soon as you get to know it well enough to really utilize it. If you claim Delphi bests C++, you have no idea what C++ can do for you. Do you have any idea what the STL is all about? Do you know anything about operator overloading, and how you can create true type independency? I don't intend to flame, but how can you make such a claim without the intimate knowledge of C++ which you obviously don't have as you make this claim
Delphi is by far superior to C++ when it's about creating a quick app with a nice GUI, combined from the insane amount of good ready-made components and samples, and some parts of proprietary code. Or when you work with e.g. anything combining SQL with a GUI, Delphi will be hard to beat. Or when you need to handle a ton of localized versions, which I have to for a current project.
I could make lots of samples on why to chose X as a tool when doing project Y, but I guess my opinion comes through clearly enough. There is no best tool. There is no best language. There is no best OS.
Again I can't resist preaching, I gotta learn not to jump onto baits this way
The next great MMORPG.
Because I have to... I spent many hours looking for a free (as in beer) web project management software.
If you search google for "project management" you get at least 4 advertisements. Just for you to know how much supply (and demand) exists.
My requirements are very simple: Web-based, runs on Linux, contacts, projects, tasks, bugs and companies. Almost every project management has these features, but they don't have in MY way.
For an example to show how most of them work: I can start a project. But I can't assign this project to multiple clients. Heck. A project can only 'belong' to ONE client.
Also, user management. I didn't find one single software that would let me create an user, and let this user only browse ONE project, just for reading or writing entries. Most of them either concede full access or none at all.
So I decided to write my own. Will I reinvent the project management software wheel? Nope. Because my wheel is different.
Buy a Nintendo DS Lite
Using "their" wheel is usually cheaper than inventing your own.
.sig
But sometimes, it's a disaster.
How can you tell if their wheel is any good?
Including it with out evaluating it is a huge risk.
It's not even easy to guess at the risk.
Testing helps, but a good evaluation can be as hard if not harder than recreating it.
How can I know if Net::::Hesiod is the best thing since sliced bread,
or buggy garbage that should have been fixed long ago?
Maybe if some fitness/correctness/bugginess evaluations were made by someone
(even say, comp. sci. students as a homework assignment... )
-- this is not a
I thought Apache 2.x's Protable Runtime (APR) with its commercial-friendly license was a perfect fit for my project until the complexity of its memory pools caused me to abandon it. I could not determine the rules under which it was threadsafe. Its documentation was also very vague on key issues including memory arena ownership and resource deallocation callbacks.
I know what you're thinking: "Shut the fuck up - it's free" - and you're quite right.
My only point is that a little documentation can go a long way to getting a critical mass of programmers behind a project.
When Ford Motor Co. is designing the body for a new model of car, why do they "roll their own" new front fender design instead of just using the front fenders off the '92 Taurus?
I'm not trying to troll, but I thought this article was way too preachy. The author talks about people "reinventing the wheel," but the fact is (to carry the car analogy further) that you can't use the exact same wheel on every type of vehicle. That doesn't mean that you "reinvent" the wheel for each vehicle, but often you'll have to produce a variation on the basic design. Quit agonizing about it already!
So he's been able to find third-party code on the web to reuse in his projects. Good for him. His attitude seems to be though, that if he does it, it must be the Right Way, and therefore everyone should do it.
Anyway, the difference between C and Pascal has always been about how easy it is to trap array out-of-bounds conditions, which has to do with what the MMU can do, which these days I think the important part is out of patent.
Perhaps after the courts give them another go, the bug fix rate will go up.
How many 3rd party components are sold?
right there is reuse
The Kruger Dunning explains most post on
the people making the decisions barely understand the problem and more often than not are trying to solve the wrong problem. Great architects are few and far between and most programmer suck. I put myself in the "I suck a lot of time" category, and manage to not suck on a great day. What scares me most is when I start a consulting gig and 80% of the people there suck twice as much as me. That makes me think, maybe I'm getting decent at this. Then I slap myself upside the head and remember how much I don't know.
http://www.cs.vt.edu/~rosson/papers/paradox.pdf
Problems worthy of attack prove their worth by hitting back.
hmmmmmmmm
Anyone writing software for a living for PCs or equivilent should remember the subject line. Any software you write for this kind of platform will spend 90%+ of its useful lifetime running on machines that are at least twice as fast as the one you developed it on.
Additionally, from a purely mercenary perspective, if we don't use up those cycles, no one will buy new computers, and Moore's law will succumb to apathy rather than technical limits (which I would consider to be a sad thing, both in the abstract and because a lot of us would be out of a job).
There are no trivial problems, only trivial programmers. ;-)
Re-inventing the wheel often only occurs because no "wheel" presents itself pretty much immediately.
Business-specific logic/code (get the objective done) can rarely be found already coded and available.
Getting the objective done almost certainly requires interfacing with standard components. For instance, to make a graph you will author the code to populate the graph, but use perhaps the GD or imlib libraries and your chosen language's API to the library to draw it.
There is a signficant difference that must be understood.
I do however love it when a developer finds something available that fullfills his needs in a project.
In my case, at this momement (don't trash me, I'm only making a living) I use LOTS of code - it comes in the form of the CLR (Microsoft .NET). In the past I have used lot of other code too, like the Java libraries, MFC, Win32 API, etc. etc.
I mean, really, lots of the "trivial" stuff is handled by the libraries in your development environment of choice (or assigned to you).
Stuff that isn't "trivial" is what developers are being paid to do!
Any current software engineer has to admit that the tools available today are much better than they were 10 years ago.
Hey, I may be using VS.NET, but I still use vi and various cygwin tools on a daily basis. Whatever works.
This issue is a bit more complicated than you think.
As a professional Delphi programmer (also since the 16 bit betas), and a hobbiest with programming of microcontrollers, I'd have to agree that as a general purpose language, Delphi falls way short. Obviously because its not intended to be one.
Its damn hard to beat if you are writing a buisness application though, particularly with the addition of Boldsoft's model driven design and ModelMaker.
I'd sure hate to have to use it for some of the things C/C++ is particularly good for.
For a job like it might be better to write my own parser, only a couple of hundred lines, than use expat. It would also have been easier than using the expat code. Heck the code for the interface to with expat is more that just writing the parser from scratch.
There are four sorts of people in the world: fools, lunatics, idiots and morons. - Umberto Eco, Foucaut's pendulum.
Simple, a lot of coders are afraid of being sued later on.
Or get caught in some strange license restriction they didnt understand. Since few coders are lawyers its easy to quickly 'get into trouble'.
Not many things worse then having your work ( or your job if you are a captive coder ) deemed useless due to an 'oversight'.
While it sounds simple, with the current state of affairs in the world ( example SCO ), for some its just not worth the liability risk.
---- Booth was a patriot ----
But even after I've located a mature library, I still feel those jitters that make me want to do things myself. Why? Because my concept of how the problem should be solved, and how the solution should be exposed, rarely aligns well with how the library author exposed it. More importantly, I typically have a pre-conceived notion of how i'll use the exposed solution to build my software.
When I reach this point, I step back and take a deep breath. If I'm looking at a mature library, chances are the conceptual misalignment stems from the fact that the library author understands the problem space far better than I do.
Berkeley DB provides a good example of a difficult problem space exposed intelligently. Shortly after the jitters, I realized that my understanding of databases was sorely lacking; diving into the documentation helped me understand how to structure my thinking about my application's design.
In summary: I think that developers turn back in disgust from new APIs because the API factoring doesn't match the developers' pre-conceived notions.
gimmie a break. Delphi is a desert wasteland of resources compared to C/C++. Delphi isn't even a language, its a product. Borland itself has re-invented more wheels that I can shake a stick at, with their endless wrappers for the Win32 API, COM, ORBs, DB connectivity, etc. The *NIX world is a long standing example of code reuse in both C and C++. Check out the STL, Xlibs, etc.
There's code reuse of the small stuff. Say, if you're coding VB you'll soon have a big library of nice stuff that should have been there in the first place. I have functions like Limit, FirstWord, Capitalize, an object that can do logging to a file, database or anything else, etc. All that is small stuff on its own, but adds up after a while. Using another developer's stuff is also problematic. When you write a function you have some idea of what might go wrong in it. If using somebody else's code you'll often blame yourself first, and only after that look at the library. And there's integration. My library uses this logger object, so that I get messages about possible bugs in the program's log.
Then there's the big stuff you've *got* to reuse, or you'd die of boredom or never finish it. Things like big Windows controls, spreadsheet control, fancy toolbar/statusbar control, installer, etc. In these cases reuse is a very good idea, especially if you're using a stable product that's been well tested. Then of course there's always the evil component that worked for 99% of what you needed, is used in a lot of places in your program and absolutely refuses to do the remaining 1% right. With enough time it can be much more satisfying to roll your own.
here here!
and if you can't shoot your foot off (C) how are you going to blow your whole leg off (C++).
And if you can't think of a good reason to do that... well, I think the phrase girly-man was invoked!!
-C++ Troll
In my experience, it's because the software in question are not wheels. The wheels for most applications are the user interface library (GUI, server pages), DBMS, messaging system (queuing), naming service, document processing (such as XML), and remote procedure call infrastructure. How many people write those from scratch?
There is also an issue with knowing how the thing works and the ability to fix it quickly. I'm the one that's going to get paged at 3am, so I want to either be able to find the problem quickly and fix it or get someone on the phone at any hour that can do it. It only takes one crap outside library to really make my life hell. I'll stick with solid technology from well established companies and then write the rest. The extra development time pays off many times over in aspirin.
Just don't get me started on Pirelli or Michelin.
Some of the best code reuse I've seen is in Microsoft products. On my Win2k PC I have about 20 copies of 5 different versions of MSVCRT*.DLL. Previous versions of Windows had similar reuse of VBRUN*.DLL.
if you develop for a company, you do not have the choice, you have to re-invent the weel (or hide it from your superior and legal teams).
Not to mention SCO.
--Dan
I don't know about everyone else, but in the last 20 years I personally feel that ignoring established libraries and "gotta code it myself" thinking has dropped dramatically.
I was talking to a coder in my building who works in an all Java shop and his love of the language was specifically based around the large number included and pretested libraries in Sun's Java. Some of those libarary implementations I don't particularly like, but I see the guy's point.
Perl and Python, in different ways, are both creatures of their libaries. There are good things about both languages themselves, but CPAN is obviously one of the strongest things Perl has going for it, and Python's "Batteries Included" slogan is famous to any Pythonistas out there.
And using Visual Basic (*shudder*) is almost entirely a process of linking up premade objects.
Today, I see much more use of predefined libraries than there was in the infancy of widespread computing. How many people here have coded their own window managment lately? And while I know people still do their own, I am seeing a lot more off the shelf work in graphics as well. I haven't had to code my own 2d low to midlevel stuff in a long, long time. The various Canvas objects of the world are well optimized at this point and work well. And even for 3d work, much, much less coding by hand is necessary than just 6 years ago. I know game coders who are working with DirectX straight up, and not even tweeking the low level stuff anymore.
I think that some coders are lazy and they don't keep up with what is out there to help them with their projects as much as they could. I mean, I go through Fred Lund's python links every week, because I use Py more than anything else and want to know what is out there that will do me good. And I could spend a lot more time on this for other languages I know but use less frequently. Most of us probably could. But that doesn't change that my experience personally appears to be the general case, and coders as a class are relying on more prepackaged libraries as a group than ever before, and this trend doesn't look like it is going to stop anytime soon.
Look at the last three major langauges to hit my personal radar (there have been tons, I know, but I am just talking about the ones I have started using the most in the last decade), Java, Perl and Python. What do all have in common? Relatively large and useful included libraries (CPAN might as well be thought of as included in Perl).
Another poster pointed out that you can also look at patterns as filling this hole in some ways. Which I agree with. Who can't get by in production code today without at least understanding a few patterns?
So I am not really seeing the issue as clearly as the article suggests. I am seeing just the opposite.
7. What we cannot speak about we must pass over in silence.
The guy nailed it.
For me, the decision of whether to reuse or reinvent depends on the level of expertise and/or interest I have in a particular area.
e.g. If a problem involves text parsing or indexing I will usually code from scratch to get an optimal solution. If I need general-purpose compression, I grab the zlib library without giving it a second thought. My projects tend to be a mix of reuse and reinvent.
Of course whether I'm doing a project for myself or for a client is also a factor.
when programmers are taught to a computer language, we're taught to write. When everybody else is taught any other kinda language, they're taught to read. If I learn Russian, I'll read great literature.
Trouble is twofold.
1) we con't have a corpus of great computer code we can show folks howto read.
2) reading code is most often associated with Maintenance and maintenance programmers aren't highly regarded.
call it NIH.
If you don't agree to the license, etc...
I don't have any problems at all with code re-use, I use CPAN extensively.
In fact I use more modules than most people I work with -- WAY more. The longer I code, the more modules I tend to use and the more I add to my repetoire. The code I wrote a few years ago goes from 100's of lines to 50, then 10 on a regular basis. Its not uncommon for me to bring 2000 line 1 year-old applications down to 100 to 200 lines of code.
Is my code slower than others I know who roll their own, or stay away from modules? No way. Not in the slightest. In fact my code is the fastest of anyone in my company by a long shot. I'm usually brought in to optimize another programmer's work, and almost always succeed in doing it with less effort and more modular code than they originally used.
My secret? I use my time more wisely. The one thing I have on the other programmers is that I value my time intensely.
I'm certainly not smarter or more talented. I'm just lazier.
The difference is I have the time to look for the big speed increases; the over-all redesigns that will net 20, 30 or even a 50% increase in speed across the board. I don't spend my time trying to get that extra 2% quicker response time until the end, when it usually isn't even necessary.
You probably know this already, and it's water under the bridge, but the Perl module GD::Graph does a nice job of this.
That is why the really successful GPL creations are relatively monolithic and generic: Linux, Apache & the like can be deployed as-is as a backdrop for what you're really trying to do. It's much harder to take someone else's utility class (*koffkoff* readline *koffkoff*) if it is GPL.
Note: the lots-of-little-programs approach of Linux does dovetail nicely with GPL tools, hence: host> cat | grep | awk | myprogram |
I develop in Delphi and I use a lot of stuff from the net (if you want to learn how to create reusable components, and use already made components, this is THE development environment, and there is even a free linnux version! and it is PAscal, not this joke of a language called C or C++).
I'm amazed this guy wasn't modded Flamebait 10 seconds after hitting Submit. WTF! Haha.
Delphi's pretty good, but it's dying. Too bad. I'll stick with open languages, so my products don't get shitcanned when Borland doesn't feel like fixing or supporting something.
You could apply many of the ideas in his article to the concept of code reuse. However, he is far from making the recommendation that we toss abstractions completely.
Do you care to rewrite IE/Mozilla so you don't have to deal with its internals? Do you care to rewrite your TCL/C#/MFC application in native API calls so you don't have to deal with its internals? If you do, then you're doing yourself a disservice. Rewriting those abstractions to avoid the internals means you'll be neck-deep in them.
It all goes downhill from first post
Lots of good thoughts expressed already. Here's my list of reasons we don't reduce, reuse, recycle code well:
/can't/ do it better than has already been done.
1. It goes against the unwritten rule of "elegance". Using someone else's code often means it just doesn't fit quite right into your program. We'd rather write our own solution that fits "perfectly" into our program than find and use someone else's solution that isn't quite perfect.
2. Trust. If I'm going to use someone else's code, can I trust that it is (relatively) bug-free? Can I trust that it does what it says it'll do? Without unseemly side effects?
3. It's more fun to write code than to search for code.
4. Hubris: I can do it better.
5. I know I can write my own solution. I don't know that I can find another solution, and that if I do it will work well enough for me (or won't require extensive modifications) and there won't be some other issue with it that will keep me from being able to use it. In short, I know I can develop a solution in n time... but if I spend time looking for and integrating another solution it's a crapshoot -- I might spend n/10 time or 10*n time.
Now let's look at some cases where reuse is working:
- Standard libraries. Popular languages come with a fairly large library of standard code. Reuse works here because (1) there's usually little/no choice and (2) being a standard library, there is a degree of trust given to it that is not granted other code.
- Popular add-on packages. Whether it's Log4J, a CPAN module, or a well-used bit of Javascript. Reuse works here because of trust: if lots of people are using it, it must be good.
- Really complicated things. Regex. Who wants to write regex code? Reuse works here because of the belief that you
- Really big things. Graphics libraries. Reuse works here because at some point a job becomes too large to tackle, compared to finding and using an existing solution -- even if the existing solution stinks.
In short, in order for code to be reused, it must be findable, usable, trustable, and valuable. The last meaning the time/effort spent in finding and learning existing code will be less than the time/effort spent coding a new solution.
That's 2c off the top of my head, I'm sure I can do better but it's late and I'm tired and I'm going to bed shortly.
-Thomas
Any one who's tried to re-use someone else's code will probably have to kludge their software to interface with someone else's. I've lost track of the number of times I tried to use CPAN modules only to throw them out because who ever wrote appeared to be a high school drop out with a serious logic deficiency.
However, that's Perl. C++, on the other hand, tends to be much cleaner, and doesn't suffer from Perl's version of Windoze DLL hell.
Wank wank wank.
Lets not overlook the importance of standard libraries. Now i cant speak for other languages but for C/C++. Those have a very well documented set of standard libraries.
In C yes not much there but still nobody would be crazy enough to rewrite something like fprintf
In C++ the picture gets even better. The C++ standard library is great piece of very good reusable interfaces. Here I present a simple case:
Lets take a somewhat simple algorithm like reverse, Essentialy the algorithm reverses all elements in a container using two iterators the begin and end. In terms of C we can thing of a pointer as being an iterator.
Now if you were a C guy you probably roll your own and probably produce something resonable enough that uses some pointer arithmatic etc.. You version will work fine.
Now lets consider what you get in C++
A mindless C++ programer just writes and does not give much more thought.
reverse(v.begin(), v.end());
Nevermind who has demonstarted more virtuoso pointer arithmatic skills. Who has actualy produced the better code? Surprisingly enough it is the C++ programer. Here is the reason why.
The C++ STL library has something called iterator traits which let the writers of the library write three different versions of the reverse algorithm depending on the type of the iterators used. The selection of which implementation is actualy used gets decided at compile time. Because say an array was used and random access was possible this opened up this algorithm for all kinds of possible optimizations.
Depending on how good the writers of the library were they may have went to great length to optimize this algorithm which in reality they realy did. You can look at the implementation included with gcc yourself. Surprisingly enough the actualy implementation uses loop unrolling to achive the needed efficiency which the user of the code probably had no clue about.
I think everybody wins here. The user of the library who had very simple interface and ease of use in addition to a very efficient code that required limited effort.
> and it is PAscal, not this joke of a language called C or C++).
Real Programmers Don't Use Pascal
Wait a minute. Didn't I say that on the other side of the record? I'd better check
I love reusable code. Thanks to CPAN I can mockup incredibly functional scripts without ever needing to know the details of a protocol. I love linking against libssl or libpng and not needing to know or care what TLS is or what RLE means. It's great.
But when I write code for a living it's never that easy. The problem is that most libraries cost money (in the areas I work in) and, even worse, they cost a LOT of money. If you use libraries to do the bulk of your work then you can find a product costing upwards of $500 just in licensing fees; that's before you add your own costs and profits on top. It's no wonder that so many people reinvent the wheel; it's because you can't just buy the wheel, you have to pay licensing fees everytime you use it. It's just not economical to reuse code in the "real world".
That is, unless you write open source. This is where reusable code really is working. I can ldd any binary on my system and find incredible levels of code reuse. Evolution (the mail client) links against 50+ libraries. That's great!
I think attempts in the past to encourage code reuse fell flat because they focussed on the technical problems and not the legal or economic problems. Open source changes all of that. So there's hope yet for reusable code.
Of course there is no perfect solution, but a really good repository would help developers reuse free software.
;). If you want to help join the dev list.
If I could go to a single place and search a large database of open software components easily, I would be more inclined to reuse fee software. Sourceforge or the Gnu free software directory do not do this well. I need much more than just a name and short description and I don't have time to spend weeks trying different halfway completed projects every time I want to reuse something.
I would like to see something that is actually useful. For example, the repository should include design and implementation information for each component, as well as complete test results and profiling results. And I should be able to search based on all that and more. Basically, it should make the search as painless and accurate as possible. It should also be managed so that the only correct information is allowed.
I am working on a project called Hoot that aims at centralizing and standardizing open software process and engineering. A repository like this is one of the goals. Not much has been accomplished yet, mostly due to poor leadership
The legacy of this was when the IBM-PC was first released, there was still a BASIC compiler that was distributed with MS-DOS 1.0 (or PC-DOS as it was also called). The thought that you would EVER sell a computer without a compiler or interpreter was completely unheard of. Source code was provides for at least some software (even if it wasn't the entire OS).
Contrast that to now where if you go to WalMart (or your favorite discount general merchandise store) for a $500 PC, you can get all kinds of software, more games than you can shake a stick at (several isles). I dare you to find a compiler being sold in one of these stores (with the notable exception of GCC, being sold with Linux distros). Specialty computer stores are much more likely to have compilers for sale, but even these are dusty back shelf items. You'ld be lucky to find a current version. University bookstores are a little more likely to find one for sale, especially if the school has a strong CS program.
I guess what I'm saying is that with commercial software distributions doing binary only releases, it is almost impossible to get source code to even read.
Some of the best algorithms I found on my own reading other people's software and picked up some really good programming habits that I still have today. Some of the best gems I saw were in assembly (which is a dying art today unfortunately).
Current experience with working with source code would be some intern that is given 100,000 lines of code to debug because some programmer left a really buggy bunch of software that still doesn't do what the customer wanted. The original developer left (died, was fired, found greener pastures) and now you (as this fresh intern) have to figure out what is wrong and try to fix the bugs.
Unfortunately this is the worst possible experience for a young programmer to have to deal with because:
If the software were clean and well-documented, it would be easy to fix and the intern would never see it.
Unfortunately, this way the intern learns how to write ugly code (because that is all they have been exposed to) and they are striken with perpetuating this same problem.
Fortunately, with the open source movement this is something that can be fixed for the industry in general. There is now a huge body of software that certainly can be used in educational settings, and it would be wise for a compiler class to dissect the internals of a GPL'd compiler, for example. This is the corpus of software needed to do this job right.
I'd also say that 90% to 99% of all software development is maintaining an existing software base. You may be allowed a "fresh clean sheet" to reimplement existing software in a new platform on rare occasions, but mostly it is tweaking existing software, usually to add a new feature or finish a promised feature that was stubbed in earlier.
Commonly overlooked in this kind of c/c++/perl focused discussion, but delphi's component model has been in operation ever since Delphi 1 back in the 90's, and has produced a most successful mix of freeware, shareware and commercial components easily and simply plugged into the development environment. Torry.net gives a good flavour (http://www.torry.net/). Also the Project Jedi code (http://www.delphi-jedi.org/) is now an effective extension to Delphi itself.
Comment removed based on user account deletion
I had a program that needed to zip and unzip files. I could have gone away and researched the ZIP format, or I could simply use a ZIP object that was available. 5 minutes after downloading it, I was happily setting two properties of the object and calling the "unzip" method, and it just worked.
I hate to think how much work it would have taken to rewrite that from scratch.
The same thing happened with an image display addition to a property program I worked on. I could have written code to display 30-odd file-types, but there happened to be an object that did it already, worked perfectly and took less than an hour to get working.
Why would I spend all that time working on something I didn't have to?
My Journal
Mark Fisher reminds me of someone I worked with. He is brilliant with computers, and before I saw him code, I believed that he was supernatural. Then he told me his theory on programming (which someone coined as 'Mayer's first law...'
"Steal what you can, write what only you have to..."
In case RIAA is spying on me, what he meant by 'steal' was to check all available PD/GNU/Published Code sources. If something was close enough, use it. He put together some amazing projects in a very short amount of time that way.
-- There are 10 kinds of people in the world, those who understand binary and those who don't.
I find that a lot of the people I've interviewed, people I work with, and people that read my articles on codeproject are just too damn lazy to read the documentation. Researching is what being a developer is about. Anyone can write code! Problem solving requires a certain amount of research or knowing whats available so you don't have to reinvent the wheel.
Granted, as some people have pointed out, canned solutions don't always fit or changing cryptic code - see, now that you know what the other end feels like, COMMENT YOUR SOURCE - isn't the best solution. That's understandable.
But a lot of it are these get-lots-of-money-quick-by-getting-a-career-in-com puters tech-school grads, formerly McDonald's employees. They're taught a trade, not a skill. A few might have it in them and truly be interesed enough to research more, but not many. Even university students - who are generally taught to learn or a problem-solving mindset - sometimes don't realize that class will not teach you the practical stuff you need to know - you have to do that on your own time. Heck, a few of my old professors hardly knew what they were talking about because they haven't been out in the real world since they graduated with Ph.D.s!
Software applications today are more complex than ever. They can only continue to become more complex if there is significant code reuse. In fact, there is more code reuse today than ever before. The code that is reused is not necessary at the level of libraries, but at a much larger scale. The best examples of code reuse:
I'm reminded of something I heard a few years ago on this subject: "Good programmers write good code, great programmers steal it."
The point the person was trying to make was that good programmers will sit at their computer for a week reinventing wheel, while a great programmer will spend a couple hours finding where someone has already invented the wheel and then adapting that wheel to their project.
In my experience as a professional programmer, it has always been faster to find someone else's code that does what I want and to adapt that code to my project. I've very rarely ever felt the urge to reinvent the wheel. It cuts into my productivity and is a waste of time if I can find something that already works for me.
It usually takes much less time to write a couple wrapper functions or an adaptor object interface to integrate a 3rd party library into your code than it does to duplicate the functionality of that library.
Too many programmers and too many shops suffer from "not invented here" syndrome, i.e. they refuse to use code that they didn't write.
Just be sure to wear the gold uniform when you beam down -- you know what happens when you wear the red one.
Perhaps because you cannot learn how to make new wheels until you've made a few old ones?
-----------------------
You are what you think.
I've been writing code professionally for years and now I lead others in system integration and software development.
I see new folks coming in and wasting so much time rolling their own stuff, it just kills me. The cool thing is not to build what others have already built. The cool thing is to make progress, build on what others have built, and provide users with something they can use.
Guess what guys, users don't care if your linked list code is better than anyone else's. Users want things to work. If you can spend more time concentrating on that, and less time finding and fixing the same bugs another guy dealt with two years ago, you will be doing more for users.
Guess what else. Nothing we do is perfect. That spiffy library you get from the net to solve a problem will have bugs. If you write your own, you'll have a different set of bugs.
I think too many new developers have not developed sufficient troubleshooting skills when they were learning their trade. They only know how to fix stuff they wrote because they can't get their heads around how someone else does things. I value the hardware and embedded systems work I've done because it taught me troubleshooting skills I use every day.
I can truss or trace someone elses executable binary and give the vendors / developers clues on how to fix their code without ever seeing the source code. How? Because I've developed an intuitive approach to problem solving based on the simple notion that programmers are lazy and they tend to solve similar problems in the same way. Patters are useful whether they are formal or intuitive and they are useful when developing and debugging.
When my engineers want to use a new technology in our development, I grill them very hard to determine whether they are choosing the technology just 'cause its cool and they want to learn something, or because it will actually bring some value to the product being developed. I'm all for my engineers learning new things, but I don't want them to write a lot of bad code while they figure it out. If they want to use a new technology, I prefer they re-use libs or code that an experience developer in that technology has already built. I think people should try to learn from others examples, and then innovate after achieving basic competency.
Once upon a time, single cell life ruled. " How do I know that you do the function you say you do? How do I know that you will deliver the nutrients that I need? That you will deliver them on time? I don't, so it is better to do it all myself."
Forunately for us, they figured it out....
I think that part of the reason for that is that Pascal is the RISC of languages -- it was developed as a "teaching language", but it seems that it was also developed to make writing compilers for it very easy -- the declarations have to be in front so the thing lends itself to a one-pass parser. There must be also some good engineering in the Borland implementation that makes it fast even for Pascals.
Apart from operator overloading and the STL, C++ and Delphi are pretty much equivalent and mappable one into the other -- witness C++ Builder doing pretty much the same thing as Delphi, only compiling slower. I write to the Windows API using my own Delphi classes without using VCL or MFC (produces very lean programs), and I do pretty much the exact thing in C++.
I do have to admit that Pascal syntax has lost out to C syntax (witness C#, Java and to a degree, Perl). Pascal syntax was obsolete even in its day (the clunky requirements on begin-end blocks with if statements that were reformed in Modula and Ada). But Delphi, which had modules, classes, a reference-counted long-length string type, function overloading, and reference-counted interfaces with support for UIID's grafted on to it, soldiers on while Modula and Ada (meant to be extensions to Pascal done "the right way") have become largely historical footnotes.
It does not have remember the sequence of charging and discharging of your alternator and then turn off the trunk light when the battery is low. Oil can be mixed with other oil -- I can throw in a can of Shell oil with a crankcase full of Quaker state without doing serious engine damage.
I complained to him about OO, specifically about the clunkiness of massive GUI frameworks such as VCL and MFC. Since then I have been on a little friendlier terms with VCL, but it is still a massive wad that bloats programs, but hey, memory is cheap. He sympathized with my take on reuse issues of general-purpose massive application frameworks, but argued that for in-house projects at IBM, the reuse can be strong.
A programmer can develop good reuse of their own stuff in their own projects, a small group can do some reuse depending on how well they document and communicate, and working the way up the chain the reuse may be more limited.
Clement Szyperski has a good discussion in Component Software on the dream of widespread reuse and some of the obstacles to achieving it. Following his discussion, the best success of top-level (commercial, between organizations) reuse is at the operating system level (who anymore tries to roll their own window manager as in the days when we tried to write GUI programs in DOS). The next level is in terms of language features, libraries, and stuff like the STL. The level after that is third party components, of which he mentions that Visual Basic has developed a market but few other systems have succeeded at the level of widespread sale of software components.
So we are making some progress towards software reuse, using OO and other techniques, but the progress is slow in coming because people are still figuring out what works, but we are getting there.
An ActiveX component is pretty much an ActiveX component (and yes, I have used Delphi to produce and consume them). Say what you will about Microsoft, but they try not to break their own stuff, and you can develop an ActiveX under Windows 95 and use it under Windows XP.
A VCL component in many ways is better than an ActiveX -- it is a class, not a walled-off COM component, so you can extend it with inheritance. In addition, you can link it up to other components by setting property values to point to other VCL components in the Object Inspector (you can link up ActiveX components, but you have to do it programmatically at run time). This linking up of components is not perhaps as widely used as it could, in part because you have to override the virtual Notification method to handle the connection and disconnection of components without crashing your component in the Designer, but the capability is there and is very useful.
Where VCL components become a PITA is that they are specific to Delphi version. You either tell people that your components only work with Delphi 7 and when Delphi 8 comes out they have to upgrade your component, or you have to have a collection of old Delphi's to come up with versions of your components for, say, Delphi's 3-7.
Also, ActiveX components have a simple deployment process -- one or more .OCX files and invoke regsvr32 if you want to install them by hand. I write my Delphi stuff using a separate .pas file for each class when this is practical, so any VCL component I generate has a wad of .DCU files that need to be distributed. There is probably a way to wad the .DCU files together that you can tell me about, but you know what I am talking about.
Anders Hejlsberg and Microsoft teamed up to try to get this right with .NET assemblies. An assembly is a .DLL file like and OCX, you can wad up an entire class framework in a single assembly, and you have the option of installing an assembly globaly or only using it privately one application at a time. Oh, and you can extend classes from inside an assembly by proper OO inheritance, and .NET components can be hooked up to other .NET components by setting properties to component references in the Designer just like with the VCL.
Trouble is .NET is kind of slow in being pushed out to end users -- even if you buy a computer with XP installed, you have to install the .NET runtime separately. While the transition to Windows 95 API was a "big bang" in that Microsoft really pushed the upgrade to consumers and for developers to target the Win32 API, the transition to .NET is being pursued rather cautiously, and Microsoft doesn't seem to be pushing .NET as a platform for shrink-wrapped software at least quite yet.
Some days I don't play well with others is because I don't want to get burned by the other developers. My example is we used WebObjects to develop a couple products. The developers were generally split into two groups and we generaly chunked things out into WebObject frameworks. My product had need to talk to a database that the other group had developed a framework for and I pluged it into my product. A couple months later my product won't compile any more and is complaining about a class I've never heard of. Tracked it down to the framework I got from the other group. They needed some new functionality and did a code refactor, which I would have been fine with, but the database model now made use of a class in another framework. I didn't have need of the new framework and did not want to incur another dependicy and whatever dependices it had. So I ended up copy what I needed and forking the code cuase there was no way I could convince a developer in the other group that classes needed to be moved. It also seemded like everytime we thought there was overlap, the code was useless because of the dependencies that added no benifit to my product.
Brought to you by Team SPAM! where we believe: "Information in the noise!"
sooner or later a programmer gets good enough to stop shooting himself in the foot.
Either that or they eventually die from bloodloss or infection
- We are the slashdot. Resistance is futile. Prepare to be moderated -
I think code reuse is great but just like anything, it should not be used everywhere without understanding the long term side-effects. Where I work, we maintain and enhance 12-15 year old code. Barring a few areas that had to be totally revamped (due to trillions of bugs per line) almost all of the existing code architecture/structure has been maintained since the first time the software became "stable" - approx. 11-12 years ago.
This has led to many issues that one would not expect to see in today's software development environment:
Much of the legacy code incorporated functionality that came along later (eg mutexes and semaphore locking/unlocking) but the original design was so intrusive to the rest of the code that now its impossible to work without pacifying code that doesn't do much than burn CPU cycles.
The original designers worked with one set of rigid OO concepts (e.g., "all multiple-inheritance is evil so it must be eliminated and code added to make it impossible forever") - this makes it inordinately hard to coax code into the legacy design - most often the "I'll take the OO idea" wins over "this code would work with some work" simply because by the time all the mods are factored in, it is better to just re-write the stuff to accomodate the legacy base.
There are some problems that are just best suited to custom solutions. In my experience, for work that has strict performance constraints, the custom solution often works the best - IMHO, researching existing algorithms is fine, using them as "the" solution is not. That is not to say that research should be totally ignored - often a good extension can be developed from reading someone else's experience, eventually one can create something new by oneself. But that process does not happen if one simply accepts the existing models/code as the be all end all.
I've seen a lot of cases where someone reinvented the wheel, but instead of using an axle, they just put the wheel under the object so you have to move the wheel to the front to keep going, and then to top it off, they made the wheel square or triangular.
I did that once. In 1969 I needed a sort, so I looked in the fortran programming book I had and implemented a bubble sort, to sort records on disks. When it became clear that the sort would take a couple of months to complete, I started working on optimizations. As I was working for a college, one of the profs suggested that I take a look at the collected algorithms of the ACM. There I learned about quick sort and heap sort. I was able to incorporate those, but I had to deal with the fact that I had a lot of data on disk that I couldn't bring into memory. Eventually I got a sort working that wasn't too bad for the times and the computer resources.
Then Knuth published Vol 3 which I studied with my experience in mind. I was amazed to see Knuth develop and analyze my progession of improvements and cite the authors and dates, all of which preceded my efforts by at least 5 years. I also noted that Knuth's statement that the common use of the bubble sort in programming texts was a great crime.
Roll forward a five years and I join a group where a new backup utility has been released which sorts the blocks to be backed up, but there was some sort of stack overflow problem. But I was the new guy who wanted nothing to do with tapes and besides, the two engineers working on it were comp sci graduates and I was a college drop out.
Roll forward another five years and a coworker had been stuck with this code which was still running into some sort of strange stack overflow problem. He's the polite, persistent nagger type, so I reluctantly agree to take a look at the code. In 15 minutes I realize that the code is quick sort, which then means that there is a serious bug in the code because its overflowing a 200 element stack (and if you don't know wny I knew there was a serious bug instantaniously, you MUST NEVER CODE ANY SORT). In the next 15 minutes I found 3 coding errors in the code, 1 was from the original fortran code, and 2 were from editing the fortran assembly to inline it into the module.
If I have a problem that calls for a sort, I can reuse Knuth's research into sort algorithms, which reuses the work of others to create significant advance in the subject, I can reuse the algorithm coding by transliterating the MIXAL, I can find code in various languages from all sorts of sources (which I evaluate by reusing Knuth's methodology), I can call a binary library routine that I may or may not be able to see source code for, but whose bahavior I can check with rules of thumb reused from Knuth, and I can research new algorithms and possibly reuse after reusing Knuth's analysis to verify the claimed advantages.
In my view, reuse is the obvious method to apply to any development process.
As a mechanical designer, I would be foolish to fail to use standard nuts and bolts, and where that's not reasonable, foolish for failing to use standard conventions and standards for screw threads. A mechanical engineer works with dozens of references and hundreds of catalogs.
For a programmer to fail to access reference materials and catalogs looking for existing components and art (craft) to reuse is idiotic.
The problem is that there are few good references to draw on.
The only reasonably comprehensive compendium of computer software algorithms I know of is in the 6-10 books that Knuth has published.
I've opened a number of books where the title suggests a comprehensive listing of software algorithms or C++ objects, and been greatly disappointed at the lack of depth. These books are like going into the drug store or Sears to find the right nuts and bolts for a project. I was hoping for something closer to Home Depot which only scratches the surface of reusuable fastener technology.
Softwa
I see a lot of posts pointing out the infexibility of software objects/components and the need for custom "wheels." I think the former can largely be blamed on the direction modern, statically-compiled programming languages took in their use of data hiding and mandatory encapsulation as "abstractions." Kiczales' Open Implementation group at PARC showed that this actually inhibits code reuse by preventing the customization of "the wheel." Open Implementation is supported by reflection and some aspects of the Meta-Object Protocol (although in most cases this is total overkill), and this is the central idea behind Kiczales' current work in Aspect-Oriented Programming. But in practice, I find relatively simple things, like function advising (and more recently Costanza's dynamically scoped functions), and CLOS's before, after, and around methods are enough to take care of almost all customization problems that arise. Sometimes, breaking data hiding rules can also be useful.
In the great CONS chain of life, you can either be the CAR or be in the CDR.
It is all a matter of what a person was trained on: I can whip out Pascal code a lot faster than C++ (all that keypunch practice means I can type out begin and end faster than you can select Shift and hunt for curly braces). Delphi Object Pascal is so extended from ANSI Pascal (string handling, C-style pointer/array syntax) that it is for the most part line-by-line mappable between C++ and back. And if you complain that Delphi lacks your favorite C++ features (templates, stack-allocated object instances, STL), lets just say C# is pretty much Delphi-with-C-syntax when you really look at it carefully, and C# has never evoked the opinion that it was particularly difficult to program in by C/C++ programmers.
This business about how nightly builds are the only proper coding model and that anyone cycling through compile-link-run is hacking -- while I guess all the advocates of interactive/interpreted languages ranging from Lisp to BASIC to Perl to Python are all hackers. The Delphi compiler is that fast that it has many of the advantages of the interactive/interpreted languages while having compiled-language execution speed. There were people who once thought that time-sharing was bunk because if someone was too sloppy to use keypunch and batch runs, they were probably writing hacked up code.
As to putting the brakes on language features to trade off for speed being stupid, it is only slow for you because you are used to prefix instead of postfix type declarations and don't have begin and end under your fingers. The opposite extreme of giving language features free reign and compiler considerations be damned is called Ada . . .
So then, better than C/C++ for just about any general application apart from specific-purpose high-performance and non-interactive apps...?
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net