The Incessant Language Propaganda Horse Race

| 9 Comments

Another year (another month), another set of vapid news posts that proclaim language $x or platform $y has won, whatever that means, for the latest astrological milestone.

Sure, it's fun to treat programming and technology as a horse race, where someone must win and someone must lose, but if you're in the business of solving real problems to help real people do important things (I'm in the business of just that), there comes a time at which you have to decide between inflating the stats to edge ahead in that horse race or getting things done.

(Someone more cynical than me might suggest that you consider who promotes certain technologies and the horse race mentality and what they want you to spend your money on—consulting fees, books, conferences, collaboration services they just so happen to sell, their venture capital contests—but I'm not that cynical, so forget I just typed that.)

For example, as much as you hear that HTML 5 is the future, that all applications will be mobile, running with JavaScript or some sort of compatibility shim at the worst, consider how many microprocessors shipped last year, microprocessors which get programmed with one of assembly, C, or C++. These run your car, your microwave, your phone, your electric toothbrush, your appliances, your watch, almost everything.

These billions of devices don't show up in a Google Trends search because they're ubiquitous. That is popularity, not what shows up most in Hacker News threads.

By all means talk about the wonderful things you're building to solve real problems for paying customers. (I hear there's an office full of people in Taiwan whose lives I make a little bit easier several times a week. Sometimes it's Perl. Sometimes it's a little bit of JavaScript, yes. Sometimes it's SQL. Sometimes it's a tiny shell script. Today I almost even wrote some C.)

Yet don't confuse the incessant sound and fury of the horse race and the propaganda it represents with actually doing things.

(Alternate title: While you were writing your own web server at the bare metal layer with Node.js, I saved one of my clients a million dollars.)

9 Comments

Although often very interesting, I always have to remind myself that Hackernews has it's own reality distortion field. Anti-FUD articles like this help a lot.

> writing your own web server at the bare metal layer with Node.js

> bare metal

> Node.js

huh?

A while back someone on Hacker News claimed to enjoy using Node.js because it felt like programming to the metal. I suppose the implication must be that HTTP is NAND gates or something.

Actually, companies like Joyent are finding ways to run things like the JVM and V8 as close to the metel as possible w/o an OS like Linux. With Joyent being a huge promoter of node, I suppose the author is making a tongue-in-cheek reference to that.

I think you're just trying to sell your books, everyone knows Perl's design principles are outdated and it's inferior to Python and Ruby which are excellently designed languages, the latter of which is a real successor to Perl (combined with the principles of Smalltalk). You're either attempting act like a salesman, or just in denial that your favourite language is on its way out.

Sorry, that's the truth, and there are times when you must accept that your favourite language is poorer than current solutions and that it has had its day.

I particularly like Python's "Functional programming is hard, let's go indenting!" philosophy, both Ruby and Python's "Variable declaration? We don't have types! It's fun to guess what scope means!" approaches, Ruby's "A coherent system for module loading? Why would you want that?", Python's "An object system is just a dictionary with some metadata, but when Perl does it it's baaaaad!", and Ruby's "If you can get it past the parser, it's allllll good" API design ethos.

Also have you seen CPAN and its ecosystem, especially CPAN Testers? (At least Ruby has something approaching specification tests now.)

Speaking of vapid posts: http://www.oreillynet.com/onlamp/blog/2006/12/dear_python_3000_bdfl.html

Python 3 was around a year later than projected. Can we expect to see Perl 6 before the end of the next Mayan cycle?

I certainly don't expect a usable implementation of Perl 6 in the foreseeable future.

Perl is certainly perfectly usable, much more so than a heck of a lot of other things.

I don't see any pressing need to move to python/ruby/jnode/whatever.

For me, it's still either perl, or a "real" compiled language like C/C++...

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

sponsored by the How to Make a Smoothie guide

Categories

Pages

About this Entry

This page contains a single entry by chromatic published on January 9, 2013 9:00 AM.

The Implementation of Perl 5 versus Perl 6 was the previous entry in this blog.

How Forking Perl 5 Could Work is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


Powered by the Perl programming language

what is programming?