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 teachers should make a habit of pointing out that writing code is a journey that will require students to learn new tools all the time.
There are many decisions that influence language design, it's not just syntax. Differing decisions are made about runtime behavior, memory management, levels of abstraction, and the efficiency of idiomatic data structures.
Even objectively, a good language to write an OS kernel in isn't necessarily equally well suited to, say, game development, or web development, or scientific computing. That doesn't mean there won't be heroic efforts to make a language work in every arena, but at some point most people draw a line based on pragmatism.
Also, often overlooked, there is the aspect of a language mapping well to a given developer's brain. Different people are drawn to different languages for different reasons, including borderline-intangible ones where they just feel more "at home", which translates into tangible outcomes like productivity.
>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).
> 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.
I find that less and less true. The canonical example for me are abstract data types. They're pretty much free on a runtime level, enable clean code, and allow for more static checking. Basically a superpowered version of enums. I can't see any argument against having it in the language unless the express goal is to have no syntax (lisp).
Again, that's a personal preference, not a statement of fact. There is a cost associated with different type systems, and that cost can vary with the problem you are trying to solve. It's not that I argue against the benefits of having such a system in place, but you should be aware of the fact that this too might not represent the end-all-be-all for all programmers.
One of the basic mistakes made here seems to be the notion "if programmers only _knew_ about the one true way of doing it, they'd all use the same language and tools, namely: mine".
In the real world, 90% of programmers use either C#, Java, C/C++, JS or Python/Ruby/Perl in their jobs.
We could restrict ourselves to this set of languages and syntax style, and design a super-set language that does everything, gets rid of their historical warts, and can go from scripting to HPC.
Stuff like using significant whitespace or not, are BS bikeshedding, which we can bypass.
The thing is, were it matters (speed, expressivity, availability of REPL and IDE, large SDK) nothing but money prevents us from making such a language...
Is there anything preventing a top notch team working for 10 years and come with one ready, including all the trims and works, JIT, AOT native compiler, ports to 2-3 architectures, batteries et al?
Sure, some people would still like their Java or their Lisp or whatever.
But there's not some logical impossibility preventing us from creating a language that's better for 90% of the tasks than what's our there.
In a sense, that's what MS did with C# -- but they stopped too soon because they have their own agenda. So it was Windows only, in the CLR with no supported AOT option, etc.
There is no need for passive aggressiveness. I get that aping the exact phrase used in a parent comment is used to communicate disrespect, and it's duly noted, but all things being equal I would prefer not to go down that route.
My argument here is that people designing languages have made choices based on their personal preference as well. It's not really appropriate to take one specific set of features you like and declare it to be the objective winner.
> In the real world, 90% of programmers use either C#, Java, C/C++, JS or Python/Ruby/Perl in their jobs.
That's a No True Scotsman-like argument. Also, what's the meaning of the three different types of separators you used there? But for the sake of convergence, yes, let's assume every important real-world language is in that list.
I'm still not sure what to say about this without repeating myself, except for: go and do it. You say it's a matter of investment, but on the other hand consider the benefits if someone pulled it off. If you really do believe you are the person who has this all figured out, please go ahead and implement this. Heck, make it a Kickstarter project or something, I'm in!
>There is no need for passive aggressiveness. I get that aping the exact phrase used in a parent comment is used to communicate disrespect, and it's duly noted, but all things being equal I would prefer not to go down that route.
What passive aggresiveness and/or disrespect?
The repeat is used to communicate disagreement with a specific thing attributed to what I said. Since it was attributed twice, with no regard to the arguments I made, it was mostly necessary.
If anything is "passive agressive" is this sudden ad-hominen and armchair psychology attempt.
I only responded to the abstract issue under discussion, didn't made any judgements on the participants. Can we keep it at that level?
>My argument here is that people designing languages have made choices based on their personal preference as well. It's not really appropriate to take one specific set of features you like and declare it to be the objective winner.
And my point is that I'm not doing that, I'm not picking features based on personal preference (my actual preferences are different), but to describe how a language can encompass the whole range of applications (be the right tool for most jobs, as much as possible).
This wasn't about "my dream language" (that would be something like Smalltalk) but about whether a language can cover all/most bases or we're forever doomed to use a babel tower of "right tools for the right job".
And the "cover all bases" thing I tried to tackle from a technical features standpoint. At this conceptual level of the argument I don't even care much if programmers will like the end result.
>That's a No True Scotsman-like argument
No, it's just a statistical observation. 90% of programmers do use this languages. I don't say the rest are not programmers or not true programmers -- just that we can cover the majority of programmers doing professional work with a language in that vein.
>I'm still not sure what to say about this without repeating myself, except for: go and do it. You say it's a matter of investment, but on the other hand consider the benefits if someone pulled it off. If you really do believe you are the person who has this all figured out, please go ahead and implement this. Heck, make it a Kickstarter project or something, I'm in!
Now, that's disrespect and passive agressiveness!
I never said it's just me that "has all that figured out". In fact lots of people say the same thing, inside every language community there's a trying to fix the same pain points to make each language more universal.
Lots of Python people for example wanted to make it GIL-less / capable of good async operation / faster / typed / etc. All this is for handling different kinds of scenarios that it currently does not.
People using JS asked for more speed, then for server side/native interfacing (Node et co), then for "programming at large" features (ES6) etc, types, things like asm.js to get native memory management, etc.
So, what I wrote was that having a language extend to almost all jobs is not impossible, and gave a laundry list of features (taken from observations such as the above), that could accomplish that.
>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.
I think the issue here is that we have two opposing theses on how this works. I posit that the programming ecosystem is very much like any other ecosystem in that there is are many organisms within it, for a good reason. For example, looking at nature, you might ask yourself why biology hasn't converged on a single lifeform yet, and whether it's not simply an issue of having all the right genes and discarding those that are not so good. But that's obviously not how it works. There are niches and different strategies for solving different problems. There is no one genome that solves everything. And yes, every single codon is a decision that opens doors and closes others as well.
If I understood you correctly, your position is the inverse of that thesis. You argue that there is a base abstraction that should work equally well in every context, and that specialization could come in the form of optionals piled on top of the one true base. There is no mathematical reason why this should be unworkable, but a solution so far eludes both programmers and evolutionary processes alike. That doesn't mean you shouldn't go ahead and try solving it. It's a worthy project. If you believe you can come up with common denominators that cover all aspects of all previous languages, by all means: give it a try!
>For example, looking at nature, you might ask yourself why biology hasn't converged on a single lifeform yet, and whether it's not simply an issue of having all the right genes and discarding those that are not so good. But that's obviously not how it works. There are niches and different strategies for solving different problems. There is no one genome that solves everything.
And yet, nature already has "converged" sort of into humans, who are "master of all trades" sort of, and somewhat analogous to the "full-spectrum language" I'm talking about.
And as with that language and other languages, the existence of humans doesn't mean all other lifeforms will perish or dissapear.
>* There is no mathematical reason why this should be unworkable, but a solution so far eludes both programmers and evolutionary processes alike.*
Well, for evolutionary processes we have humans. And soon, if we are to believe some pundits, the "singularity".
As for languages, we have some near damn all rounders, but my observation is that it's not because it has "eluded programmers" that we don't have it, but because of business reasons (e.g. some company wants to only target segment X), oss being underfunded, narrow scope, etc.
Optional gc is not something I've seen work in practice. Apple abandoned their attempt because of the difficulty getting gc'd and non-gc'd code to play together nicely. Rust has (and may again) offer something like optional GC, but it will operate at the value level rather than the program level and thus doesn't really solve the library problem.
Programming languages are designed in a huge, multi-dimensional space. Should the language be static or dynamically typed (or optionally typed)? Interpreted or compiled (or JIT'd)? Manually memory managed or gc'd? Powerful or simple type system? Large (C++) or small (scheme)? Batteries included? Hosted on a runtime?
Each of those questions (and of the dozens more than go into designing a language) involves tradeoffs. Manual memory management makes a language suitable for domains like kernels and games, but inevitably requires the user be aware of where and how memory is being allocated and deallocated. Small dynamically typed programs tend to be (in my experience) faster and simpler to write, but static typing makes maintain large codebases much easier.
I strongly believe there will never be a language that is the best available for all domains. Currently I find that I need three languages to cover my bases:
* A dynamic, batteries-included scripting language (Ruby)
* A static, fast, gc'd language (Scala)
* A static, fast, non-gc'd language (C++)
I'm hoping that Rust will collapse the last two, but there are still a lot of tradeoffs.
>Optional gc is not something I've seen work in practice. Apple abandoned their attempt because of the difficulty getting gc'd and non-gc'd code to play together nicely. Rust has (and may again) offer something like optional GC, but it will operate at the value level rather than the program level and thus doesn't really solve the library problem.
Well, you could make 2 compilers for languages with the same syntax, and 2 sets of libraries (GC and no-GC) with mostly the same APIs, divergent only in whether they have GC or not.
For low level stuff you use "GCLESSLANG" (as a better C) and for the other stuff you use "GCLANG".
Otherwise the 99% of the syntax is the same, and the 2 langs are designed to easily call into one another. They could share most of the parser and compiler too.
This would basically give you the feel that you use one and the same language, switching between GC and no-GC version.
It's a money and resources thing, not some "cannot make this work" thing.
I think Rust attempted to do a much more conservative version of this (same language, different sigils on pointers depending on whether pointers were refcounted or ownership-transferred) and determined that it didn't work in practice. Libraries have to use one scheme or the other, nobody made APIs that exposed both schemes, and calling between them was too much of a hurdle. So in practice people ended up settling on a single pointer type, which was -- somewhat surprisingly for the language designers -- the non-refcounted one. And the language got rid of syntax for the refcounted one, and everything became more usable.
I could believe that with more money and resources everything would have been rosy, but my understanding of the facts doesn't particularly support this.
It's because languages are designed to be niche. There are so many languages, that to be used you just need to be good at one or two things.
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.
A well-designed type-inferred statically-typed language either cannot support the following (which is valid Python), or can only do so with tradeoffs that either stretch the definition of "statically-typed", stretch the definition of "well-designed", or would make the language even more intimidating than monads make Haskell:
def fizzbuzz(i):
if i % 3 == 0:
return "fizz"
else if i % 5 == 0:
return "buzz"
else:
return i
for i in range(100):
print(fizzbuzz(i))
Now you might argue that it's a good thing for people to care about proper typing for large, maintainable codebases, and I would agree; in some of the better Python code I've seen, it's social convention to add type signatures in a comment (I once worked at a place where people added Haskell type signatures) and enforce proper typing. And yes, there are a few Python APIs that return either a single item or a list, instead of a one-item list, and they're annoying.
But it's a thing people do, it's especially a thing that's useful in a teaching language or in a scripting language that's trying to fill PHP's niche, and I don't think a language that refuses to type-check such a thing will fit every conceivable need. Sometimes the goal is just to get something done quickly, not be large or maintainable.
>A well-designed type-inferred statically-typed language either cannot support the following (which is valid Python), or can only do so with tradeoffs that either stretch the definition of "statically-typed", stretch the definition of "well-designed", or would make the language even more intimidating than monads make Haskell
You get static types whenever you need them and dynamic flexibility whenever you need it. No need to invoke something Haskelly at all.
For more type checking safety in this particular case, you could also say (or infer) that the return type is a union that's either "String | Integer".
I was talking about a possible very flexible uber-language here. Why would it miss those two oldest tricks in the book, that are already present in tons of existing languages?
That said, I didn't say it would have to express all idioms. Just that it would be applicable for as many domains as possible, from low (drivers, etc), to high (scripting, etc).
This particular idiom, as you also note, I don't find particular useful anyway, but rather a code smell. But if it was needed the two ways described above could solve it without much issue.
When you need to be quick and flexible use "dynamic" type, when you want to be fast and safe and take little memory switch it to a specific type. The language still covers both cases.
import Control.Monad (forM_)
fizzbuzz i | i `mod` 3 == 0 = Left "fizz"
| i `mod` 5 == 0 = Left "buzz"
| otherwise = Right i
main = forM_ [1..100] (\i -> either putStrLn print (fizzbuzz i))
Yeah, that certainly works, but one of Python's particular strengths (and in particular what the original article was about) is a teaching language. I certainly understand what you're doing there, but I wouldn't want to explain it on day 3 of high school CS class. :)
The slightly cleaner thing here would be to take advantage of both strings and integers implementing Show. I'm thinking a bit about whether that would actually work well enough in a teaching language; possibly. (Although if I'm remembering my Haskell well enough, you need to enable existentially quantified types to make this work, which, again not really day-3 material. Probably works fine in like Rust, though.)
It is amazing how much of an IDE a web browser can be. I use typescript these days to prototype stuff and it is going pretty well. Reload and changes are up. Nothing else even comes close.
To some extent. I think pry comes closest to re-creating a truly interactive development experience but the browser is slightly better especially with source maps.
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 beginner a few years ago either but that's where the momentum is now and, as the author says, the ease with which a newbie can get something interactive up on screen trumps smaller concerns. For a little more rigor you can use something like Typescript.
What's pretty funny is that the new features in ES6 and ES7 makes a lot of the patterns/mishaps/X-parts from the last 15 years pretty irrelevant or less-obviously-'the way'.
I think a lot (over 50%) of JavaScript devs 5 years from now will still be using <= ES5, but only because they've so settled in their ways over the last 10 years.
> I think a lot (over 50%) of JavaScript devs 5 years from now will still be using <= ES5, but only because they've so settled in their ways over the last 10 years.
5 years from now, there will still be people whose customers require IE6 support, too. We're still working on that.
> I think a lot (over 50%) of JavaScript devs 5 years from now will still be using <= ES5, but only because they've so settled in their ways over the last 10 years.
Funny, I'd make the opposite prediction... the JavaScript devs I've known have been among the most curious and open-minded developers about different ways of doing things, interested in experimenting with different idioms made available by the flexibility of the fundamental language, and quick to adopt them they found them useful (possibly too quick). They're people who figured out how to get many of the benefits of the language features you've listed above starting with the language features that were available years ago.
Which kindof makes sense: everybody else was too busy complaining about function scope instead of block scope or how they couldn't get their heads around Prototypes instead of Classes or having to reason about this scope or truthy/falsey values or whichever difference/wart scared them off to bother learning to use the tools at hand.
No, my bet would be that ES6 adoption will take up a lot quicker than, say, Python 3.
(and most of the lagging will probably happen around frameworks with imported paradigms -- Angular 1.x, I'm looking at you in particular -- and other aging codebases).
I hope you at least wait until those standards are thoroughly supported "in the wild" because the wild provides the entire point of choosing Javascript. Even then, the argument that ES6+ will make everything better ignores that those standards layer more stuff on top of a lot of bad old stuff that isn't going away. And the community status quo is bad documentation, messy APIs and things breaking all the time. If I did not HAVE to use this stuff I would happily choose to avoid the frustration.
There is no competition to Javascript for programming browsers, but why should programming education always center on programming browsers? For education in particular, there are a number of languages designed for education and Javascript (even ES6) has never been one of them.
Programming education doesn't have to center on browsers, but it's very likely that someone interested in programming as a career in 2015 will have to make programs which interact with browsers in some way. So, while class chicken inherits from Animal and can override Animal's speak() method, that's not quite as fun as having .chicken.animal::after put chicken memes all over your homework.
Visual Basic was also pretty awesome for this, and I'm sad to see that give way to e.g. Java, which has probably turned many people off initially to how fun and rewarding programming can be.
TL;DR public static void main is not as fun as making more internet.
+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
I think this is easier than you think. About 8 years ago I was working on a big project in Qt that was two parts -- one part a 3d rendering engine, one part an interactive web view. Having the two interoperate was surprisingly straightforward, and we could do all kinds of HTML/CSS layouts and use JavaScript hooks to call to the Qt classes. I can't imagine it's regressed much since then, though I'll admit it's been a while since I touched it.
PhoneGap provides this kind of experience for mobile.
The issue always ends up being performance -- running the JS runtimes in sandboxed webviews is always* slower than native code.
Chrome apps are already the desktop mode :) There's also stuff like Chromium Embedded Framework[1] which Atom used to use[2]. AppJS[3] sounds the most similar to what it sounds like you want, though. I've never tried it, but it seems like it'd work well enough (Chromium-based).
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.
Is rigor even that important? Is a flawed and quirky language really a problem when you are learning? I'd expect that keeping the learner's momentum going is more important – if they keep producing they will be able to engage with the crap, or make their own new kinds of crap. Quantity over quality, you know? With that in mind, stuff like developer tools is more important... and maybe community (which is eclectic for Javascript – there's lots of material out there about Javascript, but a lot of it is crap material).
We can have good, rigorous semantics and simple syntax in the same language. Python is, indeed, a good example. Ruby as well. I would even start to say Scheme is a very rigorous language that is quite easy to learn--if you first haven't been tainted by curly-bracket languages and second lived in a world in which there were a Scheme implementation with as many and as complete of a selection of libraries as Python.
A flawed, quirky language is a problem when learning, because it increases the number of things that have to be learned.
But yes, your other points are correct. Tooling is far more important.
> ... a Scheme implementation with as many and as complete of a selection of libraries as Python.
It's not quite the same size, but the Racket standard library is fairly close in size to pythons. It also has better GUI support, IIRC. It's selection of other libraries isn't quite as broad either, but it's decently sized, and you can use some things written for other implementations (well, mainly ones written in pure scheme).
I had used Racket for my personal projects for well into a year. It was a lot of fun, so it definitely filled a good niche for me at the time, but I eventually gave it up as I started to want to be more productive and start finishing projects, rather than just writing any ol' random code.
It is definitely the most complete Scheme available, which I believe is why they gave up the PLT Scheme name, to disassociate from the "bare bones" assumption of Scheme. And yes, it's GUI support is relatively better than Python's. But it's not objectively good. It tends to have mostly bare-minimum implementations of libraries. For example, the work done for connecting to databases is basically nothing more than a DB connection. Web development is basically no more than HTTP request parsing.
There's no Django or Rails or even Express for Racket.
A quirky language might slow a learner's momentum by making it necessary to explain all the quirks. As a simple example, javascript's rules for casting values to boolean is quirkier than scheme's rule in the sense that scheme's rule ("#f passes conditional tests, everything else fails") is shorter to explain than javascript's rule ("NaN, false, 0 etc fail conditional tests, except new Boolean(false) passes it, etc"). As an experienced javascripter I've grown used to the quirky parts of JS, and some of the quirks are even rather convenient; however it's that much more that needs to be explained to the beginner that isn't strictly necessary.
> 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 Raspberry Pi).
Putting a python game on a phone is definitely more of a problem, but at the same time something that is NOT made for a Phone touch controls will anyway perform poorly if you intend to do a demonstration with it.
> 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.
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.
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.
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 make compromises.
Actually, I might no longer even use webapps. Nowadays it is pretty cheap to give every kid a Raspberry PI so WxPython or Pygame can be used for everything. The showing problem boils down to borrowing a monitor, keyboard and mouse. You could actually carry around a small portable bluetooth keyboard and a mouse in your backpack with the Raspberry PI.
So, why stick with Python? It is because Python is a leader in moving up the evolutionary curve towards functional languages and functional reactive programming. I still think that Python is easier to get into that Erlang or Scala because you can "make mistakes" but still have a working program. And by examining the implications of mistakes you have a learning opportunity too. Note that Javascript has been following Python's lead in adding more functional features.
There is a general language evolution going on and Python is in the thick of it, maintaining compatibility with the old imperative style beloved of data crunching scientists along with the functional goodies that Haskell, Erlang and Scala focus on. It is not out of date. It is not mired in the past like PERL and PHP. What was good about Python 5 years ago is still good.
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.
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.
You realize all these "new" concepts you think exist in these "modern" programming languages have been around since the early 1960s, right? MVC Web Apps ugh ... Maybe for some ... I just think there is a class of learner that wants to actually learn about computers and not just show web sites to their friends.
>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.
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.
I don't hear many 13-year-olds wanting a computer with no screen, keyboard, or mouse. I do hear a lot of kids with smartphones who want to play games on them.
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 JavaScript and quickly left python behind for that project). The options are few for back-end web development-- yes, there's Django, but it just doesn't have the clarity, documentation, and community that Rails has, or Wordpress (different type of entity, I know), or many others. Flask is amazing but small in scope and community.
I'm a professional JS developer by day and I used to think JS was awful for teaching, because the functional side of it is nightmarishly confusing IN GENERAL, let alone to someone new to programming. Its objective/prototypal system takes quite a bit of getting used to, also, and it has many other quirks.
But, for the EXACT reasons mentioned in this linked post, I changed my mind. The fact that JS can be used for almost anything nowadays, is ubiquitously in demand, has a massive, massive worldwide "community," and allows easy GUI manipulation via HTML/CSS, makes it the best candidate for teaching by far.
It'll just take some careful consideration as for how to approach it best.
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.)
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 interfere with other people happily using and preferring Python 3 for years now? It is not interfering with you.
> 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
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.
Java was introduced in Netscape Navigator 2 at the same time as JavaScript. But Java was really not integrated with the html at all. It lived in its own isolated box on the page. JavaScript was integrated with html and with the browser environment.
>...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...
Couldn't agree more. Javascript is one of those things that I wish would just go the hell away and be replaced by something that isn't awful.
What we need is some kind of jvm-like VM binary standard that several languages can compile to. Right now that's simply JavaScript, though, but it's not very good for this purpose.
In case anyone hasn't heard of it, Asm.JS is basically trying to turn JavaScript into a similar standard. Combine that with sourcemaps in browser debugger tools and we're really close. I've been using clojurescript recently, and I can even connect a REPL to the browser and make on-the-fly changes just like we've always been able to do with JavaScript.
What I really wish someone would build is this: Create a platform-independent machine language which is designed to be translated into arbitrary other machine languages. Then put the equivalent of FX!32[1] in the browser to translate it to whatever architecture the client is running on. And have a compiler that will compile to both that and to asm.js, with asm.js being used (with consequent lower performance) for legacy browsers.
The point here is that it isn't a VM at all. It's just an intermediary platform-independent binary code. So it doesn't care what kind of language you're compiling from or what kind of hardware it's running on, but it still doesn't need a huge slow insecure runtime environment.
Basically it should do what Java originally tried to do, minus the fatal mistake Java made in tying the bytecode to a specific high level language (and thus all the changes made over the years which have made the JVM big and complicated).
Language of choice for beginners need not mean only language of choice. If Javascript is great to get started with, great. Once someone has that down, they can still continue on to learn C, Haskell, and other more interesting languages that explore CS fundamentals & theory. Or so I would imagine, anyway?
It's not just the browser, people often want to create mobile apps today and there is no standard language that works for all platforms (you can try C# with Xamarin but it is not the native choice of all the platforms). And there is not always good, still developed, standardized UI libraries for every language. Many people starting with programming want to see something on the screen and then you need this. And there is usually some people who wan't to develop serverside web code which should be supported by the same language.
If Xamarin was open source or free I think it with C# would be a great way to start programming. For now Javascript works.
So $25/month is too much for capability to ship on all three mobile platforms - native development - using a shared codebase written in one of the nicest languages (F#/C#) in existence? If you're a startup w/ at least three people in your team just send them a email to work something your in your favour.
Javascript has been around for close to 2 decades. I'm somewhat curious if there's a change in Javascript that has changed your mind, or is it something you think should have been true for the past 10+ years?
just the opposite. Many teachable subjects from Journalisism to data science, biology to finance increasingly include Python. NLTK, Beautiful Soup, Pandas, Ipython Notebook, Matplotlib... Programming is a tool for getting things done, and few languages offer students more tools for doing than Python. On HN we sometimes forget the ubiquity and pure value of automation and anaysis. We focus perhaps too much on software engineering (in this case gaming).
...and some of those things, python isnt any good at.
To be fair, it's very very good at others, but you can't argue with the points he's making. They're spot on.
It turns out, people learning programming in school aren't interested in processing scientific data. They're interested in games. and showing their friends what they've made on their phones.
Python is flat out bad at those things. It was never the intended purpose of python, and it's not a priority for the core team.
Why not teach kids with a tool that excites them, instead of one that frustrates them?
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 important. Having said that packaging a python program into an executable installer or even just an executable is a pain in the ass ("What sane person DOESN'T have at least one working python interpreter?!?").
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.
I have a concern with Python as a teaching language in contexts where people are not necessarily into STEM and are inexperienced or marginally experienced as programmers.
There's no neat and tidy way to deal with Python 2 versus 3. You can say use 2. You can say use 3. You can kick the issue down the road by requiring programming via web browser. But in the end anyone who catches the programming bug winds up facing a decision that even seasoned professionals struggle with.
Python as a teaching language is great for replacing MatLab. After that it entails tradeoffs as fundamental as character encoding. Not that I'm saying JavaScript is the answer.
If I were trying to get someone juiced about programming and solving the problems that MatLab does wasn't a feature the audience cared about, I'd pick Processing. It does interesting things with sound and images and exports to HTML and JavaScript to run in the browser. All that and it's small, well documented and Googles up a low noise search results page. Yet it runs as deep as you want to dive into the JVM and its languages.
I don't think mobile gaming should play a dominant role in teaching programming. (If I wanted to teach that, though, I wouldn't reach for Python, however.)
This is always a hotly debated topic. When I learned to program, I started because I wanted to understand how computers work. Javascript in a Web browser so many layers above the basics of a computer; I just don't think it is a good choice for a first language. Obviously, it depends on your goals. If you are changing careers and you just heard that you can make all this money web consulting and you couldn't care less about computer science then maybe go for Javascript, I don't know much about people who got into programming via that route.
I think Python is probably a useful first programming language for someone interested in doing mathematics or algorithms but I still think, and this is totally against the grain, that C is a good language for beginners to programming. However, it may not be the best language to teach undergrads and expect as many as possible to stick with CS, maybe that is not a terrible thing? Though, that is elitist, I think C provide enough of an abstraction on top of the machine while still allowing you to get some idea of how computers and memory work, from a CS rather than an EE perspective.
The other benefit is that once someone wants to know how to create a game or how to make a GUI program ... the resources are readily available and in fact most of the libraries will be written in either C or C++. I think C over C++ because OOP concepts and syntax of C++ can be needlessly overwhelming for a newcomer to programming.
I feel like it also gives the beginner the feeling of actually creating a program. Those interested in learning to program will always be familiar with normal executables such as EXEs on Windows or binaries that can be executed on Linux. Using C means you can create something just like those programs they are familiar with; it gives the learner a sense of really accomplishing something, in my opinion. Creating something you have to run in conjunction with another program and does not seem like a "typical executable" can leave the user feeling like "OK, how do I create a real program, though?" This is not to knock interpreted languages, at all; it's just something I think is important for some learners.
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 programming for exactly these reasons.
> 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.
Basically that's because you can't bundle c libraries in a zip file like this, so effectively you can't actually use it for any of the reasons you might want to use it.
(.exe bundlers, by comparison, bind the shared library into the executable or with it)
I'm sorry, your comment isn't making clear what teaching programming has to do with distributing graphical applications. Could you clarify what 'these reasons' are?
Teaching intro programming courses with "parse a CSV file" or "implement a text based calculator" is outdated. Modern students have grown up with smart phones and are used to being able to click around and have the computer react graphically. Students learning with C or Python have a large chasm of GUI libraries they have to cross before they can make anything like the UIs they are used to seeing. Being able to make shapes move around from day 1 in a JavaScript course seems like a much more compelling experience to me.
Javascript now has all the major language features Python does. It's not quite as ugly as it used to be. There's strict mode, which disables some of the worst legacy crap. You can use Javascript on servers, desktop clients, and phone clients. Try doing that with Python. Compilers for Javascript generate amazingly fast code today.
Javascript has a tradition of bad, obfuscated code with no comments, but that's not the fault of the language.
(I used Python for years, and prefer it to Javascript. But Python remains limited. Just distributing a Python program is a pain. Yes, there are several systems for making an installable executable from a Python program. They sort of work. It's not considered a standard operation.)
Looks like there is some sort of school of thought that differentiates 'programming' from Computer Science. This seems wrong, because you're not teaching 'how' you're teaching 'what'. The time students spend learning how to write HTML what CSV is, isn't spent on what bool, operators, statements, blocks, procedures are. They're learning 'Web Programming', which won't help them nearly as much when they have to do anything else.
I still recommend Ruby as the first language because it has all of the features you want to know about as a newbie and at the same time there are very few quirks. The things you sacrifice are performance and memory efficiency. I have seen junior programmers picking up Ruby as be able to write production ready code in couple of weeks. I guess the learning curve is not as steep.
I don't think it's a performance and memory issue that the author is raising. Ruby, much like Python, mostly wraps some lower level libraries for game dev. In both cases, you either make sure your users have dependencies installed, or you use one of the clumsy "compiler" solutions that don't always work well.
Consequently, Ruby isn't any better for the author's usage case (kids wanting to learn to write games that are super easily portable). It can be done, but it's not going to be as easy as some of the other languages/toolkits (for that specific usage case).
> for the author's usage case (kids wanting to learn to write games that are super easily portable)
This is an artificial use case. Kids wanting to learn to write games should be concerned with whatever works on the hardware they have available. Portability is premature optimization at this point.
> Portability is premature optimization at this point.
It really isn't. If I am a new developer, you're raining on my parade by telling me that I or my friends will have to jump through a bunch of hoops to run my game.
In the context of learning to program as a younger person, this is a pretty big deal. This is anything but an artificial usage case, and is what the author is specifically looking at (education).
Mobile means stuff looks easier than what really is. If you cannot be bothered to jump through hoops, this is not a career for you. What I recall of my novice days is literally one hoop after the other. It is just that some people enjoy jumping (this particular type of) hoops.
And regarding the social aspect, think of the days of microcomputers before the PC. I am too young to have experienced first hand, but I recall my uncle having a Commodore 64 and letting me use it. What I recall is that he had 2 different circles of friends: the C64 guys he traded knowledge and warez with, and his actual friends who really need to come over home to be shown the new feat (if they were interested at all).
I would not recommend Ruby over Python, as the core languages and libraries make the Ruby API set much larger than Python to do the simplest things. Example: How many APIs do you need to traverse an Enumerable in Ruby versus a a list in Python? I'd suspect it's easier to just learn 1 API for them instead of 20.
For now, if they want to learn something as a start, even though it still has its quirks, write them in Swift. You get a bit of everything plus you can code some UI without the deep diving into ObjC.
I think this author has lost his focus.
Maybe there's only 1 choice if you want something to sit "on top", but anything can interact with "an unprecedentedly ubiquitous cross-platform toolkit for layout, typography, and rendering". Including Python.
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.
It sounds like the goal is to get people programming. That means a combination of teaching them, and getting them excited. Being able to show the thing you created to your friends is a powerful motivator.
If you get excited by showing your friend some silly webpage, but aren't absolutely thrilled by function composition in haskell then you're a coder, not a programmer. You're in the wrong class.
The point of programming classes should not be to hide what programming is and show this silly mockery of it which javascript is. It shouldn't veil true programming issues, like correctly reasoning about the structure of your code, with a language which makes it easy to code in without ever programming.
If you need to motivate someone to be a programmer, they should not be one at all. They should not be going on to write poorly implemented software because they didn't have a passion for implementing proper reference counting in a legacy C codebase, but instead wanted to write an iPhone app for their friends.
If you need to motivate someone to be a programmer by teaching them to draw on a canvas or manipulate the dom, rather than teaching them the wonders of basic lambda calculus, then you're doing them a massive disservice by using the word "programming" to refer to something else entirely.
You are completely assuming that everyone who wants to program is intending to do so professionally, or that they won't be able to grow from a basic intro of "here is how to present your thoughts programmatically" and then cover the deeper subjects later, as they need to.
This is especially relevant as we start teaching programming at younger and younger ages. I hope it's obvious that when kids start programming in 4th grade, it's much more intuitive to start them on Logo than lambda calculus...
It's rants like these that really harm the perception of the functional programming community. It just portrays you as the archetypal 'misunderstood genius' trying to show everyone in the world how wrong they are and how only the 'true programmers' do what you think is right. Yet none of this is backed up by evidence that the benefits of functional programming lead to better software.
Yet none of this is backed up by evidence that the benefits of functional programming lead to better software.
Amen. I've been hearing exactly these kinds of grandiose claims from FP advocates going back as far as 1998. The funny thing is, the same people almost never seem to getting around to actually writing any code of any substance. As far as I'm concerned there are some good ideas coming from the FP community but the more extreme implementations of FP like Haskell have yet to prove their worth in production environments.
While I disagree with the author that this is the penultimate goal that should be overriding all other concerns. I'll bite for the sake of discussion. If that's the goal then Javascript was obliterated before the OP woke up to write this ill-conceived blog.
What people are building with Python on Kivy (chose the nearest example)-
I do give the author credit for not contorting the page into an eye cancer causing abomination like most web developers are doing these days. While he's espousing JS, oddly enough he may share my preference for a web that's as JS-light as possible. :)
But our professor does already have something to show his friends! So download your full blown games, accepted into the AppStore (or Google Play) to show your pals what you built. Then pass out your little URL. Let me know how thrilled they are then.
In sum, if you're looking for a great general purpose PL to start with and maybe grow with, with plenty of ways to build cool stuff- Always Bet On Python.
Just because someone doesn't have a javascript heavy blog (which is designed to be mostly text) in no way means they think must think the whole web should be kept JS-light, or that JS isn't a worthwhile technology to build interactive applications with. They could believe in an appropriate use of technologies.
There are plenty of technologies for getting JS based apps into app stores, just as there is for Python based apps.
If your argument is is "Here is a highly interactive Python app and a low interactive blog post, therefore Python is more compelling" then:
I agree that some of the arguments such as library longevity and health are debatable, but in terms of being able to get your application out to people, JS undoubtedly wins.
Yeah, unfortunately the discussion was around getting people to program so they had something to show others. Not getting your application out there to as many people as possible. Sounds like a kneejerk defense of your chosen platform than honest contribution to me.
Not that you've proven this new point either.
At $99 per student for impact.js just to learn on, I think the only thing undoubted is that you're desperately grasping for straws.
Paid software compared to Python's ecosystem that provides something better for free. Along with more varied libraries, and a better language too. Maybe as a teacher you could buy just one copy and pop the hood and show them that source code on how this is built.. oh wait, it's not open source.
Also the slight snag that impact.js doesn't have support for Android. Which happens to be the largest mobile platform in the world. For only $99.99! You may as well have sent me Xamarin to compare with Kivy and tell me how C# was the way to go.
Use what you want to teach with. But using these harebrained reasons concocted as to why you'd want to push something like JS over a PL of Python's caliber make no sense at all.
I agree. As a beginner - and even as a professional, in an average-case situation - what you need in terms of abstractive power and optimization potential tends to be something akin to a classic microcomputer Basic, plus some modern API calls. You're already way ahead of the game when you consider JS in that light. You can write a lot of practical, maintainable JS that only uses arithmetic, string manipulation, branches, loops, arrays and simple function calls. POD objects, too, if you get a little more fancy.
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.
You can program in Python using Kivy [1] to create apps for Android, iOS, and the desktop. I made a simple app and took it through the entire process it is now on the Android app store. You are still using Python so you can focus on programming and not language features, but you get the benefits of programming something your students can show off.
I figured this out when I was teaching my nephew programming. I started him on Python. He got bored quickly because he really couldn't see the results of what he did and he really wanted to make simple games.
Javascript turned out to be much better for making simple games and doing simple puzzles.
This works, today, in all browsers. Adding "forEach" to the proto chain of HTMLCollection would make this code no longer work, so no browser is willing to add it for fear of breaking sites.
The answer is to stop using HTMLCollection.
What's worse is that NodeList doesn't have this named-lookup issue, but putting Array.prototype on its proto chain (the obvious simplest way to get all the array goodies) again breaks websites, because some people uses "instanceof Array" to assume things about how an object will interact with Array.prototype.concat.
Long story short, making improvements to the DOM is very hard because of the two decades of weird website hacks that are supposed to not get broken in the process...
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.
I'm sorry to come off as harsh, but I -- without any joke -- thought I would have better things to do with my time on this planet than deal with some scumbag's Perl 5 code. I don't think the solution to the "shitbrain writing Perl" problem is more Perl. Fuck that in the ass.
Well, you say, isn't that a problem in every language?
Perhaps. But I don't have to deal with it in every language. And every other language seems to have a type system that will let me know when something idiotic is being done, or exception handling, or "well, that pointer was null, so I'm done for the day" behavior that Perl doesn't have.
And as I've (sometimes reluctantly) given up on old relationships I'd invested a lot of time in as being not for me, or anyone for that matter, so is fucking Perl. It's not FOR ANYONE.
One reason I haven't learned how to write web apps is because (sorry, but) I consider the web-app software ecosystem to be not very good. One of the modern web's defects relative other "software ecosystems" is that it is too specialized IMHO for media consumption, media distribution, entertaining and being entertained and persuading and being persuaded by "emotional" appeals (more precisely, appeals to System I rather than System II). Another one of its defects is that it is more complex (and consequently harder to adapt to new situations and new purposes) than most other software ecosystems.
The topic under discussion is what programming language (and by extension, what programming environment and what software stack) to recommend to beginners. Here is my suggestion: it depends on whether the beginner has the kind of mind that can stay engaged while alone and while staring at a white screen containing only black text all day. If the beginner can do so, then I suggest that Emacs (the version from the FSF) is the best software stack for most beginners to learn.
Emacs is often considered complex, but its complexity is of a different kind than the complexity of the modern web. Emacs consists of a small core that anyone would have to master to be able to modify Emacs and to build upon Emacs and a large amount of optional add-ons. This kind of complexity is more acceptable than the kind of complexity the web has as long as the beginner is competent enough at deciding which optional add-ons are worthy of his attention. In the case of Emacs, 95% of them are probably not. (More on this 3 paragraphs down.)
Most of the changes I want to make to my personal software environment (as a heavy Emacs user and experienced Emacs-Lisp programmer) can be made in Emacs. In other words, Emacs is a kind of non-proprietary "middleware" just as the web is a kind of middleware (which is admittedly non-proprietary in the parts most essential for a beginning programmer) and just as terminal-emulation apps plus TTYs and PTYs plus ssh plus the ncurses library and cursor-address using ANSI terminal codes is a kind of non-proprietary middleware on which a wide range of software applications (or the user interfaces of the applications) can be built. And I recommend Emacs over the "platform" consisting of terminals, TTYs, cursor-addressing and traditional Unix shells (including rc) because (very briefly) that platform has too many of it design decisions came out of an environment so constricted in computing resources as to be mostly irrelevant for today and because the common mouse idioms really did represent an advance in the state of the user-experience-design art. Hey, since I've already risked offending a large HN contingent (web programmers), why not risk offending a second large contingent (those who like apps that use a terminal for interacting with the user)!
I am aware that not all prospective programmers can stay engaged while staring at plain text all day. They would get bored. To stay engaged, they need more stimulation, e.g., colors, graphical elements, things that move around on the screen (or they need a social element, social interaction being very stimulating for humans). For them, maybe the web is the best environment in which to learn how to program (since it is difficult to learn programming while continuously staying engaged socially). I concede that I have not really studied the issue, so I am (provisionally) willing to believe the general consensus on this page -- but only when it comes to beginners who cannot stay engaged while staring at plain text all day.
Since 95% of Emacs's add-ons (including almost everything in ELPA and MELPA and much of what is distributed in the Emacs app itself) is not worth learning or embracing, perhaps I should add to my recommendation of Emacs the further recommendation that before tackling Emacs, the beginner should first explore and learn how to use OS X so as to give him o...
I did not sufficiently explain what I mean above by including "traditional Unix shells" in the list of things over which using Emacs is preferred.
In my .emacs are calls to such Unix "command line" programs as Rscript, OS X's open, sudo, rm, gzip, chown, chmod, /opt/mozilla/bin/firefox, OS X's screencapture, fetchmail, OS X's system_profiler, shutdown, ping, ps and growlnotify.
A popular and very much traditional way to call such programs (even in languages like Ruby) is via a traditional Unix shell (invoked usually in languages like C, Perl and Ruby by the "system" function), but there is no need to do that. In emacs for example, one can bypass the Unix shells by writing something like (call-process "sudo" "mv" "-i" "/foo" "/bar"). call-process in turn does a fork and exec and the exec gets the command name (in this case "sudo") and the command's arguments (here, "mv" "-i" "/foo" "/bar").
Actually, "sudo" might have been a bad example because for all it know is implemented by calling out to a traditional Unix shell (though one can certainly implement it without doing so). I'm not a purist striving to eliminate every use of a traditional Unix shell on my machine -- that would be a waste of my time.
Point is, I do not write shell functions and shell scripts anymore -- I write Emacs Lisp code instead.
I used to make heavy use of traditional Unix shells and other parts of "TTY world": from 1997 to 2005 or so, my only interaction with my computer, a Linux box, was via the Linux console. For the 5 years before that my only interaction with Unix and with the internet was through an old-school actual terminal and (later) and IBM PC XT running a terminal-emulation app and almost no other apps. But I've discovered, slowly over the years, that I'm happier writing Emacs Lisp even for things that are traditionally done with shell scripts and with shell functions defined in ~/.bashrc.
For many experienced Emacs users, Emacs is just another component of "TTY world". these users typically use Emacs in "text mode" or in "-nw mode" (i.e., without a windowing system) and perhaps they use shell mode, eshell mode or ANSI-Term mode, all of which pretty much require the use of a traditional Unix shell. But it's not difficult to use Emacs without making constant use of the components of TTY world.
237 comments
[ 2.6 ms ] story [ 264 ms ] threadHowever, 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 teachers should make a habit of pointing out that writing code is a journey that will require students to learn new tools all the time.
Not that I disagree, but could you elaborate your reasoning here?
Even objectively, a good language to write an OS kernel in isn't necessarily equally well suited to, say, game development, or web development, or scientific computing. That doesn't mean there won't be heroic efforts to make a language work in every arena, but at some point most people draw a line based on pragmatism.
Also, often overlooked, there is the aspect of a language mapping well to a given developer's brain. Different people are drawn to different languages for different reasons, including borderline-intangible ones where they just feel more "at home", which translates into tangible outcomes like productivity.
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).
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.
I find that less and less true. The canonical example for me are abstract data types. They're pretty much free on a runtime level, enable clean code, and allow for more static checking. Basically a superpowered version of enums. I can't see any argument against having it in the language unless the express goal is to have no syntax (lisp).
One of the basic mistakes made here seems to be the notion "if programmers only _knew_ about the one true way of doing it, they'd all use the same language and tools, namely: mine".
In the real world, 90% of programmers use either C#, Java, C/C++, JS or Python/Ruby/Perl in their jobs.
We could restrict ourselves to this set of languages and syntax style, and design a super-set language that does everything, gets rid of their historical warts, and can go from scripting to HPC.
Stuff like using significant whitespace or not, are BS bikeshedding, which we can bypass.
The thing is, were it matters (speed, expressivity, availability of REPL and IDE, large SDK) nothing but money prevents us from making such a language...
Is there anything preventing a top notch team working for 10 years and come with one ready, including all the trims and works, JIT, AOT native compiler, ports to 2-3 architectures, batteries et al?
Sure, some people would still like their Java or their Lisp or whatever.
But there's not some logical impossibility preventing us from creating a language that's better for 90% of the tasks than what's our there.
In a sense, that's what MS did with C# -- but they stopped too soon because they have their own agenda. So it was Windows only, in the CLR with no supported AOT option, etc.
There is no need for passive aggressiveness. I get that aping the exact phrase used in a parent comment is used to communicate disrespect, and it's duly noted, but all things being equal I would prefer not to go down that route.
My argument here is that people designing languages have made choices based on their personal preference as well. It's not really appropriate to take one specific set of features you like and declare it to be the objective winner.
> In the real world, 90% of programmers use either C#, Java, C/C++, JS or Python/Ruby/Perl in their jobs.
That's a No True Scotsman-like argument. Also, what's the meaning of the three different types of separators you used there? But for the sake of convergence, yes, let's assume every important real-world language is in that list.
I'm still not sure what to say about this without repeating myself, except for: go and do it. You say it's a matter of investment, but on the other hand consider the benefits if someone pulled it off. If you really do believe you are the person who has this all figured out, please go ahead and implement this. Heck, make it a Kickstarter project or something, I'm in!
What passive aggresiveness and/or disrespect?
The repeat is used to communicate disagreement with a specific thing attributed to what I said. Since it was attributed twice, with no regard to the arguments I made, it was mostly necessary.
If anything is "passive agressive" is this sudden ad-hominen and armchair psychology attempt.
I only responded to the abstract issue under discussion, didn't made any judgements on the participants. Can we keep it at that level?
And my point is that I'm not doing that, I'm not picking features based on personal preference (my actual preferences are different), but to describe how a language can encompass the whole range of applications (be the right tool for most jobs, as much as possible).
This wasn't about "my dream language" (that would be something like Smalltalk) but about whether a language can cover all/most bases or we're forever doomed to use a babel tower of "right tools for the right job".
And the "cover all bases" thing I tried to tackle from a technical features standpoint. At this conceptual level of the argument I don't even care much if programmers will like the end result.
>That's a No True Scotsman-like argument
No, it's just a statistical observation. 90% of programmers do use this languages. I don't say the rest are not programmers or not true programmers -- just that we can cover the majority of programmers doing professional work with a language in that vein.
>I'm still not sure what to say about this without repeating myself, except for: go and do it. You say it's a matter of investment, but on the other hand consider the benefits if someone pulled it off. If you really do believe you are the person who has this all figured out, please go ahead and implement this. Heck, make it a Kickstarter project or something, I'm in!
Now, that's disrespect and passive agressiveness!
I never said it's just me that "has all that figured out". In fact lots of people say the same thing, inside every language community there's a trying to fix the same pain points to make each language more universal.
Lots of Python people for example wanted to make it GIL-less / capable of good async operation / faster / typed / etc. All this is for handling different kinds of scenarios that it currently does not.
People using JS asked for more speed, then for server side/native interfacing (Node et co), then for "programming at large" features (ES6) etc, types, things like asm.js to get native memory management, etc.
So, what I wrote was that having a language extend to almost all jobs is not impossible, and gave a laundry list of features (taken from observations such as the above), that could accomplish that.
NGEN was there since day one.
Spec#, Singularity systems programing language (based on C#) only has AOT compilation to native code.
This work was the basis of Windows Phone 8 .NET, that only compiles to native code, in a PE format known as MDIL.
This work was then continued to bring static code compilation to the Windows 8 for tablets and now for desktop store apps.
It is part of the upcoming .NET 4.6.
The only deployment format not supported for static code compilation are the traditional desktop and the compact framework.
Parallel to this work, the Dafny the systems programming language for Ironclad,Singularity's successor, also produces static executables.
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.
If I understood you correctly, your position is the inverse of that thesis. You argue that there is a base abstraction that should work equally well in every context, and that specialization could come in the form of optionals piled on top of the one true base. There is no mathematical reason why this should be unworkable, but a solution so far eludes both programmers and evolutionary processes alike. That doesn't mean you shouldn't go ahead and try solving it. It's a worthy project. If you believe you can come up with common denominators that cover all aspects of all previous languages, by all means: give it a try!
And yet, nature already has "converged" sort of into humans, who are "master of all trades" sort of, and somewhat analogous to the "full-spectrum language" I'm talking about.
And as with that language and other languages, the existence of humans doesn't mean all other lifeforms will perish or dissapear.
>* There is no mathematical reason why this should be unworkable, but a solution so far eludes both programmers and evolutionary processes alike.*
Well, for evolutionary processes we have humans. And soon, if we are to believe some pundits, the "singularity".
As for languages, we have some near damn all rounders, but my observation is that it's not because it has "eluded programmers" that we don't have it, but because of business reasons (e.g. some company wants to only target segment X), oss being underfunded, narrow scope, etc.
Programming languages are designed in a huge, multi-dimensional space. Should the language be static or dynamically typed (or optionally typed)? Interpreted or compiled (or JIT'd)? Manually memory managed or gc'd? Powerful or simple type system? Large (C++) or small (scheme)? Batteries included? Hosted on a runtime?
Each of those questions (and of the dozens more than go into designing a language) involves tradeoffs. Manual memory management makes a language suitable for domains like kernels and games, but inevitably requires the user be aware of where and how memory is being allocated and deallocated. Small dynamically typed programs tend to be (in my experience) faster and simpler to write, but static typing makes maintain large codebases much easier.
I strongly believe there will never be a language that is the best available for all domains. Currently I find that I need three languages to cover my bases:
I'm hoping that Rust will collapse the last two, but there are still a lot of tradeoffs.Well, you could make 2 compilers for languages with the same syntax, and 2 sets of libraries (GC and no-GC) with mostly the same APIs, divergent only in whether they have GC or not.
For low level stuff you use "GCLESSLANG" (as a better C) and for the other stuff you use "GCLANG".
Otherwise the 99% of the syntax is the same, and the 2 langs are designed to easily call into one another. They could share most of the parser and compiler too.
This would basically give you the feel that you use one and the same language, switching between GC and no-GC version.
It's a money and resources thing, not some "cannot make this work" thing.
I could believe that with more money and resources everything would have been rosy, but my understanding of the facts doesn't particularly support this.
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.
But it's a thing people do, it's especially a thing that's useful in a teaching language or in a scripting language that's trying to fill PHP's niche, and I don't think a language that refuses to type-check such a thing will fit every conceivable need. Sometimes the goal is just to get something done quickly, not be large or maintainable.
A statically typed language can still have a generic type. C# for example has dynamic: https://msdn.microsoft.com/en-us/library/dd264736.aspx, and Objective-C has id.
You get static types whenever you need them and dynamic flexibility whenever you need it. No need to invoke something Haskelly at all.
For more type checking safety in this particular case, you could also say (or infer) that the return type is a union that's either "String | Integer".
I was talking about a possible very flexible uber-language here. Why would it miss those two oldest tricks in the book, that are already present in tons of existing languages?
That said, I didn't say it would have to express all idioms. Just that it would be applicable for as many domains as possible, from low (drivers, etc), to high (scripting, etc).
This particular idiom, as you also note, I don't find particular useful anyway, but rather a code smell. But if it was needed the two ways described above could solve it without much issue.
When you need to be quick and flexible use "dynamic" type, when you want to be fast and safe and take little memory switch it to a specific type. The language still covers both cases.
The slightly cleaner thing here would be to take advantage of both strings and integers implementing Show. I'm thinking a bit about whether that would actually work well enough in a teaching language; possibly. (Although if I'm remembering my Haskell well enough, you need to enable existentially quantified types to make this work, which, again not really day-3 material. Probably works fine in like Rust, though.)
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 beginner a few years ago either but that's where the momentum is now and, as the author says, the ease with which a newbie can get something interactive up on screen trumps smaller concerns. For a little more rigor you can use something like Typescript.
Examples:
It's a whole new ball game.I think a lot (over 50%) of JavaScript devs 5 years from now will still be using <= ES5, but only because they've so settled in their ways over the last 10 years.
5 years from now, there will still be people whose customers require IE6 support, too. We're still working on that.
Funny, I'd make the opposite prediction... the JavaScript devs I've known have been among the most curious and open-minded developers about different ways of doing things, interested in experimenting with different idioms made available by the flexibility of the fundamental language, and quick to adopt them they found them useful (possibly too quick). They're people who figured out how to get many of the benefits of the language features you've listed above starting with the language features that were available years ago.
Which kindof makes sense: everybody else was too busy complaining about function scope instead of block scope or how they couldn't get their heads around Prototypes instead of Classes or having to reason about this scope or truthy/falsey values or whichever difference/wart scared them off to bother learning to use the tools at hand.
No, my bet would be that ES6 adoption will take up a lot quicker than, say, Python 3.
(and most of the lagging will probably happen around frameworks with imported paradigms -- Angular 1.x, I'm looking at you in particular -- and other aging codebases).
There is no competition to Javascript for programming browsers, but why should programming education always center on programming browsers? For education in particular, there are a number of languages designed for education and Javascript (even ES6) has never been one of them.
No accounting for taste, I guess.
Visual Basic was also pretty awesome for this, and I'm sad to see that give way to e.g. Java, which has probably turned many people off initially to how fun and rewarding programming can be.
TL;DR public static void main is not as fun as making more internet.
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
PhoneGap provides this kind of experience for mobile.
The issue always ends up being performance -- running the JS runtimes in sandboxed webviews is always* slower than native code.
1. https://code.google.com/p/chromiumembedded/ 2. http://blog.atom.io/2014/05/06/atom-is-now-open-source.html 3. http://appjs.com
A flawed, quirky language is a problem when learning, because it increases the number of things that have to be learned.
But yes, your other points are correct. Tooling is far more important.
It's not quite the same size, but the Racket standard library is fairly close in size to pythons. It also has better GUI support, IIRC. It's selection of other libraries isn't quite as broad either, but it's decently sized, and you can use some things written for other implementations (well, mainly ones written in pure scheme).
It is definitely the most complete Scheme available, which I believe is why they gave up the PLT Scheme name, to disassociate from the "bare bones" assumption of Scheme. And yes, it's GUI support is relatively better than Python's. But it's not objectively good. It tends to have mostly bare-minimum implementations of libraries. For example, the work done for connecting to databases is basically nothing more than a DB connection. Web development is basically no more than HTTP request parsing.
There's no Django or Rails or even Express for Racket.
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 Raspberry Pi).
Putting a python game on a phone is definitely more of a problem, but at the same time something that is NOT made for a Phone touch controls will anyway perform poorly if you intend to do a demonstration with it.
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
Yes, there is still the issue of response time but no language works for everything. You have to accept certain limitations and make compromises.
Actually, I might no longer even use webapps. Nowadays it is pretty cheap to give every kid a Raspberry PI so WxPython or Pygame can be used for everything. The showing problem boils down to borrowing a monitor, keyboard and mouse. You could actually carry around a small portable bluetooth keyboard and a mouse in your backpack with the Raspberry PI.
So, why stick with Python? It is because Python is a leader in moving up the evolutionary curve towards functional languages and functional reactive programming. I still think that Python is easier to get into that Erlang or Scala because you can "make mistakes" but still have a working program. And by examining the implications of mistakes you have a learning opportunity too. Note that Javascript has been following Python's lead in adding more functional features.
There is a general language evolution going on and Python is in the thick of it, maintaining compatibility with the old imperative style beloved of data crunching scientists along with the functional goodies that Haskell, Erlang and Scala focus on. It is not out of date. It is not mired in the past like PERL and PHP. What was good about Python 5 years ago is still good.
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.
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.
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.
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 JavaScript and quickly left python behind for that project). The options are few for back-end web development-- yes, there's Django, but it just doesn't have the clarity, documentation, and community that Rails has, or Wordpress (different type of entity, I know), or many others. Flask is amazing but small in scope and community.
I'm a professional JS developer by day and I used to think JS was awful for teaching, because the functional side of it is nightmarishly confusing IN GENERAL, let alone to someone new to programming. Its objective/prototypal system takes quite a bit of getting used to, also, and it has many other quirks.
But, for the EXACT reasons mentioned in this linked post, I changed my mind. The fact that JS can be used for almost anything nowadays, is ubiquitously in demand, has a massive, massive worldwide "community," and allows easy GUI manipulation via HTML/CSS, makes it the best candidate for teaching by far.
It'll just take some careful consideration as for how to approach it best.
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.)
If you don't want to use Python 3, keep using Python 2 through its EOL in 2020+ but why interfere with other people happily using and preferring Python 3 for years now? It is not interfering with you.
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
But can I use it to build microservices?
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.
Couldn't agree more. Javascript is one of those things that I wish would just go the hell away and be replaced by something that isn't awful.
The point here is that it isn't a VM at all. It's just an intermediary platform-independent binary code. So it doesn't care what kind of language you're compiling from or what kind of hardware it's running on, but it still doesn't need a huge slow insecure runtime environment.
Basically it should do what Java originally tried to do, minus the fatal mistake Java made in tying the bytecode to a specific high level language (and thus all the changes made over the years which have made the JVM big and complicated).
[1] http://en.wikipedia.org/wiki/FX!32
> The point here is that it isn't a VM at all. It's just an intermediary platform-independent binary code.
PNaCl ?
Well, minus the asm.js, which I kind of wish I'd thought of at the time.
Free for open source () => http://resources.xamarin.com/open-source-contributor.html
re: if free
Free for students () => https://xamarin.com/student
re: if cheaper
So $25/month is too much for capability to ship on all three mobile platforms - native development - using a shared codebase written in one of the nicest languages (F#/C#) in existence? If you're a startup w/ at least three people in your team just send them a email to work something your in your favour.
...and some of those things, python isnt any good at.
To be fair, it's very very good at others, but you can't argue with the points he's making. They're spot on.
It turns out, people learning programming in school aren't interested in processing scientific data. They're interested in games. and showing their friends what they've made on their phones.
Python is flat out bad at those things. It was never the intended purpose of python, and it's not a priority for the core team.
Why not teach kids with a tool that excites them, instead of one that frustrates them?
0. http://www.panda3d.org/manual/index.php/Main_Page
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.
There's no neat and tidy way to deal with Python 2 versus 3. You can say use 2. You can say use 3. You can kick the issue down the road by requiring programming via web browser. But in the end anyone who catches the programming bug winds up facing a decision that even seasoned professionals struggle with.
Python as a teaching language is great for replacing MatLab. After that it entails tradeoffs as fundamental as character encoding. Not that I'm saying JavaScript is the answer.
If I were trying to get someone juiced about programming and solving the problems that MatLab does wasn't a feature the audience cared about, I'd pick Processing. It does interesting things with sound and images and exports to HTML and JavaScript to run in the browser. All that and it's small, well documented and Googles up a low noise search results page. Yet it runs as deep as you want to dive into the JVM and its languages.
I think Python is probably a useful first programming language for someone interested in doing mathematics or algorithms but I still think, and this is totally against the grain, that C is a good language for beginners to programming. However, it may not be the best language to teach undergrads and expect as many as possible to stick with CS, maybe that is not a terrible thing? Though, that is elitist, I think C provide enough of an abstraction on top of the machine while still allowing you to get some idea of how computers and memory work, from a CS rather than an EE perspective.
The other benefit is that once someone wants to know how to create a game or how to make a GUI program ... the resources are readily available and in fact most of the libraries will be written in either C or C++. I think C over C++ because OOP concepts and syntax of C++ can be needlessly overwhelming for a newcomer to programming.
I feel like it also gives the beginner the feeling of actually creating a program. Those interested in learning to program will always be familiar with normal executables such as EXEs on Windows or binaries that can be executed on Linux. Using C means you can create something just like those programs they are familiar with; it gives the learner a sense of really accomplishing something, in my opinion. Creating something you have to run in conjunction with another program and does not seem like a "typical executable" can leave the user feeling like "OK, how do I create a real program, though?" This is not to knock interpreted languages, at all; it's just something I think is important for some learners.
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.
> 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.
(.exe bundlers, by comparison, bind the shared library into the executable or with it)
Javascript now has all the major language features Python does. It's not quite as ugly as it used to be. There's strict mode, which disables some of the worst legacy crap. You can use Javascript on servers, desktop clients, and phone clients. Try doing that with Python. Compilers for Javascript generate amazingly fast code today.
Javascript has a tradition of bad, obfuscated code with no comments, but that's not the fault of the language.
(I used Python for years, and prefer it to Javascript. But Python remains limited. Just distributing a Python program is a pain. Yes, there are several systems for making an installable executable from a Python program. They sort of work. It's not considered a standard operation.)
Consequently, Ruby isn't any better for the author's usage case (kids wanting to learn to write games that are super easily portable). It can be done, but it's not going to be as easy as some of the other languages/toolkits (for that specific usage case).
This is an artificial use case. Kids wanting to learn to write games should be concerned with whatever works on the hardware they have available. Portability is premature optimization at this point.
Mobile might be an artificial use case or a premature optimization, but it is solved with his choice of JS.
It really isn't. If I am a new developer, you're raining on my parade by telling me that I or my friends will have to jump through a bunch of hoops to run my game.
In the context of learning to program as a younger person, this is a pretty big deal. This is anything but an artificial usage case, and is what the author is specifically looking at (education).
Mobile means stuff looks easier than what really is. If you cannot be bothered to jump through hoops, this is not a career for you. What I recall of my novice days is literally one hoop after the other. It is just that some people enjoy jumping (this particular type of) hoops.
And regarding the social aspect, think of the days of microcomputers before the PC. I am too young to have experienced first hand, but I recall my uncle having a Commodore 64 and letting me use it. What I recall is that he had 2 different circles of friends: the C64 guys he traded knowledge and warez with, and his actual friends who really need to come over home to be shown the new feat (if they were interested at all).
For now, if they want to learn something as a start, even though it still has its quirks, write them in Swift. You get a bit of everything plus you can code some UI without the deep diving into ObjC.
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.
The point of programming classes should not be to hide what programming is and show this silly mockery of it which javascript is. It shouldn't veil true programming issues, like correctly reasoning about the structure of your code, with a language which makes it easy to code in without ever programming.
If you need to motivate someone to be a programmer, they should not be one at all. They should not be going on to write poorly implemented software because they didn't have a passion for implementing proper reference counting in a legacy C codebase, but instead wanted to write an iPhone app for their friends.
If you need to motivate someone to be a programmer by teaching them to draw on a canvas or manipulate the dom, rather than teaching them the wonders of basic lambda calculus, then you're doing them a massive disservice by using the word "programming" to refer to something else entirely.
This is especially relevant as we start teaching programming at younger and younger ages. I hope it's obvious that when kids start programming in 4th grade, it's much more intuitive to start them on Logo than lambda calculus...
See, for example: https://neil.fraser.name/news/2013/03/16/
Also, if you look at the amount of money that "Flappy Bird" made, perhaps making brain-dead iPhone apps isn't such a bad deal...
It's rants like these that really harm the perception of the functional programming community. It just portrays you as the archetypal 'misunderstood genius' trying to show everyone in the world how wrong they are and how only the 'true programmers' do what you think is right. Yet none of this is backed up by evidence that the benefits of functional programming lead to better software.
Amen. I've been hearing exactly these kinds of grandiose claims from FP advocates going back as far as 1998. The funny thing is, the same people almost never seem to getting around to actually writing any code of any substance. As far as I'm concerned there are some good ideas coming from the FP community but the more extreme implementations of FP like Haskell have yet to prove their worth in production environments.
Huh?
What is your definition of proving worth in a production environment?
Did you hear recently about bond? It's written in haskell by Microsoft and used in Xbox Live as well as other infrastructure.
There's also facebooks Haxl...
Remember Bump file/etc transfers in Samsung Galaxy commercials? That was written in haskell too.
What people are building with Python on Kivy (chose the nearest example)-
https://itunes.apple.com/us/app/deflectouch/id505729681?mt=8
Vs.
What people are building on the webstack (also chose the nearest example)-
http://prog21.dadgum.com/203.html
I do give the author credit for not contorting the page into an eye cancer causing abomination like most web developers are doing these days. While he's espousing JS, oddly enough he may share my preference for a web that's as JS-light as possible. :) But our professor does already have something to show his friends! So download your full blown games, accepted into the AppStore (or Google Play) to show your pals what you built. Then pass out your little URL. Let me know how thrilled they are then.
In sum, if you're looking for a great general purpose PL to start with and maybe grow with, with plenty of ways to build cool stuff- Always Bet On Python.
There are plenty of technologies for getting JS based apps into app stores, just as there is for Python based apps.
If your argument is is "Here is a highly interactive Python app and a low interactive blog post, therefore Python is more compelling" then:
What people are building with Python-
http://learnpythonthehardway.org/book/ex1.html
Vs.
What people are building on the webstack-
https://itunes.apple.com/us/app/biolab-disaster/id433062854
I agree that some of the arguments such as library longevity and health are debatable, but in terms of being able to get your application out to people, JS undoubtedly wins.
Not that you've proven this new point either. At $99 per student for impact.js just to learn on, I think the only thing undoubted is that you're desperately grasping for straws.
Paid software compared to Python's ecosystem that provides something better for free. Along with more varied libraries, and a better language too. Maybe as a teacher you could buy just one copy and pop the hood and show them that source code on how this is built.. oh wait, it's not open source. Also the slight snag that impact.js doesn't have support for Android. Which happens to be the largest mobile platform in the world. For only $99.99! You may as well have sent me Xamarin to compare with Kivy and tell me how C# was the way to go.
Use what you want to teach with. But using these harebrained reasons concocted as to why you'd want to push something like JS over a PL of Python's caliber make no sense at all.
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.
[1] http://kivy.org/docs/gettingstarted/intro.html
Javascript turned out to be much better for making simple games and doing simple puzzles.
- No pointers
- No cache
- No branch predictor
- No interrupts
- No endianness
- No alignment
What exactly are we teaching students to program? It's certainly not a computer.
The answer is to stop using HTMLCollection.
What's worse is that NodeList doesn't have this named-lookup issue, but putting Array.prototype on its proto chain (the obvious simplest way to get all the array goodies) again breaks websites, because some people uses "instanceof Array" to assume things about how an object will interact with Array.prototype.concat.
Long story short, making improvements to the DOM is very hard because of the two decades of weird website hacks that are supposed to not get broken in the process...
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.
Today, you could use almost any language for that.
Thanks, people who got stuck with Perl 5 code and now have to deal with it. May the whole concept die in a fire.
Well, you say, isn't that a problem in every language?
Perhaps. But I don't have to deal with it in every language. And every other language seems to have a type system that will let me know when something idiotic is being done, or exception handling, or "well, that pointer was null, so I'm done for the day" behavior that Perl doesn't have.
And as I've (sometimes reluctantly) given up on old relationships I'd invested a lot of time in as being not for me, or anyone for that matter, so is fucking Perl. It's not FOR ANYONE.
One reason I haven't learned how to write web apps is because (sorry, but) I consider the web-app software ecosystem to be not very good. One of the modern web's defects relative other "software ecosystems" is that it is too specialized IMHO for media consumption, media distribution, entertaining and being entertained and persuading and being persuaded by "emotional" appeals (more precisely, appeals to System I rather than System II). Another one of its defects is that it is more complex (and consequently harder to adapt to new situations and new purposes) than most other software ecosystems.
The topic under discussion is what programming language (and by extension, what programming environment and what software stack) to recommend to beginners. Here is my suggestion: it depends on whether the beginner has the kind of mind that can stay engaged while alone and while staring at a white screen containing only black text all day. If the beginner can do so, then I suggest that Emacs (the version from the FSF) is the best software stack for most beginners to learn.
Emacs is often considered complex, but its complexity is of a different kind than the complexity of the modern web. Emacs consists of a small core that anyone would have to master to be able to modify Emacs and to build upon Emacs and a large amount of optional add-ons. This kind of complexity is more acceptable than the kind of complexity the web has as long as the beginner is competent enough at deciding which optional add-ons are worthy of his attention. In the case of Emacs, 95% of them are probably not. (More on this 3 paragraphs down.)
Most of the changes I want to make to my personal software environment (as a heavy Emacs user and experienced Emacs-Lisp programmer) can be made in Emacs. In other words, Emacs is a kind of non-proprietary "middleware" just as the web is a kind of middleware (which is admittedly non-proprietary in the parts most essential for a beginning programmer) and just as terminal-emulation apps plus TTYs and PTYs plus ssh plus the ncurses library and cursor-address using ANSI terminal codes is a kind of non-proprietary middleware on which a wide range of software applications (or the user interfaces of the applications) can be built. And I recommend Emacs over the "platform" consisting of terminals, TTYs, cursor-addressing and traditional Unix shells (including rc) because (very briefly) that platform has too many of it design decisions came out of an environment so constricted in computing resources as to be mostly irrelevant for today and because the common mouse idioms really did represent an advance in the state of the user-experience-design art. Hey, since I've already risked offending a large HN contingent (web programmers), why not risk offending a second large contingent (those who like apps that use a terminal for interacting with the user)!
I am aware that not all prospective programmers can stay engaged while staring at plain text all day. They would get bored. To stay engaged, they need more stimulation, e.g., colors, graphical elements, things that move around on the screen (or they need a social element, social interaction being very stimulating for humans). For them, maybe the web is the best environment in which to learn how to program (since it is difficult to learn programming while continuously staying engaged socially). I concede that I have not really studied the issue, so I am (provisionally) willing to believe the general consensus on this page -- but only when it comes to beginners who cannot stay engaged while staring at plain text all day.
Since 95% of Emacs's add-ons (including almost everything in ELPA and MELPA and much of what is distributed in the Emacs app itself) is not worth learning or embracing, perhaps I should add to my recommendation of Emacs the further recommendation that before tackling Emacs, the beginner should first explore and learn how to use OS X so as to give him o...
In my .emacs are calls to such Unix "command line" programs as Rscript, OS X's open, sudo, rm, gzip, chown, chmod, /opt/mozilla/bin/firefox, OS X's screencapture, fetchmail, OS X's system_profiler, shutdown, ping, ps and growlnotify.
A popular and very much traditional way to call such programs (even in languages like Ruby) is via a traditional Unix shell (invoked usually in languages like C, Perl and Ruby by the "system" function), but there is no need to do that. In emacs for example, one can bypass the Unix shells by writing something like (call-process "sudo" "mv" "-i" "/foo" "/bar"). call-process in turn does a fork and exec and the exec gets the command name (in this case "sudo") and the command's arguments (here, "mv" "-i" "/foo" "/bar").
Actually, "sudo" might have been a bad example because for all it know is implemented by calling out to a traditional Unix shell (though one can certainly implement it without doing so). I'm not a purist striving to eliminate every use of a traditional Unix shell on my machine -- that would be a waste of my time.
Point is, I do not write shell functions and shell scripts anymore -- I write Emacs Lisp code instead.
I used to make heavy use of traditional Unix shells and other parts of "TTY world": from 1997 to 2005 or so, my only interaction with my computer, a Linux box, was via the Linux console. For the 5 years before that my only interaction with Unix and with the internet was through an old-school actual terminal and (later) and IBM PC XT running a terminal-emulation app and almost no other apps. But I've discovered, slowly over the years, that I'm happier writing Emacs Lisp even for things that are traditionally done with shell scripts and with shell functions defined in ~/.bashrc.
For many experienced Emacs users, Emacs is just another component of "TTY world". these users typically use Emacs in "text mode" or in "-nw mode" (i.e., without a windowing system) and perhaps they use shell mode, eshell mode or ANSI-Term mode, all of which pretty much require the use of a traditional Unix shell. But it's not difficult to use Emacs without making constant use of the components of TTY world.