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

121–130 of 213 posts

Re: Becoming Productive in Haskell

#121

Post by kyllo »

pjungwir wrote: post #106

I've got a side project webapp I'd like to use to learn some Haskell. What is the most mainstream Rails-like web application framework out there? By Rails-like I mostly mean convention-over-configuration, with a strong ecosystem of plugins so I don't have to re-invent the wheel for auth, file uploads, etc. So far I've seen: - Yesod - Snap - Happstack - Scotty - Spock Right now I'm learning Yesod, but I don't feel con…

Yesod is the closest thing to a Haskell version of Ruby on Rails.

Scotty and Spock are both Sinatra-like.

There's a lot of good info here: https://wiki.haskell.org/Web/Frameworks

Re: Becoming Productive in Haskell

#122

Post by whateveracct »

tormeh wrote: post #66
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.

That's because the Scala stdlib doesn't abstract over things that can be mapped over. If you want to do that, then you need a typeclass. Scalaz has a typeclass for mappable things and it's called Functor.

Re: Becoming Productive in Haskell

#123

Post by LukeHoersten »

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…

I've actually found the exact opposite. The library ecosystem is rich and mature. Haskell is, by default, "concurrency safe" because of referential transparency. You can safely "async" and compose almost any library in the Haskell ecosystem without worrying about shared memory etc underneath.

Also, a lot of the really common libraries like text, attoparsec (parsers), aeson, networking, etc are highly tuned for low latency and performance. Many use compiler rewrite rules and techniques called stream-fusion to compact a lot of the machine code away. Also aggressive inlining etc can be done.

I'm sure there are some memory-heavy or poorly optimized libraries out there but that's certainly not the norm. I've had no problems with the libraries off-the-rack.

Re: Becoming Productive in Haskell

#124

Post by QuantumRoar »

dllthomas wrote: post #113
QuantumRoar wrote: post #103

Earlier quoted context omitted.

If you have an array that fills a significant fraction of your memory (say, tens of Gigabytes), you don't have another choice but to use mutation (Haskell doesn't support that). While quite fast, it is not in the league of low level programming languages. If you need ridiculous speeds, you don't have another choice but to use C, C++ or Fortran. Python has a lot of very useful modules. If I can solve my problem with b…

Haskell does support mutable arrays. Your code that does the mutating will have to live in IO (or perhaps ST), but the downsides of that are exaggerated.

Oh. I didn't know that. Thanks for pointing that out.

Re: Becoming Productive in Haskell

#125

Post by ihm »

dllthomas wrote: post #99
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…

As others pointed out, the way Haskell uses the term "functor" is related to the way mathematicians had been using it for at least a decade before cfront. I agree that a shared vocabulary is important, but standardizing in a way that makes the mathematical writings on the topic more accessible seems a big win. Moreover, "functor" is a bit more precise than "mappable" - a functor is a mapping that preserves structure.…

> As others pointed out, the way Haskell uses the term "functor" is related to the way mathematicians had been using it for at least a decade before cfront.

Rather a bit more than that. Eilenberg and Maclane's original paper defining the basic notions of category theory was published in 1945! http://www.ams.org/journals/tran/1945-058-00/S0002-9947-1945...

Re: Becoming Productive in Haskell

#126

Post by wz1000 »

QuantumRoar wrote: post #103
krick wrote: post #87

Earlier quoted context omitted.

> I also wouldn't want to do everything in Haskell. Examples, please? And why?

If you have an array that fills a significant fraction of your memory (say, tens of Gigabytes), you don't have another choice but to use mutation (Haskell doesn't support that). While quite fast, it is not in the league of low level programming languages. If you need ridiculous speeds, you don't have another choice but to use C, C++ or Fortran. Python has a lot of very useful modules. If I can solve my problem with b…

> If you have an array that fills a significant fraction of your memory (say, tens of Gigabytes), you don't have another choice but to use mutation (Haskell doesn't support that).

Haskell does support mutation, it just requires it to be controlled. Take a look at Data.Array.ST and Data.Array.IO

> Erlang's light-weight threads are a boon. Having a webserver written in Erlang and using Erlang as a server-side language, you can support a lot of sessions at once.

GHC provides a very similar thing in the form of "green threads".

Re: Becoming Productive in Haskell

#127

Post by QuantumRoar »

ffn wrote: post #118
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…

Absolutely, Haskell has a richness of concepts to it that's entirely in a class of its own... but that being said, Haskell is to programming what sex is to life (for a woman... because men's natural enjoyment of sex throws off my following analogy). Granted there is richness and joy in finally discovering it, one needs to realize it's important that one isn't forced into it too early. Haskell demands a lot of thinkin…

I agree, except for the sex analogy. You could've easily went with something like:

Haskell is to programming what bugs are to food. Both are functional, an acquired taste and look scary from the outside.

Re: Becoming Productive in Haskell

#128

Post by nbouscal »

ffn wrote: post #118
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…

Absolutely, Haskell has a richness of concepts to it that's entirely in a class of its own... but that being said, Haskell is to programming what sex is to life (for a woman... because men's natural enjoyment of sex throws off my following analogy). Granted there is richness and joy in finally discovering it, one needs to realize it's important that one isn't forced into it too early. Haskell demands a lot of thinkin…

> they were there for you when you were programmatically young and they introduced you gently into a world that's otherwise extremely complex.

This may be true for you, but it is not true for everyone. You assume that learning Haskell as a first programming language would be more difficult, but you don't present any evidence to support that claim. People who have done so disagree with you.

Re: Becoming Productive in Haskell

#129

Post by dllthomas »

ihm wrote: post #125
dllthomas wrote: post #99

Earlier quoted context omitted.

As others pointed out, the way Haskell uses the term "functor" is related to the way mathematicians had been using it for at least a decade before cfront. I agree that a shared vocabulary is important, but standardizing in a way that makes the mathematical writings on the topic more accessible seems a big win. Moreover, "functor" is a bit more precise than "mappable" - a functor is a mapping that preserves structure.…

> As others pointed out, the way Haskell uses the term "functor" is related to the way mathematicians had been using it for at least a decade before cfront. Rather a bit more than that. Eilenberg and Maclane's original paper defining the basic notions of category theory was published in 1945! http://www.ams.org/journals/tran/1945-058-00/S0002-9947-1945...

Thanks! I suspected that was the case, but the looser bound was much easier to be confident in with the level of effort I could spare.

Re: Becoming Productive in Haskell

#130

Post by ihm »

harry8 wrote: post #9

I don't think I have ever used a haskell program written by someone else that wasn't ghc. Is that usual? Are there now a bunch of .debs for useful things other than writing haskell that are actually written in Haskell? I'm not trolling, it's just a good test of what something is useful for when it's been around a while is to ask "Well, what has it actually been used for?"

The Elm compiler is written in Haskell, and as others have mentioned, I use xmonad and pandoc.
Post reply on HN