The author really has no clue. He also doe snot understand what static and dynamic typing means and that it is orthogonal to weak and strong typing. Or that whether you have GC or not is not necessarily dependent on the language. You can attach a GC to C and have it working reasonably well.

This article was written by an incompetent wannabe.

You will get no argument from me on that.

Yes, this joker probably meant "has a more complex type system".

You really do not get it, I agree. This metric is useless. It follows the definition of a metric, true, but it has no reasonable practical use, hence it does not deserve any special distinction, like being given a name. That is what is fake here.

The ire is because quite a few people cannot distinguish fake TV science and engineering from the real thing anymore. This "metric" is a high-quality fake and completely useless.

Really, you do not understand what makes swap slow or fast. Go play somewhere else.

Scala is too advanced for most of the mediocre crowd calling itself "programmers" these days.

Erlang is pretty cool for the intended application scenarios. It is not really a general-purpose language. If you need, for example, excellent crash-proofness, updates to running code and massive multi-threading, Erlang is what you want to use. (Ever tried to run 1000 threads in Java? I know people who did, for this Java is a completely unusable toy...)

The second problem is that Erlang is decidedly experts-only. Real understanding of advanced programing concepts is mandatory. Don't even think about doing anything with Erlang unless you have top-notch people. (These people do not need to already know Erlang before though.) Of course, one top-notch coder is more productive than 10 of the typical mediocre ones.

It is not. Strong typing can be implemented by attaching types to data. Static typing always attaches types to variables and they are fixed. But strong typing can also mean type-less variables, but no implicit conversion of values. For example, Perl is weakly typed, but that is because it will, for example, happily convert a string to a number all on its own. Python, on the other hand, is strongly typed, despite its variables not having types just like in Perl. The values assigned to the variables in Python have types and all type conversions have to be explicitly requested by the programmer.

With such a stupid article, it is really no surprise the author gets basic things wrong.

Next year, unless you are at the bottom of the skill and payment pyramid, you will need C and derivatives (C++, Objective C) and maybe Python or Perl.

When you "calibrate" swap for specific uses, it becomes non-general. In that situation it is far better to let the application use on-disk storage, because _it_ knows the data profile. Sorry, but fail to understand swap.

Other Slashdot poster adds meaningless posturing as that is the limit of what he can do.

Whether measuring speed is a meaningful benchmark depends on what you measure the speed of, relatively to what and what the circumstances are. There are many situations where "speed" is not meaningful, and others that are limited enough that it is.

However, the metric under discussion will not be meaningful in any but the most bizarre and specific circumstances, hence it is generally useless. For the special situations where it could be useful, it is much saner to adapt another metric than define a specific one as this pollutes the terminology.

The uses for that single number are as follows:

a) Some class of people like to claim "mine is bigger", which requires a single number. While that is stupid, most people "understand" this type of reasoning.
b) Anything beyond a single number is far to complicated for the average person watching TV.

In reality, things are even more complicated, as speed and compression ratio depend both on the data being compressed, and do that independently to some degree. This means, some data may compress really well and do that fast, while other data may compress exceedingly bad, but also fast, while a third data set may compress well, but slowly and a 4th may compress badly and slow. So in reality, you need to state several numbers (speed, ratio, memory consumption) for benchmark data and in addition describe the benchmark data itself to get an idea of an algorithm's performance. If it is a lossy algorithm, it gets even more murky as then you need typically several quality measures. For video, you may get things like color accuracy, sharpness of lines, accuracy of contrast, behavior for fast moving parts, etc.

Good comparison.