2nd Edition of Learn Python the Hard Way Released 167
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.'"
Languages are different (Score:3, Interesting)
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.
Re:Only a limited starter no Python (Score:4, Interesting)
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.
Re:Exercises not all that good (Score:4, Interesting)
... it seems a book only suited for someone with zero or negligible programming background.
It is. There is a place for such books as well. It does not hide this fact either.
Code by people much better than you (Score:4, Interesting)
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.
Re:Languages are different (Score:4, Interesting)
Python's good.
It's quite refreshing to go to a language where (as someone with a lot of experience in programming but not much with python) with such flexible syntax that "I wonder if I can write it this way?" usually works.
And as for rapid prototyping it's great. A couple of evenings and 500 or so lines of python and I can have something that would take me weeks in C. Of course in C I would have had more fine grained control over behaviour and I do run up against barriers in python every so often.
The major downside for me is the GIL. For anything processor intensive you have to work around the language to use the resources of a modern system, rather than work with the language.
Non issue (Score:4, Interesting)
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.