Well written code is obviously better than badly written code. But why assume the functional-style is better written than the idiomatic Python? I think a good developer understand the context they work in rather than try to fit a square peg in a round hole.

I wouldn't like to maintain Haskell code written by someone who thinks everything should look like Python. And vice-versa.

Python code doesn't have to be OOP to be idiomatic. That said, functional code that uses lambdas, map, etc. is generally not idiomatic Python. I've seen a lot get done just with functions, list comprehensions, and Python-specific magic without using OOP, though. Guess that's mostly just imperative on steroids, though.

> square peg in a round hole

Python is a multi-paradigm language. I have not found Python to be better at OOP versus imperative or functional styles of programming.

For me, functional programming provides a closer to model to how I think about problems. This is true for many people. One should choose the style that provides the easiest translation of thought to code.

If you only write code which you yourself will read and maintain, then you should definitely do whatever you feel works best for you and matches your way of thinking.

Python's lambda is very intentionally limited precisely to steer people away from overly functional code. Don't write Haskell in Python, and equally don't write Java in Python.

I believe it started as a way to model real-world object. Simula was designed for simulations. But OO turned out to be useful for much more. The simulation use case mostly live on in tutorial and examples, spreading confusion to beginners.

But I also think the "message passing" metaphor has outlived its usefulness the same way. A caller does not need to know how the callee is implemented. Sure, but this is the same in any language with functions/procedure, this is not something specific for OO. The idea of message passing is a bit deeper, for example that the client does not even know it is calling a method. It sends a message, and the object answers, even if it is just by throwing an error that the message is not supported. This is how Smalltalk and (I think) Ruby works, but not at all how a statically types language like C# works. And it is not how Python works either. In Python you obtain a method reference from an object and then invoke it. So if you apply the message passing metaphor, your are actually passing the message to the method rather than the object itself. Which I think is just a confusing way to describe a method call.

Haskell does not have borrowing and lifetime specifiers though, which is what makes the Rust example more dense.

Haskell has nice syntax for generics, no stupid <> to forward declare type parameters

It is somewhat unfair to compare this to Python, since a lot of the simplicity in Python comes from the semantics (dynamically typed, garbage collected and so on). Rust need to express all this information (types, lifetimes etc.), so it will necessarily be more dense. The question is if this information could be expressed in a more readable syntax. This might be possible, but I would like to see a suggestion of how.

I guess the signature could be made more readable by using a few type aliases. The hardest part to read is the nested types.

I'm with you on the macro syntax, it is very hard to read. It is not easy to create a readable macro syntax though. All languages I know have hard-to-read macros, so this is not yet a solved problem.

Here is a simpler syntax:

   fn accumulate tuples: &[(&'a Str, &Fn(i32) -> Bool)], i: i32 -> t
   where
        t: Monoid + From &'a Str + From String,

this is how Haskell with lifetimes and borrowing would look like (if arguments were not curried)

This is arguably less readable, because it's missing some delimiters for your eyes to latch onto.

It's also not realistically parseable- the Haskell/Ocaml-like removal of <>s and ()s relies on application being left-associative, and if you read this under that rule you've changed the meaning (e.g. `From &'a Str`).

I like removing superfluous punctuation, but if parentheses are removed from method signatures than they should also be removed from invocations, which in turn comes with its own set of readability issues. I'm not a fan of the $ operator in Haskell, for example.

This also reminds me that, in Python 2.x, the following code...

for i in range(100000000):

...creates in memory a list with one-hundred million integers.

Expressive yes, but sometimes it can be double-edged for new comers (and not new comers).

> The roman civilization used lead pipes for drinking water.

True, but the theory that this affected public health is a myth.

Do you have any supporting statements? I'm just curious.

Amazing that the same pet hypothesis can explain both rising and falling IQ.

So why is IQ increasing in the US while declining in Northern Europe?

Because in the US the IQ scores are taken more seriously than in Europe.

So why is this happening in Scandinavia but not in the US? Doesn't the US have just as many play stations and smartphones?

It's hinted in the article,

Basically, as this is an average for societies, the average environmental factors are better in Scandinavia than in America. But those factors already peaked, and now are starting a downwards trend:

>The authors note several possible factors, among them worsening health and nutrition, a decline in the quality of education, detrimental changes to media exposure, and the indirect effects of immigration.

OTOH, America's average environmental factors are still improving, so, it's still on the rise:

> It may be that, once we’ve made our schools as good as theirs, we’ll see our Flynn effect max out, and then whatever channels feed their anti-Flynn effect will show up in our data, too.

So again a pet hypothesis which can explain both rising and falling IQ. So what observation could theoretically disprove this hypothesis?

Note that you can state exactly the opposite hypothesis and still claim the numbers support it. The use of gaming consoles and smartphones improve IQ, but this effect have maxed out in Scandinavia.

Django is not going to be rewritten in Julia. Neither is Linux going to be rewritten in Python. Different languages have different domains. Some of these comments seem to think all languages is competing in the same domain as if Rust is a direct competitor to Julia or JavaScript.

The context of the comment I replied to was that Python was fantastic glue code _for scientific computing_. Julia won't won't impinge on Django's usage share.

Rust will not steal Pythons dinner, they are used for completely different domains. The comment was saying that Rust might be a realistic alternative to C/C++/Fortran for modules which are not written in Python.