Live data from Hacker News

Becoming Productive in Haskell

mechanical-elephant.com

51–60 of 213 posts

Re: Becoming Productive in Haskell

#51
post #8

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…

I think you meant "whetting". :)

Re: Becoming Productive in Haskell

#52
post #30

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

A lot of things are supposed to work certain ways but in fact I never really used `Read` for anything more than reading simple user config in scripts. Usually my data is serialized/deserialized from more common formats such as JSON.

Re: Becoming Productive in Haskell

#53
post #23

Whenever 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. :-)

Haskell is a great language for delivering business value. The typed FP paradigm encourages reusable code much more than any other paradigm I have tried.

Re: Becoming Productive in Haskell

#54
post #30

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

More typically, "Show" is whatever you want it to look like in the repl and "Read" doesn't get used. It's still useful for Show to be essentially Haskell syntax though so you can copy and paste into the repl.

Re: Becoming Productive in Haskell

#55

Scripting 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…

I've personally found it very easy to handle "exceptions" in Haskell. Partial answers feel "bad" in Haskell because all the core functionality is clean enough to not need them, but on the other hand that makes for some of the best tools around for dealing with partiality.

Re: Becoming Productive in Haskell

#56
post #49
post #46

Earlier 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…

I think the problem here is terminology. A functor is the abstract concept and it implies having the map operation with the right signature and obeying the right properties.

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

#57
post #49
post #46

Earlier 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…

There's no subset, no garbling; Functor literally has one member, map (fmap in Haskell but that's a historical artefact).

Re: Becoming Productive in Haskell

#58
post #49
post #46

Earlier 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…

[deleted]

Re: Becoming Productive in Haskell

#59

Scripting 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…

I'm not sure what you where trying to do, but there's a whole chord recognition service written in Haskell: http://chordify.net/

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

#60
post #23

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

Haskell allows very "deep" abstraction - but what I find is that you should not overuse it. Abstract where practically useful, otherwise don't go for it. :-)
Post reply on HN