Live data from Hacker News

Retiring Python as a Teaching Language

prog21.dadgum.com

11–20 of 238 posts

Re: Retiring Python as a Teaching Language

#11
post #2

JavaScript (or rather: a subset of it) is a fine teaching language too, especially since it's easy to publish runnable code - even for beginners. However, there is no language that can do everything equally well. It's a common reaction displayed by the proponent base of many languages, even here on HN, to advocate the use of their language for every conceivable need. This can't possibly work well. Programming teacher…

>It's a common reaction displayed by the proponent base of many languages, even here on HN, to advocate the use of their language for every conceivable need. This can't possibly work well.

Is that some law of nature, or merely a consequence in how we've designed languages thus far?

A well designed type-infered statically typed language with a REPL/interpreter, a fast AOT compiler, an optional GC, good documentation and IDE support, and a big API library could work well for all kinds of domains, from scripts and websites, to network application servers and systems programming.

Note also that the money we spend on language and tooling development are miniscule and laughable compared to the IT industry's size.

When there have been some decent money involved we had good results. Namely:

With SUN/Java we got the fastest, more mature VM out there, with very good GC and a ton of tooling available.

With Javascript, we got V8/JSC/etc, that made the language 10-100x faster compared to the nineties.

With MS, we got C#, a great language that can cover tons of ground for what its designed, modern, with a huge ecosystem of tools and APIs.

And from Apple, we got the great Cocoa libs and Swift (still a work in progress but very promising).

Re: Retiring Python as a Teaching Language

#12
post #7

I would almost suggest CoffeeScript in place of JavaScript. In fact it feels more like Python. My main concern would be lack of Google-able resources compared to plain JS.

Coffeescript is clearly in the same vein as Ruby: designed by experienced programmers for experienced programmers. The list of caveats and gotchas for both languages is a mile long, and the grammar of both is ambiguous. I love both languages dearly for letting me be a trixy wizard but would never reccomend either to a beginner.

Re: Retiring Python as a Teaching Language

#13
post #12
post #7

I would almost suggest CoffeeScript in place of JavaScript. In fact it feels more like Python. My main concern would be lack of Google-able resources compared to plain JS.

Coffeescript is clearly in the same vein as Ruby: designed by experienced programmers for experienced programmers. The list of caveats and gotchas for both languages is a mile long, and the grammar of both is ambiguous. I love both languages dearly for letting me be a trixy wizard but would never reccomend either to a beginner.

I would argue that CoffeeScript has less gotchas than JavaScript. And, while you can be a trixy wizard with CoffeeScript, it certainly isn't required. The leaner and more linguistic syntax would aid beginners.

Re: Retiring Python as a Teaching Language

#14

So incredibly in favor of this. I love python, it's probably my favorite language. I taught a class on it in Boston. But these exact questions have indeed brought doubts into my mind. Year after year I'm disappointed by what python simply cannot provide in any straightforward way. The options are very few for making games. The options are very few for desktop GUI (I tried to do PyQt and then discovered QML with JavaS…

You had me until you said that Django doesn't have the clarity or documentation of Rails. Django is easily one of the best and most meticulously documented pieces of software I've come across in my 18+ years of writing software.

It also, IMHO, has a much higher "clarity" quotient - Rails is a lot of magic for me, while Django is, in the end, much less religion and much more clear. (I will acknowledge that I chose Python and subsequently Django because they spoke to me personally, but seriously, Django's documentation is second perhaps only to Redis.)

Re: Retiring Python as a Teaching Language

#15
post #9

I would actually solve the game/show problem a different way. I would teach kids how to build MVC web apps and set up a cheap server so that apps could be "shown" to anyone on any device. If you use a mobile-first design philosophy for the webapps then phones are not likely to be an issue. Yes, there is still the issue of response time but no language works for everything. You have to accept certain limitations and m…

I would teach kids how to build MVC web apps and set up a cheap server so that apps could be "shown" to anyone on any device.

That's a pretty big hurdle for a newbie to get over before "Hello World".

JS in the browser has the massive advantage of being pre-installed and requiring no special tools, with an immediate edit-run feedback loop. Wrestling with a server and code deployment etc is a problem they can learn to solve once they've been bitten by the programming bug.

Re: Retiring Python as a Teaching Language

#16
post #6

> A month later, more questions: "How can I give this game I made to my friend? Even better, is there a way can I put this on my phone so I can show it to kids at school without them having to install it?" Giving a Pygame game to your friend is pretty easy. It has usually very few dependencies and should be trivial to package. And it's multiplatform (Mac, Windows, Linux including even exotic devices like the Raspberr…

> Putting a python game on a phone is definitely more of a problem

Not necessarily. kivy[1] is an alternative to pygame (for desktop builds, it uses pygame/sdl under the hood iirc) but it supports exporting to android as well as desktop platforms. I haven't done a ton with it so take this with a grain of salt, but it looks like it could be a viable option in this case.

[1] https://github.com/kivy/kivy

Re: Retiring Python as a Teaching Language

#17
post #11
post #2

JavaScript (or rather: a subset of it) is a fine teaching language too, especially since it's easy to publish runnable code - even for beginners. However, there is no language that can do everything equally well. It's a common reaction displayed by the proponent base of many languages, even here on HN, to advocate the use of their language for every conceivable need. This can't possibly work well. Programming teacher…

> It's a common reaction displayed by the proponent base of many languages, even here on HN, to advocate the use of their language for every conceivable need. This can't possibly work well. Is that some law of nature, or merely a consequence in how we've designed languages thus far? A well designed type-infered statically typed language with a REPL/interpreter, a fast AOT compiler, an optional GC, good documentation…

> Is that some law of nature, or merely a consequence in how we've designed languages thus far?

It's a game of tradeoffs, same as everything else in nature, isn't it? I would rarely say that a given language's design or implementation is universally flawed, instead it's the result that comes out of a set of premises and decisions. Yes, some of them may be objectively bad, but mostly they are just decisions made to solve specific problems.

In a way the whole point of my post was that languages don't primarily exist on a one-dimensional spectrum of "good" to "bad". They're optimized for different things. The assumption that given a list of possible decisions during language design you just have to select the right one every time is based on the fallacious premise that right and wrong are the actual choices you get.

> A well designed type-infered statically typed language [...]

...and those are already some key decisions you made that reflect what's important to you personally. Every time you choose one of these properties, you open doors and close others behind you. While you may personally believe these are the minimum requirements which every "good" language absolutely must have, you should also recognize that you are doing exactly the same thing as every single language designer in history.

Re: Retiring Python as a Teaching Language

#18
post #7

I would almost suggest CoffeeScript in place of JavaScript. In fact it feels more like Python. My main concern would be lack of Google-able resources compared to plain JS.

Coffescript wouldn't be pragmatic since they would have to learn Javascript anyway.

Re: Retiring Python as a Teaching Language

#19
post #9

I would actually solve the game/show problem a different way. I would teach kids how to build MVC web apps and set up a cheap server so that apps could be "shown" to anyone on any device. If you use a mobile-first design philosophy for the webapps then phones are not likely to be an issue. Yes, there is still the issue of response time but no language works for everything. You have to accept certain limitations and m…

I'm not sure your responding to the problem the OP has. He isn't saying Python isn't good for all the things you've listen. He is saying that for starting off in an introductory classroom environment, python is too complicated for simple interactive applications.

MVC web app certainly goes above and beyond TkInter in complexity. If you need to develop the web app, then you'll probably end up teaching Javascript anyways to accomplish what he is addressing. Having tutored friends in introductory courses before, functional programming would certainly also go over their heads.

So while I agree with you on your points. I agree with the OP that perhaps Python isn't the best language you want to use as an introductory course (if interactive GUI are on the to do list at least), but maybe bring it in during the second or third course.

Re: Retiring Python as a Teaching Language

#20
As much as i can't disagree with the choice (the realpolitik of programming has made it the most correct choice), i am saddened that the language on which the choice falls is one not chosen based on any merit, but merely due the historical accident of being the first to be implemented in a browser and having had no appreciable opposition due to browsers at the time being in hands of corporations.

In "A Deepness on the Sky", Vernor Vinge describes a future in which there is the reality of a profession called "Programmer-at-Arms", necessitated due to thousands of years of layers of indirection and cruft that will combine to make the software of that time, making it a requirement for even simple changes in a weapon system to be done by someone who can dig through all of those layers. It seems that his prediction is closer and closer to becoming reality.

Post reply on HN