If you're already a programmer, it's not for you. If you're not already a programmer, no, absolutely it is not a joke. Having taught people to program for many years it's some of the best advice I've seen.
The first lesson literally consists of "run python interpreter, then quit".
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!
Everybody goes through a stage where they have no idea what anything on their computer screen means. Some of them have the luxury of having a mentor walk them through and teach them the ontology of "the computer". Similarly one needs to learn the ontology of "computer programming".
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.
I tried teaching my little brother to program using the Ruby version of this book. The lessons were really basic but he still struggled.
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.
"A programmer may try to get you to install Python 3 and learn that. Say, "When all of the Python code on your computer is Python 3, then I'll try to learn it." That should keep them busy for about 10 years. I repeat, do not use Python 3. Python 3 is not used very much, and if you learn Python 2 you can easily learn Python 3 when you need it. If you learn Python 3 then you'll still have to learn Python 2 to get anything done. Just learn Python 2 and ignore people saying Python 3 is the future."
I don't think it is useful for a beginner to start with python3.
Nearly all packages are ported to python3.
There are still some bigger projects missing, but these are exceptions and not the norm.
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.
Well, this quote is a little pessimistic because now almost everything is either Python 3 compatible or has been replaced with something that is and it's only been 7 years. :P
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.
A beginner will want to read and write files pretty early on. In Python 2 it's very easy to e.g. ignore that you need to pass the 'b' option for reading binary files and write scripts that seem to work, and then silently corrupt data when run on windows. Which is not a good experience.
I have my main work database / Django project in Python 2.
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.
Python 3 is useful for a beginner to start with because they don't have to learn the deprecated cruft that Python 2 preserves for compatibility. If they just learn the Python 3 way of doing things, it generally works in both 2 and 3.
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."
Python 3 only has new-style classes, so the entire explanation could have been left out, allowing the beginner to, as he recommends, focus on more interesting things.
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.
No one's saying that Python 3 doesn't improve on Python 2 in significant and tangible ways. The key phrase is "If you learn Python 3 then you'll still have to learn Python 2 to get anything done" which is absolutely true in my experience.[1] This is because as soon as you hit a single dependency that doesn't support Python 3, you have to switch to Python 2. And there are still a good number of important modules that are Python 2 only. (And no, reimplementing the functionality of dependency oneself is not an option for a beginning programmer.) And even if all the modules you need right now are available for Python 3, you might find later that the new feature you want to implement in an existing program requires a Python2-only module. No matter how great Python 3 is, and how much we all wish we could switch to it, we can't just will all our dependencies to add support for it.
[1] Obviously your experience may vary depending on which modules are considered essential for your work.
I'm from "another country" and I always asumed all the characters that couldn't be printed on screen by Python were cmd.exe's (and powershell) fault for not handling Unicode correctly, not a Python "error" per se.
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.
The problem isn't extended characters in your Python script, it's how your Python script handles extended character data. Scripts written in Python 2 that ignore the existence of Unicode won't always do the right thing when they encounter non-ASCII strings in the wild.
The problem is that the Windows commandline, legacy Windows programs and modern Unix systems all use different encodings, so any particular string of bytes (representing non-ASCII text) will only be correct on one of them.
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"
will print the wrong thing – "├Ñngstr├Âm" if you run it from the commandline, and "Ã¥ngström" in a more Windowsy context (e.g. if you're writing it to a file and reading it in Notepad).
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"
In Python 3, UTF-8 source encoding and Unicode strings are the default, so the correct program becomes simply:
Wouldn't this argument preclude using anything new, ever? Don't use C++14 until all of your code is converted to use it. Don't touch ES6 until you throw out your legacy JavaScript. Some of these programs haven't been updated to use Linux-specific features, so let's all stick to UNIX System V.
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.
That nearly all good intros to Python for non-programmers insist on teaching only Python 2.x, because Python 2.x is what's used in lots of advanced programs and production code, is an attitude that I've found very unhelpful as a beginner.
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().
Is anything? I've recently decided to start learning Python and started with the assumption that Python 3 would self-evidently be the sensible thing to do.
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.
I have to serve the student's needs before any in the community, and there's a very practical reason for going with Python2:
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.
If you're new to programming, it's pretty good. If you're an experienced programmer looking to pick up python, then it is very slow going and takes a while before it gets anywhere interesting.
Basically it should really be called Learn Programming The Hard Way Using Python
Yep, this is exactly right, although I'd say it almost totally teaches programming. The book definitely teaches computational thinking and gets people over that hump and into finally learning programming, but I need to work on a follow-up book that has a lot of projects for people to tackle on their own. That's really where they finally learn to code as an independent programmer.
But here's the thing: LPTHW isn't meant for "experienced programmers", it's for raw beginners who have never written a single line of code before. Zed explains this over and over again in the intro to the book.
As a raw beginner that tried this book as the first I'll say that it's frustrating to try to learn with it. It explains something pretty well and then suddenly there is a big knowledge jump that you must fill looking at internet (I had to check the python documentation several times to understand what was happening at some examples).
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.
Wow, how come Zed Shaw manages to attract so much hate? I have found his series to be absolutely delightful. Anytime something about him appears on HN I can be sure there will be users with ad hominem attacks like this:
"> 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.
Zed can come off as defensive and/or abrasive. If he disagrees with you he's not afraid to tell you you're an idiot, and if he feels like you're attacking him he'll tell you to go fuck yourself. He's also very, very staunch in his beliefs, some of which are somewhat contrarian.
In an industry as opinionated and "willing-to-call-you-out" as tech is, that doesn't always win a lot of friends.
No sarcasm intended. I live a very sheltered life and in my circles, bad manners gets people cut off, ignored and relegated; certainly doesn't win new friends. HN is pretty much the only place I don't bother with manners.
Does it win these journalists friends, or followers? I suspect the latter, but in the celebrity industry, they're probably the same thing.
> If he disagrees with you he's not afraid to tell you you're an idiot
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.
Zed is abrasive, and I don't think I'm a particularly defensive or indirect person. I don't think the issue is that he's willing to be direct with people, it's that he's too quick to tell people to go fuck themselves. A lot of communication issues are misunderstandings and in my experience Zed would much rather tell you to go fuck yourself than listen and figure out what the misunderstanding is. The very best teachers and communicators I know don't hesitate to tell you when they disagree but would almost never literally tell you to go fuck yourself, they find a more polite route.
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.
You're conflating internet interactions with real interactions.
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.
I disagree with you about the internet. My bet is we're still learning what proper etiquette on the internet is. You have a great point about people not knowing when to let up online, but I also look around and see both the net etiquette evolving and the commentary on it evolving and to me that is a sign we're getting better.
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.
He's arrogant and rude about it, which is bad enough when someone is right and worse when they're wrong and trying to teach beginners. In particular he doesn't understand object oriented programming (look at the piece he wrote about .each vs for in ruby), but is too arrogant to realise that there's something he's missing, so he goes on these sweary rants about how OOP is nonsense/useless/evil/what have you. In any programmer that would be bad. In someone who purports to teach beginners it's disastrous.
I have no idea what are you talking about regarding OOP issues. From the Lamson project you can see he is using OOP.
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.
> And just now you've insulted him saying he doesn't understand OOP.
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.
Because he has a lot of experience in one very specialized area of programming which very much doesn't reflect the wider profession. It's the same problem as e.g. http://codon.com/the-dhh-problem
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.
I just read the each vs for part and I don't see anything wrong with it. He's saying it's easier for beginners to grasp the for loop and it's also a pretty universal loop. What's wrong with what he said?
Frankly, after reading that piece, as a Ruby developer that does decidedly prefer "each", I see nothing wrong in it. I also don't find it remotely abrasive and don't see any of that self-confidence (since when is that bad?) you seem to have a problem with. I don't see any arrogance either.
You're not doing yourself any favours by so confidently making abrasive comments about Zed based on that.
>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 had a satirical site called "Zed's so fucking awesome" mocking the whole 'Ruby rockstar' thing in the late 2000s. A bunch of people didn't get the joke and got really angry at Zed. [1]
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.
re [1]: This is not an accurate reflection of the events and circumstances at the time.
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.
It does make a difference because Jenn's rise to general attention has been through her satirical and artistic work (as well as the fact that she's an awesome developer who worked at the NBA and now works for Bocoup).
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.
That Rails is a Ghetto piece is filled with personal insults, gripes, anger, accusations that people are slighting him or intending to slight him. There seems to be one critique of Rails buried in all that, that DHH may have been running a Rails app that required many restarts a day. I only had the patience to get through the anger and the personal stuff because I really wanted to actually read the piece before I replied to your post.
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?
No, the relevant fact in RiaG is that DHH had been lying to people for years claiming that "rails scales" when he had to handle 400 restarts a day of his process.
You should consider if there may be a good reason why he attracts so much hate.
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.
We should be able to evaluate a book, a finished product, irrespective of its author. It is not acceptable to diss a body of work because the author is "contrarian and rude for the sake of being contrarian and rude". Either the book is good, or it isn't. It stands on its own.
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.
I see no reason to accept your strict view of aesthetic interpretation. Borge's 'Pierre Menard, Author of the Quixote' gives a perhaps exaggerated but definitely interesting example of how context can be relevant.
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
and the larger situation is http://www.army.mil/article/92856 . Even then one wonders why General McAuliffe said "nuts" and not stronger invective. His Wikipedia entry says he was one of the few generals who did not use profane language, which lends some flavor to understanding that word choice.
If I write "NUTS" here, does it have the same meaning and interpretation as when McAuliffe wrote it some 70 years ago? Assuredly not.
I meant it for the target book: A technical book, teaching a corpus of knowledge, designed to be complete. The comment I was replying to specifically targeted the author, implying that the end result could never be good. The inferred implication is not solid, specifically because the knowledge in the text does not require interpretation using knowledge about the author (or its environment).
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.
Your text started "We should be able to evaluate a book" and ended "The opinion I express is more of a generic attitude on life.", which made me believe it was a general statement on all books, not on a limited subset. I think I can be excused for assuming it was a more encompassing attitude.
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.
The context of your example story is specific to those people which validates what you are saying - it wouldn't make sense if you said "NUTS". But it isn't a relevant comparison. An antidotal documentation of an event is not a body of work. The body of work of a journalist would be measured differently than simply the subject of one event that they are asked to cover. There could be exceptions to the rule but I doubt many journalists hit it big and hang up the cleats.
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?
Why should I remain neutral? We live in a sea of biases. I think it's better to know one's biases and consider how that affect what one wants to do, rather than remain neutral.
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.
Keep on hatin'. Zed's just going to keep writing books that help people, and your impression of him will merely drown beneath the tides of people who benefit from all the work he's put into FOSS & teaching others.
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.
It's certainly possible to both be rude and write books that help people. The two behaviors are not mutually exclusive. I think it's completely reasonable to laud Zed for his efforts to teach while questioning his manner.
Except this is a post about his book and his teaching? But here we are dedicating all this time to rehashing all this stuff that happened years ago with people who obviously weren't there at the time.
> I have watched this kind of attitude destroy teams and companies and I prefer not to condone it.
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.
I find it interesting that many people go out of their to defend someone like Linus Torvalds, but with someone like Zed Shaw, go out of their to criticize Zed Shaw.
Sure, Linus has written and maintained an OS, but as others have pointed out, Zed's CV isn't too shabby, either.
Its really pretty simple. Mr. Torvalds has a community and communities tend to defend their own. Happens in politics all the time because that's what humans do. Zed doesn't have as big a community and he offended some in the Ruby community. I think Zed's lecture in Toronto was an amazing presentation on values, but I've not read his books.
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've only had one dealing with him. While I was interviewing for a job with a company he was working at, they had him look at the code of one of my personal projects. He was polite and complimentary, just as you'd expect from anyone you were dealing with in a professional capacity.
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 am contrarian and rude, but you most likely worship quite a few people in tech who are also contrarian and rude but you say nothing. I bet there's a CEO you admire who is even worse than me and you tout his words like they're a gospel.
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.
How about you let go of the hate and embrace some love instead for the work this man has put forth?
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.
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.
I don't know of anyone else in tech who's had that experience, ha.
I'm merely commenting on the quality of the course, not the course creator.
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
As somebody who doesn't know Python I would never use this book or recommend it to others. The reason for that is nothing to do with drama over Ruby (which I don't know either) but purely because of the quality of his other work about languages that I do know. In particular his C book and his comments about C on this site.
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.
Your dismissal of his Python material is unfounded. This book is quite good, especially for beginners that literally would be unable to learn to code otherwise.
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 don't think your analogy really makes sense; the issue isn't that the author tries to teach people things which are too difficult to handle but that the author may state things which are just incorrect. A better analogy would be teaching beginning drivers to use their knees instead of hands to drive.
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.
I'm not sure if you're being sarcastic but I'll respond in case you aren't. I don't recall saying that I thought there were mistakes in the book; I wouldn't know I haven't read it.
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.
Indeed. No idea why you thought I was attempting to criticize it, validly or not. I was just trying to elaborate on a previous comment that someone else seemed to have misinterpreted.
It's interesting that you'd use an anonymous account to sling some slander, but I'll answer you:
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.
So everyone was right, and I adapted the book to denote that. I also started a project, which hopefully I'll find time to do, that is going to catalog all of the UB in C, write a unit test for each one, and then attempt to assess the security failures of it:
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.
I'm just commenting from the position of an observer who has found that your general attitude undermines the work you do, irrespective of whether you are right or wrong about the issue at hand.
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:
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.
> The take aways are that Zed doesn't understand C and hasn't read the C standard.
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.
>And no, he doesn't mock people who read the standard. The discussion was entirely about something else.
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.
Never heard about Zed so consider this rather objective - I just read the post and I don't think I agree with your take on it:
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
He had the gall to criticize the Ruby on Rails community when RoR was still considered sacred (I believe that honeymoon is pretty much over now) in the hipster coding circles that form a considerable and certainly very vocal part of HN.
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.
How about you let go of the hate and embrace some love instead for the work this man has put forth?
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.
Honestly, I have no idea where this hatred of Zed Shaw comes from. Yes, the man is opinionated, but he's no more of an asshole about it than most people (which is to say, not much of an asshole at all).
Same here. I pre-ordered it on amazon back in 2013!
I am getting pissed as every few weeks I get an email informing that the released date is postponed again.
Me too, man that book has been an epic slog. I've ended up rewriting it like 10 times but finally have a draft off to the publisher for editing. I'm still not totally happy with it, but it's the best I could possibly do.
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.
It is interesting that one of the way Zed advocates for learning is to type, (instead of copy and paste), the code into the computer. That reminds me when I was cutting my teeth at my introduction to computers. I would get computer magazines like Compute! and type in the 100s of lines of code that comes with it. Especially the arcade games listing. I think this method also improve my debugging skills as I was tracking down the error (usually I did not type in the code properly or there was a misprint in the magazine).
> Zed advocates for learning is to type, (instead of copy and paste)
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 think the bigger issue is that coding is about knowing what the hell you're doing. Copying a snippet manually forces you, as a side effect, to read the code, and read it more slowly than you otherwise would. You notice the limits of your understanding more quickly, and can try to fill them in.
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.
Typing it out definitely helps with muscle memory. Every time I start trying to learn a new language, I make sure to type out all the examples I hunt down while trying to implement something.
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.
That's a rather slanderous thing to say, and I honestly wish programmers would quit this fear mongering of others in the profession. I do it too, but lately I've been saying that we need to stop it.
You've never met me in person, so read some of the comments from people who have. By saying that I should never work with people you are effectively attempting to prevent me from having a job. That's an incredibly abusive thing to do to someone else, and it's just an odd thing to do in a professional setting.
Based on this, I wonder how you are to work with? Are you the kind of person who goes around getting people fired? Are you to be trusted in your opinion of others if it's so easily swayed by public opinion? Are you potentially racist or at least blindly biased?
See how that works? It's possible to take anyone's words and, with a bit of grammar jujitsu, use it to destroy someone else. I've recently tried to stop saying people shouldn't work with someone or that I won't work with others, and I have been meaning to write about it. Hopefully my comment will make you feel the same way.
Right? I came to the comment section to post something I found funny in the introduction... but I'm afraid people will get offended by it now.
"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."
If you know anything about programming, skip this book. If you don't know anything about programming, also skip this book. It gives you drills without explaining anything. My SO started learning with this book and I could see the book only caused confusion. She completely misunderstood how functions and function invocation work. And his way of teaching boolean logic is to memorize truth tables, wtf?
I agree. I suggest the Head First series by O'Reilly. They are much more beginner-friendly and the teaching method is based on research and not some crufty old belief that learning should be "hard."
The pedagogy of Learn Python th Hard Way is called 'Direct Instruction'. It has been successful for teaching the very rudiments of diverse subjects. It falls flat once applied to teaching creative intuition or abstract conceptual reasoning. That's why Learn Python the Hard Way is targeted at beginners.
Page 4 of the Shaw-Hanselman interview transcript discusses direct instruction.
I took this course. It used Idle when I did it. Got a very high percentage but still do not know how to do much with python. Learned how to use the basic, how to compute Big O, but not really how to "make" anything.
Matz's happiness is closer to mine than Guido's dictatorship and Python is not the language of my soul, either. Though as a card carrying condescending know it all I find Lisps most attractive.
> She completely misunderstood how functions and function invocation work.
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?
She understands function on a theoretical level. But keep in mind, she knows nothing about the cpu and jump commands. So, there was no intuition about functions being pieces of code being stashed somewhere for later use. That the interpreter would read a call and jump to that piece of code and send arguments to it. Instead, she developed her own theory of the interpreter reading a function definition and searching for calls in the code. The book did nothing to develop a healthy intuition about the flow of the program.
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
Instead of teaching people this (basic algebra), he recommends spending a week memorizing stupid tables?
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.
I see what you're getting at, but when you're talking about a high-level language like Python your comments about the CPU and jump commands seem really off-topic. You don't need to know anything CPU instructions or memory management to write competent Python (because that's all handled automatically) and knowing about them doesn't necessarily help you have a better intuitive understanding of Python code (because again, lots of stuff is happening under the hood automatically).
No, operators have English names resembling their semantics for that reason. AND(x, y) is only true if x and y are true. OR(x, y) is only true if x or y is true (inclusive). Etc.
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.
> And his way of teaching boolean logic is to memorize truth tables, wtf?
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?
Thank you Zed Shaw.. This is an excellent resource that has helped me to become what I am today.. I started learning Python using this book and he really takes time to ensure the readers understand what they are doing.
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.
You're welcome. I honestly write the books for people like you, and thankfully the world of programmers and the world of regular people really doesn't intersect much.
Having actually used this as a self learning tool, my feelings were mixed. On one hand, I think it's organized and clear. On the other, I found it's drill approach to be ineffective for me.
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 didn't start with Zed's stuff, but I checked it out when I was interested in Python.
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.
That's a good assessment of the books, and one I put into the introduction. It's weird because what is great for a beginner with zero knowledge is incredibly painful for someone who's experienced. I think that's the key with my book's success and also why a lot of professional programmers seem to completely dislike it. It's also why I'm very honest and upfront about this right in the beginning.
I went through this whole class when it was linked here a couple of months back and really enjoyed it. I'm a self-taught programmer that needed updates on some modern concepts and a refresher on some other stuff, plus a bit of help with Python syntax. If you're like me (or a beginner) it's great. Thanks Zed.
This book is for people who don't know any programming. So let's catalog your claims in that light:
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.
I learned programming from Pascal. It was at school.
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.
3. When did you form that opinion? I've found that since Django and numpy ported, Python3's been perfectly usable for a wide variety of uses. My last startup was all on Python3, and the only library I had a problem with was Splunk. Web programming, CLI scripting, deployment, data analysis, integrating with outside data sources - all of that went fine. The situation is quite different from what it was even a year ago.
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.
1. using context manager when working with io has two pros: no need to think about freeing resources, good style.
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.
Ummm, I don't understand all the dislike. For someone with my background, this was absolutely perfect. It's one of the very first things I read when I decided I wanted to learn Python. Fast forward several years, and now writing Python code is what I do for a living. I could not be happier.
I was a violinist, and Zed Shaw's way of teaching the basics completely resonated with me.
Hello Zed.
I didn't actually read whole LPTHW, but LCTHW helped me a lot.
I recommended LPTHW to some friends of mine, who were interesting in programming but had no experience at all.
Few years later and they are doing programming for living.
I personally think it's a good source for a newbie to start with.
Keep going with your job and thanks.
177 comments
[ 4.6 ms ] story [ 237 ms ] threadNo, 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.
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:
Python 3 only has new-style classes, so the entire explanation could have been left out, allowing the beginner to, as he recommends, focus on more interesting things.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] https://www.youtube.com/watch?v=sgHbC6udIqc
[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):
will print the wrong thing – "├Ñngstr├Âm" if you run it from the commandline, and "Ã¥ngström" in a more Windowsy context (e.g. if you're writing it to a file and reading it in Notepad).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:
In Python 3, UTF-8 source encoding and Unicode strings are the default, so the correct program becomes simply: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.
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.
"> 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:
and the larger situation is http://www.army.mil/article/92856 . Even then one wonders why General McAuliffe said "nuts" and not stronger invective. His Wikipedia entry says he was one of the few generals who did not use profane language, which lends some flavor to understanding that word choice.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:
So everyone was right, and I adapted the book to denote that. I also started a project, which hopefully I'll find time to do, that is going to catalog all of the UB in C, write a unit test for each one, and then attempt to assess the security failures of it: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.
[1] https://news.ycombinator.com/item?id=8834947
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]
[1]: http://norvig.com/21-days.html[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.
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.
http://amix.dk/blog/post/19574
If you're looking for what's popular, check out
https://news.ycombinator.com/best
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?
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.
You've never met me in person, so read some of the comments from people who have. By saying that I should never work with people you are effectively attempting to prevent me from having a job. That's an incredibly abusive thing to do to someone else, and it's just an odd thing to do in a professional setting.
Based on this, I wonder how you are to work with? Are you the kind of person who goes around getting people fired? Are you to be trusted in your opinion of others if it's so easily swayed by public opinion? Are you potentially racist or at least blindly biased?
See how that works? It's possible to take anyone's words and, with a bit of grammar jujitsu, use it to destroy someone else. I've recently tried to stop saying people shouldn't work with someone or that I won't work with others, and I have been meaning to write about it. Hopefully my comment will make you feel the same way.
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."
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:
Instead of teaching people this (basic algebra), he recommends spending a week memorizing stupid tables?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?
I'm pretty sure a beginner has no idea what "public static void main(String[] args)" means.
you've got to start somewhere.
http://hanselminutes.com/407/learning-code-the-hard-way-with...
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
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.
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.
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?
http://learncodethehardway.org/blog/AUG_19_2012.html
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 was a violinist, and Zed Shaw's way of teaching the basics completely resonated with me.
Thank you, Zed.