I liked this sentence. It's so very true.
"Just because looking down your nose at C++ or Perl is the popular opinion doesn't mean that those languages aren't being used by very smart folks to build amazing, finely crafted software."
"Just because looking down your nose at C++ or Perl is the popular opinion doesn't mean that those languages aren't being used by very smart folks to build amazing, finely crafted software."
It's a platitude, sometimes it's even the wrong mindset to have, tools do matter. And worse still it's starting to sound hollow given that all dagdum talks about is how you should do awesome stuff instead of talking on the Internet.
How about he talks about something cool he did recently instead? I guess that doesn't get him as many page views.
At least in this case it is actually correct, unlike previous entries, C++ and Perl are filling two very specific niches perfectly and their obvious shortcomings are the flip side of their strengths.
You have to be careful about this. Using this as a justification not to have good tools ("What's wrong with you? Suffering worked great last time") is bogus logic; there's no reason not to have good tools. The other side of the coin, NOT doing something because you don't have good tools yet, is equally poisonous.
- The test team that spends all its time writing test frameworks and tools, and never writing any actual tests. (How many times have I seen this?)
- The engineer who spends half his time "optimizing" (finding the perfect language, defragging his hard disks six times a day, tweaking TCP settings so repository access is as fast as possible) and not writing code.
- Going around and around on a class design until it's /perfect/.
- Not moving on something because you lack complete understanding.
It's hard to overstate the benefit of just getting in the ring and doing /something/.
After 25 years of random fiddling with one side project [not going to tell you want it is] I finally just started writing some fucking code. And you know, it feels darned good. The stuff I'd been worrying about being inefficient and so forth turned out to be only a few hours of thinking and coding. It was fun.
A poor craftsman blames his tools.
If you give a shovel and a screwdriver, don't complain if the house I build is not up to code.
If I show up with a shovel and a screw-driver, you have every right to send me away.
This middle ground approach is probably best.
PG writes about tools and their importance in "Beating the Averages": http://paulgraham.com/avg.html .
They help, but they don't matter one iota in most cases. Whatever one is doing in Rails could be done in Django or PHP or whatever. A better tool can help, but not as much as using what you already know, using things that have programmers to hire in your area, using what has community support, etc.
If you are using C++ you are probably doing so because you're programming something "closer to the metal" so are probably more likely to know your stuff technically.
On the one side you have the "C was created by God himself, and undefined behavior is expected", and then you have the "languages should be as restrictive as possible because this one time I worked with a developer who was very bad."
It's all very tiring. I do mostly Ruby now, and I love how expressive it is. It reminds me a bit of C++ in that regard. It's just funny how the mindset has shifted.
Whenever I meet someone who extols the virtues of language X I always, sort of cynically, ask them what low-level embedded work they've done and how X could be utilized for that use-case. It's one of those areas where most programmers don't seem to have much background, which if they thought about it would make the utility of C readily apparent.
Edit:rephrased last clause.
Or Visual Basic.
"Just because looking down your nose at C++ or Perl is the popular opinion doesn't mean that those languages aren't being used by very smart folks to build amazing, finely crafted software".
Ie: don't shudder.
I do not accept that they are making it any easier on themselves by this choice of language.
I am interested in D for this purpose - the most recent version looks quite well designed - but it's not as widely supported.
All other things being equal, sure, choose the maximally powerful language in whichever dimension makes sense. But all other things are usually not equal.
If you are working on a project by yourself, here are some things which are more important than the characteristics of the language:
- your knowledge of the problem domain
- your knowledge of general software development
- your knowledge of the limits, capabilities and ecosystem
of the language (aka project experience)
- your customer's expectations (if you're shipping software to them)
- the ability to recruit experienced individuals for your project
- the availability of mentors / reviewers within your organization
- the availability of secondary resources (books, FAQ, etc)
Picking up a new tool shouldn't take long, but can give a significant benefit. As I like to say, learning something well enough to use is an O(1) action where the benefit is in O(n) to how much you use it.
In the long run, the quality of the tool dominates your current familiarity with it.
While bringing lots of money home, I would add.
I've worked with both and cursed them both to death. But they achieved crazy popularity for a reason. They are extremely powerful and capable tools.
C++ especially can sing in the hands of masters. (And anyone who thinks they mastered C++ in less than 10 years doesn't realize how much more they have to learn. (I mainly curse it because once you have 20 people on a C++ project, there's no hope...)