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

121–130 of 339 posts

Re: Why Lisp?

#121

Post by medo-bear »

zabzonk wrote: post #19
medo-bear wrote: post #16

Earlier quoted context omitted.

> not all python 2 code could be directly "leveraged", but it certainly could be translated, and has been translating is an effort. running lisp code thats 30 years old is mostly a matter of pressing play > don't get me wrong - i like lisp, but this article would not convince me if i was thinking of coming to it as a newbie given that this is more of a "tweet" than an article i think you missed the point

> given that this is more of a "tweet" than an article i think you missed the point this wasn't posted on twitter. but if you mean it was short and of poor content, then i agree with you.

i mean it was probably never meant to be rich in content in the way as to convince users to learn lisp

Re: Why Lisp?

#122

Post by pdimitar »

lisper wrote: post #118
pdimitar wrote: post #108

Earlier quoted context omitted.

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 tha…

If you want to be a pedant ¯\_(ツ)_/¯ then OK (and I am not sure how "native threads" == "green threads" but I won't argue) -- look up Erlang/Elixir's model, or Golang's, or Rust's async workers.

That's what I am looking for; basically M:N parallel execution model where M can be 50_000 and N (the number of CPU cores/threads) is no more than 32-64.

The rest is a suboptimal mess and, as already mentioned above, I am not looking to invent my own async [task] orchestration runtime for every project I participate in.

Re: Why Lisp?

#123

Post by pdimitar »

tikhonj wrote: post #114
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.

You won't catch me arguing with that. Like in communism: some [programming paradigmae] are more equal than others.

I am sick of being managed by clueless MBAs but I also don't want to piss against the wind anymore.

Re: Why Lisp?

#124

Post by varjag »

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.

Back in the 1990s the usual in CL implementations was green threads. Everyone kinda wished for POSIX threads support instead, which was eventually gained on most runtimes.

You can still see the glimpse of them as atavisms in old code and documentation.

Re: Why Lisp?

#125

Post by medo-bear »

pdimitar wrote: post #122
lisper wrote: post #118

Earlier quoted context omitted.

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 tha…

If you want to be a pedant ¯\_(ツ)_/¯ then OK (and I am not sure how "native threads" == "green threads" but I won't argue) -- look up Erlang/Elixir's model, or Golang's, or Rust's async workers. That's what I am looking for; basically M:N parallel execution model where M can be 50_000 and N (the number of CPU cores/threads) is no more than 32-64. The rest is a suboptimal mess and, as already mentioned above, I am not…

https://github.com/CodyReichert/awesome-cl#parallelism-and-c...

https://github.com/thezerobit/green-threads

edit:

static typing

https://github.com/coalton-lang/coalton

Re: Why Lisp?

#126

Post by eterevsky »

armitron wrote: post #119
eterevsky wrote: post #111

Earlier quoted context omitted.

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.

Wikipedia says that it is optionally typed. Is it not so?

Re: Why Lisp?

#127

Post by phoe-krk »

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

Earlier quoted context omitted.

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.

Probably the best workaround for this is going into the foreign memory land - grab some raw memory, define operators over it, manage all that yourself. CFFI works across enough implementations for this to be feasible.

Re: Why Lisp?

#128

Post by pdimitar »

medo-bear wrote: post #125
pdimitar wrote: post #122

Earlier quoted context omitted.

If you want to be a pedant ¯\_(ツ)_/¯ then OK (and I am not sure how "native threads" == "green threads" but I won't argue) -- look up Erlang/Elixir's model, or Golang's, or Rust's async workers. That's what I am looking for; basically M:N parallel execution model where M can be 50_000 and N (the number of CPU cores/threads) is no more than 32-64. The rest is a suboptimal mess and, as already mentioned above, I am not…

https://github.com/CodyReichert/awesome-cl#parallelism-and-c... https://github.com/thezerobit/green-threads edit: static typing https://github.com/coalton-lang/coalton

Thanks, that looks promising. Will check out some of the links.

Re: Why Lisp?

#129

Post by Blackthorn »

lisper wrote: post #118
pdimitar wrote: post #108

Earlier quoted context omitted.

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 tha…

Nothing implies that green threads need to run on a single core. The summary in your own link is pretty good: "In computer programming, a green thread (virtual thread) is a thread that is scheduled by a runtime library or virtual machine (VM) instead of natively by the underlying operating system (OS)."

Which is half of what we're looking for here. A thread that can be managed by the runtime, scheduled onto a native OS thread, and (here's the important part, where Common Lisp falls down on the job), transparently operates like a real thread or in other words, you can make normal blocking operations and the runtime just takes care of it. For example: goroutines

Re: Why Lisp?

#130

Post by vindarel »

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…

> static strong typing

Alright, here is it: https://github.com/coalton-lang/coalton/

> small efficient native binaries

The numbers are: with SBCL's core-compression, a web app with dozens on dependencies will weight ±30 to 40MB. This includes the compiler, the debugger, etc. Without core compression, we reach ±150MB.

> The actor runtime?

the actor library: https://github.com/mdbergmann/cl-gserver

> couldn't find a way to make money with it. I suspect many other programmers are in my boat.

Alright. Some do, that's life. Yes, some companies go with CL even in 2023 (https://lisp-journey.gitlab.io/blog/lisp-interview-kina/, they released https://github.com/KinaKnowledge/juno-lang lately; Feetr (finance): https://twitter.com/feetr_io/status/1587182923911991303)

https://github.com/azzamsa/awesome-lisp-companies/

> Give us an HTTP (1.x & 2.0) and WebSockets libraries

How so? We have those libraries. HTTP/2: https://github.com/zellerin/http2/

https://github.com/CodyReichert/awesome-cl

Post reply on HN