Prototype Based Programming in Lisp?

[Tom Emerson]

On Sun, Jul 3, 2016 at 7:25 PM, David McClain
<dbm at refined-audiometrics.com> wrote:
> My impressions from a few years ago was that Clojure was another language
> built for the heck of it, much like Python.  Not particularly well designed[...]

Rich Hickey didn't create Clojure just for the heck of it: he had very
specific goals in mind and, IMHO, put a lot of thought into the design
of the language and the decisions he made given the design space
(running within the overall JVM environment) and the warts he saw in
other languages, within and without the Lisp family. There are
numerous presentations available online where Rich talks about the
development of Clojure: if you're interested I think they would show
you that his design

> under the control of one individual[...]

I'm not sure you can compare Python's BDfL with Rich's position with
Clojure. I don't have a concrete example, but Clojure feels less
bound-up in its creator's blinders than Python. That can also be a
side-effect of its Lisp-nature though.

> with lots of cheerleading from the small audience.

Which isn't a bad thing. Any new language requires its evangelization.
I would also posit that from outside the community, Common Lisp is
viewed the same way.

[...]
> And I know
> essentially nothing of the Java world, and whether or not it is a good thing
> that they are migrating to Clojure.

That's the crux of it: if you have to co-exist in a Java universe and
want to write in a Lisp, your options are Clojure or Armed Bear Common
Lisp. ABCL is relatively recent and does not have the community
support that Clojure does. The tooling available for Clojure is quite
good, insofar as its Emacs tools are excellent and support for the two
most common Java IDEs (Eclipse and IntelliJ) is steadily improving,
making the transition for Java developers much more friendly. The
software that I'm writing in Clojure is seen by our operations team as
"just another Java binary". It allows my software to integrate into
their existing monitoring and logging systems without them doing
anything different. I also have the entire Java/Scala library
ecosystem available to me: if I need something that doesn't exist in
Clojure I can usually find it in the Java world. The interop between
Clojure and Java is cleaner, in my limited experience, than that
between ABCL and Java.

While its a tired trope, cross-platform compatibility is good. I
develop on Mac OS X, continuous integration and deployment on Linux,
and my coworkers use generally use Windows. That's not uniquely a
Clojure feature: SBCL, CCL, and LW all run on these different
environments too.

There are parts of Common Lisp I miss when developing in Clojure,
especially the conditions system. I sometimes miss CLOS, but Clojure
has multimethod dispatch which is good enough for most cases.

I like both Clojure and Common Lisp, and see them as complementary
tools which I select depending on my needs at any given time. However,
there is a cognitive load in switching between them, and since most of
my work of late is in a Java world, I tend to stick with Clojure even
for nonce tools.

ClojureScript is amazing if you are creating tools or services that
need a web-based UI, whether for primary interaction or diagnostics.
The entire system can be written in Clojure, with the UI running on
the client browser. You can share code across projects: I have a set
of functions used to generate various sequence comparison statistics
that I share between command-line tools and a single-page web
application that is written in ClojureScript. Before moving to
ClojureScript I had to maintain two versions of these, one in
JavaScript and another in Clojure. I can even make these functions
callable from Java, if I cared to do so.

Anyway, I don't want to initiate a religious war between Clojure and
CL. I just wanted to give you some reasons why a (Common) Lisper may
also use and enjoy Clojure.

Peace,

    -tree

-- 
Tom Emerson
tremerson at gmail.com
http://it-is-what-it-is.treerex.net