The only thing to take away from this anecdote is that libraries are the key to getting things done these days.
When you are writing a compiler, you are doing most of the work on your own. You don't need much help from external libraries. (Perhaps you need a compiler compiler, but that's about it.) When you are writing a web app (or something similarly "useful"), you aren't going to have much time to do your thing if you are reinventing an HTTP server, a request dispatcher, a component loader, an event handling system, a persistence layer, and so on. The reason the author's C++, Java, and Python colleagues were getting more done than him is that they were all building things on top of each other's work. The author was starting with nothing every time.
0 + 1 person's work is almost always going to be less than (everyone in the company's work) + 1 person's work. If Google used Lisp, he would probably not be "behind".
There's more to take away than that, although yours is one big tangible reason why he got left in the dust.
The major point I got from this article is that you can't stop being hungry for knowledge and expect not to get beat by those who are. The language didn't matter; he got bested by the people who kept learning and exploring while he decided he had learned "enough" for one lifetime. He made the mistake of making it about those around him; he didn't want to continually improve, just better than those he would be compared with. He went from learning just enough to best people, to being smug, to being a curmudgeon against other languages/platforms/etc he professed to not know a lot about. I keep seeing evidence around me that this is a very counter-productive shortcut to take, but one that most people don’t own up to; props to him for being honest, but sad that it took him too long to come to reason about it. In an odd way, I see this same pattern of behavior in a lot of the one-language-wonder Java programmers I meet today; they know Java, and find what reasons they can to declare that all other languages suck.
So, your point about libraries is a good one, but I’d amend your remarks to advise cultivating an attitude toward development that makes using libraries and ideas of others almost instinctual, and that, I think, is by making sure you always stay hungry for knowledge.
You can take this too far. For me, the interesting part is in the hunger for knowledge itself, and not what we do with that knowledge. That's led me to pretty much reinvent myself as a programmer every year - I went from doing Java Swing apps, to PHP webapps, to Netbeans plugins, to Haskell compilers, to JSF webapps, to Python/JavaScript Web2.0 startups, to a big C++ codebase in about 8 years (the last 5 are all in the last 3 years). The problem is that there's a whole lot of stale knowledge rolling around in my brain. I pray I will never have to use the JSF/Facelets/A4J stack again, but I spent a year becoming pretty familiar with its intricacies. Meanwhile, my coworkers who joined Google straight out of college are way ahead of me, because they didn't take all these detours through dead technologies.
There's a balance to be struck. You need to be hungry enough to viciously attack new problems, yet not so hungry that they become an obsessive end in themselves.
I am somewhat of the same way with having a hunger for knowledge itself. I've found that what happens when I go from technology to technology isn't so much a reinvention as an augmentation. Maybe your experience has been different, but I've noticed an increasing depth in my analysis of systems, and I can't help but think that a part of this is due to the knowledge I've picked up in the meantime, even if it seemed tangential at the moment I learned it. To borrow some other authors words, it's partly why Peter Norvig, the Pragmatic guys, and ESR all push for people to learn different languages; your memory of the syntax might be ephemeral, but your internalizing of the concepts might change your thinking in ways you don't consciously notice.
This poses an interesting, and very difficult, question to answer: how do you know whether something learned now will be useful in the future, especially if few other seem particularly interested? Over time you might develop an intuition for which things seem like they would be useful, but I can't imagine such an intuition would be perfect.
I think this is a deeper question than the downvoting you're receiving suggests that it is.
There is a certain amount of one's desire to learn that is a matter of personality, and my understanding is that there is some degree of a person's personality that is determined by things other than socialization. Not all of it, but enough to possibly make a difference.
The flip-side of this is that if there are people who, due to some or another in-born trait, are unable to cultivate an attitude of continued hunger for knowledge, that is something they need to deal with by not entering into a profession that demands it. And programming is definitely one of those fields.
> I think this is a deeper question than the downvoting your receiving suggests that it is.
Yes, I agree. (I upvoted the comment.)
A full response to this will take longer than I have right now (maybe I'll work on a blog entry later tonight). But for now, just for the record, my problem was definitely not that I was unwilling to learn new things. I love learning new things, and always have.
> That's one of the reasons I hate Java, because learning Java didn't teach me anything except how truly brain-damaged a language can be.
> I learned more in my one year at Google than in the previous thirty.
This actually makes sense. It's not about being curious, it's about what you're curious about. I remember once asking one of my friends a very basic question about ring theory (whether a certain ring axiom is overly strong.) He completely refused to consider the problem, because it didn't seem relevant. That's not a lack of curiosity, just a lack of curiosity about irrelevant questions, and math is all about knowing which questions to ask. It's not like you learn nothing by solving the problem, just not anything you would have ever wanted to know.
Thanks for the perspective on this; it appears I did misinterpret what you wrote in the originally linked post, likely due to the lack of context you mention.
The reaction I had to this was primarily due to me seeing in this post the stories of countless other developers who stagnate but then don't have the self-reflection to realize that they have, and don't have the motivation to get themselves out of the hole they've fallen into. While attempting to motivate the Lisp community to wake up and get working, in my mind you unintentionally created an anthem to all of them. Hopefully my initial response to this makes a little more sense. :-)
The problem I see with talking about that attitude-from-birth is that it encourages complacency. Can you get to that instinctive level? I don't know, but I think that a person could certainly try and achieve a good level of competence. Saying that it's an accident of birth discourages hard work and encourages the idea of 'innate hacker skill.'
> The problem I see with talking about that attitude-from-birth is that it encourages complacency.
Whether a statement is true or false is independent of what it encourages. Let's assume that curiosity is totally hard-wired. Then is it really a good thing for someone to try to become more curious, instead of investing that effort into something else?
And just because it's "from birth" doesn't make it "hard-wired," and even if it is "hard-wired," that doesn't mean it can't be rewired and worked around.
Neuroplasticity FTW. The human brain is a most adaptable tool.
But that said, how many infants are 'incurious'? They either are curious, or there is something wrong with them. No baby is incurious without some kind of pathology.
The takeaway for me was "It's better to be really good with your tools than to have really good tools."
He sucked because he had to write Java, yet never took the time to learn all its idiosyncrasies. Meanwhile, the people around him didn't care so much about what tool they were using, they just put effort into learning that tool really well. If he'd been using Lisp, there probably wouldn't be a problem - but you can't use Lisp (outside of prototypes and research projects) at Google.
Yeah, but you gotta feel the guy's pain. I mean going from using lisp for your whole life to Java must be pretty mind-numbing. He should have tried to get on a Python project... at least that way he wouldn't have had to go from the most expressive language to the least expressive in one step.
"The conclusion was inescapable: the problem wasn't Perl or C++ or Java,
it was me. I just wasn't a very good programmer any more. Lisp's power
had made me complacent, and the world had passed me by. Looking back, I
actually don't think I was ever a very good programmer. I just happened
to have the good fortune to recognize a good thing when I saw it, and
used the resulting leverage to build a successful career. But I credit
much of my success to the people who designed Common Lisp."
Yeah. I can attest to that. Many non-lisper friends have learned to do very difficult things while I personally remained ignorant of them because I never needed them. This is analogous to how being a fortune 100 CEO is bad for your health compared to being a day laborer; you no longer sweat and work your muscles, you no longer get the necessary daily vitamin D from sun rays, your hands are not as manly and rugged, etc.
Yeah, but then you can afford a chartered JetStream to fly you to the Bahamas for 2 hours of Jungle Gym and back.
Ron Garret just wishes 37Signals to fork SBCL and get us Lispers some hype :-P McCLIM windows with rounded corners FTW!
A good question would be who learns more: someone who is an expert at one language and toolset, and continually uses it for investigation of new ideas, or someone who continually changes his language and toolset. Given it takes thousands of hours to become an expert at any combination of language and toolset, I would rather spend my time doing great things than learning new tools. Will you gain exponentially more programming skill by learning haskell or erlang, or should you invest the same time learning another domain (e.g. chemistry, biochemistry, finance etc), and solving new problems in those domains? I would suggest that the latter provides more brain expansion.
Another way to look at it is that programming isn't hard in and of itself. The hard part in any software project is understanding the problem. If all you do is practice programming, and ignore the real world it's likely you will be a great programmer, but make beginner mistakes when trying to solve problems. I have seen brilliant programmers get completely schooled by domain experts with excel macros when it comes to solving some of these problems.
It's the difference between programming for programmings sake or programming to solve problems.
I agree with everything you said but I would take it even further. One doesn't even have to go to chemistry or finance to find better things to invest time in than learning new tools. There are plenty of areas within the domain of computer science/software engineering/hacking that are more worthy of effort than learning a new programming language (let alone a new text editor or version control system.) How about learning how to write code that matches regular expressions in guaranteed linear time. Or implementing a compiler. Or looking at the networking protocols used by QuakeWorld and how they are different from the protocols used by the original Quake and why.
I'm not against learning new programming languages. Everyone should learn a few different languages. I just think many people fetishize them out of proportion.
His story is almost sad - but in a good way I suppose.
I'm going back through my undergrad CS classes and picking up scheme and lisp again, and I'm really enjoying it this time through. I feel retroactively angry at the linguistic kludges I had to work around in other programming languages before.
That being said, there's always room for diversity. Knowing different languages will either reinforce your opinion of the superiority of your preferred programming paradigm, or it will shed light on a new way that you can hope to incorporate into future development. Either way, you end up the better for it.
"The state of C++ was so horrific back then that they were
forced to go back to Lisp because they just couldn't get things to run in C++ even though they tried very very hard." But I'm sure they were much richer for the experience, with several new connections in their brains about how to approach problems with a different set of limitations.
"...I feel retroactively angry at the linguistic kludges..."
I can so relate to this - I was looking forward to hacking in Ruby after php / C++ / Java , but this enjoyment is muted as I've now had a taste of Scheme...
Ill bite my lip and do some Rails hacking aboard the Lear jet...
I think this is a lesson that you dont' stick to one platform or language. You always branch out. Programming fundamentals are the same, different syntax and culture sometimes but you limit yourself to one language and you are done when it is done... and it will be done at some point.
>dont' stick to one platform or language. You always branch out.
The problem is that, to many Lispers, branching out from the Lisp world often feels like branching out on a random path from Rome in its glory days might have felt like - filthy, stinking barbarians abound in all directions. Personally, I feel caged whenever I am not programming in Lisp or a language with similar metaprogramming capabilities (Mathematica, for example.)
"The problem is that, to many Lispers, branching out from the Lisp world often feels like branching out on a random path from Rome in its glory days might have felt like - filthy, stinking barbarians abound in all directions."
There are plenty of languages as "elegant" as Lisp, but are significantly different in "feel" and usage - smalltalk, Forth, Prolog, Haskell, Io ...
Lisp has no monopoly on elegance or "metaprogramming", certainly not to the point where the "classical rome vs stinking barbarians" analogy is valid. (This ignores the historical fact that many greeks thought the romans were loutish parvenus, but that is a story fro another day).
>Lisp has no monopoly on elegance or "metaprogramming"
Lisp (or rather, the Lisp family - the word has not referred to a specific programming language for decades) does have a monopoly on programming by way of raw syntax tree entry. The latter appears to be required for a proper macro system (though David Moon and others have attempted to change this.)
The fact is, I feel caged when I am programming in a language where I cannot monkey with the syntax at will, and I am not alone in this feeling. When I am barred from creating new syntactic constructs, I feel like a "human compiler" (in fact, exactly that which the job title "programmer" actually meant in practice before the invention of actual compilers.)
I wish to branch out to languages which feel less limiting and more general than the Lisps, not otherwise. And I have yet to encounter any. All of the good ideas of Haskell (laziness, etc.) are easily bolted on top of even a stock Common Lisp. Likewise for the other languages named. Forth, however, remains interesting due to its AK47-like simplicity and embeddability.
I feel like a "human compiler" (in fact, exactly that which the job title "programmer" actually meant in practice before the invention of actual compilers.)
Here's what I did. For a set of problems, of increasing difficulty, I would write a solution procedure, using the notation of A Programming Language I would then ask the graduate student assigned to me to:
program the procedure in any programming language he chose,
execute the procedure for a representative set of data values
give me his program and answers so that I could compare them with the specifications I had written and the answers I had previously calculated.
The result, which I still find surprising and impressive, was:
In every case, what was programmed was exactly what I specified.
I feel like Lisp's big win over C, Java, etc. is its support for aesthetically pleasing functional programming. Much more of the difference between Lisp and Blub comes from functional programming than from user-defined macros.
Macros are cool, but I don't write my own macros very often, especially when working in Clojure, which has great built-in ones. Most of the general-purpose macros implemented in, say, On Lisp have decent analogues built into Clojure or Clojure.Contrib.
Python, Ruby, et al haven't necessarily gotten as good as Lisp, academically speaking, but for a lot of purposes, they're good enough.
I think that anyone who wants to consider himself a serious hacker needs to learn Ocaml or Haskell, though, in order to gain exposure to what a good static-typing system has to offer.
branching out from the Lisp world often feels like branching out on a random path from Rome in its glory days might have felt like - filthy, stinking barbarians abound in all directions
A rather apt analogy, as it was those filthy, stinking barbarians (and their descendants) who were mostly responsible for the renaissance, the enlightenment, and modern western society. If biology has taught us nothing else, it's that a monoculture is always at risk.
I am trying to analyze his choice of Python.
Python in my opinion, is a practical language, not a fun language.
Perl, Ruby and Groovy are all in my opinion more fun and interesting to work with than Python.
Perl is my opinion, hardcore and the Perl community is again in my opinion by far the most interesting.
Ruby, well, its hip! I guess, and all the girl developer are using it.
Groovy combines Java's practicality and the fun of using a dynamic language with advance feature, like closure! or Groovy's definition of it
Python, well, yea okay they have Django and TwistedMatrix, other than that I believe Python can destroy more careers than Java, C++ and Visual basic combined, the community is so dry and the language is so boring ... which I believe makes it an effective deterrent to any free-spirited individual
Python was one of the first languages I tried, and I have to say that it knocked me out! and I am still recovering! The Python community just killed my enthusiasm to be a programmer.
What I believe killed Ron's career, is that he never cared if Programming was fun! And it seems he still don't!
Lisp is smart, intellectual and intrigues you to think, but not very usable and the brackets thingie, its annoying.
Python is not thought provoking at all but very usable and practical.
I enjoyed this post because I feel the same way about Ruby. Many moons ago I used to know C (as in, I didn't have to look every little thing up), Pascal, and even some x86 (for inline use only, mind).
For the last four years I've done nothing by Ruby and.. statically typed languages freak me out now. I know I could do it, but if it's not as super easy as Ruby I'm not all that interested anymore even though there are probably plenty of cool projects I could be using C, C++, Objective C, or whatever for.
It is the author's fault for not realizing the real-world skills he'd need. You're not a good programmer unless you know multiple paradigms -- that's like saying you're a mechanic but only being able to change the tires. And true, knowing Lisp gives insight on the flaws of Java ... but knowing Java gives insight on the flaws of Lisp.
if current java/python/perl/ruby and their goodies were used instead back then ... could Rover in moon be REPL-debugged miles away from earth? ... given the limitations of very low memory
i'm particularly curious about that one year learning from google
When you are writing a compiler, you are doing most of the work on your own. You don't need much help from external libraries. (Perhaps you need a compiler compiler, but that's about it.) When you are writing a web app (or something similarly "useful"), you aren't going to have much time to do your thing if you are reinventing an HTTP server, a request dispatcher, a component loader, an event handling system, a persistence layer, and so on. The reason the author's C++, Java, and Python colleagues were getting more done than him is that they were all building things on top of each other's work. The author was starting with nothing every time.
0 + 1 person's work is almost always going to be less than (everyone in the company's work) + 1 person's work. If Google used Lisp, he would probably not be "behind".