This is more nomenclature than anything. We have a broad definition of what a lisp is, but a fairly narrow definition of what a C variant is. I'd argue that C++ and Java have more in common with each other than, say, Shen and Emacs Lisp.
Rich uses a very precise and archaic definition of simplicity, which he describes in his "Simple Made Easy" talk. In a nutshell, when Rich talks about making something simple, he's talking about limiting the number of things that can affect it.
For example, under this definition, the simplest thing possible is immutable data, since nothing can affect it. The next simplest things are pure functions, because they're affected only by their arguments. Clojure is a language built around Rich's idea of simplicity, so Clojure prefers data over pure functions, and pure functions over side-effectful functions.
What you're describing is what Rich would likely term "easy". Something is easy if you can do it with little effort. Something is simple if few things affect it.
Tablets are also useful for watching video in cases where a large TV is impractical or just plain unnecessary. They typically have longer battery life than laptops, which makes them extremely useful on long haul flights, and easier to pull out of a coat pocket than a laptop. They're also typically cheaper; I don't mind using a £100 tablet on a train to check emails or whatever, but I'm more leery at pulling out a £1200 laptop.
ClojureScript is now self-hosting, which means that you can eval any valid ClojureScript, so yes, eval in ClojureScript is now equivalent to the eval in languages like Clojure, Racket or any other Lisp.
Because Clojure isn't a pure functional language, transducers may be stateful. `take` uses a volatile (i.e. a fast, mutable variable) to retain state. I don't believe a `flatMap` transducer exists in Clojure yet.
Regardless of whether commit messages are in past or present tense, have trailing period or not, properly capitalized or not -- they are all equally unreadable with all the "Merge pull request #20552 from jamesdabbs/belongs-to-polymorphic-force-reload" junk.
Yeah, that's something that I never understood. The most important information is not that this is a merge, but the intent of the branch. You can give extra detail in the extended part, but the title should not be just referencing the way in which those changes found their way to the branch, and not what they do as in the rest of commits...
I believe Github lets one add extended commit messages for merge commits. Most of us (including me) tend to ignore that and use the autogenerated one. It'd be nice if we had an easy option to automatically include the PR's description (first comment) as the merge commit's message.