Hi All,
After having been comfortably isolated in a Lisp atmosphere for more than 20 years, I’m finding myself being dragged into a “new” world centering on Javascript and prototype based programming. It feels like I’m being dragged back by more than those 20 years, but in an effort to overcome the resistance tendencies of aging, I thought I’d delve a bit more deeply into this realm.
I’ve done some investigating and found the genesis in Self. But really, this seems like a trivial kind of pursuit for Lisp. I am aware of the new difficulties in making fast systems with the lack of classes, and troubles deciding inheritance of behaviors.
Does anyone have some interesting insights and pointers to papers regarding prototype programming in Lisp?
- DM
Hi David,
You might find this framework interesting. It has an interesting heritage that may be useful in exploring some the unique qualities and challenges of prototype based systems:
https://github.com/zkat/sheeple
While not specifically concerned with Lisp implementations, Lieberman’s work in this area is comprehensive and does make reference to some aspects of Prototype implementations in Lisp:
http://web.media.mit.edu/~lieber/Lieberary/OOP/Delegation/Delegation.html
There is also Prometheus for scheme which takes an interesting tack:
http://old.jorgenschaefer.de/software/prometheus.html
Best, Gene
On Jul 2, 2016, at 9:05 AM, David McClain dbm@refined-audiometrics.com wrote:
Hi All,
After having been comfortably isolated in a Lisp atmosphere for more than 20 years, I’m finding myself being dragged into a “new” world centering on Javascript and prototype based programming. It feels like I’m being dragged back by more than those 20 years, but in an effort to overcome the resistance tendencies of aging, I thought I’d delve a bit more deeply into this realm.
I’ve done some investigating and found the genesis in Self. But really, this seems like a trivial kind of pursuit for Lisp. I am aware of the new difficulties in making fast systems with the lack of classes, and troubles deciding inheritance of behaviors.
Does anyone have some interesting insights and pointers to papers regarding prototype programming in Lisp?
- DM
On Sat, 2 Jul 2016 06:05:47 -0700 David McClain dbm@refined-audiometrics.com wrote:
Hi All,
After having been comfortably isolated in a Lisp atmosphere for more than 20 years, I’m finding myself being dragged into a “new” world centering on Javascript and prototype based programming. It feels like I’m being dragged back by more than those 20 years, but in an effort to overcome the resistance tendencies of aging, I thought I’d delve a bit more deeply into this realm.
I’ve done some investigating and found the genesis in Self. But really, this seems like a trivial kind of pursuit for Lisp. I am aware of the new difficulties in making fast systems with the lack of classes, and troubles deciding inheritance of behaviors.
Does anyone have some interesting insights and pointers to papers regarding prototype programming in Lisp?
There is various documentation available on optimizing JS, i.e. tracing JIT, etc as it's so popular. Unfortunately I don't have exact references on hand without some searching myself, I haven't followed the development in years, but I used to follow the SpiderMonkey to TraceMonkey developments on the Mozilla js-eng mailing list, of which archives are available. I was an avid SpiderMonkey+JS user before I got into Lisp, but for application programming rather than the web. (i.e. http://mmondor.pulsar-zone.net/mmsoftware.html#js-appserv-sh )
A naive system with a prototype chain implemented as a list, and objects implemented as hash-tables, is indeed rather slow. In Javascript, the programmer also should make an effort to not overly use closures and to as possible inherit from the parent prototype objects to avoid unnecessary object creation overhead (i.e. complex constructors doing a lot of object-instantiation setup are slower than a pointer to a parent object). This is also true for functions that are object properties, and closures often cause extra per-instance initialization in this model. Beware that I was still very new to Lisp, but a very naive test implementation: http://git.pulsar-zone.net/?p=mmondor.git;a=blob;f=mmsoftware/cl/test/protot...
There is an interesting similarity for prototype object property references and symbol references in Lisp packages; and an approach that can be used is to create a faster reference like an index ID or pointer when "interning" a property/symbol, such that generated code can use faster indexing instead of hash table lookups at runtime. A small example of what I mean: http://git.pulsar-zone.net/?p=mmondor.git;a=blob;f=mmsoftware/cl/test/vsymbo...
But there also are many cases where inference can allow to eliminate a lot of dynamic code to result in more static code. ECMA also defined extensions for less dynamic objects which are closer to Java classes, for use when optimization is more important than flexibility. I'm not sure if those are currently used in JS as they were in Flash, however.
An approach could be to compile Lisp to Javascript, and to implement the prototype system library to use the native features of the language, and take advantage of currently optimized engines and their dynamically-specialized JIT/VMs. There is also asm.js and WebAssembly which are realistic targets for an existing bytecode compiler. There may actually exist simpler Lisps already targetting Javascript (there are libraries that compile a limited subset for web frameworks at least). Perhaps that extending such, or implementing a temporary simpler Lisp for initial testing might be a realistic investment?
On 02 Jul 2016, at 15:05 , David McClain dbm@refined-audiometrics.com wrote:
Hi All,
After having been comfortably isolated in a Lisp atmosphere for more than 20 years, I’m finding myself being dragged into a “new” world centering on Javascript and prototype based programming. It feels like I’m being dragged back by more than those 20 years, but in an effort to overcome the resistance tendencies of aging, I thought I’d delve a bit more deeply into this realm.
I’ve done some investigating and found the genesis in Self. But really, this seems like a trivial kind of pursuit for Lisp. I am aware of the new difficulties in making fast systems with the lack of classes, and troubles deciding inheritance of behaviors.
Does anyone have some interesting insights and pointers to papers regarding prototype programming in Lisp?
- DM
There's KR: http://www.cliki.net/KR http://www.cliki.net/KR - this is a prototype-based object system that used to be part of a graphics toolkit, but now appears to have been turned into a separate package.
Thanks for all that great information! Actually, what I’m interested in doing is just delving into the world of prototype programming, hopefully while remaining in Lisp. I do have to use Javascript from time to time, as an extension language for tools that are related to astronomy and astrophotography (TheSkyX and PixInsight). But so far I have remained in Lisp when possible, having it just produce JS scripts that I send to the apps for execution, while the executive logic behind those scripts remains in Lisp.
I really don’t want to wallow too deeply in the pure ECMAScript / Javascript world itself. I noticed almost immediately the sheer lack of introspective features in the base languages. You have to know about an object before you can do anything. No browsers, no tree diagrams, etc. That seems very much like trying to run in a pool of molasses.
What I really want to do right now is develop a Lisp based prototype programming system for experimentation. I’m a long-time language and systems developer, and so that’s how I learn best - by diving in and doing the bottom up and developing the language and applications demonstrating its powers.
The pointer to Sheeple looks interesting, but I see that it doesn’t run right now in Lispworks. Any ideas what the issues are with LW? I see a mention of a Sheeple-like persistent object store in the works. I already have a very elaborate, distributed OODBMS developed in Lisp, called Okeanos (Greek for “Ocean”). Maybe I can bend that to purpose?
I’ll go ahead and ASDF Sheeple and see where that leads. Maybe the LW port will be relatively trivial?
Cheers,
- DM
… I got Sheeple up and running in LW64. It needed only a minor change in the GC function. Whether it is completely correct or not, I cannot tell just yet. Both EOS and FIVEAM need a more advanced form of ASDF than is built into LW64 Version 7.1. But the examples on the GitHub page seem to work just fine. Thanks for that! I’ll roll my sleeves up and dig in…
- DM
On Jul 2, 2016, at 08:33, David McClain dbm@refined-audiometrics.com wrote:
Thanks for all that great information! Actually, what I’m interested in doing is just delving into the world of prototype programming, hopefully while remaining in Lisp. I do have to use Javascript from time to time, as an extension language for tools that are related to astronomy and astrophotography (TheSkyX and PixInsight). But so far I have remained in Lisp when possible, having it just produce JS scripts that I send to the apps for execution, while the executive logic behind those scripts remains in Lisp.
I really don’t want to wallow too deeply in the pure ECMAScript / Javascript world itself. I noticed almost immediately the sheer lack of introspective features in the base languages. You have to know about an object before you can do anything. No browsers, no tree diagrams, etc. That seems very much like trying to run in a pool of molasses.
What I really want to do right now is develop a Lisp based prototype programming system for experimentation. I’m a long-time language and systems developer, and so that’s how I learn best - by diving in and doing the bottom up and developing the language and applications demonstrating its powers.
The pointer to Sheeple looks interesting, but I see that it doesn’t run right now in Lispworks. Any ideas what the issues are with LW? I see a mention of a Sheeple-like persistent object store in the works. I already have a very elaborate, distributed OODBMS developed in Lisp, called Okeanos (Greek for “Ocean”). Maybe I can bend that to purpose?
I’ll go ahead and ASDF Sheeple and see where that leads. Maybe the LW port will be relatively trivial?
Cheers,
- DM
On Sat, Jul 2, 2016 at 12:18 PM, David McClain dbm@refined-audiometrics.com wrote:
… I got Sheeple up and running in LW64. It needed only a minor change in the GC function. Whether it is completely correct or not, I cannot tell just yet. Both EOS and FIVEAM need a more advanced form of ASDF than is built into LW64 Version 7.1. But the examples on the GitHub page seem to work just fine. Thanks for that! I’ll roll my sleeves up and dig in…
ASDF is self-upgrading. Just download the latest release git branch into ~/common-lisp/asdf/ That said, my lispworks 7.0.0 has a pretty recent ASDF 3.1.4. Just how recent an ASDF do you need? fiveam only needs asdf 3.1. Is your LispWorks actually a 6.x? The LispWorks site advertises 7.0.0, and 6.1.1 for the Personal Edition, but no 7.1. (NB: self-upgrading from ASDF 2 is also possible, but requires more work.)
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Life is like an onion: you peel off layer after layer, then you find there is nothing in it.
Yep, my bad… I just looked at the About box - I’m running LW 7.0/64. And thanks for the info on ASDF. My (ASDF-VERSION) shows 1.627. That’s what was delivered with LW 7.0. I’ll try to update ASDF now.
The FIVEAM package halted on load with the error stating that it needs ASDF >= 3.1 to load properly. When I tried just using EOS, as indicated in the Sheeple docs, it needs a generic function on OPERATE that can dispatch on an argument. OPERATE in my old version of ASDF is a normal function.
Cheers,
- DM
On Jul 2, 2016, at 09:30, Faré fahree@gmail.com wrote:
On Sat, Jul 2, 2016 at 12:18 PM, David McClain dbm@refined-audiometrics.com wrote:
… I got Sheeple up and running in LW64. It needed only a minor change in the GC function. Whether it is completely correct or not, I cannot tell just yet. Both EOS and FIVEAM need a more advanced form of ASDF than is built into LW64 Version 7.1. But the examples on the GitHub page seem to work just fine. Thanks for that! I’ll roll my sleeves up and dig in…
ASDF is self-upgrading. Just download the latest release git branch into ~/common-lisp/asdf/ That said, my lispworks 7.0.0 has a pretty recent ASDF 3.1.4. Just how recent an ASDF do you need? fiveam only needs asdf 3.1. Is your LispWorks actually a 6.x? The LispWorks site advertises 7.0.0, and 6.1.1 for the Personal Edition, but no 7.1. (NB: self-upgrading from ASDF 2 is also possible, but requires more work.)
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Life is like an onion: you peel off layer after layer, then you find there is nothing in it.
On Sat, Jul 2, 2016 at 12:50 PM, David McClain dbm@refined-audiometrics.com wrote:
Yep, my bad… I just looked at the About box - I’m running LW 7.0/64. And thanks for the info on ASDF. My (ASDF-VERSION) shows 1.627. That’s what was delivered with LW 7.0. I’ll try to update ASDF now.
1.627 is ancient. Like, February 2010, during the transition between ASDF 1 and ASDF 2.
That's weird, because IIRC, LW 6.1.1 used to ship ASDF 2 (I don't remember which), and LW 7.0.0 was famous for being the last maintained Lisp to ship ASDF 3.
I recommend using the script in .../asdf/tools/install-asdf.lisp to install a newer ASDF on top of the old one.
-#f
Wow! My bad again! I just found that my system had been running an ancient version of ASDF because of crufty old 20 year old code laying around that had been running forever… Once I cleaned that out, I found that LW 7 has ASDF 3.1.4 already installed.
I managed to load up EOS and run the Sheeple self tests. Results show that everything is fine. The GC code in Sheeple needs a slight change to run in LW/64 since MARK-AND-SWEEP is not present in the 64-bit version of LW. But otherwise, all tests seem to have performed without error.
- DM
On Jul 2, 2016, at 09:30, Faré fahree@gmail.com wrote:
On Sat, Jul 2, 2016 at 12:18 PM, David McClain dbm@refined-audiometrics.com wrote:
… I got Sheeple up and running in LW64. It needed only a minor change in the GC function. Whether it is completely correct or not, I cannot tell just yet. Both EOS and FIVEAM need a more advanced form of ASDF than is built into LW64 Version 7.1. But the examples on the GitHub page seem to work just fine. Thanks for that! I’ll roll my sleeves up and dig in…
ASDF is self-upgrading. Just download the latest release git branch into ~/common-lisp/asdf/ That said, my lispworks 7.0.0 has a pretty recent ASDF 3.1.4. Just how recent an ASDF do you need? fiveam only needs asdf 3.1. Is your LispWorks actually a 6.x? The LispWorks site advertises 7.0.0, and 6.1.1 for the Personal Edition, but no 7.1. (NB: self-upgrading from ASDF 2 is also possible, but requires more work.)
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Life is like an onion: you peel off layer after layer, then you find there is nothing in it.
Okay! Well, I can certainly see how Prototype Programming in Lisp could become addictive… I think I’ll try recasting some of my apps into this style to see where the good, bad, and ugly arise…
Many thanks to you all!
- DM
Don't forget ClojureScript.
I had Cells ported to Clojure in a week or two and one more week had it running in the browser (via cljs): https://github.com/kennytilton/rube
More featureful than CL Cells, to boot, though backporting would be trivial.
-hk
On Sat, Jul 2, 2016 at 1:52 PM, David McClain dbm@refined-audiometrics.com wrote:
Okay! Well, I can certainly see how Prototype Programming in Lisp could become addictive… I think I’ll try recasting some of my apps into this style to see where the good, bad, and ugly arise…
Many thanks to you all!
- DM
interesting… I recall your Cells as being a reactive programming framework. Do you find Clojure to be truly useful? or is it just a fad in passing?
- DM
On Jul 3, 2016, at 11:58, Kenneth Tilton ken@tiltontec.com wrote:
Don't forget ClojureScript.
I had Cells ported to Clojure in a week or two and one more week had it running in the browser (via cljs): https://github.com/kennytilton/rube https://github.com/kennytilton/rube
More featureful than CL Cells, to boot, though backporting would be trivial.
-hk
On Sat, Jul 2, 2016 at 1:52 PM, David McClain <dbm@refined-audiometrics.com mailto:dbm@refined-audiometrics.com> wrote: Okay! Well, I can certainly see how Prototype Programming in Lisp could become addictive… I think I’ll try recasting some of my apps into this style to see where the good, bad, and ugly arise…
Many thanks to you all!
- DM
-- Kenneth Tilton
Lisper/Clojurian for hire
Common Lisp + qooxdoo sample: http://tiltonsalgebra.com http://tiltonsalgebra.com/ Cells for Clojure/Clojurescript: https://github.com/kennytilton/rube https://github.com/kennytilton/rube Clojurescript + qooxdoo mobile JS + Cells: https://github.com/kennytilton/ https://github.com/kennytilton/rubeqxia
On Sun, Jul 3, 2016 at 4:15 PM, David McClain dbm@refined-audiometrics.com wrote:
interesting… I recall your Cells as being a reactive programming framework.
Yep.
Do you find Clojure to be truly useful? or is it just a fad in passing?
Definitely not a fad. I still prefer Common Lisp but Clojure has a lot of things going for it so right now I am withholding final judgment.
The community is really jumping and while still small the job market is real and growing. I think all the best Java developers are getting into it.
ClojureScript alone is a very big win.
-kt
Hi Ken,
Not to put too much of a damper on your enthusiasm, but can you suggest solid technical reasons for migrating from Common Lisp to Clojure? I don’t do web programming. I do machine control, image processing, DSP audio processing, cryptography research, etc. I have never programmed a web page in my life, and probably never will.
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, under the control of one individual, with lots of cheerleading from the small audience. Perhaps it has now matured? I have seen the jobs posted for Clojure programmers, but that doesn’t motivate me in particular. And I know essentially nothing of the Java world, and whether or not it is a good thing that they are migrating to Clojure.
Not trying to pick a fight. But looking for some meat in the arguments.
Cheers,
- DM
On Jul 3, 2016, at 13:28, Kenneth Tilton ken@tiltontec.com wrote:
On Sun, Jul 3, 2016 at 4:15 PM, David McClain <dbm@refined-audiometrics.com mailto:dbm@refined-audiometrics.com> wrote: interesting… I recall your Cells as being a reactive programming framework.
Yep.
Do you find Clojure to be truly useful? or is it just a fad in passing?
Definitely not a fad. I still prefer Common Lisp but Clojure has a lot of things going for it so right now I am withholding final judgment.
The community is really jumping and while still small the job market is real and growing. I think all the best Java developers are getting into it.
ClojureScript alone is a very big win.
-kt
On Sun, Jul 3, 2016 at 7:25 PM, David McClain dbm@refined-audiometrics.com wrote:
Hi Ken,
Not to put too much of a damper on your enthusiasm,
No enthusiasm. As I said, I prefer Common Lisp. You asked if it was a fad, I said "No" and provided the indicators I see.
but can you suggest solid technical reasons for migrating from Common Lisp to Clojure? I don’t do web programming.
No, I prefer CL. I was responding to this from you:
" I’m finding myself being dragged into a “new” world centering on
Javascript and prototype based programming. "
So I suggested ClojureScript (if you have that option.)
I do machine control, image processing, DSP audio processing, cryptography research, etc. I have never programmed a web page in my life, and probably never will.
So what is the Javascript for? A node.js app of some kind?
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, under the control of one individual, with lots of cheerleading from the small audience. Perhaps it has now matured?
I just started using it three months ago because I am looking for a job, so I cannot offer much on growth over the years. I do know a few folks now add to the core, and the product is very stable, solid, and mature.
And again, Clojurescript is amazing. Cells is fairly intense and once I had it ported to Clojure it took just a week to get it running on CLJS (most of that do to some source code reorg in re macros forced by the CLJS->JS compilation chain. So in the context of "OMG! Ihave to do JS" I offered my recommendation.
Not that cljs will save you from the prototype model. :)
best, kt
Hi Ken,
The Javascript is imposed on me from outside. My tools (TheSkyX and PixInsight) are both wedded to Javascript. But that offers essentially no executive control — state that must be kept aware of wider context. So I generally do all my control from Lisp and issue snippets of JS across a network connection to the tools. My Lisp code keeps aware of context and state and the JS provides only immediate commands to the tools.
- DM
On Jul 3, 2016, at 16:46, Kenneth Tilton ken@tiltontec.com wrote:
On Sun, Jul 3, 2016 at 7:25 PM, David McClain <dbm@refined-audiometrics.com mailto:dbm@refined-audiometrics.com> wrote: Hi Ken,
Not to put too much of a damper on your enthusiasm,
No enthusiasm. As I said, I prefer Common Lisp. You asked if it was a fad, I said "No" and provided the indicators I see.
but can you suggest solid technical reasons for migrating from Common Lisp to Clojure? I don’t do web programming.
No, I prefer CL. I was responding to this from you:
" I’m finding myself being dragged into a “new” world centering on Javascript and prototype based programming. "
So I suggested ClojureScript (if you have that option.)
I do machine control, image processing, DSP audio processing, cryptography research, etc. I have never programmed a web page in my life, and probably never will.
So what is the Javascript for? A node.js app of some kind?
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, under the control of one individual, with lots of cheerleading from the small audience. Perhaps it has now matured?
I just started using it three months ago because I am looking for a job, so I cannot offer much on growth over the years. I do know a few folks now add to the core, and the product is very stable, solid, and mature.
And again, Clojurescript is amazing. Cells is fairly intense and once I had it ported to Clojure it took just a week to get it running on CLJS (most of that do to some source code reorg in re macros forced by the CLJS->JS compilation chain. So in the context of "OMG! Ihave to do JS" I offered my recommendation.
Not that cljs will save you from the prototype model. :)
best, kt
An example may help… TheSkyX is a telescope control system for an equatorial mount known as a Paramount. This is a high quality telescope mount with tracking of stars. It can interface not only to the mount, but also to cameras for imaging and autoguiding. But it has limits. An autoguider camera mounted on the side of a telescope suffers some degree of differential flexure and so the guide camera gradually drifts away from where the imaging camera wants to be centered. If left to the autoguider control in TheSkyX control program, long exposures would develop streaked star images.
So in response to that problem, I have a little “Kicker” program, written in Lisp, running alongside TheSkyX, that computes the rate of change in differential flexure during the tracking. It prods TheSkyX with changing positions as to where it should expect the guide star to be. In effect I’m fooling the autoguider into doing the right thing in the face of changing differential flexure.
My wider context for control is the location in the sky where I am pointed with the imaging camera, and the current time. Javascript does not have a concept of saved state, which could allow for differential nudges relative to the previous nudge. Instead, I keep that information updated in the Lisp executive and offer just the blind differential nudges every minute to TheSkyX.
- DM
On Jul 3, 2016, at 18:18, David McClain dbm@refined-audiometrics.com wrote:
Hi Ken,
The Javascript is imposed on me from outside. My tools (TheSkyX and PixInsight) are both wedded to Javascript. But that offers essentially no executive control — state that must be kept aware of wider context. So I generally do all my control from Lisp and issue snippets of JS across a network connection to the tools. My Lisp code keeps aware of context and state and the JS provides only immediate commands to the tools.
- DM
On Jul 3, 2016, at 16:46, Kenneth Tilton <ken@tiltontec.com mailto:ken@tiltontec.com> wrote:
On Sun, Jul 3, 2016 at 7:25 PM, David McClain <dbm@refined-audiometrics.com mailto:dbm@refined-audiometrics.com> wrote: Hi Ken,
Not to put too much of a damper on your enthusiasm,
No enthusiasm. As I said, I prefer Common Lisp. You asked if it was a fad, I said "No" and provided the indicators I see.
but can you suggest solid technical reasons for migrating from Common Lisp to Clojure? I don’t do web programming.
No, I prefer CL. I was responding to this from you:
" I’m finding myself being dragged into a “new” world centering on Javascript and prototype based programming. "
So I suggested ClojureScript (if you have that option.)
I do machine control, image processing, DSP audio processing, cryptography research, etc. I have never programmed a web page in my life, and probably never will.
So what is the Javascript for? A node.js app of some kind?
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, under the control of one individual, with lots of cheerleading from the small audience. Perhaps it has now matured?
I just started using it three months ago because I am looking for a job, so I cannot offer much on growth over the years. I do know a few folks now add to the core, and the product is very stable, solid, and mature.
And again, Clojurescript is amazing. Cells is fairly intense and once I had it ported to Clojure it took just a week to get it running on CLJS (most of that do to some source code reorg in re macros forced by the CLJS->JS compilation chain. So in the context of "OMG! Ihave to do JS" I offered my recommendation.
Not that cljs will save you from the prototype model. :)
best, kt
So I generally do all my control from Lisp and issue snippets of JS across a network connection to the tools.
That is how I program web apps: send snippets of JS back on each XHR.
With CLJS and Qooxdoo mobile the whole system lives on the client, simplifying a lot of the coordination I had to do between server and client.
Sounds like you need Cells running in JS managing everything. You just send over one program that takes care of everything, all in a declarative modelling paradigm.
Note that your bias (and mine) is that you want to program the devices in Lisp, not JS. With CLJS you would be programming them in a Lisp.
-kt
On Sun, Jul 3, 2016 at 9:26 PM, David McClain dbm@refined-audiometrics.com wrote:
An example may help… TheSkyX is a telescope control system for an equatorial mount known as a Paramount. This is a high quality telescope mount with tracking of stars. It can interface not only to the mount, but also to cameras for imaging and autoguiding. But it has limits. An autoguider camera mounted on the side of a telescope suffers some degree of differential flexure and so the guide camera gradually drifts away from where the imaging camera wants to be centered. If left to the autoguider control in TheSkyX control program, long exposures would develop streaked star images.
So in response to that problem, I have a little “Kicker” program, written in Lisp, running alongside TheSkyX, that computes the rate of change in differential flexure during the tracking. It prods TheSkyX with changing positions as to where it should expect the guide star to be. In effect I’m fooling the autoguider into doing the right thing in the face of changing differential flexure.
My wider context for control is the location in the sky where I am pointed with the imaging camera, and the current time. Javascript does not have a concept of saved state, which could allow for differential nudges relative to the previous nudge. Instead, I keep that information updated in the Lisp executive and offer just the blind differential nudges every minute to TheSkyX.
- DM
On Jul 3, 2016, at 18:18, David McClain dbm@refined-audiometrics.com wrote:
Hi Ken,
The Javascript is imposed on me from outside. My tools (TheSkyX and PixInsight) are both wedded to Javascript. But that offers essentially no executive control — state that must be kept aware of wider context. So I generally do all my control from Lisp and issue snippets of JS across a network connection to the tools. My Lisp code keeps aware of context and state and the JS provides only immediate commands to the tools.
- DM
On Jul 3, 2016, at 16:46, Kenneth Tilton ken@tiltontec.com wrote:
On Sun, Jul 3, 2016 at 7:25 PM, David McClain < dbm@refined-audiometrics.com> wrote:
Hi Ken,
Not to put too much of a damper on your enthusiasm,
No enthusiasm. As I said, I prefer Common Lisp. You asked if it was a fad, I said "No" and provided the indicators I see.
but can you suggest solid technical reasons for migrating from Common Lisp to Clojure? I don’t do web programming.
No, I prefer CL. I was responding to this from you:
" I’m finding myself being dragged into a “new” world centering on
Javascript and prototype based programming. "
So I suggested ClojureScript (if you have that option.)
I do machine control, image processing, DSP audio processing, cryptography research, etc. I have never programmed a web page in my life, and probably never will.
So what is the Javascript for? A node.js app of some kind?
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, under the control of one individual, with lots of cheerleading from the small audience. Perhaps it has now matured?
I just started using it three months ago because I am looking for a job, so I cannot offer much on growth over the years. I do know a few folks now add to the core, and the product is very stable, solid, and mature.
And again, Clojurescript is amazing. Cells is fairly intense and once I had it ported to Clojure it took just a week to get it running on CLJS (most of that do to some source code reorg in re macros forced by the CLJS->JS compilation chain. So in the context of "OMG! Ihave to do JS" I offered my recommendation.
Not that cljs will save you from the prototype model. :)
best, kt
Hi Ken,
I think I see what you are recommending. But one of the facts of these external programs is the lack of multi-processing in their JS interpreters. If I sent over one program to maintain state and issue periodic nudges, that would tie up the JS interface for all other possible needs.
Instead, by offering periodic snippets to the JS engine, I leave it mostly available for all other uses. The nudges themselves take only a fraction of a second, issued once per minute.
- DM
On Jul 3, 2016, at 19:09, Kenneth Tilton ken@tiltontec.com wrote:
So I generally do all my control from Lisp and issue snippets of JS across a network connection to the tools.
That is how I program web apps: send snippets of JS back on each XHR.
With CLJS and Qooxdoo mobile the whole system lives on the client, simplifying a lot of the coordination I had to do between server and client.
Sounds like you need Cells running in JS managing everything. You just send over one program that takes care of everything, all in a declarative modelling paradigm.
Note that your bias (and mine) is that you want to program the devices in Lisp, not JS. With CLJS you would be programming them in a Lisp.
-kt
On Sun, Jul 3, 2016 at 9:26 PM, David McClain <dbm@refined-audiometrics.com mailto:dbm@refined-audiometrics.com> wrote: An example may help… TheSkyX is a telescope control system for an equatorial mount known as a Paramount. This is a high quality telescope mount with tracking of stars. It can interface not only to the mount, but also to cameras for imaging and autoguiding. But it has limits. An autoguider camera mounted on the side of a telescope suffers some degree of differential flexure and so the guide camera gradually drifts away from where the imaging camera wants to be centered. If left to the autoguider control in TheSkyX control program, long exposures would develop streaked star images.
So in response to that problem, I have a little “Kicker” program, written in Lisp, running alongside TheSkyX, that computes the rate of change in differential flexure during the tracking. It prods TheSkyX with changing positions as to where it should expect the guide star to be. In effect I’m fooling the autoguider into doing the right thing in the face of changing differential flexure.
My wider context for control is the location in the sky where I am pointed with the imaging camera, and the current time. Javascript does not have a concept of saved state, which could allow for differential nudges relative to the previous nudge. Instead, I keep that information updated in the Lisp executive and offer just the blind differential nudges every minute to TheSkyX.
- DM
On Jul 3, 2016, at 18:18, David McClain <dbm@refined-audiometrics.com mailto:dbm@refined-audiometrics.com> wrote:
Hi Ken,
The Javascript is imposed on me from outside. My tools (TheSkyX and PixInsight) are both wedded to Javascript. But that offers essentially no executive control — state that must be kept aware of wider context. So I generally do all my control from Lisp and issue snippets of JS across a network connection to the tools. My Lisp code keeps aware of context and state and the JS provides only immediate commands to the tools.
- DM
On Jul 3, 2016, at 16:46, Kenneth Tilton <ken@tiltontec.com mailto:ken@tiltontec.com> wrote:
On Sun, Jul 3, 2016 at 7:25 PM, David McClain <dbm@refined-audiometrics.com mailto:dbm@refined-audiometrics.com> wrote: Hi Ken,
Not to put too much of a damper on your enthusiasm,
No enthusiasm. As I said, I prefer Common Lisp. You asked if it was a fad, I said "No" and provided the indicators I see.
but can you suggest solid technical reasons for migrating from Common Lisp to Clojure? I don’t do web programming.
No, I prefer CL. I was responding to this from you:
" I’m finding myself being dragged into a “new” world centering on Javascript and prototype based programming. "
So I suggested ClojureScript (if you have that option.)
I do machine control, image processing, DSP audio processing, cryptography research, etc. I have never programmed a web page in my life, and probably never will.
So what is the Javascript for? A node.js app of some kind?
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, under the control of one individual, with lots of cheerleading from the small audience. Perhaps it has now matured?
I just started using it three months ago because I am looking for a job, so I cannot offer much on growth over the years. I do know a few folks now add to the core, and the product is very stable, solid, and mature.
And again, Clojurescript is amazing. Cells is fairly intense and once I had it ported to Clojure it took just a week to get it running on CLJS (most of that do to some source code reorg in re macros forced by the CLJS->JS compilation chain. So in the context of "OMG! Ihave to do JS" I offered my recommendation.
Not that cljs will save you from the prototype model. :)
best, kt
-- Kenneth Tilton
Lisper/Clojurian for hire
Common Lisp + qooxdoo sample: http://tiltonsalgebra.com http://tiltonsalgebra.com/ Cells for Clojure/Clojurescript: https://github.com/kennytilton/rube https://github.com/kennytilton/rube Clojurescript + qooxdoo mobile JS + Cells: https://github.com/kennytilton/ https://github.com/kennytilton/rubeqxia
On Sun, Jul 3, 2016 at 10:18 PM, David McClain <dbm@refined-audiometrics.com
wrote:
Hi Ken,
I think I see what you are recommending. But one of the facts of these external programs is the lack of multi-processing in their JS interpreters.
JS is always single-threaded. (But CLJS can fake threads -- they really are doing some good work.)
If I sent over one program to maintain state and issue periodic nudges, that would tie up the JS interface for all other possible needs.
The "program" is just a bunch of code and data waiting on events. It is not tying up anything except RAM.
Instead, by offering periodic snippets to the JS engine, I leave it mostly available for all other uses. The nudges themselves take only a fraction of a second, issued once per minute.
Sure, this whole thing works that way: http://tiltonsalgebra.com
btw, controlling telescopes and cameras? I'm jealous! :)
-kt
On 16-07-04 04:08 AM, Kenneth Tilton wrote:
On Sun, Jul 3, 2016 at 10:18 PM, David McClain <dbm@refined-audiometrics.com mailto:dbm@refined-audiometrics.com> wrote:
Hi Ken, I think I see what you are recommending. But one of the facts of these external programs is the lack of multi-processing in their JS interpreters.JS is always single-threaded. (But CLJS can fake threads -- they really are doing some good work.)
Aside: all cpu cores are always single-threaded[*]. Multi-processing is an epicycle[+], an illusion.
If you don't need variables on the stack / full-preemption, nor access to special hardware like mmu's, then writing concurrent programs in js is a breeze (esp. with closures).
See collate-fbp-classic and FBP-from-scratch on https://github.com/guitarvydas or try reading my essays on https://bittarvydas.wordpress.com/.
pt
[*] modulo some kind of hardware assist in modern cpu's. If you understand how to build a multi-tasking O/S on 8-bit cpu's, then you understand how to do this in js (or just about any language) as well.
[+] An epicycle because "we" decided to standardize on subroutines instead of co-routines at Albuquerque [Bugs Bunny].
Hi Paul,
Please forgive my ignorance, but don't the things you advocate require access to, or rewriting of, the JS Server side? Or are you performing this magic from the client side? That’s all I have access to in these foreign tools.
- DM
On Jul 5, 2016, at 09:48, Paul Tarvydas paultarvydas@gmail.com wrote:
On 16-07-04 04:08 AM, Kenneth Tilton wrote:
On Sun, Jul 3, 2016 at 10:18 PM, David McClain <dbm@refined-audiometrics.com mailto:dbm@refined-audiometrics.com> wrote: Hi Ken,
I think I see what you are recommending. But one of the facts of these external programs is the lack of multi-processing in their JS interpreters.
JS is always single-threaded. (But CLJS can fake threads -- they really are doing some good work.)
Aside: all cpu cores are always single-threaded[*]. Multi-processing is an epicycle[+], an illusion.
If you don't need variables on the stack / full-preemption, nor access to special hardware like mmu's, then writing concurrent programs in js is a breeze (esp. with closures).
See collate-fbp-classic and FBP-from-scratch on https://github.com/guitarvydas https://github.com/guitarvydas or try reading my essays onhttps://bittarvydas.wordpress.com/ https://bittarvydas.wordpress.com/.
pt
[*] modulo some kind of hardware assist in modern cpu's. If you understand how to build a multi-tasking O/S on 8-bit cpu's, then you understand how to do this in js (or just about any language) as well.
[+] An epicycle because "we" decided to standardize on subroutines instead of co-routines at Albuquerque [Bugs Bunny].
On 16-07-05 01:31 PM, David McClain wrote:
Hi Paul,
Please forgive my ignorance,
No sweat :-).
but don't the things you advocate require access to, or rewriting of, the JS Server side? Or are you performing this magic from the client side? That’s all I have access to in these foreign tools.
Closures are basically what the RTOS (real-time operating systems) guys call "processes".
The difference between an RTOS process and a closure is that a process *cannot* call it's peers directly, except by resorting to a "special API" called "IPC", handled by the RTOS scheduler.
To duplicate the look-and-feel of processes, one must simply stop allowing oneself to "call" peer routines / closures.
You have a single distinguished routine (called "the scheduler") and you "return" to it. The scheduler maintains a queue of ready-to-run closures and calls them one at a time (in "random" order).
You send "messages" to peer closures (think Actors, CSP, FBP). The scheduler keeps a queue of pending messages (there are many optimizations possible), peels one message off of the queue and invokes a closure with that message.
The closure deals with the message, may produce new messages, then returns to the scheduler. And the cycle repeats.
The closures have to promise to "return promptly" to the scheduler and to not leave any junk (persistent data) on the stack (i.e. use closed-over variables instead of auto variables).
Does what / how I am saying this make sense? I've been beating this horse for a long time and most people don't get it. I would be glad to continue to answer questions.
[Admittedly, I haven't done this on a js client, yet, but I see no road-blocks, my node.js code should port directly].
pt
I strongly recommend Rob Pike's talk "Concurrency is not Parallelism - It's Better" to understand why this is a good way to think.
On Tue, Jul 5, 2016 at 3:06 PM, Paul Tarvydas paultarvydas@gmail.com wrote:
On 16-07-05 01:31 PM, David McClain wrote:
I strongly recommend Rob Pike's talk "Concurrency is not Parallelism - It's Better" to understand why this is a good way to think.
The link that google found is broken, any idea how to find it?
Best, Alexandre
On 16-07-05 02:33 PM, Alexandre Rademaker wrote:
On Tue, Jul 5, 2016 at 3:06 PM, Paul Tarvydas <paultarvydas@gmail.com mailto:paultarvydas@gmail.com> wrote:
On 16-07-05 01:31 PM, David McClain wrote: I strongly recommend Rob Pike's talk "Concurrency is not Parallelism - It's Better" to understand why this is a good way to think.The link that google found is broken, any idea how to find it?
Best, Alexandre
Strange - the original video that I watched in December is 404'ed.
This seems to replace it (2nd slide contains link to video) https://talks.golang.org/2012/waza.slide#1
I guess someone liked the Waza talk better.
The slides look to be about the same (except for the 1st slide is missing the line "It's Better" :-).
pt
… looking through the source code for Sheeple, I am impressed by the quality of the code. Clearly, its authors understand Lisp at a deeper level.
- DM
On Sun, Jul 3, 2016 at 7:25 PM, David McClain dbm@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
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@gmail.com wrote:
On Sun, Jul 3, 2016 at 7:25 PM, David McClain dbm@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@gmail.com http://it-is-what-it-is.treerex.net
I though that ABCL is older than Clojure , am I wrong ?!
One big frustration for me was the error handling ! Errors in Clojure are exposed as Java errors, we don't have the amazing CL handlers.
Alexandre Sent from my iPhone
On 4 de jul de 2016, at 17:07, Tom Emerson tremerson@gmail.com wrote:
On Sun, Jul 3, 2016 at 7:25 PM, David McClain dbm@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@gmail.com http://it-is-what-it-is.treerex.net
ABCL is older, yes. I can't look up the dates now, but it started as an embedded interpreter for the J editor surely more than a decade ago, and even when it became a standalone project I think Clojure was still in Rich's head at best. That said, ABCL never had even .1% of the community Clojure has, which is a pity. ABCL is far from perfect, but with a solid open source community contributing to it, it could do everything Clojure does. Many of Clojure's core features are just a library away:
- immutable data structures -> FSet - concurrency primitives -> LParallel - STM -> CL-STM (I think) - ClojureScript -> Parenscript
etc. The only things that are still missing from ABCL proper are the ability to generate Java classes from Lisp and an easy to use ahead-of-time compiler (to produce libraries readily usable from Java and other languages). The ecosystem is missing more things, like Java IDE plugins and a Java/Maven savvy build tool (I'm sure ASDF could be hacked to become that tool). Clojure once didn't have those, too.
Besides ABCL, there are other Lisps for the JVM, most notably Kawa, a Scheme which has been existing for many years, it's older than ABCL I think.
I don't want to start a war either, and I'm sure Clojure benefits from its clean room design and implementation, but it's sad to see so many wheels reinvented, so much effort wasted.
On 4 July 2016 at 23:17, Alexandre Rademaker arademaker@gmail.com wrote:
I though that ABCL is older than Clojure , am I wrong ?!
One big frustration for me was the error handling ! Errors in Clojure are exposed as Java errors, we don't have the amazing CL handlers.
Alexandre Sent from my iPhone
On 4 de jul de 2016, at 17:07, Tom Emerson tremerson@gmail.com wrote:
On Sun, Jul 3, 2016 at 7:25 PM, David McClain dbm@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@gmail.com http://it-is-what-it-is.treerex.net
I played around with Kawa around the time I joined Sun which was in 1997. So it's at least that old.
Regards, Elias
On 5 July 2016 at 15:34, Alessio Stalla alessiostalla@gmail.com wrote:
ABCL is older, yes. I can't look up the dates now, but it started as an embedded interpreter for the J editor surely more than a decade ago, and even when it became a standalone project I think Clojure was still in Rich's head at best. That said, ABCL never had even .1% of the community Clojure has, which is a pity. ABCL is far from perfect, but with a solid open source community contributing to it, it could do everything Clojure does. Many of Clojure's core features are just a library away:
- immutable data structures -> FSet
- concurrency primitives -> LParallel
- STM -> CL-STM (I think)
- ClojureScript -> Parenscript
etc. The only things that are still missing from ABCL proper are the ability to generate Java classes from Lisp and an easy to use ahead-of-time compiler (to produce libraries readily usable from Java and other languages). The ecosystem is missing more things, like Java IDE plugins and a Java/Maven savvy build tool (I'm sure ASDF could be hacked to become that tool). Clojure once didn't have those, too.
Besides ABCL, there are other Lisps for the JVM, most notably Kawa, a Scheme which has been existing for many years, it's older than ABCL I think.
I don't want to start a war either, and I'm sure Clojure benefits from its clean room design and implementation, but it's sad to see so many wheels reinvented, so much effort wasted.
On 4 July 2016 at 23:17, Alexandre Rademaker arademaker@gmail.com wrote:
I though that ABCL is older than Clojure , am I wrong ?!
One big frustration for me was the error handling ! Errors in Clojure are exposed as Java errors, we don't have the amazing CL handlers.
Alexandre Sent from my iPhone
On 4 de jul de 2016, at 17:07, Tom Emerson tremerson@gmail.com wrote:
On Sun, Jul 3, 2016 at 7:25 PM, David McClain dbm@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@gmail.com http://it-is-what-it-is.treerex.net
-
Alessio Stalla -
Alexandre Rademaker -
David McClain -
Elias Mårtenson -
Faré -
Gene Diveglia -
Kenneth Tilton -
Matthew Mondor -
Paul Tarvydas -
Raymond Wiker -
Tom Emerson