Learn Python the Hard Way
learnpythonthehardway.org
learnpythonthehardway.org
It may be too silly for you programmers, but almost every beginner programmers as me would have definitely cam across this resource. This has helped innumberable and I'm sure it will.. Thanks once again.
I am planning to brush up my SQL knowledge in coming weeks and will read your stuff. Already enjoyed LPTHW
The copy an paste option is always attractive, as it gives the impression of writing lots code quickly. But I agree with Zed in that it leads to a false premiss of being productive.
Coding is all about typing in code, not copy and pasting code.
It's actually quite hard to type in lots of code without generating compiler errors. But it is quite easy to just copy and paste code without error.
So the copy an paste option leads to a false sense of coding ability.
I didn't learn with Zed's books, but I did (and do) avoid copying and pasting anything I didn't (don't) understand, and would recommend that approach to any newbie.
Whether it's whitespace, or semi-colons, or brackets. After a couple days of typing everything out, they become second nature and I don't have to worry as much about syntax as I do about thinking in whatever way the language seems to flow.
For someone like me, it would have been really fun when I was less experienced. I would have liked the repetitive challenges while I was doing them, because I would have challenged my self to go through them as fast as a I could and gamify it (though it wouldn't have been called gamification back then). It would have got me to memorize things.
His books are different, I appreciate another take on them. I would read and follow along with his books if they fit my needs now. I've recommended him a couple times to people I thought would benefit from that style.
As to his personality, I think most people are jerks sometimes, and not jerks at other times. We all have our issues. :)
Generally, I feel that all the conversations about it much more harmful to the profession than the original instances being discussed.
Page 4 of the Shaw-Hanselman interview transcript discusses direct instruction.
http://s3.amazonaws.com/hanselminutes/hanselminutes_0407.pdf
Out of curiosity did your SO learn Python and if so what resources worked particularly well?
I tried out a few Ruby classes just for the heck of it, and with Ruby, somehow things fell into place.
How can that be? I remember learning about functions such as f(x) = ax + b in the fifth grade if I am not mistaken and learning about functions in programming was extremely natural. I studied programming in high school taken from the very basic and nobody had troubles with how functions worked. It was so math like that it was simply a non-issue. I am really interested to understand what the problem was and how did she figure it out eventually.
> And his way of teaching boolean logic is to memorize truth tables
But isn't Boolean algebra based on exactly that? Isn't this the pillar field covered by the mathematical logic, how can it be wrong?
From the book:
> Learning logic has to come after you do some memorization. I want you to do this exercise for an entire week. (http://learnpythonthehardway.org/book/ex27.html)
Why would you need to memorize that not true == false? All of the others can be deduced by simple reasoning. One example:
not (True and False)
True and False is False
not (False) is True
The same thing with spending first ten chapters having people write print statements with convoluted string interpolations. String interpolation is a hard concept to grasp for beginners. Unpacking variables before learning about objects, introducing what he calls "commands" like raw_input(), before even mentioning functions. I could go on and on.
If you're just going to remember truth tables, throw those names to the wind. You might as well call them P and Q. But we don't, because OR and AND and XOR make sense.
It looks like he introduces these truth tables (sec 27), where, to be fair, he does say this:
> The terms (and, or, not) actually work the way you expect them to, just like in English.
And then he asks you to practice memorizing the tables until you know them intuitively.
That seems like an odd thing to single out. I took an "Intro to Logic" course years before I did any CS courses and truth tables were very much used. I believe that they helped ease students not accustomed to thinking precisely about logical propositions into that mode of thought. Why rely on students' intuitions about ambiguous natural language constructs when we can be explicit and also provide an early lesson on the precision required by machine languages?
The latest rewrite emphasizes secure coding and defensive programming practices, algorithms, testing, and how to learn a new programming language, and simply uses C in as safe a way as possible to do that. Hopefully it's effective but I still need to sit with students in IRL classes to test that out better.
Python 2.6.5
no use of context managers when working with files
no use of format when working with text formatting and output
"Avoid any project that mentions "Python 3""
"Every if-statement must have an else"
no list|dict|generator|set comprehensions.
no idiomatic hints
no gotchas.
Definitely a hard way.
Having learnt wrong leads to hard learning to do right.
1. "no use of context managers when working with files" - I teach files early on, before they even know how to make a block. After my book they can easily learn this.
2. "no use of format when working with text formatting and output" - Which format? At the time I was writing this there were what seemed like 10 changes to it and how it worked. The % format syntax works all the time, and it's something found everywhere. Learning it is useful, and doesn't prevent them from using format later.
3. "Avoid any project that mentions "Python 3"" - They should, Python 3 is not ready and is simply frustrating. Python 2 is on all of their computers already for many people, so that's the better one for a beginner. Also after learning 2, they can learn 3 if they need, but if they learn 3, they have to learn 2.
3. "Every if-statement must have an else" - This is for training their ability to think of the entire set of possible boolean results in an if-statement. It's also the cause of many logic bugs and you should consider it as a good way to check your own logic constructs.
4. "no list|dict|generator|set comprehensions." - The book is for beginners who can't even figure out how to run a python script on their own. You think they'll get comprehensions? That's insane. Later they can easily learn this, and I think a theme in your comments is that you think once someone reads one book they are done learning, which is a bizarre idea.
5. "no idiomatic hints" - Which idiom would that be? The early Python that's like JavaWithCamelCase or the new Python that's like c_with_underscores? The problem with Python idioms is they warp fairly regularly depending on what's in vogue at the time, so I just teach the simplest thing that seems to be common among all of them. And again, they will whatever "idiom" you think is important later when someone like you who thinks they're important yells at them about it. Brains are not made of stone.
6. "no gotchas." -- The book has loads of gotchas, AND I have videos that go with it where I show people the gotchas, AND there's additional problems for them to solve at the end of every exercise, AND I encourage them to break their scripts to see how Python gives them errors.
You would do well to ditch the idea that people cannot relearn things. Maybe this is holding you back as well, and it's simply false. Heroin and smoking are "bad habits". Playing a guitar scale wrong is a "bad habit". Whether you use CamelCase or loads_of_underscores is just easily updated information.
Later on I was taught some C and x8086 assembly. I needed to forget Pascal. But I didn't get C.
Then I was introduced to OOP and C++ and was pissed off. I needed to forget procedural programming (at that time I didn't even know it was called that). But I didn't get it.
When I started to learn Python I dove deep in its OOP, data model, magic methods, functools, itertools, datatypes, any "writing idiomatic" and "top mistakes python programmers make" articles. When I didn't understand something (and it was a lot!), I walked to read theory about programming approaches, duck typing, functional programming, Guido disgusted by functional programming, difference and tragedy of py2/3 dichotomy, by the way learning a lot about programming, design patterns, computer science and history of all of that.
When I started all my knowledge about programming before learning python this way was just buzz words and almost no real experience.
But learning python this way - the hard way - allowed me to learn programming, its theoretical concepts. When I got stuck with something, I just hadn't move on till I understood everything the right way.
Where do you teach your readers to think right?
And with Python3, you don't have to deal with baffling UnicodeDecodeErrors whenever you deal with real-world data, you get sane standard library names, and a lot of other syntactic warts have been cleaned up.
2. '{}'.format(). besides, print is a function
3. python versions you use as a ref in your book were released more than 5 years ago. All major projects have dropped support for them in favor of python 3.3+. Today it is difficult to find a project that doesn't support python3. There's not so much diff between py3.4 and py2.7. What is frustrating?
4. Occam's razor and K.I.S.S. tell me keep my stack as small as I can. Beginners better learn right principles than "easiness". Show them what's really effective. Programming is 95% mental work, 1% coding, 4% testing/debugging/optimizing. Teacher cannot inject knowledge into student's mind, but he can show the right direction and help make first steps.
5. comprehensions are idiomatic. context managers are idiomatic. Begin from the beginning. Begin from "import this".
6. well, yes. Your "they will learn that later" mantra is one of them.
I ditched the idea that learning programming begins with choosing a language and learning its basics. Instead you go learn KISS, DRY, YAGNI, etc., history of programming languages, stateful vs stateless, and learn this by practice, by exercise, just like playing the guitar. You begin with handling the instrument the right way and learning basics of music theory and once you get the idea of pentatonic scale and bebop you can go practice it, not vice versa. Well, you can play bebop in pentatonic and not be aware of what you're doing, but understanding the underlying theory and alternative approaches is the key to learning more complex things and discovering new horizons.
Relearning is a bad habit. Reusing your knowledge and expereince is a good one.
I think reps are really good for something that uses muscle memory, like shooting 3s or dicing an onion. However, I found for learning programming, I got a lot more mileage out of teaching methods that have set up a solvable problem, point you in the right direction, but leave it to me to create a solution.
I don't think it is useful for a beginner to start with python3.
Python3 simplifies many aspects of the language, for example handling of bytes and handling different encodings. In my day to day use I don't want to miss these features.
Many interesting features where added in 3, like yield from, more powerful generator syntax and the libraries multiprocessing and pathlib.
Even NumPy and SciPy work on Python 3 now, and it's not like there are massive differences between Py2 and Py3 anyway, so generally speaking it shouldn't be hard for a noob to revert to Py2 if it becomes inexplicably necessary.
It's time. All new code should be in Python 3.
It will happen someday, but not yet.
The majority of python code on my computer is now python 3.
I have a few smaller projects I have started since then - I used Python 3.
There are very few noticeable differences. Why would you not start with a more up to date version. Unless there are specific packages you need or expect to need that are not supported I would say Python 3 makes more sense.
In his explanation of classes he has several paragraphs about old-style vs. new-style classes, ending it with:
"Just completely ignore the idea of old style versus
new style classes and assume that Python always requires
(object) when you make a class. Save your brain power for
something important."
Another example is his advice, in exercise 11, to avoid the input() function because of its security problems. Python 3 doesn't have that function, so the beginner doesn't have to remember to avoid it.
And of course, there's Unicode, which this book seems to completely ignore. A beginner starting with Python 3 has to learn the "Unicode sandwich" approach[1], which applies very well to Python 2 code as well. But someone starting with Python 2 can easily be confused about the concept (because the language is confused) and will have a hard time getting things to work correctly. For example, the book recommends that people "from another country" set their source encoding to UTF-8 – good luck printing things on Windows.
[1] Obviously your experience may vary depending on which modules are considered essential for your work.
Also, all my Python sources are set to UTF-8 and I never had any problem in Windows. Notepad.exe gives you the encoding option when you save a file, and every sensible text editor/IDE gives you encoding and line feed options.
So what would be the problem with Zed's tip? Have you ever tried to run a Python script with special characters? The interpreter dies instantly with an encoding error. It's easier to set the encoding to UTF-8 and get the program running than parse the whole thing checking whether you used a special character in the comments -- which shouldn't affect program execution, but hey!. Also, this way you can write meaningful comments in your native language without worrying if it'll kill the interpreter right away.
For example, let's say our Other Country is a Western European country. The encoding for non-Unicode Win32 programs will be Windows-1251 (more or less ISO 8859-1) and the encoding for MS-DOS programs and the commandline will be codepage 850.
In this scenario, this Python 2 program (saved as UTF-8):
#-*- coding: utf-8 -*-
print "ångström"
To make it correct, you can apply the Unicode sandwich approach:
1) Know the input encoding and decode from that to Unicode.
2) Process the text as Unicode.
3) Know the output encoding and encode into that encoding on output.
In other words, making it a Unicode string will transform the text from whatever encoding you chose to write the file in to whatever encoding your terminal happens to use, so this program will always (if the system is correctly configured) print the right thing:
#-*- coding: utf-8 -*-
print u"ångström"
print("ångström")If anyone is best in the position to take up the bleeding edge with no thought to backwards compatibility, it's the people just starting out. They're the ones who, by definition, don't have legacy code to maintain.
True beginners don't need to use numpy and run a bunch of production-ready libraries. They first need to learn what libraries ARE and the basics of using them. Besides, numpy &c. can already run on Python3, how much further will they be along in 1-3 years? Most simple Python3 programs work fine in Python 2.7.9 with little wrangling, and it's not hard to keep two installs of Python.
"Learn Python" right now means "learn both", only many introductory tutorials will refuse to teach both. Instead they'll compound your frustration by making you learn the intricacies of Python 2's print statement instead of print().
I tried that for about a week before discovering that about 90% of the libraries that I wanted to play with, and 90% of the tutorials and StackOverflow answers that I found were 2.7-specific.
The vast majority of code out there is in Py2, so if someone learns Py2 first, they can start coding and doing stuff right now. If they stumble onto a need for Py3 later, then they would have the skill to learn Py3 from the tutorial and other books.
If they learn Py3 first, then immediately they have to learn Py2 because there's simply too much code out there that uses it. This will frustrate beginners as the next thing they need to do after my book is start using Python to make things.
When the situation changes, and not just because the Python leaders say it does, then I'll update the book. Honestly though, I think Go, Rust, Nim, and Clojure have a better chance at widespread adoption than Python3 at this point.
Incidentally, the mistake that the Python3 project made was to not use a virtual machine that could run both 2 and 3 byte code. If I can run tons of languages on my CPU, the JVM, and the .NET CLR, then Python3 could have run both 2 and 3. I predict that to get people on the new version of Python they will have to make Python4 and have it run 2,3 and 4 seamlessly so that it won't matter how much code is out there in any version of the language.
Just my .02 on that topic.
http://hanselminutes.com/407/learning-code-the-hard-way-with...
I was a violinist, and Zed Shaw's way of teaching the basics completely resonated with me.
Thank you, Zed.
Basically it should really be called Learn Programming The Hard Way Using Python
I started looking at other books and found "Learn python programming arcade games with pygame"by Paul Cramel, who is teaching his own book at an university course.
For me it's sooo much clear, taking you step by step through the difficult concepts (hand holding if you wish), that suddenly are not that difficult. It contains lots of simple exercises and questionnaires that make sure that you understand the concepts in the lesson. Each lesson has also it's own Lab, that gives you the specs and making you use the lesson material to code on your own. I find this to be the perfect way to fix the ideas in a practical way. I don´t know enough to create my own exercises' specs being a complete newbie.
Of course making games and moving drawings is hands down much fun than writing command line scripts.
It only has a small problem, you need to install pygame's libraries, which can be a bit difficult in mac. I had to do several tries with snow leopard, Finally I installed the latest Mac OS and it installed without problems.
I'm recommending it to every body who asks me. It's free in his site and the e-book(that I bought) it's inexpensive.
I´m sure LEARN PYTHON THE HARD WAY is and will be useful to a lot of people, and don´t mean to disrespect the author effort in helping people learn programming, but I thought worth giving an alternative in case you are looking for one.
I´m not related in any way to Mr. Cramel, I just happen to find his book very useful.
This thread is proof that programmer types need their share of celebrity gossip as much as anyone :)
"That Zed Shaw. He's abrasive, but is he too abrasive? Tune in to our panel discussion to find out!"
"If you are reading this book and flipping out at every third sentence because you feel I'm insulting your intelligence, then I have three points of advice for you:
1.Stop reading my book. I didn't write it for you. I wrote it for people who don't already know everything.
2.Empty before you fill. You will have a hard time learning from someone with more knowledge if you already know everything.
3.Go learn Lisp. I hear people who know everything really like Lisp."
"> is this a joke?
No, just written by Zed Shaw. Honest mistake though."
How about you let go of the hate and embrace some love instead for the work this man has put forth?
LE: For advanced Python you can read his code from the Lamson project. I am sure there are many other coders out there who are just as talented as he is but he takes the time to comment his code and also has a style of clarity so to speak. Thank you Mr. Shaw for your work and thank you to all of the amazing, talented coders out there who gave me confidence and helped me to learn.
In an industry as opinionated and "willing-to-call-you-out" as tech is, that doesn't always win a lot of friends.
Or, did I miss some implied sarcasm??
Does it win these journalists friends, or followers? I suspect the latter, but in the celebrity industry, they're probably the same thing.
Honestly, I think this is the other way around. People get defensive and call him names when he is pointing clear mistakes / bad practices. Of course you get frustrated when someone calls you names and it's natural to pay them back in their own coin.
That said, Zed seems like a good guy at heart, I have seen him offer help to people out of nowhere both here on HN and on Twitter. Not to mention making most (all?) of his Learn the Hard Way material for free. So while I don't particularly care for his communication style I don't want to distract from the fact that he is also doing a lot of great work that genuinely helps people.
I don't drink at all. Never done drugs and have never been drunk or anything. When I go to bars with friends I find that as the night goes on people become complete drunken idiots and are impossible to deal with. There's no polite way to tell a guy to stop talking to you about his chia pet collection or to keep someone from puking on your shoes or trying to start a fight. Best solution is to just not go to bars, which is what I do. If I need to fit in for some reason, I usually just pretend I'm kind of drunk like everyone else, which I haven't done since I was in my early 20s.
Twitter, these HN comments, IRC, the whole internet is like a massive bar full of drunk idiots. Especially toward the end of the day. Something about the internet makes people turn off their rational mind and just spew hate, stupidity, propaganda, and lies. In this case, it's the same interactions and I get tired of it. You can't tell a belligerent drunk to politely stop smashing your car any more than you can tell a belligerent twitter user to stop talking to you.
So, your comment amounts to judging my interactions with people professionally based on my interactions a bunch of drunk idiots at a bar. Nobody is a saint, and expecting me or anyone else to take abuse and poor behavior like Jesus before you'll think they're a good person is wrong.
And, the fact that you are actually spending your morning (day/night) telling people how I'm a fucked up asshole because of how I deal with fucked up assholes kind of says more about you than me.
Why am I spending my time today on this conversation? Because you've become reasonably influential (and certainly for good reason, mongrel, learn the hard way, etc) and because of your influence someone might say hey if I'm a good programmer it might be reasonable to have a short fuse with people and tell them to go fuck themselves because Zed Shaw does. And I want to use this space to say, hey I hope we can be nicer to each other. That's it. I really don't want it to be about anyone in particular, I just hope since programmers work with each other and write about each other's work on the internet we can be considerate and try to be nice to each other even when we're being critical.
Also, how and when is he arrogant? When he is being called names over and over? And just now you've insulted him saying he doesn't understand OOP. You know Linus Torvalds is not very fond of OOP as well, right?
Always use OOP where it makes sense. I don't think he ever argued that.
The laws of politeness are like the laws of war: once you violate them you forfeit their protection.
> You know Linus Torvalds is not very fond of OOP as well, right?
I would emphatically advise beginners not to listen to Linus Torvalds, and be very concerned if he started writing programming tutorials for beginners.
> Always use OOP where it makes sense. I don't think he ever argued that.
I'm thinking specifically of http://learncodethehardway.org/blog/AUG_19_2012.html as that was where I first encountered him. This article is a) something he wrote by himself, not in response to being called names b) self-confident and abrasive in a way that I think it is fair to describe as "arrogant" c) wrong, in a way that seems to reflect not understanding polymorphism - particularly given his replies in the HN discussion of that piece.
Lest they might learn something?
I'd recommend beginners listen to a wide variety of "big names", but only those who are clear about the scope and limits of their experience.
You're not doing yourself any favours by so confidently making abrasive comments about Zed based on that.
This comment doesn't sound very modest either.
>In particular he doesn't understand object oriented programming (look at the piece he wrote about .each vs for in ruby)
Actually nothing in what he wrote (in Learn Ruby the Hard Way) about each vs for is related to object oriented programming.
Nor is there any particular indication that he doesn't understand OO (which, I'm sorry, but sounds ridiculous as an accusation). He might not be some prodigy, but he's a senior programmer with a lot of experience building systems in different langauges, and OO programming is not some mysterious researchy thing but a tired old industry staple than programmers with 1/10th his experience can grasp...
Zed also pointed out some genuinely bad stuff that was happening in the rails community in: http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto which made them more angry.
Edit: a user points out below that post came before the ZSFA site. I'm not sure that matters.
He also claimed Ryan Dahl ripped off Mongrel's HTTP parser. The flip side of this (which I've heard from someone else involved in node) is that Ryan Dahl is super talented and just read the damn HTTP spec like Zed did. I honestly don't know enough about HTTP parsers to say either way.
Zed's talented: Mongrel and Lamson are in the top of their categories. Learn C The Hard Way is a modern, but still fundamental C book. Any interaction with Zed I've ever had has been brilliant.
[1] The people who got angry at ZSFA in the late 2000s are probably the same people who write Jenn Schiffer angry tweets for writing tech satire these days.
The "Zed's so fucking awesome" follows the Rails is a Ghetto post, and the start of acrimony between Zed and other members of the Rails community, and so was more of a consequence of the aforementioned acrimony than it was the cause.
The context in which everyone was relating to Zed was the dude who wrote mongrel who did an about face and not only left the ruby community but decried it all the way out.
Remember this was in the heyday of Ruby on Rails's rise, twitter was still using mongrel as their primary web serving mechanism.
When you spew that much anger into the world you're going to rub people the wrong way and concern others that if things start to go slightly south you're next to go on the shit list.
I already feel like I'm posting too much in this thread about a particular individual that I've only had a few interactions with on Twitter, but as a programmer it's extremely important to me that discourse between programmers is considerate. If you can't or won't express yourself without endless anger and personal insults, why is it the responsibility of other people to be patient with your tantrums?
Yep, it was more a criticism of people's behaviour than rails itself.
And then I was trying to be funny and shit.
I have found him to be contrarian and rude for the sake of being contrarian and rude.
To me, his behavior represents the worst of the archetypal 'rockstar' programmers I have worked with -- perhaps more skilled than the average, but full of himself, unreasonably mean and impossible to collaborate or work with. I have watched this kind of attitude destroy teams and companies and I prefer not to condone it.
There are plenty of people much more talented than him who are capable of providing feedback without seemingly delighting in being an asshole.
I am a stranger to this feud, and knew nothing about Zed Shaw to this day. I have no chips in this discussion. The opinion I express is more of a generic attitude on life.
Consider the message "NUTS". It was a "legend of World War II" on the US side. (Quoting from https://news.google.com/newspapers?id=XxAdAAAAIBAJ&sjid=CJsE... .)
It clearly does not stand on its own. Without knowing the author, or the context, it's impossible to explain why that message resonated so deeply. (Eg, I seem to recall it being reappropriated in one of the early Star Trek novels.)
The message metadata gives some idea of the context:
December 22, 1944
To the German Commander,
N U T S !
The American Commander
If I write "NUTS" here, does it have the same meaning and interpretation as when McAuliffe wrote it some 70 years ago? Assuredly not.
A technical book, which condenses technical knowledge, has most of its content in the lines, not between them. There is no second reading of the book, there is no hidden meaning, there is no need for secondary information for interpretation of the text.
If you feel more comfortable viewing the subject under a reduction to the absurd lens, think about criticizing a published mathematical proof based on the opinions about the author's personality. The proof is either valid or invalid, and all the information needed to prove its validity must be contained in the proof (or it is invalid).
Your examples are not relevant, as they are not designed to be complete. The first is a view of an ancient text through a modern perspective, and the second is a fragment of a communication ensemble. A technical text, unlike these, is designed to be complete. I stand by my original position, although I was perhaps too broad in painting it. I didn't expect it to be read as extensible to literary texts.
As for "designed to be complete", I don't know what that means in this context. Perhaps you mean stand-alone, as it does not depend on having access to other resources? Otherwise, the only definition I can come up with is tautological, as it covers everything the author meant it to cover. A technical book on "advanced differential equations" is not complete in that it assumes the reader already has a basic understanding of differential equations.
I have read many technical papers. They are still human documents. They can and often do contain meaning between the lines. I am reviewing some of the literature in my field from the 1960s, and it's easy to infer the social context. For a simple example, in most of the papers refer to a generic chemist as 'he' and clerical staff as 'she'. More subtly, there can be veiled attacks, like when one paper says "it's surprising that X and Y are connected" and then a paper a few years later says "as many of the people who founded X came out of Y, it's not surprising that there's a close connection between the two". It's not hard to read between the lines and infer that the second author is chiding the first author for not knowing the history.
More classically, in 'Dialogue Concerning the Two Chief World Systems' Galileo put the words of Urban VIII into the mouth of the character Simplico. The pope and many others interpreted that as a hidden attack on the pope, despite being a book on scientific ideas.
Have you never come across mathematical proofs written by kooks? The language, and frequent references to numerology and other occult philosophical traditions make it effectively impenetrable. Unfortunately, I can't find one easily. Visit your local math department and ask around - it's not uncommon. Sometimes much more sane versions of these get published, like http://www.math.utep.edu/Faculty/sewell/AML_3497.pdf .
In any case, math proofs are supposed to be interesting. Otherwise we would just hook up a theorem prover to a journal publisher. If you look at the early papers in statistics, they use games of chance as examples. Sure, the proofs stand alone, but from the text you can also determine that gambling was not strictly taboo during that era.
BTW, I agree with the statement that none of Zed Shaw's internet persona is evident in this book. By all accounts, it is a good resource for learning how to program. In my cursory scan, I found no hidden or double meanings. However, that's a specific property of this book, I disagree that that's true of every arbitrarily chosen technical book.
A body of work around a certain subject that lots of people study and use in their professions is different. It should be judged without the author in mind, otherwise how are you going to remain neutral and form your own calculated reality of how it works when you review work by other authors?
I've been watching archeology videos recently. The archeologists are not neutral on what how to interpret their finds. They use their non-neutral viewpoints to help guide where they work next. They are also well aware that the views of their profession have changed over time, and that those views can reflect implicit personal and cultural biases.
In this case I do not think Zed Shaw's personality outside of "Learn Python the Hard Way" affects the interpretation or use of that book. But I think Galileo was foolish for putting the words of the pope in the mouth of the character Simplicio and expect the pope and his supporters to remain neutral.
Dont judge a books value by your opinions of the author.
I don't agree w/ Zed on everything, but i have benefitted from his work for literally a decade now: mongrel; his early writing on why programmers should learn statistics; his writings on the types of collaboration/projects programmers are involved in; Learn C The Hard Way; his various talks.
A good read, here's the link for lazy - http://zedshaw.com/archive/programmers-need-to-learn-statist...
Funnily enough, I actually knew Zed before he became "Zed" (we were both team leads for related organizations). He came off as one of the more caring and right-headed leads that I'd known at the time.
Things change of course (it's been years), but I wouldn't infer too much about what he'd do to a team from his internet persona.
There is a vital difference between "contrarian and rude" and "contrarian, rude, and right."
The latter doesn't erase the two former, but his code compiles and as far as I can tell his software works, which is at least worth mentioning.
Disclaimer: I don't have a horse in this race, know 0 of the principals involved, couldn't write FizzBuzz in Ruby, etc.
Sure, Linus has written and maintained an OS, but as others have pointed out, Zed's CV isn't too shabby, either.
Its also why people say they "hate" a politician, leader, or band without listening to one word they say or believe snippets represent the whole of a person. The group think spreads quite nicely. At the end of it all, there is so much information and we have so little time, we outsource some of our beliefs. Comedians tend to use this to craft some jokes and sometimes abuse folks. For example, President Ford slipped a couple of times in slick shoes. Chevy Chase made him out to be a klutz and un-athletic on SNL to great merriment. President Ford was probably the most athletic President the US has had. He played linebacker in American Football and was consider a decent athlete.
My Dad was not a fan of this and did tend to scold his children that "if we were going to hate someone, we better damn well know why". I do admit to failing at this since there is so much, but it is a good lesson and tends to result in new joys.
I actually asked one of his colleagues what it was like working with him. Words like "quiet" and "pussy cat" were used. They said he has strong opinions, but is never contrary for the same if it, and is often just quietly sitting in a corner listening.
I personally would love nothing more than to have the industry flush everyone who behaves like that totally out of it, but as long as people like you hold those with no power to different standards than those with power, it'll never change.
I've seen enough of these threads on Hacker News to know the answer is clearly "it's different because I don't like him."
Zed wounded a lot of egos back in the day, so calls for positivity that may otherwise work on HN are going to fail. By framing him as a "controversial figure" they attempt to create a route to hate on him that doesn't count as shit talking.
Zed wounded a lot of egos back in the day, so calls for positivity that may otherwise work on HN are going to fail. By framing him as a "controversial figure" they attempt to create a route to hate on him that doesn't count as shit talking.
I don't know of anyone else in tech who's had that experience, ha.
I found this course useful. But not as useful as some others. Learning the basics were easy enough, but Zed kinda tripped over with the harder topics such as OOP.
Overall, it's a good place to start programming if you've never done it before, but you will need to look elsewhere for clarity if you want to make sense of anything beyond If-Then statements and while/for loops
Anybody who knows C should read this thread: https://news.ycombinator.com/item?id=8834869
The take aways are that Zed doesn't understand C and hasn't read the C standard. He even takes pride in his lack of knowledge of the fundamental concepts that you need to understand to write correct C, and mocks those who do take the time to learn about the standard. Such a person should not be writing a book to teach C to beginners. People following his advice are going to write code that is dangerously incorrect. (If you want to take the position that C is insane and nobody should use it then that is fair enough and hard to disagree with, but in that case the honest thing to do is to encourage people not to use C; don't write a book teaching dangerous practices to beginners).
Since I don't know Python I have no way to know if he takes a similar attitude towards Python. What aspects of the language does he ignore because he is too prideful to read the standards or documentation? Given what I know about his attitude towards C, I can't trust him to teach me the things I would need to know to use Python correctly and safely.
As a professional educator myself, I strongly disagree with your sentiment about "teaching dangerous practices to beginners". By far, the biggest "danger" to beginners is that they won't learn how to code at all or get frustrated and quit because of pedants.
Do we teach beginning drivers using 18-wheeled tractor trailers? Or using F-15 fighter jets? No, we use cars with automatic shifting driving around in an empty parking lot at first.
I suppose I'm in a different position than you though; I don't see any need to get everyone to start coding. I think if people want to code there are already good books out there, and if they don't then I don't think we need more developers who hate their job.
The person I was replying to just didn't seem to understand what anon1385 was trying to say; it's difficult to recommend a book written by someone who writes and teaches on topics he/she doesn't fully understand. There was a link to a thread where the author of a book on C was wrong about one of the fundamental aspects of the language.
Again, I don't have the slightest idea whether there is wrong information in any of the author's books, but I can also see why one would be wary trusting a book written by someone who has shown a serious lack of mastery on previous occasion.
I believe the person I was replying to misunderstood the cause of concern as being one where a person is taught poor or suboptimal practices as opposed to one where a person is taught things which are just flat out incorrect.
I actually found youtube tutorials,videos,and codeacademy to be far more interesting and effective.
I don't think I would recommend a book to a pure beginner anymore, places like code academy have matured to be far better.
Yep, that comment thread is great and people should read it for an explanation as to how completely insecure C is. It made me realize that nobody can teach C safely. Not me, not K&R, nobody. The language is completely unsafe by design. If you think K&R could, you should realize that they fixed the code in the book numerous times to make it more secure during it's 40+ printings.
Based on that, I killed my darlings. I should have never started this book as a "C book". I rewrote about 50% of it to instead focus on the things a mere mortal like me can teach:
0. How to learn any programming language quickly with some tricks I know.
1. Secure programming and defensive coding skills, which a broken language like C is perfect for teaching.
2. Testing and reliability.
3. Most of the C I've found safe and useful, and how to avoid UB when possible.
4. Algorithms and how to apply them.
5. And finally building projects as small challenges to get better at C.
https://github.com/zedshaw/cubfail
I'm currently finishing up a book, but this project interests me because what I've seen is most "professional" C programmers end up pulling out UB whenever they are called out on a secure coding practice they fail at. I think a good catalog of how to cause security failure with C UB would be instructive to everyone.
And then we can all just stop using C. It's terrible.
Now that you have this new information, hopefully you'll update your slander.
We are all wrong at times. There is no shame in that. But finally admitting fault after months of intransigence (I'm taking about from the launch of the book, when people first started criticising it, until that thread) doesn't excuse your behaviour prior to that. With a bit more humility from the beginning none of this would have happened. If you are going to pick a fight with people, C language lawyers are probably about the worst target.
I don't care about "winning" the argument - just about everybody already agreed that C is highly unsafe, and personally I think K&R is quite outdated now, since it doesn't dwell as much as it should on all the dangerous and difficult aspects of C. Much like C itself, it generally assumes superhuman competence on the part of the reader.
Putting that aside, I do think we are lacking in resources that teach people about the many pitfalls of C in one place (if only to scare people away from the idea of using C for anything network facing). Especially in an era when a lot of people learning C are probably already familiar with the basic syntax and control flow, through knowledge of Java or other languages, and will thus probably be tempted to skim through beginner C books. People coming from that direction probably find C deceptively familiar, and aren't aware of a bunch of things like the undefined behaviour of certain integer overflows and shifts, or the strict aliasing rules, or possibly even reading uninitialized variables.
John Regehr has a lot of good blog posts on this topic:
http://blog.regehr.org/archives/1054
http://blog.regehr.org/archives/1136
http://blog.regehr.org/archives/959
As you can see in some of those examples UB can be very difficult to spot, even for experts like compiler engineers or crypto developers who are intimately familiar with the rules. Also some things are just plain tricky to do correctly and efficiently (e.g. http://blog.regehr.org/archives/1063) and in the past compilers were much less aggressive about optimisations that affected code containing undefined behaviour. So you could get away with it, and incorrect code became the accepted way to do some things. This resulted in a lot of gnashing of teeth and a few well known security vulns when old code started to break with newer compilers.
If you are looking to catch bugs and undefined behaviour in test cases you should certainly look into the -fsanitize options in clang. This post gives an introduction: http://blog.regehr.org/archives/905 and the up to date docs are here: http://clang.llvm.org/docs/UsersManual.html#controlling-code...
This statement is quite unfair. I have read the code from Mongrel2 and I've learned things which completely eluded me in the past. Have you considered that he is actually a human being which can be surprised at how an old book can present aspects never noted before?
Just because he hadn't thought about that particular language horror side effect doesn't mean he doesn't understand C. C can be manipulated in horrific ways, such as a psychopath can absolutely horrify you. That doesn't mean you don't understand life for example.
And no, he doesn't mock people who read the standard. The discussion was entirely about something else. He proposed an improvement on how to handle strings and how the original K&R code should only be looked at from a didactic POV and not production level quality.
That is what I saw in that thread.
Allow me to quote for you, since this comment[1] was downvoted to the bottom of that thread and maybe you missed it:
Ahhh the "undefined behavior" trope, whereby a C "expert" who's memorized a standard trots out the abstract machine to justify his point. An abstract machine that doesn't actually exist and that no computer actually functions as.
>Just because he hadn't thought about that particular language horror side effect doesn't mean he doesn't understand C.
No, really. Somebody who isn't aware of undefined behaviour can't claim to understand C. The fact that he has now changed his position on the entire language (now advising people not to use it, advice I broadly agree with BTW), indicates that he wasn't aware of these things prior to that discussion.
Just because he hadn't thought about that particular language horror side effect doesn't mean he doesn't understand C
But UB is such a key aspect, if you don't understand in full what it is, I'd say you do lack some understanding of C?
And no, he doesn't mock people who read the standard.
It is open to interpretation, but you should admit his Ahhh the "undefined behavior" trope, whereby a C "expert" who's memorized a standard trots out the abstract machine to justify his point. is rather snarky
People who know C are not the primary audience for Learn C the Hard Way. Every programming tutorial aimed at beginning students puts the student on a tricycle, points them toward a cliff, and tells them to peddle as hard as they can.
Norvig points out the cliff is always there.[1] Zed Shaw starts 50 lessons away from the edge. How to Design Programs puts the student at a different distance. Instruction for advanced students [working programmers] expects the student to know they are headed for a cliff.[2]
The last compound type that we shall consider in this
section is the record type. Records are quite similar to
Pascal records and to C structures (and to
similar features in other programming languages). A
record consists of a finite set of labelled fields, each
with a value of any type (as with tuples, different
fields may have different types). Record values are
written by giving a set of equations of the form l = e,
where l is a label and e is an expression, enclosed
in curly braces. The equation l = e sets the value of
the field labelled l to the value of e. The type of such
a value is a set of pairs of the form l : t where
l is a label and t is a type, also enclosed in curly
braces. The order of the equations and typings is
completely immaterial | components of a record are
identified by their label, rather than their position.
Equality is component-wise: two records are equal if
their corresponding fields (determined by label)
are equal. -- Introduction to Standard ML
[2]: http://www-plan.cs.colorado.edu/diwan/class-papers/ML-doc.pd...
Also, the puritanical American allergy for "profanity" under the thing guise of "professionalism" doesn't mix well with mr. Shaw's somewhat direct methods of communicating.
I'm with you. The man cares and, for all of his supposed abrasiveness, he's a good communicator. He's smart and he's not afraid to bring out the honest truth (e.g. "Programming, motherfucker") about an issue.
http://amix.dk/blog/post/19574
If you're looking for what's popular, check out
Because a bunch of people voted it up because it's relevant and useful to a bunch of people even though it's been on HN before. Can you believe it?
I'm pretty sure a beginner has no idea what "public static void main(String[] args)" means.
you've got to start somewhere.
No, just written by Zed Shaw. Honest mistake though.
> Sometimes people who already know a programming language will read this book and feel I'm insulting them.
Especially as the GP has already referred to the intro, which you have supposedly already read.
So let me point it out for you again: http://learnpythonthehardway.org/book/intro.html
He goes into great detail arguing why he thinks this is one of the best ways to learn something completely new quickly and efficiently.
How is this a useful way to approach things? He compares it to learning to play guitar - if my first guitar lesson consisted of "Open your guitar case. Take out the guitar. Put it back.", I'd ask for my money back!
And this tutorial is not meant for snotty CS program graduates, which again is explained in the introduction, which you to this time refuse to read and understand.
If you have a teacher worth his salt, he will have you open the guitar case and teach you about what the instrument is, what its parts are, how you are supposed to handle it and take care of it. At least that is what my trumpet teacher taught me when I started out.
If the first lesson in an introductory guitar book was how to properly handle a guitar, I would not be surprised at all. In fact, I know from experience with other instruments that that would be entirely normal.
This is for beginners, and it helped me a lot when I was starting out. It's not perfect, but it's a great way to get started.