JavaScript, PHP Top Most Popular Languages, With Apple's Swift Rising Fast

Nerval's Lobster writes Developers assume that Swift, Apple's newish programming language for iOS and Mac OS X apps, will become extremely popular over the next few years. According to new data from RedMonk, a tech-industry analyst firm, Swift could reach that apex of popularity sooner rather than later. While the usual stalwarts—including JavaScript, Java, PHP, Python, C#, C++, and Ruby—top RedMonk's list of the most-used languages, Swift has, well, swiftly ascended 46 spots in the six months since the firm's last update, from 68th to 22nd. RedMonk pulls data from GitHub and Stack Overflow to create its rankings, due to those sites' respective sizes and the public nature of their data. While its top-ranked languages don't trade positions much between reports, there's a fair amount of churn at the lower end of the rankings. Among those "smaller" languages, R has enjoyed stable popularity over the past six months, Rust and Julia continue to climb, and Go has exploded upwards—although CoffeeScript, often cited as a language to watch, has seen its support crumble a bit.

Comments

Re:bleh

[Anonymous Coward]

At one point VB6 was probably one of the most used....

Who's surprised by this?

[Anonymous Coward]

Javascript is the barest-metal web language we have, so of course it's popular, especially as ES6 threatens to improve the language. And Swift and Go are heavily endorsed by two of the biggest companies on earth, with Swift being one of only two blessed options available in its ecosystem, just like JS. So anyone surprised by their huge climbs must have more trouble seeing the screen in front of their faces than anything else. It's only surprising when you see something like Rust or Julia climb, as they have to actually struggle to gain adoption, not being the only options in their niches or endorsed by the world's biggest companies.

Re:Who's surprised by this?

[omfgnosis]

Since JavaScript is increasingly also a compilation target, the fact that it continues to dominate is a good indicator that the competition among compile-to-JS languages is strong.

One of those biggest companies on earth promotes both Go and Java as compile-to-JS languages with less success than I would expect.

Granted I'd prefer to see ClojureScript grow, but I am not placing any bets there.

Re:Who's surprised by this?

[omfgnosis]

Frankly, the only thing that's going to upend the JS dominance of client-side web programming is a functional language. There isn't a compelling reason to trade OOP horses on the web. There's a good reason to choose a better paradigm for the problem. A functional paradigm with a good immutability story is going to have a much better time convincing people to rethink how they program web apps with a focus on user interaction over time.

There isn't much point in vying for who can do the best at mixing data and behavior. Separating those will be a good way to compel people to consider alternatives.

Re:Who's surprised by this?

[Anonymous Coward]

Nonsense. I like functional programming more than most of the people I know, but JS itself is becoming a pretty decent functional language. It's not as "pure" or academically-sanctioned as some of us might want, but it's hardly as bad as a lot of other popular languages. It fact it's already half-decent, and ES6 will even have proper tail recursion. Other popular languages struggle mightily with that concept, while JS is trying to actually make it standard. JS is basically just C++-like in that it has a lot of baggage, and the VMs are still only just starting to achieve a level of maturity where we can truly code efficiently in functional ways. The more people pretend that it's all dire and shitty, the more obvious it becomes that they've never really tried to use JS as a proper language, and are just trying to use it badly. Or that they just want to pretend that it's still 1999, and JS hasn't budged an inch, and isn't moving at all, while Firefox and even IE11 are rapidly implementing ES6 (and Google won't be far behind, if they're thusly put to shame).

Re:Who's surprised by this?

[omfgnosis]

Nothing you said makes my point nonsense. The only thing that is going to go head-to-head with JS is a properly functional language. The fact that JS adopts more functional concepts and encourages more functional approaches only underscores that.

Re:Who's surprised by this?

[Half-pint HAL]

Tail vs head recursion is a result of the imperative programming paradigm. FP is supposed to be an analogue of mathematics, which logically implies that it should be declarative. FP has been hamstrung by people fixating on ML, Lisp etc, and forgetting that much of how they do things is determined by the memory and processor constraints of machines 40 or 50 years ago. Yes, on one level it's good that programming language codebases are kept more stable and predictable than other code (given how much other software relies on the compiler or interpreter), but we have a hell of a lot more resources to play with, so we can do things a bit more clever, surely?

Maybe I just did too much maths in my early years at university, but I always felt ".... where x=whatever(y)" was far easier to read than interrupting code with "let x=whatever(y) in ... end". The linearity of code and the [two|three|whatever] pass compiler system was designed not for the programmer, but for the machine. We have enough memory to do away with that now and make readability a true priority.

We're kidding ourselves on if we tell ourselves that linearity is best, because we always find situations where we break it -- for example Python's list and generator comprehensions. Let's look at the order of evaluation of this example:
my_list = [ x*x for x in input_list if x > 0 ]
The first thing we do is retrieve input_list, then we iterate elements x, then we test the condition, then multiply for our final answer, then we assign the full thing to my_list. We can notate the order of evaluation thus: 5 = [ 4 for 2 in 1 if 3 ]

List comprehensions are great. It doesn't take long to get used to them, and I find the above more readable than the (reverse) linearly evaluated
my_list=map(lambda x: x*x,filter(lambda x:x>0,input_list)
The comprehension doesn't just save a dozen characters, it's much, much quicker to mentally process. And of course it saves you iterating twice across large lists.

Re:Who's surprised by this?

[Foofoobar]

The barest metal web language? seriously? maybe we have a different definition of 'metal'. If you are talking scripting languages, Groovy is going to kill everything because it's based on the JVM, can build Android apps, is used for Gradle builds, Spock and even Grails as well as shell scripting. The only thing it can't do is client side. And if you statically code it, it can even be FASTER than Java at times (believe it or not).

Re:Who's surprised by this?

[narcc]

I find the above more readable than

Sure, I can see that. But both are infinitely less readable than a for loop.

Re:Who's surprised by this?

[Wootery]

FP has been hamstrung by people fixating on ML, Lisp etc, and forgetting that much of how they do things is determined by the memory and processor constraints of machines 40 or 50 years ago.

we have a hell of a lot more resources to play with, so we can do things a bit more clever, surely?

So you're really just saying performance be damned, functional programming is great, right?

I'm not opposed to FP, but I disagree that performance doesn't matter. High-performance is a great thing for in-browser scripting. It's an enabler. It means neat things like WebGL (against which there are many valid complaints, but I'll ignore those for now) might actually be useful, and not just an interesting gimmick. Asm.js is exciting precisely because it enables really fast code to run in the browser, within the usual execution model.

A slight aside: bloated, pointless use of JavaScript is already a plague on browser-compatibility, mobile-device power-consumption, security (because it discourages use of things like NoScript, which really do improve security) and sometimes even causes overheating. If JavaScript were less efficient, such idiotic abuses of it would be that bit worse.

Re:Who's surprised by this?

[narcc]

Groovy? I know it looked hot back in 2013, but that was the result of some foul-play. It has since dropped off the radar.

I honestly didn't know that anyone still cared about it.

Re:Who's surprised by this?

[omfgnosis]

JS is not a functional programming language. It has a lot of functional attributes, but it is very heavily skewed toward imperative approaches to problems, and it's a stateful mess.

The syntax is far from JS's only problem.

Re:Who's surprised by this?

[Half-pint HAL]

I find the above more readable than

Sure, I can see that. But both are infinitely less readable than a for loop.

I disagree with that, except in the trivial sense that you need to know what a list comprehension is before you can recognise one, and that Python FOR loops are reasonably similar across different languages.

my_list = [] for x in list : if x>0 : my_list.append(x*x)

The problem with most imperative programming is that the meaning of the program is broken up between multiple statements. The semantics of an individual statement are purely technical, and carry little meaning in terms of the overall functioning of the program. A list comprehension is a single statement that describes neatly and explicitly the

Re:Who's surprised by this?

[Half-pint HAL]

Oops... wrong button. I was trying to sort the formatting on the code.

Anyway -- as I was saying... With a for loop, you have to understand each step individually then construct the relationship between lines. The more experience you have, the easier this becomes, but it is still a more difficult cognitive task than reading a single statement. The list comprehension syntax isn't perfect, and you still need to break it down, but once you know about list comprehensions, it's impossible not to recognise what you're looking at, and you know the state of the execution environment afterwords. It eliminates inadvertent overwriting of variables with the same name as your intermediate values. And it's not like hand-crafting a near-identical FOR loop every single time you're faced with the task makes the resulting code any more efficient....

Re:Who's surprised by this?

[Half-pint HAL]

So you're really just saying performance be damned, functional programming is great, right?

Did I say we should all be using FP? No. I said that FP doesn't work right in an imperative paradigm. Now a declarative language would need to be compiled, because yes, an interpreted declarative language isn't going to be able to optimise itself on the fly. But a compiler should be able to handle performance for us. One of the reasons compiler optimisations are so difficult is down to the multitude of ways imperative programming can be hacked about, so there is very little that is predictable in its behaviour, but even then, any decent compiler will spot redundancies in simple expressions and optimise them out, eg 3*((3*x)+2) optimised to (9*x)+6. In pure FP with immutable values, everything's an expression that can be reordered in that way. At that point, you are essentially programming declaratively anyway.

That was my point. FP isn't really FP if you try to do it as an imperative paradigm.

Re:Who's surprised by this?

[narcc]

The more experience you have, the easier this becomes, but it is still a more difficult cognitive task than reading a single statement.
my_list = [ x*x for x in input_list if x > 0 ]
my_list = [] for x in list : if x>0 : my_list.append(x*x)

I strongly disagree. As you said: "you still need to break it down" which, adds to the cognitive load. The for loop is not only neatly broken down for you, but includes additional information to help you understand each part and the relationships between each part.

Further, the components themselves are also "in order" making it read more "naturally". The order in the list comprehension example might as well be completely random. Consider the same example using list comprehensions in C#:
my_list = from x in list where x > 0 select x*x;

This is dramatically more readable than the Python example simply because those imperatives of imperative programming (direct sequencing, conditional branching, bounded iteration, and conditional iteration) are still applicable. It's almost as readable as a for loop, though it still requires special/uncommon knowledge; just far less than in the Python example.

I suppose it doesn't really matter how much better or worse than other languages handle them. In every case that I'm familiar, they add complexity (without also adding value, an unforgivable sin). Complexity, naturally, harms readability.

Re:Who's surprised by this?

[Wootery]

a compiler should be able to handle performance for us. One of the reasons compiler optimisations are so difficult is down to the multitude of ways imperative programming can be hacked about

But this simply isn't true. Here in the real world, C, C++, and FORTRAN are incredibly fast. Faster than Haskell or OCaml.

This isn't a theoretical question. Real C code can generally be expected to outperform real Haskell code. (Yes, carefully tuned Haskell code can be fast too.)

Re:Who's surprised by this?

[Half-pint HAL]

I strongly disagree. As you said: "you still need to break it down" which, adds to the cognitive load.

You either have to break down or build up, and either is a cognitive load. What I like about the Python list comprehension is that having the statement in brackets basically screams THIS IS A LIST and it's very hard to miss the intended meaning. The C# list comprehension doesn't have any similar visual indicators, and the readability relies more on meaningful variable names

The for loop is not only neatly broken down for you, but includes additional information to help you understand each part and the relationships between each part.

No, the thing that's most sorely lacking in imperative programming is structures that explicitly encodes relationships between statements. Consequentiality from one line to the next is almost entirely buried in the (unseen) state of variables.

Further, the components themselves are also "in order" making it read more "naturally". The order in the list comprehension example might as well be completely random. Consider the same example using list comprehensions in C#: my_list = from x in list where x > 0 select x*x;

This is dramatically more readable than the Python example simply because those imperatives of imperative programming (direct sequencing, conditional branching, bounded iteration, and conditional iteration) are still applicable.

That assumes that imperative programming is natural, which it is not. People have great problems learning to program because human thought doesn't work that way. Just think of the classic "peanut-butter and jelly" demonstration of trying to tell someone how to make a sandwich procedurally -- it's really hard, and even many programmers can't do it right first try.

It's almost as readable as a for loop, though it still requires special/uncommon knowledge; just far less than in the Python example.

I suppose it doesn't really matter how much better or worse than other languages handle them. In every case that I'm familiar, they add complexity (without also adding value, an unforgivable sin). Complexity, naturally, harms readability.

Reductio ad absurdum: Complexity harms readability. Base 10 is more complex than base 2, therefore 11001 is more readable that 25. The flaw in this logic is simple -- although base 10 is more complex, base 10 is an integral part of our daily lives. Or to put it another way, base 10 is compatible with human thinking. Humans don't think procedurally, and we don't speak in strict chronological order -- "always wash your hands after going to the toilet".

Let's bring that back to a list comprehension. For the English "give me a list of the names of all the students in the class whose grades are above 50%", the pseudo-Python list comprehension would be = [ student.name() for student in class if student.grade() > 0.5]. And yes, there are multiple ways of issuing the same command in English, and I've selected the one that matches the Python syntax most closely. That isn't important, though -- Python's syntax models a possible human syntax, therefore has high compatibility with human thought. On the other hand, I'd struggle to produce a natural-sounding English analogue to the C# syntax. All the "for... if..." stuff doesn't imply "list" -- only the "select" does, and it's an odd word in the situation.

The Python starts with our goal in brief, then gives more information, which is human nature. In fact, if you think about it, assignment statements in most programming languages do. A few languages tried doing it the other way round, as this was a purer procedural way of doing things ( eg 3*x+2 => variable ), but programmers didn't like it that way round, because the variable is the goal, and the expression is more information.

As for FOR loops being the most readable, well, let's try a FOR loop in English. "Ma

Re:Who's surprised by this?

[Half-pint HAL]

OCaml is an imperative language -- I was talking about FP as declarative. Haskell may be described as "pure" functional, but it still allows monads with side-effects, which means it still has order-of-execution issues and is therefore not declarative. So clearly I was not talking about OCaml or Haskell. This is a theoretical question, because "here in the real world", there is no declarative functional language to benchmark against.

My personal belief is that the problem with FP is the same problem as every other terse paradigm has: it can't do everything. Procedural programming is our default option, in a "a jack of all trades is a master of none" type way. Everything is clumsy, but everything can be done. The problem with multiparadigm languages is that they either make everything possible, so nothing is guaranteed (eg "Python can be used for functional programming", but it never enforces immutability) or everything descends into a morass of keywords, imperatives and classifiers. But more importantly, every language sticks to a single syntax, regardless of the paradigm, when individual paradigms really need their own syntaxes. If you can program in a statement-based style inside your functions, everything gets confused.

Re:Who's surprised by this?

[Wootery]

This is a theoretical question, because "here in the real world", there is no declarative functional language to benchmark against.

Then I really don't care. You're talking about such a narrow set of language - so narrow that you concede no such languages even exist - that it's really not worth our time to reason about them from a practical, software engineering perspective.

What 'concessions' Haskell makes are in the name of practicality, and it's still nowhere near a practical language, really, at least not judging by its uptake.

If you're seriously going to argue for adoption of ultra-pure functional programming languages, you've got your work cut out.

Re:Who's surprised by this?

[Half-pint HAL]

What I'm trying to suggest is that the whole idea of "a language" is wrong. Instead, I would like to see a multi paradigm "multi language" - ie a single type system and calling mechanism which unifies various syntaxes incorporating multiple programming paradigms. We already sort-of-kind-of do this, but our paradigms are all hidden in libraries, and we end up missing out on compile-time checks (eg cross-calling SQL from an unverified ad hoc string, rather than having properly mediated source code). But we kid ourselves on that we don't do this. We need to accept that we do and explicitly make tools that support it.

Re:Who's surprised by this?

[Half-pint HAL]

Why? Because functional programming cannot do everything. The best toolbox doesn't contain one tool that can be used to do everything, but multiple tools that can be used together. I mean, you can tap a nail with a chisel, and you can cut a plank of wood it half with a chisel, but you'd be better with a hammer and a saw. If we try to make all of our languages do everything, we end up no specialised tools. So we need to focused on integrating muktiple tools into a single toolbox.

Re:Who's surprised by this?

[narcc]

If I can cut to the core of your argument:

Humans don't think procedurally

That's ridiculous. Of course humans think procedurally. Don't know how to do something? Here's this step-by-step procedure! If you ask how to bake cookies or change your spark plugs, you'll find (and expect) that you're provided a handy list of steps.

Just think of the classic "peanut-butter and jelly" demonstration of trying to tell someone how to make a sandwich procedurally -- it's really hard, and even many programmers can't do it right first try.

I've used that and similar problems when teaching kids how to program. Not a single child has failed to get it right on the first try. Have you really seen someone fail at this? Were they conscious?

(Just thinking about it, that's often how kids explain things to you when they're proud of some accomplishment. "I did x! ... First I ... then I ... ")

So, without providing a list of steps, can you explain to me how to make a peanut-butter and jelly sandwich? Surely, there's a much more natural way to communicate that knowledge, yes?

Re:Who's surprised by this?

[Half-pint HAL]

If I can cut to the core of your argument:

Humans don't think procedurally

That's ridiculous. Of course humans think procedurally. Don't know how to do something? Here's this step-by-step procedure! If you ask how to bake cookies or change your spark plugs, you'll find (and expect) that you're provided a handy list of steps.

Humans can cope with procedural instructions, but it's not our most natural mode of thought. But even within the steps of a recipe, there are lots of jumps where descriptions change or items aren't repeated. e.g. "Sift the flour, sugar and baking powder together into a bowl. Beat an egg and milk with 1 tablespoon of milk, then add to the dry ingredients and mix thoroughly". Notice that "the flour, sugar and baking powder" becomes "the dry ingredients". The fact that the egg/milk mix is being put into the bowl is an unstated assumption in the call to add the mix to the dry ingredients. Adding to the ingredients is declarative rather than imperative. The fact that an egg must be cracked and emptied before beating is omitted, which is again declarative as it's an unstated prerequisite. You could claim that proc beat(egg) includes if intact(egg) { crack(egg) } but that's a bit of a hack. It's still an assumed prerequisite, and all we're doing is trying to hack a bit of declarativity into the imperative paradigm. We do this because humans think declaratively.

Just think of the classic "peanut-butter and jelly" demonstration of trying to tell someone how to make a sandwich procedurally -- it's really hard, and even many programmers can't do it right first try.

I've used that and similar problems when teaching kids how to program. Not a single child has failed to get it right on the first try.

Then you weren't doing it right. The whole point of the exercise is for them to get it wrong. Your job is to take the slightest ambiguity and do it wrong. You don't ask them for clarification, you don't let them shout "STOP!" when you're doing it wrong. Almost nobody every thinks about the fact that you need to line up the corners/edges -- it's so much a natural part of our understanding of "sandwich" that it never strikes us as significant. Have you really seen someone fail at this? Were they conscious?

(Just thinking about it, that's often how kids explain things to you when they're proud of some accomplishment. "I did x! ... First I ... then I ... ")

So, without providing a list of steps, can you explain to me how to make a peanut-butter and jelly sandwich? Surely, there's a much more natural way to communicate that knowledge, yes?

Re:Who's surprised by this?

[narcc]

Then you weren't doing it right. The whole point of the exercise is for them to get it wrong.

But that's not pedagogically sound. The first rule: don't set them up for failure. The point of the exercise is to show them that they already have some of the necessary skills, and to foreshadow future topics.

Your job is to take the slightest ambiguity and do it wrong.

You actually ... make the sandwich?

We do this because humans think declaratively.

That's a bit of a stretch, isn't it? You always start with 'what' before the 'how'. It's why top-down design has been such a useful and successful approach. (You even hint at that in the sandwich example with the need for further refinement.)

Ask a 4-year-old to tie their shoes (the what) and there's a good chance you'll hear them say "I don't know how". Given them a complicated toy and they'll quickly rush back to you with a "How do I make it do ..." Even very young children seek out procedures. Dare I say, it's natural...

Even in the example that started this, you still include the "how" (as you can see by comparison to the C# and loop examples) it's just not in sequence and includes less information useful to the reader. (Hence, it's less readable.)

Re:Who's surprised by this?

[Wootery]

I would like to see a multi paradigm "multi language"

But this isn't possible. The differences between languages aren't just skin-deep. For instance, Haskell's lazy-evaluation really is a world away from the sequential-execution paradigm used in imperative languages. These differences run deep enough that they use quite different compiler frameworks.

Similar fundamental incompatibilities exist for type-systems, memory-management strategies, approaches to concurrency and parallelism...

I agree that it's quite possible the web would be a better place if JavaScript used a bytecode system of some sort, but I don't think a 'grand unified framework' is practical (well, excluding a very low-level 'portable assembly' representation, which I don't think is really what you mean).

What's your opinion of Asm.js?

Re:Who's surprised by this?

[Half-pint HAL]

But this isn't possible. The differences between languages aren't just skin-deep. For instance, Haskell's lazy-evaluation really is a world away from the sequential-execution paradigm used in imperative languages. These differences run deep enough that they use quite different compiler frameworks.

Surely that's a matter for the compiler writer, and not for the person using the language? I mean, we already have the capability to cross-call from pretty much any language to any other (with varying degrees of difficulty), so we're already dealing with this to an extent. But cross-calling becomes a conscious act, and people tend to hack around with a single language rather than picking the right tool for the job.

While I'll admit I've never done any compiler work more serious that a trivial undergrad coursework task, I imagine that the constraints of pure FP would obviate a lot of the incompatibilities, as you would be able to call FP subsystem from anywhere, but the FP section would not be able to call out anything else (as that would break purity).

All you have to do is make sure a call into FP works, whether by typechecking immutability of arguments at compile time or actively "freezing" any mutable arguments at run time. (That could be a slightly altered call system from within the procedural system, but it should be essentially transparent to the coder.) Once you're in the FP system, the differences are perfectly OK as they don't make a bit of difference to the result you'll get when flow control returns to the procedural subsystem.

The point would be to encourage cross-calling wherever appropriate. I accept that this would open up the potential for programmers to overuse cross-calling, and that that could potentially introduce new inefficiencies, but I believe that would be a fair trade-off against the inefficiencies that would be eliminated by having enforced mutability and mathematical provability for various subsystems.

Similar fundamental incompatibilities exist for type-systems, memory-management strategies, approaches to concurrency and parallelism...

I may be missing something, but concurrency and parallelism seem trivial for immutable items, which means the functional subsystem would not need to interfere with the main system in that sense. Memory management is clearly a bigger issue.

I personally believe, and admit I may be wrong, that most of the difficulty in reconciling multiple languages is that they all attempt to do too much. If you strip away all of the hacks that allow you to do things that are not appropriate to the paradigm, integration would be simplified -- still not a trivially easy task, certainly, but maybe worth doing anyway.

Re:Who's surprised by this?

[Half-pint HAL]

Then you weren't doing it right. The whole point of the exercise is for them to get it wrong.

But that's not pedagogically sound. The first rule: don't set them up for failure. The point of the exercise is to show them that they already have some of the necessary skills, and to foreshadow future topics.

I have two (very different) responses to that:

1: If an accurate simulation of the process of compiled imperative code is pedagogically unsound, then surely that means that compiled imperative code is pedagogically unsound?

2: The beauty of the peanut-butter-jelly-sandwich task is failure is fun. Failure is intriguing and interesting. Or at least hopefully, because once you start coding, you're entering a whole world of debugging.

We do this because humans think declaratively.

That's a bit of a stretch, isn't it? You always start with 'what' before the 'how'. It's why top-down design has been such a useful and successful approach. (You even hint at that in the sandwich example with the need for further refinement.)

Surely then the pedagogically sound way to learn about coding is top-down -- starting with declarative languages, then working our way closer to the metal, naturally bringing in procedural languages.

In fact, many of the attempts to make kid-friendly programming environments are just collections of library functions that the kids can string together. But all that string is procedural-imperative, when black-box library functions are semantically declarative.

Ask a 4-year-old to tie their shoes (the what) and there's a good chance you'll hear them say "I don't know how". Given them a complicated toy and they'll quickly rush back to you with a "How do I make it do ..." Even very young children seek out procedures. Dare I say, it's natural...

Even in the example that started this, you still include the "how" (as you can see by comparison to the C# and loop examples) it's just not in sequence and includes less information useful to the reader. (Hence, it's less readable.)

Re:Who's surprised by this?

[narcc]

1: If an accurate simulation of the process of compiled imperative code is pedagogically unsound

No. Setting students up for failure is pedagogically unsound. Don't twist things; that's not productive.

Surely then the pedagogically sound way to learn about coding is top-down -- starting with declarative languages, then working our way closer to the metal, naturally bringing in procedural languages.

What did I say about twisting things? Pedagogy is about process, not content. (Otherwise, some subjects would be unteachable!) Further, I don't think you understand top-down design, or you're being purposefully obtuse.

Moving on: There's a reason that imperative languages dominate the landscape -- other paradigms are just more difficult (for beginners and professionals alike). You could start kids off with a functional language, concatenation language, or a declarative language, though you'd be doing them a disservice. Kids already know how to give instructions, which is what imperative programming is all about! It's incredibly simple, and very easy to understand.

We develop and use programming languages for a single reason: to make programming easier. Have you ever tried to do anything non-trivial in a declarative language? It's a nightmare. Worse, the resulting code looks suspiciously imperative! (First, get the computer to give you x and y from z. From z you can then get it to give you a and b. From a and b, you can get the computer to give you c, the thing want you wanted in the first place.) This could be a weakness of declarative programming, or just a sign that imperative programming is more natural. Either way, it's pretty obvious that declarative programming, outside a few narrow domains, does not succeed in that singular goal of making programming simpler.

As you're probably painfully aware, declarative programming has been an absolute failure for general purpose computing. If it were truly more natural, as you say, shouldn't declarative languages be dominant?

Re:Who's surprised by this?

[Wootery]

we already have the capability to cross-call from pretty much any language to any other (with varying degrees of difficulty)

It's that 'difficulty' which I'm referring to. Mapping C++ constructs onto Haskell (or vice versa) isn't trivial.

I imagine that the constraints of pure FP would obviate a lot of the incompatibilities, as you would be able to call FP subsystem from anywhere

What about lazy-evaluation vs eager? What about static vs dynamic type systems? It isn't the case that all functions are created equal.

I may be missing something, but concurrency and parallelism seem trivial for immutable items

But real-life C++ code doesn't tend to make extensive use of immutable objects, and for good reasons.

If you strip away all of the hacks that allow you to do things that are not appropriate to the paradigm, integration would be simplified

No. This isn't like Lego. The differences between the languages are considerable. If you want Java or C# to play nice with C++ objects, managed by C++ smart-pointers for reference counting, you have no choice but to reinvent C++ inside Java. (As I understand it this is kinda what 'Managed C++' does.) Likewise if you want Java objects to be accessible from C++, you either have to start pinning objects to block the Java garbage-collector from moving the object, or integrate C++ into the JVM's world.

There's a reason that nice bindings take some effort.

Re:Who's surprised by this?

[Wootery]

Additionally, binding-generators like SWIG already do a very good job of removing unnecessary complexity from the task of getting different languages to communicate.

How about a salary comparison?

[Anonymous Coward]

Forget percentage of use, how do they pay compared with each other?

Re:How about a salary comparison?

[unrtst]

Forget percentage of use, how do they pay compared with each other?

These: http://developers.slashdot.org...

Interesting pattern

[Salamander]

Below the line are languages that are more popular on GitHub. Above the line are languages that are more popular on Sewer Overflow. There's a distinct difference. The "GH" languages tend to be systems languages (Go/Rust/D) and CS favorites (Haskell/OCaml/Erlang). The "SO" languages tend to be more lightweight and application-specific - Visual Basic, Matlab, ColdFusion. "Assembly" seems to be an outlier, but other than that the pattern seems pretty consistent. Conclusions about the audiences for the two sites are best left as an exercise for the reader.

Re:Interesting pattern

[david_thornley]

The Github languages are those that people who use Github generally like to use. The Stack Overflow languages are those that people who frequent Stack Overflow generally ask questions about. Those are not the same things.

not really the whole story

[Lawrence_Bird]

Sure, lots of interest in javascript, php. What is the longevity of that code (beyond libraries)? Weeks? Months? And not sure public github or stack overflow are really as representative as they want to believe

Re:not really the whole story

[Dutch Gun]

More critically, the question I always ask about this is: "Used for what?"

Without that context, why does popularity even matter? For example, I'm a game developer, so my programming life revolves around C++, at least for game-side or engine-level code - period. Nothing else is even on the radar when you're talking about highly-optimized, AAA games. For scripting, Lua is a popular contender. For internal tools, C# seems to be quite popular. I've also seen Python used for tool extensions, or for smaller tools in their own right. Javascript is generally only used for web-based games, or by the web development teams for peripheral stuff.

I'll bet everyone in their own particular industry has their own languages which are dominant. For instance, if you're working on the Linux kernel, you're obviously working in C. It doesn't matter what the hell everyone else does. If you're working in scientific computing, are you really looking seriously at Swift? Of course not. Fortran, F#, or C++ are probably more appropriate, or perhaps others I'm not aware of. A new lightweight iOS app? Swift it is!

Languages are not all equal. The popularity of Javascript is not the measure of merit of that particular language. It's a measure of how popular web-based development is (mostly). C/C++ is largely a measure of how many native, high-performance-required applications there are (games, OS development, large native applications). Etc, etc.

Raw popularity numbers probably only have one practical use, and that's finding a programming job without concern for the particular industry. Or I suppose if you're so emotionally invested in a particular language, it's nice to know where it stands among them all.

Re:not really the whole story

[unrtst]

... And not sure public github or stack overflow are really as representative as they want to believe

Yeah.. why is this any better than:
TIOBE index: http://www.tiobe.com/index.php...
This story about python surpassing java as top learning language: http://developers.slashdot.org...
Or this about 5 languages you'll need to learn for the next year and on: http://news.dice.com/2014/07/2... ... those are all from the past year on slashdot, and there's loads more.

Next "top languages" post I see, I hope it just combines all the other existing stats to provide a weightable index (allow you to tweak what's most important). Maybe BH can address that :-)

Re:not really the whole story

[hcs_$reboot]

What is the longevity of that code (beyond libraries)? Weeks? Months?

Simple. Just peek one of the available functions/vars
$longevity = PhpGetLongevity_days();
$longevity = php_get_long_evity( IN_DAYS );
$longevity = $_SERVER['longevity_days_from_server_variable'];
$longevity = $OBJ.__what_isMyLongevity();

Re:not really the whole story

[serviscope_minor]

C/C++ is largely a measure of how many native, high-performance-required applications there are (games, OS development, large native applications)

And embedded things. it remains perenially popular there since the firmware tends to be native and of course high performance within the tiny constraints of something like an 8051.

Re:not really the whole story

[Anonymous Coward]

No, the first has been deprecated, its:

$longevity = RealPHPGetLongevity(LONGEVITY_DAYS);

Re:not really the whole story

[hcs_$reboot]

The problem is sometimes you don't even know the beginning of the function, eg is it number_format() or format_number() (or formatnumber etc...). Where can you find a hint when the whole language is inconsistent. it's impossible to follow a logic, a trend, PHP has so many inconsistencies nothing intuitive can be deduced from the existing funcs/structure... enjoy...

Re:not really the whole story

[hcs_$reboot]

That makes : one.

Re:not really the whole story

[hcs_$reboot]

Arrr I gave myself away - not a PHP pro ... Well....

68th to 22nd and there are many to go

[gavron]

All new languages start out at the bottom, as Swift did.
In time, the ones that don't get used fall down.

Swift has gotten up to 22nd, but the rest of the climb past the stragglers won't ever happen.

However, to be "the most popular language" is clearly no contest worth winning.
Paris Hilton and Kim Kardashian are most popular compared to Steven Hawking and Isaac Asimov.
Being popular doesn't mean better, useful, or even of any value whatsoever. It just means
someone has a better marketing-of-crap department.

There's a time to have popularity contests. It's called high school.

E

Re:68th to 22nd and there are many to go

[Anonymous Coward]

*cough* windows

Re:68th to 22nd and there are many to go

[coop247]

Being popular doesn't mean better, useful, or even of any value whatsoever

PHP runs facebook, yahoo, wordpress, and wikipedia. Javascript runs everything on the internet. Yup, no value there.

Re:68th to 22nd and there are many to go

[93 Escort Wagon]

Swift has gotten up to 22nd, but the rest of the climb past the stragglers won't ever happen.

Well, since Objective C is currently at #10, it seems apparent Swift is still nowhere near its potential ceiling.

Re:68th to 22nd and there are many to go

[phantomfive]

Swift has gotten up to 22nd, but the rest of the climb past the stragglers won't ever happen.

I'm really interested in why you think Swift will not make it much higher. I have my own opinions but I'm interested in hearing yours.

There's a time to have popularity contests. It's called high school.

The point of popularity contests in programming languages makes the difference between having to write all the libraries yourself, or being able to use work others have done. Also it's interesting to see what other people think is good.

Re:68th to 22nd and there are many to go

[MillionthMonkey]

Paris Hilton and Kim Kardashian are most popular compared to Steven Hawking and Isaac Asimov. Being popular doesn't mean better, useful, or even of any value whatsoever. It just means someone has a better marketing-of-crap department.

Thanks, now I'm imagining Stephen Hawking yelling at his marketing team from that wheelchair. "Why is Kim Kardashian more popular than me? You think her space-time is more curvy than mine?"

Re:68th to 22nd and there are many to go

[Mike Buddha]

I don't think it'll really catch on until you have access the entire iOS API.

Re:68th to 22nd and there are many to go

[omfgnosis]

Genuine question: don't you?

Re:68th to 22nd and there are many to go

[iluvcapra]

You can get at pretty much the whole thing now. The only thing you can't do in Swift is create a C function pointer to a Swift code block, so some of the callback-based tasks in CoreAudio and CoreMIDI can't be used. But apart from that calling into C and using C data structures pretty much just works.

The existing APIs aren't very idiomatic to Swift, you gotta do more casts than you probably should have to and there are some really common patterns in Cocoa that are a pain.

Re:68th to 22nd and there are many to go

[iluvcapra]

Well, maybe not yelling, anyway...

Re:68th to 22nd and there are many to go

[Anonymous Coward]

Pff. Swift never started "at the bottom". It's the only real choice you have on iOS: the aging, crufty objective C, or a more modern language. So even if it started at the bottom between those two choices, it's nowhere near the bottom compared to other languages, given iOS's popularity. Pretending otherwise is like pretending that C# and .NET were once "at the bottom", when in reality they were equally predestined to draw a huge crowd, because they were filling a very obvious and direly-needed niche, just like Swift.

You want an actually-impressive feat? Try watching Rust or Julia claw their way up, actually having to compete with well-established languages that are backed by big companies. Swift isn't even all that performant yet, but it's still rising fast. That shows you just how desperately people needed something better than Obj-C on such a constrained platform, not any merit of the language itself compared to other ones on other platforms. Hell, if XCode worked with other modern languages, and Apple accepted them as easily into the App Store as their own pet languages, then Swift wouldn't be nearly as popular.

Re:68th to 22nd and there are many to go

[Anonymous Coward]

Hawking is interested in black holes.

Kardashian is interested in black a**holes.

Re:68th to 22nd and there are many to go

[SuperKendall]

Swift has gotten up to 22nd, but the rest of the climb past the stragglers won't ever happen.

I was going to write a response but the statement is so brazenly absurd it's obvious you are simply trolling.

Congrats on faking out the mods.

Re:68th to 22nd and there are many to go

[pspahn]

More popular ... wiping your ass with toilet paper, or wiping your ass with fir boughs?

More popular ... vacation on Maui, or vacation in Damascus?

More popular ... Green means proceed / go, or red means proceed / go?

You define popularity as an amount of noise generated by media about a given consumer product. I prefer to think of popularity as the choice of the masses due to utility.

Are you trying to imply that Swift would be better served by being less popular? I mean, maybe among you and your Swift coding buddies, sure, it will still be the most popular, but will it be the most popular EVAR? I feel like this ultimately has something to do with an inner fear and irrational hatred of anything below 32 bit.

Re:68th to 22nd and there are many to go

[Half-pint HAL]

The point of popularity contests in programming languages makes the difference between having to write all the libraries yourself, or being able to use work others have done. Also it's interesting to see what other people think is good.

Surely there's a saturation point for libraries where trying to see the wood for the trees is less convenient than just getting on with the job.

Re:68th to 22nd and there are many to go

[jellomizer]

Swift popularity is just due to the ability to make iOS apps. As iOS is a popular platform for apps.
Before swift you had objective C. So you really didn't have much of a choice.
Unless Apple opens their api a bit more so we can use swift in non-apple land and make cross platform apps. I will classify it in fad status.
Because there could be many things that can disrupt it now.
1. Cell plans get reasonable with their data plans and have better coverage. So we can go towards web apps again.

2. Cross platform mobile development tools with a cross compiler, so you don't need a Mac to develope iOS.

3. The next big thing that makes Apple look like blackberry.

4. Apple pisses off a lot of customers. From a politically incorrect message from upper management to a bad product line, or a massive security breach.

5. Fails to keep the OS current

6. Massive legal action.

7. Customers loose interest in the product.

8. A competitor gets the killer app and will not port it to iOS

9. Apple just stops liking swift (that is more of a Google thing)

10. Failed to expand the language to meet demand.

Re:68th to 22nd and there are many to go

[brunes69]

The fact that Swift *only* targets iOS and OSX makes it a non starter for most companies. Companies are not in the game of building an app twice from the ground up. Cross platform frameworks for apps and games are ESSENTIAL - even if the app has a different skin between iOS and Android, the internals all need to be cross-platform. Otherwise you are spending 2x the cost for none of the benefit.

FWIW, this is also why this survey is incredibly flawed. The vast majority of iOS and OSX apps are not open source so stats from Github are totally irrelevant as to what trends are actually occurring in industry.

Re:68th to 22nd and there are many to go

[narcc]

Hasn't that ridiculous rant been debunked to death yet? It's like the homeopathy of blog posts.

Re: 68th to 22nd and there are many to go

[EvilIdler]

Ruby has been used where Java was used before, but now some companies are switching to Go for the same purposes. Smaller, lighter apps that do exactly the same thing as the Ruby version. CloudFlare is one company that blogged about it, and I've seen other major companies make the switch.

Re:68th to 22nd and there are many to go

[david_thornley]

I'm trying to imagine Asimov doing something like that, but in reality he was a materialist and didn't believe in ghosts.

Re:68th to 22nd and there are many to go

[pubwvj]

Paris what?
Kardainsky?
Sorry, I've never heard of those scientists.

Re:68th to 22nd and there are many to go

[qw(name)]

Maybe with the volume on high.

"SITED as a language to watch"?

[jeffb (2.718)]

If only one of these languages would let me write a spell-checker that puts a red underline beneath words that are misspelled, and a 5KV pulse under the kiester of any "editor" who passes the wrong homophone...

Re:"SITED as a language to watch"?

[jeffb (2.718)]

...or under the keister of anyone who doesn't double-check the correct spelling of a word, even though the existing spell-checker flags the correct spelling as wrong as well.

Guess it wasn't German-derived.

Re:"SITED as a language to watch"?

[Half-pint HAL]

I'd always assumed it derived from the Scots "keich" -- excrement. Internet says no.

Control vs creation

[Anonymous Coward]

Alternately, the SO-heavy languages tend to be commands or data for an existing heavyweight software platform (SQL, XML, Makefiles, DOT, Mathematica) , while the GH-heavy languages are those used to build small or ground-up pieces of software.

Popularity != Quality

[UnknownSoldier]

McDonalds may serve billions, but no one is trying to pass it off as gourmet food.

Kind of like PHP and Javascript. The most fucked up languages are the most popular ... Go figure.

* http://dorey.github.io/JavaScr...

Re:Popularity != Quality

[unrtst]

McDonalds may serve billions, but no one is trying to pass it off as gourmet food.

But if you want to learn a skill that will almost certainly get you a job somewhere, then learning to flip burgers is a pretty safe way to ensure a job (quality of job not considered).

This type of popularity *does* have a purpose and implications and value. It's good to know. You still need other factors before you make your decisions, but it's a valuable one. It'd be nice if the various indexes had a page that also allowed them to be cross referenced and weighted to produce new calculated scores (ex. pay scaled by a factor of 1.5; lines of code in the wild scaled by factor of 0.5; most growth in past N years scaled by factor of 1.2; job postings for it scaled by 1; etc etc; combine them and calculate new scores). I don't know if I'd actually get any more usable value out of that, but it'd be (arguably) better than these stats we've been given lately.

Re:Popularity != Quality

[Xest]

I think this is the SO distortion effect.

Effectively the more warts a language has and/or the more poorly documented it is, the more questions that are bound to be asked about it, hence the more apparent popularity if you use SO as a metric.

So if companies like Microsoft and Oracle produce masses of great documentation for their respective technologies and provide entire sites of resources for them (such as www.asp.net or the MSDN developer forums) then they'll inherently see reduced "popularity" on SO.

Similarly some languages have a higher bar to entry, PHP and Javascript are both repeatedly sold as languages that beginners can start with, it should similarly be unsurprising therefore that more questions are asked about them than by people who have moved up the change to enterprise languages like C#, Java, and C++.

But I shouldn't complain too much, SO popularity whilst still blatantly flawed is still a far better metric than TIOBE whose methodology is just outright broken (they explain their methodology on their site, and even without high school statistics knowledge it shouldn't take more than 5 seconds to spot gaping holes in their methodology).

I'm still amazed no one's done an actual useful study on popularity and simply scraped data from job sites each month. It'd be nice to know what companies are actually asking for, and what they're paying. That is after all the only thing anyone really wants to know when they talk about popularity - how likely is it to get me a job, and how well is it likely to pay? Popularity doesn't matter beyond that as you just choose the best tool for the job regardless of how popular it is.

Re:Popularity != Quality

[Actually, I do RTFA]

But if you want to learn a skill that will almost certainly get you a job somewhere, then learning to flip burgers is a pretty safe way to ensure a job (quality of job not considered).

Not really. In 2009, you were more likely to get into Harvard then to get a job at McDonalds... and McDonalds was hiring tens of thousands of new employees. And that's one of the many new part time jobs they opened up, not one that pays the bills.

JS and PHP are a lot like that. A lot of jobs, but so many people competing for them, and so few hiring managers are able to judge quality, that it becomes a lottery for a shit job.

If you want a skill that will almost certainly get you a job somewhere, I recommend getting a CPA or something similar. Do something that is difficult, boring and yet is required by most people/companies and you'll do fine.

Re:Popularity != Quality

[T.E.D.]

The most fucked up languages are the most popular ... Go figure.

That's because they took their stats from StackOverflow. So basically this is a list of the languages people have the most trouble with.

Re:Popularity != Quality

[narcc]

That's not an uncommon story...

Re: Hmmm

[Anonymous Coward]

I think coffee script has its place. You probably just know enough about JS to wield its power properly. Most people won't get to that point (but will think they have) and giving them training wheels is probably in everybody's best interests.

typos in summary

[lkcl]

has anyone else noticed that typos have become much more prevalent in slashdot articles in the past year, and that they are less-often corrected? sited, it's, and many more.

Just learn C and Scala

[Anonymous Coward]

If you understand what is happening on the machine (C) and can wrap your head around a functional OO language (Scala or similar) then everything else is just variations on the theme.

I never got why employers are so obsessed about people having worked in language whatever.

Re:Just learn C and Scala

[jc42]

I never got why employers are so obsessed about people having worked in language whatever.

In my experience, this is because "employers" in this context means the people who are either doing the hiring process, or are the top management. That is, they are people who have no concept of what a programming language is. So they make the obvious connection based on the terminology: It's like a (written, probably) human language. This means that it's so complex, inconsistent, and full of special cases that it takes years for anyone to become fluent.

I've experimented in a few interviews, and tried to get across what learning a programming language is really like. One of the example I like to bring up is my introduction to C. I borrowed a colleague's "C bible", took it home for the weekend, and read through it. On Monday morning, I sat down at a terminal at work and tried writing a few programs. One of my self-assigned programs was a functional sort routine, which I had running and correctly sorting some available multi-Mbyte datasets by noon. After lunch, I coded up another half dozen sort routines, wrote an inteface routine that took pointers to a data set and a sort function and churned out the results. I tested all the sort routines on all several dozen available datasets, and printed out the sort speed for each routine on each dataset. (The results of this surprised a lot of people, who knew the usual estimated speeds of sorts on random data, but of course none of our datasets were anywhere close to random. Some were really upset when the winner on several of our - very non-random - datasets was the bubble sort. ;-)

Inevitably, though, the interviewers decided that I was lying. Nobody could learn a language that fast, y'know. They were clearly puzzled about why I would even try to pass off such a blatant lie, when anyone would know it couldn't be possible. My colleagues in the DP department weren't surprised, of course; they'd all done similar things to learn other languages. Sorting is a well-defined subject with lots of well-defined algorithms that they could mostly code up in a few hours, and C is a logical, well-defined language that was (almost;-) completely described in a rather small book. But the HR and manager types that did the hiring all judged the difficulty by imagining how long it would take them to learn to explain a sort algorithm fluently in a strange human language, and by that misunderstanding, I had to be lying, because nobody can learn a language that well in only a weekend.

(Actually, I've only tried this sort of thing after I've already decided I don't want the job. Making them thing you're lying during the interview isn't really a good idea if you want a job. ;-)

Anyway, if you understand this, you understand why employers might not want to hire someone who doesn't know a language. They're thinking of examples like opening a sales organization in Pakistan or Thailand, and what would happen if they hired people who weren't fluent in the local languages to run the sales campaigns. The computer folks' use of the term "language" makes them think that hiring a programmer who doesn't know language X to write software in language X will be that sort of disaster, and they can't wait the years it'd take to develop the sort of fluency they need. There's nothing you can do to teach them about their serious lack of understanding. If you try, you'll just be labelled a liar, so don't bother trying to educate them.

Re:Just learn C and Scala

[Shados]

Its not about the language, its about the ecosystem. ie: .NET may be somewhere in between java and scala, and the basic of the framework is the same, but if you do high end stuff, JVM languages and CLR languages are totally different. Different in how you debug it in production, different in what the standards are, different in what patterns people expect you to use when they build a library, different gotchas. And while you can pick up the basics in an afternoon, it can take years to really push it.

Doesn't fucking matter if you're doing yet-another-e-commerce-site (and if you are, why?). Really fucking big deal if you do something that's never been done before with a ridiculous amount of users.

Re:Just learn C and Scala

[w_dragon]

As someone who is a developer, no, you don't learn a language in half a day. I know academics think they can, but academics write the most obfuscated, unmaintainable, bug-ridden code known to man. And no, people interviewing developers at tech companies are pretty much never management. It's almost always a mix of developers and team leads.

Re:Just learn C and Scala

[angel'o'sphere]

There are plenty of languages you learn in half a day, e.g. as a C++ developer it should not take you much to learn Java/C#

But perhaps you mix up 'language' with 'libraries' comming with that language.

Re:Just learn C and Scala

[Actually, I do RTFA]

There are plenty of languages you learn in half a day, e.g. as a C++ developer it should not take you much to learn Java/C#

If you stick to the "See Spot Run" of "I can compile a sort algorithm" or similar, sure. But, just randomly based on my experiences, that's bullshit. The quirks of any language are fundamentally important. I've spent a couple of days looking for a bug in my code, that turned out to be a subtle difference in how templates/generics are handled between C++ and C#, where I was used the C++ way. Threading models are slightly different. Understanding when C# is passing by reference and by value is slightly diffferent.

I'm not saying it's impossible. And I'd rather hire a smart C++ programmer for a c# position than a dumb C# programmer. But I'd be far more likely to hire a smart C++ programmer who knew it would take more than a day than to hire a slightly smarter C++ programmer who thought that was all it took to switch.

Re: Just learn C and Scala

[david_thornley]

Sure. If the language concepts are familiar, you can learn it enough to do monkey coding over the weekend. You won't know how to use the language effectively or idiomatically, or where the dark corners are, or be able to easily read code written by somebody else that has a language construct you just skimmed over on Sunday afternoon. If it has concepts you aren't familiar with, you're going to have to learn the concepts to be truly proficient, and that can take years. Many languages nowadays have large standard libraries, and you aren't going to be familiar with them after one weekend.

Re:Just learn C and Scala

[david_thornley]

Speaking as an excellent C++ developer, it's easy to learn to read and write parts of Java and C#. Actually learning the languages is going to take a lot more than half a day.

Re:Just learn C and Scala

[angel'o'sphere]

And I'd rather hire a smart C++ programmer for a c# position than a dumb C# programmer.
Well, I guess picking up a new language quickly is a skill good programmers/software engineers have.

Regarding your template/generics issue, did you blog it somewhere? Would be interesting to see such examples.

Understanding when C# is passing by reference and by value is slightly diffferent.

I thought that was a property of the C# class?

Anyway, similar like with natural languages there are always smaller and bigger niches in a language (programming environment) where a particular programmer is not fluent. But extending that to: "no one can master the whole language (in a day, a week a month)" is a bit far sketched imho.

Re: Just learn C and Scala

[angel'o'sphere]

I explicitly excluded libraries :D

However I believe it depends on the libraries anyway. Is it framework like (Swing vs. WindowsForms -- which are both not frameworks, btw.), ofc you need some time to dig into it.

Is it just a library of collection classes, think about java.util.* then the IDE does most of the work. Can't be so difficult to figure if a method add() or put() is used to add to a container class.

I once wrote an XML parsing and binary file writing program in C# with out knowing much about C#.

The only problems where some missing overwrite fixed during programming and debugging and I was blamed not to have used the correct C# capitalization (actually that is the main reason I don't do .NET, lower case class names and capitalized method names just hurts my eyes ;D )

I did not have the feeling I was slower in C# than in Java, but it was a GUI less command line tool. Being required to make a C# GUI versus a Java GUI would likely been more time consuming (in Java I mainly program it by hand, in C# I would use a GUI builder)

Re: Hmmm

[gl4ss]

why is coffee script then less readable? it's not training wheels, it's something else.

it's more like blocking the handlebars from going one way, locking the seat to super low position and removing one of the pedals and saying that makes it easier to instruct new bicyclists.

Re:Is this a joke? IPhones are dying.

[Noah Haders]

ms just released a high quality outlook app on ios. works pretty good.

Re:Is this a joke? IPhones are dying.

[iluvcapra]

I know, that LINC is an underground sensation...

methodology

[phantomfive]

If anyone is wondering about the methodology, I did the hard work of reading the article so you don't have to.

Essentially they measured the popularity of the language on github, then measured the popularity of the language on stack overflow. The rank is an average of the two.

Swift is right there next to assembly, in case you're wondering how popular it is.

Re:methodology

[swilver]

It looks like a logarithmic or ranked scale as well, as some obscure stuff is way too high compared to the top contenders.

Re:methodology

[sog11]

[Disclosure: I'm the author of the linked piece]

The scale is not logarithmic, just a basic plot of the correlated rankings.

Re:bleh

[Darinbob]

Most used piece of furniture in large households is the toilet.

Re:bleh

[omfgnosis]

I hope that depends whether you're counting sittings versus time spent.

Re: Hmmm

[omfgnosis]

CoffeeScript has too much in common with JavaScript, with too many of its own esoteric compromises, to be a good compile-to-JS contender. It also has the disadvantage of being fucking awful.

If we're picking languages that compile to JS, we have a lot of options. Why would we pick something that is such a derivative work? If I'm going to be that close to the metal, I'd rather just write on the metal.

Re: Is this a joke? IPhones are dying.

[Anonymous Coward]

This could be the year of the windows des.. umm, ph... err thing.

Shell is the best

[lucm]

I don't know why "Shell" is in only 11th place. It's such a powerful language, it has the whole shebang.

Slashdot 101

[lucm]

that they are less-often corrected?

If you've noticed that, it means that you often read those articles more than once. That's not how Slashdot is supposed to work.

Here is a tutorial:

1) Have a quick look at the new articles. If you manage to read an entire title, click on it, otherwise scroll.

2) Check if the submitter is Bennett. If it's the case, go back to #1.

3) Read the first 2 lines of the summary, and if those contain hyperlinks, move your mouse over the first one to see if it's a reputable domain (but don't click - the idea is just to see if the story is bullshit). If there are many hyperlinks in the first two lines, especially if there is a series of 1-word hyperlinks, go back to #1. In any event don't read more than 2 lines.

4) If there are 10 comments or less, post a Frist! comment. If there are more than 10 but less than 50 comments, post a comment without reading the existing ones. If there are 50 comments or more, find the first 5 Interesting and try to find a weakness in the comment (that's your best way to a 5 Insightful). Don't worry if you don't know the details of what is in the article (or even in the summary), most people don't read those either, and those who do will provide you with the tldr version at some point if you're terribly wrong.

5) If you are bored, scroll to 2/3 of the page and find the first -1 Flamebait. Odds are that it's one of the most interesting comments in the page.

6) If you are still bored and there's nothing left but yro or "answers your questions" stories on the homepage, pick any article, remove the moderation filters and try to find those long rambling homophobic/racist erotica comments, or why not treat yourself to a full read of one of the posts from Mr Hosts file.

There you go. There's plenty to do on Slashdot besides keeping statistics about how often typos are fixed.

Re:Slashdot 101

[omfgnosis]

This is fascinating, and I think it gets to a lot of the gripes I see in comments here. Basically, the longed-for slashdot of old was designed for rapid consumption of low-density news data at a fast pace. The slashdot we all experience now provides that, but the complaint is that the superficial browsing you describe yields less of a fix for data-hungry readers than it used to.

Frankly, I think the level of discussion has gone up as the level of satisfaction has gone down. I come here for the comments.

Thanks for at least giving me some interesting meta-discussion!

Re:Slashdot 101

[Hognoxious]

7) Try to work in something about the layout being totally fucked. Even if it's not, it probably will be again by the time anyone reads it.

Re:Slashdot 101

[ignavus]

I think Slashdot should make this their official site tutorial.

Re:bleh

[gl4ss]

that's because you're lazy.

I'd wager that even then the bed would win.

"CoffeeScript, often cited as a language to watch"

[Shados]

CoffeeScript is almost tied to Ruby. Its Javascript for people who like Ruby syntax, even if it costs them real debuggability (sourcemaps are meh with it, and the output code is terrible, no matter how much they argue until they're blue in the face that its beautiful... I had 20 lines of CS code get compiled to a single line of nested ternary operations before...that was fun...not).

While on that index Ruby went up, non-ruby people rarely hit CoffeeScript (they do, but in a significantly smaller ratio), and with ES6 around the corner and amazing transpilers for ES6 (that are actually debuggable), that eats away at it.

Its a technological dead-end (generators JUST got in master...node.js had time to get forked and the fork have a 1.0 release that supported them before CS added them...), so of course its going down.

Stats are irrelevant

[msobkow]

You have to use the right tool for the job, even if that means learning something new to you. Competent programmers don't make their decisions based on what tools they already know; they make them based on what is the best fit for the requirements of the system or component.

Yes, component. It's not at all uncommon for a well-designed system to be implemented using multiple technologies and languages, each best suited to their piece of the puzzle.

Re:Stats are irrelevant

[Half-pint HAL]

It's not at all uncommon for a well-designed system to be implemented using multiple technologies and languages, each best suited to their piece of the puzzle.

Which is why it's a nuisance that a single file can only be in one language. I've been saying it a lot of late, but the reason that most multiparadigm languages fail is that they add keyword upon keyword in order to hack a single syntax into multiple different paradigms, rather than simply having syntax defined by context.

The most extreme example I can think of would be SQL queries. When I last needed to database queries from Servlet Java (over a decade ago), you had to build everything up as strings and then call a library method with the string, then process the output... casts etc etc etc. Yeuch. I imagine it's now more like python-sql, where you do everything with object manipulations, which then generate the SQL code automatically. But by shifting all the database handling to "libraries", we no longer have a language for databases. What if instead our language allowed us to embed different language/syntax blocks? For example, an SQL recordset can easily be converted into a Python list of dicts, so wouldn't this be nice...?

list_of_dicts = SQL { SELECT t1.name AS name, t2.location AS location FROM t1, t2 WHERE t1.id IS t2.id ANS t2.location == PythonVariableNameHere; }

It would mean my code editor would be able to do syntax highlighting from all the different structure types in my code, and not just the ones in the "master" language.

Re:C is the best language

[phantomfive]

I don't know why the marketing weenies that hire idiots don't just hire competant C programmers and make them transition to the language they want.

Because they're hard to find.

Also, just an FYI, if you're having trouble finding a job right now, it's not because of your skill it's because of your personality.

Re:"CoffeeScript, often cited as a language to wat

[phantomfive]

I had 20 lines of CS code get compiled to a single line of nested ternary operations before...that was fun...not).

You have to admit it's pretty cool, though.

Where are the nixy shells?

[stridebird]

No bash in the stack vs git graph. We not using that anymore? I didn't get the memo.

To interpret Swift rank properly

[abies]

From the chart they have presented:
- Swift is less popular on github that Emacs Lisp and Lua and considerably less popular than VimL
- Swift is about same popular on stack overflow as Assembly, ColdFusion, Dephi and Powershell

Too bad they don't provide raw numbers. Currently Swift is ranked at '75' while Javascript is ranked as '100'. What it really means that there are 1,161,994 repositories marked as javascript, and 17,413 repositories maked as Swift. Pascal, which has '50' in that axis has 4348 projects.

Coffeescript

[Daniel Hoffmann]

Many coffeescript devs when asking questions in stackoverflow or making public libraries in github use Javascript for increased visibility. Also I don't know how they measure data in github, but for each .coffee file there is a .js file as well which could distort the results.

Top most popular language for learnings

[wonkey_monkey]

JavaScript, PHP Top Most Popular Languages

Not just most popular, but top most popular!

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Is this a joke? IPhones are dying.

[Gonoff]

Your message is partially right. iPhones market share is heading down true but unit sales were still rising and have just taken a boost from China.

In the long term, your provocative heading may well turn out to be correct but that is years away. Businesses want their development done now on machines that are "out there" at present, not years away.

I would like it If Windows phones actually caught on but that one may be even further away. Their market share is so low that it could be hugely changed by a rounding error.

Businesses are shedding BlackBerrys at speed. There are two alternatives. Android for companies interested in cost, functionality and versatility or iPhones for appearance, coolness and keeping non-technical executives happy. Windows phones are somewhere in between but it is hard to tell as they are so rare.

I have just had my work BB replaced with an iPhone. Our department has provided support for them for years but now we are on them too. As I was aware, in comparison to good android phones it is limited and fiddly. Sending email is infuriating. I suppose the fashion conscious don't use email any more. I've got better things to do than look like a manager. I would have preferred a Note4. I could then leave the tablet behind. As it is, I read the email on the iShiny but if I need to reply, it's Android 7" tablet to the rescue!

Maybe iThings would fo the way of the Dodo if there was more than one alternative. At present, there is only Android and that is not favoured by the uninformable suit wearers.

Re:"CoffeeScript, often cited as a language to wat

[Shados]

For me it was classes and inheritance that drew me to coffeescript

Bad start, considering classical inheritance is a downgrade from prototypical... CS is just sugar over the built in stuff, but it basically does it worse than how a library could using the full power of javascript prototypal inheritance (ES6 has that same issue though, it was a big source of debates...). Now you have the issue where ES6 and CS inheritance are incompatible in very subtle ways...for most purpose they work together fine, but the super behavior is different, which can be awkward at best.

Personally, I don't see it as a dead-end

Its a deadend because they're late or don't have a path to use the new features. Generators were way late, getter/setters can't even be safely consumed in all cases (it introduces very subtle bugs) and can't be created, string templates are behind (I don't think CS has string templates yet?), and they don't have a plan to keep up with it. The maintainers generally start thinking "Oh crap, we need to introduce this feature somehow" once its natively supported by mainstream environments...which is way too late. And in some cases (again, classes/inheritance), they're incompatible, which will lead to some subtle, very annoying bugs.

The language features almost all come from other languages, so unless "Other JS Devs" do nothing but JS, you don't really have a leg up.

And no, I've never had an issue with debuggability

Yes, source maps will give you errors. You may even be able to use them in the debugger to set breakpoints. Its flaky at best. Getting error line numbers isn't debugging. Being able to load up the Blink V8 remote debugger and line by line/watch/set breakpoints/REPL using the same language you wrote the code in, is debugging, and you can't do that with any transpiled language. Using ES6 transpilers you can at least get close, and as features get supported in your environment (ie: io.js supporting generators), you can disable the transpile of features 1 by 1 and improve your debuggability.

Its gool to get exception line number...until your bug doesn't throw any exception. Then again, ruby devs seem to think binding.pry is modern debugging (and while Ruby IDEs usually offer modern debugging environments, they're usually so slow/unstable as to be unusuable... RubyMine fail). Even embedded C devs have access to better tools than that.

Re:C is the best language

[hcs_$reboot]

printf(1+2+"3+4+5");

You missed something:

printf(1+2+"3+4+5"); // Insightful

Re:C is the best language

[hcs_$reboot]

Because they're hard to find.

Unfortunately a lot of the incompetent ones are experimenting with programming and proudly offer their babies as open source (e.g. a lot of the camera, multimedia stuff on Ubuntu).

*Not* the most popular

[T.E.D.]

They took their list from the languages GitHub and StackOverflow. GitHub is an online source code repository service, and StackOverflow is a technical Q&A site. So this is essentially some combination of the languages used most by folks for Open Source (typically non-paying) work and the languages that are causing people the most grief.

That's an interesting way to define "popular".

Re:C is the best language

[Qzukk]

I think you mean /* Insightful */

Re:Objective C at 10th

[narcc]

As they complete exclusively with each other, I'd say that swift taking the 10 spot is unlikely without Objective C vanishing from use completely.

Re:Hmmm

[slashdice]

Coffescript is good for people that love the worst parts about javascript, python, and ruby.

Re:C is the best language

[tepples]

if you're having trouble finding a job right now, it's not because of your skill it's because of your personality.

So do people with personality disorders or mild autism deserve to starve?

No iOS API to enumerate nearby SSIDs

[tepples]

I don't think it'll really catch on until you have access the entire iOS API.

Genuine question: don't you?

No, the public doesn't have access to the entire iOS API in any language. Apple reserves large chunks of the iOS API for itself, not for apps on the App Store. For example, Mozilla Stumbler is an app to help contribute to a free database of local positioning beacons. It watches your GPS and Wi-Fi and reports locations associated with SSIDs that your device can see. But it's Android exclusive because the public subset of the iOS API lacks any way to enumerate nearby SSIDs.

Re:C is the best language

[phantomfive]

Eh, based on his post it sounded more like Tourette's, in the most stereotypical way.