"C is not like a hammer, C is like wood. [...] Knowing all about the subtle details of working with wood isn't especially portable to working with cables that carry electricity or layers of carbon fibre or blocks of solid aluminum."
All metaphors leak, but this one seems leakier than its predecessor. Turing equivalence (http://en.wikipedia.org/wiki/Turing_completeness) tells us that any program can be written in any computer language. (Except SQL. But let's not get into Turing-incomplete languages now.) Whereas electric cables can't be made from wood.
The "hammer" metaphor, on the other hand, would suggest that you can do all kinds of woodwork with just a hammer; it's just needlessly difficult. Which seems more accurate.
Mr. Babbage tells me we can make a computer out of wood. And our wooden computer can simulate what an electric cable does. And that's what Turing tells me. Not that we can write any program with a Turing complete language, but that we produce the same computational result, quite possibly by simulating the other programming environment, just as we might Greenspun Lisp into every other programming language.
So when discussing media, no we can't make a bamboo bicycle that has exactly the same weight and strength as a carbon fibre bicycle. But then again, we can't write an assembler program with the same number of lines as the equivalent Haskell program, so those differences can be hand-waved away. The point is that we can make bicycles out of either material, and knowledge of the material is different from knowledge of a specific tool that works the material.
I think your point is interesting, but I'm not convinced that my suggestion is leakier than comparing C to hammers. I stand by my suggestion that hammers are more like IDEs than programming languages, and that there is a very important distinction between IDE as a tool and programming language as a tool. I reject the latter.
To borrow another Perlisism, "The debate rages on: Is this metaphor Bactrian or Dromedary?"
"our wooden computer can simulate what an electric cable does."
Theoretically, yes, but I still think that using C for all your programming needs is closer to the degree of difficulty of "using only a hammer for all your woodwork" rather than the degree of difficulty of "replacing all your electric cables with miniature wooden computers".
Well, that's very true. But you know, if I meet someone who calls themselves a "C Programmer," I would be surprised if they were trying to build a client-side web application as a browser plug-in in C. C Programmers tend to ply their trade in places where their skills provide value, so "using C for all of their programming needs" might work out with very little difficulty, just as a carpenter would be unlikely to try to wire a house.
Then again, there's nothing like expanding your horizons a little. While it's fun and surprisingly instructive (for me, at least) to think things like this through, I'm sure people will grant that debating how much the metaphor leaks says nothing about what you or I might think of C, or Javascript, or the benefits of learning a new programming language every year.
Ouch. That kind of sucks, actually. IIRC, Turing incompleteness had some nice side effects for SQL - such as guaranteeing program halt, and allowing perfect automatic optimization.
Being Turing Incomplete doesn't mean that programs are guaranteed to not halt. It just means that the Halting Problem may not be undecidable for that class of programs/machines. I'd be surprised if that was useful in the real world.
You can't talk about Turing equivalence without acknowledging the Turing tarpit (http://en.wikipedia.org/wiki/Turing_tarpit), which reminds us that in theory there is no difference between theory and practice, but in practice there is.
Why not? I'm not advocating the use of Brainfcuk for all your programming needs, and Turing completeness has plenty of other uses in discussion. (It's particularly useful for converse statements - e.g., for most languages, there exists no compiler that determines whether your program will halt.)
You know, if I liked hammers, and I didn't do carpentry for the sake of making houses, but just because I liked hammering nails, I might well call myself a hammer carpenter.
Not many carpenters would claim that, but that's because hammers aren't very interesting compared to programming environments.
That's a really interesting suggestion. People self-identify for all sorts of reasons, and the pleasure of doing things a certain way is one of them. If you don't like writing queries in SQL, all the arguments in the world about SQL's efficiencies are not going to drag you away from an abstraction you enjoy.
People say (description)(profession) to quickly describe what they do to other people. They pick the best description.
Long haul truck driver doesn't mean incapable of driving short distances, it means that most days she gets up, gets into a truck and drives a long way. If you're some place that makes outsiders cringe you might get all philosophical about whether the "long haul" or the "truck driver" part of your job description is the heart of the matter, but... no one wants to listen to that:
Internet marketers go on about whether internet or marketing are really the heart of what they do. So do leggo artists.
Why not "Front End Developer"? Sure the tool is JavaScript, HTML, and CSS but if there was a better tool tomorrow, you would still be building front ends- just with different hammer.
You would be surprised how many people decide to stay with the hammer they know, regardless of a better hammer (easier, less intensive, less mistakes) being released. The only thing that might sway them is the master carpenters up on the food chain heavily promoting their use of their new hammer, but that still may not be enough. Having a better tool is one thing, actually getting people to use it is something else entirely.
"C is not like a hammer, C is like wood. So a C Programmer is a wood-worker."
Uh, no. The data is the wood. Programming languages are tools to manipulate data. The analogy is valid, but I prefer using musical instruments.
You can make music with many different kinds of instruments. But it would be hard to call yourself a great composer if all you know how to play is the flute.
Metaphors aside, am I the only one who defines an x-language programmer as someone who is able to actually fix problems that are specific to the environment that the language provides? (e.g. buffer overflows in C, cross browser support in javascript, to give examples of the languages mentioned in the discussion)
Certain debates are timeless. I think that in my children's time there will be programmers and that some of those programmers will be unable to understand what their tools abstract away.
Most programmers today don't really understand how a compiler/interpreter works, how to write assembler, how to allocate/free memory, or even a solid understanding of data structures yet work somehow gets done.
My friend, I am going to have to let you go on this one. That's another, fine debate that has carried on since the invention of the first compiler, and continues today with people firmly on both sides of the fence.
I personally think that an abstraction is useful when it helps me to focus on the essentials of completing a task and allows me to ignore the irrelevant, but allowing me to ignore it today doesn't mean I need never understand it.
As an example, I was the development manager for a tool called JProbe. One of its fine tools was useful for identifying memory leaks in Java programs. We had a devil of a time explaining to people what a memory leak was and how a Java program could have a memory leak despite not having any of those complicated pointer thingummies.
To a great extend, Java's memory manager provided value by allowing a programmer to think about other things most of the time. You be the judge of whether Java programmers ought to know how memory works and what a reference is, and the difference between a strong and a weak reference, and how it is that a program with no pointers can have a memory leak.
Yep. At the last D.C. meetup, a bunch of us HNers heard an environmental engineer express her fear of programming because she has always been "bad with languages", and couldn't master Spanish or German.
I really wish I called them "notations", instead I said they were "formalisms, just like in mathematics" .. and somehow I don't think she thought that conveyed neither simplicity nor ease of learning.
> comparison to languages like English and Japanese That was my point.
Just like a speaking language, you can only learn them by practicing them.
Just like a speaking language, the pedagogy has to be geared towards forcing yourself in awkward situations or problems to master the language rather than lecture.
Just like a speaking language, they have different version dialects or syntax that change over time. This is a collaborative process.
Just like different speaking languages, programming languages some differences in grammar rules as well as similarities. As learning Latin will help you learn other Romance languages, learning C helps you learn C++ and C#.
Just like speaking languages, programming languages are developed to facilitate communication. Between programmer<->programmer and programmer<->computer. They are the vocabulary for defining situations.
Just like speaking languages, programming languages influence how we think when using other languages and leave us with accents.
Just like linguistics, there is an underlying core set of operations in computer science that languages are built over as an abstraction. The languages themselves are abitrary inventions and not derivable, mathematics seems a particularly bad analogy.
Except that C is not like wood, in the sense that it's a substrate out of which programs are constructed. It's more of a notation for describing the program, which the compiler then translates into another description, which the hardware then "runs" without the program ever being brought into existence as such. Therefore, C is more like a specific type of blueprint: it's good for building sheds, but it's not good for building motors or skyscrapers.
It's not like a blueprint, either, because you can just go ahead and build a birdhouse with no blueprint, but you can't just go ahead and build a program with no language.
We can pick holes in one metaphor after another, and fundamentally get nowhere. The point is simply to not over-specialize on any one environment, unless either you strongly believe it's the best one for every job or you're pretty sure you'll only ever want to do that job. I would contend that most people know neither of those things with any real certainty.
I think your argument is extremely literal. Metaphors don't sugest that X is Y or that X is like Y in every way, just that from a certain perspective, X has a lot in common with Y. So there will always be holes to pick in every metaphor.
Your argument reminds me of another Perlisism:
There will always be things we wish to say in our programs that in all known languages can only be said poorly.
It's true, and that's sort of the point. My "argument" (as it was firmly tongue-in-cheek) was more literal than yours, just as yours was more literal than the hammer argument. The whole idea was to demonstrate that there's always a more apt metaphor. When you get to the point where you can't find a difference, it's not really a metaphor anymore.
The best part about metaphors is not the conclusions one can draw from the similarities between two things. It's the conclusions one can draw from the differences.
Also. for what it's worth, I think that quote applies just as well to human languages as to programming languages. Perhaps the metaphor itself might make a good metaphor for programming? :)
I don't see the harm in specializing, really. There are plenty of room, and need, for both generalists and specialists. Being a specialist doesn't mean you are unable to learn new things, or that you are daft.
I think what people really mean is "don't be daft".
I call myself web developer, but if I were a little bit more specific I could call myself: HTML/CSS/JavaScript/<whatever crazy sever technology you can think of> programmer. If I wanted to be a little vague I would call myself ninja or rock star.
The reason I like web developer is that it gives a clue to everyone about what I am doing or trying to accomplish, it also may give the impression that I am trying to be open minded about the technologies I use, with some bias towards the things I already know.
Frameworks are good but you should not get stuck with them. You should not use them if there is something else that may be better for the job.
I call myself a Ruby programmer, a Java programmer, a Python programmer and a Scala programmer because I like to programme things in Ruby, Java, Python and Scala.
And it is a convenient way to, you know, help people understand that I can't programme in C# or COBOL or Perl or Objective-C or Prolog or Scheme (yet), but I could certainly give it the old college try.
45 comments
[ 3.5 ms ] story [ 96.3 ms ] threadAll metaphors leak, but this one seems leakier than its predecessor. Turing equivalence (http://en.wikipedia.org/wiki/Turing_completeness) tells us that any program can be written in any computer language. (Except SQL. But let's not get into Turing-incomplete languages now.) Whereas electric cables can't be made from wood.
The "hammer" metaphor, on the other hand, would suggest that you can do all kinds of woodwork with just a hammer; it's just needlessly difficult. Which seems more accurate.
Mr. Babbage tells me we can make a computer out of wood. And our wooden computer can simulate what an electric cable does. And that's what Turing tells me. Not that we can write any program with a Turing complete language, but that we produce the same computational result, quite possibly by simulating the other programming environment, just as we might Greenspun Lisp into every other programming language.
So when discussing media, no we can't make a bamboo bicycle that has exactly the same weight and strength as a carbon fibre bicycle. But then again, we can't write an assembler program with the same number of lines as the equivalent Haskell program, so those differences can be hand-waved away. The point is that we can make bicycles out of either material, and knowledge of the material is different from knowledge of a specific tool that works the material.
I think your point is interesting, but I'm not convinced that my suggestion is leakier than comparing C to hammers. I stand by my suggestion that hammers are more like IDEs than programming languages, and that there is a very important distinction between IDE as a tool and programming language as a tool. I reject the latter.
To borrow another Perlisism, "The debate rages on: Is this metaphor Bactrian or Dromedary?"
Theoretically, yes, but I still think that using C for all your programming needs is closer to the degree of difficulty of "using only a hammer for all your woodwork" rather than the degree of difficulty of "replacing all your electric cables with miniature wooden computers".
Then again, there's nothing like expanding your horizons a little. While it's fun and surprisingly instructive (for me, at least) to think things like this through, I'm sure people will grant that debating how much the metaphor leaks says nothing about what you or I might think of C, or Javascript, or the benefits of learning a new programming language every year.
http://bitbucket.org/cheery/z_woodc/overview
Actually, SQL2008 is Turing-complete! See (if HN doesn't mangle the link): http://assets.en.oreilly.com/1/event/27/High%20Performance%2...
Not many carpenters would claim that, but that's because hammers aren't very interesting compared to programming environments.
People say (description)(profession) to quickly describe what they do to other people. They pick the best description.
Long haul truck driver doesn't mean incapable of driving short distances, it means that most days she gets up, gets into a truck and drives a long way. If you're some place that makes outsiders cringe you might get all philosophical about whether the "long haul" or the "truck driver" part of your job description is the heart of the matter, but... no one wants to listen to that:
Internet marketers go on about whether internet or marketing are really the heart of what they do. So do leggo artists.
-----
[1]: http://jashkenas.github.com/coffee-script/
[2]: http://github.com/mootools/slick
[3]: http://github.com/cloudhead/less.js
Uh, no. The data is the wood. Programming languages are tools to manipulate data. The analogy is valid, but I prefer using musical instruments.
You can make music with many different kinds of instruments. But it would be hard to call yourself a great composer if all you know how to play is the flute.
Most programmers today don't really understand how a compiler/interpreter works, how to write assembler, how to allocate/free memory, or even a solid understanding of data structures yet work somehow gets done.
I personally think that an abstraction is useful when it helps me to focus on the essentials of completing a task and allows me to ignore the irrelevant, but allowing me to ignore it today doesn't mean I need never understand it.
As an example, I was the development manager for a tool called JProbe. One of its fine tools was useful for identifying memory leaks in Java programs. We had a devil of a time explaining to people what a memory leak was and how a Java program could have a memory leak despite not having any of those complicated pointer thingummies.
To a great extend, Java's memory manager provided value by allowing a programmer to think about other things most of the time. You be the judge of whether Java programmers ought to know how memory works and what a reference is, and the difference between a strong and a weak reference, and how it is that a program with no pointers can have a memory leak.
I really wish I called them "notations", instead I said they were "formalisms, just like in mathematics" .. and somehow I don't think she thought that conveyed neither simplicity nor ease of learning.
Just like a speaking language, you can only learn them by practicing them.
Just like a speaking language, the pedagogy has to be geared towards forcing yourself in awkward situations or problems to master the language rather than lecture.
Just like a speaking language, they have different version dialects or syntax that change over time. This is a collaborative process.
Just like different speaking languages, programming languages some differences in grammar rules as well as similarities. As learning Latin will help you learn other Romance languages, learning C helps you learn C++ and C#.
Just like speaking languages, programming languages are developed to facilitate communication. Between programmer<->programmer and programmer<->computer. They are the vocabulary for defining situations.
Just like speaking languages, programming languages influence how we think when using other languages and leave us with accents.
Just like linguistics, there is an underlying core set of operations in computer science that languages are built over as an abstraction. The languages themselves are abitrary inventions and not derivable, mathematics seems a particularly bad analogy.
It's not like a blueprint, either, because you can just go ahead and build a birdhouse with no blueprint, but you can't just go ahead and build a program with no language.
We can pick holes in one metaphor after another, and fundamentally get nowhere. The point is simply to not over-specialize on any one environment, unless either you strongly believe it's the best one for every job or you're pretty sure you'll only ever want to do that job. I would contend that most people know neither of those things with any real certainty.
Your argument reminds me of another Perlisism:
There will always be things we wish to say in our programs that in all known languages can only be said poorly.
http://www.cs.yale.edu/homes/perlis-alan/quotes.html
The best part about metaphors is not the conclusions one can draw from the similarities between two things. It's the conclusions one can draw from the differences.
Also. for what it's worth, I think that quote applies just as well to human languages as to programming languages. Perhaps the metaphor itself might make a good metaphor for programming? :)
I think what people really mean is "don't be daft".
I immediately thought of his metaphor with the woodworker and his toolset, that needs skills build on it, as well as the working material.
The reason I like web developer is that it gives a clue to everyone about what I am doing or trying to accomplish, it also may give the impression that I am trying to be open minded about the technologies I use, with some bias towards the things I already know.
Frameworks are good but you should not get stuck with them. You should not use them if there is something else that may be better for the job.
And it is a convenient way to, you know, help people understand that I can't programme in C# or COBOL or Perl or Objective-C or Prolog or Scheme (yet), but I could certainly give it the old college try.