Language is not important(coffeenco.de)
coffeenco.de
Language is not important
http://coffeenco.de/articles/language_is_not_important.html
63 comments
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.
> How hearing it in the original pronunciation brought out the puns and rhymes.
These happen accidentally sometimes.
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.'
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.
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".
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".
Languages, and even syntaxes, do matter. In a lot of ways and not all of them are immediately obvious.
Personally I went from "languages matter" to opposite and back again during the years.
At the beginning I used C and then I started learning C++. At that point I had some experience with Pascal and BASIC and by comparison C++ looked like the undisputed winner. At this time I assumed that "languages matter" (or rather "C++ matters", but close enough).
In the following years I learned a couple more languages. Ada, PHP, Python, Java. This is where I started believing that languages don't matter - they of course differ from one another, but the differences are minimal.
But I didn't stop there. I started learning more and more languages, some really, really different. I first learned OCaml, then Erlang, then Prolog, then Scheme. Then more than a dozen of other languages, including Clean, Smalltalk, J, Forth and other such "esoteric" ones. I don't remember exactly when it happened, but somewhere along the road I realized, again, that languages do matter.
There are two parts to this realization actually. One is that I started doing programming professionally - this caused me to interact with other programmers, to read their code, to explain things to them. I realized that language design has to accommodate large variety of people's habits, projects and circumstances and that not everything is completely rational when it comes to language usage "in the wild". That language design has non-trivial impact on language community (and language syntax on idioms/best practices) and that community matters very, very much.
And the second part was that, as mentioned, I finally learned some languages which really were different. There are many notable differences between Pascal and C, for example, but they are not that great. On the other hand C, Smalltalk and J don't have almost anything in common and they all have specific niche where using one of them is clearly a win.
In the end I concluded what I said at the beginning of this comment: that languages do matter and in many different ways at that. Some make thinking about certain problems easier, some make writing certain kind of software easier, some make learning particular concepts easier and some make earning money easier. Some differ more, some less, but - outside of purely theoretical discussions - you can't pretend that they don't. Or that the differences are negligible.
Personally I went from "languages matter" to opposite and back again during the years.
At the beginning I used C and then I started learning C++. At that point I had some experience with Pascal and BASIC and by comparison C++ looked like the undisputed winner. At this time I assumed that "languages matter" (or rather "C++ matters", but close enough).
In the following years I learned a couple more languages. Ada, PHP, Python, Java. This is where I started believing that languages don't matter - they of course differ from one another, but the differences are minimal.
But I didn't stop there. I started learning more and more languages, some really, really different. I first learned OCaml, then Erlang, then Prolog, then Scheme. Then more than a dozen of other languages, including Clean, Smalltalk, J, Forth and other such "esoteric" ones. I don't remember exactly when it happened, but somewhere along the road I realized, again, that languages do matter.
There are two parts to this realization actually. One is that I started doing programming professionally - this caused me to interact with other programmers, to read their code, to explain things to them. I realized that language design has to accommodate large variety of people's habits, projects and circumstances and that not everything is completely rational when it comes to language usage "in the wild". That language design has non-trivial impact on language community (and language syntax on idioms/best practices) and that community matters very, very much.
And the second part was that, as mentioned, I finally learned some languages which really were different. There are many notable differences between Pascal and C, for example, but they are not that great. On the other hand C, Smalltalk and J don't have almost anything in common and they all have specific niche where using one of them is clearly a win.
In the end I concluded what I said at the beginning of this comment: that languages do matter and in many different ways at that. Some make thinking about certain problems easier, some make writing certain kind of software easier, some make learning particular concepts easier and some make earning money easier. Some differ more, some less, but - outside of purely theoretical discussions - you can't pretend that they don't. Or that the differences are negligible.
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.
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.
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..."
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.
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.
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.
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.
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.
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.
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.
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.
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 [2]: https://github.com/bitemyapp/learnhaskell
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 [2]: https://github.com/bitemyapp/learnhaskell
The author of the post refused to avail himself of other peoples' help
ifesdjeen: i don't want anyone to fix my problems)
bitemyapp: I don't give a fuck what you want.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
x: just write a function of that type for fmap
x: thats YOUR problem now isnt it
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...
Would you mind posting links to the unhelpful behaviour you have seen on mailing lists or IRC (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.
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.
@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).
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).
Feel free to email me: http://web.jaguarpaw.co.uk/~tom/contact/
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.
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.
I spent a little time with Haskell and gave up because progress was slow. Later I picked up Ocaml and found many of the concepts to be similar but had a much easier time making progress. Having used Ocaml to familiarize myself with strongly typed FP, I think it wouldn't be so hard now to go back to Haskell and have more success.
If you decide to give it a try, I highly recommend Real World Ocaml [1] as a starting point, especially the installation instructions that help you get up and running with a sane toolchain right away [2].
[1]: http://realworldocaml.org/ [2]: https://github.com/realworldocaml/book/wiki/Installation-Ins...
If you decide to give it a try, I highly recommend Real World Ocaml [1] as a starting point, especially the installation instructions that help you get up and running with a sane toolchain right away [2].
[1]: http://realworldocaml.org/ [2]: https://github.com/realworldocaml/book/wiki/Installation-Ins...
This sounds great. I've starting looking at the CIS 194 lectures, though, and so far not a single example works in ghci. Googling around indicates that you need to use 'let' or define things in a module and load them . . .
Is this tutorial already out of date?
Is this tutorial already out of date?
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".
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.
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.
In the same way, using a lighter changed the way I thought about rubbing sticks together.
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.
> 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.
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.
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.
>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.
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).
>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.
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.
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.
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.)
(I say this as someone who wrote one of the top Haskell tutorials on the net, and am currently using Python for my startup.)
Precisely what problem domains are Python and Ruby adapted for that Haskell and Rust are not?
Which tutorial? So far I've only done Learn You and some exercism.io stuff.
Write Yourself a Scheme in 48 Hours
http://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_H...
http://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_H...
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
"A programming language is for thinking of programs, not for expressing programs you've already thought of."
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
"A programming language is for thinking of programs, not for expressing programs you've already thought of."
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.
A good/experienced developer will pick up any language quickly.
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.
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.
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.
...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.
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).
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?
yeah I just meant that good devs can use any language, not that any language is good for any problem. It obviously isn't. :)
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.
Do at least K&R not feel this way?
That discussion above does not really apply to C++. But then, if you lower the bar to how much C++ is widely known (the intersection, not union), it'll apply.
That discussion above does not really apply to C++. But then, if you lower the bar to how much C++ is widely known (the intersection, not union), it'll apply.
On the one hand, R (http://www.cs.bell-labs.com/who/dmr/index.html) is sadly gone. However, this might be interesting to your question:
From http://www.lysator.liu.se/c/duffs-device.html:
"Somewhere I have a note from dmr [the R in K&R] certifying that all the compilers that he believes in accept it."
So at least at some point Duff showed Ritchie something in C that Ritchie hadn't seen or considered before, long after C had been invented.
From http://www.lysator.liu.se/c/duffs-device.html:
"Somewhere I have a note from dmr [the R in K&R] certifying that all the compilers that he believes in accept it."
So at least at some point Duff showed Ritchie something in C that Ritchie hadn't seen or considered before, long after C had been invented.
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.
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.
[deleted]
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.
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.
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:
Of course this won't get rid of every problem programmers face, but it helps.
def greater_than(a, b):
return a > b
if __name__ == '__main__':
print(greater_than(5, 4))
print(greater_than([], 4))
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
Of course this won't get rid of every problem programmers face, but it helps.
greater_than = (>)
>the type system only provides a syntax which catches certain classes of errors
Yes, type errors. The problem is you have a drastically limited idea of what a type error is.
>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.
Yes it does, you are choosing not to use the type system. If they are not five Ints but five specific things, then you should have five types, not one.
Yes, type errors. The problem is you have a drastically limited idea of what a type error is.
>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.
Yes it does, you are choosing not to use the type system. If they are not five Ints but five specific things, then you should have five types, not one.
I'm not sure what you mean by a "specific thing." Take the absolute simplest case, Fibonaccis. You accidentally write somewhere:
You get similar problems if you were looking for the max of two mins of two lists of Ints and you accidentally wrote the min of the two mins, or if you have two functions
Ultimately you're responding to a claim which says that there exist semantic errors, by saying that no, that's "a drastically limited idea" of what syntax can do, and results from people "choosing not to use the type system". That's a bit baffling to me. Could you clarify, so that I could see how I can eliminate these sorts of semantic errors entirely?
fibs n
| n <= 1 = n
| otherwise = fibs n + fibs (n - 1)
You get similar problems if you were looking for the max of two mins of two lists of Ints and you accidentally wrote the min of the two mins, or if you have two functions
findMinBefore :: (Ord x) => Array Int x -> Int -> x
findMinAfter :: (Ord x) => Array Int x -> Int -> x
Ultimately you're responding to a claim which says that there exist semantic errors, by saying that no, that's "a drastically limited idea" of what syntax can do, and results from people "choosing not to use the type system". That's a bit baffling to me. Could you clarify, so that I could see how I can eliminate these sorts of semantic errors entirely?
>Ultimately you're responding to a claim which says that there exist semantic errors, by saying that no, that's "a drastically limited idea" of what syntax can do
No I am not. I am responding to what you said, not what you want to invent after the fact. It is very simple, and is the difference between these two functions:
No I am not. I am responding to what you said, not what you want to invent after the fact. It is very simple, and is the difference between these two functions:
f :: Int -> Int -> Int -> Int -> Int -> Int
f :: Type1 -> Type2 -> Type3 -> Type4 -> Type5 -> Type6Well, let me encourage you to actually respond to what I said, then:
> you have five Ints and you use the wrong one for an index
In other words:
It sounds like your panacea here is to instead have the programmer write:
Are you saying that `f` should not have input type `Int`? That input type is isomorphically non-negotiable: you're either going to write five `f` functions or you're going to have type coercions, and both ways have the problem. I really don't see anything you've said which alleviates it.
If none of what I was saying was what you thought I was saying, that's OK, mistakes happen all the time. Then, I'd just ask: in your own words, what did you think I was saying when I said, "you have five Ints and you use the wrong one for an index"?
> you have five Ints and you use the wrong one for an index
In other words:
f :: Int -> Foo
doStuff :: Int -> Int -> Int -> Int -> Int -> Foo
doStuff lo hi (p - 1) p (p + 1)
It sounds like your panacea here is to instead have the programmer write:
doStuff' :: Lo -> Hi -> Pminus -> Pivot -> Pplus -> Foo
Are you saying that `f` should not have input type `Int`? That input type is isomorphically non-negotiable: you're either going to write five `f` functions or you're going to have type coercions, and both ways have the problem. I really don't see anything you've said which alleviates it.
If none of what I was saying was what you thought I was saying, that's OK, mistakes happen all the time. Then, I'd just ask: in your own words, what did you think I was saying when I said, "you have five Ints and you use the wrong one for an index"?
If you didn't want to learn and were just posting FUD, then save everyone the time and say that after the first post. No need to act ignorant and try to drag things out in to some endless charade of pretending you don't understand so you can salvage your FUD.
I would like to learn if there is something here to teach but after giving you several opportunities to explain yourself and only getting vague short comments, I'm not sure that I believe you have anything to teach.
I don't have any desire to post FUD about Haskell. I like Haskell and it's probably my favorite language at the moment. What I posted was not FUD and these replies are not "salvaging" FUD.
So, again: in your own words, what did you think I was saying?
I don't have any desire to post FUD about Haskell. I like Haskell and it's probably my favorite language at the moment. What I posted was not FUD and these replies are not "salvaging" FUD.
So, again: in your own words, what did you think I was saying?
> 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.
You could use newtype.
You could use newtype.
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.
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.
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.
If you inherit a Java program, you can't just use C++ to work on it. You will have to edit Java source code.
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?
That is the definition of "small, self-contained program". Choose any language which supports your database libs.
"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.