Someone linked me here asking me how I can write good quality code so fast so I thought I would come and drop a comment just in case other people read this and fall prey to the "HN must be true" virus.
I have no idea if I write code better or faster than other people. Maybe I do, but I always think that I don't write very good code most of the time so I have to be extra careful. I spent a lot of time writing code very slowly and being extra careful so that I could make sure it's good quality. I guess after focusing on quality for so long I just got faster at it compared to others. But, I'm going to guess that I actually am not much faster than other people.
LOL. An account with these as the only comments and no submissions? Man this place is so weird. It's like you're at a party, and then some guy can scream at you from across the room while wearing a Richard Nixon mask and everyone goes "Oh yeah that is true." Never questioning why the guy is wearing a mask at a party.
Anyway, I think you need to look up the words "tirade" and "incomprehensible"
Looks like you got some haters... The only reason to make a throw away in order to bash you - deservedly or not I don't know - is because you know this person and they don't want to remove their Nixon mask and risk a real life confrontation.
I did not create this account as a throwaway. I just don't have the inclination to comment on HN much and was lurking for a long time until recently. As proof I point you to my Reddit account of the same name which has a great deal of activity and which is reasonably well recognised and regarded in certain communities. I say this to demonstrate that I am not creating burner personas for the sole purpose of starting flame wars - but I did think it was worth stating in this discussion that Zed has succeeded in discrediting himself in some programming circles.
How to See Color and Paint It -- It taught me how to see color and paint it. Also how to use a palette knife which makes my paintings very different and fun.
Remembrance of Things Past -- I'm still reading this, as it's a massive stream of consciousness book, but I wish I'd started it when I was younger so that I'd be done with it by now. It's just so weird to read it and experience the writing that I enjoy it for simply being different. As you read it just remember that every ; is really a . and every . is really \n\n.
Van Gogh: The Life -- I absolutely hate the authors. They're great at research, but I feel they had a vendetta against Van Gogh of some kind. Throughout the book, at times when Van Gogh should be praised for an invention, they make him seem like a clueless dork. Ironically, their attempt to portray him as a dork who deserves his treatment ends up demonstrating more concretely how terrible his life was because he was different. I think if this book were around when I was younger I might have become an artist instead of a programmer.
A Confederacy of Dunces -- Absolutely brilliant book, and probably one of the greatest examples of comedic writing there is. It's also nearly impossible to explain to people except to say it's the greatest example of "and then hilarity ensues".
Mickey Baker's Complete Course in Jazz Guitar -- After a terrible guitar teacher damaged my left thumb I thought I'd never play guitar again. I found this book and was able to use it to learn to retrain how my left hand works and finally get back to playing. Mickey Baker's album also brought me to the Bass VI, which got me thinking I could build one, and then I did and now I've built 6 guitars. I play really weird because of this book and I love it. This book also inspired how I wrote my own books teaching programming and without it I'd still be a cube drone writing Python code for assholes. If I'd found this book when I was younger it most likely would have changed my life then too.
Reflections on A Pond -- It's just a book of this guy painting the same scene 365 times, one for each "day of the year" even though it took him many years to do it. All tiny little 6x8 impressions of the same scene. I learned so much about how little paint you need to do so much, and it's also impressive he was able to do it. I can't really think about anything I've done repetitively for every day of a year. I've attempted the same idea with self-portraits but the best I could do was about 3 month's worth before I went insane and started hating my own face.
Alla Prima: Everything I Know About Painting -- Instructionally this book isn't as good as How To See Color, but as a reference guide it is about the most thorough book on painting there is. It's so huge it's almost impossible to absorb all of it in one reading, so I've read it maybe 5 times over the years.
The man who moved my book into the "avoided" category admitted to me in an email that he did it just because of my K&R critique, not because of the book's quality, is not a C programmer, hasn't coded C professionally ever, and works doing PHP with almost no C experience.
Yeah I am not picking sides here but they really sold me against your book on freenode. As a newbie I didn't know any better. Come to think of it, I was doing just fine following your book, until I went on #C at freenode.
For reverse engineering? You should use every single thing you can get your hands on that helps you learn. The K and R are the two people who wrote C. Of course you should read their if you want to learn C. Then read, and WRITE the code in, everything else you can get your hands on to learn a programming language. It may only take one book, it may take 10, but that's how you do it.
Then after that go learn Assembler, or even better, implement a compiler. You'd probably learn a ton of the things you need to know for reverse engineering code from just making one simple compiler.
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.
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.
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.
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.
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.
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.
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.
I have no idea if I write code better or faster than other people. Maybe I do, but I always think that I don't write very good code most of the time so I have to be extra careful. I spent a lot of time writing code very slowly and being extra careful so that I could make sure it's good quality. I guess after focusing on quality for so long I just got faster at it compared to others. But, I'm going to guess that I actually am not much faster than other people.