Great article. I do think a better "Getting started with Haskell" guide is Chris Allen's: https://github.com/bitemyapp/learnhaskell OP's article is still a great way of wetting appetite, and sharing insights; but moving on from there is better facilitated by Chris Allen's recommendations. There is also the IDE issue; FPComplete has a web-based IDE that is good for beginners, and it is possible to setup Emacs to be a…
Becoming Productive in Haskell
51–60 of 213 posts
Re: Becoming Productive in Haskell
#52Scripting languages try to seduce you to just fiddle around until the output looks like something you want. While that quickly gives you some results, I think it's a huge roadblock in the mid- to longterm. Especially when programmers are only familiar with "easy" scripting languages, there are rarely insights about the general approach to the problem until the project already grew to become an abomination. While fidd…
IIRC, the Show class is supposed to be the reverse of the Read class -- so you should not use it to pretty print stuff.
Re: Becoming Productive in Haskell
#53Whenever I try to be productive in Haskell I end up taking the research phase too far and end up over-my-head in category theory that I don't understand. I'm never productive in Haskell.
You might not be productive in the traditional sense of "delivering business value". However over the years of letting Haskell change my brain a little piece at a time, the results have accumulated. I wouldn't swap that deeper understanding for all the productivity in the world. :-)
Re: Becoming Productive in Haskell
#54Scripting languages try to seduce you to just fiddle around until the output looks like something you want. While that quickly gives you some results, I think it's a huge roadblock in the mid- to longterm. Especially when programmers are only familiar with "easy" scripting languages, there are rarely insights about the general approach to the problem until the project already grew to become an abomination. While fidd…
IIRC, the Show class is supposed to be the reverse of the Read class -- so you should not use it to pretty print stuff.
Re: Becoming Productive in Haskell
#55Scripting languages try to seduce you to just fiddle around until the output looks like something you want. While that quickly gives you some results, I think it's a huge roadblock in the mid- to longterm. Especially when programmers are only familiar with "easy" scripting languages, there are rarely insights about the general approach to the problem until the project already grew to become an abomination. While fidd…
And what makes the model of haskell any more superior to models developed in any other field like accounting, physics or chemistry ? I am sorry, haskell is just a huge roadblock to get things done in the real world. In the real world proffesional need to juggle all sorts of models. Haskell just says "Fcuk you ! its my way or the gonadway !". I need to juggle between json, matrix, html, etc. Each of them have hundreds…
Re: Becoming Productive in Haskell
#56Earlier quoted context omitted.
That Either is Mappable is, IMO, both clearer and more informative than that it's a Functor.
Maybe someone can correct me here, but that kind of approach seems ill-founded to me when after a couple examples, people are already talking about different things using the same terminology. The article says "A list is a Functor". Now you're saying "Either is a Functor". But those two things don't have the same nature. Maybe what the author meant "The [] list constructor is a Functor"? I'm not sure what is gained b…
The best way to say it is "The list type 'forms' a functor" or "The Either type 'forms' a functor". The fact that they form a functor implies that their map operation has a fixed set of properties, and these properties are independent of what exactly the data structure does and how it works.
Re: Becoming Productive in Haskell
#57Earlier quoted context omitted.
That Either is Mappable is, IMO, both clearer and more informative than that it's a Functor.
Maybe someone can correct me here, but that kind of approach seems ill-founded to me when after a couple examples, people are already talking about different things using the same terminology. The article says "A list is a Functor". Now you're saying "Either is a Functor". But those two things don't have the same nature. Maybe what the author meant "The [] list constructor is a Functor"? I'm not sure what is gained b…
Re: Becoming Productive in Haskell
#58Earlier quoted context omitted.
That Either is Mappable is, IMO, both clearer and more informative than that it's a Functor.
Maybe someone can correct me here, but that kind of approach seems ill-founded to me when after a couple examples, people are already talking about different things using the same terminology. The article says "A list is a Functor". Now you're saying "Either is a Functor". But those two things don't have the same nature. Maybe what the author meant "The [] list constructor is a Functor"? I'm not sure what is gained b…
Re: Becoming Productive in Haskell
#59Scripting languages try to seduce you to just fiddle around until the output looks like something you want. While that quickly gives you some results, I think it's a huge roadblock in the mid- to longterm. Especially when programmers are only familiar with "easy" scripting languages, there are rarely insights about the general approach to the problem until the project already grew to become an abomination. While fidd…
And what makes the model of haskell any more superior to models developed in any other field like accounting, physics or chemistry ? I am sorry, haskell is just a huge roadblock to get things done in the real world. In the real world proffesional need to juggle all sorts of models. Haskell just says "Fcuk you ! its my way or the gonadway !". I need to juggle between json, matrix, html, etc. Each of them have hundreds…
Apart from that, I have written many production grade Haskell application, and I can not agree with you that Haskell is getting in the way. I admit that when learning Haskell I sometimes had that feeling too, but basically that was just me thinking about the problem too complicated or in a wrong perspective. Now that I am past that point Haskell is super fun to write, very productive and results in extremely maintainable code - it is just so easy to refactor anything you can imagine - and when it compiles again you are probably good to go!
Re: Becoming Productive in Haskell
#60Whenever I try to be productive in Haskell I end up taking the research phase too far and end up over-my-head in category theory that I don't understand. I'm never productive in Haskell.