Intro to Haskell for Erlangers
bob.ippoli.to
bob.ippoli.to
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 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.
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.
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.
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!
http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-...
> 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.
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.
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 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.
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 think video of the talk that goes with these slides will eventually be uploaded at: 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.
http://bob.ippoli.to/haskell-for-erlangers-2014/#/abstractio...
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-...
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".
http://www.haskell.org/cabal/users-guide/installing-packages...
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&s...
[1] http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
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.
Seriously, it seems like the more people agree on something the more they bikeshed over it.
Well worth being at least familiar with both.
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 };
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.
Bottom line? Works great.
I'm sure that you also know C, since you know C++. Let me know how it goes.