I'd suggest learning C as soon as a basic grasp of programming (variables, condition, iteration, basic data structures and abstract data types) is there. C is the lingua-franca of programming: advanced algorithms are often implemented in C (or in C like languages), other language concepts are often expressed in terms of C language concepts. "Gold standards" of systems programming are the C POSIX API and BSD sockets (best books on network programming use C for all of their examples). Learning UNIX and the GNU tool chain is also important.
Learning a non-imperative languages is also vital: most importantly Lisp such as Scheme and a strictly and statically typed functional language with type inference like Haskell or ML.
As for Ruby vs. Python, it's an implementation detail. The languages are close enough as if you know one, you can learn the other when you need to (at a new job, or when there's an open source project you'd like to contribute to). Make sure to be fluent in one, however, as "scripting" is a vital skill (especially if you have to deal with a production environment or build/release tooling).
Same principle as Ruby vs. Python also goes for Java vs. C#. I would, however, suggest learning C++ and/or (one of) Java/C#, as they're rather widely used in industry (and not just for legacy work).
Important thing is understanding the fundamentals and seeing the overall patterns.
Important thing is understanding the fundamentals
and seeing the overall patterns.
And the most damning for C and Java in my opinion. C and Java's syntax (which does matter to those who are learning), is so verbose as to hide a lot of what the fundamentals and patterns are.
This is why I chose Ruby and Python. The languages syntaxes are clean and are never in the way, allowing new programmers an easier time understanding those fundamentals.
By "fundamentals," strlen means "memory management," "pointers," the gritty stuff. You can't escape memory management by using Ruby and Python, and a rudimentary understanding of pointers are also essential.
a = ["Hello", "World"]
b = a
b[0] = "Goodbye"
print a
The first time I tried this, I was baffled why ["Goodbye", "World"] showed up. The answer lied in the way this scripting language used pointers, and it wasn't until I learned C that I really understood that.
As for memory management, I often accidentally write scripts that use gobs of memory thanks to silly mistakes; e.g. not using weak references when I should (oh look, more pointers!), creating new objects instead of reusing old ones , forgetting to unregister event handlers in my nodejs apps, etc. C's "every malloc() must be free()d" policy teaches these things to you in a very explicit way. Sometimes you have to clean things up when your scripting runtime doesn't know it should.
Even after using python for many years, I still occasionally make this mistake. It is a tough "bug" to track down. Can anyone comment as to why deep-copy is not the norm?
def f(b):
b[0] = 'Goodbye'
a = ['Hello', 'world']
f(a)
It's more efficient to pass function arguments by reference, and it would be fairly baffling if function argument passing did not work like assignment (c.f. C++ copy construction being similar to, but slightly distinct from, assignment).
Less philosophically, everything in Python has pass-by-reference semantics, even ints. The things you might think are passed by value are immutable, so it doesn't really matter whether they are passed by value or by reference. For example:
a = 1
a = a + 1
conceptually creates a new integer object and binds the name a to it, and so does
Simply because it is slow. In the GP's example if a was a much bigger array, copying it over to b would be expensive. On a related note, in C++ for many containers (if not all) in the standard library, copying is the norm; in "The C++ Programming Language" Bjarne Stroustrup warns that it may be slow.
C's syntax is different from Python's for a reason: what each operator does is very much transparent from the syntax. The point of learning C is to understand what the computer does (as you program it in a higher level language).
In Python, I can say:
...
if "foo" in bar:
do_something()
That's excellent, that's what I expect from a high level language. However, I am not forced to think about whether bar is a hash table (dictionary) an array, or something else. That, again, is excellent for the kind programming you do with Python: you're programming to an interface and not an implementation. Java's standard library also encourages that.
Collection<String> bar = getBar();
...
if(bar.contains("foo")) {
However, you also need to understand how the various containers implement "__contains__" or ".contains()". That is, you need to understand algorithms, pointers (in Python and Java, every value is a pointer and memory leaks are still possible!), memory management. C is a better language for learning these fundamentals than Python or Java.
Of course, Python and Java (and also, Smalltalk and Lisp/CLOS) are much better languages for learning object oriented design and "design patterns" in the classical sense. However, I've found that I never quite "got" OO until I had already had a job as a software engineer. I would have never gotten a job as a software engineer without knowing the fundamentals. I also feel that having grown up on C has been an advantage in terms of being able to reason about systems aspects of my work, even though professionally I mostly worked in C++ (with STL), Perl/Python and Java.
C's syntax as being applied to high level languages is a different matter. I agree it doesn't make much sense for Java: for example, lack of any type inference is really annoying. Perhaps that's why I find programming in Scala to be more pleasant, even when I am writing imperative code. I agree, it can be annoying to use a syntax meant for a low-level language to write in a strongly typed, memory-safe high level language. However, the syntax is not the most important part of a language, especially for pedagogic purposes.
At what academic level are these students? Every university^ I know of teaches incoming students in a language with C style syntax and they handle it just fine.
Carnegie Mellon's intro CS course has been in python for a couple of years, and we're switching to ruby for the coming year.
Of course, that's followed by (Our own version of! =/ ) C, and then SML.
Question for those who know more than I: what are the tradeoffs of first learning one language in depth, then branching out versus learning several languages(/styles) early on?
Using python for a completely introductory course for students that had no prior exposure to programming is one thing. However, it must almost _immediately_ be followed by C (and later by Lisp, ML/Haskell) rather than be used as primary language of instruction.
No offense, but I actually picked Ruby because everyone just seemed so damned excited all the time, gushing over the latest Rails release or coming up with weird names for gems, and when you're knee-deep in bug-infested legacy code or banging your head against the keyboard wondering why you're the only hacker in the world that doesn't get it, that's actually very important.
OK, _why is amazing, but the Poignant Guide is really not the best place to learn Ruby. It may be for some, but I have to be honest, it diverges so much into madness and a pointless, meandering storyline for so long that I couldn't bring myself to finish it. I've spoken to others with the same experience. Maybe the first few chapters are worth reading, if only to get references like "chunky bacon". I suggest the pick-axe book for some good Ruby learning.
I am picking up Ruby, and the Poignant Guide is... uh... lousy. It maunders and meanders and diverges into slightly drunk? stoned? btardy? certainly ridiculous areas.
Problem is, I'm trying to maintain a focus: learning Ruby. Humor is fine. But I want to focus and Get Stuff Done.
I've taught Ruby to six or seven people now. We're talking average joe people (well, for the most part. my girlfriend is a nerd). All of them told me point blank "The Pickaxe book made me fall asleep".
The storyline and madness keep the reader's attention in a sea of absolutely alien ideas. If you can't see the value in that...
You may be right to suggest another book as an eager student's introduction to Ruby, but the Poignant Guide is a really awesome book that absolutely deserves a mention. The meandering storyline and its quirky character are part of its charm.
_why's explanation of block syntax in the Poignant Guide sticks with me to this day! The imagery of a little waterslide that block arguments slide down into their block is both charming and memorable.
Once again, my reaction: "What is this I don't even"
Amateur hour gibberish.
This was just as stupid as the last time it was posted. Same shallow treatment. Same jokey stuff about becoming 'the master'. Same name-checking of a few books that this guy has vaguely heard about ("The Dragon Book is teh awesome") and not read.
This would be charming if it were rewritten without the pretentious gibberish and sexism as a 'what worked for me, a newbie myself' type post.
There are some problems with rendering this text in Chromium - words around some of the punctuation overlap. Also, I think that ESR's guide is much more informative:
http://www.catb.org/~esr/faqs/hacker-howto.html
The OP omits some of the points I consider important - problem-solving attitude, low level programming, learning unix. Also I think that starting with both Python and Ruby is a bit strange idea - they are really similar (in almost every way I can think of) and such course of learning may cause some confusion (e.g. which pieces of syntax belong to which language?).
"starting with both Python and Ruby is a bit strange idea"
This suggestion is precisely interesting, because while we might consider them close they solve problems differently in many cases. The one hacker lesson to learn of this (besides the fact that programming can be enjoyable by gazillion orders of magnitudes than with "corporate" languages) is that while bad solutions do exist, there might also be competing but perfectly valid solutions and that one being good does not mean that everything else is bad.
I was going to respond to a few things, but you linked to ESR's guide, the most condescending guide to hacking I know. Anyone who links to this guide seriously is usually not going to be swayed by even the best arguments.
I'd be more than happy to hear your arguments. Perhaps I am missing some points you could show me clearly? Your original post lacked some explanation behind what you mean by word hacking itself and while at first kind of dismissed your post with ESR, I would like to know what do you think hacking is about? (As esr's text guided me somehow, your comment made me think i may actually be missing something)
I think that starting with both Python and Ruby is
a bit strange idea - they are really similar (in almost
every way I can think of)
Exactly the point. They are so similar that the transition from one to the next is easier than most other languages. Once you have an easy transition students will notice similar patterns. "Oh, looping. Hey, this is something that happens in both languages."
Has anyone actually been successful following a similar path? Has the author actually read all these books? This is just a list of books on programming languages and tools. Why am I learning Ruby and Python? Why am I avoiding relational database servers and learning SQLite? Nothing is explained.
Yeah, I think a better way is to just pick some software or project you care about and dive right in. The books mentioned in the articles are all fine, but without a goal and lots of experimentation, reading books won't make you great at anything.
That said, picking a Ruby/Python project first and picking up some of the topics mentioned in the article on the way is certainly not a bad thing.
3. I've chosen Ruby, SQLite, and the like because of how easy it is to go from 0 to learning. Have you ever spent 8 hours trying to figure out a messy install of MySQL? You can bet a learner will.
All of these are "path of least (possible) resistance"
I'm rolling my eyes right now, just so you know. I'm sure EVERY programmer should really be interested in "teh womenz."
OTHER HOBBIES FOR FUCK SAKE
Now my head is firmly planted in the palm of my hand. You seriously can't tell them apart they're so embedded. I don't know when that started happening, but it's really quite remarkable.
People program as a hobby. It's how a lot of free software gets written. It's how people learn.
Here's a simpler guide to "becoming a hacker":
1. Read a tutorial (note: not a big honking book or anything listed on in the article. not yet.)
2. Implement the most simple possible number guessing game
3. Think of ways to improve the game and implement them
4. Get stumped on something, refer to the language documentation, or google as a last resort
5. Repeat 3-4 until you've exhausted all your ideas
6. Find a slightly more ambitious program to write. An address book is a good start. Repeat 3-4 until you have a decent address book program
7. Repeat 6 until you have a handful of small programs under your belt
8. Now pick a book to read, pick the parts that interest you, do the exercises if there are any, and take notes
9. Apply what you've learned to improve your programs; if you notice some marked improvement (readability, performance, your own productivity), retain that theory. if there was nothing gained; repeat this step or abandon it and move on
10. Start building non-trivial programs, forking open source projects, and write more code. Do some coding puzzles once in a while
For any new language, start at 1.
I am generally against starting with books. Especially for people who are interested in programming but haven't already figured out how to write and compile a few simple programs on their own. These sorts of people aren't even sure that they will like it, so throwing a thick meaty book filled with a whole bunch of nonsensical programmer-speak isn't going to really entice them. I say wait for the books until you've gotten a taste and are committed to learning more. The effect is much more impressive when you just run some code and see the computer "do stuff." That's when you realize it's not rocket-science and anyone can do it.
The problem with "teh womenz" is that up until that point I was thinking of adding that list to a set of programming resources I'm sending to a friend of mine who's been learning programming recently. And sure, she'll have to deal with that kind of attitude eventually, but I'm not going to throw it in with the basic training resources.
Talking about "teh womenz" is a good way to end up with a dearth of women in your general vacinity.
As most, if not all, learning books have you do exactly as you listed I'm not exactly sure why you're against starting with books.
It's just a rule of thumb.
Most books are just crap. I own a lot of them and have read most of them. They're great for programmers. From experience handing them to complete newbies, they're awful. Once you get past the tutorial they turn into a few hundred pages of greek. As well, being even over a hundred pages makes the book an investment for a newbie and most people are lazy. If the book is too thick it'll get lost under papers and forgotten promptly.
That being said, not all books are like this. I am considering handing out copies of The Little Schemer to any friend who is interested in programming. It's succinct, well-written, and teaches just one thing -- concepts. It doesn't teach a language, theory, libraries, and list a few example programs. Just one thing. That's enough for a newbie.
So that's why I say, just do a tutorial first before you delve into a book. Learn only enough that you can muck around and make a few basic things to impress yourself with and decide whether you're having a good time.
It's humour. Relax.
It's not really funny. Not because I'm humorless and uptight. It's just not funny.
That's why it says "other hobbies". "Other", as in "in addition to" or "besides this one".
blech. this is an alright recipe to being a standard nerd/web developer and reads far too much like a list of things the author has done, especially the hobbies part which imo has bugger-all to do with being a hacker.
my personal idea of a hacker is someone who knows _everything_ and is not afraid to take advantage of that knowledge. of course it's impossible to know everything, but the best hackers I know do a very good job of approximating that :)
Sure, but it's just standard practice to do so, and taking a hobby doesn't really get you any closer to being a hacker. And putting "womenz" and "drinking" as hobbies is just lame.
Also not wanting to give the wrong impression, the folks I'm thinking of are not "know-it-alls", they don't tell you random crap to sound smart, but I can learn a lot from talking to them normally.
Is this kind of thing really helpful? I mean if I think about what "Hacker" means to me, it's someone who's passionate enough about computers to explore the inner workings and make cool things.
It seems to me that if you need a guide for the journey, you're already kind of missing the point.
I went on an interesting journey with this article. I first clicked expecting to see what Paul Buccheit succinctly labelled "Limited Life Experience + Overgeneralization = Advice".
I found generalised advice, without a word on the author's actual experience. Which I generally dislike, because I like to know who's telling me things. I'd much rather read "Here are some things that worked for me and might work for you" than "this is what you should do".
I also nearly gave up because of poor opening sentence construction, bad jokes ("Drinking Heavily? Not Another Neckbeard?") and outright sexism ("Teh Womens").
Also offputting is the arrogance that comes through the article's tone of "the master" giving omniscient advice. Every great programmer I've personally met was humble about what they could do, and the Dunning–Kruger effect would seem to suggest that's not coincidence.
But then I started thinking about how it's hard to give advice to newbies when you have experience. I mean, my advice on "what worked for me" to start programming is "Have your parents buy you an Apple //e when you're a kid, learn AppleSoft Basic and then try to learn 6502 assember, keep making things and learning from mistakes for 20+ years and you might be on the right path to become me but then again this might be the wrong path to become you.". That clearly doesn't translate on several levels. And I'm relatively young blood who wouldn't dare give advice on this topic. If you're older and more experienced then your story is going to be even more complicated, and harder to translate.
That's when I decided to look at the author's bio. And from right here on HN: "I started learning how to program with Ruby about 10 months ago". Combined with their own bio[1], this suggests they are actually pretty new to this too.
Which would seem to be bad, but it's actually a tremendous advantage when giving advice to newbies. So my advice to the author, if they're reading this, is:
* Rework the advice you clearly want to give around your own experiences. For example, you say "read the Dragon book". Did you actually read the Dragon book? Which parts? What did you learn from it, and how did you apply the knowledge? What did you need to know before you could begin to understand it? Tell us what you did, that you think someone following in your footsteps should do.
* For a second example, you say upfront to learn both Ruby and Python (seemingly concurrently, which I think sounds like an awful idea) but your own experience seems to suggest you learned Ruby first. Why do you now recommend learning both?
* More importantly, please tell us which things you think you wasted your time learning or trying to do or practising that weren't worthwhile.
* Drop the attitude (even if it's intended tongue-in-cheek, it's offputting) and drop the sexism.
I too found the tone of "the master" offputting, so I thought, let's check out this guy's skills, see if he has something to back it up.
http://krainboltgreene.heroku.com/resume - linked from the front page - "Application Error". Real experts dot their i's and cross their t's, especially before going public...
Sexism, a term coined in the mid-20th century,[1] is the
belief or attitude that one sex is inherently superior
to, more competent than, or more valuable than the other.
It can also include this type of discrimination in
regards to gender. Sexism primarily involves hatred of,
or prejudice towards, either sex as a whole (see misogyny
and misandry), or the application of stereotypes of
masculinity in relation to men, or of femininity in
relation to women.[2]
It's not fucking sexism, for the 56th time today. It's light internet humor. It's an incomplete sentence.
post script: The dates on how long ago I started learning ruby are outdated.
There's a lot of geek feminists (myself included) who get irritated about assumptions that all geeks/hackers/programmers are male. No amount of dictionary definition quoting is going to make me think it's not sexist to put a gender-specific joke in a generalised list of advice.
post script: The dates on how long ago I started learning ruby are outdated.
It doesn't matter if you learned ruby 3 months ago or 7 years ago. The point of my comment is this - instead of giving a laundry list of canonical "do this, do that, become 'a hacker'" you could give some advice on how you learned to hack, that you think might be relevant to others. The more recently you learned to hack, the more valuable that advice is.
A generalised laundry list of "the path" is disingenuous. I don't care if it comes from you, me, DHH, Linus Torvalds, Donald Knuth, Jacob Appelbaum, RMS, Fabrice Bellard, Rusty Russell, Guido van Rossum, Jamie Zawinski, my mum, or some school kid. Everyone's path is different and personal, noone's is canonical. But therein lies the value.
Functional languages will blow your mind, and make you a better programmer in the end. Languages like Haskell, Erlang, Lisp, and Clojure are great for this sort of thing.
It's great that people think so highly of functional programming, but this always sounds like damning with faint praise. I mean, "It'll blow your mind and broaden your horizons" is a reason to drop acid, not learn a programming language. Learn these languages because they're useful. There are many more effective methods to reach some state of mind-altering enlightenment.
Python first (because it's intuitive and I want to build motivation by completing a project right away), and then C (to learn memory management and other subtleties.) That sound reasonable?
Thank you for this article. I recently started teaching my sister how to program and chose Python thanks to articles/discussions on HN similar to this one.
If you are taking pull requests here are a few suggestions:
* "Honing Those Skills"
+ http://hginit.com (Free, Web)
[Why? I found it a wonderful intro to distributed version control in general and Mercurial specifically]
+ http://yuiblog.com/crockford/ (Free, Video+Transcripts)
[Why? Provided great context and in-depth details in a very efficient manner]
* "Gettin’ Paid, Makin’ Money"
+ C# / .NET (Large job pool)
* "Things You’ll Need"
+ Ability to take constructive criticism
[Why? Get better faster. Appreciate user feedback.]
* "Not Another Neckbeard"
- Teh Womenz
[Why? It's obvious from your comments that you do not feel this is sexist nor did you mean it to be. I would have to log this under "taking constructive criticism" however. You point out that you know women who don't mind but there are some women who are bothered by this and taking it out would not impact the goal of the article. If you can make 1 person feel better about your writing by removing it to avoid any misunderstandings while not altering your meaning, it seems like a win for all.]
It is posts like these, where a majority of the audience will be super-educated and a small portion (me) not at all, that it would be great to have upvotes. I can only make an educated guess as to what the best advice is to learning code here.
A strong opinion could send me on my way for months doing the wrong thing.
While perl is certainly useful for scripting, I'd reecommend you learning python/ruby (personally I use former) - they are most universal among these 5 language; whereas js/php are good mainly for web related stuff and perl won't give you as much possibilities either.
Learning on your own != learning as a college CS student, it seems. I'd be curious to compare and contrast "Hacker's Paths" for students versus people trying to squeeze in a few hours a day. (My intuition is that the theory-first approach makes more sense for students than for the self-taught.)
This should be called The Coder's Path for the same reason this site should be called Coder News. A whole section on "Gettin’ Paid, Makin’ Money"? Fucking please.
Eventually every artist has to learn how to sell their work. Is it because they're selling out, just doing it for the cash? No. Some of us have families to feed.
You are confusing the difference between approaching the process of becoming a hacker for-profit and approaching the path to hackerdom because you seek enlightenment. When you are primarily seeking promised riches at the end of the path, you aren't following the path.
Honestly, Why does everyone and their brother STILL recommend Kernighan & Ritchie in all those "Getting Started" articles in this day and age?
I am not trying to diminish the significance of their work in any way shape or form but first we should learn Ruby and Python and THEN "C Programming Language" to "get paid"...?
Why not recommend diving into modern C++ and some of the absolutely fantastic libraries out there (Boost etc..) or more modern books on C instead? I am sure this would get you much further and keep you up to speed with current advancements since a hell of a lot has changed, even newer standards in C, since 1988. (referring to 2nd edition)
And while good intentions were surely behind it, it really went downhill here:
"Drinking Heavily" and "Teh Womenz"
You do not NEED to become an alcoholic or fsck "teh womenz" to be or work as a successful "hacker". You do absolutely need soft skills, friends, some networking and you NEED to socialize and yes, a partner (or partners) can be a wonderful thing in your life and booze does work wonders as a social "lubricant" but these are far from being the only forms of social interaction or positive recreational activities you should invest your time in and, quite frankly, we tend to overrate getting hammer and getting laid.
Learning a non-imperative languages is also vital: most importantly Lisp such as Scheme and a strictly and statically typed functional language with type inference like Haskell or ML.
As for Ruby vs. Python, it's an implementation detail. The languages are close enough as if you know one, you can learn the other when you need to (at a new job, or when there's an open source project you'd like to contribute to). Make sure to be fluent in one, however, as "scripting" is a vital skill (especially if you have to deal with a production environment or build/release tooling).
Same principle as Ruby vs. Python also goes for Java vs. C#. I would, however, suggest learning C++ and/or (one of) Java/C#, as they're rather widely used in industry (and not just for legacy work).
Important thing is understanding the fundamentals and seeing the overall patterns.