From Common Lisp to Julia

Here&#x27;s a thorough answer by someone who has worked a lot on types, optimizations and numerical libraries, and who still uses Python as his first language (for academic purposes):<p>Why not: from Common Lisp to Julia<p><a href="https:&#x2F;&#x2F;gist.github.com&#x2F;digikar99&#x2F;24decb414ddfa15a220b27f6748165d7" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;digikar99&#x2F;24decb414ddfa15a220b27f674...</a>

I wish Julia moved away from using abstract types and concrete types and moved away from &quot;inheritance&quot;, and instead decided to tackle traits full on. Traits in Julia are SO powerful but currently are hacky or third party enabled with weird odd syntax. The built in abstract type system should really just be deprecated in favor of a generic trait system, because otherwise people will learn that way of programming which is (imho) a less expressive way to represent the same problem.<p>What are the chances of that happening for Julia 2.0? It feels unlikely. Julia is SO close to being an objectively perfect programming language. With more and more things being compiled ahead of time, it&#x27;ll replace all my needs for Go. I still might use Rust though :)

&gt; Getting help is also often a problem. Experienced Common Lispers assume a basic understanding of the language, good style practice, and familiarity with Emacs and the associated Common Lisp tooling installed. Asking for help as a beginner, and posting a small snippet of code, more often than not results in a wall of text of replies asking the user to fix their style before they can consider helping. This is quite disuading as a newcomer, and detracts from the user&#x27;s learning path. In extreme cases, which are not rare at all, the community can be quite inflammatory towards newcomer questions, as they often get very upset over incorrect terminology or improperly formatted code.<p>It’s a shame to see such posts as you were a cordial and enjoyable member of the IRC community for quite some time. For me, it’s one of the better IRC channels out there and I learnt a lot from the PROFESSORS of computer science who regularly helped newcomers in the channel #clschool. [lisp123]<p>Otherwise glad to see you have found something enjoyable and curious on how you have pivoted away from CLOS, maybe I should investigate Julia too

Stefan Karpinski (one of the core Julia contributors) gave a talk (in 2016, so rather dated as far as the Julia syntax and whatnot go) about how Julia is secretly more lisp-y than even lisp &amp; Scheme. The core of this argument is that most language specifications dedicate many pages to defining how arithmetic works, whereas Julia is actually just able to define that in Julia code as part of the stdlib (the implementation just calls out to LLVM intrinsics, but nonetheless, super neat!). `Int64` is actually defined in a Julia file.<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=dK3zRXhrFZY&amp;t=2s" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=dK3zRXhrFZY&amp;t=2s</a>

&gt; Writing performant code in Common Lisp is not for everyone, and it most certainly cannot be done portably; what might run fast on one implementation may run poorly on another. The moment you start writing implementation-specific code, in my honest opinion, you are better off using another programming language (which can also be considered writing implementation-specific code).<p>can you please elaborate on this conclusion - &quot;better off using another language&quot;? i find it interesting because i happen to fit into this category - ie writing performant code in cl (sbcl). besides sbcl no other implementation interests me (actually maybe CLASP) and i care very little if my code is portable; hence marked as cl (sbcl). sbcl allows me to do all sorts of optimizations that not even julia has. and cl with emacs+slime is to me by far the most enjoyable hacking experience<p>the fact that you are writing a graphics engine (which is hardware dependent if performance is what you want) suggests to me that you too should not spend so much time on portability. i think implementation specific libraries in cl should be welcomed. like with people, if you try to get everyone to like you you are not going to get very far

Most of his technical problems would be non-issues if he abandoned portability to different CL implementations: Just pick a single implementation (SBCL) and use it. Other languages don&#x27;t have this problem because there&#x27;s only a single widely-used implementation.<p>Yet, a lot of Common Lisp developers keep kneecapping themselves by imposing the portability constraint where it makes absolutely no sense whatsoever: Few will actually care in practice about the 3-4 other CL implementations that the code happens to &quot;support&quot; (usually, entirely untested) but the code will be bloated by the use of 3rd party half-assed underdocumented &quot;portability&quot; libraries.<p>I&#x27;m a newcomer to Common Lisp and I do agree to a certain extent with the &quot;social problems&quot; part of the OP critique. If I had to emphasize one, it&#x27;d be the lack of focus and polish (which includes documentation) in people&#x27;s output. There are very few people in the opensource CL community that consistently produce good code and that&#x27;s a major problem.

Author here. I am a relative beginner to Julia, having only used it seriously for a few months. For those familiar with Common Lisp, I will try to answer any questions you may have in this thread, that weren&#x27;t addressed in the article.

&gt;There is support in other editors, but it is nowhere near as complete and convenient as it is in Emacs.<p>Why not, rather giving up the language, just disable the debugger? Found from SO[1]<p><pre><code> (defun debug-ignore (c h) (declare (ignore h)) (print c) (abort)) (setf *debugger-hook* #&#x27;debug-ignore) </code></pre> Of course you lose a significantly strong functionality but so you do moving elsewhere.<p>&gt;are multiple implementations of this ANSI standard, each with their own set of features.<p>Can just target a single implementation. Though, similar to previous, this kinda kills the point of having a standard and multiple implementations.<p>Some code examples on the CLOS section and how it compares to Julia&#x27;s approach will be nice and will make the points made easier to understand. The rest seem to be indeed cultural issues rather technical which for a language to be considered is also important.<p>[1]: <a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;3074698" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;3074698</a>

&gt; In short, Julia is very similar to Common Lisp, but brings a lot of extra niceties to the table<p>This is probably because Jeff Bezanson, the creator of Julia, created a Lisp prior to Julia, which I think still exists inside Julia in some fashion<p><a href="https:&#x2F;&#x2F;github.com&#x2F;JeffBezanson&#x2F;femtolisp" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;JeffBezanson&#x2F;femtolisp</a>

My C code from last century fails to compile due to changes in &quot;more secure function definitions&quot;.<p>C++ changes &quot;the standard&quot; every couple years. When someone tells me they &quot;know&quot; C++ I have to ask which &quot;standard&quot; they &quot;know&quot;.<p>Common Lisp code I wrote in the last century runs unchanged today.<p>So the complaint about Common Lisp being stuck in the past is actually a feature, not a bug.<p>When Julia settles on a standard (and only one standard) then it will be worth the learning investment. When that happens I can write code that will run without change in 2070.

I&#x27;ve not been reading good reports about Julia startup times and base memory use for simple programs.<p>In Common Lisp you can make a program that starts in milliseconds, from scratch; no Lisp stuff in RAM, other than your OS&#x27;s buffer&#x2F;file caches being warm. The same was true twenty years ago or more already.

I use both CL and more recently (obviously!) Julia exclusively and extensively. Julia is almost an acceptable lisp. Except that’s it’s not homoiconic, and they f’ing mark the macros (and a couple other minor nits). So Julia can’t really be used for the primary use case of lisp, which is DSLs. So now I do my DSL-like work in lisp, and scientific computing in Julia (or lisp with a sucky ffi to python that I rolled myself — hmmm, I guess I should rewrite that to go to Julia —- hmmm) Anyway, yeah, Julia is an almost acceptable lisp. Like, close, but missed the mark (yet again, but as close as I’ve seen). Maybe if I fix the ffi as above, I won’t have to actually see the ugly Julia non-homoiconic mess, and the hemispheres will no longer be fundamentally at odds.

&gt; There is no built-in package manager for Common Lisp.<p>This was appalling to me coming to CL from languages with a lot of control over dependencies. It&#x27;s essential that I can pin versions and ensure that I am getting the correct source code.<p>However lately I have been playing around with Guix System and now I&#x27;m wondering if the Guix package manager is the &quot;missing&quot; killer package manager for CL libraries (or for most any language).

So, the article is harsh on CL: YMMV. Also, your goal may vary: I want to build and ship (web) applications, and so far Julia doesn&#x27;t look attractive to me (at all). Super fast incremental development, build a standalone binary and deploy on my VPS or ship an Electron window? done. Problem(s) solved, let&#x27;s focus on my app please.<p>The author doesn&#x27;t mention a few helpful things:<p>- editor support: <a href="https:&#x2F;&#x2F;lispcookbook.github.io&#x2F;cl-cookbook&#x2F;editor-support.html" rel="nofollow">https:&#x2F;&#x2F;lispcookbook.github.io&#x2F;cl-cookbook&#x2F;editor-support.ht...</a> Emacs is first class, Portacle is an Emacs easy to install (3 clicks), Vim, Atom support is (was?) very good, Sublime Text seems good (it has an interactive debugger with stack frame inspection), VSCode sees good work underway, the Alive extension is new, usable but hard to install yet, LispWorks is proprietary and is more like Smalltalk, with many graphical windows to inspect your running application, Geany has simple and experimental support, Eclipse has basic support, Lem is a general purpose editor written in CL, it is Emacs-like and poorely documented :( we have Jupyter notebooks and simpler terminal-based interactive REPLs: cl-repl is like ipython.<p>So, one could complain five years ago easily about the lack of editor support, know your complaint should be more evolved than a Emacs&#x2F;Vim dichotomy.<p>- package managers: Quicklisp is great, very slick and the ecosystem is very stable. When&#x2F;if you encounter its limitations, you can use: Ultralisp, a Quicklisp distribution that ships every 5 minutes (but it doesn&#x27;t check that all packages load correctly together), Qlot is used for project-local dependencies, where you pin each one precisely, CLPM is a new package manager that fixes some (all?) Quicklisp limitations<p>&gt; [unicode, threading, GC…] All of these features are left to be implemented by third-party libraries<p>this leads to think that no implementation implements unicode or threading support O_o<p>&gt; most of the language proper is not generic<p>mention generic-cl? <a href="https:&#x2F;&#x2F;github.com&#x2F;alex-gutev&#x2F;generic-cl&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;alex-gutev&#x2F;generic-cl&#x2F;</a> (tried quickly, not intensively)<p>Documentation: fair points, but improving etc. Example of a new doc generator: <a href="https:&#x2F;&#x2F;40ants.com&#x2F;doc&#x2F;" rel="nofollow">https:&#x2F;&#x2F;40ants.com&#x2F;doc&#x2F;</a><p>Also I&#x27;d welcome a discussion about Coalton (Haskell-like type system on top of CL).

&gt; The fact that Common Lisp is a standard is both a blessing and a curse. Many developers consider this to be the former, as your code is much less likely to break over time. For others, it means that the language is frozen in time.<p>This is not a consequence of it being a standard, rather no one has bothered of creating a new revision of the standard, like has been happening with Ada, C, C++, JavaScript,....for the last decades.

Julia broadcast operators: easy to understand, and deceptively powerful.<p>It just sits there like its not something most high-level languages have ignored for decades. ;)

Unfortunately, Julia has a number of correctness flaws [0]. Just based on this alone, I can&#x27;t use Julia simply because I can never be sure whether my code is wrong or the compiler itself is wrong. In scientific computing and machine learning, these problems are very important, unlike in other types of programs where it&#x27;s more tolerable, because they deal with vectors and tensors with potentially billions of parameters and computation&#x2F;training time might take several days. If I get an incorrect result, my time has just been wasted, not to mention money via compute resources.<p>[0] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31396861" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31396861</a>

The issue regarding editors is a real one IMHO. Common Lisp is too tied towards emacs. It can put, people who don&#x27;t like Emacs, off. And while there are alternatives, but like the author said none of them provide as a complete CL dev env as Emacs. But at least there is work done to perhaps remedy this issue. Emacs is the main reason I gave up on CL.

Some questions about CL I have relating to my interests: Does Common Lisp support operator overloading? What&#x27;s the situation with support for matrices and linear algebra? Has autodiff been implemented?<p>[edit] What about Computer Algebra systems? Can I just interface with Sagemath, Maxima or Sympy somehow?

&gt; It <i>really</i> is not that far off from Common Lisp if you squint really hard<p>This made me chuckle.<p>But this post did help me understand how Julia is Lisp done right in some specific ways, and also understand the appeal of Lisp as a programming language.

What would be awesome would be if Julia had an allowed alternate syntax that happened to look exactly like Lisp. Then the world really would be a better place. (Yeah yeah, see my comments elsewhere in this thread!)

Boiling down some of his points on the problems with common lisp that made him switch away from it:<p>1. Editor support. The original poster bemoans that the only fully supported editor is emacs and that there is not sufficient support for neovim. I have used emacs and slime, but I had to stop because of the ulnar tunnel syndrome it was causing. But I knew vim before I learned emacs and I am a neovimmer myself. I have used jpalardy&#x27;s plugin[1] for many years and couldn&#x27;t be happier with it. There&#x27;s a visible repl built in, so by definition it&#x27;s fully featured. The reason emacs is the only editor for lispers is that it tries to be the whole operating system. It turns out using a terminal multiplexer along with an editor gives you everything you need. I like GNU screen on Linux and ConEmu on windows.<p>2. Community. The original poster speaks of toxicity and a community full of people who are not welcoming to newcomers who ask simple questions. I&#x27;m just barely starting my Common Lisp journey so I can&#x27;t speak to that. But I don&#x27;t know if I&#x27;m discouraged by a community that values members who are capable of doing their own research and not needing their hands held. I&#x27;m often surprised by developers who need YouTube videos to explain to them how to do their job as if they can&#x27;t read their own code. Maybe that&#x27;s why the documentation is so poor in the Common Lisp community: the expectation is that you can read their code and figure out what it does. The original poster says that the community is full of people who do not wish to work with others. That makes me feel like if I write in this language I&#x27;ll be able to be productive even if no one else wants to work with me. I&#x27;m not hugely popular and don&#x27;t have a ton of stars on my GitHub pages, so the idea of a language that allows me to be productive even if no one else wants to help sounds pretty good to me.<p>3. Packaging. The original poster speaks against packagers who take responsibility for the cleanliness of code before it gets packaged up for the quicklisp dist. He complains that packages are released on a monthly basis and that this is not fast enough for him. As a DevOps engineer, I think this is fantastic. I hate it when developers release code too frequently because the new releases often break things even when they are not intended to, and reacting to those changes takes time. A little bit of time before each release is easier on your consumers. I feel like the best sweet spot is 90 days. I&#x27;m getting killed at work right now because of the breakneck speed of helm chart packages and how fast they release completely breaking changes. I also consider that the absolute best packaging community on this planet is Fedora and Debian operating system packages. The idea of having a separate packager from the actual software making sure that the software lands well and plays nice with its neighbors is a huge feature of those communities. Those operating systems wouldn&#x27;t be possible without them. The original poster also complains that there is not any versioning. If this is the case it is very sad to me and I hope that somebody can refute this claim.<p>1: <a href="https:&#x2F;&#x2F;GitHub.com&#x2F;jpalardy&#x2F;vim-slime" rel="nofollow">https:&#x2F;&#x2F;GitHub.com&#x2F;jpalardy&#x2F;vim-slime</a>

Julia is excellent. There are a lot things with Julia (think multiple dispatch) that once you learn them you can&#x27;t stop noticing that other languages are doing it wrong

I used to say that Swift and Julia are the closest to my idea of an ideal language, but I&#x27;ve heavily shifted towards Swift.<p>The main issues for me: The function(object) is bad for readability and IDE completion. No interfaces. 1-based indexing.<p>When I use Swift, I&#x27;m not missing much from Julia of in terms of core language design. I&#x27;m missing the REPL and some parts of the ecosystem.