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

171–180 of 339 posts

Re: Why Lisp?

#171

Post by cutler »

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…

> If LISP is so fantastic why isn't there a serious effort to make it multicore-friendly?

There is. It's called Clojure.

Re: Why Lisp?

#172

Post by kdmccormick »

readthenotes1 wrote: post #95
leethomas wrote: post #91

I like lisps syntactically. The only thing stopping me from using it more frequently is the lack of static typing. I wasn't always a stickler for static typing, but I've spent a lot of time working with Scala and TS and the main advantage for me is ease of refactoring and avoiding NPEs. EDIT: What I'm continuously evaluating for myself is Clojure specifically

"I like lisps syntactically" and yet, not a single parentheses in your text. Disappointed.

  ((syntactically like) I lisps)

Re: Why Lisp?

#173

Post by pdimitar »

cutler wrote: post #171
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…

> If LISP is so fantastic why isn't there a serious effort to make it multicore-friendly? There is. It's called Clojure.

Other commenters say it's nowhere close to what I'm looking for, btw.

And let me repeat that I am not looking for the old-school OS threads support. Almost all programming languages have that. It's nowhere nearly good enough.

Re: Why Lisp?

#174

Post by cutler »

leethomas wrote: post #91

I like lisps syntactically. The only thing stopping me from using it more frequently is the lack of static typing. I wasn't always a stickler for static typing, but I've spent a lot of time working with Scala and TS and the main advantage for me is ease of refactoring and avoiding NPEs. EDIT: What I'm continuously evaluating for myself is Clojure specifically

Clojure is head and shoulders above other lisps. Watch Rich Hickey's Sermons From the Mount in the years following Clojure's release and you may never be the same again. At least that was my experience. David Nolen's Clojurescript videos are similarly riveting.

Clojure also has far more reach than any other lisp with implementations for JS, JVM, .Net and recently Dart/Flutter. It also has a library - libpython - for easily importing Python libraries.

Re: Why Lisp?

#175

Post by hot_gril »

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 agree about high-level parallelism. Having done it every which way, from C to Python (bleh) to Rust to Java to Erlang: NodeJS is actually nice with throng, at least for a webserver. And the built-in async/await stuff is your greenthreading. Easy to avoid race conditions because you know the event loop stays in context until you hit an `await`.

Re: Why Lisp?

#176

Post by thou24343434 »

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…

Common Lisp (CL) is not the entirety of the Lisp world. However, CL does have a lot of limitations given its 30-year old design.

1. The typing is vague, annoying and its weird half-assed existence to a CLOS is a constant source of trouble 2. Code-walking is not completely deterministic and is not implementation independent. 3. The environment is not part of the standard.

CL was written in a completely different time when there was money to be made selling various bespoke implementations, and therefore there was a big need to vagueness in the spec. Today this need is much less so: there's 1-2 big open source impl. and about 2-3 commercial vendors.

Re: Why Lisp?

#177

Post by packetlost »

pdimitar wrote: post #166
packetlost wrote: post #138

Earlier quoted context omitted.

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.

Probably the random missing documentation. To be fair, it's easy enough to navigate the source code but the real problem for me is discovering what's what and where to import it from.

Re: Why Lisp?

#178

Post by lisper »

pdimitar wrote: post #165
lisper wrote: post #163

Earlier quoted context omitted.

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…

> Was I vague?

Well, here's what you originally wrote:

> Where is the stuff like Erlang/Elixir's green threads or Golang's goroutines/channels and Rust's async runtimes workers/channels, and OCaml 5.0's recent multicore runtime (and the emerging libraries around it)?

> I want the higher-level stuff. I want to solve problems and not invent a new async orchestration runtime for every project I work on.

That seems pretty vague to me. You mentioned four different languages (Erland, Go, Rust, OCaml). Do you want the intersection of the features of all those languages? The union? Some subset?

> You seem to be arguing in bad faith

I didn't even realize this was an argument, so I guess the problem must be that I'm just too dim to glean the correct meaning of your words. Sorry about that.

Re: Why Lisp?

#179

Post by JenrHywy »

dreamcompiler wrote: post #41
Hirrolot wrote: post #8

> When you have a running program you can compile functions, redefine classes, etc. all while the program is running. You are changing the internal state of the image. This can surely be convenient in certain cases, however most of the times I find myself playing around with unit tests rather than with a single running process. Unit tests are small and fast so I don't even notice any inconvenience with the traditiona…

I find the repl invaluable for writing unit tests. I think about what I want to test, try it out in the repl, refine it for better generality, and then basically copy/paste it into a file full of unit tests.

You can get a very similar experience with hot-reloading. In C# my current test-writing workflow is:

1. write the basic test scaffolding

2. debug, stepping until I get to a point in the test that needs to change

3. modify the test code (and save, which hot-reloads)

4. move the execution point to before my change

5. GOTO 2.

There are some changes that can't be hot-reloaded, but I've been surprised and how flexible it is.

Re: Why Lisp?

#180

Post by skissane »

thou24343434 wrote: post #176
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…

Common Lisp (CL) is not the entirety of the Lisp world. However, CL does have a lot of limitations given its 30-year old design. 1. The typing is vague, annoying and its weird half-assed existence to a CLOS is a constant source of trouble 2. Code-walking is not completely deterministic and is not implementation independent. 3. The environment is not part of the standard. CL was written in a completely different time…

> CL was written in a completely different time when there was money to be made selling various bespoke implementations, and therefore there was a big need to vagueness in the spec. Today this need is much less so

Part of the issue here is that the spec has essentially been abandoned, and frozen for the last almost 30 years. The committee which produced it decided to dissolve itself.

If the surviving major commercial vendors and open source implementations thought it was in their interest, they could get together and update the standard for the 21st century, removing a lot of the vagueness and standardising the most widely implemented extensions. ANSI/INCITS is commonly criticised as an overly cumbersome and bureaucratic process, so maybe it would best be done by starting a new bespoke standardisation committee, like what WHAT WG did for HTML. However, I don’t think enough of the major players see it as sufficiently worth their while to invest in, which is why I doubt it will ever actually happen.

Post reply on HN