Earlier quoted context omitted.
Using modern Clojure's clj is so much easier than the CL procedure.
Until you have to deal with unintelligible Java stack traces.
They are intelligible if you know Java and Clojure 1.10 improved stack traces.
Scripting in Common Lisp
31–40 of 41 posts
Re: Scripting in Common Lisp
#32I'm somewhat baffled that Hy didn't gain any traction. Let's review the facts: - A lot of people love Python. - Plenty of people love Lisps, afaict with a sizeable overlap with the first group. - Hy, which is a Lisp on the Python platform, has no popularity whatsoever compared to other Lisps like Clojure. The heck?
Hy may have changed since I last looked at it, but when I had looked at it, Hy was more of an s-expression syntax bolted onto python. Some random thoughts on why this matters: Clojure is very much not a thin s-expression layer for java; that would have been terrible (Python is more like lisp than java which is why Hy is tenable whatsoever). In particular, CL style macros with out some first-class concept of symbols a…
I'm actually interested in what other problems make Hy and similar languages infeasible. Even if a brief overview, as food for thought on the matter.
Re: Scripting in Common Lisp
#33Earlier quoted context omitted.
Until you have to deal with unintelligible Java stack traces.
They are intelligible if you know Java and Clojure 1.10 improved stack traces.
Yup.
Common Lisp stack traces tend to be no better, anyway, at least with SBCL and CCL. Up to 90% of a trace you see in the inspector can be compiler/runtime infrastructure. Given that macros don't show up, only their expansions, the backtrace can be full of stuff like SB-KERNEL:%FUNCTION-THAT-I-DONT-RECOGNIZE-BUT-MACROEXPANDED-FROM-SOMETHING-I-KNOW.
Like in Java, most of the time the top few lines are the ones related to your code, but just like in Java, there are exceptions, in which the source of the problem ends up in the middle of the backtrace, surrounded by infrastructure frames.
Re: Scripting in Common Lisp
#34Pretty nice considering the speed and capabilities of [SB]CL relative to other mainstream scripting languages.
I shy away from CL scripting due to runtime startup time, though if you compile it down to binary it's manageable (if one doesn't mind a 50MB executable).
That said, I wonder why nobody tried a "hybrid" solution, in which the multi-call binary is implemented as a resident, self-restarting process, that executes each request in a lightweight sandbox. Actual shell commands would then be implemented as a request to that process, and incur only the costs of setting up IO streams on startup.
Re: Scripting in Common Lisp
#35Earlier quoted context omitted.
They are intelligible if you know Java and Clojure 1.10 improved stack traces.
Yup. Common Lisp stack traces tend to be no better, anyway, at least with SBCL and CCL. Up to 90% of a trace you see in the inspector can be compiler/runtime infrastructure. Given that macros don't show up, only their expansions, the backtrace can be full of stuff like SB-KERNEL:%FUNCTION-THAT-I-DONT-RECOGNIZE-BUT-MACROEXPANDED-FROM-SOMETHING-I-KNOW. Like in Java, most of the time the top few lines are the ones relat…
[deleted]
Re: Scripting in Common Lisp
#36Pretty nice considering the speed and capabilities of [SB]CL relative to other mainstream scripting languages.
I shy away from CL scripting due to runtime startup time, though if you compile it down to binary it's manageable (if one doesn't mind a 50MB executable). That said, I wonder why nobody tried a "hybrid" solution, in which the multi-call binary is implemented as a resident, self-restarting process, that executes each request in a lightweight sandbox. Actual shell commands would then be implemented as a request to that…
what CL implementation ? sbcl ? I don't know what's the leanest CL out there (even if not the most featured, since we're talking about short scripts)
Re: Scripting in Common Lisp
#37Earlier quoted context omitted.
I shy away from CL scripting due to runtime startup time, though if you compile it down to binary it's manageable (if one doesn't mind a 50MB executable). That said, I wonder why nobody tried a "hybrid" solution, in which the multi-call binary is implemented as a resident, self-restarting process, that executes each request in a lightweight sandbox. Actual shell commands would then be implemented as a request to that…
what CL implementation ? sbcl ? I don't know what's the leanest CL out there (even if not the most featured, since we're talking about short scripts)
SBCL mostly. I probably should give GCL a try here. SBCL is fast as hell once it starts up, and bare SBCL starts up quickly, but once you add Quicklisp and start loading external systems, the startup time gets noticeable - though again, this gets reduced quickly iff you dump a binary of your image with dependencies already loaded. The one CL script I wrote that I actually use[0] (for controlling Hue lamps) I have dumped into binary just to cut down startup time to below the point I notice.
--
Re: Scripting in Common Lisp
#38Earlier quoted context omitted.
what CL implementation ? sbcl ? I don't know what's the leanest CL out there (even if not the most featured, since we're talking about short scripts)
SBCL mostly. I probably should give GCL a try here. SBCL is fast as hell once it starts up, and bare SBCL starts up quickly, but once you add Quicklisp and start loading external systems, the startup time gets noticeable - though again, this gets reduced quickly iff you dump a binary of your image with dependencies already loaded. The one CL script I wrote that I actually use[0] (for controlling Hue lamps) I have dum…
SBCL does have a tiny delay (akin to a raw JVM). CLISP is near interactive though. But that's without quicklisp.
Re: Scripting in Common Lisp
#39Earlier quoted context omitted.
Hy may have changed since I last looked at it, but when I had looked at it, Hy was more of an s-expression syntax bolted onto python. Some random thoughts on why this matters: Clojure is very much not a thin s-expression layer for java; that would have been terrible (Python is more like lisp than java which is why Hy is tenable whatsoever). In particular, CL style macros with out some first-class concept of symbols a…
I'm actually interested in what other problems make Hy and similar languages infeasible. Even if a brief overview, as food for thought on the matter.
They aren't infeasible; a real lisp could target Python. However, just bolting on lisp syntax to python ends up in an uncanny valley of "not python" and also "not lisp."
I would actually recommend watching the entire youtube video I posted earlier (Clojure for Lisp programmers). Rich talks about a lot of the design decisions that went into Clojure. Some decisions I agree with, some I don't, but there was thought into creating a unified whole and he was clearly aware of work that had gone before, even when he chose to do things differently.
Note also that Clojure was his third attempt at doing a lisp/java interop, so there was a lot of previous experience backing many of those decisions.
Lastly, it's really easy to make a bad lisp-frontend for a language and a massive amount of work to make a good one. This is well known by anyone who has been in the lisp community for a while (if for no other reason than they themselves have made a bad one) so for better or worse, such frontends tend to be ignored.
Re: Scripting in Common Lisp
#40This is a great guide, and solving quick real problems is how people get started programming in general. I think seeing scsh for the first time made me realize just how good & bad shells are.
> I think seeing scsh for the first time made me realize just how good & bad shells are. Oddly enough, just last week I was trying to do some scsh-like things with Common Lisp, and I ended up banging my ahead against its case-mapping behaviour (Common Lisp upcases input by default). There’s definitely an opening for a Lisp version of something like scsh. There’s some tricky stuff to be aware of (e.g. SBCL’s RUN-PROGR…
Setting case to invert by default fixes a lot of those problems (you just invert the case again before passing the string onto the shell).
Also, for doing many shell things fork/execv is the only thing that gives you sufficient control, so I suggest avoiding run-program and using those instead.