The Language of the System - Rich Hickey

This is the perfect case for hypermedia in the RESTful sense. Rich Hickey recently gave one of his talks[1] where at one point he offhandedly mentioned that hypermedia (which gives URIs for related HTTP resources, with some link-like metadata) doesn't make sense for APIs because APIs don't have human "drivers" that can read the link text and make meaningful sense of what relations actually mean in the domain model. I think the genius of RESTful hypermedia, though, could really come through in a system like this. How else do you show relations? Last time I checked, RailsAdmin can't do much for you here except provide the resource ID as a link to that resource's table and row. As a benign example, imagine a guest-party admin page. What today would look like "Guest: 'Pitt, Brad', Party: '43'", tomorrow could be be "Guest: 'Pitt, Brad', Party: 'Pitt-Jolie'" with a link to '/parties/43'. I sense that developers (or at least Crockford[2]?) don't want JSON to become overloaded with XML equivalents like XML schemas and metaschemas and XSLT...but think of what we could do! [1] [VIDEO] [2] [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'. ( [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).

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 [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]

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 ( [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 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] [VIDEO]

Is there a functional-programming-first curriculum? Even though knowing OOP is important (if even just for the vocabulary), I wonder if a lot of pain could be sidestepped by talking about data as a separate concern than ADTs, and state as a fact rather than a place. [1] [1] [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" ( [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

I've watched one of Rich Hickey's talk and at some point he brings that issue on the table, what happens when the receiver is not responding to the message. He is advocating Queues and one of his arguments is that Queues decoupling the requester from the receiver. So you don't really have to worry about things like this by using a queue. [1] [VIDEO]

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

> 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

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. [VIDEO] The Language of the System [LINK] Design, Composition, and Performance [LINK] Spec-ulation [LINK] Maybe Not

Simple Made Easy ( [LINK] ) The Language of the System ( [VIDEO] ) The Value of Values ( [LINK] ) All by Rich Hickey (Clojure creator) - strongest programming speaker I've found to date.

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: [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]

IIRC Rich Hickey says something similar to the "pipeline-oriented programming" piece in his talk about systems: [VIDEO]

Rich Hickey actually did a talk called "Language of the System" [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.