Hacker News new | past | comments | ask | show | jobs | submit login

What are the advantages of lisp over julia?

- Array indices start at 0. :) [Half-joking.]

- An excellent debugger and condition system!

- Code won’t be broken in 20 years (which I value when developing things like compilers). There’s one standard, and several de facto standard extensions.

- Almost 30 years of history, documentation, discussions, etc. Every corner of the language has been discussed to death.

- Several stable, mature, and independent choices of open source implementation.

- Implementations are written in Lisp all the way down. You can immediately jump to the definition of anything at any depth, and often edit or redefine to taste. (Example, I improved SBCL’s integer square root in my live image, and submitted a patch.) The only off-limits bits are a part of the runtime, like the garbage collector.

- Several independent choices of commercial implementation and commercial support.

- Generally easy to optimize and micro-optimize code. Easy to edit/disassemble/debug.

- Easy to write assembly code with SBCL.

- Fast start-up time, easy to compile into native executables. No JIT lags.

- Excellent IDE support through Emacs and SLIME. Incremental development is real with Lisp, and absolutely not so with Julia.

- Easy to dynamically generate and compile code at runtime.

- Excellent metasyntactic programming facilities. (Macros, symbol macros, reader macros, ...)

Negatives compared to Julia:

- Poor support for numerical libraries and poor support for plotting, much to the chagrin of a scientific programmer like myself.

- No hip website or hip foundation backing it.

- Quiet community, with very broad interests. Not everybody is rallying around one theme in Lisp. You got database programmers, game programmers, scientific programmers, etc. This could be a positive, if the community were larger.

- Implementations are written in Lisp all the way down. You can immediately jump to the definition of anything at any depth, and often edit or redefine to taste. (Example, I improved SBCL’s integer square root in my live image, and submitted a patch.) The only off-limits bits are a part of the runtime, like the garbage collector.

I'd add even the GC is accessible if you have the knowledge. Grammarly has a blog post that talks in part about manipulating parts of the GC to achieve higher through put by keeping heap objects (I think!) from reclamation.

Yes, lots of tunable aspects of the GC are available at runtime. You can enable/disable GC, pin memory, control how much of the heap is dedicated to which generations, control GC rate, etc. You just can’t muddle with the actual GC algorithm readily from your image. (Not that you’d ever want to??)

There's talk about using off-the-heap data structures in one of the most successfull software piece written in Lisp, AllegroGraph.

"Escape from the Heap: Low-Level Programming in Common Lisp" https://www.youtube.com/watch?v=S7nEZ3TuFpA

This is an excellent talk.

What's a good lisp to get started with? I'm a bioinformatician who's semi-competent with python & R.

I recommend SBCL with emacs. http://www.sbcl.org/platform-table.html

One big one is that Lisp is probably much faster. Common Lisp is AOT compiled to the metal so it starts up fast and runs fast. CL is often within a factor of 2 of C speed and dramatically faster than plain Python. I haven't used Julia but recent stories on HN suggest it's no speed demon.

Lisp compilers also tend to be quite fast, compared to LLVM-based compilers (well, except for Clasp, which is a Lisp based on LLVM, but that project is aiming for tight integration with LLVM-based code compiled from other languages.)

On my desktop, SBCL will compile itself from source and run the small version of its test suite in 90 seconds.

I don't know which recent stories you're talking about. I have read only one story here recently, and it was about an outdated version of Julia. Compare these two:



Julia should be faster than CL for long running numerical computation at least (reaching C/Fortran speed for type-stable code) as it was designed for that purpose (plus the good GPU support and use of libraries like BLAS). But there is no AoT option yet so you'll have to deal with JIT, making it much slower for any shorter running scripts because of all the compilation, which makes CL speed much more consistent across tasks.

Do you have any citation for this claim? The results from the programming language benchmark game[1] suggest that Julia is sometimes a bit faster than SBCL, one of the fastest lisp implementations, and sometimes a bit slower.

These benchmarks may not apply for every use case, but at least they suggest that Julia is roughly as fast as compiled Lisp.

From my perspective, Lisp falls into the third tier of programming language speed.

First tier (speed wise) of commonly used or discussed programming languages on HN are C++, C, and Rust. These have the performance for almost any task but require significant development effort.

Second tier languages trade off a bit of speed for other conveniences. These include Ada, C# and Java. Definitely slower than first tier, but easier to use in their own domains of use.

The third speed tier languages are many of my favorites, for example Swift, Go, Lisp, Racket, Julia, OCaml, Haskell, Javascript, and Dart. These are still fast enough for most situations and can be very productive.

I do a lot of programming in Python3 because it is just so expressive; speed wise, it occupies the forth tier with Ruby and Lua. The relative slowness isn’t a problem for many tasks and Python is really fun to program in.

Speed isn’t everything. While in grad school, for fun, I wrote a program to generate programming language parsers. Unfortunately, this was in 1974 using punched cards and the only language that I had access to was FORTRAN IV or assembly language—both very fast languages. I never got the program to a useful level of functionality (my goal was a LALR parser generator). If I had Python, it would have been a different story.

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

There are multiple benchmarks, but it's hard to trust anything because of varying level of skill with each language (and also there is no point in creating unmaintainable code just for speed as you say, the ideal comparison would be with idiomatic performance aware code). Also Julia is probably on tier 3, but in math problems it targets tier 1 (similarly how to python drops down to tier 1 for ML but on a language level).


https://news.ycombinator.com/item?id=19750507 (picked the discussion because combining the optimizations of two people CL got to Julia level, though Julia code is correctly written but not particularly optimized)


https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (the more direct comparison)

Good points!

“It was designed for that” doesn’t justify a claim. Common Lisp is a general purpose language with excellent support for fast numerical code. In SBCL in particular you can even write assembly if you want to do crazy AVX stuff.

While it doesn't justify by itself, it means that this area will be constantly profiled and optimized tricks will be implemented to handle it better, like auto-simd, using multiple dispatch to detect optimal BLAS method for every matrix operation, implementing broadcast/loop fusion. Even matlab which will poorly handle almost anything is pretty competitive in numerical processing.

And saying CL is fast because you can write in assembly is like saying Python is fast because you can write in C. And while you can't write in assembly in Julia, you can go down all the way down to the LLVM (and intercept the compiler right between detecting types and compiling so you can rewrite every intrinsic with your new backend in a more flexible way than multiple dispatch) like they did with XLA.jl for TPUs and CUDANative for GPUs.

> And while you can't write in assembly in Julia

Julia allows inline LLVM IR, so this is technically possible, if a little awkward:


Likewise in CCL.

Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact