6 ms·

I always have been interested on haskell.... but it doesn't look to be enough practical. For example there is almost no information about how to write a smartph

I always have been interested on haskell.... but it doesn't look to be enough practical. For example there is almost no information about how to write a smartphone videogame in haskell, even if it possible to trasnpile it to C or to Javascript. It is possible to interoperate with the host language? Does it perform well for high performance activities? Is it possible to isolate some kind of events in a thread? Edit: This lack of practical approach is what makes me hesitate in contrast to clojure (just to mention a language), especially if the only goal is to become again a "better developer" rediscovering functional terms and abstractions also documented in other languages.

exDM69 12y ago
Your fears are not warranted. Haskell is the most practical of the "research languages" out there, it's very mature and has good facilities for interfacing with the "real world". > For example there is almost no information about how to write a smartphone videogame in haskell This has been done before but most of the "hard stuff" here is getting your game built and deployed on a smartphone. You can find Haskell for Android articles if you look around. There are examples of game programming in Haskell too. > It is possible to interoperate with the host language? There is no concept of "host" lanugage, Haskell emits native code. You can call native code from Haskell and Haskell code from C or other native languages. > Does it perform well for high performance activities? Haskell is good enough for most "high performance" activities (it's one of the highest performing high level languages according to the debian shootout), but caveats may apply with long running processes and garbage collection, etc. > Is it possible to isolate some kind of events in a thread? Yes. Haskell has very nice threading facilities and high-level concurrency primitives, including stuff similar to "channels" from golang.
rhizome31 12y ago
I enjoyed working through this book. Actually it helped me learn enough Haskell to realize that I wasn't that interested in it. I found that it wasn't as safe as it claimed to be and that the tooling was not very good. There are some refreshing and interesting ideas, but overall I'm not sure it was worth my time.
- codygman 12y ago
  > I found that it wasn't as safe as it claimed to be and that the tooling was not very good. How was Haskell not "as safe as it claimed to be"? What tooling was not very good? What tooling was missing for you?
  - rhizome31 12y ago
    * Non-exhaustive patterns error was disappointing after being told that "if it compiles it will run". It seems to be the Haskell equivalent of NullPointerException (I'm told OCaml doesn't have this problem). * Cabal Hell: https://news.ycombinator.com/item?id=8011267 https://news.ycombinator.com/item?id=8011267 * Installing libraries is slow * The Haskell platform is not batteries included * JSON parsing seem to be more complicated than it needs to be * Also got confused by keywords naming: https://news.ycombinator.com/item?id=5689951 https://news.ycombinator.com/item?id=5689951 * I found Yesod API to be inelegant. I found it odd that it needs so many non-standard compiler extensions, which might be a sign that the language is not expressive enough. * One-letter variables seem to be idiomatic. This is unappealing to me because I try to make my code readable. * For the same reason, frequent use of special characters in operators (, <>, ///, etc.) in the standard library and in third-party libraries was not appealing. I was disappointed because I was attracted by referential integrity, strong compiler checks, pattern matching and function composition but overall I was left with the impression that the Haskell environment was not very well polished from a software engineering point of view.
    - tome 12y ago
      > Non-exhaustive patterns error was disappointing after being told that "if it compiles it will run". Yes, it's somewhat strange this is only a compiler warning rather than a compiler error.
      - codygman 12y ago
        I agree, I would prefer that it was an error as well. For my personal projects I use -WError, but sane defaults count for a lot.
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.
lmm 12y ago
> For example there is almost no information about how to write a smartphone videogame in haskell, even if it possible to trasnpile it to C or to Javascript. These guys are doing it pretty seriously: http://keera.co.uk/blog/all-posts/ http://keera.co.uk/blog/all-posts/ And frankly a smartphone videogame is a pretty specialized use case; a lot of pretty mainstream languages (perl?) don't have a good story for how to do that. In fact I've never heard of anyone writing a smartphone game in Clojure - I guess you could do one for Android since it's just java bytecode, but does anyone? "Practical" for most programmers is server-side business apps, and Haskell is very very good at those. > Does it perform well for high performance activities? Yes, very much so.
- Jach 12y ago
  Regarding Clojure, yes it's done. I haven't kept up with the latest clojure on android news, but https://play.google.com/store/apps/details?id=com.friendlyvillagers.ballz https://play.google.com/store/apps/details?id=com.friendlyvi... has been around for a while and I think the author just built off of libGDX. There's also exciting work on Unity integration: http://arcadia-unity.tumblr.com http://arcadia-unity.tumblr.com

exDM69 12y ago

Your fears are not warranted. Haskell is the most practical of the "research languages" out there, it's very mature and has good facilities for interfacing with the "real world". > For example there is almost no information about how to write a smartphone videogame in haskell This has been done before but most of the "hard stuff" here is getting your game built and deployed on a smartphone. You can find Haskell for Android articles if you look around. There are examples of game programming in Haskell too. > It is possible to interoperate with the host language? There is no concept of "host" lanugage, Haskell emits native code. You can call native code from Haskell and Haskell code from C or other native languages. > Does it perform well for high performance activities? Haskell is good enough for most "high performance" activities (it's one of the highest performing high level languages according to the debian shootout), but caveats may apply with long running processes and garbage collection, etc. > Is it possible to isolate some kind of events in a thread? Yes. Haskell has very nice threading facilities and high-level concurrency primitives, including stuff similar to "channels" from golang.

rhizome31 12y ago

I enjoyed working through this book. Actually it helped me learn enough Haskell to realize that I wasn't that interested in it. I found that it wasn't as safe as it claimed to be and that the tooling was not very good. There are some refreshing and interesting ideas, but overall I'm not sure it was worth my time.

codygman 12y ago
> I found that it wasn't as safe as it claimed to be and that the tooling was not very good. How was Haskell not "as safe as it claimed to be"? What tooling was not very good? What tooling was missing for you?
- rhizome31 12y ago
  * Non-exhaustive patterns error was disappointing after being told that "if it compiles it will run". It seems to be the Haskell equivalent of NullPointerException (I'm told OCaml doesn't have this problem). * Cabal Hell: https://news.ycombinator.com/item?id=8011267 https://news.ycombinator.com/item?id=8011267 * Installing libraries is slow * The Haskell platform is not batteries included * JSON parsing seem to be more complicated than it needs to be * Also got confused by keywords naming: https://news.ycombinator.com/item?id=5689951 https://news.ycombinator.com/item?id=5689951 * I found Yesod API to be inelegant. I found it odd that it needs so many non-standard compiler extensions, which might be a sign that the language is not expressive enough. * One-letter variables seem to be idiomatic. This is unappealing to me because I try to make my code readable. * For the same reason, frequent use of special characters in operators (, <>, ///, etc.) in the standard library and in third-party libraries was not appealing. I was disappointed because I was attracted by referential integrity, strong compiler checks, pattern matching and function composition but overall I was left with the impression that the Haskell environment was not very well polished from a software engineering point of view.
  - tome 12y ago
    > Non-exhaustive patterns error was disappointing after being told that "if it compiles it will run". Yes, it's somewhat strange this is only a compiler warning rather than a compiler error.
    - codygman 12y ago
      I agree, I would prefer that it was an error as well. For my personal projects I use -WError, but sane defaults count for a lot.

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.

lmm 12y ago

> For example there is almost no information about how to write a smartphone videogame in haskell, even if it possible to trasnpile it to C or to Javascript. These guys are doing it pretty seriously: http://keera.co.uk/blog/all-posts/ http://keera.co.uk/blog/all-posts/ And frankly a smartphone videogame is a pretty specialized use case; a lot of pretty mainstream languages (perl?) don't have a good story for how to do that. In fact I've never heard of anyone writing a smartphone game in Clojure - I guess you could do one for Android since it's just java bytecode, but does anyone? "Practical" for most programmers is server-side business apps, and Haskell is very very good at those. > Does it perform well for high performance activities? Yes, very much so.

Jach 12y ago
Regarding Clojure, yes it's done. I haven't kept up with the latest clojure on android news, but https://play.google.com/store/apps/details?id=com.friendlyvillagers.ballz https://play.google.com/store/apps/details?id=com.friendlyvi... has been around for a while and I think the author just built off of libGDX. There's also exciting work on Unity integration: http://arcadia-unity.tumblr.com http://arcadia-unity.tumblr.com