20 ms·

From Common Lisp to Julia

183 points by thetwentyone 4y ago

sundarurfriend 4y ago
> It really is not that far off from Common Lisp if you squint really hard This made me chuckle. 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.
- pjmlp 4y ago
  Dylan was the first Lisp that could fit that criteria, but then Apple went with C++ for the NewtonOS. At least it survives as open source project.
t6jvcereio 4y ago
Julia is excellent. There are a lot things with Julia (think multiple dispatch) that once you learn them you can't stop noticing that other languages are doing it wrong
- wdkrnls 4y ago
  I don't understand why people keep talking about multiple dispatch like Julia invented it. You can do that in many other languages, even languages designed for numeric computation. What's cool about Julia is that it has brought 90s compiler technology to scientific computing: a field which still thinks MATLAB is a really good way to develop and communicate scientific ideas.
  - t6jvcereio 4y ago
    What other languages?
    - michaelfiano 4y ago
      Author here. How about Common Lisp, what the article talks about? :)
      - t6jvcereio 4y ago
        Somehow, lisp ends up being really slow. so it's doing something else wrong.
        michaelfiano 4y ago
        Which Lisp? What applications do you think it is slow at? Hint: It can be faster than C due to compiler macros, and infact, its regular expression engine is much faster than Perl's, which is written in C, just to give a concrete example.
        _ofdw 4y ago
        My experience with SBCL disagrees with this. It's not as fast as, say, C++ for some use cases, but it's pretty quick. Significantly faster than something like Python.
        TurboHaskal 4y ago
        My experience is that even writing "idiomatic", CLOS heavy code tends to be faster out of the box than most dynlangs out there. Writing close to C++ code requires a lot of manual work and is probably not even worth it unless for optimizing hot-paths.
        pfdietz 4y ago
        You're probably using O(n^2) idioms, like appending to the end of a growing list.
  - galangalalgol 4y ago
    MATLAB is fairly impressive for development. It works ok for communication. What are the areas for improvement you have in mind, and what are the alternatives I should consider?
    - adgjlsfhk1 4y ago
      The 2 biggest problems with Matlab are price and lack of community. The price is an issue even if you can afford it because it makes it really hard to deploy widely since anyone who wants to run the code also needs to be paying Mathworks. This closely ties in to the community issue. Almost all Matlab libraries are proprietary (and written by MathWorks). If you find a bug, your only option is to file a report and wait 3 years for it to not get fixed. In an open source ecosystem, you can dig into the code and fix the problem yourself if you need to.
      - galangalalgol 4y ago
        Both fair points. And the alternative? I like Julia, but i still haven't found a workflow I like. I still typically prototype in Matlab and deploy in c++/cuda.
        adgjlsfhk1 4y ago
        I'm using Julia, but if I wasn't, I probably would either be using Python or C#.
        galangalalgol 4y ago
        I'm trying to work entirely inside the repl. Its not bad but for large stuff the lack of go to definition hurts, and there isn't an easy way to copy commands that worked into my module. I'll try vscode next. That is what I use for c++/c. Is there anything else I should try?
        adgjlsfhk1 4y ago
        I use VSCode+repl which works well for me (although the language server for Julia isn't as good as a C/C++ one). The one other workflow to look at is Pluto notebooks. They're similar to jupyter notebooks, but they track cell dependencies and automatically dependent cells, to guarantee that you maintain consistent state.
  - adgjlsfhk1 4y ago
    I think a lot of the reason is that most previous incarnations of multiple dispatch give you slow multiple dispatch, and a different way to define functions that don't have multiple dispatch and are faster to call. As such MD tends not to be commonly used in languages where it exists. Julia isn't the first to have multiple dispatch, but it is the first where everything is multiple dispatch. The result of this is that we put in a ton of work to make multiple dispatch fast, and all the APIs are designed around it, which gives a very different feel to the language.
    - chalst 4y ago
      As I noted around a year ago, there's a little puzzle here: in principle Julia's approach was available in the 90s, when decent JIT technology was becoming available. So why was MD given only toy-like treatment before Julia? (MATLAB did get a JIT in 2002, so it's not really a toy, but the performance was not good enough to prove the concept) My impression is that the complained-about inflexible division between concrete and abstract types was pretty necessary to achieving good results in practice, but this division is alien to the expressiveness-loving lisp culture. Cf. https://news.ycombinator.com/item?id=26590270 https://news.ycombinator.com/item?id=26590270
  - manwe150 4y ago
    Perhaps because it can be equally remarkable how many other languages lack multiple dispatch, when it is not a new concept
  - forgotpwd16 4y ago
    It didn't invented it but made it central to the language's design (being essentially the prime paradigm rather some opt-in functionality).
  - agumonkey 4y ago
    > What's cool about Julia is that it has brought 90s compiler technology to scientific computing that's how I read julia's praises, I don't think most people ignore the past here
- deleted 4y ago
  [deleted]
- agumonkey 4y ago
  I forgot the name of this curse but not the curse itself. /me goes back to old python OO crud
travisd 4y ago
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 & 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. https://www.youtube.com/watch?v=dK3zRXhrFZY&t=2s https://www.youtube.com/watch?v=dK3zRXhrFZY&t=2s
- JonChesterfield 4y ago
  Defining parts of the language as executable code instead of prose is attractive. One drawback is over specification - the reference implementation may have inessential features that a prose version could leave to the implementor - but overall I think that risk is minor compared to having executable test cases/examples embedded in the standard. Arbitrary size integers written in lisp is a thing. Maybe gambit and sbcl? Can't remember offhand. Calling down to llvm.sum.i64 or w/e is very similar to calling down to x64.
- crabbygrabby 4y ago
  Julia's syntax is it's greatest strength but also it's biggest weakness. Large Julia code bases without team standards are complete soup. For small to medium size projects it's all good though. Just wish the community wasn't overall so crappy.
  - travisd 4y ago
    What do you mean by crappy? I've always found it very lovely and welcoming (though a touch small). The Julia community is also (in my experience) skewed towards scientific computing rather than software engineers which can definitely have an impact on things like "codebase quality" even in big important libraries. That's not a dig or insult – there are different priorities (privileging exploration, innovation, new ideas, and code that only needs to work until the paper you're writing is done rather than long term maintainablity is not a fundamentally wrong tradeoff to make).
michaelfiano 4y ago
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't addressed in the article.
- akkartik 4y ago
  Is the Common Lisp community really still so dysfunctional? I notice your link there dates back to 2006. Surely communities can improve over 15 years..
  - michaelfiano 4y ago
    I would say it has improved, but it very much hurts me to watch some conversations. Lots of passive aggressiveness and stubborn people stuck with these old habits.
  - abrax3141 4y ago
    The sense that the user community is toxic arises from two specific individuals, one in the early days of lisp, at MIT, who was so toxic that they created a whole email list (as it was in those days) whose name was explicitly “—-without-[ahole]—-“, and one more recently who was so toxic that he single-handedly drove everyone off comp.lang.lisp. The StackOverflow lisp community, such as it is, is much less toxic.
    - eigenspace 4y ago
      Oof. You know you have a real problem when StackOverflow is your less toxic community. At least that's my experience with StackOverflow
      - abrax3141 4y ago
        Yes, we’ll, it was a real problem, but it was really just caused by a tiny number of people, almost entirely two. One really bad apple ... and all that — two in this case, but separated by many years, so the feeling had barely calmed down before another one arose. It could have happened in any community. For some reason it happened in Lisp. Shrug. Also, you need to take into account that Lisp has been in active use for over half a century!! A couple aholes in 60 years isn’t that bad a record.
djhaskin987 4y ago
Boiling down some of his points on the problems with common lisp that made him switch away from it: 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's plugin[1] for many years and couldn't be happier with it. There's a visible repl built in, so by definition it'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. 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'm just barely starting my Common Lisp journey so I can't speak to that. But I don't know if I'm discouraged by a community that values members who are capable of doing their own research and not needing their hands held. I'm often surprised by developers who need YouTube videos to explain to them how to do their job as if they can't read their own code. Maybe that'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'll be able to be productive even if no one else wants to work with me. I'm not hugely popular and don'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. 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'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'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. 1: https://GitHub.com/jpalardy/vim-slime https://GitHub.com/jpalardy/vim-slime
abrax3141 4y ago
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.
- JonChesterfield 4y ago
  I don't quite follow. Macros are visibly different to functions so they're always marked. Do you mean syntactically marked as opposed to semantically?
  - orthoxerox 4y ago
    Yes, syntactically. Where is CL your macros look just like functions or builtin special forms, Julia macros are all prefixed with @. On one hand, it clearly shows that there's some trickery going on and you can't expect referential transparency. On the other hand, it means that you can't write a DSL that has a "native" look and feel.
michaelwww 4y ago
> In short, Julia is very similar to Common Lisp, but brings a lot of extra niceties to the table 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 https://github.com/JeffBezanson/femtolisp https://github.com/JeffBezanson/femtolisp
- melony 4y ago
  The Julia compiler frontend I believe is written in lisp.
  - michaelfiano 4y ago
    Only the parser is, and it was recently re-written in Julia and in the process of being merged.
    - adgjlsfhk1 4y ago
      technically both the parser and the lowering stage are currently in lisp. The parser has been ported, but the lowering is more complicated and has not yet been re-written.
- forgotpwd16 4y ago
  Can be accessed with: julia --lisp
math-dev 4y ago
> 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'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. 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] 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
- openfuture 4y ago
  +1 for #clschool, it's a really great place to learn lisp.
kazinator 4y ago
I've not been reading good reports about Julia startup times and base memory use for simple programs. In Common Lisp you can make a program that starts in milliseconds, from scratch; no Lisp stuff in RAM, other than your OS's buffer/file caches being warm. The same was true twenty years ago or more already.
- forgotpwd16 4y ago
  Yeah, Julia doesn't work well for short-lived programs. And it's fine. It wasn't meant to be the language that does everything. (Though you can force it, e.g. utilizing a sysimage.)
cercatrova 4y ago
Unfortunately, Julia has a number of correctness flaws [0]. Just based on this alone, I can'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's more tolerable, because they deal with vectors and tensors with potentially billions of parameters and computation/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. [0] https://news.ycombinator.com/item?id=31396861 https://news.ycombinator.com/item?id=31396861
- mxkopy 4y ago
  In Julia's defense, its ecosystem is nascent and it's not designed with a focus on guarding undefined behavior. So far the community has been really good at cataloging & fixing interop issues between packages. As time goes on I'm sure it will get better.
- jakobnissen 4y ago
  I think that's a reasonable take for a usecase like ML. In most code, >99% of your bugs will be the one you write yourself, and debugging the few bugs from Julia itself is really not much harder than debugging your own, in my experience. Of course it's annoying that Julia itself is this buggy, but the problem is sometimes framed as if it causes some fundamental uncertainty and doubt about your program because the compiler can't possibly be debugged, whereas is my experience, when you see a Julia bug, it's just another bug, usually in some bog-standard stdlib function which you can easily inspect using code introspection. And again, I've maybe seen 20 Julia bugs in 4 years of coding it daily, compared to probably 20,000 of my own bugs.
- eigenspace 4y ago
  Almost all of those 'correctness flaws' are bugs in packages that weren't interfacing with each-other correctly. Everything has bugs and correctness problems, but it may be that Julia users run into them more often because they compose packages in novel ways very often. But we also have very rigorous testing infrastructure and a community that cares deeply about these things and moves very fast to fix them. You'll notice that every legitimate issue in that post is now closed and fixed, and the remaining ones are about the users misusing in place functions in the presence of aliasing.
blindseer 4y ago
I wish Julia moved away from using abstract types and concrete types and moved away from "inheritance", 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. 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'll replace all my needs for Go. I still might use Rust though :)
- jakobnissen 4y ago
  I'm an avid Julia user and I 100% agree with that. Traits are far superior. They would not be too hard to add to Julia. However, I think the chances are slim of it happening in Julia.
  - snicker7 4y ago
    My understanding is that this was being worked on by Jan Vitek and his team as a research project. Not sure how much communication his team has with the Julia compiler devs.
pjmlp 4y ago
> 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. 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.
- bmitc 4y ago
  Same thing happened with Standard ML, if I’m not mistaken, with regards to the standard not evolving. It’s a lovely little language that could have been easily pruned with some more modern sensibilities.
- medo-bear 4y ago
  almost all bits that make python famous live outside the standard library. moreover nothing in common lisp prevents one from extending the language. in fact quite the opposite, common lisp gives you enormous flexibility to do just this. HOWEVER, what is required in practice is that your library should be popular enough for it to become defacto standard. things like this already exist [1], but common lisp community is quite small so major libraries are nowhere near as common as in other languages. still though, given its size, some exellent projects are under way [1] https://alexandria.common-lisp.dev/ https://alexandria.common-lisp.dev/
  - pjmlp 4y ago
    You have adsf for that, https://asdf.common-lisp.dev/ https://asdf.common-lisp.dev/ However that is orthogonal to the language standard. As for the standard library, and the usual bashing Python batteries get, the great thing about being in the standard library regardless how obtuse it might be, is the guarantee it exists everywhere there is a compliant implementation. With everything else, it is hit and miss.
    - medo-bear 4y ago
      im not bashing python. im simply saying that there is nothing stopping extension of common lisp through libraries (see coalton as a recent example of this in cl) as happens in python (eg numpy). that cl is ansi standardized is only a plus because it gurantees to me that massive portions of the language (the whole standard) will allways remain the same
armitron 4y ago
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't have this problem because there's only a single widely-used implementation. 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 "support" (usually, entirely untested) but the code will be bloated by the use of 3rd party half-assed underdocumented "portability" libraries. I'm a newcomer to Common Lisp and I do agree to a certain extent with the "social problems" part of the OP critique. If I had to emphasize one, it'd be the lack of focus and polish (which includes documentation) in people's output. There are very few people in the opensource CL community that consistently produce good code and that's a major problem.
- michaelfiano 4y ago
  I have given up on portability a long time ago. I value the concision of Julia code, the "automatically fast by default due to the great JIT compiler and type inference engine", and the "everything is zero-runtime overhead generic".
- e12e 4y ago
  > Other languages don't have this problem because there's only a single widely-used implementation. Not true for c/c++ (clang+clang/osx, gcc, msvc, icc - ed: see also stdlib, libc), Java (fewer now, but still many implantations of compiler and vm), Javascript, scheme, standard ml... Arguably it's not even true for Python. Ruby has many implantations, but my impression is that mruby and jruby are mostly insignificant wrt the average ruby programmer. I would say pypy sees more real-world usage, maybe?
herewulf 4y ago
> There is no built-in package manager for Common Lisp. This was appalling to me coming to CL from languages with a lot of control over dependencies. It's essential that I can pin versions and ensure that I am getting the correct source code. However lately I have been playing around with Guix System and now I'm wondering if the Guix package manager is the "missing" killer package manager for CL libraries (or for most any language).
- vindarel 4y ago
  The post doesn't mention other package managers: Ultralisp is a Quicklisp distribution that ships every 5 minutes (but it doesn'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 (whose limitations you may not encounter after a few years of happy use: it is very slick). - https://gitlab.common-lisp.net/clpm/clpm https://gitlab.common-lisp.net/clpm/clpm
  - herewulf 4y ago
    Hello, vindarel. Thanks for your reply! I've actually been working through your Common Lisp course on Udemy. Thanks very much for that too! Sadly it has been slow because I have a lack of free time. I have been enjoying a bit of a programming Renaissance within the last year or two after writing in imperative languages for decades. I switched from Vim to Emacs (with evil), got into Emacs Lisp, then on down the rabbit hole with CL, Scheme, etc.. Good times. Anyway, clearly I have more to explore with the CL ecosystem, but the point of my comment was really that I am surprised that a language as old (or venerable) as Common Lisp doesn't seem to have already sorted out strong package versioning and cryptographically verifiable dependencies. The fact that using HTTPS is sort of new is concerning. Maybe the language just comes from more trustworthy days in general, but my paranoia has problems with that these days. I see CLPM has a "beta" warning, mostly one author, and 14 stars (for what that's worth). It seems there is still a lot of work to be done in this area. Despite all that, I would recommend to anyone to try CL for all its other advantages. Other tools (such as my suggestion with Guix) might be leveraged to make up for any shortcomings until good "native" solutions are sorted out (assuming I'm not completely misunderstanding the state of affairs).
medo-bear 4y ago
> 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). can you please elaborate on this conclusion - "better off using another language"? 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 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
- deleted 4y ago
  [deleted]
- kscarlet 4y ago
  > The moment you start writing implementation-specific code, in my honest opinion, you are better off using another programming language This is such a nonsensical statement. Guess Julia doesn't have this problem because it only has one single implementation!
abrax3141 4y ago
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!)
- forgotpwd16 4y ago
  Can be argued that it wouldn't have been as popular had it been a parentheses spaghetti.
  - abrax3141 4y ago
    Although I’m sure you’re right about that, to us lispers, your Algol-based languages are comma, bracket, braces, semicolon, sometimes-infix-sometimes-not, indentation, newline, end-statement spaghetti. :-)
- rpmuller 4y ago
  You mean like https://github.com/swadey/LispSyntax.jl https://github.com/swadey/LispSyntax.jl ?
  - abrax3141 4y ago
    I propose the word “gitiot” for an idiot who posts a “there oughta be…” without googling it first. (I can’t figure out how I missed this. I’ve been in a “lisp on the one hand and Julia on the other” bubble for years. It simply never occurred to me to look for this, and it never crossed my desktop. Gitiot!!)
    - mindB 4y ago
      To be fair to yourself, LispSyntax.jl is more of a proof of concept than something that anyone would want to actually do significant coding in as can be seen by the TODO list in the README[1]. It also hasn't seen any active development in several years. [1] https://github.com/swadey/LispSyntax.jl https://github.com/swadey/LispSyntax.jl
Joel_Mckay 4y ago
Julia broadcast operators: easy to understand, and deceptively powerful. It just sits there like its not something most high-level languages have ignored for decades. ;)
- freilanzer 4y ago
  One of my favourite features and something I miss in every other language.
forgotpwd16 4y ago
>There is support in other editors, but it is nowhere near as complete and convenient as it is in Emacs. Why not, rather giving up the language, just disable the debugger? Found from SO[1] (defun debug-ignore (c h) (declare (ignore h)) (print c) (abort)) (setf *debugger-hook* #'debug-ignore) Of course you lose a significantly strong functionality but so you do moving elsewhere. >are multiple implementations of this ANSI standard, each with their own set of features. Can just target a single implementation. Though, similar to previous, this kinda kills the point of having a standard and multiple implementations. Some code examples on the CLOS section and how it compares to Julia'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. [1]: https://stackoverflow.com/a/3074698 https://stackoverflow.com/a/3074698
- proffeatur8 4y ago
  And then there’s the little issue of over a magnitude improvement in performance in Julia compared to the already-optimized Common Lisp code…
  - forgotpwd16 4y ago
    True. Julia makes it easier to write performant code. Plus there're nice facilities enabling further optimization.
  - deleted 4y ago
    [deleted]
  - reikonomusha 4y ago
    On average, you will not get anything close to order of magnitude speed-ups on optimized Lisp code.
    - eigenspace 4y ago
      This really depends. If someone is trying to operate with small user defined generic functions on a large array of user defined defined classes in Common Lisp in a tight loop (i.e. what Michael was doing) then performance is very very hard to recover. Of course, performance claims about Common Lisp are very slippery because one can always say "well, __ implementation using ___ library can avoid ____ specific performance problem", but I think it's fair to say that in general, generic code and CLOS features can land you in very serious performance trouble quite quickly, especially if you're trying to make reasonably portable code.
vindarel 4y ago
Here'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): Why not: from Common Lisp to Julia https://gist.github.com/digikar99/24decb414ddfa15a220b27f6748165d7 https://gist.github.com/digikar99/24decb414ddfa15a220b27f674...
- ubj 4y ago
  > The unnecessarily-long-for-debugging compilation times certainly put me off. I think I do like the semantics of Julia better than Python, but the compilation times is a deal-breaker for me. Perhaps I might make the switch once this gets fixed in the upcoming years :) I like Julia, but this is a point of frustration for me as well. Compilation time is fine for smaller scripts. But whenever I've tried using more powerful packages such as the SciML ones (DifferentialEquations.jl, DiffEqFlux.jl, Symbolics.jl), the precompilation time during the edit/debug cycle can be excruciating. It's a shame because the SciML packages are so amazing. I'm waiting until Julia's static compilation process improves and is standardized. On-the-fly compilation that disappears every time you close the REPL will never be fast enough to give users a good experience when working with highly complex code. EDIT: Just to be clear, I'm overall confident that things will improve. The folks at Julia have already made good progress in reducing precompilation times from where they used to be. Looking forward to seeing further advancements in the future.
  - DNF2 4y ago
    I'm not experienced with the SciML ecosystem, but they have apparently put huge efforts into improving compilation lag, and this has been going on for quite some time: https://twitter.com/ChrisRackauckas/status/1561278092043325440 https://twitter.com/ChrisRackauckas/status/15612780920433254... Quote: "Coming very soon: a version of DifferentialEquations.jl that fully precompiles the solvers on Vector{Float64}, virtually eliminating the any #julialang #sciml JIT lag."
    - crabbygrabby 4y ago
      It's still rough. They've been at it for yrs and it's a perpetual bed of sand... A lot of machines will fail to install it because it's so resource intense to install... Promising idea overall, maybe in three yrs or so it'll be worth using for something outside of research.
vindarel 4y ago
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'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's focus on my app please. The author doesn't mention a few helpful things: - editor support: https://lispcookbook.github.io/cl-cookbook/editor-support.html https://lispcookbook.github.io/cl-cookbook/editor-support.ht... 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. So, one could complain five years ago easily about the lack of editor support, know your complaint should be more evolved than a Emacs/Vim dichotomy. - package managers: Quicklisp is great, very slick and the ecosystem is very stable. When/if you encounter its limitations, you can use: Ultralisp, a Quicklisp distribution that ships every 5 minutes (but it doesn'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 > [unicode, threading, GC…] All of these features are left to be implemented by third-party libraries this leads to think that no implementation implements unicode or threading support O_o > most of the language proper is not generic mention generic-cl? https://github.com/alex-gutev/generic-cl/ https://github.com/alex-gutev/generic-cl/ (tried quickly, not intensively) Documentation: fair points, but improving etc. Example of a new doc generator: https://40ants.com/doc/ https://40ants.com/doc/ Also I'd welcome a discussion about Coalton (Haskell-like type system on top of CL).
- vindarel 4y ago
  moreover, someone is building a CL editor in Rust and Tauri! https://www.reddit.com/r/lisp/comments/x41i0e/what_features_should_a_lisp_ide_have/ https://www.reddit.com/r/lisp/comments/x41i0e/what_features_... (no code release yet, very much POC)
RivieraKid 4y ago
I used to say that Swift and Julia are the closest to my idea of an ideal language, but I've heavily shifted towards Swift. The main issues for me: The function(object) is bad for readability and IDE completion. No interfaces. 1-based indexing. When I use Swift, I'm not missing much from Julia of in terms of core language design. I'm missing the REPL and some parts of the ecosystem.
daly 4y ago
My C code from last century fails to compile due to changes in "more secure function definitions". C++ changes "the standard" every couple years. When someone tells me they "know" C++ I have to ask which "standard" they "know". Common Lisp code I wrote in the last century runs unchanged today. So the complaint about Common Lisp being stuck in the past is actually a feature, not a bug. 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.
- mrtranscendence 4y ago
  So learning a programming language would be worth the investment only if that language has one unchanging standard? That feels to me like a bit of a hot take. Almost everything else changes in the world, often by necessity, so it's unclear to me that it's worth ossifying implementations so that C code from 1990 easily compiles in 2022.
  - daly 4y ago
    A large portion of my (non-lisp) time is taken up because someone changed a language. What used to compile no longer does. Take, for example, Python. A large codebase in 2.7 needs to be ported to Python3 because a customer has a Python3 library. The original problem now needs to be re-coded by people who did not write the original code, achieving nothing of value. Of course, some of the Python 2.7 libraries need to be re-written without access to the source. The goal for a 'standard' is not ossifying a language. Don't pretend that Python3 is in any way related to Python. Call it Snake or something else. Then 'python' code continues to work and 'snake' continues to work. The confusion, especially evident in C++, is that 'C++' is at least half-a-dozen languages related by chance. When asked if you know C++, you really should reply with the 'standard' that you claim to know. There are 6 C++ "standards" that I'm aware of. I understand there is a 7th due to arrive in 2023. I wonder if 'concepts' will be in the new 'standard'. If so, do you know what it means to inherit 'up the add chain' versus regular inheritance? If not, can you still claim to 'know C++'? It takes a LONG time to get "command of a language". Reading other people's code is a great way to see how much you don't know. For example, did you know that in C++ you can dynamically create a class and an instance IN THE ARGUMENT LIST OF A FUNCTION? It can take years to really "know" a language, much longer than the change time of languages.
mustermannBB 4y ago
The issue regarding editors is a real one IMHO. Common Lisp is too tied towards emacs. It can put, people who don'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.
- forgotpwd16 4y ago
  If utilizing free tooling isn't a requirement, there're also LispWorks and Allegro providing a different experience.
- _19qg 4y ago
  I would think that none of the available options provide a complete integrated development environment as LispWorks and Allegro CL (which are commercial, but still they exist and are available) do. The combination of SLIME/GNU Emacs and SBCL has some unique features (and is really a very useful combination), but the whole integrated development feeling one won't get from it. For example the LispWorks IDE is completely written in itself, is fully GUI based and is also in one application. Thus the cross-platform GUI system used to write the IDE is also available to the application developer. GNU Emacs OTOH is an external application, not written in Common Lisp and with a clunky user interface. Then there is a path of older and mostly abandoned, but powerful and/or very usable user interfaces: examples are Xerox/Medley Interlisp (https://interlisp.org https://interlisp.org), Symbolics Genera, Macintosh Common Lisp and others.
ogogmad 4y ago
Some questions about CL I have relating to my interests: Does Common Lisp support operator overloading? What's the situation with support for matrices and linear algebra? Has autodiff been implemented? [edit] What about Computer Algebra systems? Can I just interface with Sagemath, Maxima or Sympy somehow?
- reikonomusha 4y ago
  1. CL supports multiple dispatch, but its built-in numerical operators are not extensible. There are two libraries, GENERIC-CL and CL-GENERIC-ARITHMETIC, that put wrappers over existing operators... but you have to use those wrappers. 2. Matrices and linear algebra has only rudimentary support in Lisp. It's better than nothing but it's worse than NumPy. MAGICL, Numericals, LISP-STAT, and NUMCL are four such libraries. 3. To my knowledge, minimal/toy implementations of auto diff exist in Common Lisp, but nothing big or serious. Scheme was actually a real hotbed for autodiff research, by Pearlmutter, Siskind, et al. 4. Two of the historically best computer algebra systems are written in Common Lisp: Maxima (derived from MACSYMA of the old days) and FriCAS (derived from AXIOM of the old days). These systems basically build a computer algebra programming language and engine on top of Lisp.
  - ogogmad 4y ago
    Thank you. That was very helpful. Regarding 4, I'd like to use these CASes from within a library. A bit like how you can use Sympy as a library within Python.
    - reikonomusha 4y ago
      It's possible, especially with Maxima, but it feels a little clunky honestly. Incredibly powerful, but clunky.

183 points by thetwentyone 4y ago

> It really is not that far off from Common Lisp if you squint really hard This made me chuckle. 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.

pjmlp 4y ago
Dylan was the first Lisp that could fit that criteria, but then Apple went with C++ for the NewtonOS. At least it survives as open source project.

t6jvcereio 4y ago

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

wdkrnls 4y ago
I don't understand why people keep talking about multiple dispatch like Julia invented it. You can do that in many other languages, even languages designed for numeric computation. What's cool about Julia is that it has brought 90s compiler technology to scientific computing: a field which still thinks MATLAB is a really good way to develop and communicate scientific ideas.
- t6jvcereio 4y ago
  What other languages?
  - michaelfiano 4y ago
    Author here. How about Common Lisp, what the article talks about? :)
    - t6jvcereio 4y ago
      Somehow, lisp ends up being really slow. so it's doing something else wrong.
      - michaelfiano 4y ago
        Which Lisp? What applications do you think it is slow at? Hint: It can be faster than C due to compiler macros, and infact, its regular expression engine is much faster than Perl's, which is written in C, just to give a concrete example.
      - _ofdw 4y ago
        My experience with SBCL disagrees with this. It's not as fast as, say, C++ for some use cases, but it's pretty quick. Significantly faster than something like Python.
      - TurboHaskal 4y ago
        My experience is that even writing "idiomatic", CLOS heavy code tends to be faster out of the box than most dynlangs out there. Writing close to C++ code requires a lot of manual work and is probably not even worth it unless for optimizing hot-paths.
      - pfdietz 4y ago
        You're probably using O(n^2) idioms, like appending to the end of a growing list.
- galangalalgol 4y ago
  MATLAB is fairly impressive for development. It works ok for communication. What are the areas for improvement you have in mind, and what are the alternatives I should consider?
  - adgjlsfhk1 4y ago
    The 2 biggest problems with Matlab are price and lack of community. The price is an issue even if you can afford it because it makes it really hard to deploy widely since anyone who wants to run the code also needs to be paying Mathworks. This closely ties in to the community issue. Almost all Matlab libraries are proprietary (and written by MathWorks). If you find a bug, your only option is to file a report and wait 3 years for it to not get fixed. In an open source ecosystem, you can dig into the code and fix the problem yourself if you need to.
    - galangalalgol 4y ago
      Both fair points. And the alternative? I like Julia, but i still haven't found a workflow I like. I still typically prototype in Matlab and deploy in c++/cuda.
      - adgjlsfhk1 4y ago
        I'm using Julia, but if I wasn't, I probably would either be using Python or C#.
        galangalalgol 4y ago
        I'm trying to work entirely inside the repl. Its not bad but for large stuff the lack of go to definition hurts, and there isn't an easy way to copy commands that worked into my module. I'll try vscode next. That is what I use for c++/c. Is there anything else I should try?
        adgjlsfhk1 4y ago
        I use VSCode+repl which works well for me (although the language server for Julia isn't as good as a C/C++ one). The one other workflow to look at is Pluto notebooks. They're similar to jupyter notebooks, but they track cell dependencies and automatically dependent cells, to guarantee that you maintain consistent state.
- adgjlsfhk1 4y ago
  I think a lot of the reason is that most previous incarnations of multiple dispatch give you slow multiple dispatch, and a different way to define functions that don't have multiple dispatch and are faster to call. As such MD tends not to be commonly used in languages where it exists. Julia isn't the first to have multiple dispatch, but it is the first where everything is multiple dispatch. The result of this is that we put in a ton of work to make multiple dispatch fast, and all the APIs are designed around it, which gives a very different feel to the language.
  - chalst 4y ago
    As I noted around a year ago, there's a little puzzle here: in principle Julia's approach was available in the 90s, when decent JIT technology was becoming available. So why was MD given only toy-like treatment before Julia? (MATLAB did get a JIT in 2002, so it's not really a toy, but the performance was not good enough to prove the concept) My impression is that the complained-about inflexible division between concrete and abstract types was pretty necessary to achieving good results in practice, but this division is alien to the expressiveness-loving lisp culture. Cf. https://news.ycombinator.com/item?id=26590270 https://news.ycombinator.com/item?id=26590270
- manwe150 4y ago
  Perhaps because it can be equally remarkable how many other languages lack multiple dispatch, when it is not a new concept
- forgotpwd16 4y ago
  It didn't invented it but made it central to the language's design (being essentially the prime paradigm rather some opt-in functionality).
- agumonkey 4y ago
  > What's cool about Julia is that it has brought 90s compiler technology to scientific computing that's how I read julia's praises, I don't think most people ignore the past here
deleted 4y ago
[deleted]
agumonkey 4y ago
I forgot the name of this curse but not the curse itself. /me goes back to old python OO crud

travisd 4y ago

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 & 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. https://www.youtube.com/watch?v=dK3zRXhrFZY&t=2s https://www.youtube.com/watch?v=dK3zRXhrFZY&t=2s

JonChesterfield 4y ago
Defining parts of the language as executable code instead of prose is attractive. One drawback is over specification - the reference implementation may have inessential features that a prose version could leave to the implementor - but overall I think that risk is minor compared to having executable test cases/examples embedded in the standard. Arbitrary size integers written in lisp is a thing. Maybe gambit and sbcl? Can't remember offhand. Calling down to llvm.sum.i64 or w/e is very similar to calling down to x64.
crabbygrabby 4y ago
Julia's syntax is it's greatest strength but also it's biggest weakness. Large Julia code bases without team standards are complete soup. For small to medium size projects it's all good though. Just wish the community wasn't overall so crappy.
- travisd 4y ago
  What do you mean by crappy? I've always found it very lovely and welcoming (though a touch small). The Julia community is also (in my experience) skewed towards scientific computing rather than software engineers which can definitely have an impact on things like "codebase quality" even in big important libraries. That's not a dig or insult – there are different priorities (privileging exploration, innovation, new ideas, and code that only needs to work until the paper you're writing is done rather than long term maintainablity is not a fundamentally wrong tradeoff to make).

michaelfiano 4y ago

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't addressed in the article.

akkartik 4y ago
Is the Common Lisp community really still so dysfunctional? I notice your link there dates back to 2006. Surely communities can improve over 15 years..
- michaelfiano 4y ago
  I would say it has improved, but it very much hurts me to watch some conversations. Lots of passive aggressiveness and stubborn people stuck with these old habits.
- abrax3141 4y ago
  The sense that the user community is toxic arises from two specific individuals, one in the early days of lisp, at MIT, who was so toxic that they created a whole email list (as it was in those days) whose name was explicitly “—-without-[ahole]—-“, and one more recently who was so toxic that he single-handedly drove everyone off comp.lang.lisp. The StackOverflow lisp community, such as it is, is much less toxic.
  - eigenspace 4y ago
    Oof. You know you have a real problem when StackOverflow is your less toxic community. At least that's my experience with StackOverflow
    - abrax3141 4y ago
      Yes, we’ll, it was a real problem, but it was really just caused by a tiny number of people, almost entirely two. One really bad apple ... and all that — two in this case, but separated by many years, so the feeling had barely calmed down before another one arose. It could have happened in any community. For some reason it happened in Lisp. Shrug. Also, you need to take into account that Lisp has been in active use for over half a century!! A couple aholes in 60 years isn’t that bad a record.

djhaskin987 4y ago

Boiling down some of his points on the problems with common lisp that made him switch away from it: 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's plugin[1] for many years and couldn't be happier with it. There's a visible repl built in, so by definition it'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. 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'm just barely starting my Common Lisp journey so I can't speak to that. But I don't know if I'm discouraged by a community that values members who are capable of doing their own research and not needing their hands held. I'm often surprised by developers who need YouTube videos to explain to them how to do their job as if they can't read their own code. Maybe that'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'll be able to be productive even if no one else wants to work with me. I'm not hugely popular and don'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. 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'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'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. 1: https://GitHub.com/jpalardy/vim-slime https://GitHub.com/jpalardy/vim-slime

abrax3141 4y ago

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.

JonChesterfield 4y ago
I don't quite follow. Macros are visibly different to functions so they're always marked. Do you mean syntactically marked as opposed to semantically?
- orthoxerox 4y ago
  Yes, syntactically. Where is CL your macros look just like functions or builtin special forms, Julia macros are all prefixed with @. On one hand, it clearly shows that there's some trickery going on and you can't expect referential transparency. On the other hand, it means that you can't write a DSL that has a "native" look and feel.

michaelwww 4y ago

> In short, Julia is very similar to Common Lisp, but brings a lot of extra niceties to the table 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 https://github.com/JeffBezanson/femtolisp https://github.com/JeffBezanson/femtolisp

melony 4y ago
The Julia compiler frontend I believe is written in lisp.
- michaelfiano 4y ago
  Only the parser is, and it was recently re-written in Julia and in the process of being merged.
  - adgjlsfhk1 4y ago
    technically both the parser and the lowering stage are currently in lisp. The parser has been ported, but the lowering is more complicated and has not yet been re-written.
forgotpwd16 4y ago
Can be accessed with: julia --lisp

math-dev 4y ago

> 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'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. 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] 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

openfuture 4y ago
+1 for #clschool, it's a really great place to learn lisp.

kazinator 4y ago

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

forgotpwd16 4y ago
Yeah, Julia doesn't work well for short-lived programs. And it's fine. It wasn't meant to be the language that does everything. (Though you can force it, e.g. utilizing a sysimage.)

cercatrova 4y ago

Unfortunately, Julia has a number of correctness flaws [0]. Just based on this alone, I can'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's more tolerable, because they deal with vectors and tensors with potentially billions of parameters and computation/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. [0] https://news.ycombinator.com/item?id=31396861 https://news.ycombinator.com/item?id=31396861

mxkopy 4y ago
In Julia's defense, its ecosystem is nascent and it's not designed with a focus on guarding undefined behavior. So far the community has been really good at cataloging & fixing interop issues between packages. As time goes on I'm sure it will get better.
jakobnissen 4y ago
I think that's a reasonable take for a usecase like ML. In most code, >99% of your bugs will be the one you write yourself, and debugging the few bugs from Julia itself is really not much harder than debugging your own, in my experience. Of course it's annoying that Julia itself is this buggy, but the problem is sometimes framed as if it causes some fundamental uncertainty and doubt about your program because the compiler can't possibly be debugged, whereas is my experience, when you see a Julia bug, it's just another bug, usually in some bog-standard stdlib function which you can easily inspect using code introspection. And again, I've maybe seen 20 Julia bugs in 4 years of coding it daily, compared to probably 20,000 of my own bugs.
eigenspace 4y ago
Almost all of those 'correctness flaws' are bugs in packages that weren't interfacing with each-other correctly. Everything has bugs and correctness problems, but it may be that Julia users run into them more often because they compose packages in novel ways very often. But we also have very rigorous testing infrastructure and a community that cares deeply about these things and moves very fast to fix them. You'll notice that every legitimate issue in that post is now closed and fixed, and the remaining ones are about the users misusing in place functions in the presence of aliasing.

blindseer 4y ago

I wish Julia moved away from using abstract types and concrete types and moved away from "inheritance", 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. 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'll replace all my needs for Go. I still might use Rust though :)

jakobnissen 4y ago
I'm an avid Julia user and I 100% agree with that. Traits are far superior. They would not be too hard to add to Julia. However, I think the chances are slim of it happening in Julia.
- snicker7 4y ago
  My understanding is that this was being worked on by Jan Vitek and his team as a research project. Not sure how much communication his team has with the Julia compiler devs.

pjmlp 4y ago

> 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. 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.

bmitc 4y ago
Same thing happened with Standard ML, if I’m not mistaken, with regards to the standard not evolving. It’s a lovely little language that could have been easily pruned with some more modern sensibilities.
medo-bear 4y ago
almost all bits that make python famous live outside the standard library. moreover nothing in common lisp prevents one from extending the language. in fact quite the opposite, common lisp gives you enormous flexibility to do just this. HOWEVER, what is required in practice is that your library should be popular enough for it to become defacto standard. things like this already exist [1], but common lisp community is quite small so major libraries are nowhere near as common as in other languages. still though, given its size, some exellent projects are under way [1] https://alexandria.common-lisp.dev/ https://alexandria.common-lisp.dev/
- pjmlp 4y ago
  You have adsf for that, https://asdf.common-lisp.dev/ https://asdf.common-lisp.dev/ However that is orthogonal to the language standard. As for the standard library, and the usual bashing Python batteries get, the great thing about being in the standard library regardless how obtuse it might be, is the guarantee it exists everywhere there is a compliant implementation. With everything else, it is hit and miss.
  - medo-bear 4y ago
    im not bashing python. im simply saying that there is nothing stopping extension of common lisp through libraries (see coalton as a recent example of this in cl) as happens in python (eg numpy). that cl is ansi standardized is only a plus because it gurantees to me that massive portions of the language (the whole standard) will allways remain the same

armitron 4y ago

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't have this problem because there's only a single widely-used implementation. 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 "support" (usually, entirely untested) but the code will be bloated by the use of 3rd party half-assed underdocumented "portability" libraries. I'm a newcomer to Common Lisp and I do agree to a certain extent with the "social problems" part of the OP critique. If I had to emphasize one, it'd be the lack of focus and polish (which includes documentation) in people's output. There are very few people in the opensource CL community that consistently produce good code and that's a major problem.

michaelfiano 4y ago
I have given up on portability a long time ago. I value the concision of Julia code, the "automatically fast by default due to the great JIT compiler and type inference engine", and the "everything is zero-runtime overhead generic".
e12e 4y ago
> Other languages don't have this problem because there's only a single widely-used implementation. Not true for c/c++ (clang+clang/osx, gcc, msvc, icc - ed: see also stdlib, libc), Java (fewer now, but still many implantations of compiler and vm), Javascript, scheme, standard ml... Arguably it's not even true for Python. Ruby has many implantations, but my impression is that mruby and jruby are mostly insignificant wrt the average ruby programmer. I would say pypy sees more real-world usage, maybe?

herewulf 4y ago

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

vindarel 4y ago
The post doesn't mention other package managers: Ultralisp is a Quicklisp distribution that ships every 5 minutes (but it doesn'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 (whose limitations you may not encounter after a few years of happy use: it is very slick). - https://gitlab.common-lisp.net/clpm/clpm https://gitlab.common-lisp.net/clpm/clpm
- herewulf 4y ago
  Hello, vindarel. Thanks for your reply! I've actually been working through your Common Lisp course on Udemy. Thanks very much for that too! Sadly it has been slow because I have a lack of free time. I have been enjoying a bit of a programming Renaissance within the last year or two after writing in imperative languages for decades. I switched from Vim to Emacs (with evil), got into Emacs Lisp, then on down the rabbit hole with CL, Scheme, etc.. Good times. Anyway, clearly I have more to explore with the CL ecosystem, but the point of my comment was really that I am surprised that a language as old (or venerable) as Common Lisp doesn't seem to have already sorted out strong package versioning and cryptographically verifiable dependencies. The fact that using HTTPS is sort of new is concerning. Maybe the language just comes from more trustworthy days in general, but my paranoia has problems with that these days. I see CLPM has a "beta" warning, mostly one author, and 14 stars (for what that's worth). It seems there is still a lot of work to be done in this area. Despite all that, I would recommend to anyone to try CL for all its other advantages. Other tools (such as my suggestion with Guix) might be leveraged to make up for any shortcomings until good "native" solutions are sorted out (assuming I'm not completely misunderstanding the state of affairs).

medo-bear 4y ago

> 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). can you please elaborate on this conclusion - "better off using another language"? 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 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

deleted 4y ago
[deleted]
kscarlet 4y ago
> The moment you start writing implementation-specific code, in my honest opinion, you are better off using another programming language This is such a nonsensical statement. Guess Julia doesn't have this problem because it only has one single implementation!

abrax3141 4y ago

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!)

forgotpwd16 4y ago
Can be argued that it wouldn't have been as popular had it been a parentheses spaghetti.
- abrax3141 4y ago
  Although I’m sure you’re right about that, to us lispers, your Algol-based languages are comma, bracket, braces, semicolon, sometimes-infix-sometimes-not, indentation, newline, end-statement spaghetti. :-)
rpmuller 4y ago
You mean like https://github.com/swadey/LispSyntax.jl https://github.com/swadey/LispSyntax.jl ?
- abrax3141 4y ago
  I propose the word “gitiot” for an idiot who posts a “there oughta be…” without googling it first. (I can’t figure out how I missed this. I’ve been in a “lisp on the one hand and Julia on the other” bubble for years. It simply never occurred to me to look for this, and it never crossed my desktop. Gitiot!!)
  - mindB 4y ago
    To be fair to yourself, LispSyntax.jl is more of a proof of concept than something that anyone would want to actually do significant coding in as can be seen by the TODO list in the README[1]. It also hasn't seen any active development in several years. [1] https://github.com/swadey/LispSyntax.jl https://github.com/swadey/LispSyntax.jl

Joel_Mckay 4y ago

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

freilanzer 4y ago
One of my favourite features and something I miss in every other language.

forgotpwd16 4y ago

>There is support in other editors, but it is nowhere near as complete and convenient as it is in Emacs. Why not, rather giving up the language, just disable the debugger? Found from SO[1] (defun debug-ignore (c h) (declare (ignore h)) (print c) (abort)) (setf *debugger-hook* #'debug-ignore) Of course you lose a significantly strong functionality but so you do moving elsewhere. >are multiple implementations of this ANSI standard, each with their own set of features. Can just target a single implementation. Though, similar to previous, this kinda kills the point of having a standard and multiple implementations. Some code examples on the CLOS section and how it compares to Julia'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. [1]: https://stackoverflow.com/a/3074698 https://stackoverflow.com/a/3074698

proffeatur8 4y ago
And then there’s the little issue of over a magnitude improvement in performance in Julia compared to the already-optimized Common Lisp code…
- forgotpwd16 4y ago
  True. Julia makes it easier to write performant code. Plus there're nice facilities enabling further optimization.
- deleted 4y ago
  [deleted]
- reikonomusha 4y ago
  On average, you will not get anything close to order of magnitude speed-ups on optimized Lisp code.
  - eigenspace 4y ago
    This really depends. If someone is trying to operate with small user defined generic functions on a large array of user defined defined classes in Common Lisp in a tight loop (i.e. what Michael was doing) then performance is very very hard to recover. Of course, performance claims about Common Lisp are very slippery because one can always say "well, __ implementation using ___ library can avoid ____ specific performance problem", but I think it's fair to say that in general, generic code and CLOS features can land you in very serious performance trouble quite quickly, especially if you're trying to make reasonably portable code.

vindarel 4y ago

Here'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): Why not: from Common Lisp to Julia https://gist.github.com/digikar99/24decb414ddfa15a220b27f6748165d7 https://gist.github.com/digikar99/24decb414ddfa15a220b27f674...

ubj 4y ago
> The unnecessarily-long-for-debugging compilation times certainly put me off. I think I do like the semantics of Julia better than Python, but the compilation times is a deal-breaker for me. Perhaps I might make the switch once this gets fixed in the upcoming years :) I like Julia, but this is a point of frustration for me as well. Compilation time is fine for smaller scripts. But whenever I've tried using more powerful packages such as the SciML ones (DifferentialEquations.jl, DiffEqFlux.jl, Symbolics.jl), the precompilation time during the edit/debug cycle can be excruciating. It's a shame because the SciML packages are so amazing. I'm waiting until Julia's static compilation process improves and is standardized. On-the-fly compilation that disappears every time you close the REPL will never be fast enough to give users a good experience when working with highly complex code. EDIT: Just to be clear, I'm overall confident that things will improve. The folks at Julia have already made good progress in reducing precompilation times from where they used to be. Looking forward to seeing further advancements in the future.
- DNF2 4y ago
  I'm not experienced with the SciML ecosystem, but they have apparently put huge efforts into improving compilation lag, and this has been going on for quite some time: https://twitter.com/ChrisRackauckas/status/1561278092043325440 https://twitter.com/ChrisRackauckas/status/15612780920433254... Quote: "Coming very soon: a version of DifferentialEquations.jl that fully precompiles the solvers on Vector{Float64}, virtually eliminating the any #julialang #sciml JIT lag."
  - crabbygrabby 4y ago
    It's still rough. They've been at it for yrs and it's a perpetual bed of sand... A lot of machines will fail to install it because it's so resource intense to install... Promising idea overall, maybe in three yrs or so it'll be worth using for something outside of research.

vindarel 4y ago

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'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's focus on my app please. The author doesn't mention a few helpful things: - editor support: https://lispcookbook.github.io/cl-cookbook/editor-support.html https://lispcookbook.github.io/cl-cookbook/editor-support.ht... 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. So, one could complain five years ago easily about the lack of editor support, know your complaint should be more evolved than a Emacs/Vim dichotomy. - package managers: Quicklisp is great, very slick and the ecosystem is very stable. When/if you encounter its limitations, you can use: Ultralisp, a Quicklisp distribution that ships every 5 minutes (but it doesn'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 > [unicode, threading, GC…] All of these features are left to be implemented by third-party libraries this leads to think that no implementation implements unicode or threading support O_o > most of the language proper is not generic mention generic-cl? https://github.com/alex-gutev/generic-cl/ https://github.com/alex-gutev/generic-cl/ (tried quickly, not intensively) Documentation: fair points, but improving etc. Example of a new doc generator: https://40ants.com/doc/ https://40ants.com/doc/ Also I'd welcome a discussion about Coalton (Haskell-like type system on top of CL).

vindarel 4y ago
moreover, someone is building a CL editor in Rust and Tauri! https://www.reddit.com/r/lisp/comments/x41i0e/what_features_should_a_lisp_ide_have/ https://www.reddit.com/r/lisp/comments/x41i0e/what_features_... (no code release yet, very much POC)

RivieraKid 4y ago

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

daly 4y ago

My C code from last century fails to compile due to changes in "more secure function definitions". C++ changes "the standard" every couple years. When someone tells me they "know" C++ I have to ask which "standard" they "know". Common Lisp code I wrote in the last century runs unchanged today. So the complaint about Common Lisp being stuck in the past is actually a feature, not a bug. 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.

mrtranscendence 4y ago
So learning a programming language would be worth the investment only if that language has one unchanging standard? That feels to me like a bit of a hot take. Almost everything else changes in the world, often by necessity, so it's unclear to me that it's worth ossifying implementations so that C code from 1990 easily compiles in 2022.
- daly 4y ago
  A large portion of my (non-lisp) time is taken up because someone changed a language. What used to compile no longer does. Take, for example, Python. A large codebase in 2.7 needs to be ported to Python3 because a customer has a Python3 library. The original problem now needs to be re-coded by people who did not write the original code, achieving nothing of value. Of course, some of the Python 2.7 libraries need to be re-written without access to the source. The goal for a 'standard' is not ossifying a language. Don't pretend that Python3 is in any way related to Python. Call it Snake or something else. Then 'python' code continues to work and 'snake' continues to work. The confusion, especially evident in C++, is that 'C++' is at least half-a-dozen languages related by chance. When asked if you know C++, you really should reply with the 'standard' that you claim to know. There are 6 C++ "standards" that I'm aware of. I understand there is a 7th due to arrive in 2023. I wonder if 'concepts' will be in the new 'standard'. If so, do you know what it means to inherit 'up the add chain' versus regular inheritance? If not, can you still claim to 'know C++'? It takes a LONG time to get "command of a language". Reading other people's code is a great way to see how much you don't know. For example, did you know that in C++ you can dynamically create a class and an instance IN THE ARGUMENT LIST OF A FUNCTION? It can take years to really "know" a language, much longer than the change time of languages.

mustermannBB 4y ago

The issue regarding editors is a real one IMHO. Common Lisp is too tied towards emacs. It can put, people who don'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.

forgotpwd16 4y ago
If utilizing free tooling isn't a requirement, there're also LispWorks and Allegro providing a different experience.
_19qg 4y ago
I would think that none of the available options provide a complete integrated development environment as LispWorks and Allegro CL (which are commercial, but still they exist and are available) do. The combination of SLIME/GNU Emacs and SBCL has some unique features (and is really a very useful combination), but the whole integrated development feeling one won't get from it. For example the LispWorks IDE is completely written in itself, is fully GUI based and is also in one application. Thus the cross-platform GUI system used to write the IDE is also available to the application developer. GNU Emacs OTOH is an external application, not written in Common Lisp and with a clunky user interface. Then there is a path of older and mostly abandoned, but powerful and/or very usable user interfaces: examples are Xerox/Medley Interlisp (https://interlisp.org https://interlisp.org), Symbolics Genera, Macintosh Common Lisp and others.

ogogmad 4y ago

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

reikonomusha 4y ago
1. CL supports multiple dispatch, but its built-in numerical operators are not extensible. There are two libraries, GENERIC-CL and CL-GENERIC-ARITHMETIC, that put wrappers over existing operators... but you have to use those wrappers. 2. Matrices and linear algebra has only rudimentary support in Lisp. It's better than nothing but it's worse than NumPy. MAGICL, Numericals, LISP-STAT, and NUMCL are four such libraries. 3. To my knowledge, minimal/toy implementations of auto diff exist in Common Lisp, but nothing big or serious. Scheme was actually a real hotbed for autodiff research, by Pearlmutter, Siskind, et al. 4. Two of the historically best computer algebra systems are written in Common Lisp: Maxima (derived from MACSYMA of the old days) and FriCAS (derived from AXIOM of the old days). These systems basically build a computer algebra programming language and engine on top of Lisp.
- ogogmad 4y ago
  Thank you. That was very helpful. Regarding 4, I'd like to use these CASes from within a library. A bit like how you can use Sympy as a library within Python.
  - reikonomusha 4y ago
    It's possible, especially with Maxima, but it feels a little clunky honestly. Incredibly powerful, but clunky.