4 ms·
Except macros are great for more than just lazy evaluation. For instance, completely altering syntax to make your app make a lot more sense and remove any amoun
by orthecreedence 13y ago
Except macros are great for more than just lazy evaluation. For instance, completely altering syntax to make your app make a lot more sense and remove any amount of boilerplate.
As far as parallelism, sure Haskell can give that for free. The cost is you have to be pure about everything, which just seems obnoxious to me...especially when you don't necessarily care about parallelism or performance.
With lisp, I can use macros to make parallelism just as natural as programming regular lisp. Yes, I have to be explicit about when I'm being parallel and when I'm not. But that doesn't seem like such a big deal to me, and sometimes you want explicit control over your threads.
As far as community, I have no doubts the Haskell community is great. But so is the lisp community. There are a lot of bright people who jump at any chance to help out others, and in the past 5 years the CL implementations and community-built libraries have been making leaps and bounds.
This isn't to say Haskell isn't a great choice for many, many applications and requirements. But it's not a replacement for lisp, just as lisp isn't a replacement for Haskell. They are two different beasts that are great at different things.
- coolsunglasses 13y ago>Except macros are great for more than just lazy evaluation. Haskellers agree, that's why we have Template Haskell. We use it for all sorts of things, like automatically implementing typeclasses (interface'ish) at compile-time. > parallelism, sure Haskell can give that for free Not really. >The cost is you have to be pure about everything Nonsense. Boom, mutable variables: http://bitemyapp.com/posts/2014-03-25-when-nested-io-actions-are-wanted.html http://bitemyapp.com/posts/2014-03-25-when-nested-io-actions... >sometimes you want explicit control over your threads. You can have that in Haskell. You can use green threads or OS threads and optionally pin OS threads to a particular CPU to avoid context-switching. So you can know what you're talking about next time, my recommended guide for Haskell: https://gist.github.com/bitemyapp/8739525 https://gist.github.com/bitemyapp/8739525 The concurrency primitives in Haskell are broad and deep, check this book out: http://chimera.labs.oreilly.com/books/1230000000929 http://chimera.labs.oreilly.com/books/1230000000929 --- an ex-Lisper
- xico 13y agoAutomatically implementing typeclasses can often be done with just generics http://www.haskell.org/haskellwiki/GHC.Generics http://www.haskell.org/haskellwiki/GHC.Generics
- djur 13y ago> So you can know what you're talking about next time, my recommended guide for Haskell: I like your guide, but is this really necessary? This isn't the first time you've been aggressively hostile to people expressing a preference for Lisp over Haskell, either.
- coolsunglasses 13y agoThere were untrue statements, I corrected them. Also you can't express a preference (up or down) for something you've never used. I'll elide the snark next time, but I'm not going to stop correcting false statements or sharing learning resources.
- chrisdone 13y agoI don't approve of the snark either. I think you can read it as zeal rather than bitterness, at least.
- chrisdone 13y agoConsider the comment you're replying to: > I have no doubts the Haskell community is great. You're not making a strong case for it, are you? ;-)
- coolsunglasses 13y agoIt was imperfectly stated and with unconstructive tone. I allowed my irritation at statements made about Haskell by someone that hadn't used it get to me. That's my fault. Would be nice if the culture could shift a notch or two towards, "know nothing -> say nothing" though.