The point of the article isn't to say that python is better, all it's saying is that a more functional style leads to cleaner code. This is irrespective of python's technical merits.

With a dynamic, functional language you could enjoy all of this simplicity. But you don't even need that to benefit from this perspective today! You can adopt the techniques of functional programming right now in your favorite language (such as Python, used above). What's important is your mindset and how you approach problems, minimizing state and maximizing clarity in the code you write.

I suspect the point of the article was to be seen again and remind people of his book.

Whether or not that is the case, surely the substance of the article more worthy of your analysis than something as intangible as the authors internal motivations? Assuming positive intent is worthwhile frame of reference that keeps my world looking a bit brighter and something I always hope other do for me.

Fair enough. My comment above was unnecessary.

I did elsewhere in a top level comment go into detail about why I thought TFA wasn't good. https://news.ycombinator.com/item?id=33722399

I agree that another language that's better for functional programming would make this more compelling. Python has a lot of limitations in this area. I think all of those alternatives you listed (Julia, Clojure, etc) include turn-offs for Python programmers that are deal breakers. So I'm seeking another language that appeals to Python programmers but has more of the attributes that are amenable to functional programming.

IMO, Ruby is a better general purpose "scripting" language like Python that has cleaner and more consistent features - including ones that lend themselves to functional approaches. Outside of web development it doesn't have the same appeal as Python due to the larger Python ecosystem... (many companies think they want to and will do "data science!")

Also, in my experience, Pythonistas tend to be more resistent to paradigm changes. So often I have heard, "Why would you want to do that?", or "This works fine as it is.". Not that I'm a fan of list comprehensions in Python (I think they're awkward and ugly compared to Ruby collection operations), but Python codebases I have had the displeasure of working in had lots of nested loops, mutations everywhere, copy-pasted code, and 30+ line methods. Trying to encourage single-responsibility, composability, less OOP, and more pure functions is like shoveling water uphill.

With both Ruby and Python you do need to be a bit thoughtful about unnecessary collection copies (which you would tend to favor when writing pure functions); but often you have a good sense of how large a volume of data you are handling and where copies will be particularly slow or heavy to do. When necessary, you can have an impure function that mutates input data, and at least in Ruby you can warn callers of the impending mutation by adding the ! to the function name. update_order!(order).