3 ms·

I would not say that Haskell is currently ideal for writing native smartphone apps. It's possible and people are working on making it easier, but it's rough ter

by merijnv 12y ago

I would not say that Haskell is currently ideal for writing native smartphone apps. It's possible and people are working on making it easier, but it's rough territory still. Javascript is easier, ghcjs (while still a bit tricky to install) is 1.0 and lets you compile arbitrary GHC Haskell (including all extensions, lightweight threads and STM) to JS for both Node.js and the browser. Template Haskell support is on the way too. Calling the C FFI from Haskell is fairly trivial in my experience. If you have structs you want to manipulate from inside haskell it's a bit cumbersome and confusing initially, but if you're just using primitive types and pointers it's easy. Haskell does very well for high-performance when it comes to IO, as-of GHC 7.8's new IO manager the fastest Software-Defined Networking (SDN) application is written in Haskell [1]. In terms of pure computation bound performance Haskell, does well enough, optimising truly high-performance Haskell is as much arcane art as optimising C (we're talking "I want microsecond inner-loops" level of optimising). In general I would say that you should expect Haskell to be around JIT Java levels of speed for most cases where the code is not blatantly inefficient. So certainly an order of magnitude faster than python/ruby. Lots of people complain about performance reasoning in Haskell being hard, which is partially true. But mostly, IMO it is simply different from doing so in C, so you need to unlearn/relearn all your performance tweaking skills. As for Haskell vs Clojure and becoming a better developer. I think Clojure looks like an interesting language, but I would recommend learning Haskell anyway. Why? Because Haskell is one of the "most different" languages in which people are still writing lots of real world code. Which means that it will expose you to the largest number of new concepts while still having decent practical library support. Key features, IMO are: Purity, type system, laziness, and type classes. Incidentally, I would urge everyone to please stop using this silly "transpile" word. Compile is already source-to-source and introducing a new silly sounding word for it isn't helping anyone. [1] - http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask03...

danieldk 12y ago
Lots of people complain about performance reasoning in Haskell being hard, which is partially true. But mostly, IMO it is simply different from doing so in C, so you need to unlearn/relearn all your performance tweaking skills. I don't agree. First, of all, the naive solution in C is often pretty fast, while the naive solution in Haskell often has obnoxious runtime properties. Then, most C optimization performance reasoning applies to Haskell as well: keep your data small, in contiguous memory, etc. The first thing that complicates optimization in Haskell is that defacto Haskell data structures are the opposite: pointer/thunk-rich. So, you usually end up with libraries such as 'vector', doing the heavy lifting in the ST monad. Then, laziness adds even more complications, both in that it adds a new class of bugs (of course, Haskell removes buffer overflows et al.) which tend to be relatively hard to debug (the heap explodes in less expected places). When you write production code, you usually accumulate some monads. Unfortunately, the relatively obvious way to use multiple monads (monad transformers) is slow. So, you have to roll your own monad stacks: https://wiki.haskell.org/Performance/Monads https://wiki.haskell.org/Performance/Monads --- In the end, even something as simple as reading a list integers in the IO monad can be an exercise in frustration: http://www.joachim-breitner.de/blog/620-Constructing_a_list_in_a_Monad http://www.joachim-breitner.de/blog/620-Constructing_a_list_... The same can't be claimed for C. Even a newcomer could do it.
- codygman 12y ago
  > In the end, even something as simple as reading a list integers in the IO monad can be an exercise in frustration Only if you need it to do it in less than 164616 bytes, otherwise I'd just use: replicateM 1000 (return 42)

by merijnv 12y ago

danieldk 12y ago

Lots of people complain about performance reasoning in Haskell being hard, which is partially true. But mostly, IMO it is simply different from doing so in C, so you need to unlearn/relearn all your performance tweaking skills. I don't agree. First, of all, the naive solution in C is often pretty fast, while the naive solution in Haskell often has obnoxious runtime properties. Then, most C optimization performance reasoning applies to Haskell as well: keep your data small, in contiguous memory, etc. The first thing that complicates optimization in Haskell is that defacto Haskell data structures are the opposite: pointer/thunk-rich. So, you usually end up with libraries such as 'vector', doing the heavy lifting in the ST monad. Then, laziness adds even more complications, both in that it adds a new class of bugs (of course, Haskell removes buffer overflows et al.) which tend to be relatively hard to debug (the heap explodes in less expected places). When you write production code, you usually accumulate some monads. Unfortunately, the relatively obvious way to use multiple monads (monad transformers) is slow. So, you have to roll your own monad stacks: https://wiki.haskell.org/Performance/Monads https://wiki.haskell.org/Performance/Monads --- In the end, even something as simple as reading a list integers in the IO monad can be an exercise in frustration: http://www.joachim-breitner.de/blog/620-Constructing_a_list_in_a_Monad http://www.joachim-breitner.de/blog/620-Constructing_a_list_... The same can't be claimed for C. Even a newcomer could do it.

codygman 12y ago
> In the end, even something as simple as reading a list integers in the IO monad can be an exercise in frustration Only if you need it to do it in less than 164616 bytes, otherwise I'd just use: replicateM 1000 (return 42)