I tried to use Haskell three times. Cabal was the always the reason why I left. I use three different machines. 2 at two different locations at work and one at home. All three would be different and have different errors. I would spend hours and always left with a horrible taste in my mouth.
Today I use Racket and I won't go back but I am glad Stack is taking over Cabal.
It is not only Cabal, but also the constant churn in a lot of packages. For example, conduit was a great package when I used Haskell. But usually I had to update quite a bit of code when I would bump conduit up to the latest version after not touching a program for a year.
Maybe I have been unlucky enough to use Haskell during some transitions (pre-arrows -> arrows rule, let's use them everywhere -> arrows suck, basic IO monad -> iteratees, old fashioned field access -> various lens proposals -> lens). But I never used a language ecosystem before or after where things would change or break so often.
Yes, there have been quite a few transitions happening. They didn't happen "for fun", but because it had been felt that the optimal solutions were not found yet (optimal as in elegant, easy to use, maintainable, ...).
Luckily, Haskell's static typing coupled with the extremely helpful error messages of the compiler makes refactoring a cheerful task: If it worked before and all type errors have been fixed, then we can be quite confident that it works again.
Many areas have stabilized now. For instance, Edward Kmett's lens package is the de facto standard for all things related to records, getters, setters, and all those things on steroids. (Personally, I love how this turned out. Before lens, we quite frankly had the problem that field accesses were much more painful than they are in mainstream object-oriented languages like Python or Java. Nowadays field accesses are as simple as they are in other languages, and in addition to this we have the flexibility of composable first-class lenses.)
... by someone trying to actually address the issues. There are almost always wrong ways you can fix a type error. Fortunately, that's usually the situation at hand...
The number one mistake they made was in deciding to make the package database stateful. Such an odd choice for a language so focused on purely functional programming. Packages should be pure functions, with the final result being a read-only cache. This is how Nix [0] works and it makes everything else seem like a bad idea by comparison.
With sandboxes, I had little-to-no trouble developing individually on a single machine. I sometimes ran into issues trying to get the same thing building elsewhere.
There are a couple of peculiarities of Haskell's module system which made it difficult, but yes, I agree that it took longer than it should have.
However, nowadays there is a decent dependency management and build tool! It's called "stack", as in "stack install xmonad". I never once had any dependency or other compile problems with stack. It simply always works. :-)
I've had a lot of problems with Stack whenever I'm doing non-trivial (that is, beyond just "build this executable the standard way") kinds of tasks—in particular, it tends to corrupt its package DB after a while for mysterious reasons, and you have to blow it away and rebuild, and it can be a nightmare to do certain bits of configuration where the UI is undocumented or nonexistant—but it's a pretty big step up from historical Cabal.
There's also an already-working-but-still-not-quite-finished alternative system within Cabal which is eventually gonna become the default one, and which does builds in a Nix-inspired way. I've been using that for the better part of a year now, and I like it far better than either historical Cabal or Stack: http://blog.ezyang.com/2016/05/announcing-cabal-new-build-ni...
I didn't ever figure out a minimal reproduction, but I also should be clear that that was my experience using Stack at the time: I haven't used it in more than a year (I jumped ship to new-build as soon as it was first available and haven't looked back) so those problems might have been alleviated since then.
Two things missing that I wish I knew when I had learned Haskell.
First, Haskell is just another programming language. It has many papers written about it, and many people have strong opinions about it, but at the end of the day it is not that special.
Second, the Haskell community is not friendly and welcoming to many groups of folks. In particular, if you are a fan of dynamic/gradual typing, objects, distributed systems, etc. do not expect a warm welcome.
A personal anecdote: I left #haskell on Freenode because a regular and popular user proposed and endorsed an extended analogy wherein all humans are divided into "dynamically-typed" and "statically-typed" people, and statically-typed people are superior because they are more reliable. This kind of bias pervades the community and ruins any kind of cross-ecosystem collaborative efforts.
Edit: Was I being confrontational? I wasn't even part of this conversation! I was lurking, and I saw this ridiculous thing play out unprompted between regulars.
In my opinion the Haskell community is friendly and an endless source of new ideas and concepts to learn from.
> if you are a fan of dynamic/gradual typing, objects, distributed systems, etc. do not expect a warm welcome.
I have not experienced this, but this might be because when I'm participating in the Haskell community I mostly talk about Haskell. I'm a fan of Python and Elixir, and haven't kept these facts secret as I've participated in the Haskell community (including a local meetup who's organizer is also a fan of Erlang/Elixir), and nobody has singled me out to bully me because of this. Nobody even notices.
> In my opinion the Haskell community is friendly and an endless source of new ideas and concepts to learn from.
This is also my experience! I received a very warm welcome when I first started with Haskell. You could ask all sorts of questions on #haskell and always receive great answers. The regulars were really happy when they were able to help you.
Also they were not dismissive at all in view of my background in dynamic programming languages. In fact, several members of the Haskell community were quite interested in Pugs, the experimental Perl 6 platform which we built in Haskell in those days, to the extent that they joined our effort and became committers. :-) There was quite a bit of cultural exchange happening.
Partly to pay back the kindness I received back then, and partly just because it's so much fun, I participate in free regional Haskell workshops. If you are located near Augsburg, Germany feel invited to attend! Details are at http://curry-club-augsburg.de/.
Conversely, if I am a fan of static typing and compile time constraints, should I expect a warm welcome pushing those ideas in Clojure and Ruby communities?
One should not be surprised that actively rejecting/attacking the core values of a community brings ire. Are you sure you weren't the one being confrontational?
Most communities are trash at accepting people who know, use, and don't mind multiple languages. I singled out Haskell because its community is exceptionally bad, not because all the other communities are good.
We could all stand to understand the totemism which pervades our science. Be mathematicians; be swayed by proof and logic. Be scientists; be swayed by empiricism and the scientific method. But stop being cultists already.
Clojure has the core.typed [0] optional type system! So yes, though they are dynamic, they embrace that others can differ.
> This work adds static type checking (and some of its benefits) to Clojure, a dynamically typed language, while still preserving idioms that characterise the language. It allows static and dynamically typed code to be mixed so the programmer can use whichever is more appropriate.
Some communities don't hold the dynamic vs static debate as an issue of such a hard regard that an individual must be rejected, lest they infect others.
matz has pretty much said that static type checking will not be part of Ruby, and he won't open up the syntax for it. But bugs like this one [1] aren't filled with hate, telling people to get lost. There's a constructive approach.
I am aware of those extensions. There is a difference between some features/extensions and core principles. If you want to play that game, Haskell supports ways to "add on" more dynamic behavior as well. One way is via -fdefer-type-errors [1] which allows parts of the program which do not typecheck to not impede the rest of the program.
But this is missing the point of core values. I will refrain from listing all the digs that Rich Hickey has taken at static types and their ilk, but he has done so quite a lot.. My point is both sides don't like their core values rejected. I thought this thread is about community and not extensions so much.
> bugs like this one aren't filled with hate, telling people to get lost. There's a constructive approach.
And there are many examples of haskell folks treating others with a constructive approach too on various topics outside of the "cannon". I'm not sure what you're implying here, or are if you're referring to a specific case (however, tallying up some cherry-picked anecdotes may not be so useful)
> I am aware of those extensions. There is a difference between some features/extensions and core principles.
Referring to a core library as an extension that isn't in line with core principles just sounds... Wrong.
> I thought this thread is about community and not extensions so much.
For something to be taken by the community, and willingly added to the core library, suggests a level of embracement within the community. Hickey himself weighed in on typed [0], embracing it with praise, despite the fact it may go against his personal values, he doesn't see it going against Clojure's values.
Static typing simply isn't a core value for Clojure. Thus:
> Conversely, if I am a fan of static typing and compile time constraints, should I expect a warm welcome pushing those ideas in Clojure and Ruby communities?
Absolutely.
> And there are many examples of haskell folks treating others with a constructive approach too on various topics outside of the "cannon". I'm not sure what you're implying here, or are if you're referring to a specific case (however, tallying up some cherry-picked anecdotes may not be so useful)
I agree, anecdotes here may be entirely unhelpful. Yet, I know I am not alone in saying that some of the haskell community is warm and embracing of newcomers, and yet there are also those that clearly reject newcomers, instructing them instead to learn mathematical concepts or the right words for the right concepts, and not guiding them to do so.
I did not say core.typed wasn't accepted by the Clojure community. It's great you have many examples of Clojurians extolling core.typed.
I said rejecting "core values", outright, would be met with resistance. Since Optional Typing via core.typed is a "core value" as you claim, there is no conflict. I want to be clear about what I'm claiming here.
> > Conversely, if I am a fan of static typing and compile time constraints, should I expect a warm welcome pushing those ideas in Clojure and Ruby communities?
> Absolutely.
Well, I think you're being disingenuous. After saying "Static typing simply isn't a core value for Clojure". If I claim in the Clojurians slack the value of what we agree is not a core value for Clojure, namely, ahead-of-time/compile-time static typing, yes, I think that would be met with some resistance.
Also, I hope you're not thinking that in this thread I have some problem with Clojure. I'm talking about sociology, not technology.
As a relative newbie to Haskell, the linked document contains a lot of information that I had wondered about but hadn't found definitive answers for (eg. Should I be using String at all?) as well as a wealth of information I hadn't even thought to ask yet. I suspect it's going to live in a browser tab next to Hoogle until I get a lot more experience.
Favorite line: "Playing "type-tetris" to convert between Strings explicitly can be frustrating." Such understatement! Converting between string types and dealing with the lack of scoping in records have been two major pinch points for me with Haskell so far.
Most puzzling part: The description of Erlang as an imperative language.
27 comments
[ 3.5 ms ] story [ 52.4 ms ] threadToday I use Racket and I won't go back but I am glad Stack is taking over Cabal.
It is not only Cabal, but also the constant churn in a lot of packages. For example, conduit was a great package when I used Haskell. But usually I had to update quite a bit of code when I would bump conduit up to the latest version after not touching a program for a year.
Maybe I have been unlucky enough to use Haskell during some transitions (pre-arrows -> arrows rule, let's use them everywhere -> arrows suck, basic IO monad -> iteratees, old fashioned field access -> various lens proposals -> lens). But I never used a language ecosystem before or after where things would change or break so often.
Luckily, Haskell's static typing coupled with the extremely helpful error messages of the compiler makes refactoring a cheerful task: If it worked before and all type errors have been fixed, then we can be quite confident that it works again.
Many areas have stabilized now. For instance, Edward Kmett's lens package is the de facto standard for all things related to records, getters, setters, and all those things on steroids. (Personally, I love how this turned out. Before lens, we quite frankly had the problem that field accesses were much more painful than they are in mainstream object-oriented languages like Python or Java. Nowadays field accesses are as simple as they are in other languages, and in addition to this we have the flexibility of composable first-class lenses.)
... by someone trying to actually address the issues. There are almost always wrong ways you can fix a type error. Fortunately, that's usually the situation at hand...
[0] https://nixos.org/nix/
I don't understand why it keeps receiving so much heat. What does stack do that cabal can't?
It's mystifying the Haskell community still hasn't been able to come up with a decent dependency management + build tool.
However, nowadays there is a decent dependency management and build tool! It's called "stack", as in "stack install xmonad". I never once had any dependency or other compile problems with stack. It simply always works. :-)
There's also an already-working-but-still-not-quite-finished alternative system within Cabal which is eventually gonna become the default one, and which does builds in a Nix-inspired way. I've been using that for the better part of a year now, and I like it far better than either historical Cabal or Stack: http://blog.ezyang.com/2016/05/announcing-cabal-new-build-ni...
Odd, I've been using stack in anger for a while now and have never had that happen. Have you reported a bug? Any ideas about reproduction?
https://www.youtube.com/watch?v=w_KY2I34-f8
First, Haskell is just another programming language. It has many papers written about it, and many people have strong opinions about it, but at the end of the day it is not that special.
Second, the Haskell community is not friendly and welcoming to many groups of folks. In particular, if you are a fan of dynamic/gradual typing, objects, distributed systems, etc. do not expect a warm welcome.
A personal anecdote: I left #haskell on Freenode because a regular and popular user proposed and endorsed an extended analogy wherein all humans are divided into "dynamically-typed" and "statically-typed" people, and statically-typed people are superior because they are more reliable. This kind of bias pervades the community and ruins any kind of cross-ecosystem collaborative efforts.
Edit: Was I being confrontational? I wasn't even part of this conversation! I was lurking, and I saw this ridiculous thing play out unprompted between regulars.
> if you are a fan of dynamic/gradual typing, objects, distributed systems, etc. do not expect a warm welcome.
I have not experienced this, but this might be because when I'm participating in the Haskell community I mostly talk about Haskell. I'm a fan of Python and Elixir, and haven't kept these facts secret as I've participated in the Haskell community (including a local meetup who's organizer is also a fan of Erlang/Elixir), and nobody has singled me out to bully me because of this. Nobody even notices.
This is also my experience! I received a very warm welcome when I first started with Haskell. You could ask all sorts of questions on #haskell and always receive great answers. The regulars were really happy when they were able to help you.
Also they were not dismissive at all in view of my background in dynamic programming languages. In fact, several members of the Haskell community were quite interested in Pugs, the experimental Perl 6 platform which we built in Haskell in those days, to the extent that they joined our effort and became committers. :-) There was quite a bit of cultural exchange happening.
The legendary #haskell troll attempt, recorded at https://gist.github.com/quchen/5280339, is worth reading.
Partly to pay back the kindness I received back then, and partly just because it's so much fun, I participate in free regional Haskell workshops. If you are located near Augsburg, Germany feel invited to attend! Details are at http://curry-club-augsburg.de/.
One should not be surprised that actively rejecting/attacking the core values of a community brings ire. Are you sure you weren't the one being confrontational?
We could all stand to understand the totemism which pervades our science. Be mathematicians; be swayed by proof and logic. Be scientists; be swayed by empiricism and the scientific method. But stop being cultists already.
> This work adds static type checking (and some of its benefits) to Clojure, a dynamically typed language, while still preserving idioms that characterise the language. It allows static and dynamically typed code to be mixed so the programmer can use whichever is more appropriate.
Some communities don't hold the dynamic vs static debate as an issue of such a hard regard that an individual must be rejected, lest they infect others.
matz has pretty much said that static type checking will not be part of Ruby, and he won't open up the syntax for it. But bugs like this one [1] aren't filled with hate, telling people to get lost. There's a constructive approach.
[0] https://github.com/clojure/core.typed/wiki
[1] https://bugs.ruby-lang.org/issues/9999
But this is missing the point of core values. I will refrain from listing all the digs that Rich Hickey has taken at static types and their ilk, but he has done so quite a lot.. My point is both sides don't like their core values rejected. I thought this thread is about community and not extensions so much.
> bugs like this one aren't filled with hate, telling people to get lost. There's a constructive approach.
And there are many examples of haskell folks treating others with a constructive approach too on various topics outside of the "cannon". I'm not sure what you're implying here, or are if you're referring to a specific case (however, tallying up some cherry-picked anecdotes may not be so useful)
[1] https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...
Referring to a core library as an extension that isn't in line with core principles just sounds... Wrong.
> I thought this thread is about community and not extensions so much.
For something to be taken by the community, and willingly added to the core library, suggests a level of embracement within the community. Hickey himself weighed in on typed [0], embracing it with praise, despite the fact it may go against his personal values, he doesn't see it going against Clojure's values.
Static typing simply isn't a core value for Clojure. Thus:
> Conversely, if I am a fan of static typing and compile time constraints, should I expect a warm welcome pushing those ideas in Clojure and Ruby communities?
Absolutely.
> And there are many examples of haskell folks treating others with a constructive approach too on various topics outside of the "cannon". I'm not sure what you're implying here, or are if you're referring to a specific case (however, tallying up some cherry-picked anecdotes may not be so useful)
I agree, anecdotes here may be entirely unhelpful. Yet, I know I am not alone in saying that some of the haskell community is warm and embracing of newcomers, and yet there are also those that clearly reject newcomers, instructing them instead to learn mathematical concepts or the right words for the right concepts, and not guiding them to do so.
[0] https://groups.google.com/forum/#!msg/clojure-dev/ryYzI1Bj0p...
I said rejecting "core values", outright, would be met with resistance. Since Optional Typing via core.typed is a "core value" as you claim, there is no conflict. I want to be clear about what I'm claiming here.
> > Conversely, if I am a fan of static typing and compile time constraints, should I expect a warm welcome pushing those ideas in Clojure and Ruby communities?
> Absolutely.
Well, I think you're being disingenuous. After saying "Static typing simply isn't a core value for Clojure". If I claim in the Clojurians slack the value of what we agree is not a core value for Clojure, namely, ahead-of-time/compile-time static typing, yes, I think that would be met with some resistance.
Also, I hope you're not thinking that in this thread I have some problem with Clojure. I'm talking about sociology, not technology.
Favorite line: "Playing "type-tetris" to convert between Strings explicitly can be frustrating." Such understatement! Converting between string types and dealing with the lack of scoping in records have been two major pinch points for me with Haskell so far.
Most puzzling part: The description of Erlang as an imperative language.