Hello, most of your points seem wrong in the extreme and I feel like addressing them. I confess I pressed the enter key hard a few times as I wrote this, gritt

Hello, most of your points seem wrong in the extreme and I feel like addressing them. I confess I pressed the enter key hard a few times as I wrote this, gritting my teeth at some of your points. But I have tried to keep a level tone to help people see that many of these points either are simply FUD or, in a few cases, haven't been true for well over a decade. But, first and foremost, it's very clear you've conflated Haskell (and perhaps Purescript?) with all functional programming. This is a mistake, and many functional languages do not make use of pure functions, laziness, monads, or algebraic data types. > - it tries to abstract away von Neumann architecture and make it more math-like, stateless, true and permanent. Yet von Neumann is completely stateful (resembling real-world in its complexity and model approach), Most languages abstract away von Neumann architecture to some point. This is generally seen as a feature, as the notion of "von Neumann" itself has evolved substantially over time such that many historical practices are no longer meaningful (example: overlays). For the last 2 decades, it's been considered Industry Best Practice to do this, as we're increasingly finding we don't want the limitations of this classical architecture to limit our computations or computers. For example, it's quite easy to push computations to GPUs or TPUs in Haskell because by default it doesn't force assumptions onto users about what state means. > causing all kinds of frictions, for which monads and other syntactic sugar were invented No, Monads were not invented to solve this problem in Haskell. They were a subsequent improvement to the original solution. > while Turing complete, it has some weird properties, making it difficult or inefficient to change communication between various components that are using deep function calls when such a need arises in the future. This is quite untrue. And if it were true then it's quite a curious chain of events that functional composition has only become more mainstream and relied upon in many languages, and before the proliferation of closures and functional composition frameworks and techniques (e.g., Dependency Injection) came into being to model the kinds of interactions composed functions make natural. > This leads to using mutable "shortcuts" that render a lot of advantages functional programming might have had useless and starts resembling imperative/OOP programming with its issues again I am surely not alone in having no idea what you're talking about other than perhaps the occasional use of unsafePerformIO in haskell, but even then. > - trivial things like IO can't be modeled without side-effects, so any software requiring input from keyboard, loading external files etc. can't be pure Monads are a way of modeling impure computation purely. And IO is a side effect. It's absolutely wrong to suggest the IO monad is some short of shortcut or inherently impure, or that it's deficient in any way compared to a block of Javascript for modeling the real world. None of that is true. > - often functional constructs make code unreadable despite readability being one of the main reasons for its existence This is a matter of opinion and training. One could make the same argument of React/Redux reducers (really, the state transitions are in the actions?), Google's Guice DI framework (what is happening), or elaborate builder-notation spec framework tests. Most people will find languages like Clojure or Ocaml pretty familiar. What I will agree with is that languages that more closely model referential transparency tend to appeal to some tools modeled after category theory that require up-front study to really understand and apply. Most languages have one or two things like this: Ruby has proc vs block, Python has many arbitrary restrictions and list comprehensions, C has pointers, C++ has generics, Java has reflection, Javascript has callbacks, Haskell has Functor->Applicative->Monad. > - bottom-up creation of algorithms is preferred by many language authors, making it difficult for beginners This has nothing to do with FP and everything to do with programming in a modular fashion. Every language with modules naturally leads people to bottom up styles. That includes Javascript. > - if you really want to know how it works, it takes 5+ years PhD level of studies in abstract math The Haskell compiler is a big, complex piece of work. But so is the C++ compiler, the Java JVM is surely bigger, the CLR is fantastically complex, and have you ever looked at some of the bugs in the Python interpreter? Of course it takes dedicated study to understand a modern compiler. That's only natural. > Disclaimer: I approach 100 languages I've used in production, Okay. 100. > worked for companies that created some of the most popular languages and hate them all Who? Maybe we've worked together. > I hope to work on AI-assisted language creation in the near future. You're very late to the starting line here.