Slashdot Mirror
2nd Edition of Learn Python the Hard Way Released
theodp writes "Are you or your kid intrigued by Python, but not quite ready to purchase an in-depth O'Reilly book? Zed A. Shaw's 2nd edition of Learn Python The Hard Way may be a friendlier option. Shaw's path to Python programming is simple: 1. Go through each exercise, 2. Type in each sample exactly, 3. Make it run. If $60 for the hardcover is too much to ask, or $15.99 for paperback, you can spend a measly buck for the PDF/ePub download. Still too steep? OK, there's even a free online HTML edition. After completing the 52 exercises, Shaw's concluding Advice From An Old Programmer says, 'Which programming language you learn and use doesn't matter. Do not get sucked into the religion surrounding programming languages as that will only blind you to their true purpose of being your tool for doing interesting things.'"
They can be in your way, they can make you jump though hoops, they can require you to create so much noise that you need tools to write anything in it (java is a prime example). If you are a truly good programmer, you want a language that does not tell you how to do things and just lets you do what you think is right. Even if that language has less extensive libraries than others.
Personally, I like Python, Lua and C at this time. Python does OO but does not force a specific, limited model on you as most other OO languages do. The one thing that comes close is Eiffel, but at the price of the compiler needing global scope. Lua is just plain elegant minimalistic and again supports OO, but as you see fit, not some restrictive inheritance model. And C just lets you do what you want, very fast if you know what you are doing, although OO, while feasible, has no language support at all. But often you can do without in C anyways. (Yes, even people that understand and like OO sometimes find that not using it is better.) In addition, all three languages are light-weight.
As to C++, I think that abomination would have been better aborted before birth. You need to know far too much about its internal execution model to write efficient code. At the same time, it is not light-weight anymore.
I also have observed that most of the Java crowd never manages to get to the level of being even mediocre programmers. To me these people look more like "library call sequencers" that could not ever do anything useful without these libraries and development tools that automatize a lot. Quite often this leads to slow, complex and insecure solutions, where the code is basically unreadable due to too much code, to many layers, too much abstractions and no insight on the part of the programmer. Sometimes Java code is 95% clutter and noise. This problem is less pronounced with other languages. One piece of advice I therefore give to anybody that wants to learn programming is to avoid Java like the plague. This is definitely only a language for quite advanced programmers, although the typical Java programmer is very far from that indeed.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
"A programmer will eventually tell you to use Mac OSX or Linux. If the programmer likes fonts and typography, they'll tell you to get a Mac OSX computer. If they like control and have a huge beard, they'll tell you to install Linux. Again, use whatever computer you have right now that works."
Philip Greenspun has some good titles: Philip and Alex's Guide to Web Publishing (dated, but I paid cash money for it back in the day), Software Engineering for Internet Applications, and SQL for Web Nerds. If you find yourself in the DB2 world, Graeme Birchall's DB2 SQL Cookbook is a must-have.
I am a novice level programmer in C++/Python and I thought I could benefit from this book. But the exercises seem to be ridiculously simple and it seems a book only suited for someone with zero or negligible programming background.
A month or so ago I decided to pick up a Python book at the Borders-is-dying sale, and while it's from O'Reilly, the book is too much of a reference - a lot of bottom-up "here's are six different list-like things" and "nobody expected the Spanish Inquisition, which is why you need to use this method to catch the exception it throws, but you can change that by overloading _ _ that _ _ method name's variable __pope__ or using _ComFyChaiR_ instead, but you can't set __pope__ to French, because that object uses __antipope__ instead, though in later versions you can modify it by using Cardinal()."
A friend of mine pointed me to python.org's tutorials", which were going to be my next step, but this looks pretty simple and accessible too.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I have been doing Python 3 for some time. The language is better than Python 2, but you still frequently run into things that are not ported yet. So I would definitely advise either to learn Python 2 and have a look at 3 or the other way round.
For larger projects, I would advise to still use Python 2 at this time, but with a style that allows an automated upgrade later on. This will mean not using some Python 2 features.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Check out MIT's OCW. Free lectures with a GPL Python programming book that does an excellent job at explaining programming and the Python language. The lectures are bad quality but the projects are good for practice.
Oh, you think watching Python on VHS is the hard way, do you? Why, in my day, if we wanted to see a good Monty Python skit we had to go kidnap the performers, construct a set, and buy enough booze to get them drunk enough to perform. VHS? Luxury.
One of the things I really liked about C was that once you've learned a few basics like how pointers and structs work, looking at code written by people much better at C than you just makes sense and comments like /* you are not expected to understand this */ are quite rare. That wasn't as true about C++ or Java, where many kinds of things are readable (after getting the basic "object" stuff down") but some of the template stuff is too obscure. It wasn't true at all about APL or PERL :-)
I was expecting Python to resemble LISP with a different syntax, but it's looking a lot messier than even Common LISP, and of course a lot of the moving parts are hidden in the large number of pre-written modules that come with Python.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
You can always grab the ePub for that same $1 and use Calibre to convert it to a format the Kindle can use. I just bought it myself, looks great on my Nook.
Today is red jello day - all workers must eat all of their red jello. Failure to comply will result in five demerits.
and then from the next paragraph:
No, the fact the language doesn't deal with the real programmer's life issues with (eventually) bad text editor, or simply because there will always people with bad or diverging habits is python downside.
In the same way that the the it is difficult to drive nails into wood with a nail file is the downside of a nail. Once you apply the correct tool in the correct fashion the problem vanishes.
Really all you have to do is alias python to path/python -tt and there is no problem only a syntax error. Or Alternatively, I have a "bad habit" I tend on occasion to leave the semi-colon off the end of the line when writing in Perl or C. Thus both Perl and C's "downside" is that they "[don't] with the real programmer's life issues .. simply because there will always people with bad or diverging habits." Makes sense to me.
The fact that one may or may not use a text editor that you consider "good"
I wrote "... whatever text editor you have you ought to be able to set this up." If you can't then the editor is not "good," but not as a function of my personal aesthetics, but due to its lack of fitness to do its job. Are there really programmer's text editors out there that cannot substitute a tab for four spaces throughout a file?!!
You may "like it", and I can see why ... but do not dismiss the issues associated with it.
After 2 or 3 months annoyance with the tabs/spaces "issue" followed by about 10 years withoIn factut even noticing any, I think I'm entitled to dismiss the "issues associated with it."
As it happens I wasn't dismissing the issue, I was offering advice about how anyone still suffering from this issue could dismiss it.
Better to be despised for too anxious apprehensions, than ruined by too confident a security. --Edmund Burke
Most of this "advice" is bullshit. The "line I've been programming for a very long time. So long that it's incredibly boring to me. At the time that I wrote this book, I knew about 20 programming languages and could learn new ones in about a day to a week depending on how weird they were. " gives it away.
Sure if you've got a background covering C you can pick up those languages based on C syntax pretty quickly - in terms of writing raw statements - but that means very little as most of the heavy lifting these days is done using the supporting libraries. Sure myself I picked up C# syntax in about that, but groking .Net to a productive level takes a fair bit longer. Even Javascript, which appears very simple for someone with a C background is deceptively simple to think you've got but you're probably missing out on the subtleties whole protoypical inheritance model. And then there's C++. Can anyone who doesn't code C++ as their day-job for less than two years really claim to have C++ and completely under their fingers?
And we haven't even considered more unusual things like Haskell or Prolog, or even Lisp where it's not just a question of the syntax. Sure if by 'picking up' you mean getting to the point of being able to code Quicksort then yes, but otherwise - well I call bullshit. And I've got over 20 years experience and an average of one language a year over that (but I'd only claim to really have half a dozen completely understood).
This is exactly how I like to learn, a dew lines about the code, the code, and expected output. Its concise, no crud in there. Its a format i'd like to see more of. I remember reading a C++ book, one of those monster ones from the late 90s that used up about 50 pages printing out encoded resource files, pages and pages of non-human readable crap. (Being a nub at the time I actually typed a lot of it out)
I've got almost 40 years in, and long ago lost count of languages, operating systems, and hardware environments.
You'll get past this stage.
You will never have any living computer language "completely understood" for any significant amount of time if you are working on anything more meaningful than simply tracking that language's implementation arc in a world of constantly changing underlying platforms.
There's a difference between learning a language and memorizing that language's commands and libraries. There's a difference between knowing a language and knowing which language features are optimally supported on a specific OS or hardware implementation, too.
Learning how you learn is the key, and I think you've already got that. Trying to learn every single thing there is to know about a computer language is a waste of time that could be better spent creating something wonderful. Instead, just learn language weaknesses and vulnerabilities, and google for syntactic boilerplate as you need it.
Hopefully you'll reach a point where you know exactly what you want to accomplish, and how that can be optimally computed in the target execution environment (regardless of whether that evironment is an embedded RISC processor or a browser DOM) and you'll plot the best path to get to that goal in whatever languages are available to you.
Eventually you'll probably start avoiding the use of any libraries at all, and start liking languages with very terse syntax. When you find yourself preferring to write fifty lines of C rather than five lines of perl that calls in 50,000 lines of code from CPAN, look out! If you don't keep that tendency well under control, you might turn into Paul Graham.
To avoid that fate, train yourself to always write code that is maintainable by people who are far less skilled than you are. That way you can delegate maintenance and enhancement to less skilled hands, and go do more interesting things yourself.