If you look at a language like Smalltalk, you will see that there's very little to the syntax (even less than LISP, i'd say), so knowing Smalltalk really amounts to knowing its class library.

I'm guessing that you've taken an extreme position to make your point.
One certainly does need to know how to write, (http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html), idiomatic Python to call oneself a good Python programmer, but one also needs more than a basic knowledge of the standard library and the methods of built-in objects. (And knowledge of doctest :-)

- Paddy.

I'm guessing that you've taken an extreme position to make your point.
One certainly does need to know how to write idiomatic Python to call oneself a good Python programmer, but one also needs more than a basic knowledge of the standard library and the methods of built-in objects. (And knowledge of doctest :-)

- Paddy

Well, I suppose what I am partly saying is that my sense of "knowing" a language is out of whack with actual reality; these languages have such useful standard libraries that they become part of the language. This is helped by the way they support arrays and automatic memory allocation, which allows a lot of standardization in the libraries.

Arguably it's also because few people are using them to write software that is as complicated as that which is written in C (so the built-ins are enough to handle the 90% case, which is certainly not true for what C is used for), but if I said that I would get jumped on by fans of BitTorrent, or Movable Type for that matter.

- adam

Hmmm. Pulling my 35+yo signed copy of K&R 'The C Programming Language' off the shelf it is interesting to note that by Chapter 2 of that very small tome the authors are already into utilizing the standard libraries. So I don't think this has been a trend of the last 10 years. More its an intrinsic desire to get to higher level modules quickly since the beginning.

My final observation is that most 'hiring managers' really screw things up thinking of programming skills in terms of how good someone is at C#. The bigger question is how well can a candidate grasp the problem and its scope.

In a language such as Forth or Lisp, there is very little syntax to be learned. Thus, "learning the language" consists mostly of learning which method calls do what and how to use them. The latter can involve some subtleties, however; programming with stack- or list-based data structures is quite different than, say, programming with arrays, lists, or hashes.

In moving to Ruby (from Perl), I found that conceptual issues (e.g., iterator design and use, method aliases, symbols) were the most challenging. In general, I knew that there "should be" calls to perform certain tasks; I simply needed to find out what their names were in Ruby, etc.

In any case, I would say that debugging examples should use the idioms of the language in question. This avoids reactions like "the author clearly doesn't understand the language, so why should I believe he knows about debugging", but that's only a minor reason. The major reason is that, in a high-level language, the language constructs and idioms allow code to be far shorter and cleaner, reducing the opportunity for bugs to arise. So, a book on debugging should concentrate on the kinds of bugs that _can_ arise in that language.

I don't think I really see your point, Adam.

If you care to learn Scheme, for example, you can learn literally *all* of its built-in syntax in about an hour or so. Does this mean you "know" Scheme, even though you couldn't produce anything particularly useful in it?

Oh, and by the way, I suggest you add rel="nofollow" automatically, to try and stem the tidal wave of spam. See:
http://googleblog.blogspot.com/2005/01/preventing-comment-spam.html

I think its more of an issue of new school vs. old school.

The massive draw of python for me is that it HAS so many optimized built-ins. I can prototype my code in python within minutes, have the general idea working, and then re-write it in a more clunky language across multiple files (for those now-non existing libraries).

There is definitely something to be said about each programmers personal preference - legends of the hardcore c guru's having personal libraries in the millions of lines of code. Personally? I'll stick with small python/ruby tools to generate what I need when I need it.

I do agree with your notion of an 'experience' language specific developer though - knowing both the syntax, list/tuple/dict differences (and how to create them without the calls), and knowing common built-in functions off the top of ones head.

I think part of this is actually due to Python itself. The more I learn Python, the more important it is to understand the subtleties of the language. You can get by ok with for loops and the like, but the real power happens with list comprehension and advance usage of the core types.

For example, Python will never need a "switch" statement because you can use a dictionary. When I first heard that it flew right over my head. A dictionary works well as a replacement because you can use a function as its value. This is important because functions are first class citizens, similar to javascript. When you throw in the concept of callables (objects implementing the __call__ method), it can be even more powerful.

I don't know if this sort of thing is entirely unique to Python. C# has some similar language constructs that can be very helpful beyond a "library". I seem to remember seeing a few helpful nuggets in PHP as well.

I suppose I should mention that I didn't get hired for a PHP job because I didn't know about the ksort function, so it is probably best to cover the language and the libraries if at all possible ;)

"A man should keep his little brain attic stocked with all the furniture that he is likely to use, and the rest he can put away in the lumber-room of his library, where he can get it if he wants it." -- Sherlock Holmes

"While obsessively trolling the Web for mentions of Find the Bug"

I think you mean trawling. (Or better yet, "searching.") Trolling is something else entirely, especially in the context of the internet. :) (And even in the technical sense: to troll means to get at something by baiting it to follow or come to you (like one would with bait); trawling is the opposite method of sweeping an area searching for something and collecting it directly (like one would with a net).

I know this comment is loathesome, but interchanging trolling/trawling is a pet peeve of mine.

Woosh, comment frenzy! Here I go:

JohnMc: Yes, in K+R they use the standard libraries, and today that is basically irrelevant for knowing C. I think the standard library for Python will remain more relevant.

Rich: Possibly I could have done some examples in Python that were 30-40 lines of dense Python. But I think those would have been too hard to find. And the point of the book is that the debugging skills you need are language-independent. It wasn't a "Python gotchas" kind of book.

Peter: Well, that's my point. Things have changed. As for nofollow, I probably should add it, although I confess I don't see how it actually avoids spam (do spammers check for nofollow before spamming?)

Eric: We agree (as for not being hired because you didn't know a specific fact, that is generally not the way to hire long-term, but I suppose if it was a contract thing, and knowing ksort would be expected, it could be viewed as a sign you didn't know it as well as you claimed).

Stephen: Right! I think Einstein said don't remember something you can look up.

T. Rawler: Apologies for choosing wrong among troll and trawl. I should of known the difference. I'll try to make less mistakes of that sort in the future. Seriously, I am also prone to language policing, so thank you for pointing that out.

- adam

Could not agree less.

1) Some Slashdot commenter had what I think is the best phrasing of this issue: "Libraries are the new languages." 2) "Trolling", in its literal sense, is dragging a bait or lure behind a moving boat. The word is derived from "trawling" because they're similar forms of fishing, with different equipment.