“If Your Only Tool Is a Hammer Then Every Problem Looks Like a Nail”
quoteinvestigator.com
quoteinvestigator.com
I can’t even say what’s wrong with PHP, because— okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there.
You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes.
You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.
You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever.
And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools.
Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door.
That’s what’s wrong with PHP.
[1] http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
[1] https://www.flickr.com/photos/raindrift/sets/721576294929080...
EDIT: noticed that jfb had used this already, if only in slightly different form.
Now that I'm a programmer, I find myself and many co-workers doing the opposite. (In fact, I'm a huge culprit, so this isn't a holier-than-thou comment.) A specific set of technologies dictates the problem set and the approach. I recently heard about a college class, for instance, that challenged students to solve a business problem using a Raspberry Pi and an Arduino. I won't deny that those are interesting and useful technologies, but once they wielded those hammers, without a single hour of research, every problem probably looked like a nail.
Whilst I agree with your first paragraph, I think you've picked a particularly poor example to illustrate it with here.
The problem the college course is solving is "find an engaging/useful way to teach students about embedded programming & automation". As such, "solving" a notional business problem through personal meetings and a written process whilst leaving all the hardware in its wrapping would/should result in a failing grade.
This formulation is much more "If you're being rewarded on your ability to hammer things, it's largely immaterial whether or not they are nails.", or perhaps a little more favourably:
"Someone who successfully solves problems with hammers will tend towards seeking nail-like problems."
Or people who only use general-purpose tools for one or two things based on stereotypes they heard somewhere?
See also the Web.
http://en.wikipedia.org/wiki/Tsujigiri
In my mind this is isomorphic to the metaphor of the hammer. A samurai with a new sword will go out and cut up the first person he sees.
This is a cautionary tale, you might end up hurting somebody. If, for example you get a new katana(e.g. python decorators) you might decorate everything that looks like a function, but you would actually suffer casualties in readability and structure; debugging becomes a mess. Therefore you should also understand when and who needs to be cut up.
Re: OP. I always maintain the source of the quote to be Nietzsche (He was a jackdaw - aren't we all? - so I'm not claiming he's the original source. As if that means much anyway - ideas/memes are like the fashion cycle, being upcycled to 'culture' from the street.
(Its over twenty years since I read any N. so no idea which book but maybe Menschliches, all zu..)
Which is well and good, until you've got to recompile them on a checkout, or figure out what the hell they're doing, or get bitten by stupid bugs that only live at the low-level.
:(
That, and the lack of a sufficiently-abstract concept of strings.
To wit, let's get the length of two strings in Ruby and C.
Ruby:
("aha" + "oho").length
C: char buffer[1024]; // lol i hope this doesn't overflow
memset(buffer,0,1024);
strcat(buffer, "aha");
strcat(buffer, "oho");
return strlen(buffer);
And that C version? Still not always safe; consider the case where a string overflows, where somebody else fucks up that memory in the stack by (say) a bad variadic arg invocation or array access out-of-bounds.Oh, and is that string length including the null terminator (no)? And why do we even care about null terminators unless we're doing low-level memory frobbing?
Anyways, imagine that sort of arcana multiplied across every string operation in your dumb little script. It's awful.
strlen("ahaoho")
The C code more closely reflects what the Ruby is doing, but otherwise yes, you're correct. In C++ I could probably get it all done at compile time anyways.The only real case for a short C utility is if the heart of what you're doing is a single system or library call that isn't so readily accessible in Python, Perl or shell.
"When you have a nail in your eye, everything looks like a nail."
--danceswithcats on some random website I'm not going to bother finding in my history
Dans ses écrits, un sage Italien
Dit que le mieux est l'ennemi du bien.
~~Voltaire
Also, the author is a careful researcher with a long track record.