So many people are obsessed with Web application size. But there are other important factors as well. First of all, the UI must be functional even it's slow and heavy. If it does the job then it's already a win. I don't actually care how long I'll wait while I'm downloading the JS bundles. I've been waiting 5-10 mins GTA to load back in 2008, waiting seconds is totally ok.
While Google advises to use abstractions, I like the left-hand side variant. It looks to me easier to understand and change. The right hand side is scattered and abstractions mutate the object, which may have side effects.
It's all about the right level of abstraction at the right time. The example given is too kind to the reader, I can imagine functions with 1000s of lines with the exact same structure of doing too much distinct sub-steps. Of course you don't want to create something like the indirection hell that frameworks like Spring in Java create but it's not hard to find a middle ground. For instance I find it specially easier to create code like the right-hand side when I'm using test driven development.
Agreed more readable, instead of searching/scanning. That's an issue I have with larger projects, more files and classes to jump to for not any gain really.
It definitely is. His first example is Assembly. That's like saying someone saying 'don't program in assembly' is being hypocritical because everything they program ends up in assembly.
You theoretically can but Clojure is not OS-level so you'd be working something like JVM->CLJ->Go and that would remove a lot of performance. Or Go->Clj->Go which is redundant. So yeah, I stand by my statement. And I could be your dad, how do you know 100%?
Go -> JVM bytecode with a Clojure-facing API and a Clojure-based compiler as a Clojure package wouldn’t be so bad. It’d just be another JVM frontend, hosted in Clojure. Clojure is also just a JVM frontend. I’m not quite understanding this “JVM->Clojure” bit of your equation; Clojure is a JVM frontend and stdlib API.
