Why Do Programming Languages Succeed Or Fail?

magicmat writes "UC Berkeley EECS graduate researchers Leo Meyerovich and Ari Rabkin have compiled an interesting data set on the sociological aspects of programming language usage and adoption. 'Socio-PLT' is the result: compiling survey results from Berkeley's recent 'software engineering' massive online open course, SourceForge, and two years of The Hammer Principle online surveys, they have discovered some interesting phenomenon about what we, as programmers think about our languages, and why we use them. You can head over and explore the data yourself using cool interactive visualizations, and even fill out a survey yourself to have your say."

Comments

Because programmers use them or they don't

[rfioren]

Because programmers use them or they don't.

Re:Because programmers use them or they don't

[slim]

Because programmers use them or they don't.

Brilliant insight there, leading 4 people to moderate you "insightful"... You could have saved those researchers a whole lot of work.

Ever heard of "five whys"?

1. Why is a programming language successful? - Because programmers use it, or don't.
2. Why do programmers use it? - Because it does what they want.
3. What do programmers want from a language? - .....

Less than 3 why's in, we've already reached a question that you can't glibly answer. Or if you can, go ahead and release your perfect language.

Re:Because programmers use them or they don't

[19thNervousBreakdown]

Oh man.

I came in here to post that we can expect to see programming explosively progress relative to previous craft professions, because unlike other professions that disdain introspection, our field practically requires it, and teaches very early and very harshly that absolute intellectual honesty is the only way to move forward.

And then ... this. +5, Insightful. A post that is the equivalent of the middle-management meme that made the rounds a few years ago, "It is what it is." Absolutely meaningless, utterly unhelpful, not only devoid of thought but actively blocking it, a trite tautology is apparently the pinnacle of what the Slashdot community (which, according to a recent poll, is something like 40% developers) has to offer.

Well, at least it won't be too hard to leave you guys in the dust.

Re:Because programmers use them or they don't

[dkleinsc]

That last one isn't that hard to explain though, because it usually comes down to a few factors:
A. Easy to learn.
B. Easy to write highly functional code.
C. Easy to understand what someone else has written.
D. Easy to integrate with components written in other languages (via libraries, compatibility layers, etc)

Getting all of those right is more art than science.

Re:Because programmers use them or they don't

[TheLink]

Yeah, I had to debug and fix some stuff too. If the module is not too crap, fixing it is usually still faster than writing it from scratch in Lisp. Add in the OK modules that perl has and lisp doesn't and it still could be faster.

Even so many of the modules are written by programmers who are better than I am. That's how I improve the code quality of my program - most of the code is written by better programmers :).

Lisp does have Cliki: http://www.cliki.net/index
But compare the documentation of the average module.

Re:Because programmers use them or they don't

[ducomputergeek]

Just started a new project which required an API to essentially pass information from a database and CSV files to an HTML client in JSON. Broke out the basic script I wrote in Perl circa 2002 to do just that. Since 2002 I've made two major changes to the script: added JSON support (originally it returned XML because back then it was all about XML) and replaced some rather nasty els if statements with switch statements when that became standard in Perl 5.10. The sub routines vary from project to project (i.e the queries), but the other life saver has been CPAN. Every time I've ever needed to interface with some new service, there seems to be a Perl Module for that...Facebook, twitter, whatever...there always seems to be "a perl module for that".

I'm the senior programmer on the project with a couple younger kids with CS degrees about a year out of college. They were trying to push to use nodejs for the back end and I said no, we were going to use Perl for the web services/api/cgi-script/server-side-process-term-of-the-year. I got some disgusted looks for using "old and broken" instead of "new hotness". Then I chuckled that I had heard it all before. The world was going to be Java, which is true in the Enterprise world, then it was all about PHP, then Python, then C#, then Ruby on Rails and yet this very simple framework I wrote a decade ago in perl still works just as it did back then. As I told them was I don't feel like having to rewrite the damn thing because no one is going to deprecate a function like split() in favor of calling it explode() or suddenly you find out that the flavor of the year suddenly can't scale as advertised.

A major selling point was DBD::CSV, a perl module that allowed CSV to be queried with SQL statements. Yes, it doesn't support all the features, but does support the basics like "SELECT this.column FROM file.name Where some.column = some.value". Which means when all the CSV eventually do get imported into the database (that will be a few months as there is something like 500k csv files on the server) it won't take much to switch out to use the database.

What they fail to understand is that what the client cares about is out the "app" looks on the HTML side. How it the data gets from the database/file servers to the client they don't care and frankly not what they are paying us for. What will make them happy is how it looks. So long as the backend is "fast enough" to deliver data over a cell network they don't care. We aren't having to execute financial transactions where milliseconds matter.

Girl Analogy

[A10Mechanic]

Programming languages must have a certain elegance, a flow or symmetry that entices the mind. Pascal/Delhpi have always done that for me. She's not the hottest girl at the dance, a little older and not dressed to the 9's, but she's the one I'm taking home that night. It's entirely personal, and I could'nt care less what others use.

Certianly has nothing to do with language quality

[Anonymous Coward]

Since PHP and Javascript stubbornly remain popular.

If you can get useful results quickly, it succeeds

[gestalt_n_pepper]

Otherwise it fails. Two of the most popular languages in existence are Visual Basic and PHP. Math folks and programmers tormented by the hobgoblin of consistency hate both languages. Guess what? It doesn't matter.

Sure, they're inconsistent, oddly constructed and don't support polymorphism (which describes many programmers too, for that matter). Nevertheless, you can get something *done* in jig time and move on with your life. They are languages that are not about the language but the task. In that sense, they perfectly suit the human mind and so they get used again and again.

The big fail of programming languages generally is that nobody thought to combine ease of use with scalability. A programming language should make the most frequently done things trivially easy (e.g. file i/o) and less frequently done things (e.g. serializing and deserializing) possible.

My favorite example of a programming language fail is Powershell. The language is very consistent. It's a consistent pain in the ass. It's picky, prissy and everything has to be done "just so." I use it every day, and I'd like to condemn the developers to a hell where they had to do real system administration with it for eternity.

Same way as real languages

[Kjella]

English isn't the world's most spoken language (when you include secondary speakers) for its elegance, consistency or expressiveness. It's a combination of history and politics and power and isolation and culture and grabbing concepts and words and pronunciation from other languages. Languages are the same, some exist practically by being first. Some exist only because they've had large companies like Sun or Java backing them. Others survive because they've been isolated cornering a specific need in finance or science or academia. I remember Java 1.0 and very early Javascript, that the world is now full of Android and AJAX apps is nothing short of a freak of history. Trying to analyze it from the language's qualities alone is never going to give meaningful results.

Wish I had mod points

[Viol8]

You got it spot on. One thing you didn't mention was critical mass - once enough people are using a language others will come along and try it (or be forced to use it at work) no matter how good or bad it is and once they're comfortable with it they'll probably carry on using even if there are better alternatives because a learning curve is always more hassle than staying with what you know.

A language can be the price of entry

[alispguru]

A language/methodology can catch on fast if it is the price of entry to a hot field. Broad, long-term popularity requires finding applications outside the original field.

Objective C is the current price of entry for iOS development. It will stay around as long as Apple allows no alternatives, but is unlikely to grow outside that niche.

OOP was the price of entry for GUI toolkits. It has since proved its worth as a general structure and analysis method.

Java started out as the price of entry for applets. It eventually settled in as a portable platform for enterprisey stuff.

Lisp was the price of entry for AI. It died back when strong AI faltered.

Functional programming may yet become the price of entry for reliable concurrent programming.

Re:sometimes backwater is good

[Mike Buddha]

Objective-C is horrible. I wouldn't wish it on my worst enemies. It hasn't gone off the rails? It's never been on the rails to go off of to begin with! It's a series of kludges tacked on to a terrible core.

For instance: memory management. End of argument.

Re:sometimes backwater is good

[vux984]

I was one of those imbeciles that ridiculed the whites space

I still ridicule the white space.

White space is brilliant!

Formatted code is brilliant. Code that can't be copy and pasted reliably is still something only an imbecile could like.

if something:
        do something
        a bunch of stuff goes here
        blah blah blah
and this is after the if clause... for now

is not easier to read than

if (something)
{
        do something
        a bunch of stuff goes here
        blah blah blah
}
and this is after the if clause... and will reliably stay that way

And if the code with {} gets mangled by some editing, you just highlight it and reformat, and its back as it should be. Mangle the indenting/formatting in python, and you have to re-validate the semantics of the code.

A few {} do not make it harder to read, the code is trivially easily to prettify with automatic formatting (nobody has to look at unindented or all-on-one-line code in a {} language even if it was originally written that way), and I have found the structure is much more resilient to editing. If I'm editing away in something like notepad and delete the "blah blah blah" line in python there are good odds the "and this is after the if clause" will end up appended to the "a bunch of stuff goes here line" and then I'll hit return and have to think about whether its part of the if clause or not.

In C worst case, the } gets appended to that line and I press return to pop it down again, knowing that its closing the block.