Hacker News Reader

Hacker News

Comment by adamc | Hacker News Reader

Parent Full thread

adamc

Looks like another C/C++ language-family product for sure.

What I want is a Lisp with Python-level libraries.

View on HN

Have you looked at Hy?

https://github.com/hylang/hy

Clojure? The java ecosystem is the only thing that rivals the python one, and Clojure integrates very well.

Debatably the JS ecosystem rivals it in size, but it’s a different scope and lower quality in a lot of ways.

Which Clojure can also use.

Julia. Not exactly Lisp, but the concepts are there. Plays well with Python.

I've been learning and using Julia the last few weeks (coming from an OOP background). I highly recommend it. I mainly write highly mathematical programs and utilities to process some data or another. So far I've knocked out some smaller programs and started translating a larger library to learn about the type system. I haven't dug in to UI bindings yet.

I would like to have an excuse to use Julia in 2020

Clojure. Faster than Python, just as good libraries.

My experience with Clojure was that you spend a lot of time looking at Java-level exceptions. It doesn't really hide the Java dependencies. It's an OK lisp if you want to combine it with Java, but if you don't... not so good.

Yup. And not necessarily a new Lisp - Common Lisp, with SBCL implementation, is plenty fast enough. It's just the library and tooling ecosystem that's lacking.

Then you're probably not looking in the "performance-oriented" category.

Why? SBCL implementation of Common Lisp is very usable for performance-oriented tasks; it compiles to native code, and with sufficient nudges, you can get pretty tight assembly out of it.

Clasp implementation of CL would be another choice, it leverages LLVM for compilation.

The problem is with the library and tooling ecosystem.

If you're going to do SIMD, you have to care about memory alignment. If you're going to do high-performance without SIMD, you still wind up caring about things like cache misses. So you'd want a Lisp that 1) lets you control memory alignment, and probably 2) that doesn't garbage collect. At that point, is it really a Lisp?

Now, you may say that "performance-oriented" doesn't have to go as far as SIMD or caching tweaks. And that's true. But if you want a performance-oriented language that can reach all the way up the performance curve, I don't see it being Lisp.

Depends on which parts of Lisp you're interested in. You can go as far as writing Lispy assembly (SBCL does), which gives you control over memory and is not garbage collected.

As someone desiring a performance-oriented Lisp, this is something I'd like. At runtime, I can handle memory myself ($deity knows I often do that when writing performant code). What I want to have is the friendly, homoiconic Lispy syntax, the ability (and the ease) to write code that writes code, and perhaps to have these facilities available at runtime.

Also, memory alignment isn't an entirely foreign concept to Lisp, it just rarely has been a focus. The long living irony that the etymology of the names of very common Lisp functions `car` and `cdr` themselves are a lingering artifact of 36-bit word memory alignment on an ancient IBM system architecture.

Reply on news.ycombinator.com