Retiring Python as a Teaching Language

You could also not use Perl 6 for that.

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.

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

Warning: this is a very opinionated comment.

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 or her a fighting change at learning how to tell which 5% of Emacs is worth learning and worth adopting. (I consider most popular apps on OS X to be well-enough designed to be worth learning, and my hope in making this recommendation would be that those examples of good-enough design will rub off on the beginner to the extent that he or she would be semi-competent in deciding what parts of Emacs to learn. Textmate in particular has a very well-designed user interface, but Textmate is just text editor for coders, not a flexible middleware like Emacs is, so stay with Textmate only long enough to get an idea of what good user-interface design is.) Certainly, I believe that most beginners should stick to graphical Emacs so that the common mouse idioms (moving the insertion point, selecting by dragging) are available, leaving Emacs running in a terminal to experienced employed programmers who need to ssh in to servers a lot. Also, stick to dired mode as opposed to other ways of navigating and making changes to the file-name space, and avoid org mode, shell mode, eshell mode and especially term mode: org mode makes you learn too many new commands and keyboard shortcuts, and shell mode, eshell mode and especially term mode are too rooted in the very old "ANSI terminal, cursor addressing and Unix command line" way of doing things, which IMHO is overrated on HN unless the goal is to become a professional sysadmin or maybe devops person. And all 4 of those packages / libraries, org mode in particular, do not allow the user to use the mouse enough IMHO.

A more important reason I haven't learned how to write web apps is because the web is our civilization's most important medium for reading, publishing writings and browsing (in the old sense of "browsing" as in browsing through a section of a book store) through collections of textual documents, and IMHO the more people writing web apps, the less suited the web becomes for this essential civilizational function -- because as a general principle, when a software ecology such as the web is adapted for a purpose A then it naturally tends to become less useful and less good for purpose B. In other words, a complex software system serving 2 masters serves those masters less well than a system serving only one master.

Again, I realize that not everybody finds reading static textual documents on the web stimulating enough to keep at for large blocks of time. however, for those of us that do, and who are using the web for a serious purpose (e.g., learning, teaching, inventing, creating new scientific information) the web of 1998 (when the web was already pretty good for reading, publishing and the old pre-electronic sense of "browsing", but had not been significantly adapted or specialized for writing web apps) was generally superior to the web of today. And I believe that the people for whom the web of 1998 was generally superior to web of today deserve some consideration, and I choose to show them some consideration by refraining personally from learning how to create web apps.

I am receptive to follow-up questions via email, especially from beginning programmers.

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!

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.