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.)
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.
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.
Your assumptions are not very accurate at all. The job I just left we had moved to haskell precisely for growth. We had no problems hiring haskellers, or having our existing PHP devs learn haskell. The new job I took is getting tons of applications from experienced haskellers. There's tons of people who know haskell and don't get to use it at work. They are generally quite eager to fix that problem.
I meant it in good humor, but over the last 15 years, I have had the joy (and pain) of getting to ship production systems in a lot of less popular stacks including: Erlang (multiple), Eiffel, Haskell, and OCaml.
Hiring and training for these less popular stacks has been a goddamn nightmare in "win" conditions. You have the benefit of the better signal to noise ratio in resumes, absolutely. But, you pay for that in rarity, salary and job demands, which is fine as long as you go in eyes wide open and plan to have a small team (under 10).
Rapid team growth (from money injection, or simply success and need) is really, really hard when you don't have a large pool of qualified candidates to pull from... and training, I honestly can't fathom trying to train PHP developers in Haskell. If you company has done this successfully, please setup a newsletter, I would subscribe.
>But, you pay for that in rarity, salary and job demands
Quite the opposite. As I said, there are a lot of people who know haskell but don't get to use it in their job. There's tons of people applying for haskell jobs at $50-60k/year. Being able to use haskell is a big enough draw in and of itself.
>If you company has done this successfully, please setup a newsletter, I would subscribe.
There would be nothing to go in it. Haskell is not particularly difficult to learn. People can get up and running doing web development very quickly, without any significant changes to how they normally do things since you don't do much destructive updating in most web apps anyways.
make a powerful language, and many things which ought to be part of the core system are going to be in a library.
That's an issue? I would consider it a feature. Core language features which cannot be extended are very frustrating to deal with; just look at generic containers in Go!
> Somewhat related to the large Tcl vs small Tcl issue was one particular extension, or extensions to the language that was noticeably absent: a system for writing “object oriented” code. Tcl, at heart, will never be an OO language through and through, like Ruby or Smalltalk, but that doesn’t mean that an OO system for it is not a useful way of organizing larger Tcl systems. Indeed, Tcl’s syntax is flexible enough that it’s possible to write an OO system in Tcl itself, or, optimizing for speed, utilizing the extensive C API in order to create new commands. Over the years, a number of such systems have arisen, the most well-known being “Incr Tcl” (a play on the incr command, which is akin to += 1 in languages like C). However, none of these extensions was ever included with the standard Tcl distribution or somehow “blessed” as the official OO system for Tcl. This meant that a newcomer to Tcl wishing to organize their code according to OO principles had to pick a system to use from several competing options. And of course, newcomers are the least able to judge a complex feature like that in a language, making it a doubly stressful choice. Furthermore, even experienced Tcl programmers who wanted to share their code could not utilize an OO system if they wanted their code to work with just standard Tcl. Also, if their code had a dependancy on some OO system, it would require the user to download not only the extension in question, but the OO system it was built on, which, naturally, might conflict with whatever OO system the user had already selected! As of Tcl 8.6, thanks to the work of Donal Fellows, Tcl is finally integrating the building blocks of an OO system in the core itself, but this effort is probably something like 10 years too late.
This is not the same thing. You are talking about language extensions, I am talking about libraries. Features which require language modification/extension in other languages can usually be implemented as ordinary libraries in Haskell.
> Features which require language modification/extension in other languages can usually be implemented as ordinary libraries in Haskell.
Tcl can implement OO as a library. Granted that it's not "turtles all the way down OO" ala smalltalk, but it's good enough for code organization purposes.
Yes, and then you get several different and incompatible ways of handling errors, at least three different lens libraries... The resulting fragmentation is an issue. It is the same issue as Tcl.
Fragmentation is an issue with every mature, vibrant ecosystem. It's also a benefit in that it fosters innovation.
As for lens libraries? Edward Kmett's library[0] has taken over that space. The other libraries represent previous attempts at discovering the optimal API and mainly exist now for historical/compatibility reasons.
> Fragmentation is an issue with every mature, vibrant ecosystem. It's also a benefit in that it fosters innovation.
I get your point, but sometimes it can be better to have a somewhat less-than-optimal solution standardized rather than many "better" solutions. And while people obviously come up with different solutions to the same issue, it is important to distinguish critical systems (eg, error handling) from other systems which are specific to a few domains (eg, webservers). IMHO, the former absolutely need to be standardized.
> As for lens libraries? Edward Kmett's library[0] has taken over that space. The other libraries represent previous attempts at discovering the optimal API and mainly exist now for historical/compatibility reasons.
I get your point, but I'm sure you'll still find a number of libraries on Hackage depending on non-Lens packages. This is not a desirable state of affairs.
I get your point, but I'm sure you'll still find a number of libraries on Hackage depending on non-Lens packages. This is not a desirable state of affairs.
That's an issue of package curation. It has nothing to do with the merits or demerits of a language. When outdated/broken/abandoned software sits around it's always going to be a problem for beginners who don't know the difference.
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.
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.
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".
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!
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.
You do realise that this talk was given at an Erlang-only conference which you have to pay to attend to it (well, everyone but the speakers)? How people are so focused on language popularity will never cease to amaze me.
Ippolito is well known in the Erlang world for his work at Mochiweb and he is sharing with his community his explorations in Haskell. What's the matter with this?
Juxtapositions between Haskell and Erlang have historically always come up so a comprehensive summary is always welcome.
Also, out of all the possible epenis measurement metrics for 1337est programming languages, popularity is the absolute dumbest one and is the bastion of mediocre codemonkeys.
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.
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.
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.
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.
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.
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.
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.
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.
