7 ms·

Intro to Haskell for Erlangers

• DiabloD3 13y ago
  As someone that knows Erlang but doesn't Haskell and wants to learn, this might come in handy.
• lclarkmichalek 13y ago
  Anyone know of anything similar going the other way around?
• judk 13y ago
  Nice, a slide show using a bleeding edge layout/display framework that doesn't work on mobile. Way to spread your ideas.
  • thu 13y ago
    It seems those are slides for a live presentation, so I guess you might also complain about the lack of sound or about how pointless it is to post slides on the internet. Or you might make a constructive comment. Or no comment at all. Still I was curious to find out what "doen't work" means in the context of your comment. I tried on my Nexus 4 and everything was nice. So maybe you should complain about how a slack the original author is to not try his intended-for-a-live-presentation slides on all possible devices a careful reader like you could see them.
    • deleted 13y ago
      [deleted]
  • nbouscal 13y ago
    It worked really nicely on my iPhone.
  • coldtea 13y ago
    Yes, because mobile users are entitled to his presentation right?
  • runejuhl 13y ago
    Because of your comment I tried the site in my installed browsers: stock CyanogenMod browser, Firefox, Chrome, Opera and Dolphin. I tried looking at the source of the page, and I've looked at it in w3m and elinks. Bottom line? Works great.
    • bhauer 13y ago
      Worked just great on IE for Windows Phone.
  • jeffdavis 13y ago
    What specific device and software are you using? Perhaps the problem can be fixed once it's identified.
• mulligan 13y ago
  I attended this talk and it was very well done. Most intro to $LANGUAGE talks try to share a few very simple examples of the language. Something most people could read about and absorb on their own in 10-15 minutes. Bob's slides and presentation went for breadth, acknowledging that this was not a tutorial but a way to present listeners with a great sense of what the language does, how it contrasts with Erlang, and [what I found the most useful] a good explanation of how to approach some of the more difficult to explain concepts. Now when I sit down to actually learn Haskell, I have a useful mental model on a bunch of the not so obvious concepts. I think video of the talk that goes with these slides will eventually be uploaded at: http://www.youtube.com/user/ErlangSolutions http://www.youtube.com/user/ErlangSolutions Some of the presentations from just a couple days ago are already up, so I hope to see the rest soon.
  • pohl 13y ago
    I love how dense but clear slide 125 is. I look forward to the upload.
    • jaytaylor 13y ago
      Getting to slide 125 can be a challenge (no TOC, each next slide takes a history slot in Chrome). http://bob.ippoli.to/haskell-for-erlangers-2014/#/abstractions http://bob.ippoli.to/haskell-for-erlangers-2014/#/abstractio...
• louthy 13y ago
  > Cabal; easily fetch more packages from Hackage Having spent the past two days trying to recover from Cabal Install's dependency hell (still ongoing), I must disagree on this. OSX seems to be particularly shonky (on mavericks), Windows has been relatively plain sailing. http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/ http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-... Don't let that put you off though, Haskell really is a beautiful language, I quite often find myself just sitting back and looking at the code thinking "Damn that looks good".
  • louthy 13y ago
    Heh, 1 min after posting this I fixed my dependency hell! Finally. Clearly I just needed a bit of HN distraction :)
    • lelf 13y ago
      You should sort out how to use cabal sandboxing http://www.haskell.org/cabal/users-guide/installing-packages.html#developing-with-sandboxes http://www.haskell.org/cabal/users-guide/installing-packages...
  • nbouscal 13y ago
    Cabal still has a little ways to go, but it has been improving rapidly. Sandboxes came out recently and have helped a lot.
  • MaxGabriel 13y ago
    This was what finally got Cabal working for me on OS X http://stackoverflow.com/a/21285413/1176156 http://stackoverflow.com/a/21285413/1176156
  • lallysingh 13y ago
    I just cabal init in each new project directory, add my deps as desired there, and cabal-dev install it. Pretty easy.
• jokoon 13y ago
  what about C++ers ? :(
  • wging 13y ago
    A little googling has dug this up: http://www.haskell.org/haskellwiki/Haskell_Tutorial_for_C_Programmers http://www.haskell.org/haskellwiki/Haskell_Tutorial_for_C_Pr... I'm sure that you also know C, since you know C++. Let me know how it goes.
• spullara 13y ago
  This seems like a vanishingly small set of people. You're introducing the 49th[1] most popular language to people that program in a 50+ language. If you are trying to get more converts to Haskell, I would go after a larger set of programmers. If it is just for fun, cool. [1] http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
  • chongli 13y ago
    Functional language cannibalism at its finest! Seriously, it seems like the more people agree on something the more they bikeshed over it.
    • chc 13y ago
      Haskell and Erlang are different enough in large and significant ways that I don't feel like they really qualify for the "color of the bikeshed" comparison. They both fit into the "functional languages" paradigm, but then, Objective-C and Fortran both fit into the "imperative languages" paradigm.
      • troutwine 13y ago
        Being very proficient in Erlang and able to bumble about pretty effectively in Haskell, I can confidently say that while the two languages require complementary skills they target two different problem domains: Erlang's a heavy-lift rocket, Haskell's a sub-orbital rocket-plane. Well worth being at least familiar with both.
      • chongli 13y ago
        After having slept on it, I now don't know what point I was trying to make with the bikeshed comment. It doesn't make any sense now!
  • kungfooguru 13y ago
    Hah.
  • 13y ago
• jerf 13y ago
  This is how I came to Haskell. If you're a polyglot sort and you eventually want to get to Haskell, but Erlang also looks interesting, it's not a bad path. Erlang can get you over the basics of working with immutable data structures (in particular it can get you past "But how can I write a program without mutable values?!?"), has enough interesting stuff to learn on its own about reliable programming to justify learning it on its own merits, and then when you go to Haskell, you won't be trying to swallow quite as much in one go. You can focus on what Haskell actually has to say, instead of being stuck on the basics. The downside is after that, Erlang's deficiencies as a functional language will be pretty obvious and quite frustrating. (I'm not kidding that it's worth learning, probably much moreso than the next C(#/++/)-etc variant, but there's a certain klunkiness to Erlang that gets old after a while.)
  • mercurial 13y ago
    On the other hand, I find myself unable to plateau in Haskell, it seems that there is always new abstractions behind the corner. Want to thread exceptions through your monad transformers? Learn MonadState. Want accessors which do not suck? Learn Lens. And then you have free monads, comonads, Operational, Kleisli arrows, Pipes/Conduits/IO Streams/Iteratees... It may be an issue with the language: make a powerful language, and many things which ought to be part of the core system are going to be in a library. And as Haskell's syntax unfortunately allows library designers to go wild with ASCII symbols, you can easily end up with really hard-to-grok code (especially with the right amount of point-free style). Bonus if you use one-character variables. Unfortunately, in the real world code is read more than it is written, and the prevalent cleverness doesn't really help with that.
    • lostcolony 13y ago
      I'm working to learn Haskell, and that's actually part of the appeal. I don't expect to ever write Haskell in production. Oh, sure, some places do, but they're very, very few; I suspect it's pretty much impossible in any area where you expect to grow, simply because finding people who know it already is nearly impossible, and learning it is difficult, especially as your established crew learns new and more powerful abstractions; the amount of learning required to get someone up to speed gets higher and higher, which is not what you want as you expand. But that said, as a developer even in more approachable languages, learning that cleverness has its benefits. It provides new insights into ways problems can be expressed. Most developers agree on the benefits of learning a new language; you learn a few good ideas, a few paradigms and approaches, that can carry over and affect the way you code in your day to day. Haskell, with its depth, is better still; you have a seemingly neverending set of ideas to learn and draw from. Many, yes, are too clever to see a full implementation elsewhere in production code that has many maintainers. But borrowing even part of an idea expressed in Haskell may lead to a simple, reusable, and concise solution to a problem that otherwise would be an ugly bug riddled one off solution.
• lostcolony 13y ago
  Can't wait for the talk to be made available. I missed out on Erlang Factory this year, but this is one talk I am definitely looking forward to seeing uploaded.
• subleq 13y ago
  In what way is Haskell's pattern matching not as clever as Erlang's?
  • lostcolony 13y ago
    It shows later in the slideshow, no? Slides 40-41.
    • subleq 13y ago
      I see, it's just the non-linear patterns? Looks like they were considered for Haskell and there are some good arguments against them: http://www.mail-archive.com/haskell@haskell.org/msg03721.html http://www.mail-archive.com/haskell@haskell.org/msg03721.htm....
      • lostcolony 13y ago
        I don't know if it's only; didn't see the talk. I can see why to exclude it, but Erlang has everything in place to make its inclusion a very obvious ones. All data types are comparable, for ill or for good (I've been both helped and hurt by it), and allowing non-linear patterns makes for some very clean pattern matching code for many recursive functions.
      • nox_ 13y ago
        Yes, Erlang patterns are non-linear, Haskell has view patterns. Neither are more powerful than the other. They are just different. Erlang non-linear patterns fit more with the semantics of match where an already bound name isn't shadowed, view patterns fit well into Haskell because of the ensured purity.
  • peteretep 13y ago
    Consider: evaluate([ A,A,A, _,_,_, _,_,_ ]) when A != b -> { winner, A }; evaluate([ _,_,_, A,A,A, _,_,_ ]) when A != b -> { winner, A }; evaluate([ _,_,_, _,_,_, A,A,A ]) when A != b -> { winner, A }; I don't think I can do that as eloquently in Haskell using pattern matching, but I'd love for you to show me.
• glesica 13y ago
  Having seen this talk, I highly recommend it, even if you don't know Erlang (just skip the Erlang slides). It's a great overview of Haskell for anyone looking to quickly become productive(-ish) with the language!
• rdtsc 13y ago
  To piggy back on this topic -- this is happening at Erlang Factory (Erlang's main "conference"). Here is a list of uploaded videos from it. There are some very exciting talks, including a talk from Whatsapp about their architecture. https://www.youtube.com/user/ErlangSolutions/videos?view=0&shelf_id=1&sort=dd https://www.youtube.com/user/ErlangSolutions/videos?view=0&s...