41–50 of 238 posts
There is a compelling need to be able to distribute graphical python applications that isn't met (and that https://www.python.org/dev/peps/pep-0441/ isn't even a step in the right direction is an indication of how far away a solution is).
Don't get me wrong, python is a great language, but its not the right solution for teaching programming for exactly these reasons.
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…
Emm, MVC web apps are not appropriate for games. The could be the backend for SOME games, quizzes, RPGs maybe etc, but for the vast majority of games you need a canvas to draw in.
So that would still require using Javascript, not just Python on the server side.
For games, an introductory class using Python with Kivy or PyGame doesn't fit the bill because they may not always be around? If a student really wants to go deeper into game dev, they're going to need to learn at least one of Swift/ObjC/Java/C# and their respective native libraries anyway. You're not indoctrinating them into a platform like the web or iOS, you're introducing them to programming.
The rant about libraries not always being maintained is really brilliant considering the library churn than in the JS space. After all, they may be "well-intentioned today but unsupported tomorrow?". TkInter? This was around before Angular 1.x was a glimmer in daddy GOOG's eye. It'll be around after Angular2.0, and long after 2.0 is buried and the next JS framework/library rears its ugly head only to be put down in short time. Given the choice of having invested my time into TkInter, or Angular 1.x, I know which I'd rather have dumped my time into.
So what's the goal here, to teach programming with something you can show others? If so, then you can do it with almost anything, especially Python.
Use what you want to teach, but don't delude yourself with half-baked reasoning to justify what you clearly always considered an inferior choice to do it in- for the last 2 decades.
Back to the drawing board, professor.
Teaching towards that subset is also a healthy instruction in rule of least power - once you grasp how to use the basics, you have a fighting chance of picking up most other languages too. It's way more unhealthy to guide newbies into cargo cult thoughts about "proper" something-something design(insert favorite methodology here) - a learner has to make their own mistakes to learn properly, but they should do so from within the subset of programming concepts that predate current languages, because those are the things that have lasted through multiple generations of software.
If we consider Python, Ruby, JS, C#, and Java - the design of most of their core features was locked down all the way back in the 1990's. So all the new ideas they brought to the table tend to be "baby implementations", frozen in a half-correct state of refinement. But the things they got _really_ right tend to be the things that were there and usable, but not refined so well in prior languages.
As a proponent of python and a full time python developer I fully endorse this decision. There is a compelling need to be able to distribute graphical python applications that isn't met (and that https://www.python.org/dev/peps/pep-0441/ isn't even a step in the right direction is an indication of how far away a solution is). Don't get me wrong, python is a great language, but its not the right solution for teaching…
> This feature is not as popular as it should be mainly because no one’s heard of it
Count me as one. As someone who does a lot of development in Python, I'm surprised I never heard of that feature either.
Perhaps another reason this feature goes unnoticed is because it still requires the end user to have Python installed. Therefore, when distributing a Python application, most people just bundle it into an EXE/ELF/etc and don't bother looking for other solutions.
Javascript turned out to be much better for making simple games and doing simple puzzles.
As a proponent of python and a full time python developer I fully endorse this decision. There is a compelling need to be able to distribute graphical python applications that isn't met (and that https://www.python.org/dev/peps/pep-0441/ isn't even a step in the right direction is an indication of how far away a solution is). Don't get me wrong, python is a great language, but its not the right solution for teaching…
From the link: > This feature is not as popular as it should be mainly because no one’s heard of it Count me as one. As someone who does a lot of development in Python, I'm surprised I never heard of that feature either. Perhaps another reason this feature goes unnoticed is because it still requires the end user to have Python installed. Therefore, when distributing a Python application, most people just bundle it in…
(.exe bundlers, by comparison, bind the shared library into the executable or with it)
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…
The "universal" language would be fairly low level, but would allow you to create your own DSLs. So you'd really be designing your own language for each task. That language would be 100% suitable to the task at hand. For example, you'd embed SQL directly into your code, not as a string, but actually parsed by someone's library so it's syntax checked.