It was sarcasm. My point was that with AI, anyone has a chance to make their name about this "amazing new tech" just like Rich and contemporaries did in the 2010's. Not AI as the means to an end, but as the end in itself.
Clojure is the language that made me "understand Lisp", as originally stated by Eric Raymond and citet by Paul Graham: https://paulgraham.com/avg.html
It seems like a small thing, but Clojure's choice to open up for other types of parentheses made seeing the structure of lisp programs much easier. This helped me understand how code is data and how macros are functions that can transform both code and data.
An important design philosophy (which is also hinted at in the trailer) is "simplicity". Clojure is designed to give you the tools to build simple solutions to the problems that you want to solve. It approaches mutability, which is one of the key sources of complexity in programming, with immutable data structures. It's a really clever way to do functional programming where your data is copied a lot but the copies are lightweight.
I don't write Clojure any more these days. I'm mostly doing Rust. But it is true what Eric Raymond said: Lisp has made me a better programmer.
Lisp philosophy is all about inventing languages (libraries), creating abstractions for each problem. Clojure is all about using primitive data types and maps everywhere explicitly.
> virtually all abstractions are built on top of primitive data types
Obviously. The point being made is that the Clojure style discourages building DSLs and the like and prefers to remain close to Clojure types and constructs. It departs in various ways from traditionally Lisps.
DSLs typically involves constructing macros that are domain specific (to cobble together a domain specific programming language on top of the host). Most of the linked examples are not macro based and are the exact opposite. They specifying domain specific data layouts built directly using the Clojure-native immutable datatypes. They don't create Domain specific datatypes or function-generating wrappers. It's just rarely necessary
A good example is making GUIs in Clojure. At first there was a cool macro based system called `fn-fx` that maked a JavaFX GUI. Then vlaaad wrote `cljfx` which just used plain Clojure maps and removed the macros entirely. This increased the boilerplate a tiny amount but made the system much more flexible and extensible
> DSLs typically involves constructing macros that are domain specific
a DSL is a constrained language for expressing domain concepts.
in traditional Lisps they are often syntax-oriented, because code is lists and macros are a natural tool.
in Clojure, pervasive use of keywords, vectors and maps allows you to shift DSL design towards data interpretation rather than syntax transformation.
so in Clojure doesn't discourage DSLs - clojure practicioners simply prefer data-oriented DSLs to macro-oriented ones, mostly because they are easier to reason about and process with existing tools, while macros are used more selectively.
The original comment you took issue with "The point being made is that the Clojure style discourages building DSLs and the like and prefers to remain close to Clojure types and constructs". You seemingly read half the sentence and in the most unfavorable way possible. (in context it's clearly not talking about "data-oriented DSLs)
> DSL is a constrained language for expressing domain concepts
What you're calling "data-oriented DSLs" is not constrained.
I guess this is all semantic, but in my book just specifying a data-structure doesn't make a language. You're not extending the host language in any way
"DSLs" can both mean "Using the language's variant of 'arrays' to build a DSL via specific shapes" like hiccup in Clojure does, and also "A mini-language inside of a program for a specific use case" like Cucumber is its own language for acceptance testing, but it's "built in in Ruby" in reality.
Clojure favors the "DSLs made out of shapes" rather than "DSLs that don't look/work like lisp inside of our programs".
Yes, maybe that's the sort of DSL you're talking about, the other person mentioned "Clojure style discourages building DSLs" which I'm fairly sure to be about the other DSL and is also true, hence the whole "you're talking/reading past each other".
> Clojure style discourages building DSLs and the like and prefers to remain close to Clojure types and constructs
This to me, seems to indicate they're talking about "DSLs not built with Clojure types and constructs", I'm just trying to have the most charitable reading of what people write and help you understand why it seems you're not actually disagreeing, just talking about different things.
It's a bit unfortunate that several calls to .setHTML() can't be batched so that several .setHTML() calls get executed together to minimize page redraws.
Unlikely. Maybe I'm overly optimistic, but I think it's fairly likely that the RAM situation will have sorted itself out in a few years. Adding reference counting to the JVM and .NET would also take considerable time.
It makes more sense for application developers to think about the unnecessary complexity that they add to software.
Honest question: do you want them to? Most of us aren't running high-profile OSS projects, and drive-by PRs are a pretty widespread complaint about GitHub's model of opensource
Facebook and others have been scanning your private messages for many years already. Then someone discovered that this practice is illegal in Europe. So they passed the temporary chat control 1.0 emergency law to make it legal. The plan was to draft a chat control 2.0 law that would then be the long-term solution. But negotiations took too long and the temporary law will expire on the 4th of April (not the 6th) which means that it will be illegal again for Facebook and others to scan the private messages of European citizens without prior suspicion of any wrongdoing.
My impression was that the temporary permission-granting regulation was passed before the relevant privacy law came into effect, but I didn't check the dates now.
The "voluntary" scanning is still mass surveillance of private messages. We as technologist tend to rely on technical methods to protect our private data. But non-technical people should also enjoy confidential communication, even if they don't actively protect their conversations.
reply