Why I call myself a Javascript Programmer
raganwald.posterous.com
raganwald.posterous.com
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?"
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.
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/
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.
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.
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.
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".
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.
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.
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.
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 immediately thought of his metaphor with the woodworker and his toolset, that needs skills build on it, as well as the working material.