The dependency hell situation has vastly improved (and there are plans to make it much better still).
I agree that a downside of Haskell's very high level nature is difficulty to predict some runtime characteristics. This is just an instance of the general trade-off between low-level and high-level languages. Everyone is already comfortable with the loss of easily predictable performance incurred by GC, but people are still not comfortable with the same w.r.t laziness.
I use Haskell for real world projects, and I find it more practical and more suitable than any other language I've ever used. Laziness rarely bites me, and has incredible real-world benefits such as easy refactoring and simpler code.
I think the silliness about PhD's is very very silly. Of the Haskell programmers I know, the majority don't have a first degree...
About profiling -- I have never profiled a Scala/Java application, but how much easier is it compared with: "cabal configure --enable-executable-profiling", and then running the program with "+RTS -p"? It may not be point-and-click, but it really is not hard at all.
>I think the silliness about PhD's is very very silly.
Of course it is. I just wanted to make a point that the "average programmer" has probably never seen a single line of ML-syntax before.
>About profiling -- I have never profiled a Scala/Java application, but how much easier is it compared with: "cabal configure --enable executable-profiling", and then running the program with "+RTS -p"? It may not be point-and-click, but it really is not hard at all.
I don't remember exactly what we tried, what worked and what didn't; we had no experts on the team, and just came to the conclusion that hooking up jconsole/yourkit/<insert jvm profiler here> to a running jvm process and see what's happening in real time on an app server was so much more comfortable.
It's still bad and cabal is still bad. I was in #haskell on IRC not too long ago and they couldn't even figure out why a haskell-platform install couldn't upgrade its own cabal with no other packages installed.
Your propagandizing is either based on very insulated anecdote or you're being disingenuous for the sake of promoting your favorite language.
The salesmanship does not help Haskell and sets expectations poorly. Fix ghc-pkg and cabal!
Clojure and Go make this look ridiculous and unnecessary.
N.B. Been using Haskell off and on for 3 years. Never once has it not been a pain.
I am not saying cabal is perfect, but the situation has dramatically improved since the prevention of spurious reinstalls. It also seems that hackage uploaders are playing nicer these days, and I just generally get far less breakage.
Lots of work is being done on Haskell's package system to make it better.
I've been using Haskell for 5 years. It used to be very painful. It is only rarely painful these days.
Experience comes into it too, but as I mentioned earlier, they mostly fixed the "butteryfly problem" by avoiding spurious reinstalls. The butterfly problem was the source of at least 90% of the pain relating to cabal installations.
They are also going to allow multiple installations of the same package version with differing dependencies very soon, which will help alleviate some of the final problems still there with cabal.
I do think that it is not my relatively smooth experience that is the anomaly, but your unsmooth recent experience. Perhaps your installation was somehow borked? Perhaps you were trying to install new packages using a very old "cabal-install" that still had long-fixed issues?
If you just install the newest Haskell Platform and run "cabal install cabal-install" that does work on Linux. For Windows, IIRC, you also need to install cygwin/mingw (well-documented) and then it is a smooth install as well. I don't know about OS X but it is generally smoother than Windows.
Can you describe in more detail the actual problem you encountered?
No, it isn't. You have the exact same problems with CPAN and everyone and even the most devoted perl-haters will admit "perl is a terrible language, but CPAN is amazing". You run into the exact same problems with every other language, the only difference being dynamic languages tend to be lazy about correctly managing version numbers, so you get "installs properly but completely breaks my app" instead of "tells you it can't install because of a version conflict".
>I was in #haskell on IRC not too long ago and they couldn't even figure out why a haskell-platform install couldn't upgrade its own cabal with no other packages installed.
Well obviously, since it does in fact work just fine, it is quite difficult to figure out what weirdness that individual did to create his problem.
I don't use Perl and that's a crock anyway. I've used Leiningen on Clojure, easy_install/pip on Python and the Golang stack happily with no trouble. I don't like XML or Java, but you'd have a hard time arguing Maven "doesn't work". It's what Leiningen is built upon anyway. Rubygems, rbenv, and bundler aren't perfect but they do largely work for everybody in the Ruby community. Quicklisp has done a lot to improve the state of affairs in Common Lisp and made it pretty easy to use arbitrary libraries.
It's ghc-pkg/cabal on Haskell that have been a pain in the ass. Even sbt on Scala is better and that sucks too.
Cut the tu quoque bullshit, not everybody has a crappy ecosystem. Those that don't, don't because they didn't project a reality distortion field so they could pretend everything was hunky-dory.
Python used to have serious packaging problems. It got over them and eventually became a smooth experience because people recognized the problem and worked on it.
Clojure without Leiningen was horrific. Hagelberg's work there was amazing.
The Golang team has taken things like this seriously all along and since 1.0 a lot of things have been standardized.
Stop denying there's a problem. I'm far from the first person to mention the Haskell ecosystem need works.
The REAL irritation isn't with just ghc-pkg and cabal, but rather that I keep running into crazed partisans like you that won't admit there's a problem. You're the problem.
Nobody's pretending that everything is "hunky-dory" with Cabal--there are concerted efforts at fixing the problems, and discussions on it come up often both on the mailing list and on /r/haskell. However, some people are pretending that it's worse than it really is. It's not perfect, but it's certainly not bad enough to not use Haskell!
I remember having annoying problems with Python--both easy_install and pip--just a year ago. Perhaps it's better now, but that just means packaging issues can be fixed. And, for Haskell, people are fixing them.
>It's sbt on Scala and ghc-pkg/cabal on Haskell that have been a pain in the ass.
And yet scala people will tell you sbt is totally fine and has no problems. Just as you pretend pip has no problems, and go has no problems, despite it being trivial to get package conflict errors in both of those.
>Cut the tu quoque bullshit, not everybody has a crappy ecosystem
No, not everybody does. You just pretend a couple do because you have an irrational dislike for those particular cases, while ignoring the fact that they are actually equally good to the languages you do like.
>Stop denying there isn't a problem. I'm far from the first person to mention the Haskell ecosystem need works.
True. And because the haskell community is tolerant to a fault, they humour trolls like you, and try to find ways to make a perfect packaging system. But the reality of course is that all the packaging systems are 95% identical, and the 5% isn't making a difference.
>My REAL isn't ghc-pkg and cabal, but rather that I keep running into crazed partisans like you that won't admit there's a problem. You're the problem.
Yes, obviously I broke your packages and made you troll haskell articles like a petulant child. I had nearly forgotten about doing that, I am quite sorry. To make it up to you, I'll let you give an actual, real example of a problem cabal presents that doesn't happen with python. Ready? Go!
Could you elaborate what 'real-world' means to you in this context? Millions of users, hundreds of servers, a personal blog? 'Real-world' is often a very broad term with a huge likelihood of misunderstandings.
Serving my real needs both for a professional job:
* Debug information processing and analysis
* Concurrent execution of tests
* Build systems
* Various automation/scripting needs and other auxiliary projects
Also, in a different context, a structural editor for programming based on our own GUI framework (~10KLOC so far). This project is still preliminary but advancing at a (mostly) steady pace.
The dependency hell situation has vastly improved (and there are plans to make it much better still).
I agree that a downside of Haskell's very high level nature is difficulty to predict some runtime characteristics. This is just an instance of the general trade-off between low-level and high-level languages. Everyone is already comfortable with the loss of easily predictable performance incurred by GC, but people are still not comfortable with the same w.r.t laziness.
I use Haskell for real world projects, and I find it more practical and more suitable than any other language I've ever used. Laziness rarely bites me, and has incredible real-world benefits such as easy refactoring and simpler code.
I think the silliness about PhD's is very very silly. Of the Haskell programmers I know, the majority don't have a first degree...
About profiling -- I have never profiled a Scala/Java application, but how much easier is it compared with: "cabal configure --enable-executable-profiling", and then running the program with "+RTS -p"? It may not be point-and-click, but it really is not hard at all.