Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Lisp?

nyxt.atlas.engineer

Post reply on HN
Print view View original

111–120 of 339 posts

Re: Why Lisp?

#111

Post by eterevsky »

lisper wrote: post #104
eterevsky wrote: post #101

Isn't Lisp 5-20 times slower than C/C++/Rust ( https://benchmarksgame-team.pages.debian.net/benchmarksgame/... )? Performance is important for a browser.

It depends on how you write the code and the compiler you use, but Lisp can be as fast as if not faster than C. But the main thing is that in Lisp it's easy to turn the dial between speed and other things you might want to optimize for like safety and debugability. Making C code memory safe is a lot of work at best, and actually impossible at worst.

You could write safe-ish C++ and Rust that is both readable and fast.

Could you point me to some benchmarks of Lisp being comparable to C?

Also, unless I am mistaken, Common Lisp doesn't have strong types. How can you make either fast or safe language without compiler knowing the types?

Re: Why Lisp?

#112

Post by lispm »

eimrine wrote: post #93
behnamoh wrote: post #53

Earlier quoted context omitted.

Janet is not a Lisp, it uses parentheses though.

I have pg's list of nine Lisp ideas [1]. What of these are missing in Janet? My guess is that only 9th one but I would like to understand Lisp (any) vs Janet point. [1] www.paulgraham.com/diff.html

LISP originally came in an implementation (LISP I) and LISP is short for List Processor.

Janet looks like a really great language&implementation, but it is not similar to that specific List Processor, for example given that it does not use linked lists at its core.

Re: Why Lisp?

#113

Post by foldr »

phoe-krk wrote: post #110
foldr wrote: post #109

Earlier quoted context omitted.

Portable CL is missing some key features for making zero cost abstractions such as unboxed arrays of structs.

Yes. That's a consequence of language design - unboxed arrays of structs mean no object identity, which means that operators like SETF and EQ no longer have their invariants satisfied when performing assignment to such arrays.

Sure, there may be reasons for it, but it means you can’t really build zero cost abstractions. For example, you can’t make a simple 2D vector object with the standard operations defined over it and then store those vectors in flat arrays. This is something that can trivially be done in C++, Rust, etc.

Re: Why Lisp?

#114

Post by tikhonj »

pdimitar wrote: post #97

I can gloss over LISP's lack of static strong typing and if I force myself a bit, I can also ignore it not producing small efficient native binaries... but the lack of (semi-)transparent concurrency / parallelism is my deal-breaker. Multicore CPUs are a fact for life for a long time now. Where is the stuff like Erlang/Elixir's green threads or Golang's goroutines/channels and Rust's async runtimes workers/channels, a…

> that solution might end up being non-extendable, rigid and a dead-end

This is definitely something businesses are concerned about, but my experience has been that bog-standard enterprise-style codebases are way more likely to calcify than custom DSLs... but, somehow, it's never seen as a problem with standard technologies and approaches.

Re: Why Lisp?

#115

Post by [deleted] »

Blackthorn wrote: post #105
jabradoodle wrote: post #102

Earlier quoted context omitted.

There are staticly typed and gradually typed lisps. Clojure also has a similar concurrency to go with channels.

Clojure's core.async channel concurrency is nothing like go's. You need to wrap your concurrent block in a macro so it can code walk to find explicit blocking points. That means these points need to be marked, and can't be in already compiled functions. That's an enormous limitation. Compare to go's which just works, no caveat.

[deleted]

Re: Why Lisp?

#116

Post by [deleted] »

pdimitar wrote: post #97

I can gloss over LISP's lack of static strong typing and if I force myself a bit, I can also ignore it not producing small efficient native binaries... but the lack of (semi-)transparent concurrency / parallelism is my deal-breaker. Multicore CPUs are a fact for life for a long time now. Where is the stuff like Erlang/Elixir's green threads or Golang's goroutines/channels and Rust's async runtimes workers/channels, a…

[deleted]

Re: Why Lisp?

#117

Post by bcrosby95 »

Blackthorn wrote: post #103
pdimitar wrote: post #97

I can gloss over LISP's lack of static strong typing and if I force myself a bit, I can also ignore it not producing small efficient native binaries... but the lack of (semi-)transparent concurrency / parallelism is my deal-breaker. Multicore CPUs are a fact for life for a long time now. Where is the stuff like Erlang/Elixir's green threads or Golang's goroutines/channels and Rust's async runtimes workers/channels, a…

I'd kill for common lisp with transparent green threads. It would be so great. As you noted once you use them you can never really go back. Of course, it will never happen because it can only be done in the compiler/runtime, not in a library, and the standard is frozen in stone, so that's that. I've got some hope for clojure with that at least, thanks to it being jvm hosted.

Hope no more - Java 21 will have virtual threads: https://openjdk.org/projects/jdk/21/

Speaking of, I have yet to test how agents with virtual threads perform vs core.async for my use cases.

Re: Why Lisp?

#118

Post by lisper »

pdimitar wrote: post #108
lisper wrote: post #107

Earlier quoted context omitted.

Clozure CL and Allegro CL have native threads. I think SBCL and Wraith Scheme do as well, but I'm not sure.

Well, that's exactly what I don't care about. Most languages have native threads. I want an actor runtime with transparent green threads, for example. Like Erlang/Elixir.

I don't think you understand what green threads are. Green threads are simulated threads that run on a single core.

https://en.wikipedia.org/wiki/Green_thread

But you wrote:

Multicore CPUs are a fact for life for a long time now.

So I assumed that you didn't really want green threads and were just using the wrong terminology.

In any case, you can get a Lisp with green threads too, though as you yourself point out that is considered pretty dated technology nowadays.

Re: Why Lisp?

#119

Post by armitron »

eterevsky wrote: post #111
lisper wrote: post #104

Earlier quoted context omitted.

It depends on how you write the code and the compiler you use, but Lisp can be as fast as if not faster than C. But the main thing is that in Lisp it's easy to turn the dial between speed and other things you might want to optimize for like safety and debugability. Making C code memory safe is a lot of work at best, and actually impossible at worst.

You could write safe-ish C++ and Rust that is both readable and fast. Could you point me to some benchmarks of Lisp being comparable to C? Also, unless I am mistaken, Common Lisp doesn't have strong types. How can you make either fast or safe language without compiler knowing the types?

You are mistaken, CL is strongly typed.

Re: Why Lisp?

#120

Post by lisper »

eterevsky wrote: post #111
lisper wrote: post #104

Earlier quoted context omitted.

It depends on how you write the code and the compiler you use, but Lisp can be as fast as if not faster than C. But the main thing is that in Lisp it's easy to turn the dial between speed and other things you might want to optimize for like safety and debugability. Making C code memory safe is a lot of work at best, and actually impossible at worst.

You could write safe-ish C++ and Rust that is both readable and fast. Could you point me to some benchmarks of Lisp being comparable to C? Also, unless I am mistaken, Common Lisp doesn't have strong types. How can you make either fast or safe language without compiler knowing the types?

https://www.iaeng.org/IJCS/issues_v32/issue_4/IJCS_32_4_19.p...
Post reply on HN