I've noticed many questions on here from new programmers that can be solved using libraries. When a library is suggested, often times they respond "I don't want to use X library" Is it the learning curve? or ? Just curious!

+11  A: 

It's the learning curve.

+18  A: 

Almost always it's because their professor has told them that they can't.

Sometimes it's just because they want to learn it themselves, but I'd say that's rare.

Noon Silk
+1, no it isnt rare, but you are right(teachers are good example)
great point, plus if you use library ur teacher should learn it also to understand ur code. teachers are not into learning new things, because they already know everything.
+7  A: 

I always have this urge to do it myself, but sometimes I can see my own limitations. Just recently downloaded a library to create PDF documents, but thats pretty much the only time I can remember.

At least for me, (trying to) do things myself, is my way of learning.

My impression is that many newbie programmers wouldn't consider it their own work if they were to use someone elses libraries.

if you are using a compiler you are using someone else's work, does that mean we should all write in machine code only?
fuzzy lollipop
+5  A: 

I don't think that this is necessarily a bad thing. Using libraries is great; it saves time, effort, bugs, etc. However, you learn very little in the process, and for new programmers, learning is the goal. To answer the question, I think that they tend to shy way from libraries simply because they are not used to using them and perhaps they don't know that they exist.

Ed Swangren
You learn to use libraries, which is a valuable thing in itself. Nor is the problem that people don't know about libraries, but that they refuse to use them.
David Thornley
Learning libraries is not all that useful for a beginner.
Ed Swangren
+1  A: 

I think the professors want them to stick to the basics. When I graduated from under-grad school, I knew C++, Java and some other languages but had no clue about libraries and frameworks being used in companies. It was like do you know java..yes..can you write a

+28  A: 

When you're still learning the ins and outs of a new language, also having to learn how to use a 3rd party library can look like too much work. Also, libraries tend to be badly documented - or at least have documentation that seems totally opaque to a new(er) programmer.

So, faced with trying to solve problem X, saying "use a library" can sound a lot like "solve problem Y THEN problem x".

(Also, their professors told them not to. I managed to get all the way though my undergrad in C++ without learning the STL existed. Boy, did THAT cook my noodle.)

I shudder at the thought of teaching C++ without assorted STL features. Without things like vector<> and auto_ptr<>, C++ is no safer to work with than C.
David Thornley
LESS safe, I'd say, since it made so much less sense. Discovering the STL was mind-blowing. I've never been so happy to throw away hundreds of lines of custom code in my life. ("I didn't have to write my own hashtable? EXCELLENT! etc.")
"libraries tend to be badly documented" - This is my main reason. At least in open source areas, libraries tend to be written in C with cryptic variable names and little-to-no documentation.
Brendan Long
What's worse, soemtimes the professors discourage such library usage just because of some issues it had 20 years ago. For instance saying "You should not use the STL or virtual functions in real code because they are too slow"
+2  A: 

Because part of maturing as a developer is learning to quickly identify problems which can be solved by a library or existing solution and which need personal attention.

Rex M
+7  A: 

For many poorly documented libraries that are either implemented loosely or in languages that don't allow you to control containment and visibility very well, it can be quite difficult to guess just how the library is supposed to be used.

After you've used it for a while, you've gotten used to the quirks or read other source code that taught you the right way; but until then it can be pretty irritating to use a poorly put-together/designed library. (or even a well designed one that isn't terribly well documented).

If you don't have the source code to the library, that's another problem--you have no control over the ability to keep your program working. This is much more rare these days, but still happens in the case of a purchased library.

Bill K
A cursory glance at (some) of the Boost library documentation illustrates your first paragraph well.
+4  A: 

I think there's a lot of time that needs to be invested in understanding the library's purpose - yes, a learning curve, but it's more that newbie programmers probably don't know what they need until they have a lot more experience.

Craig Shearer
+1  A: 

For speed demons they rarely use 3rd party libraries and new programmers are usually looking to squeeze every once of speed of of their code. I think if they don't have control over their code they can't get the performance that they are looking for. At least thats why i avoided libraries when I first started to program.

I remember programing my first DAL and avoided all the other free libraries out on the web because I wanted my code to perform at top speed. Later, I discovered that usually its not the code thats the bttleneck its actually the database.

A well-implemented library is likely faster than whatever code an inexperienced person is going to write. It is almost certainly more robust and has fewer bugs, and I don't think giving those up for the possibility of a little more speed is a good principle.
David Thornley
+2  A: 

I'm a programmer, not a psychologist! :)

It was a long, long time ago for me, but it was because I wanted to learn and experience. I didn't want to use something I did not understand, so if I didn't think I understood the library and could program it myself, I tried not to use it. There might have been a bit of fear too; programming gives you a feeling of control, and using a library is like giving away this control.

+2  A: 

When you're trying to learn how to do things, anytime something is accomplished "magically" by calling AwesomeClass.doAwesomeStuff(), you end up giving away a portion of control. When you are "new" and don't know what you're giving away or why it can be unsettling. This was my primary knock against Rails when I was first learning it. So many things just "worked" and I didn't know why without digging through lots of Rails source (which I generally didn't have time to do).

At least, that's my take on it.

+1  A: 

Some open source libraries are buggy or not as efficient as others.

Care to justify how?
+88  A: 

A lot of new programmers are still working at a very low level of abstraction, learning the trade. That's something everyone has to go through. It takes a while to "move up the stack" so to speak.

Once programmers realise that they spend most of the time solving the same problems as someone else already did, and the goal is to realise "business value", then they can really appreciate the value a good library brings.

Nader Shirazie
Well put, in my view.
I disagree! Those who can achieve that stage are good developers; most won't. So you would see senior developers whose "are still working at a very low level of abstraction".
Ngu Soon Hui
Sure, there are times where your senior guys are working at a low level... but those are the times where its worth their time to the business. Also, by Senior Developer, I don't mean people have been programming for a long time...
Nader Shirazie
You can also blame education. Lots of courses on writing a string class or writing a quicksort and the overall impression that using an existing library would be cheating.
Martin Beckett
Excellent points (+1)
Stefan Valianu
Going deeper on "using an existing library would be cheating": to get a computer science degree, I had to take many classes on how to write code, but none on how to manage libraries. If you can do the former, you can probably figure out the latter on your own, eventually, and there's only finite time in the classroom, so I'm not sure I'd 'blame' anyone for this. Fresh graduates have little experience, film at 11. :-)
+17  A: 

Some people, when confronted with a problem, think “I know, I'll use a library.” Now they have two problems.

Seriously - this is a reasonable way for a newbie, already overwhelmed by new language, programming environment, paradigms, keystrokes, etc. to react to the suggestion to use a library. If you've got a solution, but it's not working, there are many potential sources of error; sorting through them is a challenge. Adding to them can seem irrational.

"Use a library" means find the library, download it, install it in your project, and call the necessary function. Not hard, if you're used to it (and there aren't corporate policies against it, and you have reason to trust the vendor, and the library itself has minimal dependencies, etc.). But if it's all new to you, when you ask a programming question and get back a system configuration answer, it can seem unhelpful (even if it is not, in fact).

Carl Manaster
The hassle level of some libraries are simply not worth it for programs that will not use their full complexities. Often, it's like 4 days installing a library, reading the documentation, figuring out how it wants its input, and integrating it compared with 1 or 2 days with your own code, *and* you can write detailed docs for your own code...
Paul Nathan
+4  A: 

More libraries = less billable hours.

That's a very short-sighted vision, but it may hold true for less-experienced programmers. In truth what you should do is get past the re-inventing the wheel bit as soon as possible in order to provide true business value to your client (and they DO notice).
Less billable hours means you can charge more per hour.
Matthew Whited
+3  A: 

Because it's fun.

+7  A: 

I remember shying away from several libraries simply because I wanted to see if I could create my own algorithm. I didn't want to just give up and let someone do the work for me but rather I wanted to learn from my mistakes. Once I had come up with a solution I was happy with, I looked into the libraries.

So for me it was simply wanting to see if I could do it.

Same thing here
That's the great thing about libraries, you can work on something until you reach the "Oh, my idea would work" moment, and then switch to using a library instead :D
Brendan Long
+4  A: 

Most of the points covered off (for me the main one is the learning curve) but one other I think plays a part:

Because learning about a library is less exciting than coding the same functionality yourself.

Jon Hopkins
+2  A: 

The same reason that more experienced developers do -

Because it can often be as difficult to learn how to use a library as to write the part of it you need yourself. And at least then you can understand how it works when it doesn't do what you expect.

An experienced developer just has experience at understanding how to use libraries so more likely to consider it. An inexperienced developer it's one more thing to learn...

John Burton
I'm pretty sure it's almost *never* as difficult to learn how to use a library as to write it yourself - it just seems like that when you start out because you're not aware of all the aspects of the problem, and because programmers always underestimate debugging.
Michael Borgwardt
Don't forget that most third party APIs have features and requirements that you may not need. This can lead to API bloat and cause it to take more time to learn the API then to write a new lighter one.
Matthew Whited
+2  A: 

In my eyes another factor is that additional libraries add complexity. Programs tend to get harder to understand, harder to maintain and buggier when getting more complex. I think what makes especially new programmers shy away from libraries is that adding library code increases complexity more than adding your own code - simply because understanding how the library works is still out of their grasp. So it seems to be a problem of both skill and psychology.

Adding library code increases complexity less than writing one's own - for every other person that will ever touch the code. Only obnoxious prima donnas and newbies that don't know better yet will avoid libraries for that reason.
David Thornley
I dare to partly disagree. If it's a small library doing exactly what you want and nothing more, you are totally right, but bigger libraries do add complexity and their contents are out of your control if you don't invest time reading their source code.If you only need a single feature it might indeed be the better choice to code it yourself instead of adding the code and complexity of a whole library.Regarding code quality, adding an established library to do the job might be better than tinkering on your own - especially if you're a newbie.
+1  A: 
  • newbie programmers not only means guys who just started learning programming, there are cases including people just started learning new languages.

    • learning curve is acceptably the most preferred one, apart from that, people learning new language often don't have that luxury to go to the frameworks suggested.

It's not always easy to compromise your managers to go ahead with the new framework. It requires lot of testing and have to study how this should fit in to your needs.

See my case, I am basically a c# programmer and started learning javascript for my work. Some time ago here in stack I have asked a question about the javascript puplisher/subscriber pattern. Most guys responded telling me it's already been implemented in frameworks like JQuery and prototype and you can easily reuse them.


Ramesh Vel

Ramesh Vel
+1  A: 

I think more fundamental issues can be recognized as a deterrant to using existing libraries.

  1. Part of this as "newbie programmers" is a lack of exposure to libraries. If you don't know they exist, how do you know to use them?
  2. Number Of Options Available. Let's say I'm really interested in learning more about MVC, but if I have to choose between cakephp and smarty and zend and ... well you can quickly see the gears work to discover a way to achieve the goal without investing the time experimenting. Take a look at Freshmeat or SourceForge to get a better understanding at the daunting selection of libraries available.
  3. Questionable support combined with sketchy/outdated documentation for the libraries. Do I want to use this tool that may no longer work or may be abandoned in the future? It is likely that a project will evolve, and so it will for the project of a library too. Will its usefulness last the lifetime of my project or will I be required to re-do this work again?
Good Time Tribe
+2  A: 

Libraries often come with the overhead of learning some API and it's paradigm. It can get complex fairly quickly, and I could easily understand that beginners would prefer something a bit more in their comfort zone. From my experience, I found most libraries & frameworks seem to do a great job abstracting some tedious routine, but when I need to either extend this functionality, or use it in a way that's not intended, it can be a handful.

I think it's one of those things where "practice makes perfect".

+1  A: 

Using a library requires you to understand the relatively complex design of the library, something that new programmers might not have mastered because all they've ever written is simple/procedural/single-purpose code. For example, to an experienced programmer standard design patterns like template method, observer and command seem pretty obvious, but to a newbie it all just seems like magic and/or unnecessary complexity. For me the turning point was when I got good enough to grok design patterns and write some basic reusable code.

+1  A: 

It's been a long time now, but when I came out of college, I knew nothing of libraries. This was in the days of mainframes and mini-computers. Our college had a VAX and the managers were paranoid about students hacking the system, so didn't allow us to even see the library manuals. So, when I first came out of college, I didn't even think of libraries being available.

+2  A: 

Well, the newbie's purpose might be more solving the problem than implementing a solution. Perhaps what they really want to do is figure out how to solve the problem. I mean, if they're still heavily in the learning phase, it's quite possible they don't want easy answers handed to them.

+1  A: 

I am sure there are a lot of reasons why the newbie doesn't want to use the new library. But wouldn't this be a good opportunity, if you have enough time, to show them what the advantage of using the library is? With the people I work with, I will usually provide an example of why something is better than their approach. It helps them learn and mature as a programmer.

+1  A: 

Happens that noobs use Libs without knowing, but when they must import/add one that is fairly less documented, there is a fear of unknow. That happens mostly for compiled langs!

In the interpreted, (or compiled IRT), mainly when there is a console, such fear is almost non-existent; since you can require and see if it fails, call a method and see what it returns.

Consoles are tools of bravery !

Fabiano PS
+1  A: 

I consider myself a mid-level programmer, mostly self-taught, almost exclusively working on my own. I've started to use libraries, but fairly recently.

A major barrier to this was a lack of understanding of different design patterns - or even of the concept. I would determine an approach to solving the problem my own way, starting coding along the way. If I did look at a library, I would often think "Hey, that looks handy, but it won't fit my design."

It took a fair bit of reading and experience trying to apply new ideas to realize two things:

  1. My designs were poor and did not keep things properly separated.
  2. If I consider existing libraries early, the remaining bits often fall into place easier!
+3  A: 

Using libraries is probably one of the worst things a learning programmer can do. Instead of learning how to code, they're learning how to use specific APIs that other people implemented. I'm not saying that every programmer has to understand every single thing that they use, but programmers who know the ins and outs of a computer (digital logic, assembling op-codes, etc) usually have an edge over people who've started with something like Java Swing and are just throwing together libraries.

In production, this is a different matter of course. But I think the best course of education is to 'make everything' once, at least. Writing my own PHP framework from the ground up really improved my programming skills and abstract abilities. Doesn't mean I'll use that framework if someone hires me to build them an application, but I know the strengths, weaknesses, and reasons behind the things that the 'giant' frameworks use, and it can help me choose a particular framework for a particular situation.

Lotus Notes
+1  A: 

Maybe I'm still a beginner, I sometimes still avoid using certain libraries. Some libraries introduces too many abstractions, forcing you to put in more effort to get around it or forcing you to do things in a certain way and I think that's bad. When I'm doing Javascript I'm used to not relying on any libraries. I do, however, copy and paste bits and pieces of code from them and construct my own "mini" commonly-used functions. One of my argument is because some libraries introduces too much "bulk" making web pages load slower. However when doing C/C++ I tend to not afraid of using libraries. But still, when having a choice between a leaner, smaller library to a huge complex library that does almost the same thing, I would choose the former.

Hao Wooi Lim
+1  A: 

I'm not entirely a newbie programmer, but a lot of times I like to implement something myself first, so I understand at least one way of how it works. Then when I have to use it for client work I would go ahead and use a library's implementation of whatever needs to be done.

Ryan Giglio
That makes sense. Thanks.
Byron Whitlock
+1  A: 

I'm probably close enough to a new programmer to be able to comment, and personally at least, I have to say I don't like using libraries because I'd rather get the experience doing it myself for now. I'm not doing anything to a schedule, so the time's not a problem. I'll use libraries when I know I understand an area completely, and can't get anything out of using someone else's code.

Interesting. Thanks for the comment.
Byron Whitlock
+1  A: 

Well, as perhaps the most 'newbie' person to respond, I can answer what my hesitation is...I'm trying to learn the very basics of programming, and so I feel like even though I "can" use a library, I feel like I need to still have a better understanding before I can even dive into those.

I'm not sure if that makes sense, but imagine that a library a physical library. It is full of information and anything I can want to learn is easy to find...right?

But if you don't yet know how to read-or more accurately-comprehend the sentences you are reading, then a library is useless.

I'm still learning how to read. :-D

+2  A: 

Answer from a noob - "I am not sure how to use the libraries or even how to access them or how it works"

+1  A: 

Some newbies feel that if they use libraries they'd be missing on some kind of fun. They have this IWIIOMO (I-want-to-implement-it-on-my-own) syndrome.

+1  A: 

I'd say they find them sort of intimidating. And if they're new to a language diving into more libraries may seem like bitting off more than they can chew. Not to mention more steps involved in getting the environment to work with the library. D:

And from my education experience, (assuming most of these newbies are students) they really don't get much exposure to them.

I sure didn't (while in the classroom). :/

+1  A: 

A few potential reasons (as a newbie):

  • You're not sure exactly what the library is doing. It may be unsuitable for the platform or have unintended consequences and researching this to the required rigour may be seen as a waste of time. Doubly so if the documentation is poor, which open source often is.

  • If code you wrote is bugged, you stand a good chance of making a quick fix when it's noticed. If a library is bugged, you can either i) work around the bug ii) complain to the library's owner or iii) remove it and write your own implementation. Since including the library reference in the first place was your decision, you're responsible for the fix. A slow fix for the above reasons makes you look like a poor programmer.

  • You may have to justify your decision to use a library you know, but your mentor doesn't. With a suspicious type looking over your shoulder it often isn't worth the effort.

  • The code you might potentially include the library in isn't portable enough to make use of libraries as an efficient means of getting things done. A pro may write neat, elegant, portable code which can happily accept the results of library calls. A novice may not. Shoehorning the library into a naive architecture built by a novice may be more trouble than it's worth.

Tom W