The Language of the System - Rich Hickey

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

in “Effective Programs: 10 Years of Clojure” · View on HN

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".

in “Transit: JSON Data Interchange Format” · View on HN

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]

in “A farewell note to a programming language” · View on HN

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).

in “Queues and databases” · View on HN

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.

in “Clojure Async Flow Guide” · View on HN

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

in “Maybe Functions” · View on HN

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] ▶ this video

in “Alan Kay and Missing Messages” · View on HN

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] ▶ this video

in “How to Design Classes [pdf]” · View on HN

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] ▶ this video [2] [link] ?

in “Show HN: AdminJS, the Backend-Agnostic Administration Framework” · View on HN