[QuantumRoar]

Scripting languages try to seduce you to just fiddle around until the output looks like something you want. While that quickly gives you some results, I think it's a huge roadblock in the mid- to longterm. Especially when programmers are only familiar with "easy" scripting languages, there are rarely insights about the general approach to the problem until the project already grew to become an abomination.

While fiddling around is still somewhat possible in Haskell, the language itself makes it quite difficult. Haskell kind of forces you right at the beginning to pause and think "Well, what is it that I'm actually trying to do here?" It let's you recognize and apply common patterns and implement them in abstract ways without having to think about what kind of values you actually have at runtime. In that way Haskell is the most powerful language I know.

Have a tree/list/whatever? Need to apply a function to each of the elements? Make your tree/list/whatever an instance of the Functor type class and you're done. Need to accumulate a result from all the elements? Make it foldable.

Something depends on some state? Make it a Monad.

You either get a result or you don't (in which case any further computations shouldn't apply)? Use the Maybe Monad.

You need to compute different possible results? Use the List Monad.

Need to distinguish three different possible values that are different compositions of elementary types? Make yourself your own type and pattern match the behavior of applying functions.

Need to output in a certain way? Make it an instance of the Show class.

Most concepts that are used every day have some kind of idea behind them that is abstract and implementation independent. Haskell kind of forces you to reference those ideas directly. The downside is that you actually have to know about those concepts. However, knowing about the such concepts makes you also a better programmer in other languages, so it's not like it's a bad thing.

[munro]

Ability to fiddle isn't tied to static or dynamic programming, it's just every static language platform I've seen including The Haskell Platform neglects making it easier to fiddle.

When trying to build complex software in Haskell, I find myself spending a lot of time commenting/uncommenting swaths of code, just so I can get part of a algorithm to load in GHCi. It sucks. What I wish would happen is GHCi allowed me to load just the things that type check, and skip the rest, so I can fiddle. This is definitely possible. Not compiling is great for production, but not while developing.

Software is built in pieces, if I'm working on one piece, another statically unrelated piece shouldn't prevent me from working. In this regard Haskell GHCi (and many static languages), makes developing more complex than dynamic languages, but again it's not intrinsic.

I also wish when I run my tests, it listed all the type errors, as well as run tests on the code that do type check. Having more safety mechanism in Haskell helps with writing correct code, but compiling doesn't mean the code works. Automated testing is still more useful for writing software that works. Haskell isn't as safe as many people think [1].

    sort a = a ++ a  -- it compiles, so it must sort

[1] http://hackage.haskell.org/package/base-4.8.0.0/docs/Prelude...

[gmartres]

> What I wish would happen is GHCi allowed me to load just the things that type check

Use `-fdefer-type-errors` (should work with both GHC and GHCi), all errors become warnings, and if you try to use a function which was compiled with an error, you get a runtime error.

[DannoHung]

Thus perfectly illustrating Cunnigham's law.

[semigroupoid]

Of course compiling successfully does not imply a correct program with the desired behavior. Nobody claims that GHC is able to verify the behavioral correctness of your program and it also can't tell you if your function actually sorts a list or if it does not. However, if you claim in your definition of "sort" that it takes a list and returns a list, then GHC can verify if that is actually true. That is the power of types. They are no magic things that write correct programs for you.

[kaeluka]

IIRC, the Show class is supposed to be the reverse of the Read class -- so you should not use it to pretty print stuff.

[sordina]

It's not a pretty-printer. It's fine for printing stuff when you don't care what it looks like most of the time. Pretty printing is a vague term though. There are certainly many ways to pretty-print in Haskell, some of which are bi-directional pretty-printers/parsers.

[tel]

More typically, "Show" is whatever you want it to look like in the repl and "Read" doesn't get used. It's still useful for Show to be essentially Haskell syntax though so you can copy and paste into the repl.

[Tyr42]

This split was learnt from in Rust, and Rust has both the Debug class (which is the inverse of Read) and a Display typeclass for showing nice versions of things.

[QuantumRoar]

Yeah, technically I agree.

But I must confess, I used it in the past to have a convenient way to print out something like: 'Add "x" "y"' as "x + y". I didn't care about using read to turn it back into the internal representation since expression parsing is kind of difficult. I used Parsec instead. So I had show to output and a parser as the inverse.

[inglor]

A lot of things are supposed to work certain ways but in fact I never really used `Read` for anything more than reading simple user config in scripts. Usually my data is serialized/deserialized from more common formats such as JSON.

[hyperpallium]

Requirements Uncertainty: Fast iteration has many benefits - especially when you (or your client) don't actually know what's required ("agile"); and when what is required changes quickly, because of changes in competitors, customers, technology, regulation etc.

But you're right, as projects get larger, a priori design and static types quickly become essential. And at that point, requirements are usually known and frozen.

I predicted that the natural resolution would be languages with both (i.e. optional static types, especially at important interfaces) - but while this feature exists, it hasn't taken off.

Instead it seems that performance is the main attraction of static types in the mainstream (java, c#, objective-c, c, c++); and ML-family and Haskell are popular where provable correctness is wanted.

[tel]

To be honest, I think Haskell is the best language I know of for fast iteration as well. You can successfully create and manage far worse, yet working code when you've got a good type-driven guardrail. A common pithy quote, which I agree with wholeheartedly, is that "`IO` is the best imperative language out there today".

There's definitely a lot of missing documentation about this folk practice of "fast, loose, shitty Haskell" due to the strong culture of pretty code that's also enabled by Haskell. I remember seeing a video presented at CUFP that went into the merits here, though.

Essentially, this is a "tricky" concept because you want to design your types to be exactly as restrictive as you can afford without having to think too much. It probably requires a good grasp of the Haskell type system applied in full glory in order to bastardize it just right.

So, tl;dr?

I think types are the ultimate fast iteration tool, but this is not a well-documented practice.

[avmich]

"Civilization advances by extending the number of important operations which we can perform without thinking about them." A. N. Whitehead.

It's often said that a Lisp advantage is to be able to write sloppy - without fully understanding what's needed. I guess you can model that degree of "less constraints" in Haskell as well? Otherwise constant forcing "understand what you're doing" can sometimes be a burden.

[munro]

> ML-family and Haskell are popular where provable correctness is wanted.

Haskell doesn't have a theorem prover, you may want to check out Idris [1]. Haskell gives you more safety that you aren't going to get run time errors than say Java, but not completely. You'll still need automated testing for correctness, that you're not getting garbage in, garbage out.

[1] http://dafoster.net/articles/2015/02/27/proof-terms-in-idris...

[ffn]

Absolutely, Haskell has a richness of concepts to it that's entirely in a class of its own... but that being said, Haskell is to programming what sex is to life (for a woman... because men's natural enjoyment of sex throws off my following analogy). Granted there is richness and joy in finally discovering it, one needs to realize it's important that one isn't forced into it too early. Haskell demands a lot of thinking up front and therefore requires a programmer of a certain logical / organizational maturity in order for the process not to be frustrating and painful (or even traumatizing). Haskell (like C, Lisp, and the arcane slog known as Erlang) should rarely be someone's first language.

And that's where Ruby, Python, Javascript, and to some extent Matlab come in. For whatever else people may say about them later (they don't scale, they're a roadblock, they're a mess, null is not a function, etc.), they were there for you when you were programmatically young and they introduced you gently into a world that's otherwise extremely complex.

After all, programming, like literally everything else, is 99% human and 1% logic, machines, data, "scaling", etc. Programs are written by people for people (incidentally they can also be read by a computer), so it's incredible important that the 99% of that equation (you the programmer) don't become discouraged at the onset by an extremely elegant, expressive, but rather rapey language before you're ready for it. In that sense, it's absolutely okay to be "seduced" by an easy scripting language in the beginning. Eventually, though, when you start lamenting about "undefined is not a function" and how that could be so easily avoided when proper type-checking, that's your body telling you that you're ready for Haskell now.

[dragonwriter]

> And that's where Ruby, Python, Javascript, and to some extent Matlab come in. For whatever else people may say about them later (they don't scale, they're a roadblock, they're a mess, null is not a function, etc.), they were there for you when you were programmatically young and they introduced you gently into a world that's otherwise extremely complex.

Well, no, they literally weren't there for me when I was new to programming. (MATLAB existed then, but I wouldn't actually see it for more than a decade.)

And while I don't think they are bad languages for beginners, I don't see a clear argument presented as to why they are superior for that purpose (just a somewhat vulgar analogy that presumes that people share your subjective opinions about the languages involved.)

[autoreleasepool]

> (for a woman... because men's natural enjoyment of sex throws off my following analogy)

Pro tip: If your analogy needs a disclaimer that perpetuates gender stereotypes for it to work, then its probably sexist.

[gr8b8m8-88]

The parenthetical statement by ffn, although a bit tongue-in-cheek, is largely "men want sex more than women." Which, judging by the statistical consumption of porn across the world, is resoundingly true. I get your point about not perpetuating gender stereotypes, but the whole spirit of that movement (feminism, equality, what have you) is to not perpetuate gender stereotype types where they are irrelevant - as in when sex is not directly involved (e.g. leading a corporation, programming a computer, playing with children, etc.)... But you will literally not find a field where sex is more directly involved than sex itself. Granted there are always exceptions, but the statement that "man want sex more than woman" is sexist the same way "man is physically larger than woman" or "woman have higher % body fat than man" is sexist.

In other words, it's sexist in the sense that we recognize there is a biological difference between the sexes - we're not applying it to infer men are automatically rapists, or women are automatically unable to make executive decision. So maybe instead of playing around with labeling terms that carry a lot of negative connotations, you can actually consider the circumstance and context of what is being said before you label.

[throwaway232]

so men want sex more than women because of some statistic that you didn't even bother to fully pull out of your ass? nice

[gr8b8m8-88]

Here's a study (scroll to page 6 for the table):

http://www.hawaii.edu/hivandaids/Gender_Differences_in_Porno...

Now combine that with some data from Christian Rudder's Dataclysm (just a link to a info-pic + summary article here):

http://www.bloomberg.com/bw/articles/2014-09-04/mining-okcup...

Men consume a lot more porn than women and hunt for casual sex a lot more than women. Actually, if you weren't so rustled, you could've just google'd "consumption of porn by gender" and gotten a lot more results than the two I put up there. But yeah, way to not walk away and accept that someone else has a valid point, and feel free to continue loudly cry "no, your stats suck", "give more sources", while hiding behind a throw-away account and throwing out sensational accusations of "sexism!" for the sake of accruing karma on your main one.

[sridca]

Taking only graphic porn into consideration is a bias; women consume 'porn' in the form of romance novels.

"By and large, men prefer images and graphic sex sites; women prefer erotic stories and romance sites." - http://rescuefreedom.org/parallax/wp-content/uploads/2015/01...

[autoreleasepool]

For the record, that really isn't me. I didn't think your comment deserved a response so I ignored it. I don't have a way to prove it to you. Sorry.

[QuantumRoar]

I agree, except for the sex analogy. You could've easily went with something like:

Haskell is to programming what bugs are to food. Both are functional, an acquired taste and look scary from the outside.

[nbouscal]

> they were there for you when you were programmatically young and they introduced you gently into a world that's otherwise extremely complex.

This may be true for you, but it is not true for everyone. You assume that learning Haskell as a first programming language would be more difficult, but you don't present any evidence to support that claim. People who have done so disagree with you.

[imakesnowflakes]

>While fiddling around is still somewhat possible in Haskell, the language itself makes it quite difficult. Haskell kind of forces you right at the beginning to pause and think "Well, what is it that I'm actually trying to do here?"...

Wouldn't Scripting languages allows one to gradually build that understanding. Suppose you end up with a lot of complex code? Ditch it and build it from scratch. Usually takes around 1/10th the time it took first time with much better results.

So I think by the time one can think up and build the perfect abstractions in Haskell, one can write 3 or 4 iterations of the program in a dynamic language. Each time with better abstractions and neater organization....

[dllthomas]

In my experience, to borrow seanmcdirmid's terminology below, one can use Haskell as a "program to think" language - and in fact Haskell brings some significant tools to the table that I miss when I'm using Python to feel around a problem, to the point that I often choose Haskell for this. In both languages, writing small pieces of code and examining their shape and their output can be helpful in growing my understanding of the solution space, but I find that Haskell tends to let me ask more complete questions with less complete code.

[lallysingh]

No. The debugging time, refactor/rewrite time of writing in scripting languages is substantially longer, harder work, and distinctly unpleasant compared to just thinking and using good tools to do it right in Haskell.

In Haskell, I'll often have a problem and just stare at my laptop and think for an hour. Then write a dozen lines of simple, straightforward code. The code is easy to test, and the problem is marked as "solved" instead of "seems to work" as happens in scripting languages.

Edit: auto complete fixes

[biftek]

Pausing for an hour to think about and understand your problem is important in any language. Probably more important than testing honestly.

[lallysingh]

Indeed. I'd argue that strongly typed languages represent many problems in the type system, often letting you know very quickly that you'll have to spend that hour.

[Intermernet]

I now do all of my logic and data structure design on paper. It usually ends up looking like a series of incomplete sketches, as I very quickly iterate over wrong ideas that would have taken hours to discover if I'd coded up all the alternatives.

The final few sketches almost always end up simpler than the original idea seemed!

I also try to follow ESR's paraphrasing of Fred Brooks:

"Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious."

I think this concept is actually more important than the choice of language.

[ufo]

The nice thing about Haskell is that the type system lets you work at a higher level of abstraction. One of the problems with dynamically typed languages is that even though they let you create abstractions they are bad at error detection. For example, if you have a function that expects non-null inputs and you pass null to it the error is only going to be caught when you try to call a method on the null. On the other hand, in a statically typed language you get an error message poining directly to the real source of the issue.

Another othing Haskell gets right is the support for parametric polymorphism (generics). You are forbidden from manipulating generic parameters other than passing them around so there is less room for error. This "theorems for free" is what makes things like monads "tick".

That said, one thing that is in vogue right now is adding optional type systems and runtime contracts to scripting languages. Its still a bit of a research area but I think it has a very promising future.

[marcosdumay]

Different languages lead to different exploratory behaviors.

Haskell makes it very safe to change your code, but it adds some initial costs. Scripting languages make it very unsafe to change the code, unless you spend a lot of time writing tests, but then they stop being fast to iterate.

[jplahn]

I think that's an interesting point, _if_ people actually do that. That said, I'm wary of the claim of 1/10th time and being able to iterate 3 or 4 times per every one iteration with Haskell. Sure, maybe when you're starting out, but once you become proficient I don't think that would be the case anymore. And, there's no guarantee that 3rd or 4th iteration will be as good as the well thought out Haskell code, since the first iterations may be prohibitively complex.

[seanmcdirmid]

The point is that a scripting language is a "program to think" language, while haskell is often seen as a "think to program" language (at least when described as in the top level post). That you have to do more thinking and planning when using haskell (supposedly) doesn't help when the problem you are working on is not well understood and requires exploration (where you are forced to do exploration in your head...or on a whiteboard, rather than in code).

[mightybyte]

I strongly disagree. In Haskell the compiler helps me think a LOT more than other languages because it's checking more things for me. I don't have to explore things on the whiteboard, I can explore them in code and get very quick feedback about things I might have missed. I have built things in Haskell that I don't think I would have been able to build in other languages. The compiler is your friend, not your enemy. It's like having another developer there to bounce your ideas off of.

EDIT: Bottom line, I think Haskell also works well for people who "see programming as a cybernetic extension of their mind".

[seanmcdirmid]

I didn't make a claim, especially that claim. If haskell requires a lot of up front thinking, then it might turn off those who see programming as a cybernetic extension of their mind (using the computer to help you think, vs. thinking to use the computer). I do not know if the premise was true, but was made by the top level post.

[seanmcdirmid]

On your edit, I also didn't make that claim. All my premises are open.

[vilhelm_s]

I think part of it may be that it helps with thinking, but with a different kind of thinking than scripting languages?

There's that Perlis quote: "Show me your data structures, and I won't usually need your code; it'll be obvious". For me, a lot of thinking about programs involves thinking about the types of data involved, and there Haskell gives a language to talk about it. You can start writing down your datatypes, and the function types, directly in your emacs buffer (leaving the function bodies as just "undefined" at first). By contrast, if you are programming in some untyped language like Scheme, you have to do all that work inside comments---e.g. if you write a compiler you maybe start by writing a huge comment saying "this is the grammar I expect input expressions to follow". Having a type language around kind of helps by providing a notation.

I guess there is some other kind of exploratory thinking which untyped langauges provide a good notation for? But in my life I have mostly worked in typed languages, so I don't have any concrete idea of what it is.

[cousin_it]

The quote is from Fred Brooks (author of "The Mythical Man-Month"), and it goes like this:

> Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious.

I don't think it's about exploratory programming. It's more about reading other people's code.

[vilhelm_s]

Wow, I got that extremely wrong huh. Thanks for the correction.

[TuringTest]

> Wouldn't Scripting languages allows one to gradually build that understanding.

Lately I've reading this[1] academic paper about End-User Software Engineering. While not an easy read nor a good introduction if you've never read about End User Development, it delves precisely on methods for building tools that allow just that, while adding opportunistic checks to correct bugs.

[1]http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.360...

[thesz]

Haskell allow you to express algorithms in a more error-proof way.

For really complex things the implementation in scripting language can introduce errors that are catchable in typed language.

So you code your complex things, it fails to perform to expectations (but somehow performs, not just stack dumps). Where the source of fault lies, in the complex idea itself or in the almost whole source code?

My rule of thumb is that I write in Tcl/Python/Bash something that is not longer than 200-300 lines.

[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.

[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.