Our great sponsors
-
-
coalton
Coalton is an efficient, statically typed functional programming language that supercharges Common Lisp.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
Fortunately doing infix math in CL has since the 90s been one small library include away: https://github.com/quil-lang/cmu-infix
I can agree it's not the same, but what's the point? A more interesting disagreement is that I wouldn't say it's a downside (though yes, there are tradeoffs). Especially in Current Year when open source is fashionable and pretty much every language has a package manager to make pulling in or swapping out dependencies pretty easy, I don't see the issue. It's also interesting to note that of all the things Clojure did to "fix" shortcomings of past languages with a more opinionated (and often more correct I'll admit) design philosophy that users are forced to use (even when it's not more correct), infix-math-out-of-the-box wasn't one of them. I don't think that specifically really hurt Clojure adoption. (But of course Clojure is reasonably extensible too so it also has a macro package to get the functionality, though it's more fragile especially around needing spaces because it's not done with reader macros.)
I've brought the library up many times because CL, unlike so many other languages, really lets you extend it. Want a static type system? https://github.com/coalton-lang/coalton/ Want pattern matching? No need to wait for PEP 636, https://github.com/guicho271828/trivia/ If all that keeps someone from trying CL, or from enjoying it as much as they could because of some frustration or another, due to lacking out of the box, chances are it is available through a library.
I can agree it's not the same, but what's the point? A more interesting disagreement is that I wouldn't say it's a downside (though yes, there are tradeoffs). Especially in Current Year when open source is fashionable and pretty much every language has a package manager to make pulling in or swapping out dependencies pretty easy, I don't see the issue. It's also interesting to note that of all the things Clojure did to "fix" shortcomings of past languages with a more opinionated (and often more correct I'll admit) design philosophy that users are forced to use (even when it's not more correct), infix-math-out-of-the-box wasn't one of them. I don't think that specifically really hurt Clojure adoption. (But of course Clojure is reasonably extensible too so it also has a macro package to get the functionality, though it's more fragile especially around needing spaces because it's not done with reader macros.)
I've brought the library up many times because CL, unlike so many other languages, really lets you extend it. Want a static type system? https://github.com/coalton-lang/coalton/ Want pattern matching? No need to wait for PEP 636, https://github.com/guicho271828/trivia/ If all that keeps someone from trying CL, or from enjoying it as much as they could because of some frustration or another, due to lacking out of the box, chances are it is available through a library.
I was looking for a new data notebook toy to ease the tedium of reporting some metrics.
I found the clojure-based https://github.com/nextjournal/clerk which I like the look of and remember clojure being rather pleasing interactively.
That lisp and Julia might have some commonality made me look for something similar (that isn't jupyter) for Julia. Seems like https://github.com/fonsp/Pluto.jl is such a thing.
Does anyone have any experience of either they could share?
I was looking for a new data notebook toy to ease the tedium of reporting some metrics.
I found the clojure-based https://github.com/nextjournal/clerk which I like the look of and remember clojure being rather pleasing interactively.
That lisp and Julia might have some commonality made me look for something similar (that isn't jupyter) for Julia. Seems like https://github.com/fonsp/Pluto.jl is such a thing.
Does anyone have any experience of either they could share?
I agree you can make arguments, I like your explanation for the final form further downthread. For the second form, another choice could be (.x foo) or (. foo x). Or if you're trying to write something like System.out.println("x"), Clojure's .. shows it could be written as (.. System out (println "x")). Or, if you're using CL, you can use the access library (https://github.com/AccelerationNet/access) and write things like #Dfoo.bar.bast or (with-dot () (do-thing whatever.thing another.thing)).
In trying to further steelman a case where random Lisp syntax can be more difficult to read than, say, equivalent Python, two other areas come to mind. First is the inside-outness order of operations thing, it trips people up sometimes. Like the famous "REPL" (with a bad printer) is just (loop (print (eval (read)))), but in English we want to see that as LPER. Solutions include things like the arrow macro (Clojure did good work on showcasing it and other simple macros that can resolve this issue in many places) and if you write/pull one into CL REPL becomes (-> (read) (eval) (print) (loop)), how nice to read. But even the ancient let/let* forms allow you to express a more linear version of something, and you can avoid some instances of the problem with just general programming taste on expression complexity (an issue with all languages -- https://grugbrain.dev/#grug-on-expression-complexity ).
The second area is on functions that have multiple exit points. A lot of Lispers seem to just not like return-from, and will convert things into cond expressions or similar or just say no to early-exits. The solution here I think comes from both ends, the first is a broader cultural norm spreading in other languages against functions with multiple return statements and getting used to code written that way, the other is to just not get so upset about return-from and use it when it makes the code nicer to read.