The parser of the Julia compiler is written in this dialect. It just goes to show how much power you have in a small package with lisps.
(Not to detract from Julia devs but there were plenty of Lisp based contenders ready for scientific computing before so its useful to ask why Julia why now etc )
*edit: this was kinda snarky but I actually meant a compliment on the excellent strategic choices Julia devs made as compared to other scientific computing attempts
Any examples?
Common Lisp has been used in scientific computing since decades, so in some sense it's "ready". Also, see CLASP: lisp at the state of the art of computational chemistry.
numcl, a numpy clone in Common Lisp - https://github.com/numcl/numcl
Clojure kixi-stats- https://cljdoc.org/d/kixi/stats/0.5.0/doc/readme
and the book Clojure for Data Science - http://clojuredatascience.com/
Clojure's Incanter has been mentioned already - http://incanter.org/
OWL, the OCaml Scientific Computing project - https://ocaml.xyz/
And probably not quite what you're looking for, but there is a Racket data frame structure which provides some data science like manipulation capabilities - https://alex-hhh.github.io/2018/08/racket-data-frame.html
Appreciate some of the above are Schemes and not Lisps, but they may still be interesting.
And when people discover the lispiness in Julia which is a thin layer below the surface syntax (such as the metaprogramming system and multiple dispatch) they at least already gave the language a fairer chance. Other languages that borrowed from Lisp but didn't go, to different degrees, with s-expr like Scala and Clojure (plus R) also had success in the data science/ML area. Hopefully Nim also gets a foothold, and possibly Racket with optional infix syntax.
Yes, and this is practically the only thing that I find wrong with Julia, besides the lack of the interactivity of CL.
It's like populism -- an inferior syntax choice taken just to attract the Pythonistas.
I like being able to do this:
(+ 1 2 3 4 5) 1 + 2 + 3 + 4 + 5
+(1, 2, 3, 4, 5)
>Lisp Mode
I wish every language had Lisp Mode, haha
Of course, LispSyntax.jl still has some glaring omissions that someone should really get around to implementing.
And secondly, Lisp programmers are also human, and more power means more responsibility. When you have a language to create any language, people are tempted to do it, but a language is also a social construct, not just technical (a language only has value if many people talk it, which means documentation, community, support...), and making it so easy to make your own that you end up ignoring that aspect is the Lisp Curse. Modern languages actually see value in limiting the power, by either removing it completely (like Go), or hiding it/making deviations explicit (like Julia's surface syntax and macro identifier '@' which alerts the user that he is deviating from the "first class" language that everyone is supposed to know).
It's one thing that Julia currently does "ok" with, the syntax is fine (albeit slightly more verbose and often more abstract), but the iteration speed gets fairly nasty when you're not doing big computations or need to rapidly iterate, in which the JIT can take awhile to warm up. There are things you can do, but it's still a lot slower for day to day work for a lot of MATLAB users.
At least in my opinion. I tried to switch to Julia from GNU Octave (from which I moved from MATLAB proper) for a lot of hobby controls/DSP work and it was just a pain to iterate and explore ideas with. Same with Python imo as well.
This is a very hard truth for the more aspbergery wing of lisp users to accept.
Generally, s-expressions is not a particular popular or needed tool. We've seen similar systems for code data&representations though - for example XML was used to represent code, too.
```
julia
julia> include("file.jl") # when you want to reload, ctrl-c then arrow-up and enter to include again
```
This isn't so dissimilar to MATLAB in some respects: you don't restart MATLAB every time you want to re-run your code.
julia> includet("file.jl") # Notice the final 't' in 'includet'
This will cause file.jl to get automatically reloaded whenever it is changed.
Plenty of inside info on these comment threads.
As someone who is a Julia fan, but has a background from mathematics rather than computer science, I don't agree. Julia syntax resembles mathematics only on a very superficial typographic level that have little actual significance when reading or writing code.
Mathematical notation, unlike code, is fundamentally two-dimensional, with vertically written fractions, subscripts and superscripts, etc. Simple mathematical expressions are easy to read in both Julia and S-expression notation. More complicated expressions are hard to read in Julia (I sometimes have to write them out by hand on paper in order to understand them), while the same expressions written in properly indented S-expression syntax with a generous use of newlines are easy to read. They are somehow structurally more similar to standard 2-dimensional mathematical notation, despite the superficial infix vs prefix differences.
What attracted me in the first place to Common Lisp (my first programming language) as a person with no technical skills or experience was the friendly and intuitive syntax. It was the first programming language I saw that didn't look visually intimidating. These days I use Julia, but I use it for the awesome features, libraries and community, not for the syntax. I would love Julia even more if it used S-expressions.
And as Julia gets more mature and popular, I wouldn't be surprised if more people notice the strength of it's ecosystem and start creating new language that targets it, just like Elixir and Erlang or all JVM machines (and something more than just reader macros like LispSyntax.jl, like having full editor support and exclusive features that makes it unique compared to Julia). A JuliaLisp could have an amazing interop with the main language, and serve as an alternative for those who prefer s-expr.
* this is intentionally under-specified, but to me it means some nontrivial subset of matlab/numpy functionality
“Downloadable Windows LA REPL” was a criteria Julia met within ~6-8 months of public release, and it was one of the reasons I got involved even though I only ever use(d) windows at work (...mostly for scientific instrumentation which shipped with and only supported windows).
This is slowly changing, but IMO windows support is still table stakes for a scientific computing environment, and seeing windows support meant both that I could use it where I most needed it, and signaled that Julia had potential for real traction (not abandoning >70% of users out of the gate). I think windows support is also one of the reasons Python/NumPy got to be where it is — it wasn’t always perfect, but they at least cared about windows, more so than most other scripting languages in the mid-2000s. Ditto CMake.
In all seriousness that's probably the quickest way, if by 'lisp' you mean 's-expressions'.
For a real lisp, maybe these Numpy bindings[0] for Chez Scheme? Although the py-* names look a bit awkward. You could easily rebind those, but maybe that's not "out of the box" enough.
julia --lisp