I would not worry too much about rankings like that. What Haskell community should worry about is producing nice empirical software engineering research about usage of Haskell in practice, especially about development vs. maintenance cost for long term projects. It's easy to "learn" and develop something in JavaScript/Python/Java etc. It's much harder to evolve the software when there's sparse documentation and after team members leave (which is the most common situation). I'd say that compared to Haskell, JavaScript and Python codebases are "unmaintainable" in the long term. It's like walking on a mine field, pretty much. I know that doing such studies is very costly but some quantitative evidence should trickle down from the field. I have one anecdotal story to tell. I was doing a very extensive change in my project. It was huge. I approached a change a few times, trying to minimize it but as I was performing the change I was learning a lot about the codebase (I am a maintainer, other people wrote it) with the help of the compiler. You try it and you see the impact. Finally, I found a good way and implemented the change. Once I got it to compile again, one test case failed. I quickly identified the bug I introduced during the change and fixed it in 10min or so. After that, all my test suites and regression tests passed. All that without going through lots of manual testing/debugging/etc. Since then, no new bugs related to that huge change were found. That is the kind of power Haskell provides and we need more stories like that. Cheers, Michal On Fri, Apr 17, 2015 at 9:44 AM, David McBride wrote:

I wouldn't put much stock in tiobe. They change their algorithm regularly and they apparently did something drastic this month.

As for haskell, I have never seen as many job offers for haskell developers as I have seen in the last few months. I do think scala is more popular than haskell in industry, but not by as much as tiobe seems to think at this particular moment.

On Fri, Apr 17, 2015 at 9:21 AM, Gregory Guthrie wrote:

...

I find that Haskell has a very different learning curve from other languages that I use/know/have-tried, in that the basic language itself is very simple and easy to learn and appreciate. However once one starts using a lot of monads and applicatives and other libraries, it can begin to look more like APL.

...

...

...

parser >>= >>> ( \s -> return ( pl' {

P.payloadData = setField pld (Just s) } } ) )

Certainly one can learn to parse and read this, but with all of the new operators and thus syntax not familiar to standard IP language users. (Not a complaint, just an observation from teaching this to students new to FP.)

And in my experience the cabal problems are the "fatal-flaw"; it is not infrequent that I have had to delete all libraries and start over, and I have only very simple usage. I would not want to have a business project that depended on this, as often I have not found a good solution where I could install all the packages I wanted. (Perhaps I just need to learn more about sandboxing techniques.)

I am not a fan of the Scala syntax, but it does seem to be an easier transition because it look-and-feel's more like the typical IPs.

-------------------------------------------

...

-----Original Message----- ...

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

I work with a lot of Haskell beginners and the Cabal problems went away when sandboxes were added to Cabal and the learners started using a sandbox for every project. I've only seen a handful (one hand, 5 fingers) of problems since then that weren't attributable to, "wasn't using a sandbox". Of those, about half were the user doing something uncommon/unusual. I have a tutorial here http://howistart.org/posts/haskell/1 which among other things, covers the basics of using sandboxes. Library maturity is my only worry with production Haskell. Not enough eyeballs and all that. It's not enough to stop me or my colleagues using it in production though. I can fix libraries, I can't fix Scala. On Fri, Apr 17, 2015 at 1:21 PM, Joe Hillenbrand wrote:

...

On Fri, Apr 17, 2015 at 6:21 AM, Gregory Guthrie wrote:

And in my experience the cabal problems are the "fatal-flaw";

Big +1 here. Cabal is the biggest thing keeping me from aggressively promoting Haskell in industry. The risk of promoting Haskell now is that people will try out Haskell, hit a cabal issue, give up, and then form a bad opinion of Haskell because of it.

There is saying "If a user has a bad experience, that's a bug."

I've been patiently awaiting the Backpack overhaul before promoting Haskell in the workplace. [1]

[1] https://ghc.haskell.org/trac/ghc/wiki/Backpack _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Sandboxes are really a bandaid and most tutorials don't promote them enough. You can also still hit the multiple package versions issue in a sandbox. The lack of "cabal upgrade" is another big headache. On Fri, Apr 17, 2015 at 11:29 AM, Christopher Allen wrote:

I work with a lot of Haskell beginners and the Cabal problems went away when sandboxes were added to Cabal and the learners started using a sandbox for every project.

I've only seen a handful (one hand, 5 fingers) of problems since then that weren't attributable to, "wasn't using a sandbox". Of those, about half were the user doing something uncommon/unusual.

I have a tutorial here http://howistart.org/posts/haskell/1 which among other things, covers the basics of using sandboxes.

Library maturity is my only worry with production Haskell. Not enough eyeballs and all that. It's not enough to stop me or my colleagues using it in production though. I can fix libraries, I can't fix Scala.

On Fri, Apr 17, 2015 at 1:21 PM, Joe Hillenbrand wrote:

...

...

On Fri, Apr 17, 2015 at 6:21 AM, Gregory Guthrie wrote:

And in my experience the cabal problems are the "fatal-flaw";

Big +1 here. Cabal is the biggest thing keeping me from aggressively promoting Haskell in industry. The risk of promoting Haskell now is that people will try out Haskell, hit a cabal issue, give up, and then form a bad opinion of Haskell because of it.

There is saying "If a user has a bad experience, that's a bug."

I've been patiently awaiting the Backpack overhaul before promoting Haskell in the workplace. [1]

[1] https://ghc.haskell.org/trac/ghc/wiki/Backpack _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On 17-04-2015 20:47, Joe Hillenbrand wrote:

Sandboxes are really a bandaid and most tutorials don't promote them enough.

They *are* a bandaid, but a reasonably well-working one. Hopefully we'll an even more robust Nix-like approach soonish: http://www.well-typed.com/blog/2015/01/how-we-might-abolish-cabal-hell-part-... (there's a link to part 1 at the start if you haven't read that) That doesn't solve the diamond dependency problem, but hopefully there'll also be a solution for that at some future point in time (Backpack). I'll also note that I personally don't know of *any* software platform that has actually solved this problem entirely satisfactorily. On the JVM, OSGi gets close (at least in theory), but AFAICT it's a lot more complex that it (ideally) should be.

You can also still hit the multiple package versions issue in a sandbox.

Indeed, but my personal experience is that it actually doesn't happen very much in practice. (Anecdotal, I know.)

The lack of "cabal upgrade" is another big headache.

Meh. Speak for yourself! :) Personally I'm more interested in repeatable and consistent package installations rather than avoiding 30 minutes of 100% CPU usage once in a while. (Of course, priorities may vary and reasonable people can disagree!) Regards,