The Language of the System - Rich Hickey

Simple Made Easy ( link ) The Language of the System ( ▶ this video ) The Value of Values ( link ) All by Rich Hickey (Clojure creator) - strongest programming speaker I've found to date.

I came across this after watching Rich Hickey's The Language of The System [1], and it has really changed the way I look at distributed persistent storage. Any thoughts? [1] ▶ this video

EDN has some really good ideas in it. Here's the main spec: link The Learn X in Y Minutes: link A related talk by Rich Hickey that I think you'd find interesting: ▶ this video For a schema, I'd start with what CUE has done. The idea of types that constrain down as a lattice + a separate default path really resonates with me. link

I would say Clojure more than substantial returns of invested time. Not just the language itself, but also the wider approach to software composition, feature accretion vs backward compatibility, schema'd dynamic typing seem benefictial no matter what your development tools you use. Maybe check out the talks below and see if they don't enRich you as software engineer. ▶ this video The Language of the System link Design, Composition, and Performance link Spec-ulation link Maybe Not

> Clojure with the same exact constructs represented with more C-like syntax would, at the level the presentation speaks to, allow the same level of simplicity. I don't think this is true. I think it would be easier for "most people," but definitely not simpler . Easy meaning close at hand, simple meaning one strand, one braid, independent, less context necessary. Clojure syntax is the AST of the program, right there in front of you, in literal notation. There are fewer special cases, fewer moving parts interacting. C syntax requires spinning up a virtual machine in your mind and executing multiple statements. C is easier because we've already spent the time and effort to familiarize ourselves with it, but it has more complexity. Compare a 954 line ANTLR grammar for C [1] with a 261 line Clojure grammar [2]. > Cognitive overhead is lower working with a language that at least "looks like", what you're used to, and more developers know C-like languages, thus a language like Kotlin is "easier to approach" but necessarily "easier" in the way the presentation talks about. I would agree, using Rich's definitions of simple and easy, that Kotlin is easier for the majority of developers than Clojure. This follows immediately from the definition of easy. > This is a misapplication of the presentation really. It speaks to a level above selecting a language and is really about the design of systems. I would recommend Rich Hickey's talk "The Language of the System" [3]. The programming la

Rich Hickey, the creator of Clojure, gave a talk with some very relevant points in this space (The Language of the System): ▶ this video

I love this talk, but it does throw out a lot of complicated ideas somewhat loosely, so I get why reactions and interpretations are all over the place. I think a good companion to understanding this better is Rich's talk on "The Language of the System" ( ▶ this video ). I interpret his overarching thesis as this: Most "situated" programs are in the business of processing information according to complex and changing rules, in cooperation with other programs (i.e., a system). Many languages, though, are overly-concerned with how they represent data internally: classes, algebraic types, etc. This "parochialism", he calls it and "concretion" about how data aggregates should work, make them hard to adapt when the rules, data, or other parts of the system change, and make it hard for their programs to work in systems. At some point your Java class or Haskell ADT has to communicate its data to other programs that have no notion of these things. So you end up w/ a ton of surface area in your code with mappers and marshallers totally unrelated to the content of the data and purpose of the program. The idea behind Clojure is to provide easy access to simple, safe, and relatively universal structures for holding data, and a library of functions to manipulate those structures. Its "big picture" design bits are about providing semantics for multiple "programs" (from threads to services) in a system to operate on data robustly and reasonably (concurrency semantics, time and identity models, pe

The downvotes are because it comes across as a shallow, middlebrow dismissal. An interesting and useful criticism would first engage with the strongest arguments of Rich Hickey (creator of Transit and edn). If you find something in his Language of the System talk ( ▶ this video ) that you either (a) disagree with (b) think XML solves already, I and many others would certainly be interested in having that conversation. Note that this doesn't mean the exposition of "Why Transit" can't be better, but that calls for constructive criticism on how explain the ideas better, or a question made in qood faith. What it doesn't call for is a hostile reply saying in effect "pff, already been done already, stop reinventing the wheel".

I would suggest to you that Clojure has a very clear "the Clojure Way" I would say, more so then almost any other language. It goes beyond syntax to a pretty deep design level. Its not even all that unique to clojure, you could do 'the clojure way' in other languages, but they usally dont. Some of the importent keynotes from some of the early conjs are really importent, and they really went deep in the community, you can see it in almost every major library. Another commenter has mentioned the notion of 'simple' but thats not really all that clear. I not enougth of a writer to tell you about it, but I can give you the resources: - This classic got Clojure on the map for many people: Are We There Yet? - Rich Hickey www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey - Simple Made Easy - Rich Hickey - link - Simplicity Ain't Easy - Stuart Halloway - link - Ousterhout's Dichotomy Isn't (Part 2 of the Simplicity/Power/Focus Series) - Stuart Halloway - link - The Language of the System - Rich Hickey ▶ this video - Hammock Driven Development - Rich Hickey link In addition to these, there are many talk that are about people trying to run with these ideas. Datomic is a example of taking these ideas to the max, it really standas as a nice example. You can find others in talks by David Nolan for example, but there are tons of applied talks. - The Design of Datomic - Rich Hickey link

This paper describes ideas around #2: link But yes, your database stores the status of a message. At this point you could drop every single message on your queue and have enough information to resend them. Each message could have its own resend (SLA) semantics. Amazon Simple Workflows is an implementation of this pattern: link . I've never used SWF but the docs are great food for thought. [edit] Also might be of interest to watch Rich Hickey's 'Language of the System'. ( ▶ this video -- there are a few versions of this talk, not sure if this is the exact viewing I saw). The talk is not really about queues, but he tries to break things up a bit. You need a data store, you need a queue, etc. As soon as a queue tries to have durable messages it is becoming a database and has all of the problems a database has to deal with. Instead you could keep data storage being solved by the data storage provider and let queues focus on passing messages. This raises the issue of how to deal with dropped messages, but that can be solved without durable queues (like that paper describes / SWF / etc).

Rich Hickey actually did a talk called "Language of the System" ▶ this video way back in 2013 before core.async was even created that lays out a lot of the ideas. It even has a big section explicitly about "flow" which contains the germs of core.async.flow.

IIRC Rich Hickey says something similar to the "pipeline-oriented programming" piece in his talk about systems: ▶ this video