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.
