10 ms·

Language is not important

82 points by r4um 12y ago

protomyth 12y ago
I read a story in the Telegraph http://www.telegraph.co.uk/culture/theatre/william-shakespeare/10372964/Shakespeare-read-in-Elizabethan-accent-reveals-puns-jokes-and-rhymes.html http://www.telegraph.co.uk/culture/theatre/william-shakespea... 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 12y ago
  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 12y ago
    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 12y ago
      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.
scrrr 12y ago
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.
- astrobe_ 12y ago
  Quickly? Perhaps. But being productive is a whole different story. You may pick Scheme or Forth in maybe half a day; but being productive with them implies knowing their common idioms, their standard libraries by heart and their ecosystem well. That's the meaning of the "Looking for ..." job offers.
- volker48 12y ago
  This is true, but certain languages are better at tackling certain problems e.g. I wouldn't recommend trying to write a multi-threaded application in PHP. I could build a house by hammering in all the nails with the back of a screw driver, but why would I want to do that?
  - scrrr 12y ago
    yeah I just meant that good devs can use any language, not that any language is good for any problem. It obviously isn't. :)
- lostcolony 12y ago
  To a point. I've noticed in functional language jobs the specific language is less meaningful. While it may be Clojure, it will often have a requirement of "experience in functional languages" rather than explicitly Clojure. I think that's a combination of fewer developers to choose from, smaller companies (so a technical person reviewing it rather than HR), and the recognition that the major difficulty to getting productive is that first paradigm shift, after which it's evolutionary rather than revolutionary.
- EliRivers 12y ago
  How quickly is "quickly"? I've been coding in C++ for years and I still find new ways of doing things and new idioms to consider.
drostie 12y ago
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.
- Dewie 12y ago
deleted 12y ago
[deleted]
pera 12y ago
There is a funny typo (spell corrector maybe?): it's "Homotopy" not "Homeopaty" Type Theory
- ifesdjeen 12y ago
  (author here) was on purpose. I've tried to built in several subtle jokes)
rokhayakebe 12y ago
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.
lostcolony 12y ago
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".
- drcomputer 12y ago
  There is often the desire to formalize all concepts under a single, over-arching, unifying language, of which everyone learns from and adds their discoveries to, and it is perfect in clarity, unchanging in form, and eternal in elegance. But I think that desire often stems from the fact that learning stuff is hard. It doesn't matter what you are learning, if it is foreign enough to your brain, then it's hard. It makes everything seem in vain, that there is always more to do. But, everything is interesting, because there is always more to do. Also, creativity. We don't have to be dictators or communists over our programming languages. We can be artists, scientists, mathematicians, and poets.
rdtsc 12y ago
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.
twelfthnight 12y ago
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 12y ago
  In the same way, using a lighter changed the way I thought about rubbing sticks together.
michaelochurch 12y ago
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 12y ago
  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 12y ago
    That is the definition of "small, self-contained program". Choose any language which supports your database libs.
  - vegedor 12y ago
    Use English to specify your problem, before you turn anything into code or ask anyone for input on the solution. As you need to write javascript for the page directly, why not use nodejs or use local-storage at the client. Depends on what you want to achieve, really, the question is vague.
- wtetzner 12y ago
  I completely agree. One really annoying thing I hear quite often is that a language is just a tool. But that's wrong. The language is the building material. The language isn't the hammer, it's the wood, and it's the nails. If you inherit a Java program, you can't just use C++ to work on it. You will have to edit Java source code.
mightybyte 12y ago
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 12y ago
  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.
  - cgag 12y ago
    Sure, debates between two extremely similar languages aren't important, but it's not like the people arguing between Python and Ruby couldn't include Haskell or Rust in that debate, and the difference between those is huge.
    - nostrademons 12y ago
      Haskell and Rust are adapted for very different problem domains than Python and Ruby. The reason someone choosing between Python and Ruby doesn't include Haskell and Rust is because Haskell and Rust would be very bad choices for the types of software that are typically built with Python and Ruby. (I say this as someone who wrote one of the top Haskell tutorials on the net, and am currently using Python for my startup.)
sramsay 12y ago
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.
- mightybyte 12y ago
  The time it takes for people to learn Haskell varies greatly from person to person. Your experience might be different from that of the OP. But no matter how long it takes you, I think you'll get vastly more than a "small slice of cake".
- jdiez17 12y ago
  In my experience (OP's post resonates highly with me, I've also been dabbling in Haskell for a while and consider myself somewhat competent), it's a long term investment. I've been at it on and off for a while and even though I haven't done anything "useful" with it (except Uni coursework, which I convinced my teachers to mark in Haskell), I feel like I've grown a lot as a programmer thanks to it. Understanding concepts functors, applicatives, monads, lenses etc is a reward in itself, at least to me. Sometimes I write small toy programs, like a sudoku solver, which lets me get a glimpse of the true power of languages like Haskell. But at the end of the day, I agree with the general intent of your message (and OP's post) - different programming paradigms change the way you think about programming, and generally makes you a better programmer.
- nostrademons 12y ago
  You profit from learning Haskell in a way other than "I get to use Haskell to build cool things". Rather, it changes how you think about programming in other languages. If you work in Java, you'll find that you'll create a lot more immutable objects after learning Haskell, and you'll understand Java 8 streams a lot better. If you work in C++, you'll grok concepts, traits, and the STL a lot better after working with typiclasses. If you work in Go, you'll grok interfaces and use them extensively. If you work in Python, you'll depend much more heavily on list comprehensions and inner functions than on mutating objects. In most statically-typed languages, you start using Optional<T> instead of nulls, or at least a NullObject pattern. You also learn how to use the type system to tag values and prevent misuse, whereas before you might've just used Strings everywhere. This is particularly handy in C++, where the overhead of defining a new type around a single primitive is zero. I've found that helpful even though I never got to write Haskell for money and rarely write it at all now, it's changed how I program in a way that takes out a lot of the constructs that previously caused a lot of bugs & handwringing. A lot of the benefits of Haskell, you can achieve in other languages through disciplined programming.
dlwj 12y ago
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."

82 points by r4um 12y ago

I read a story in the Telegraph http://www.telegraph.co.uk/culture/theatre/william-shakespeare/10372964/Shakespeare-read-in-Elizabethan-accent-reveals-puns-jokes-and-rhymes.html http://www.telegraph.co.uk/culture/theatre/william-shakespea... 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 12y ago
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 12y ago
  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 12y ago
    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.

scrrr 12y ago

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.

astrobe_ 12y ago
Quickly? Perhaps. But being productive is a whole different story. You may pick Scheme or Forth in maybe half a day; but being productive with them implies knowing their common idioms, their standard libraries by heart and their ecosystem well. That's the meaning of the "Looking for ..." job offers.
volker48 12y ago
This is true, but certain languages are better at tackling certain problems e.g. I wouldn't recommend trying to write a multi-threaded application in PHP. I could build a house by hammering in all the nails with the back of a screw driver, but why would I want to do that?
- scrrr 12y ago
  yeah I just meant that good devs can use any language, not that any language is good for any problem. It obviously isn't. :)
lostcolony 12y ago
To a point. I've noticed in functional language jobs the specific language is less meaningful. While it may be Clojure, it will often have a requirement of "experience in functional languages" rather than explicitly Clojure. I think that's a combination of fewer developers to choose from, smaller companies (so a technical person reviewing it rather than HR), and the recognition that the major difficulty to getting productive is that first paradigm shift, after which it's evolutionary rather than revolutionary.
EliRivers 12y ago
How quickly is "quickly"? I've been coding in C++ for years and I still find new ways of doing things and new idioms to consider.

drostie 12y ago

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.

Dewie 12y ago

deleted 12y ago

[deleted]

pera 12y ago

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

ifesdjeen 12y ago
(author here) was on purpose. I've tried to built in several subtle jokes)

rokhayakebe 12y ago

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.

lostcolony 12y ago

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".

drcomputer 12y ago
There is often the desire to formalize all concepts under a single, over-arching, unifying language, of which everyone learns from and adds their discoveries to, and it is perfect in clarity, unchanging in form, and eternal in elegance. But I think that desire often stems from the fact that learning stuff is hard. It doesn't matter what you are learning, if it is foreign enough to your brain, then it's hard. It makes everything seem in vain, that there is always more to do. But, everything is interesting, because there is always more to do. Also, creativity. We don't have to be dictators or communists over our programming languages. We can be artists, scientists, mathematicians, and poets.

rdtsc 12y ago

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.

twelfthnight 12y ago

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 12y ago
In the same way, using a lighter changed the way I thought about rubbing sticks together.

michaelochurch 12y ago

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 12y ago
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 12y ago
  That is the definition of "small, self-contained program". Choose any language which supports your database libs.
- vegedor 12y ago
  Use English to specify your problem, before you turn anything into code or ask anyone for input on the solution. As you need to write javascript for the page directly, why not use nodejs or use local-storage at the client. Depends on what you want to achieve, really, the question is vague.
wtetzner 12y ago
I completely agree. One really annoying thing I hear quite often is that a language is just a tool. But that's wrong. The language is the building material. The language isn't the hammer, it's the wood, and it's the nails. If you inherit a Java program, you can't just use C++ to work on it. You will have to edit Java source code.

mightybyte 12y ago

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 12y ago
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.
- cgag 12y ago
  Sure, debates between two extremely similar languages aren't important, but it's not like the people arguing between Python and Ruby couldn't include Haskell or Rust in that debate, and the difference between those is huge.
  - nostrademons 12y ago
    Haskell and Rust are adapted for very different problem domains than Python and Ruby. The reason someone choosing between Python and Ruby doesn't include Haskell and Rust is because Haskell and Rust would be very bad choices for the types of software that are typically built with Python and Ruby. (I say this as someone who wrote one of the top Haskell tutorials on the net, and am currently using Python for my startup.)

sramsay 12y ago

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.

mightybyte 12y ago
The time it takes for people to learn Haskell varies greatly from person to person. Your experience might be different from that of the OP. But no matter how long it takes you, I think you'll get vastly more than a "small slice of cake".
jdiez17 12y ago
In my experience (OP's post resonates highly with me, I've also been dabbling in Haskell for a while and consider myself somewhat competent), it's a long term investment. I've been at it on and off for a while and even though I haven't done anything "useful" with it (except Uni coursework, which I convinced my teachers to mark in Haskell), I feel like I've grown a lot as a programmer thanks to it. Understanding concepts functors, applicatives, monads, lenses etc is a reward in itself, at least to me. Sometimes I write small toy programs, like a sudoku solver, which lets me get a glimpse of the true power of languages like Haskell. But at the end of the day, I agree with the general intent of your message (and OP's post) - different programming paradigms change the way you think about programming, and generally makes you a better programmer.
nostrademons 12y ago
You profit from learning Haskell in a way other than "I get to use Haskell to build cool things". Rather, it changes how you think about programming in other languages. If you work in Java, you'll find that you'll create a lot more immutable objects after learning Haskell, and you'll understand Java 8 streams a lot better. If you work in C++, you'll grok concepts, traits, and the STL a lot better after working with typiclasses. If you work in Go, you'll grok interfaces and use them extensively. If you work in Python, you'll depend much more heavily on list comprehensions and inner functions than on mutating objects. In most statically-typed languages, you start using Optional<T> instead of nulls, or at least a NullObject pattern. You also learn how to use the type system to tag values and prevent misuse, whereas before you might've just used Strings everywhere. This is particularly handy in C++, where the overhead of defining a new type around a single primitive is zero. I've found that helpful even though I never got to write Haskell for money and rarely write it at all now, it's changed how I program in a way that takes out a lot of the constructs that previously caused a lot of bugs & handwringing. A lot of the benefits of Haskell, you can achieve in other languages through disciplined programming.

dlwj 12y ago

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."