[eru]

Haskell, the prototypical careful language, defines their equivalents for 'any' and 'all' exactly like Python does it. And that's not an accident.

> That wasn't necessarily a choice, it may have just been an oversight not to deal with the "empty list" case.

If your general code gives you a answer for a corner case, it's a good hint that this might be a reasonable answer. Not a guarantee, though.

[gridlockd]

Functional languages tend to elevate some mathematical ideals before concerns of practical safety, performance or just common sense.

[eru]

On my cynical days, I'd be inclined to grant the latter two. But do you have an example of the first?

[gridlockd]

It boils down to the position that side-effects are actually totally fine when they allow you to write a simpler, more straightforward program, where state is easy to observe and debug.

Such code is less likely to contain obfuscated logical errors arising from an attempt to not break "functional purity". It has a chance to be practically more safe.

Another aspect is the way most functional languages treat memory. If you need a garbage collector, you effectively have to throw out hard realtime constraints. Latency and memory usage can be safety concerns. Most functional languages do not let you reason about that.

[eru]

Thanks for the answer!

Garbage collectors are used in most modern languages. Most implementations of garbage collectors don't give any real time guarantees. And neither do typical free/malloc implementations.

You can do functional programming without garbage collectors. Eg via linear types / uniqueness typing.

But the more general answer here is: whether your tool is appropriate depends on your problem.

Hard real time constraints are rare for most software. Most languages in widespread use don't support those out-of-the-box. Eg C certainly doesn't.

> It boils down to the position that side-effects are actually totally fine when they allow you to write a simpler, more straightforward program, where state is easy to observe and debug.

You know that eg Haskell allows you to write imperative code just fine? It's actually one of the more pleasant languages for imperative programming.

And it's pretty easy to get proponents of FP to admit that imperative programming has its uses. Much easier at least, than to get them to say positive things about Java-style OOP.

> Such code is less likely to contain obfuscated logical errors arising from an attempt to not break "functional purity". It has a chance to be practically more safe.

As I said most functional languages support imperative programming styles just fine. But, of course, your complaint remains more valid if you are redirecting it against certain functional programmers. Languages are tools to be used by people. Some of them more flexible, some more boneheaded.

[lmm]

> Latency and memory usage can be safety concerns. Most functional languages do not let you reason about that.

Most languages of any kind do not let you reason about that. You're not wrong, but neither is this some specific issue with functional languages. Indeed I'd say functional languages are at the forefront of trying to bring in ways to reason about those, with things like Linear Haskell or https://www.microsoft.com/en-us/research/publication/coq-wor...

[gridlockd]

> Most languages of any kind do not let you reason about that.

I might as well generalize my statement to:

"Programming languages tend to elevate some ideals before concerns of practical safety, performance or just common sense."

It just wouldn't make as much sense in-context.

[lmm]

> "Programming languages tend to elevate some ideals before concerns of practical safety, performance or just common sense."

That statement would be difficult to substantiate, particularly in the context of functional languages. Practical safety, performance, and common sense are absolutely priorities; the ideals that functional language design follows are servants of those goals, not the master.