Live data from Hacker News

Retiring Python as a Teaching Language

prog21.dadgum.com

51–60 of 238 posts

Re: Retiring Python as a Teaching Language

#52

Funny, I have done a lot of game/graphics related programming using python and panda3d, which is written in c++ and has nice python bindings [0]. Sure, you can't just do "import wheemakegames" but the tools are out there. The same is true for GUI apps. If you want to click on stuff just have them use pyqt or pyside. I think that teaching students about other packages and how software actually works together is very i…

One of the issues I've had using Python to teach in the last few years has been the glacial transition to Python 3 for some packages, often with some annoying cross platform inconsistencies (trying to keep up with two or three different tool kits for one purpose because of different support for Windows vs OS X is annoying).

I really enjoy Python as a language, I enjoy using it for teaching fundamentals, but I really don't enjoy using it for teaching 'the fun stuff' as far as high school kids are concerned.

I might consider switching to JS in my new school. I was looking forward to perhaps using Swift but the new place is Windows-based.

Re: Retiring Python as a Teaching Language

#54
post #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

I might just not have played with it enough at the beginning of 2014, but kivy had some serious weirdness when it came to the way in which it approached its layouts, which I feel was down to the way in which it tried to approach being multi platform. This was mostly looking at developing a basic desktop app which I could then shift over to mobile as well.

Re: Retiring Python as a Teaching Language

#55
post #31

Earlier quoted context omitted.

And this is why I'd argue that Python 3 was a big mistake. In exchange for 6 years and counting of freezing and bifurcating the ecosystem, we got a smattering of minor improvements that don't substantially change the developer experience. What could we have had if that effort had instead been focused on things like real performance optimization and native browser support?

This makes the false assumption that resources put into Python 3 somehow prevented "native browser support," something that has always been firmly in the hands of browser vendors and was never blocked by insufficient loyalty to Python 2. The world where just giving up on Python 3 would magically bring huge benefits never existed. If you don't want to use Python 3, keep using Python 2 through its EOL in 2020+ but why…

> This makes the false assumption that resources put into Python 3 somehow prevented "native browser support,"

Agreed, browser support was probably unrealistic.

However other points still stand.

Python 3 was a mistake. It at the wrong time (too late), and didn't bring enough. The talks, and the time, and drama around it weren't worth to get dict comprehension and unicode support.

A 10x speed improvement (heck, just a 2x) would have been. Better IO handling via something sane like lightweight threads (via an already existing framework like gevent or eventlet). Better packaging. Better default GUI library. Refresh the standard library with something like requests, ipython...

Python had a golden opportunity and it squandered it. There were

Re: Retiring Python as a Teaching Language

#56
post #30
post #5

It's with all of this in mind that my recommended language for teaching beginners is now Javascript. I know, I know, it's quirky and sometimes outright weird, but overall it's decent and modern enough. Javascript is a flawed, quirky language, but with the upcoming ES6 and ES7 standards it's going to be a much, much better. I'd call it a tossup comparing it to Python or Ruby. I wouldn't have recommended JS to a beginn…

+1 on the interactivity aspect. Not having to go through a bunch of compiler configuration (C/C++ land) to get a basic GUI up and running is a huge plus. And HTML is a lot easier to understand for people with no experience than a bunch of tkInter classes.

i kindof believe all languages should have some ability to run with a browser-based GUI... why bother with all the hair-brained implementations (Swing, Qt, etc.) when we could just have a "desktop mode" (altered security) version of Chrome pop up to provide GUI. it wouldnt even have to follow same rules as browser really (navigation could be via buttons only, no back/refresh), just be based on html & perhaps js to allow a bit of advanced nav logic (though hopefully not enough to start polluting app logic)

i believe chrome apps may have some steps toward this, though not sure... at 1 point i considered trying to make a browser-based GUI that does all local RPC communication to a c++ app, but i feel like you know.... there should be a nice standard way of doing this out there

Re: Retiring Python as a Teaching Language

#57
post #17
post #11

Earlier quoted context omitted.

> 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 so…

>It's a game of tradeoffs, same as everything else in nature, isn't it?

My question is if tradeoffs are inherent in programming language design (some mathematical inevitability) or due to lack of resources and other "real world" concerns that can be overcome given enough care and money.

I'm not convinced by anything that I've seen that we don't just have the latter.

E.g. one could say in 1995 "JS is an awful language for development, and it's unsuitable for anything that needs to be fast. It's an inevitable tradeoff, use the right language for that etc".

And then the big corps got interested in optimizing JS, and we can now write full 3D games, and even video encoding in it, and we have asm.js and the like that take the performance of JS 2-3x worse than C for most things, as opposed to 100 times worse back in the day.

And we got node in the server side, and tons of libs etc. And with ES6/7 we get tons of language improvements.

Even the "fundamental" issues with JS, like bizarro type coercion, global by default, no integer types etc, could be corrected, it's just compatibility concerns that makes us not fix them, not some inherent impossibility of getting a great language without those issues.

Heck, we could even introduce optional gradual typing for JS, if it wasn't for those backward compatibility concerns, and even AOT compilers to native code.

Those things maybe wouldn't make JS perfect and useful for everything, but it would make it an order of magnitude better than what it is.

And if we started from scratch, without all those compatibility constraints at all, we could get a new language pretty close to perfect with enough money and a great team.

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

What door exactly closes? In the "mathematic necessity" way, not the "some people only like dynamic typing" way.

Because the thing under discussion was wether a language good for everything (or close to it) could be produced.

I chose those attributes not because I like them personally, but with this end goal in mind. Namely:

1) Without static types, you can't get the last mile of performance and safety checks, for using it for high performance apps and systems programming. They also help having a better IDE experience (autocomplete, suggestions etc) for those who like that.

2) If the types are not infered the language will feel too verbose and weighty to people wanting to use it for quick scripts and the like.

>you should also recognize that you are doing exactly the same thing as every single language designer in history.

Well, I don't have any beef with any language designer in history.

My basic problem with current languages is not that they made some choices, but that they didn't make some additional work they could PILE ON TOP of the previous choices and get much better.

Re: Retiring Python as a Teaching Language

#59
post #5

It's with all of this in mind that my recommended language for teaching beginners is now Javascript. I know, I know, it's quirky and sometimes outright weird, but overall it's decent and modern enough. Javascript is a flawed, quirky language, but with the upcoming ES6 and ES7 standards it's going to be a much, much better. I'd call it a tossup comparing it to Python or Ruby. I wouldn't have recommended JS to a beginn…

I'll be the first to admit that ES6 is nicer than Python in terms of the language itself. But I feel like it's still going to take years of heavy lifting to get the same level of high quality libraries, web frameworks, learning resources, etc. And it's hard for me to see js replacing Python as the obvious choice for beginners until that happens. It might be more fun to code in than Python, which is probably at least in part why there is more js code being written on github, but the larger ecosystem still seems like kind of a mess.

Re: Retiring Python as a Teaching Language

#60
A language like Perl 6 would probably be a good first programming language if some good libraries become available for it.

Printing one line of text is one line of code. Then you can start teaching branching, loops etc.

Object-orientation is also baked in.

Oh and by the way, there is this thing called "types". It helps you catch some types of bugs early and can potentially make your programs be compiled and thus run faster in some cases. Learn about that also without switching the language.

Some functional programming concepts can also be taught.

Also it has a C-style syntax so switching to another similar language later on would also be easier.

Post reply on HN