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

151–160 of 339 posts

Re: Why Lisp?

#151

Post by jcranmer »

lisper wrote: post #144
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…

> I am not sure how "native threads" == "green threads" You are still confused. Green threads and native threads are mutually exclusive implementation strategies for threads. Native threads are provided by the O/S. Green threads are implemented at the user level without relying on any O/S capabilities. Green threads, by definition, run in a single O/S process and can therefore only use one core. > look up Erlang/Elix…

FWIW, you are literally the first person I've seen who has insisted that green threads are incompatible with an M:N threading model. Every other definition I've seen for green threads is that they involve userspace scheduling, and there's no requirement that there must be but one thing that something can be scheduled onto.

Re: Why Lisp?

#152

Post by lisper »

jcranmer wrote: post #151
lisper wrote: post #144

Earlier quoted context omitted.

> I am not sure how "native threads" == "green threads" You are still confused. Green threads and native threads are mutually exclusive implementation strategies for threads. Native threads are provided by the O/S. Green threads are implemented at the user level without relying on any O/S capabilities. Green threads, by definition, run in a single O/S process and can therefore only use one core. > look up Erlang/Elix…

FWIW, you are literally the first person I've seen who has insisted that green threads are incompatible with an M:N threading model. Every other definition I've seen for green threads is that they involve userspace scheduling, and there's no requirement that there must be but one thing that something can be scheduled onto.

It's possible that the definition has changed; (human) language is malleable. But the original definition of "green thread", which goes back at least to the 1990s, was in contrast to "native thread" where the latter was implemented by the operating system and the former by the language implementation. The whole point of "green threads" was that they let you do something that looked like parallel processing (but was really just time-slicing under the hood) with no support from the O/S.

If there's a new accepted definition someone should update the Wikipedia page.

Re: Why Lisp?

#153

Post by pdimitar »

lisper wrote: post #150
pdimitar wrote: post #146

Earlier quoted context omitted.

> you can do those things in Lisp too Well if you can that would be a huge step. Gotta check again it seems.

The only implementation I know of that offers these features built-in is Allegro. But the cool thing about Lisp is that it's easy to add features like this at the user level even if they are not a native part of the implementation.

Not convinced. If it's so easy why hasn't anyone done it yet and made it easy to consume for everyone else?

To me this is a red flag. "Just roll it yourself" is not a constructive response in the eyes of a commercial programmer. We come to an ecosystem expecting certain basic building blocks. I am not paid to evolve LISP's ecosystem. Not to mention nobody will give me the time in a world where deadlines and milestones are a fact of life.

If I was doing programming purely as a hobby -- sure! But I don't. And I'd bet most commercial programmers don't as well.

Re: Why Lisp?

#154

Post by Paul-Craft »

Here's a question the article doesn't answer: why Common Lisp? I.e. why not Scheme? Scheme is a plenty powerful language these days with all the libraries it has available. Granted, it doesn't have history going back to the 1950s, but it does date back to the 1970s. There are also multiple implementations, each with its own set of strengths. And there are some solid standards written for the language that have good implementations.

It seems to have all the exact same features they're saying make CL a good choice (e.g. it's hard for me to imagine that a language older than most working programmers doesn't have "longevity" or "staying power.") Besides, if you click through to https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/#s8... (linked in the article), it shows a picture of the index of CLtL, where the entry for 'kludges' spans the entire book lol!

Re: Why Lisp?

#155

Post by Blackthorn »

lisper wrote: post #150
pdimitar wrote: post #146

Earlier quoted context omitted.

> you can do those things in Lisp too Well if you can that would be a huge step. Gotta check again it seems.

The only implementation I know of that offers these features built-in is Allegro. But the cool thing about Lisp is that it's easy to add features like this at the user level even if they are not a native part of the implementation.

No, I go not think this particular feature can be added at the user level. It's something that requires significant support from the runtime to handle all the blocking -> thread parking shenanigans. Attempts to do it at the user level are terribly limited in that respect and just end up like clojure's core.async.

Re: Why Lisp?

#156

Post by lisper »

Blackthorn wrote: post #155
lisper wrote: post #150

Earlier quoted context omitted.

The only implementation I know of that offers these features built-in is Allegro. But the cool thing about Lisp is that it's easy to add features like this at the user level even if they are not a native part of the implementation.

No, I go not think this particular feature can be added at the user level. It's something that requires significant support from the runtime to handle all the blocking -> thread parking shenanigans. Attempts to do it at the user level are terribly limited in that respect and just end up like clojure's core.async.

You're not wrong, but most modern CL implementations provide all the primitives you need even if they don't go all the way and provide a fully-fledged Erlang-style parallelism library out of the box.

Re: Why Lisp?

#157

Post by lisper »

pdimitar wrote: post #153
lisper wrote: post #150

Earlier quoted context omitted.

The only implementation I know of that offers these features built-in is Allegro. But the cool thing about Lisp is that it's easy to add features like this at the user level even if they are not a native part of the implementation.

Not convinced. If it's so easy why hasn't anyone done it yet and made it easy to consume for everyone else? To me this is a red flag. "Just roll it yourself" is not a constructive response in the eyes of a commercial programmer. We come to an ecosystem expecting certain basic building blocks. I am not paid to evolve LISP's ecosystem. Not to mention nobody will give me the time in a world where deadlines and milestone…

> why hasn't anyone done it yet and made it easy to consume for everyone else?

Dunno. No demand? No standard?

I recently wrote a library like this for my job. It took me about a day. I haven't published it because it was a work for hire and so it's not mine to publish. But it's the basis for my confidence that it's not hard to do.

If you want to write up a spec, I'm available for contract work (and I'm sure you would have people lining up if you actually were willing to pay someone to do this work). But I suspect you would find that writing the spec is the hard part, and if you actually did it you would find that it's easier to implement yourself than to try to hire someone.

Re: Why Lisp?

#158

Post by xmcqdpt2 »

Paul-Craft wrote: post #154

Here's a question the article doesn't answer: why Common Lisp? I.e. why not Scheme? Scheme is a plenty powerful language these days with all the libraries it has available. Granted, it doesn't have history going back to the 1950s, but it does date back to the 1970s. There are also multiple implementations, each with its own set of strengths. And there are some solid standards written for the language that have good i…

I recently decided to try a scheme and did not find any that had supported Windows as a first class platform, so that's one limitation. By comparison SBCL just runs on Windows without any difficulties.

Re: Why Lisp?

#159

Post by chlorion »

Paul-Craft wrote: post #154

Here's a question the article doesn't answer: why Common Lisp? I.e. why not Scheme? Scheme is a plenty powerful language these days with all the libraries it has available. Granted, it doesn't have history going back to the 1950s, but it does date back to the 1970s. There are also multiple implementations, each with its own set of strengths. And there are some solid standards written for the language that have good i…

That's a very good question and the same thing I ask myself whenever I consider using some lisp (for hobby purposes mostly).

I came to the conclusion that scheme is a better language from a technical standpoint and I enjoy using it more, but the primary issue is that lisp is already sort of niche, and scheme is like a niche inside of a niche, which in practice results in the "ecosystem" being very weak.

By ecosystem, I mean how much activity there is on the implementations, but moreso the available libraries and the quality of the available libraries!

An example of the ecosystem thing would be elisp. elisp has a ton of libraries available, there "s.el" for string manipulation, dash for lists, "f.el" for files and paths, "ht" for hashtables, and a lot more. Vanilla Emacs comes with around 5 million lines worth of Elisp OOTB too, this includes stuff like regex, a custom sexpr based regex DSL called "rx", json and xml parsers, sqlite bindings, etc. Very rarely do I feel like I'm missing something in elisp, with the exception of concurrency support!

When I used scheme, I was not able to find alternatives to many of these things and felt pretty limited. Schemes do tend to have better "native" support for some things like list manipulation, so it's at least usable without something like dash.

Anyways, Guile scheme seems like the most usable scheme to me right now and gets a bit of attention thanks to guix, but I think common lisp gets a bit more attention right now, and neither can compare to something like ruby or python sadly! So this could be one reason one might prefer common lisp over scheme I guess.

So for me personally, common lisp feels too old and clunky to comfortably use, scheme is nice but lacks support in a lot of areas, so in practice I end up not using either of them. I have yet to try racket though and it looks like it addresses most of my issues.

Re: Why Lisp?

#160

Post by pdimitar »

lisper wrote: post #157
pdimitar wrote: post #153

Earlier quoted context omitted.

Not convinced. If it's so easy why hasn't anyone done it yet and made it easy to consume for everyone else? To me this is a red flag. "Just roll it yourself" is not a constructive response in the eyes of a commercial programmer. We come to an ecosystem expecting certain basic building blocks. I am not paid to evolve LISP's ecosystem. Not to mention nobody will give me the time in a world where deadlines and milestone…

> why hasn't anyone done it yet and made it easy to consume for everyone else? Dunno. No demand? No standard? I recently wrote a library like this for my job. It took me about a day. I haven't published it because it was a work for hire and so it's not mine to publish. But it's the basis for my confidence that it's not hard to do. If you want to write up a spec, I'm available for contract work (and I'm sure you would…

I mean, high-quality work should be paid. Obviously.

But now we're making a full U-turn to my initial argument: LISP doesn't have features that I find are (or should be) basic building blocks so I am just taking my business elsewhere.

Post reply on HN