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.'"

Comments

Languages are different

[gweihir]

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:Languages are different

[greg1104]

Java as a base language is just fine. The problem is that the sort of problems people like to solve with Java involve things like database interaction, web applications, and user interface construction. And doing all those things turns Java programming into a giant library exploration exercise.

Many other languages end up falling into the same trap if you try to push them toward the same things Java aims at. Python for example has a pretty weak database interface layer. If you want to build a non-trivial DB app, you're likely to add both a database driver plus an ORM solution to make that work sensibly. As a PostgreSQL developer I run into psycopg2 + SQLAlchemy as an example combination. The resulting code is arguably no less "library call sequencer" than a similar solution built using JDBC + Hibernate. And the Java one also fits together into all these other "enterprise" app widgets--application servers and database connection poolers for example. You can do all that in Python, too, but you'll find yourself wandering into the same scale of library mess in the end.

Building an application development framework toolkit that doesn't feel like your language has been turned around to suit the needs of the library is a hard problem. I think one of the reasons Rails has become so successful is that it did a better job than most of avoiding that problem (albeit while giving you a whole different set of problem trade-offs to worry about instead).

Re:Languages are different

[Raenex]

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).

While I'll admit that Java has too much boilerplate, tools are good regardless of any language you use. You don't need tools to write in Java -- people managed before fancy IDEs came along. However, because Java is statically typed, it lends itself to more powerful tools. This is really helpful as projects get bigger.

I also have observed that most of the Java crowd never manages to get to the level of being even mediocre programmers.

Oh please, cut the bullshit bashing. I could say the same thing about Python programmers, but that's just throwing insults around.

Re:Languages are different

[Nursie]

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.

From lesson 0

[xs650]

"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."

Re:Only a limited starter no Python

[gweihir]

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

[gweihir]

... 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

[billstewart]

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:What format is the PDF in? Kindle?

[Inner_Child]

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.

Non issue

[Capsaicin]

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.