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