It's the title of my other blog written in my native tongue.
Why wannabe?
Because I grew up with Eric Raymond's essays like How To Become A Hacker and with Paul Graham's Great Hackers, which while partly childish and narcissistic, I think it had irreversible effects on my personality.
Certain ideas stick around, and before you know it, you have faith without questioning assumptions. But if I were to name a single truth I learned is that "code talks, bullshit walks".
Somehow I could never grok that the end-result should matter more than the means to get there. That is why in my personal projects I tried really hard to stick to my beliefs. And personal projects are those projects where, you know, you have absolute control and none of that "bullshit" that goes with working on a big company. And yet I couldn't get the job done more efficiently at home.
Why? Because I would get pretty confused about the choices I had to make. Choices that I ended up judging based on politics and personal feelings.
Should I use Python? It makes me feel good. Yeah but it's not "turtles all they way down" like Scheme and its performance is not so good. But Scheme doesn't have libraries. And oh God, that Linq feature in C# is sooo cool, but C# is as verbose as Java. Hey, maybe I should use F#, since it is a ML dialect with all kinds of goodies and has access to a huge library, but it's proprietary, and why not use Scala? It's open-source, and good for DSLs, but somehow it feels dirty, and that JVM is consumating tons of resources which I can't stand. Ruby is a nice language and I can stand performance issues since it's so beautifull, but damn, its unicode support sucks.
Sounds childish, and it is.
Some of us can recognize this as the paralysis of choice. Don't fall into that. Don't use Lisp because of Paul Graham's classification of good/bad programmers. Don't use Linux because Eric Raymond said you cannot hack other systems. These are just tools. The end results is usually far greater than the sum of the parts you use.
And really, you can find a lot more beauty in algorithms.
Good tools make a difference, but when you're hit by choice paralysis, you should stop, take a deep breath, and choose what you're most familiar with, even if that's a painful decision. And in the end a far greater ingredient for success is passion. Nurture it, don't suffocate yourself with useless debates.
Sure, it's great to have mentors and to try the taste of multiple technologies and paradigms, and to reason about why some people have had success, but as they say "bad artists copy, great artists steal".
Sunday, September 7, 2008
Subscribe to:
Post Comments (Atom)
4 comments:
Earlier this week I was experiencing some choice (or analysis) paralysis on a personal projects, so I know what you mean.
On the other hand, for me, rarely is it based on what technology to use or not - I just pick one and run with it. I have problems identifying what features I want to put in and in which order.
Should I mention OCaml and Haskell to give you more choice? :)
OCaml is imho beautiful, but its libraries quite suck. Typesystem sometimes too, but not too much. Compared to Java it's bless.
Haskell is also nice, but imho too much forcing the pure functional style (that is, the monadic code somewhat sucks compared to doing same thing in the non-pure and strict language). Haskell IO is though very good with concurrency and network IO.
So I'm using mostly perl, ruby and ocaml, with occasional haskell, as libraries and staff seems to fit and connecting pieces in adhoc ways. Who says some project can't use 3-5 a bit esoteric languages at once? :P
"the monadic code [in Haskell] somewhat sucks compared to doing same thing in the non-pure and strict language"
I disagree. Once I understood it, I find that monads are the most concise and clear way to write imperative code. I've been tossing an imperative language around in my head off and on for a while, and I don't think I would be able to bear designing it without monadic semantics.
If you take the sum total of all the code that's out there from Eric Raymond and Paul Graham, and add them together, it'll be a tiny fraction of the text of the self-promotional essays they've written. That suggests that that Bullshit does, indeed talk.
I have to say I've never had trouble deciding which tool to use. But I don't think I've ever approached it by trying to 'validate' myself to a celebrity nerd. Choose whatever you think is best for the problem at hand (and that problem might be wanting to learn a cool new tool).
I do, however, think it is very important to use tools where you have access to the source code. At least to the compiler and to the libraries you are using (system and otherwise). I say this because it was a big watershed moment for me to realize how quickly and easily the source code can answer any question I have about the system. I recall I had spent days trying to figure out why I couldn't write to a block device, until I finally got out the code to the 'dd' program and saw how it was done there.
Now I have the source code to my toolchain downloaded and installed in my home directory, I also have written a set of shell scripts to make it easier to find what I'm looking for in there. The alternative is to spend days or weeks banging your head fruitlessly against questions about the system when the answer is just out of reach inside a binary module.
You also have the advantage of reading a great deal of expertly-written software, which is one of the best ways to become a better programmer.
Post a Comment