tags:

views:

180

answers:

12

I have been programming "a lot" in the past few months and at first I was trying to find the "easyest" language. Fortunately I realized that it's not about the language, it's about learning HOW to code. I ran into the Stanford lectures online (programming methodology) and I watched them all (around 23 hours total) awhile ago. Then I got into Java ME and programmed about 28.47% of a mobile RPG game (only around 2k lines of code). I feel like I learned a lot from those two experiences compared to previous ones but now that I'm moving into flash/actionscript 3.0 development and I'm finding myself learning like I did when I first started with PHP. I'm not really getting whats under the hood kind of. I'm finding myself using libraries to speed up development time which doesn't seem like a bad thing BUT I personally do not know how to write the libraries myself off hand.

So should I be coding everything myself or is it ok to use libraries when you don't even know how to code them?

+3  A: 

Would you drive a car if you didn't know how to build one?

If you continue programming, you will be using libraries written by other people the whole time. And there's nothing wrong with doing that.

In fact, I'd say that using libraries where you know nothing of the internals helps you gain an intuition into how you should write your own libraries and how much functionality to expose in code that you write.

Mark Rushakoff
+1  A: 

Standing on the shoulders of giants isn't a bad thing. If you value your productivity (and your future employers certainly will) then learn a valuable skill by nurturing your ability to explore the capabilities of libraries, learn their idioms and get maximum return on your time.
Every bit of (quality, tested) library code that you successfully integrate into your solution is more time you can spend on really nailing the specific problem at hand and providing value to your end users.

Hamish Smith
+7  A: 

Yes.

If you are learning how to program, you should be using libraries, because using libraries is what programmers do.

If you want to learn the inner workings of the libraries, then try writing your own libraries. But this should be done only if you are a strange person and you are interested in that sort of thing, otherwise using existing libraries is a good habit to get into.

thomasrutter
A: 

In general you don't want to reinvent the wheel. It is useful to understand on a high level how a library works so you understand why the library works the way it works. Use the library to learn how you might code the library.

Brian
A: 

Libraries cover the core programming issues that come up again and again, and that someone has already solved for you. So yes, use the libraries as the foundation for the rest of your code.

There's still plenty to learn without taking the time to rewrite the core functionality of the language you're working with.

Neil
+2  A: 

Yes, you should.

Quite often the libraries you are using were developed over quite a long time and using a lot of brain power to give you the kind of performance and functionality they provide and writing your own can basically kill your project because it heavily increases development time.

If you're feeling "bad" about using stuff you don't understand because of the learning factor, you could start by reading the documentation and probably the source code of the library to get a good picture of it. It won't be necessary but it will enhance your understanding of the library and you can most likely get something useful by reading code from another, possibly more experienced, programmer.

Marc Müller
+2  A: 

Libraries and frameworks are force multipliers, enabling you to work much, much faster and more effectively than if you were to do everything on your own. You'll probably get a better feel for how they are implemented the more you use them, and you can always study their source code (and contribute to their development) to learn more.

Jim Ferrans
+1  A: 

There's nothing wrong with using libraries, but at the same time if you really want to go be a good programmer you should be able to program those libraries yourself even if you don't. So it might be a good idea to try writing with a library to see if you can figure out how it works and so on.

And of course, you're always going to be using some library, like the PHP standard library and the standard actionscript/Java ME. Writing without a library means writing ultra-low level code in assembler - in theory you would have you write your own OS because even doing stuff like screen IO, file IO and graphics requires at least using low-level API calls to the underlying OS.

Chad Okere
A: 

It depends

The best solution is a balance.

Some libraries abstract far too much for you to learn anything from them such as GUI toolkits.

Minimalists will argue for you to start with C which is too low level in my opinion, and you will spend too much time worrying about low level details.

Likewise, if you spend time trying to learn Swing, it will not teach you much about programming in general except how to make Java GUIs.

For a beginner, I suggest sticking to libraries that do very low level things such as math and file operations while making programs.

Unknown
A: 

If you re-write a library you might end up 'reinveinting the wheel'.

Here is a good article about that http://www.codinghorror.com/blog/archives/001145.html.

df
+1  A: 

If it's a core business function -- do it yourself, no matter what.

ref: Joel Spolsky - In Defense of Not-Invented-Here Syndrome


Many answers here are good, but there's another aspect to consider with Libraries: Built-in vs 3rd Party

Built-in:
By all means, use the built-in libraries until you come to a point they are not adding value. Then, add your own library (i.e. reusable code) that sits on top of them. The less code you write, the less code you maintain.

If using a good library, you'll end up learning anyways. Only consider writing your own library when you've hit the wall of usefulness of the built-in libraries and you find yourself writing more awkward code to get around those deficiencies.

Also, by using a built-in library, you're more likely to have code that's understood by your fellow developers. (They'll otherwise wonder why you needed to re-implement string splitting, sorting, searching, etc)

3rd party:
The bar to using a 3rd party library should be much higher. Ideally you want to minimize the number of external dependencies in a project. Also, 3rd party libraries vary greatly in quality that's not immediately apparent, and you need to invest time to evaluate them. They usually have an added purchase cost (sometimes per-developer), deployment costs (i.e. per server), and cost more in terms of increased regression testing you must perform when they come out with a new version, or fix a bug, or just change things around. A built-in library has a large percentage of this regression testing done for you and breaking changes are less common with built-in libraries.

Anecdotally, after evaluation, I've found that many 3rd party libraries don't appear to do much more than I can do myself, and they're useless unless their design focus matches my needs 100%. Sometimes all they do is lock you into their proprietary ways, especially if you only need the 1 or 2 bits of functionality.

When using a 3rd party library, it's often a good approach to utilize an adapter pattern if possible to reduce the amount of coupling from 3rd party code to your own code.


On the one hand, Not-Invented-Here syndrome causes many bugs to be introduced (arrogant programmers figure they can do it better, only to realize later they've essentially reproduced the same that the library offers, but with fewer features, more bugs, and this isn't even taking into account the development cost of unnecessary code).

On the other hand, using libraries can speed your delivery and time to market.

The trick is to recognize what your core competencies are and choose accordingly.

Don't forget to check the web for how well a particular library performs or what other people think. e.g. jQuery (3rd party, javascript, free) and Linq (built-in, .net) are libraries that are invaluable when one looks at the huge productivity gains made when utilizing them.

Robert Paulson
I enjoyed that one of Joel's articles very much, but disagree with the line you quoted at the beginning of your comment. If it is a core business function, then make sure it's done right, and if there is nothing already in existence that does it right, do it yourself. I think Joel's point is that if it is a core business function, it makes less sense to settle for something that almost-but-doesn't-quite satisfy your needs.
thomasrutter
It's defining what your core business function is that is the tricky part. What you don't want is to rely on another company for what makes you money because that introduces risk to your bottom line.
Robert Paulson
A: 

Use enough libraries and you'll find times when it just won't do what you need. Or when the documentation is out-of-date or missing and you need to dig in to the source to figure things out. You'll also learn by experience what good design looks like. These are all great learning experiences. In "the real world" people look for libraries first to avoid reinventing the wheel. Using libraries extensively can also keep you motivated because you get cool things done quickly. And having fun over the long haul, learning a little at a time, is what's going to make you successful.

But many times, there isn't a library that does what you need. Or doesn't work with other libraries you need. Or isn't fast enough, or has security holes, or isn't thread safe, or doesn't support Unicode ;-) Sometimes you job is to write the library - I worked on a commercial database engine for 9 years. It's fun when your product exists to factor out tricky code, data structures and algorithms to make life easier for other programmers, so working on libraries can be very rewarding. For one thing, the bug reports tend to be just what you need to reproduce the problem on your computer.

Sometimes you'll be using libraries, sometimes you'll be writing them. Either way, keep working on problems that matter to you. And keep finishing small manageable pieces of work so you can sit back and enjoy what you've done.

Harold L