All of your points make great sense in theory, but in practice it rarely works out so smoothly.
> If it's an abstract data type, it doesn't have to be understood by the caller, it just has to be passed to another "lego brick" which understands the abstract interface. If it's a structured data-type, then there's no reason why it shouldn't be understood by the caller, the type should tell you how to consume it.
And this is exactly how any well constructed OO API works as well.
You can have really good and really bad APIs in any language, it really is up to the skill of the developers. I firmly believe that, there’s no language or tool that suddenly makes you create better things.
I have in my jobs interacted with high profile robust APIs in C++ as well as functional languages. They can be a joy to use when designed well, regardless of language.
I'm sorry but this is a lot of shallow hyperbole. It doesn't matter if your functions are pure if they return a unique data type for your API or library that is not understood easily by the caller. So the solution is to make that data easily convertible or generic.. and guess what? That's no different than doing the same in an OO language. In the end, lego pieces are ultimately about the data itself, not how it is manipulated.
The key ingredient in making software reusable and portable is the talent and experience of the engineer, regardless of language.
I think this is a rather simplified and naïve analysis. Getting functional programs and functional APIs to compose well with each other is just as much a challenge as in other language paradigms. Just because the logic is organized as functions doesn’t magically make things fit together. Your APIs need to speak in a consistent way as well, and the arrangement of your data needs to be the same or easily convertible between your “Lego pieces“. Having spent many years of my career writing functional code all day, it is just as easy to make a mess of things in functional programs as it is an object oriented programs. I do not believe either is inherently better at creating the “Lego“–style.
> Clojure is a dynamically typed language and always will be
I don't entirely agree with the "always will be," as Clojure is a very creative language that inspires a wide variety of experimentation, and core.typed is currently being actively worked on (as a PhD dissertation no less by the original author of core.typed), so there is ample room to think the future will offer good static typing abilities for Clojure.
I really like and use Clojure professionally, but I have become wary of the extraordinary time I spend dealing with runtime issues because of the dynamic typing. I hope the future of core.typed is bright. I know it is being very seriously worked on. It can't come soon enough for me. Nowadays, I prefer to write in any statically typed language even if it is more line counts, just for my own sanity.
Since FB got Instagram under the belt, it's no less annoying. On the mobile app, I've turned off all notifications, because why? If I want to check in on my Instagram apps, I'll open the app myself, thank you very much. No need to litter my screen with that stuff. But guess what? The app of course knows if you have notifications turned off, and there is no way whatsoever to get the app to stop bothering you about this when you open. Every time, it asks me why I don't have notifications turned on, and does so in a half-screen-sized banner that is obnoxious. No matter what I do, this never tops appearing until I turn on notifications again.
Yes they are, and it's not really adding to the debate.