

Choosing a Programming Language - fawce
http://the-world-is.com/blog/

======
monkeyfacebag
There is no single best language. Instead, what you get from any sufficiently
good programming language is a series of tradeoffs. Haskell, for example,
provides the benefits of pure functions (lazy evaluation, composable memory
transactions, ability to reason about code) but in so doing it takes away your
ability to arbitrarily mutate state and perform IO. That's a tradeoff. Python
provides a clean, easily readable syntax that leverages whitespace. But you
can't define multi-line lambdas. That's a tradeoff. Most of the languages on
the author's list use garbage collection, yet another trade off.

Importantly, it is nigh on impossible to understand the pros and cons of these
tradeoffs unless you learn the language first. So get a dart board out and
pick a language at random. Learn it well enough to find things you don't like
about it. Then learn another language that fixes the problems you had with the
first and figure out what you don't like about _that language._ And so on.

Also, be aware that this process will never, ever end. Because there is no
single best language.

Except Haskell ;)

~~~
dons
> it takes away your ability to arbitrarily mutate state and perform IO

No. Haskell requires that you declare where IO is allowed (via the type). Once
you assert that you admit mutable state (ST) or arbtirary IO (IO), then you
are free to use them.

~~~
polymatter
In fairness, Haskell makes it more awkward to deal in mutable state and
arbitrary IO. Like how not using goto in a more mainstream language makes it
more awkward to have arbitrary control flow. Debugging is annoying when I
can't stick a println or puts in any arbitrary function. (The solution of
course is to have small functions and print them. If your Haskell function is
over 20 lines long you're probably doing it wrong.)

Of course, Haskell also means if your program compiles, 90% of the time it
runs fine. I love that about it. (Unit tests are still required for the things
the compiler can't catch, but its a major win regardless)

~~~
dons
> Debugging is annoying when I can't stick a println

You might not know about Debug.Trace?
[http://www.haskell.org/ghc/docs/latest/html/libraries/base/D...](http://www.haskell.org/ghc/docs/latest/html/libraries/base/Debug-
Trace.html#v:trace)

~~~
polymatter
Thanks very much! Thats just what I wanted :)

------
agentultra
Analysis paralysis!

The computer is a machine. It understands one language. Everything else is
sugar on top. The language you should choose is the one that exists at the
right level of abstraction for the problem you're trying to solve. That's a
very academic way of saying, "choose the right tool for the job."

Personally I'm of the opinion that you can get really far knowing C and Common
Lisp. They represent two fundamentally different models of computation and all
of the other languages (save the Smalltalk offshoots and obscure ones I
haven't had the pleasure of experimenting with yet) are essentially sub-sets
of functionality from one or both of these two languages.

It's too easy to get caught up in the "feature creep," of all of the languages
available today. Some will claim "immutability by default," is a feature. It's
not. Any sufficiently sophisticated evaluator of a language can stratify a
program into a process capable of emulating a machine that can treat all
memory as "immutable by default." It's important to remember that often these
languages are created to solve a specific problem and then evolve over time to
become more general. It is best, in my experience, to just go straight to the
source and work down to what you need.

~~~
rdtsc
> Personally I'm of the opinion that you can get really far knowing C and
> Common Lisp.

Yup. I advocate a fast running & low level language like C plus a quick to get
started with lots of libraries language like Python.

At the end of the day, unless pure algorithms are the deliverables (and it may
very well be), it is really about the libraries and ecosystem. In the majority
of cases, it is simplest to re-use code someone already wrote. Who cares if
this language compiles to assembler and is super functional and does all kinds
of fancy tricks, can it read from Postgres or talk to RabbitMQ? Does it have
an easy way to parse JSON or generate uuid's, or do I have to now spend time
writing db drivers, json parsers before even starting on the real problem?

~~~
cpprototypes
I agree that it's enough to know well one low level (or medium level) language
and one high level language. For me, I decided a while ago that the two
languages will be Java and Javascript. It was an easy decision since I use
those languages at work, they both have healthy and growing ecosystems, and
active communities.

------
sswezey
The graphics in this are not very helpful, inconsistent and in some cases
wrong. Your 3-d size/cpu/memory was impossible to read, there was no origin.

Secondly, the intended uses and paradigms were wrong. Lisp can do object-
oriented programming with the CLOS and I'm pretty sure C++ was designed to be
a general purpose language. In the intended uses, you have so many categories
that are one off or very similar to others: what's the difference between web,
web application and client-side?

Also, the graphics were not sharp and looked hazy. And the languages choices
were not consistent, you have Clojure on some of them but not others. And in
general, benchmarks don't mean anything without context.

This article has very little insight and has quite bad presentation.

~~~
iand675
Another wrong issue in the article is that Haskell was not created with the
intent of it being a general purpose programming language.

------
notb
I don't understand these questions:

 _“Is optimization of speed premature while productivity languishes?”; “Are
semantic elegance and lexical simplicity just means by which to further our
productive capacity?”_

The flowery language is confusing me. Is there any real content here? I've
never heard anyone talk about programming languages like this. Writing like
this just makes it harder to understand and seems like putting on airs

------
just2n
The grids comparing language features are mostly incorrect, generally towards
a stereotype that's common but incorrect, or very dated.

------
nullc
C not for applications? (or LISP for that matter) A little bias showing there.

~~~
muuh-gnu
Not only bias, but obviously pure ignorance too, at least with respect to
Lisp. In his table, Lisp seems to be unsuitable both for meta programming and
multiple dispatch, which always have been touted as Lisp's major features.

~~~
reeses
It's apparently not aspect-oriented, either.

The article is full of wrong information, wrong logic, and wrong conclusions.
I feel embarrassed for the author, who must have spent a lot of time to
produce something that is an intellectual net loss for anyone who reads it.

------
terhechte
I write Python & Objective-C most of the day, used to work for several years
in a PHP/JS shop and have to code in Ruby and/or C from time to time. I
recently felt the urge to learn a new language which is distinctly different
from what I know so that I can learn new things. I considered Erlang, Common
Lisp, Clojure, Go, Haskell, Scala and Elixir. I plan to use it for server side
web development and if possible for command line scripting (where I currently
oftentimes use Python). After much back and forth I ended up having to decided
between Clojure, Erlang or Scala. I then went with Scala because it seemed to
offer the best of both worlds: It has a good actor library with Akka, it has
macro support, it is functional, it offers good OOP support (to ease the
transition for me), and as a boon it also allows to develop for Android,
something I may want to tackle in the future. So far I'm really happy. The
only downsides are that the REPL starts up pretty slow (I'm used to Python,
which starts up way faster), and package installation (especially of Java
packages) confuses me at times. I still may want to go to Clojure or Common
Lisp from here, but right now I'm happy with my choice.

~~~
Nick_C
> Scala... REPL starts up pretty slow.

I wonder if your setup is faulty. My Scala REPL takes a couple of seconds to
start. Admittedly longer than Python's, but not enough to worry about it. I'm
on an old clunker laptop too.

Also, you may be interested in this course on Functional Programming in Scala
run by Martin Odersky himself. It started last week.
<https://www.coursera.org/course/progfun>

~~~
happy_dino
I'd say that this sounds pretty too slow, too. My REPL starts in less than a
second.

------
greg5green
I tried to take the quiz but the app the OP built it in on FB kept asking over
and over and over for permissions I wasn't willing to give it. :(

------
richardjordan
I suspect like a lot of people who came late to programming my choice was
initially dictated by simple pragmatic concerns:

What can I learn quickly? ...that has a fairly simple forgiving syntax ...that
has a ton of online help and resources ...that I can get a prototype product
out simply with ...etc - I think it's a not atypical set of concerns.

For me, because of all the online help and community and ease of getting
something useful working quickly I landed on ruby, at first using rails.

My analysis may have been simpler than the OP but as I learned more I was able
to understand more of what I needed, where my choices were good, where not. I
was able to pick up other tools and languages as my interest was piqued.

So no one choice is right for everyone but this approach worked for me, but
more than anything the key is to drop the analysis and learn SOMETHING ...once
you start it's easier to pick up more.

------
vorg
The RedMonk chart measures language popularity by activity on GitHub and
StackOverflow. Top business languages Cobol, Transact-SQL, and PL/SQL aren't
included at all in the 84 languages listed so the popularity measurement
criteria is flawed.

The Redmonk measurement also seems to be gamed because the second cluster in
the chart includes some languages with backers who are heavily promoting the
popularity of the language, including using Stack Overflow as their primary
documentation effort and creating numerous shell projects on Github.

------
fleitz
Seriously how many people here write programs to solve k-means or n-body
problems? Who fucking cares how many lines of code it takes to write k-means,
and who fucking cares how long it takes to execute or how much memory it
consumes.

Most of us write software that moves bits from an API or DB to a screen. If
we're lucky we translate a couple of those values to a color or something.

Why are benchmarks so focused on code no one writes? How many successful YC
companies aren't CRUD apps?

Type the problem you have into google, write your stuff in the language that
has the most concise stackoverflow answers on how to solve that problem.

~~~
banachtarski
If you are in the games industry, you solve n-body problems all the time. If
it's a multiplayer game, you work with distributed n-body problems. Even if
all you did was a CRUD app, if you truly became successful, memory footprint
and CPU usage will matter. The 300x slowdown from Ruby _will_ sting. But for
everybody else, you're right. None of this is relevant, in the same way that a
5000 hp car engine isn't useful to anybody but Batman.

Personally, I am very fortunate to __not __think about nothing but CRUD apps
all the time. Working with games, all the fun things like sort speed, path
finding, etc are real world problems :)

~~~
fleitz
And how many games programmers are thinking.. hmm... should I write my physics
engine in ruby?

~~~
banachtarski
Zero, but other languages like Haxe, Actionscript, Javascript, and the like
are becoming more relevant as higher quality browser games become more
prominent.

------
vxNsr
The graphs seem to imply that functionality wise C# is the best choice.... I
don't know much about languages but if that's true I wonder why it's not
taught more often in schools, most classes I've seen are either for java or
c++, and then assembly and matlab

~~~
doktrin
The case could be made that universities teaching Java are already catering
too much to industry. For my part, I would vastly prefer working with a lisp,
ML or other esoteric language while in school. There's no shortage of time
afterwards to work with more pragmatic languages & frameworks.

edit : not meant to imply that Lisp or Ocaml are not "pragmatic", just that
the likelihood of working with them as a professional developer are
substantially lower than Java / C# or Ruby / Python.

~~~
yuushi
Why does it have to be limited to a single language at all? Exposure to
multiple languages should be the norm.

------
malodyets
How does a non-programmer write a guide to programming languages that has any
value? Full of errors and misinformation gleaned from far too many hours
reading websites and far too few hours writing code.

------
dbbolton
I'm pretty curious as to how the author came up with the answers in that quiz.

