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

161–170 of 339 posts

Re: Why Lisp?

#161

Post by Paul-Craft »

chlorion wrote: post #159
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,…

> Very rarely do I feel like I'm missing something in elisp, with the exception of concurrency support!

I have some good news for you, then! Cooperative threading was added in Emacs 26:

https://www.gnu.org/software/emacs/manual/html_node/elisp/Th...

https://www.emacswiki.org/emacs/NoThreading

I've never used it, but the big disadvantage seems to be that unless you're going to do some super advanced macrology, any function you run within a thread needs to explicitly call `thread-yield` in order to yield back to the scheduler so other threads can run. I don't know of any library or anything that makes it so you can just take a function that isn't thread-aware, run it concurrently with other possibly not thread-aware functions, and have it all work sensibly, but at least the building blocks are there.

---

If that doesn't suit you, Emacs 25 introduced generators!

https://www.gnu.org/software/emacs/manual/html_node/elisp/Ge...

Generators have some funky interactions with `unwind-protect`, so handle with care.

---

Finally, there's also a (really old and probably won't work as is anymore, but also probably fun to poke at) coroutine library available:

https://www.emacswiki.org/emacs/CoRoutines

---

I'm sure one of those (probably emacs threads) will meet your needs nicely. :)

Re: Why Lisp?

#162

Post by ravi-delia »

iloveCS wrote: post #81

the fact that there are repeated statements like "why X" where X = some language, points to rationalization more than reality; if the language is really so good, there won't be any need for a "why" articles on it. I haven't seen a repeated series of "Why C#" or "Why Go" or "Why Swift" articles. I also think Lisp is way overrated. Swift is based on Miranda which is based on Hope which borrows heavily from SML...There'…

There was a straight decade where HN was covered, nay choked, by "Why Go" articles. This ended under two years ago. Swift doesn't get the same coverage, but pretty clearly falls into roughly the same category for everyone but Apple UI developers

Re: Why Lisp?

#163

Post by lisper »

pdimitar wrote: post #160
lisper wrote: post #157

Earlier quoted context omitted.

> 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.

But it does. Allegro CL has it. Other implementation might have it too. It's hard to say because you've been very vague about exactly what it is that you want.

Re: Why Lisp?

#164

Post by ravi-delia »

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?

Others have responded, but without much depth. Common Lisp on SBCL (maybe the proprietary compilers are similar/better, I haven't worked with them) has a remarkably good type inference system. You need to declare, which is optional, but of course you'd need to declare all your types anyway in Rust or C++. The result is extremely good- for a highly dynamic language. Real number crunchy code actually gets very close to bare metal performance with type declarations, though if you're doing generic function calls it'll choke up fast.

So to get fast, the compiler knows the types because you tell it. For safe, you don't need to do anything- CL is garbage collected. It's easy to have fast or safe in any language- doing both requires type declarations and a good optimizing compiler.

That being said, none of that matters for this discussion. Nyxt uses Webkit under the hood because CL, even with SBCL pulling off genuine miracles, is not really intended to go toe to toe with C. I think of CL as occupying around the same niche as Java, which it's usually only a bit slower than.

Re: Why Lisp?

#165

Post by pdimitar »

lisper wrote: post #163
pdimitar wrote: post #160

Earlier quoted context omitted.

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.

But it does. Allegro CL has it. Other implementation might have it too. It's hard to say because you've been very vague about exactly what it is that you want.

Was I vague? Or were you being overly pedant about Wikipedia-sourced definitions that, as another commenter pointed out, are kind of outdated? And now trying to frame me as not knowing what I want? And pretending that the examples I gave about three other languages don't paint the picture well enough?

You seem to be arguing in bad faith from where I am standing.

...And okay -- I'd like a M:N green threads runtime (or library if you prefer) with preemptive scheduling or at least not a completely manual cooperative scheduling. And yes, we're talking full 100% CPU usage on all cores when needed. Not single-thread.

And to repeat, since you kind of pretended I never said anything about what other languages do, and if you are indeed aware of how Erlang's BEAM VM is doing it -- that is what should be present in more than one language / runtime IMO. Failing that, Golang's goroutines and Rust's async workers+channels are quite fine too.

To me, in 2023, no language has an excuse for not having something like that. Modern example: OCaml team worked on it for years and recently delivered it.

Re: Why Lisp?

#166

Post by pdimitar »

packetlost wrote: post #138
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…

Gerbil Scheme has some of these: https://cons.io/

TBF I liked Gerbil quite a bit when I tried it roughly a year ago. Don't remember why I gave up on it at this point though. Thanks for reminding me.

Re: Why Lisp?

#167

Post by pmarreck »

Elixir is like a LISP with pure functions, only immutable values all the way down (which gets you a guarantee you wouldn't have otherwise in languages where this is optional), actor concurrency, pattern-matching, actual readable syntax, and of course macros (which do the same thing LISP macros do- Accept and output an AST value that happens at the compilation step- the only difference being LISP homoiconicity). It singlehandedly ended my Haskell envy, my LISP envy and my Erlang envy, while essentially killing off what remained of my Ruby romance.

I just wish I could 1) compile it directly to a single binary (so I still have some Rust and Go envy), 2) run it 100% in the browser (so I still have some Clojure envy via ClojureScript), 3) talk to ML stuff as well as Python can (although Elixir Nx and Livebooks are coming along!)

Re: Why Lisp?

#168

Post by kerkeslager »

xmcqdpt2 wrote: post #158
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.

Racket has supported Windows since I tried it out in high school, which was a long, long time ago.

The thing with Schemes is that you can implement one in an afternoon, and you can probably add some neato feature in the same afternoon, so there are a ton of Schemes out there. But you can't build community, ecosystem of libraries, platform support, etc. that you would want for a language you're going to use in production.

Racket has been around for a long time, is used in various production systems, and has a solid community. It actually has the best standard library I know of for writing desktop GUIs, which might not be much of a claim to fame in 2023, but makes it super useful for writing small desktop tools. It definitely does some things better than others, like any language, but I think I'd be comfortable committing to it for a production project any day, which is more than I can say for any other Scheme.

Re: Why Lisp?

#169

Post by kerkeslager »

chlorion wrote: post #159
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,…

You might want to check out Racket. It's not immediately obvious that it's a Scheme, but it has a much more vast ecosystem of libraries than any other Scheme I know of.

Re: Why Lisp?

#170

Post by dragonwriter »

kerkeslager wrote: post #169
chlorion wrote: post #159

Earlier quoted context omitted.

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

You might want to check out Racket. It's not immediately obvious that it's a Scheme, but it has a much more vast ecosystem of libraries than any other Scheme I know of.

Racket is no longer called PLT-Scheme because its not a Scheme, though it includes some and is still closely related.
Post reply on HN