I don't like libraries, because ...

[molendijk]

I don't like code extension libraries, because ...
===
Arie
===

[djr33]

because?

Do you mean book libraries or code extension libraries?

[molendijk]

Do you mean book libraries or code extension libraries?

Thanks. Corrected the error. I mean code extension libraries.
===
Arie
===

[BLiZZaRD]

Is this like a fill in the blank thing or are you just a major procrastinator?

[Snookerman]

http://css-tricks.com/the-abstraction-point/

[djr33]

In response to the 'because', I hate memorizing new styles/terms and frequently find it easier to just write it over myself. I find this to be the case with extensions and some of the more advanced functions in PHP-- for example, XML parsing is so complex in some cases that I've written some of the more basic things myself so I didn't have to deal with it.

Given that a library generates quality code, etc., then I don't see a problem. However, this means LEARNING the library, which in many cases is an overall waste of time.

For simple things, write it yourself-- it'll also keep it simpler/more efficient overall.

For complex, involved projects, learn the library and it WILL save you time. But this means that you're putting enough time into it that you'll save time in the end, and that's not all that often especially for special purpose libraries.


The worst of course is when you're trying to use something that doesn't work that well, isn't documented (or commented) well, AND you don't understand what it does in the first place. That's awful, since you of course can't rewrite it yourself.


And in general, I'm always happier writing code rather than reading code-- reading code means you're trying to figure out what's going on and that generates many more headaches than writing. This happens most often when working with someone else's complex system, and I'd say that's the worst part of programming, such as just finding the file/line where some event occurs. Try modifying forum software (any of the packages out there) and finding simple things are generated-- it's always hard and slow.

Of course this also applies to helping others here on the forums-- it's infinitely easier to explain/write something than it is to fix something someone posts (unless the problem jumps out at you) because you have to first think through what they did (sometimes wrong) then how to do it, then find where it DID go wrong and fix/rewrite it. And of course for those of us who help with PHP, this means fixing it without being able to test on the server...

For these reasons, I wish everything was commented. When I write a complex thing I attempt to keep it commented, for the more complex parts literally every line, so that if I go back later I don't have to figure it out again.

[molendijk]

... this means LEARNING the library, which in many cases is an overall waste of time.I completely agree
... For complex, involved projects, learn the library and it WILL save you time. But this means that you're putting enough time into it that you'll save time in the end, and that's not all that often especially for special purpose libraries.
... The worst of course is when you're trying to use something that doesn't work that well, isn't documented (or commented) well, AND you don't understand what it does in the first place. That's awful, since you of course can't rewrite it yourself.
... And in general, I'm always happier writing code rather than reading code-- reading code means you're trying to figure out what's going on and that generates many more headaches than writing.

I couldn't agree more.

... are you just a major procrastinator?

If I were a procrastinator, I'd use libraries and would defer ('pro') to tomorrow ('crastinus') what I should do today: understand what I write rather than simply borrow code.
===
Arie
===

[Snookerman]

I think Chris Coyer explained this really well in the article I linked to. For a website owner, doing it yourself might mean opening a WYSIWYG editor instead of hiring a web designer. For a web designer, it might mean opening Wordpress and writing the code rather than picking a theme and going with it. For another, it might mean writing the PHP code yourself, instead of using a CMS. The point is, you can always* go deeper, you can always* write more yourself. Like Chris said, it depends on how much you know, and how much control you want. For instance, I've started learning JavaScript, and I will work at getting better at it, but I'll still use jQuery because it's so simple and makes things so much easier, thus saving me time.

*Unless you're the ultimate guru and you make your own computer our of paperclips and cheese, but that's just reinventing the wheel.

[molendijk]

Like Chris said, it depends on how much you know, and how much control you want.

Well, I want as much control as possible. But I agree that the situation may vary from one person to another.
Anyhow, if I use a calculator without any knowledge of algebra, I will certainly make unnecessary mistakes at some point. We could compare libraries to calculators.
===
Arie
===

[djr33]

The idea that you can "always go deeper" is a silly notion. That's true in anything. The truth is that you choose a domain and within that should be reasonably proficient. Of course you could always go deeper, but the need should be based on the project, not some artificial sense of existentialism.

That is to say that if you want to create a website, you do not need to recreate html, php, server programming or anything. You learn how to use these well and then you do. Arguably you could rewrite the server so you have more control (but why not just learn the one that already works and is compatible?) and EVEN rewrite php (html generating software). But you can't rewrite html-- it's standardized for a reason.
In other words, no one is special enough to rewrite everything. There's a skill in working within a system.

HOWEVER, working at an artificially removed level that then abstracts from what you are actually doing can be dangerous. Example: using a WYSIWYG editor. The explanation of this is simple: you are not creating 'WYSIWYG'. You are creating HTML. To properly create HTML you should make HTML, not "WYSIWYG" (I'm considering "WYSIWYG" the stuff of preview-based editors-- the graphics, layout, etc.). Likewise using a library is artificially creating something else.
But don't take this to mean it's useless-- it's just that you should understand what is happening at the highest relevant level (that of the coding language, for example) rather than relying on removed tools. If you do understand this, there's no reason not to use such tools as long as you watch what code they generate.


So the important question is not whether you invent the wheel again, but:
1. Do you understand that wheel?
(You wouldn't want to ride in a wagon with a driver who doesn't know that it rolls.)
2. Does the wheel function?
(If only square wheels exist, then it's time to reinvent them.)