Haskell

dunno about Haskell, but in general functional languages need a dedicated "functional" hardware to truly shine. Emulation overhead on a "C" hardware is just too big.

Also something something programmer's time is more expensive than computer's time something something

...

"Functional" hardware is slower at running functional languages than normal hardware. When they said Lisp machines were slower than PCs and Macs, they meant Lisp programs on Lisp implementations that ran on PCs and Macs were faster than the same programs on Lisp machines, not assembly programs or whatever you might be thinking. Bet your special ed professors didn't tell you that. Did you hear of Microsoft LISP? I wonder why they don't make that one anymore.

We don't use "C" hardware, dumbass. "C" is why we can't use our hardware to its full potential.

Just like prison buttsecks.

I've always liked the mental masturbation that is required by functional languages.
Which functional languages has the best standard libs and external libs? Is there any one that is as multipurpose as something like python?

post the code for that.

You seem to know a lot about it

Racket, but as it's name suggests, It's a racket and not purely functional.

In haskell this is 2 milliseconds slower but uses less memory than C++, on my machine:

mapM (putStr . (\x -> show x ++ " ")) [1, 3 .. 99]

The thing about Haskell is that it's a playground for mathematicians, and it sacrifices a lot of ease-of-use to be purely functional.

That being said, Haskell can be a lot more intuitive for problems that are heavy on the mathematical side, but it can be really counter-intuitive with things that are usually easy, like IO.

Haskell is "bad" because it doesn't solve the problems anyone has and makes up problems people don't have.

For example, they say "there's an IO problem" and the FP community spends more than a decade trying to find out what the problem was and how to solve it until eventually rediscovering the procedure (IO) and reference (IORef) types which are now acceptable FP.

It's also "bad" because of their tendency to blame paradigms for problems in other languages. They say "because it's an imperative language" or "that's how OOP is" instead of "that's a C problem" or "that's a Java problem."

wrong

Why do you talk about things you don't understand on the internet?

Why do YOU talk about things you don't understand on the internet?
The IO action is known as a procedure in other programming languages.

just use Rust instead

haskell a shit
ecosystem churn
two competing package managers, one is official and the other is ran by (((an Israeli company))) to steal the community.
installing multiple compiler versions is a pain
bitrotting packages
no books

FP is great, Haskell is not. It's a cool academic toy, not for actually getting shit done.

Also ML style languages ⊆ FP

If you are going to cite benchmarksgame as a source, at least compare the language people are discussing to what you are shilling. Haskell is faster than NodeJS according to your own source:

benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ghc&lang2=racket

Wrong link, sorry I was comparing CLisp and Racket to Haskell. Here's the correct link:

benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ghc&lang2=node

Which FP language is great?

Not him, but OCaml and F# are far less cancerous. Elm as well, but it's frontend only. However it's probably the best frontend language bar none.

Not only do the packages bit rot, every fucking autist designs their own syntax for their library. I got into haskell big league a few years back, and I had all sorts of customs dsl's for sql and web page templating. Shit was so cancerous I became a schemer for the homogeneity.

Because people who have been using for loops for their entire life suddenly feel "enlightened" when they learn about map, reduce, concat, and the other functions that exist in the list-applicative toolbox. 90% of "best-practice" Clojure code is either using the thread-first or thread-last macros, or processing everything inside a giant let binding, which is to say, trying to operate imperatively inside a functional paradigm.

The thing is that you can do all of this stuff in Javascript or LISP, and to some extent, python and ruby. While JS and Lisp have their downsides, they have the most sensible blend of "functional" and "imperative" features without incurring too much of a performance loss over Sepples. You don't have to go fully autistic and zealously crusade against state as if it's the ultimate evil. While ML-syntax makes some algorithms look "elegant," it really makes casual hacking a hell of a lot harder because it's far easier for human brains to think about a complex operation as a list of stateful transformations rather than as one big expression. Unless you have a very good reason for being "purely functional," it's better to choose a language that lets you just imperatively mutate state.

Ada shouldve taken over C and C++ ages ago.
US Government funded and helped to develop it to replace all its program languages.
(its military grade reliable)
But it didn`t happen and even the gov started using off the shelf stuff decade later.

Agreed, it's also impractical from a development standpoint most of the time. Imagine you're trying to make a Facebook clone. How the hell would you handle something like posts/likes/etc without maintaining some kind of state? I mean sure you could have a bunch of functions which hook up to a data structure that represents the state of a post, but that's ultimately just a different kind of state machine.

Not only that, but the functions would get so unwieldy so quickly. So you'd have a like function which gets passed into a post function which gets passed into a feed function, etc. It'd be a nightmare to maintain.

There's an active community behind MLP as well.

That said, I'm interested in trying it out some time.

It's not a procedure in Haskell, if you knew what you were talking about you would at least bother to mention that IO effects are composable expressions.