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

181–190 of 213 posts

Re: Becoming Productive in Haskell

#181

Post by bsummer4 »

windlep wrote: post #177
bsummer4 wrote: post #110

Earlier quoted context omitted.

Could you name some of these libraries? IME, most of the libraries that are needed for common things are very mature.

I tried to write a Haskell websocket server, the library is quite nice, but it leaked memory (space leak? fragmentation? some of both?): https://github.com/jaspervdj/websockets/issues/72 The author helped me narrow it down to some issues with how ghc by default allocates a stack space that is rarely enough, and once it starts growing the stack space the RAM per connection gets pretty ridiculous. Using higher default…

Thank you! This is a really good comment.

Also, your bug reports are really solid.

Re: Becoming Productive in Haskell

#182

Post by semigroupoid »

munro wrote: post #162
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…

Ability to fiddle isn't tied to static or dynamic programming, it's just every static language platform I've seen including The Haskell Platform neglects making it easier to fiddle. When trying to build complex software in Haskell, I find myself spending a lot of time commenting/uncommenting swaths of code, just so I can get part of a algorithm to load in GHCi. It sucks. What I wish would happen is GHCi allowed me to…

Of course compiling successfully does not imply a correct program with the desired behavior. Nobody claims that GHC is able to verify the behavioral correctness of your program and it also can't tell you if your function actually sorts a list or if it does not. However, if you claim in your definition of "sort" that it takes a list and returns a list, then GHC can verify if that is actually true. That is the power of types. They are no magic things that write correct programs for you.

Re: Becoming Productive in Haskell

#183

Post by semigroupoid »

AnimalMuppet wrote: post #149
sordina wrote: post #43

Earlier quoted context omitted.

> sometimes completely at odds with the way other languages use them: e.g. C++ also has functors, and they're completely unrelated to Haskell functors. Really, this should be considered as C++ perverting the existing terminology from category-theory for Functors. > I really like the author's suggestion of mentally translating Functor to Mappable. Are there any other synonyms for other Haskell terms of art? I think th…

> > sometimes completely at odds with the way other languages use them: e.g. C++ also has functors, and they're completely unrelated to Haskell functors. > Really, this should be considered as C++ perverting the existing terminology from category-theory for Functors. Only if you assume that category theory is the correct source of meaning of such terminology. But Wikipedia, for example, lists functor as being ambiguo…

The definition of functor in category theory is from 1945 while most of today's mainstream programming languages are much younger than that. The people who wrote those definitions for C++, C#... simply ignored the existing terminology.

Re: Becoming Productive in Haskell

#184

Post by AnimalMuppet »

semigroupoid wrote: post #183
AnimalMuppet wrote: post #149

Earlier quoted context omitted.

> > sometimes completely at odds with the way other languages use them: e.g. C++ also has functors, and they're completely unrelated to Haskell functors. > Really, this should be considered as C++ perverting the existing terminology from category-theory for Functors. Only if you assume that category theory is the correct source of meaning of such terminology. But Wikipedia, for example, lists functor as being ambiguo…

The definition of functor in category theory is from 1945 while most of today's mainstream programming languages are much younger than that. The people who wrote those definitions for C++, C#... simply ignored the existing terminology.

Fair enough. And yet, at the time (and even today, outside of the FP crowd), category theory is really far outside the scope of what most people consider programming, so it's hard to blame them for not looking there for terms.

For that matter, category theory borrowed the word from linguistics, and most definitely did not keep the same meaning.

Re: Becoming Productive in Haskell

#185

Post by windlep »

marcosdumay wrote: post #119
windlep wrote: post #101

I really like Haskell, but one of the main problems I've had (that I don't see many people cite) is that the libraries just aren't made for use under serious load/concurrency. Many of the people that have written these libraries, and use them are not using them in high-performance, memory-sensitive areas (production use at companies). There are Haskell libs of course that are used in these environments, and the compa…

Haskell has a problem in that people think about the basic libraries as deprecated, but won't deprecate them due to backward compatibility. Thus, people starting on it will get plenty of slow and unsafe constructs, while people used to it only look at the fast and safe ones. There should be warnings all over the Prelude and basic libraries documentation.

Yup, agreed. The #haskell channel on FreeNode has been great about providing feedback on what libraries one should use for performance.

Re: Becoming Productive in Haskell

#186

Post by SamReidHughes »

tel wrote: post #179
SamReidHughes wrote: post #146

Earlier quoted context omitted.

Is there a spec that leaves the order unspecified? Having it not be a right fold would be quite nutty. It is a right fold in implementation.

It's useful for more general folds over more general types. If you have a tree structure then you might not want to fold from the left or the right but instead in multiple places in parallel and then combine them at the end * + (* + (* + (* + (* + (* + *))))) versus (((((* + *) + *) + *) + *) + *) + * versus ((* + *) + *) + (* + (* + *))

Oh God, right. The changes over the years have left me bamboozled. Is (.) fmap yet?

Re: Becoming Productive in Haskell

#187

Post by gallabytes »

grp wrote: post #10
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…

Haskell with Emacs is awesome! There's a few modes available to have a powerful IDE. I don't remember which ones as xmonad + yi (or vi) is enough for me now.

How've you liked actually using yi? My only experience with it was rather frustrating.

Re: Becoming Productive in Haskell

#188

Post by agarden »

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…

lamdu has some interesting features:http://peaker.github.io/lamdu/

Re: Becoming Productive in Haskell

#189

Post by sordina »

AnimalMuppet wrote: post #184
semigroupoid wrote: post #183

Earlier quoted context omitted.

The definition of functor in category theory is from 1945 while most of today's mainstream programming languages are much younger than that. The people who wrote those definitions for C++, C#... simply ignored the existing terminology.

Fair enough. And yet, at the time (and even today, outside of the FP crowd), category theory is really far outside the scope of what most people consider programming, so it's hard to blame them for not looking there for terms. For that matter, category theory borrowed the word from linguistics, and most definitely did not keep the same meaning.

I certainly wouldn't blame anyone for not being familiar with the terms. What I would blame people for is attacking Haskell's choice of terminology due to it not 'being like c++'. A generous interpretation of intent goes a long way, and if that is out of reach, at least do enough research to make sure you're not pointing out weaknesses based on a false premiss. Instead I commonly see people starting from "I don't find Haskell intuitive" and extrapolating to "Haskell's contributors are indoctrinated and people who defend its use of established terminology are arrogant". Maybe I should just ignore such points of view but they seem to be infectious.

Re: Becoming Productive in Haskell

#190

Post by zem »

david-given wrote: post #14

The author's comments on noise chime true with me: every time I give Haskell a try I end up struggling with frustrating and opaque vocabulary, sometimes completely at odds with the way other languages use them: e.g. C++ also has functors, and they're completely unrelated to Haskell functors. I really like the author's suggestion of mentally translating Functor to Mappable. Are there any other synonyms for other Haske…

you might like elm [http://elm-lang.org/]; it's inspired heavily by haskell, but the author thinks long and hard about finding the right names for things rather than just using the defaults from haskell or ml.
Post reply on HN