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
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.
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.
And that leaves you with an application having an efficiency similar to that of a big SUV. OK, so I do it too, but that's no excuse. ;)
-Looking for a job as a materials chemist or multivariat
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.
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...
Apache Jakarta has some really great libraries for Java. I use them extensively. That allows me to worry about high-level issues as opposed to being bogged down with the details of XML-parsing and validation, translation, etc. Additionally, Jakarta Commons has a number of useful tools that I would find myself re-implementing if they weren't already available, like the HttpClient. I've been really impressed with the stuff they've produced. However, it certainly adds to the bloat. Also from what I've used of it, Struts is awesome.
This post was generated by a Cadre of Uber Monkeys for Monkey-Man2000 (603495).
Not to mention how much CPU time each of those takes. For example, check out the "tinyurl.pl" example in CPAN. It uses:
.6 user CPU seconds alone - an approximation of how much CPU time it takes to start up (and by my measurement, a pretty accurate approximation).
use POE;
use POE::Component::IRC;
use LWP::UserAgent;
use HTTP::Response;
use HTTP::Request::Common;
use URI::Find;
Each of which probably use a good number of libraries themselves. Running perl -wc on the script takes
Hell, check this out:
$ time perl -e "use POE"
0.23s real 0.21s user 0.01s system
Sick.
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.
#!/usr/bin/env pythong .setPixmap(QPixmap("my_image.png"))g et(img)
import sys
from qt import *
a=QApplication(sys.argv)
img=QLabel(None)
im
a.setMainWid
img.show()
a.exec_loop()
9 lines.
You're welcome.
It would probably have been even shorter in Perl.
'Bloat' is not knowing the right tools for the task.
-- B.
This sig does in fact not have the property it claims not to have.
Do I _REALLY_ want to pull in libpng and libSDL just to do this?
You're going to write your own code to read PNG files?!? Just how much time do you have to write code and fix bugs?
How much will this bloat my code?
You think that rewriting the code will take less space then interfacing to an existing library?
Will users be confused from the different versions of these libraries?
Much less then the users will be confused when they run into a file that you can't read and all their other programs can. All code has bugs, but libpng has a lot of testing and is actively being improved, unlike your code. And standards change, and the libpng people have more time to chase any changes to the standard then you do.
What if I one day want to port to a platform that these libraries [don't] work on?
libpng should work on any platform with an ANSI C compiler, and has been tested on far more systems then you can. Your code to display it on the screen is going to be system dependent; at least third party code has a chance of working on multiple systems out of the box. And if you have to port it to a system that it doesn't support, it's just as easy to port it to that system or add your code to support that system as an alternative to the graphic library, as it is to write it from scratch. And you saved yourself the trouble of writing the code for Linux and Windows and anything else that worked out of the box, as well as working on systems you would never have got to.
Turns out it's usually simpler, easier, and less risky to just roll your own.
It's going to be more buggy (and have different bugs from the standard), and require you to write a lot of code, especially every time you port to a new system. I see minimal advantages to a user, especially with a library as ubiquitous as libpng.
Yes, wrappers or layers are just a type of abstraction/encapsulation... and you always have to be careful when creating new abstractions. (See "Leaky abstractions" etc.)
What I was saying about wrappers for wrappers was meant to be just sort of a joke... pointing out the fact that if you are making a wrapper around some standard tool to tailer it for your own use, you have no idea what that tool is in fact a wrapper around, itself. Just the irony of building a black box around a black box creating a new black box... and while thinking about that you have to wonder about what's inside the box inside of yours (was that inoherent? probably). China dolls? Who knows. Anyway... now I'm just rambling.
The point of talking about layers is simply to address the concern raised further up the thread that people can't reuse code because it is either too general, or too specific (for something else). Wrappers are a good way to make a general tool into a tool that is specific for your purposes... and it is often easy to create a simple but robust wrapper that just makes a general tool more useful. Some simple (possibly over simple) analogies are shell scripts ad aliases. Think about what you are doing with these... you're just taking powerful tools and tailering them to the particular use-cases that you want them for.
Or here is (probably) a much better example: XML parsers. A truly compliant XML parser is an incredible pain in the ass to a typical application developer, because it leaves far too much work for the developer. How often does a developer simply want to use an XML parser/generator simply for serialization/deserialization of complex data objects? (I know that I do this all the damn time.) What you need is not a powerful, compliant XML parser, but a nice little wrapper around one that does everything you need and nothing you don't. Of course, different projects may have different notions of what is necessary and what isn't... hence you end up making your own wrapper around a very general tool... then you end up using that wrapper all over your code.
:Wq
Not an editor command: Wq
Win32 string handling is a confusing mess.
Maybe you should learn the use the STL first. One of the first things they teach you when learning the STL is that auto_ptr cannot be put in containers (try boost::shared_ptr for that). Its one of the most well documented libraries I've ever used. Try the SGI STL site, as well as Dinkumware's STL reference. Anyway, Google is your friend. A search for auto_ptr nets this article, on using auto_ptr effectively, as the first hit. It has an entire section titled "Things Not To Do, and Why Not To Do Them".
A deep unwavering belief is a sure sign you're missing something...
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.