Hacker News Reader

> 2) It is actually surprisingly difficult to teach object oriented programming in Python, since most simple problems are much more easily solved in a functional manner than with classes.

That's actually a good thing. I'm afraid too many people learn programming early on with e.g. Java and end believing programming equates defining classes and mutating objects. I've worked with people with such background (actually, I routinely do), and it's not pretty. I notice a difficulty in these people to grasp fundamentals, like data structures, idempotency and high-order functions, which leads to awful bad practices.

I completely agree. Still, OOP is an important tool to have in your belt. I would say though, that a difficulty to grasp data structures or higher order functions is pretty universal in beginners regardless of background. Those are just hard concepts.

Could you explain how setup is more difficult on a Mac than on Windows? Other than a decent beginner's text editor, everything you mentioned comes pre-installed on OSX. Trying to install 3rd-party Python libraries on OSX is kind of a pain, but if you're just using the standard library (which will get you pretty far in an intro class). Finding a good text editor for Mac also isn't that difficult. When I've taught beginners on a Mac, I usually just download Textmate.

Doesn't Emacs and Vim come preinstalled on OS X? Or has that changed with Mavericks?

Those are exceptionally poor choices for a beginner's class.

I disagree. Why do you say they are?

Because it's a class to learn programming, not a new text editor.

But they don't know any text editor. They have to learn something.

Most new students have seen a text editor before (like Notepad or Microsoft word). They are used to things like using the arrow keys for navigation (instead of HJKL), not having to switch modes, and using the mouse to manipulate text. There are plenty of serviceable programmers' text editors which follow these idioms. Better to let students use something familiar so you can focus on the actual subject (programming) and not frustrate them with learning a completely different set of keyboard shortcuts.

When was the last Emacs that didn't use arrow keys by default? 1987 on a VAX? Ditto with mice and such. And it's modeless.

People just ape things they've heard without thinking. Emacs and Vim may not be perfect beginner's editors, but they are much better than just decent.

Yes, I'm interested in hearing about this as well. OS X comes not only w/ Python 2.7, but also easy_install. Getting IPython Notebook up and running is a single command:

sudo easy_install ipython[all]

Personally, I think IPython Notebook is a fantastic (the best?) tool for teaching Python, and being able to distribute/collect notebooks seems for classrooms seems like an awesome thing.

There are plenty of text editors, and if you must go the IDE route, IEP and Light Table are both free and cross platform (among lots of other options).

Python itself is no problem, that's true. But even installing simple modules leads to headache. You suddenly need to have XCode installed, and you get compiler errors, and you need to modify your PATH...

The lack of binary installers for Python/Mac packages really was an issue for my students.

> 1) Setting up Python, a text editor and a shell is easy on Windows (using WinPython), but pretty confusing for Mac users.

How is this even possible? TextWrangler (or other choices) come from the App store, Terminal is right there and Python is already installed.

> introductory > object-oriented programming

Unless I was mandated to make my syllabus match the language reference's table of contents, I would defer most of object-oriented programming to a second semester. How to use particular objects from the standard library would likely be covered on an as-needed basis in an introductory class -- for example, "you use the syntax d.keys() to get a list of a dictionary's keys" without attempting to explain that "keys" is a function attribute of a class of which d is a member, and thus by MRO rules d.keys triggers a lookup of the "keys" member from the built-in dict class, and d will be passed as the first parameter when the function call operator denoted by the parentheses is executed ...You may be tempted to include such detail for various reasons, but trust me, your students will thank you if you save that content for a more advanced course.

> There is no way to teach integer logic really (Python has auto-growing arbitrary precision integers)

You can still teach binary representation and use bit-wise operators.

Also, I once wrote a storage-efficient bit vector class with the built-in bytearray module, which is a good exercise to tie together object-oriented programming and binary representation. However, a student at the level of doing that exercise is no longer beginner, but firmly intermediate or advanced.

> floats can lead to strange errors

These are a natural consequence of the floating-point representation and this problem exists in each of the article's top three language choices.

Re floats:

True, this problem is universal. I still wish there was a way to circumvent it, much like the arbitrary precision integers circumvent integer problems. Rationals and fractional integers come to mind, though I don't know their performance characteristics.

Python has a decimal package in stdlib. It provides an arbitrary-precision floating point type. The performance will obviously be worse than with floats, but I doubt it matters in an intro programming class. The only real drawback is that there are no decimal literals.

Actually, several languages I know of have decimal types in stdlib. Two that do not are C and JavaScript.

While obviously it's a fundamental thing to teach/cover the various data types (or at least how '1', 1, and 1.0 are different since they'll be encountering this over and over if they continue programming), on a practical level, frequent casting can be sidestepped by using string formatting when printing numeric output.

In all my production code (my string printing is not performance critical) I pretty much always use string substitution when printing as a matter of style/convenience. It's much easier to add/replace substitutions, and I often need formatting anyway.

If students get used to printing w/ string substitution, they can then simply use %d or %f to control how they want their numbers to display, which is probably the right way of thinking about rendering text output.

Python has the "fractions" module which provides a more powerful abstraction: It's not restricted to denominators that are powers of 10.

> I don't know their performance characteristics

It's easy to make some good guesses.

Since (I'm guessing) it's implemented with pairs of integers, adding probably uses

    a / b + c / d = (ad + bc) / (cd)

which is 3 multiplications and an addition, and multiplication probably uses

    (a / b) (c / d) = (ac) / (bd)

so only two multiplications. So it's a small constant factor times the cost of integer multiplication, plus a bit of overhead for the wrapper class.

So my back-of-the-envelope guess is that the fractions module is less than 10x slower than the same operation with integers, or fast enough for just about anything you do in a beginner level class.

These numbers will change significantly if fractions are automatically reduced by gcd of numerator and denominator; I'm not sure about this point.

> It is more or less impossible to peek under the hood. There is no way to teach integer logic really (Python has auto-growing arbitrary precision integers) and floats can lead to strange errors (x=1; for i in range(10): x+=0.1 does not yield 2).

I believe the same problem applies to C, and any program that employs a float register. 0.1 cannot be defined accurately in a float, there is incompatibility between a base 10 system and a base 2 system. This should be true no matter the size of the register. The larger the register, the more precision you get, but you don't get more accuracy.

> 2) It is actually surprisingly difficult to teach object oriented programming in Python, since most simple problems are much more easily solved in a functional manner than with classes.

Do you have an example? From the outside, it doesn't seem to be that difficult, for example, in the C++ course I followed, the teacher introduced classes with the implementation of a RPG character. That was pretty simple.

While I don't know that it's difficult to teach OOP in the sense of 'objects exist' in Python, I do think it's more difficult to teach a lot of tthe concepts associated with OOP, because the way it's done in Python is so unusual (explicit self, no real encapsulation, etc., etc.).

In the introductory programming course I took, the way OOP was introduced involved writing incredibly un-idiomatic Python. So in that sense it works fine, but if you're going to ignore the 'spirit' of a language in order to use it as a teaching tool, it seems to me what language you choose doesn't really matter, so long as it has the features to shoe-horn in whatever style you want to teach people in.

I explained it using a bank account. That works well enough. It's just that I couldn't come up with many real-world problems and exercises that are naturally solved with classes.

Classes are a rather high-level abstraction, and most problems in introductory classes are decidedly low-level.