Perhaps not what you intended, but I believe this is that exactly what Cosmopolitan is doing: - They are writing portable software in that it can run on various architectures and operating systems - They compile it for each platform, even if the output is a single binary - For the best performance and functionality, they mention several examples of how Cosmopolitan outperforms the native alternatives
I'm sure there are plenty of rebuttals ("Emacs on Windows is a port", "Cygwin isn't portable", "they could make the native version of $WHATEVER more performant", "Cosmopolitan isn't always faster", etc.), all of which are well and good, but would be missing the bigger picture, which is that there are reasons for both approaches (among others!) to exist, an idea that far transcends software.
Not that joins in SQL use a particularly intuitive notation. At the very least it doesn't make it obvious you can usually swap the order of joins around without affecting the end result.
You mentioned moving JOINs around, so I'll mention that if represented as structured data, you can move any of the top level components around, so you could more closely follow the "true order of SQL" [1]. For example, I would love to be able to put FROM before SELECT in all or almost all cases. There's also being able to share and add to something like a complicated WHERE clause, where essentially all programming languages have built-in facilities for robustly manipulating ordered and associative data compared to string manipulation, which is not well-suited for the task.
Now don't get me wrong, I don't particularly care for YAML (though it doesn't bother me that much), but as someone who's done their fair share of programmatic SQL creation and manipulation in strings, not having a native way to represent SQL as data is a mistake in my opinion.
0: https://github.com/seancorfield/honeysql#big-complicated-exa... 1: https://blog.jooq.org/a-beginners-guide-to-the-true-order-of...
Also, although it may not be easy to remember, is this really a problem in practice given the installation count in most contexts is one? If there's a context where it's installed regularly, that's a one-time addition to an install script, Dockerfile, etc. in my experience. Do you have a situation that isn't amenable to that?
So, "Packages are the new standard of distributing packages, and replace packages" is clearer to you?
> 99% of top Python packages are now on version 2
He was just clicking around compulsively, jumping between stuff randomly without even reading it, while not understanding what he was looking at. I have no idea how he's successful in tech, judging from what I saw there.
I think judging only from what you saw there is the issue. If you look somewhere like Wikipedia [0], you'll see he was the first person to jailbreak the iPhone, the first person to achieve hypervisor access to the PS3's CPU, he took first place in several notable CTFs (at least one time as a one-person team), he worked on Google's Project Zero team (and created a debugger called QIRA while he was there), creating comma.ai, and the list goes on.
It really feels at this point like Python has subsumed the best features of every dynamically typed language.
Typically, people endorse Clojure for the following reasons: 1. It's functional! OK, well, all the higher order functions exist in Python, too, but in fact you wouldn't want to use them anyway because in Python you have list comprehensions, which, it turns out, usually leads to an even more readable solution. 2. REPL-driven development! Python also has a REPL. True, it isn't the best REPL imaginable, but as far as I can tell it has feature parity with Clojure's! Both are missing the ability to fix errors live in a breakout REPL like you would find in a true LISP REPL. 3. Macros! Code is data! You can easily create your own DSL! OK, maybe. But actually, in Clojure I've gathered the impression that macros are looked down upon, a feature of last resort, unlike in other LISPs. I also can't recall ever using Python and wishing I could replace its syntax with a DSL, since it is already so expressive and flexible. But admittedly that might be a limitation with my own imagination and experience.
People tend to say all these things in favor of Clojure, but when you actually investigate them they seem quite flimsy. Meanwhile, for a language like Python the value product is clear and obvious. Where else are you going to do your machine learning, for example?
I really am not trying to be an asshole to people who do enjoy and like Clojure, because I want to be one of you! I just need some reason to continue learning because clearly I haven't yet grokked the benefits. If anybody could concisely explain the advantages Clojure has over a language like Python (speed, maybe?) which do not fall apart under close scrutiny I would be grateful.
As someone who writes more Python than Clojure these days, Python's limited lambdas are a regular source of frustration. Additionally, Clojure's first-class data structures are sorely missed in Python.
> 2. REPL-driven development!
The huge drawback IMHO that rarely gets discussed is the ability to change modules in Python's interactive interpreter (Clojure's analog is the namespace). For example, in the context of a web app, adding a new view in some views module, then swapping to the routes module and adding the adding a new route to wire up the view. Additionally, there's no built-in way to connect to the interpreter, as manually typing in a REPL is not the usual flow. To me this makes Python's interpreter unusable for anything but toy examples.
> 3. Macros!
Clojure is less macro-dependent than other lisps, but in most projects I use, there are one or two that really help clean things up. If you look to other modern languages that have macros (for example, Rust), I think the same idea applies.
I've added Clojure to several legacy Spring Boot apps, and the fact that it can be introduced as "just a library" made that portion a snap. If you're not trying to access resources related to Spring Boot's dependency injection, it's pretty straightforward to call into Clojure from Java. If you _do_ want access to DI resources, there's a small amount of code required to wire things up, though it took me a while to find out what that code was, mostly because it requires access to portions of Spring Boot that are not typically user-facing.
Since I had hooked Clojure up to the Spring apps, I also set things up so I could SSH onto application servers, then get a REPL via a socket server into the applications themselves. Being able to check and sometimes change the state of the application live at runtime was like a superpower. This proved extremely valuable, often for debugging errors in the Java portions of the code, but also for situations like final design tweaks live with a client in a development environment. Client asks to bump a font size or change a color or adjust a border or change some copy, then I make the change in my editor, send it over the socket REPL, tell the client to refresh, and repeat. When done, I would simply save, commit, and would be confident that it's what the client was after. The only downside is that I'm no longer at a shop that uses Clojure, and feedback loops for production debugging or letting clients see their decisions are measured in days or weeks when possible at all, not seconds or minutes.
I will admit that connecting to a running application is dangerous, but so is what many surgeons do, and we are certainly not going to ask them to turn in their scalpels. By being conscious of the "great power; great responsibility" bit, I was able to come out mishap-free.
On the other hand, when I had to create new projects where I thought Clojure would be a good fit, I just went all-in with the Clojure ecosystem rather than start with Spring Boot and add Clojure, and I found going all-in with Clojure to be incredibly productive. With that being said, I made the decisions with a decent understanding of both Spring Boot and Clojure, so my experience would likely vary from that of someone who is experienced with Spring Boot and knows nothing of Clojure.