
Programming Clojure, Smalltalk Style - swannodette
http://robert.kra.hn/projects/cloxp
======
pjmlp
Actually it is more Xerox PARC style, not only Smalltalk[0].

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.

~~~
swannodette
Smalltalk was invented at ... Xerox PARC. The author works at CDG Labs where
Dan Ingalls of Smalltalk fame is employed. I'm fairly certain the author is
aware of the history around PARC Smalltalk environments and the PARC Lisp
graphical environments that followed.

~~~
pjmlp
I guess I didn't express myself correctly.

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.

~~~
adamnemecek
What Xerox PARC documents are you referring to? I've been looking for
something along those lines.

~~~
pjmlp
These books contain all the relevant Smalltalk 80 ones,

[http://stephane.ducasse.free.fr/FreeBooks.html](http://stephane.ducasse.free.fr/FreeBooks.html)

On bitsavers search for Mesa, Cedar, Interlisp-D and Smalltalk.

[http://www.textfiles.com/bitsavers/pdf/xerox/](http://www.textfiles.com/bitsavers/pdf/xerox/)

Also
[http://www.softwarepreservation.org/projects/LISP/interlisp](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.

~~~
swannodette
Wow these are great links thanks!

------
reilly3000
As somebody who is trying to learn Clojure I am really interested in this
project. Contextual access to docs and syntax would definitely help speed
along the process!

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?

------
mercurial
> As a result the system supports a workflow that is more like a conversation,
> a back and forth between programmer and system.

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.

------
coding4all
Clojure for the win yet again.

~~~
klibertp
There's nothing - or very little - language specific here. The idea - as TFA
admits - is old and already implemented a few times. Aside from (many)
implementations in "esoteric" (Smalltalk, Self, Lisp...) languages, we even
have things like LivelyKernel, which is implemented in JavaScript... and
almost nobody heard about it.

~~~
coding4all
Did you read the last two paragraphs?

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.

~~~
seanmcdirmid
1 and 2 are platitudes devoid of content. 3 is a bold claim but doesn't pan
out in practice: live programming is creating to changes in code and state,
making changes go away only eliminates the problem by eliminating the
experience (see [1]).

[1] [http://research.microsoft.com/en-
us/people/smcdirm/managedti...](http://research.microsoft.com/en-
us/people/smcdirm/managedtime.aspx)

~~~
terranstyler
I think he means that _using clojure_ (to implement the IDE) is very language
specific as opposed to saying "it is based on clojure" or "clojure is cool
because X" (which everyone can).

~~~
seanmcdirmid
I believe they are talking about the programming experience vs. the
implementation. Here is the specific passage:

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

~~~
tensor
To be fair to Clojure, it has a much more nuanced approach to state management
than simple encouraging immutability. It pushes that you should be immutable
whenever possible, but if you must use state then you should use it in a
controlled and understandable way either by atomic operations, transactional
memory, or agent. Further, it provides implementations of all of these things.

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.

~~~
seanmcdirmid
I agree with this; Clojure's design is incredibly pragmatic about state,
including mutable state, like any good Lisp.

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.

------
pron
If he adds code bubbles (which he mentions) that would be _really_ cool.

------
kyllo
Cool, reminds me of Dr. Racket mixed with Smalltalk, but for Clojure.

