
Language is not important - r4um
http://coffeenco.de/articles/language_is_not_important.html
======
protomyth
I read a story in the Telegraph
[http://www.telegraph.co.uk/culture/theatre/william-
shakespea...](http://www.telegraph.co.uk/culture/theatre/william-
shakespeare/10372964/Shakespeare-read-in-Elizabethan-accent-reveals-puns-
jokes-and-rhymes.html) that talked about the original pronunciation of the
Early Modern English in Shakespeare's plays. How hearing it in the original
pronunciation brought out the puns and rhymes.

"I will never be able to do Pattern Matching in Java that'd look at least
remotely sane, but in majority of cases I can also live with it."

Many of us have only experienced the Bard in a modern pronunciation and have
enjoyed it greatly. We can live with it, but I cannot help but think that I am
missing something. It seems very much like what you miss from using the
programming language closest to your thoughts and the tools that go with it.

~~~
drcomputer
Shakespeare also invented words when the ones he could not express the
concepts he wanted to convey. Those words also had to be accepted and
understood by those who read his literature. I think when people feel stuck
between paradigms, there's something very special about that.

> How hearing it in the original pronunciation brought out the puns and
> rhymes.

These happen accidentally sometimes.

~~~
mrcsparker
Lots of the puns also come out when spoken with a Southern accent. Add a drawl
and "hour" sounds a lot like "whore".

    
    
      And then he drew a dial from his poke,
      And, looking on it with lack-lustre eye,
      Says very wisely, 'It is ten o'clock:
      Thus we may see,' quoth he, 'how the world wags:
      'Tis but an hour ago since it was nine,
      And after one hour more 'twill be eleven;
      And so, from hour to hour, we ripe and ripe,
      And then, from hour to hour, we rot and rot;
      And thereby hangs a tale.'
    

Edit: added Act II, Scene VII from As You Like It for context.

~~~
stormbrew
That's not really surprising. The American southern accent is, afaik, widely
believed to be much closer to the accent spoken by the British who first
colonized the US. This accent would have been something on the cusp of early
modern english (which Shakespeare's work is an example of) turning into modern
english.

------
lostcolony
I find it interesting to hear people say 'language doesn't matter' (and
similar, 'it's not important'), in general (because often the same people
then, when asked what language they develop in, turn around and say that they
'use multiple; we always use the right tool for the job'), but in this article
it's especially interesting given it's right after "and here are the things I
learned, and the things that I have not grokked yet in this language".

While there is a certain truth to there being no inherent reason why you can't
use an idiom or practice learned from one language in another, it's incredibly
disingenuous to then say the language isn't important (and that it's only the
concepts learned). The language is what encourages you to think in certain
ways, and it helps you code along those ways, while making it difficult to
code in others.

I recently went from having coded in Erlang almost exclusively for two years,
to coding something small in Java, and I can't even express how irritating I
found the experience. A part of it was writing a combination function (i.e.,
given a collection, generate every combination of elements). In Erlang it was
the work of but a moment, and resulted in 3-4 lines, that were incredibly
readable. I then attempted to convert it back to Java...and what do you -mean-
collections are all destructive?! Ugh, I have to manually copy them out for
this to work?! Etc. So much pain. Java got in the way of writing it cleanly,
and when I looked for solutions online written in an idiomatically Java way, I
found even more verbose solutions, that tended not to be as reusable
(involving explicit nested loops rather than recursion, or recursion rewritten
with a while loops; i.e., a collection of 5 items would have 5 loops and not
be reusable for a collection of 6 items).

Quite simply, using a language with idioms from another language, while
possible, is often times intensely painful, with a whole new slew of not well
known caveats (since most developers in that language aren't using it that
way), to where if you know you are going to develop a specific way, you will
be far better served to use a language that supports it naturally.

And his takeaway at the end isn't in any way relevant to the title of
"Language Is Not Important".

~~~
NhanH
The note with Java is spot on. Even with the new language constructs in Java 8
(map, stream, lambda etc). More than one time I've to stop and decide whether
to just use for loop rather than any of those higher level constructs. There
are several cases where the use of map/ lambda looks worse than a for loop
(when you have to chain them together, and the function to be used is not a
class function etc.). And ugh, I have to "collect" after a map, what is that?

If a for loop is 3 line, and you have to write 3 line with a whole bunch of
"." for a map statement, it's probably of no help in term of expressiveness.

~~~
Retra
Even those higher-level constructs in Java are ugly verbose hacks... I was
excited to have those, but when they came out all I could think was "this is
more work than doing it the old way..."

------
rdtsc
I think this is a good insight.

It is about semantics -- how do you structure your program in a more
functional way or how to you use immutable data structures to model your
domain, or do you use callbacks, or actors for your concurrency. Object
oriented everything was a fad then functional everything is and so on. And
while some languages are more opinionated about one way or the other, you can
often structure or start to think in terms of different paradigms in most
popular languages today.

At a higher level then you have to answer the questions of "Why do I want to
structure my program with less global state?". Why does OO work well here?

Another point that is important to make I think is that languages are about
the library ecosystem as well. There are plenty of cool research languages
Alice, Oz, Curry [Haskell-like logic language] and others. But they lack a
rich library ecosystem. So you go to build something and you find yourself
writing the library ecosystem first. Which is instructive but not if you want
to get to your goal of having a product first.

Then there is always the issue of syntax. I hear this about Erlang. Syntax is
different, but I think that is not the hard part. If typing . instead of ; at
the end of expressions is what kills it for you, what do you do with immutable
data structures, and separating concurrent units of your code into actors.
That is the harder and more interesting part.

I like Fred Hebert's idea here -- [http://ferd.ca/on-erlang-s-
syntax.html](http://ferd.ca/on-erlang-s-syntax.html).

------
sramsay
I'm big into FP, but I've studied Haskell only lightly. Of all the posts I've
read about Haskell, this is without doubt the most intimidating.

Clearly, the OP is a quite experienced, skilled programmer, and yet he's been
at Haskell for _years_ \-- taking books on type theory with him to lunch --
but still struggling with the language at some level.

I believe very strongly that programming in one paradigm can really change the
way you think about another (learning Lisp changed the way I program in most
languages, for the better). But it really sounds as if the payoff with Haskell
just isn't that profound relative to the amount of effort required (unless
your real interests lie with abstract algebra or PL research or something like
that).

I hope this is not coming across as flamebait. I'm not wondering whether one
can profit from studying Haskell; one can presumably profit from studying just
about anything in computing. But Haskell really sounds like a very long slog
for a relatively small slice of cake.

~~~
coolsunglasses
I've taught a lot of people Haskell, including non-programmers.

After a few months of starting from nothing (zero programming experience), my
main non-programmer student is now coauthoring a book on learning Haskell [1]
with me.

Learning Haskell doesn't have to be hard. It helps to follow a guide designed
by people that have plenty of experience teaching Haskell [2].

There is an IRC channel at #haskell-beginners on Freenode.

The author of the post refused to avail himself of other peoples' help,
particularly via the mailing list. If you seek help you can learn Haskell and
apply it to practical problems in less time than you'd think.

[1]: [http://haskellbook.com](http://haskellbook.com) [2]:
[https://github.com/bitemyapp/learnhaskell](https://github.com/bitemyapp/learnhaskell)

~~~
ifesdjeen

      The author of the post refused to avail himself of other peoples' help
    

Chris. Please stop following my posts around the internet and spreading lies
about me. Last time we talked chat was like that:

    
    
      ifesdjeen: i don't want anyone to fix my problems)
      bitemyapp: I don't give a fuck what you want.

(sic.)

There were several occasions on both IRC, and Mailing Lists when people were
like:

    
    
      x: ifesdjeen: that's all functorial
      ifesdjeen: functorial?
      x: ifesdjeen: and dont you know that
    

Or:

    
    
      x: just write a function of that type for fmap
      x: thats YOUR problem now isnt it
    

Yes, I didn't know what functorial is. And yes, it happened more than once.

Please, stop spreading these lies. I have explained you more than once that
I'm not posting things to Haskell Mailing List and try avoiding asking
questions on IRC due to 2 reasons:

1\. When I have a more complicated question (such as thunk leak detection,
monadic order traversal, implementing StateT instances to allow state to be
handled transparently in concurrent apps), these questions take more than 2
minutes to answer. And both you and other people couldn't answer them (see
your email from several month from now). And I do not blame you or them for
that.

2\. When a beginner comes with a simple question, he gets based by "experts"

So there are no questions you can ask and be happy: hard ones get ignored (by
everyone including you). And easy ones make (some) "experts" talk with
condescending tone.

Yesterday, 5 people wrote me a DM saying that I should ignore you, because
your behaviour has been known to be offensive and bad even since the days
you've been doing Clojure.

As for everyone else, please don't get offended if anyone happens to say you
something condescending or offensive on IRC or Mailing List. People are
people. But it doesn't mean you _have_ to keep posting your questions if you
don't feel sure you're welcomed there.

p.s. it's also not like Chris is hearing this for the first time. I've said
same thing on Twitter and on lobste.rs:
[https://lobste.rs/s/hmmqkp/alex_p_s_blog_language_is_not_imp...](https://lobste.rs/s/hmmqkp/alex_p_s_blog_language_is_not_important/comments/10vvg4#c_10vvg4)

~~~
tome
Would you mind posting links to the unhelpful behaviour you have seen on
mailing lists or IRC ([http://ircbrowse.net/](http://ircbrowse.net/))?

The reason that I ask is that I'm concerned to hear more and more reports of
such behaviour, but I've never seen it on the only Haskell mailing list I read
(haskell-cafe) and I can't remember seeing that kind of thing on Haskell
Reddit either, at least not without a number of helpful replies alongside
unhelpful or dismissive ones. I'd like to see where this sort of behaviour is
arising and see what I can do to improve things.

~~~
ifesdjeen
@tome to be honest, I don't really want to dig and search for these things.
I've had these ones saved in my Evernote, since they were a part of discussion
I've been involved into and considered interesting enough to save.

I'll report if I find something. Also, it'd be good not to do it in public
(even though links are public, I don't want to be associated with a report).

~~~
tome
Feel free to email me:
[http://web.jaguarpaw.co.uk/~tom/contact/](http://web.jaguarpaw.co.uk/~tom/contact/)

------
twelfthnight
Frankly, I think it is a great post and highlights the important fact that a
language itself isn't important, it's the way the language shapes your problem
solving process that matters.

However, what's missing from this article is the interplay of languages on
teams. What makes Python great is that the code won't even run if someone on
the team doesn't use correct white space, forcing teams to write more readable
code. Same goes for Haskell, it forces teams to think in reusable, modular
ways.

~~~
cgag
In the same way, using a lighter changed the way I thought about rubbing
sticks together.

------
mightybyte
From the OP:

> the tools that you're using aren't that important.

If language is not important, then why aren't we writing everything in
assembly language? The fact of the matter is that languages and the
abstractions they facilitate are very important. If we're comparing things
like C vs Java or Clojure vs Haskell, the differences might not be very
obvious, but they're still there. It could be that the types of programs you
wrote didn't highlight the differences. But when we look at more extreme cases
like assembly language, the flaw in the thesis becomes very clear.

The problem here is that it's hard to resist the temptation to over-
generalize. I'm guilty of this myself. We're humans, that's how our brains
work. But sometimes it can lead us to flawed conclusions.

~~~
nostrademons
The "why aren't we writing everything in assembler?" argument always seems to
crop up when somebody posts about the relative merits of programming
languages. And the answer is that _bad_ languages can screw over a project.
But usually when people are debating language choice, it's not Unlambda vs.
Haskell or Brainfuck vs. C++, it's Java vs. C++, Python vs. Ruby, or Haskell
vs. Scala. In that context, language really doesn't matter - the fact that
you're debating it means that there are good arguments on both sides, and
you'll probably do a lot better using whatever language you are most familiar
with than whatever language someone suggests on the Internet.

~~~
imanaccount247
It seems like you missed the fundamental argument being made. First of all,
this:

>And the answer is that bad languages can screw over a project

Proves the "languages don't matter" hypothesis wrong anyways. Second, he very
clearly said that assembly simply shows how big the difference is to most
people because most people are afraid of it. Yes, scala vs haskell the
language does matter. Yes, C++ vs java the language does matter. Even python
vs ruby the language still matters even though they are incredibly similar
languages.

~~~
nostrademons
No, I heard the fundamental argument being made. I'm saying that when you
apply it to most real-world applications, it doesn't matter, just like the
article says. If you are an employee of a tech company, you use whatever
language your employer is using, and you don't get a choice in the matter. If
you are a founder, the only thing that matters is product/market fit, and so
you use whatever language will get you there fastest, which is usually the
language that you know best. If you are a consultant, then either the client
will specify a language (in which case you use that) or you will use whatever
will let you finish the job fastest (which is usually the one you know best).

~~~
imanaccount247
>If you are an employee of a tech company, you use whatever language your
employer is using, and you don't get a choice in the matter

I've been an employee at many tech companies, and I have always had a choice
in the matter. But even if your statement were true, that does not support the
idea that languages don't matter. Prisoners are not given a choice of food,
does that mean choice of food doesn't matter?

You've just repeated your previous red herring. Trying to redirect the focus
away from the subject does not make it "case closed". Nothing about startups
and picking clients has anything to do with the question of whether or not
languages matter.

------
dlwj
Here's what I personally see:

Pencil on Paper vs Vector Pen Tool on Computer. The difference between these
tools doesn't matter. Neither will teach you about the importance of
proportion of characters bodies, or how the illusion of depth can be achieved.

Sure making a curve with a pen tool is very hard, and sometimes a very simple
thing you can do with a pencil will utterly flummox you with the pen tool but
the end result is worth it. The beauty and scalability of the resulting curve
is unparalleled.

[http://www.paulgraham.com/hp.html](http://www.paulgraham.com/hp.html)

"A programming language is for thinking of programs, not for expressing
programs you've already thought of."

------
scrrr
Programming language specialisation is completely overrated. Job listings
should probably rather read "Looking for software developer" than "Looking for
Rails/Python/Clojure/whatever-developer"

A good/experienced developer will pick up any language quickly.

~~~
danieldk
_A good /experienced developer will pick up any language quickly..._

...within the same paradigm. Give a good/experienced developer of imperative
languages Prolog or a pure functional language, and it may take a few months
to get productive.

Also within the same paradigm, there is a difference between learning the
syntax superficially and knowing all common idioms, patterns, and libraries.

~~~
collyw
that's maybe where the "experienced" part comes into his description. Would
you rather have a ten years of Java guy or a three years of Java, 5 years or
Python, and three years of JavaScript. (Ok all of those are imperative, but
Python and JavaScript also have a functional element to them).

------
rokhayakebe
Languages are like raw knowledge.

1) You just do not know what you do not know, hence you cannot know how that
could be beneficial to you.

2) Most of the things you know "do not" benefit you immediately.

3) The more you know, the more opportunities you have to know more and solve
more/better.

------
drostie
Speaking as someone who's done a good bit of Haskell, the type system only
provides a syntax which catches certain classes of errors -- it doesn't catch
them all, and I've only a couple of times been surprised to see "oh, hey, it
worked!" the first run through. (Actually it's probably one-for-one between
Haskell and JS for me, though I guess I've done several times as much work in
JS as in Haskell.)

The type system, for example, does not help you when you have five Ints and
you use the wrong one for an index and the output of the procedure is thereby
completely messed up at runtime. It helps to report a lot of other syntactic
errors, and can be thought of as automatically providing the first half of a
good test suite.

To me the real win of the type system is how it gets you breaking down real-
world problems into actual code.

Programming has inertia. You can choose to either start writing garbage code
until something smells right and then build organically around that smell.
Totally valid. Or, you can sit and philosophize for a while about what
approach you're going to take, build up some lower-level primitives that
you're pretty sure you want, write some high-level overview with stub
functions of what the algorithm does, connect the low-level with the high-
level, and then grow organically around that. Also totally valid. For the
second one, it's really nice to have type signatures. For the first, they get
in the way.

Both approaches for me involve about the same amount of "wasted" time -- this
is what I mean by the problem's "inertia". With the first approach, I do throw
away dead code at a prodigious rate; and I often find out that I've
reimplemented some popular library function which does it faster and better.
With the second approach, I find that I either have to waste time redrawing my
diagrams in Visio to show to a boss (so that they don't think I'm goofing off
just 'cause I'm not typing). But I do like the tradeoff of repetitive-strain-
injury for lots of drawings.

I think most of the mystique of Haskell comes from hackers well-versed in the
first kind running into the type system as a mental roadblock which had to be
overcome, forcing them to learn to plan a bit more, "here is where I/O will
happen, here are the state variables I need to thread through this walk of the
graph", etc. You can get that anywhere.

I really like the syntax for Haskell function-calls, `a f (g 3 + 4)` rather
than `a(f)(g(3) + 4)`. I just want to figure out a way to do tensor indices
alongside it, so that I could write tutorials in mathematical physics with the
same syntax -- something a bit like the Structure and Interpretation of
Classical Mechanics did in Lisp.

~~~
jdiez17
A good type system does not prevent you from making logic errors. It's just
another level of protection, like managed memory. In the same way that
reference counting prevents you from leaking memory, a type system prevents
certain kinds of mistakes that are generally solved with discipline in other
programming languages - for example, in Python, I can construct the following
program:

    
    
        def greater_than(a, b):
            return a > b
    
        if __name__ == '__main__':
            print(greater_than(5, 4))
            print(greater_than([], 4))
    

Which is a perfectly valid program, but throws a runtime error. However, in
Haskell:

    
    
        module Main where
    
        greater_than :: (Ord a) => a -> a -> Bool
        greater_than a b = a > b
    
        main = do
            print $ greater_than 5 4
            print $ greater_than [] 4
    

I have added a constraint that forces the caller to pass a value that can be
compared - and the compiler will throw an error if I don't do that.

Of course this won't get rid of every problem programmers face, but it helps.

~~~
tejon

        greater_than = (>)
    

...sorry. The way you wrote it is better for illustrating your point to non-
Haskellers, it just felt _dirty!_

------
pera
There is a funny typo (spell corrector maybe?): it's "Homotopy" not
"Homeopaty" Type Theory

~~~
ifesdjeen
(author here) was on purpose.

I've tried to built in several subtle jokes)

------
michaelochurch
Disagree x100. Language is important. It does matter.

It matters the least if you're doing a small self-contained project. For small
programs, you can use C or you can use Haskell and it doesn't make that much
of a difference. And, when possible, you should try to write small, modular
programs. I like Clojure better than C in general, but I'd hire a C programmer
who got the Unix philosophy over a Scala or Clojure programmer who carried too
much Java (big-program methodology) baggage.

On large projects or in architectural decisions, it matters a great deal. The
codebase will evolve in a different way if you use Clojure than if you use C.
There isn't an obvious _best_ choice (although I'd tend to favor Haskell
strongly) but it certainly matters for codebase evolution, code quality,
quality of developers, and a host of other factors.

As for Haskell, static typing is very powerful _if you know how to use it_. It
may be oversold (it's not magic pixie dust that prevents bugs) but it _can_ be
used to write very correct, reliable code. That said, to do so is a skill (as
with writing performant code, whether in Haskell or C++) like any other, and
language alone doesn't guarantee much.

~~~
mbesto
Hi. I'm writing an app that allows you to open a web browser and input your
name and your email and saves it to a database. What language should I choose?

~~~
ultramancool
That is the definition of "small, self-contained program". Choose any language
which supports your database libs.

