Prototype Based Programming in Lisp?

[David McClain]

Well, thanks Tom. I really appreciate your substantive answers. 

I sounds to me like programming has broadly branched into at least two major domains, and with English being so imprecise, it is easy to conflate the two in any discussion. I see web-based programming as a huge domain, taking most of the conversations. But I have never been part of that world, and programming, to me, has always revolved around antipodal domains.

I can appreciate how interoperability in a Java world would be a huge plus. And if I faced that kind of choice, I might well become an evangelist for anything approaching Lisp in that world.

But to illustrate my own mindset a bit, I was thinking this morning about how much like the old Data General Nova-800 the concepts of prototype-based programming are. In that old machine, the low page (256 words) of memory was special with auto-incrementing cells, and the notion of indirection was such that an indirection chain was followed on every pointer that had a tag bit set until finding one that didn’t. 

I deal in machine-machine interactions for the most part. Not so much across the Ethernet, but sometimes there too. Mostly I am counting microseconds in everything that hits the bare metal. It took more than a decade before I could imagine working in anything as abstract as Lisp. But I’m very glad I made that transition. Not so much for the language proper, but for the abstract concepts it introduced to my bare-metal world.

… I’m still looking for a good application, somewhere in my vast code base, for prototype-based programming. So far I haven’t found a good use case. Doug Hoyte’s DLAMBDA sufficed for me everywhere that CLOS was too heavy. I’ll keep looking.

- DM

> On Jul 4, 2016, at 09:07, Tom Emerson <tremerson at gmail.com> wrote:
> 
> 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
> 
>