Programming Clojure, Smalltalk Style
robert.kra.hn
robert.kra.hn
From the post I am not sure if the author has checked Interlisp-D.
Or the Lisp Machines and commercial Lisps like Lisp Works and Franz Lisp.
Sometimes I wish younger generations would care to look more into what was happening at Xerox PARC and ETHZ, and less at what was happening at AT&T.
Great post.
[0] Interlisp-D, Mesa/Cedar provided similar experiences.
I was trying to convey the message that while the author is correct to talk about Smalltalk, the experience was traversal to whole operating systems being researched there.
Every time I dig into Xerox PARC documents, I discover new things, specially how we are still catching up with those environments.
http://stephane.ducasse.free.fr/FreeBooks.html
On bitsavers search for Mesa, Cedar, Interlisp-D and Smalltalk.
http://www.textfiles.com/bitsavers/pdf/xerox/
Also http://www.softwarepreservation.org/projects/LISP/interlisp
ACM also has quite a few papers if you have access to it.
Additionally you get some tips by reading Niklaus Wirth books about Modula-2 and Oberon, as he refers how Mesa and Cedar influenced his languages.
In fairness however us young people are still catching up on others' catching up on said environments. :)
We still had to learn about what was happening since the early 60's. I wonder what gets teached on the universities nowadays.
It is amazing how fast so much knowledge goes lost.
I am also really intrigued about the concept of contextual chat and collaborative coding. One of you hackers is going to finally build the Twitch of coding one day, and it shall be glorious. Perhaps cloxp will be the one to take us there?
Interesting to contrast this with my OCaml experience, which is more a REPL-punctuaded series of monologues: writing a longish piece of code in Vim, and then sacrificing goats to appease the compiler, before moving on to finding out the logic bugs.
1. >"It is based on Clojure because Clojure comes with a set of attractive properties."
2. >"Clojure also combines an exciting mindset around simplicity with enough pragmatism to make it a successful system for real-world projects."
3. >"Additionally, Clojure's strong view on how state is handled, the distinction between identities and values and focus on immutability make it easier to deal with the complexities that come with "live programming"."
That sounds pretty language specific to me.
[1] http://research.microsoft.com/en-us/people/smcdirm/managedti...
> Additionally, Clojure's strong view on how state is managed, the distinction between identities and values and the focus on immutability all make it easier to deal with the complexities that come with "live programming".
The first point makes sense; the second point doesn't. Immutability either avoids the problem of change by denying or pushes it up for someone else to handle. So say you have a dictionary: do you handle change directly by mutating the dictionary or do you create a new dictionary to be diffed later? The first way is much easier than the second.
The next sentence is true:
> Having a strong concept of what state is and how state transitions occur makes programming tools simpler.
This is very true, but again detecting a state transition is much easier when you allow for mutation of state (otherwise, diffing must be used, and that's expensive).
But anyways, this isn't really live programming as envisioned by Hancock: there is a manual "re-evaluate this line code" command under the current program state; there is no repairing of the past; compare against the Elm live programming demo, which is fully live at the code level.
So Clojure explicitly allows for state transition and provides controlled and standardized ways of handling it. One of the selling points of Clojure is that it speaks to practicality in implementation by providing alternatives, or in the extreme case, complete escape hatches to low level tools that avoid even it's state control mechanisms. It simply encourages first immutability, and second state control in a well defined way.
People just tend to misinterpret this, or they digest it as "immutability good for live programming" when that isn't true: immutability is great for programming with values, but please don't make an immutable world object and replace it when something changes! Unless you are using Javascript, I guess there is just no other way to deal with the DOM other than diffing.
Probably. I mean I skimmed the article, didn't read it very carefully.
> That sounds pretty language specific to me.
I failed to express myself properly: sure TFA is Clojure-specific, it talks about Clojure implementation of X after all.
My point is that it's 'X' that's important here, much more important than 'Clojure' part.
'X' here is "directness and liveness", which are extremely powerful ideas, first described in seventies, then implemented many times by many different people in many different languages and environments. Probably the most well-known implementation is called "Morphic" and comes from Self ('95, by the way: http://web.media.mit.edu/~jmaloney/papers/DirectnessAndLiven...), but there are others.
It's really a good thing that one of the most powerful ideas in GUI programming finally is getting some traction. It took it only forty years. It's unfortunate that it's coming to Clojure: it would be better for it to come to JS with node-webkit or something similar; that way much more people would have a chance to see and work with such a system.
So, in short, in this discussion my perspective is idea-centric instead of language-centric, which is why I don't consider the "Clojure" part important.
https://yow.eventer.com/yow-2011-1004/the-live-web-by-dan-in...