Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Becoming Productive in Haskell

mechanical-elephant.com

Post reply on HN
Print view View original

61–70 of 213 posts

Re: Becoming Productive in Haskell

#61

Post by boothead »

glutamate wrote: post #53
boothead wrote: post #29

Earlier quoted context omitted.

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.

Yes, absolutely agree with you. I wish I was writing Haskell day to day.

My point was that it takes a long trivial amount of time to learn Haskell during which you might feel "unproductive" by that measure. I feel that it's during that period that the magic happens :-)

Re: Becoming Productive in Haskell

#62

Post by boothead »

1971genocide wrote: post #34
QuantumRoar wrote: post #25

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…

> Apparently the models developed by 1000s years of music theory is not good enough for haskell

Perhaps not, but Haskell is good enough for them:

  Functional Generation of Harmony and Melody http://dreixel.net/research/pdf/fghm.pdf

Re: Becoming Productive in Haskell

#63

Post by pjmlp »

julian_perrott wrote: post #5

Nice article, i've been learning Haskell for about a month solving kata on http://www.codeswars.com/ using https://www.fpcomplete.com/ as my IDE. I'm finding it quite a learning curve understanding what library functions there are and how to use them. The code I write often ends up being quite different to the other solutions on codewars. I'm missing Visual Studio, are there any realy good Haskell IDEs out there? for…

I have used Leksah and EclipseFP a few times, they are ok. I don't remember how good they are debugging code.

http://leksah.org/

http://eclipsefp.github.io/

Re: Becoming Productive in Haskell

#64

Post by DanWaterworth »

lmm wrote: post #4

> So, I started calling it Mappable. Mappable was easy for me to remember and was descriptive of what it did. A list is a Functor. A list is Mappable. I wish there was a language or library that was willing to take the Haskell functionality and just give it all names like this.

This is actually possible with the ConstraintKinds extension in GHC.

    type Mappable = Functor
    type NotScaryFluffyThing = Monad
This makes Mappable a synonym for Functor and likewise for Monad. (This is not necessarily a good idea; it goes against the principle of least surprise, but it'll work).

Re: Becoming Productive in Haskell

#65

Post by LukeHoersten »

I've been programming Haskell for quite a while now and find that many of these types of articles don't capture what I really value in the language. The author really captured what I love about Haskell excellently! It's super terse, (really) readable, and the barriers to entry people worry about are more in their minds than in reality. It's a great language and a great article!

Re: Becoming Productive in Haskell

#66

Post by tormeh »

lmm wrote: post #4

> So, I started calling it Mappable. Mappable was easy for me to remember and was descriptive of what it did. A list is a Functor. A list is Mappable. I wish there was a language or library that was willing to take the Haskell functionality and just give it all names like this.

In Scala there aren't any names for functors that I'm aware of. I just though one day that "wouldn't it be practical if I could map an option instead of match-casing the meaning out?" and lo and behold it worked. Maybe we just don't need that much terminology.

Re: Becoming Productive in Haskell

#67

Post by tormeh »

punee wrote: post #49
lmm wrote: 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…

Scala programmer here.

  class Container(val property:Int)

  val list:List[Container]
  val mappedlist:List[Int] = list.map(x=>x.property)

  val option:Option[Container]
  val mappedOption:Option[Int] = option.map(x=>x.property)
It works in exactly the same way...

Re: Becoming Productive in Haskell

#68

Post by BasDirks »

1971genocide wrote: post #34
QuantumRoar wrote: post #25

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…

And what makes the model of haskell any more superior to models developed in any other field like accounting, physics or chemistry ?

- Type-safety. Correctness. Speed.

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 don't know what this even means.

I need to juggle between json, matrix, html, etc. Each of them have hundreds of expections.

- Haskell has great libraries for each of these.

You can say my model is imperfect but guess what buddy, every model is. The only models that will work for all cases is prolly einstein's equations but even that has exceptions when dealing with blackholes !

- models?

I tried writing a music library in haskell and haskell makes it really hard to create rules that are expections to the model. Apparently the models developed by 1000s years of music theory is not good enough for haskell !

- It just doesn't let you do it incorrectly.

I cannot even image what it must to be code chemical rules using hakell that have hundreds of expections, or biologial models ! Oh My !

- The more complex, the better Haskell is suited.

I am sorry haskell just gets makes computation much more difficult. Apparently mutation is a crime even though god himself thought it was okay as a rule for everything in the universe.

- Immutability doesn't make computation harder.

my anecdotal experience.

((

btw i really like the concepts in haskell. I read two of its famous books - LYAGH and RWH. And use all haskell concepts almost daily in production. However the implementation of haskell is not really ready for production or useful enough for the average developer. Its also not easy for the average developer to put food on the table using haskell

- You say you like these concepts, but it doesn't sound like you have the slightest idea what those concepts are useful for.

Re: Becoming Productive in Haskell

#69

Post by steveklabnik »

1971genocide wrote: post #34
QuantumRoar wrote: post #25

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…

> Haskell just says "Fcuk you ! its my way or the gonadway !".

I think it's more accurate to say that Haskell makes you annotate specifically which way you're doing it, and only combine ways when it's okay to do so.

Re: Becoming Productive in Haskell

#70

Post by imakesnowflakes »

QuantumRoar wrote: post #25

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…

>While fiddling around is still somewhat possible in Haskell, the language itself makes it quite difficult. Haskell kind of forces you right at the beginning to pause and think "Well, what is it that I'm actually trying to do here?"...

Wouldn't Scripting languages allows one to gradually build that understanding. Suppose you end up with a lot of complex code? Ditch it and build it from scratch. Usually takes around 1/10th the time it took first time with much better results.

So I think by the time one can think up and build the perfect abstractions in Haskell, one can write 3 or 4 iterations of the program in a dynamic language. Each time with better abstractions and neater organization....

Post reply on HN