[1971genocide]

And what makes the model of haskell any more superior to models developed in any other field like accounting, physics or chemistry ?

I am sorry, haskell is just a huge roadblock to get things done in the real world.

In the real world proffesional need to juggle all sorts of models. Haskell just says "Fcuk you ! its my way or the gonadway !".

I need to juggle between json, matrix, html, etc. Each of them have hundreds of expections.

You can say my model is imperfect but guess what buddy, every model is. The only models that will work for all cases is prolly einstein's equations but even that has exceptions when dealing with blackholes !

I tried writing a music library in haskell and haskell makes it really hard to create rules that are expections to the model. Apparently the models developed by 1000s years of music theory is not good enough for haskell !

I cannot even image what it must to be code chemical rules using hakell that have hundreds of expections, or biologial models ! Oh My !

I am sorry haskell just gets makes computation much more difficult. Apparently mutation is a crime even though god himself thought it was okay as a rule for everything in the universe.

my anecdotal experience.

((

btw i really like the concepts in haskell. I read two of its famous books - LYAGH and RWH. And use all haskell concepts almost daily in production. However the implementation of haskell is not really ready for production or useful enough for the average developer. Its also not easy for the average developer to put food on the table using haskell

))

[agrafix]

I'm not sure what you where trying to do, but there's a whole chord recognition service written in Haskell: http://chordify.net/

Apart from that, I have written many production grade Haskell application, and I can not agree with you that Haskell is getting in the way. I admit that when learning Haskell I sometimes had that feeling too, but basically that was just me thinking about the problem too complicated or in a wrong perspective. Now that I am past that point Haskell is super fun to write, very productive and results in extremely maintainable code - it is just so easy to refactor anything you can imagine - and when it compiles again you are probably good to go!

[muraiki]

I'm curious to find out what problems you ran into in your music library, but I suspect you were downvoted because of your tone. That being said, the reason I'm curious is because there is an entire book about writing a music parser, renderer, and player in Haskell: http://haskell.cs.yale.edu/euterpea/haskell-school-of-music/

[boothead]

> Apparently the models developed by 1000s years of music theory is not good enough for haskell

Perhaps not, but Haskell is good enough for them:

  Functional Generation of Harmony and Melody http://dreixel.net/research/pdf/fghm.pdf

[psibi]

You might want to know that there is a book related to Haskell and Music: http://haskell.cs.yale.edu/euterpea/haskell-school-of-music/

[BasDirks]

And what makes the model of haskell any more superior to models developed in any other field like accounting, physics or chemistry ?

- Type-safety. Correctness. Speed.

I am sorry, haskell is just a huge roadblock to get things done in the real world.

In the real world proffesional need to juggle all sorts of models. Haskell just says "Fcuk you ! its my way or the gonadway !".

- I don't know what this even means.

I need to juggle between json, matrix, html, etc. Each of them have hundreds of expections.

- Haskell has great libraries for each of these.

You can say my model is imperfect but guess what buddy, every model is. The only models that will work for all cases is prolly einstein's equations but even that has exceptions when dealing with blackholes !

- models?

I tried writing a music library in haskell and haskell makes it really hard to create rules that are expections to the model. Apparently the models developed by 1000s years of music theory is not good enough for haskell !

- It just doesn't let you do it incorrectly.

I cannot even image what it must to be code chemical rules using hakell that have hundreds of expections, or biologial models ! Oh My !

- The more complex, the better Haskell is suited.

I am sorry haskell just gets makes computation much more difficult. Apparently mutation is a crime even though god himself thought it was okay as a rule for everything in the universe.

- Immutability doesn't make computation harder.

my anecdotal experience.

((

btw i really like the concepts in haskell. I read two of its famous books - LYAGH and RWH. And use all haskell concepts almost daily in production. However the implementation of haskell is not really ready for production or useful enough for the average developer. Its also not easy for the average developer to put food on the table using haskell

- You say you like these concepts, but it doesn't sound like you have the slightest idea what those concepts are useful for.

[steveklabnik]

> Haskell just says "Fcuk you ! its my way or the gonadway !".

I think it's more accurate to say that Haskell makes you annotate specifically which way you're doing it, and only combine ways when it's okay to do so.

[QuantumRoar]

I didn't try to say that Haskell is the best language for everything. I also wouldn't want to do everything in Haskell. But as you are pointing out, you learned a lot from Haskell and you are using its lessons in production.

The best a language can do is to fill a niche and to be very good at that particular thing. You should always use the language that is most suited for your problem, whatever that is. But there are many languages that let you get away with being a terrible programmer. Haskell just isn't like that and I want to point out that you can learn a great deal from being forced to think in more abstract ways, just like you did.

In programming, we often encounter the temptation to just mutate everything and to use side-effects since it's quite convenient to do so in the short-term. In the long-term, these things will come back and bite us. I argue that it is important that a programmer should have experienced what it is like to simply not have the option to do so. After learning Haskell, I tried to avoid side-effects in other languages as much as possible and to use them consciously. That was something I didn't even consider before learning Haskell. And, obviously, the less side-effects you have, the easier it is to maintain or exchange parts of your program.

I currently use Haskell to calculate probably a hundred analytical derivatives for a large sparse array that is used in a simulator written in Fortran. And it's very good at that. For quickly writing some evaluations of output of this simulator I use Python, because Python is better suited.

Pick a language based on the problem. Don't just use one language because you know it. In my experience, Haskell is very well suited for a lot of mathematical stuff.

------

Off topic:

By the way, Einstein's field equations will work for gravity in the classical regime, not in all cases. But still, if you simply want to calculate how far you'll throw a ball, you really should take another model based on Newtonian gravity or simply take a constant gravitational force. Planetary movements are also fine with Newtonian gravity (except when you really need it accurately. E.g. for the precession of the perihelion of mercury). However, GPS calculations are terribly inaccurate without general relativity (time flows differently if you are close to a big gravitational potential well). So, pick your model based on what you want to do, just like you pick your programming language based on what you want to do.

[krick]

> I also wouldn't want to do everything in Haskell.

Examples, please? And why?

[dllthomas]

Lack of dependent types? :-P

[jonnybgood]

I heard Haskell is a poor choice for real-time systems and numeric computation. It's kinda ironic that a language as "mathy" as Haskell is such a poor choice for doing actual math. Assuming these things are true.

[dmytrish]

This definition of "the real math" is quite arguable. Doing a lot of computations efficiently is a realm of modeling and statistics; that does not clarify the very nature of computation, the inner laws of formal systems. Haskell is much more about "what computation is" than about "how to do computations".

Besides that, from mathematician's point of view, "efficient numerical computation" is a necessary and useful practically, but very ugly thing. Speaking of C-like types `int`/`long`/`uint32_t`: they are only a crude approximation of natural numbers, they are a ring modulo 2n, which we pretend to use as natural/integer numbers, silently failing when this range wraps up.

And that is not the end of the story: for integer numbers we can at least specify what mathematical model describes them (a ring modulo some power of two), for floating point numbers it is impossible: set of possible IEEE 754 values is a very weird and irregular finite set of values (NaN, +Inf, -Inf, +0, -0, exponential distribution of points density with min/max bounds) with complex modes of failure. Associative law, distributive law, commutative law? The very equality check? Forget about it, floating point numbers have none of that.

[Retra]

Actual math is really a pain in the butt on any computer, in any language. Doing it all in binary efficiently is the problem.

[QuantumRoar]

If you have an array that fills a significant fraction of your memory (say, tens of Gigabytes), you don't have another choice but to use mutation (Haskell doesn't support that).

While quite fast, it is not in the league of low level programming languages. If you need ridiculous speeds, you don't have another choice but to use C, C++ or Fortran.

Python has a lot of very useful modules. If I can solve my problem with basically a few import statements and don't care about performance or anything, I find Python to be better suited.

Erlang's light-weight threads are a boon. Having a webserver written in Erlang and using Erlang as a server-side language, you can support a lot of sessions at once.

[carterschonwald]

i write incredibly mutation heavy code in haskell on a nearly daily basis. I've even added compiler support for doing hardware prefetch to the most recent version of ghc https://downloads.haskell.org/~ghc/7.10.1/docs/html/librarie...

there are many lovely mutable data structuers in haskell http://hackage.haskell.org/package/vector-0.5/docs/Data-Vect... is one for unboxed C-struct style arrays,

http://hackage.haskell.org/package/hashtables is a super mature stable mutable hashtable library, that is used, among other places, in agda!

..... please fact check your feelings in the future :)

[QuantumRoar]

Sorry. I seriously didn't know. I only ever used the immutable parts of Haskell. Thanks for the correction.

[dllthomas]

Haskell does support mutable arrays. Your code that does the mutating will have to live in IO (or perhaps ST), but the downsides of that are exaggerated.

[QuantumRoar]

Oh. I didn't know that. Thanks for pointing that out.

[dllthomas]

Haskell strikes many as "bad for mutation" because introductory tutorials don't really cover it. This is because 1) mutation is not terribly idiomatic, 2) relying on mutation often (not always) a bad design decision, 3) Haskell handles the immutable case really well, and 4) mutation involves some more complexity than is involved in other languages. All of these are good reasons to avoid talking about mutation in a beginner Haskell tutorial, but when you need to address a problem where mutation is the best fit you'll find that it actually works pretty well. Haskell doesn't make mutation difficult, it makes it explicit, which has upsides and downsides.

[wz1000]

> If you have an array that fills a significant fraction of your memory (say, tens of Gigabytes), you don't have another choice but to use mutation (Haskell doesn't support that).

Haskell does support mutation, it just requires it to be controlled. Take a look at Data.Array.ST and Data.Array.IO

> Erlang's light-weight threads are a boon. Having a webserver written in Erlang and using Erlang as a server-side language, you can support a lot of sessions at once.

GHC provides a very similar thing in the form of "green threads".

[dragonwriter]

> If you have an array that fills a significant fraction of your memory (say, tens of Gigabytes), you don't have another choice but to use mutation (Haskell doesn't support that).

Haskell supports mutation, although many short tutorials don't address it and even many longer tutorials don't do much with it.

[Tyr42]

I mean, there are Data.Vector.Mutable, though I haven't needed to use them yet.

[tel]

I've personally found it very easy to handle "exceptions" in Haskell. Partial answers feel "bad" in Haskell because all the core functionality is clean enough to not need them, but on the other hand that makes for some of the best tools around for dealing with partiality.

[JadeNB]

> Partial answers feel "bad" in Haskell because all the core functionality is clean enough to not need them

Not to need them, sure, but not not to use them. (I swear that's the right number of 'not's.) I don't understand why something like Neil Mitchell's `Safe` isn't just the way that things are done by default.

[tel]

Ugh, yeah, total agreement here. Historical accident, I suppose. I try to pretend like `head` and `tail` just don't exist.

You can always recognize a file where I'm doing list ops because I define `uncons :: [a] -> Maybe (a, [a])` at the top of the file, haha.

[mightybyte]

Even better than safe, all this has been consolidated very nicely in the errors package.

[4ydx]

I would assume that anything that has an underlying pattern would be describable with Haskell. It is a functional programming language after all. If you are not very mathematically savvy, it might not be for you.

[bigpeopleareold]

I am learning Haskell. Could you describe an example/s of Haskell and music theory not working together? I am genuinely curious about this.

[michaelochurch]

I am sorry, haskell is just a huge roadblock to get things done in the real world.

Languages tend to suffer from an Iron Triangle: quick to write, quick execution, quick to learn-- pick 2. Haskell takes a long time to learn but it produces very high-quality executables and, once you know it, it's very productive.

While "quick execution" may seem separate from the type safety which is also a major selling point of Haskell-- and, arguably, a bigger one-- they're actually tightly coupled. Safe code can be optimized more aggressively, and it's often for the sake of performance that unsafe things are done... so the fact that Haskell can be robust and generate fast executables is a major win.

Haskell just says "Fcuk you ! its my way or the gonadway !"

It doesn't, but I am going to start saying this. Thank you for the inspiration.

Apparently mutation is a crime

Not so. Every program's main method has type signature IO (), which means that it does perform mutation. You just want to get as many functions as possible not to involve mutation because it's easier to reason about them. It's a similar principle to dependency injection, but more robust and clear.

However the implementation of haskell is not really ready for production or useful enough for the average developer.

I disagree. With Clojure and Scala, I've met people who've used them and moved away. Satisfaction rates seem to be about 60% with Scala (that is, 60% of teams or companies that make a major move to Scala are happy) and 90% with Clojure. I've never heard of anyone who's become unhappy with Haskell or rolled back on it.

One of the dangers of using Scala, for an example, is that, if that if your Scala deployment doesn't work out (or is sound but is blamed by the business for something unrelated) you can get stuck doing Java. Haskell, at least, doesn't have that problem.