I'm a high performance systems researcher, not a professional developer. If I could write my code by just combining existing libraries, then it wouldn't be research.
Load imbalance in a single node in a distributed stream processing system and language, and programming models and code generation techniques for the Cell processor.
Not necessarily. What I don't like about the "programming is about gluing libraries together" approach is that you have to deal with a plethora of hidden costs:
1. Finding the available libraries for the job. There might not even be one if you're doing something somewhat novel. Or there could be a huge number of them, most of them crap.
2. Evaluating the libraries found in step 1. You might find that no library is a superset of the others, that for example there's 3 of them that each tackles 1/3 of the problem in exactly the way you want but you have to compromise and choose only one of them.
3. Dealing with the library's bugs, limitations, misfeatures, incompatibility with your usual programming style. To fix those problems you either have to dig deep into a codebase that's not even your own (if you even can), or you take the passive approach and contact the vendor to ask them to please fix the bug or implement the feature and then wait 2 weeks or 2 months or 2 years or foverer until it gets done.
Whereas with the "I have a strong NIH syndrome and will do everything myself" I have lots of up-front costs but at least I know pretty much exactly what they are and the problems that come up are fun things like: "oh, I need to master this super powerful technique", not boring ones like: "oh, I need to get in touch with the maintainer of this library to implement a new feature I need if he so chooses".
Your #3 hidden cost is nonsensical in the context of CPAN. The libraries are Open Source, and usually heavily tested by both automated tests and hundreds or thousands of users, and if you grok Perl enough to roll your own, then you grok it enough to fix a bug in the library. You'd have ten times the number of bugs to fix if you wrote it yourself, at least I would...maybe you're just that much better of a developer than I am.
As for #1...CPAN search works pretty well. Google can also help. Obviously every hacker is doing something somewhat novel or else they would just be using existing software...but the point of CPAN is to insure you don't have to do the boring crap over and over again. Session management? Done. Database access? Yep. Payment processing? Sure. Templates? Definitely. Internationalization? Well, you still have to hire the translators. Processing and spitting out XML, HTML, YAML, JSON, RSS, etc.? Of course.
So, either you're writing all of this from scratch, or your software is anemic and lacks basic APIs and data export capabilities and interoperability and good security, etc. I'm sure your app will kick ass when you finish it two years from now.
As for 2...does evaluating a couple of competing libs really take longer than writing one from scratch? Maybe, for some classes of problem. But there's a lot of stuff that just takes a lot of code to accomplish.
"oh, I need to master this super powerful technique", not boring ones like: "oh, I need to get in touch with the maintainer of this library to implement a new feature I need if he so chooses".
I don't even really know how to respond to this one, but I'll take a stab at it. Is a template engine a "super powerful technique" that you're excited to figure out? Payment processing? Session handling? How about a test harness? Form validation? Having a good selection of available libraries saves you from the boring crap, not the other way around.
CPAN might be perfect now, but it wasn't always golden. The fact that every module relies upon dozens of other modules meant that your life sucked when one of the dependencies crapped out during an ubermodule install. You'd have to trace down where, what and why the dependency was broken and the idiosyncratic nature of Perl didn't help much with fixing things. Tearing my hair out during another aborted CPAN install was one of the reasons I switched to Python in 2001. Python came with its own set of issues but at the time they seemed more appealing than dealing with amateur hour on CPAN.
My post is self-contained, it didn't reference CPAN or the article.
Hmmm...That seems a little odd in the middle of a conversation about a blog post that talked about pretty much nothing but CPAN. I guess you can talk about anything you want, but you can't possibly expect us to know you're not talking about the same subject as everyone else.
I find your adversarial tone inappropriate.
I'm sorry you feel that way. I'll try to tone done the sarcasm in any future replies to you.
Well, in your first post you just thought I was attacking CPAN, while the berserk part is when you combine your two posts together.
"maybe you're just that much better of a developer than I am [...] So, either you're writing all of this from scratch, or your software is anemic and lacks basic APIs and data export capabilities and interoperability and good security, etc. I'm sure your app will kick ass when you finish it two years from now. [...] I don't even really know how to respond to this one, but I'll take a stab at it. Is a template engine a "super powerful technique" that you're excited to figure out? Payment processing? Session handling? How about a test harness? Form validation? Having a good selection of available libraries saves you from the boring crap, not the other way around."
Such extreme condescension stemming from an misunderstanding of what I was saying I consider "going berserk", yes.
"I guess you can talk about anything you want, but you can't possibly expect us to know you're not talking about the same subject as everyone else."
"I'm sorry you feel that way. I'll try to tone done the sarcasm in any future replies to you."
What a beautiful paragon of passive-aggressiveness. I applaud you!
Then I am not like you.