Considering how close Julia is to Lisp, it could be interesting to have an actual Lisp targeting the Julia compiler, for people who don't want to compromise on s-expr but would still want to have a performance oriented Lisp with access to a lot of scientific computation and ML libraries (and probably better interop compared to Clojure and Java for example). The only work I know for this is:<p><a href="https://github.com/swadey/LispSyntax.jl" rel="nofollow">https://github.com/swadey/LispSyntax.jl</a>
Tamas is a very active participant in the Julia ecosystem, so it seems that the switch went pretty well!<p>Julia 1.0 was released a little over a year ago at JuliaCon 2018. At this year's JuliaCon, there was, imo, an even more positive "vibe" than past years, which were already full of excitement. My guess is that it may be because everyone has been really happy to have a year of not breaking things and building cool new stuff on top of the solid foundation of Julia the Julia 1.x series.
I'm using Julia instead of Python/Pandas for a machine learning project and I'm happy with how things are going. Multiple dispatch is very cool. The project was previously written in R, but the performance and lack of programming clarity inspired a re-write in Julia.<p>There is something satisfying about writing code in a high-performance language, you just know you won't be kicking yourself because it would run 10x faster in another language.
Julia is one of my fav languages. For numerical computing, neither python + numpy, nor matlab come even close. The interop is nuts.<p>To call, say numpy fft, you just do<p>using PyCall<p>np = pyimport("numpy")<p>res = np.fft.fft(rand(ComplexF64, 10))<p>No casting back and forth. This is a toy example, julia ofc has fftw bindings.
Common Lisp folks should really start designing a more modern version of CL.<p>I'm pretty sure some old Lispers would come and say, 'Common Lisp's stability is a great feature', 'There are lots of new dialects', and while they are right in some aspects, Common Lisp isn't appealing to anyone these days. (I mean, even C and C++ is improving. Why shouldn't CL?)<p>Even for people who 'get' the ideas of s-exps and macros, there are too many quirks in CL to appeal to people, and most go to Clojure (where the interactive experience is at best moderate, debbuging support/error handling is a mess, e.g.).<p>I believe the hypothetical CL++ should at least:<p>* Straight out incompatibilites between implementations, especially the numerous opinions to make an image or binary, and the FFI parts.<p>* Design a better CLOS system. CLOS feels like an object system thought after (well, after all it is a system thought after) and bolted on CL with duct tape. I would appreciate a CLOS-based type system (based on macros much like CLOS) that integrates well with CL.<p>* Remove unused functions, and fixing some inconsisties in the standard library<p>* Bigger, much much bigger standard library. Crucial, community-standard libraries like asdf & uiop, syntax-sugar like the arrow/diamond macros, and reader macros that allow infix syntax (this currently exists in the standard but nobody uses it partly because most Lisp users don't really care about infix, partly because it's extensiblity is bad) should be in the std.<p>* A compatibility layer. Providing a 'cl' and 'cl-user' package with the usual CL symbols will be sufficient.<p>to appeal to the users.<p>This really isn't sufficient for the hypothetical CL++ itself; there really should be beginner materials that isn't PCL; Lispers shouldn't hate infix reader macros or syntax-sugar like LOOP(IMHO these show the real power of macros, after all, macros are another tool to write readable code with great abstractions) and beginner materials should use, or at least introduce them(infix reader macros and other syntax sugar).<p>Just a rant about the language after reading the post and becoming sad.
Seems like this:<p><pre><code> You can of course branch on the array element types and maybe even
paper over the whole mess with sufficient macrology (which is what
LLA ended up doing), but this approach is not very extensible, as
eventually you end up hardcoding a few special types for which your
functions will be "fast", otherwise they have to fall back to a
generic, boxed type.
</code></pre>
is exactly what numpy/scipy is doing (s/macrology/c-functions/), but they are successful.. granted julia has more ground-up support for these things, but it doesn't seem like an impediment to scientific computing per-se, provided sufficient userbase
><i>The standard does not guarantee that this gives you an array of double-float: it may (if the implementation provides them), otherwise you get an array of element type T. This turned out to be a major difficulty for implementing portable scientific code in Common Lisp.</i><p>Well, so? Just use a single CL implementation that does give you the guarantee.<p>After all you are now switching to use a single Julia implementation (there's no other anyway).<p>If portability is a concern, at least with CL you can always port 95% of your code to several implementations, and then write special code those kind of incompatibilities. With Julia one platform is all you get.<p>So how's that better, from the point of this complaint?
<p><pre><code> I was thinking about this the other day. How can I expose my Common Lisp code to Julia.
</code></pre>
1. You could take the Clasp path by exposing CL to C++. <a href="https://youtu.be/8X69_42Mj-g" rel="nofollow">https://youtu.be/8X69_42Mj-g</a><p><pre><code> This means taking / writing a CL in Julia.
</code></pre>
2. Julia has an AST representation written in femtolisp. So it would be in interesting target for CL or some glue middle language like Shen. <a href="http://www.shenlanguage.org/" rel="nofollow">http://www.shenlanguage.org/</a>
<a href="https://youtu.be/lMcRBdSdO_U" rel="nofollow">https://youtu.be/lMcRBdSdO_U</a>
For numeric work in CL, one might like Numcl, a clone of Numpy: <a href="https://github.com/numcl/numcl" rel="nofollow">https://github.com/numcl/numcl</a>
I don't know why no one seems to think about symbolic programming which was the original killer feature of lisp, and one of the main reasons for doing macros.<p>In math oriented programming this should be one of the most powerful features and skills in order to simplify and modify calculations. Sure you can implement that with macros and AST but that is not at the level of S-Expressions.<p>Everything else is not more important as any other competition of DSLs.
As far as I know, parts of the Julia parser is still written in a Lisp variant called Femtolisp.<p>Also one can run Femtolisp by executing:<p>julia --lisp
Discussed at the time: <a href="https://news.ycombinator.com/item?id=15478131" rel="nofollow">https://news.ycombinator.com/item?id=15478131</a>
Off the topic but,<p>Why keep reinventing the wheel when there's an ML language family already? Why do people keep giving up these juicy Hindley—Milner-ish type systems and these brief and concise equations for anything? It just doesn't make sense for me.