Live data from Hacker News

Why Lisp?

nyxt.atlas.engineer

281–290 of 339 posts

Re: Why Lisp?

#281

Earlier quoted context omitted.

and neither is scheme

Why do you say Scheme not a Lisp?

there's obviously a strong family resemblance, but scheme's focus on purity over practicality lends to a much different feel.

one of the illustrations from this 20 year old discussion that someone linked here a bit ago [t] was that, while you might say c is a 'member of the algol family', you wouldn't say that c 'is an algol'. perhaps an extreme example, but the idea is that lisp having a history of multiple implementations doesn't make scheme one of them.

put another way- while schemes extrapolate on a similar kind of purity to that which lisps are already famous for, giving them a kind of 'more lisp than lisp' aura, that shouldn't negate the language split.

[t] https://groups.google.com/g/comp.lang.lisp/c/Bj8Hx6mZEYI (perhaps skim kent pitman's posts for a summary)

Re: Why Lisp?

#282
post #280

Earlier quoted context omitted.

Well it is an argument insofar as you keep insisting that the LISP ecosystem has what I want, and I keep disagreeing with that claim. But yep, I want Erlang-style concurrency / parallelism and, failing that, something like Golang builtins or Rust's libraries. So not a subset or intersection, more like a priority-ordered wish-list: I want what I perceive as an ideal model (Erlang) but if that's not available, there is…

> I want Erlang-style concurrency OK, but you must want something besides that because... > an ideal model (Erlang) but if that's not available It is available. In Erlang. So if that's what you want, why are you not just using Erlang? Why even bother with the contingency of "if that's available"? Why are we having this discussion at all? This is the reason that Erlang-style concurrency is not available off-the-shelf…

> So if that's what you want, why are you not just using Erlang?

I do.

> Why are we having this discussion at all?

I saw an article praising LISP, I decided to chime in with realism because certain fandoms (LISP's included) seem very unaware of the realities of the commercial programming outside of their niche hobby language. As a senior dev (who also worked as a CTO a few times) I have learned to evaluate technology and to never wear rose-tinted glasses even for my favorite tech stacks. They became favorites based on merit and nothing else. (In fact I am starting to dislike working with Elixir for certain projects, even though I loved doing them with it in the past.)

LISP is not cutting it for commercial work in general, so I strive to bring nuance to articles (or discussions) that to me seem heavily tilted to the "I am a fan!" direction. And forgive me if "LISP has longevity" and "it's future-proof" seem like hand-waving to me. I don't see factoids, I see people reinforcing their own positive feeling based on actual factoids (like the powerful macro system and a REPL, for example).

And we keep chatting because you seem to insist that either LISP has what I deem good (disagreed, it doesn't) or that it's not important / there's no market for it (disagreed).

> There's no market for it.

You're doing post-hoc rationalization. You don't know that for a fact. I know I would have coded much more Racket and Gerbil Scheme if they had proper async runtime a la Erlang or Golang or Rust (OCaml these days as well though the story there is still unfolding after their recent 5.0 release).

> You can't do better than Erlang at "Erlang-style concurrency" by definition.

Loose definitions then. Rust and OCaml are making very serious strides. I have hope they can surpass Erlang in the next 2-5 years. Both are faster, much stricter with types (lack of those is an endless pit of bugs) and more memory-safe than Erlang (though anything with a GC like OCaml is prone to some of the nastiest problems Erlang has, like cycles between big objects but... topic for another time).

> The point of Lisp is not do X-style-anything better than X. The main benefit of Lisp is that it allows you to explore a much larger space of possible solutions in a much shorter time, which is a big win when you don't know what you want, which, I submit, is most of the time.

We finally got somewhere productive, thank you.

I use Elixir (lives in the Erlang's BEAM VM so has access to everything Erlang) for the same and I agree that being able to explore quickly is very valuable. I've only made the mistake to prototype stuff with Rust once. Never again. Nowadays I use Elixir and Golang for prototyping and the end products either remain that or get rewritten in Rust.

Also REPL story can be better with Clojure but I'll admit it at least exists, unlike that of many other languages. Startup time is not ideal but then again, neither is Erlang's sadly. Editor support I haven't checked in a long time, might be good. Library coverage is very hit and miss depending on which LISP you use. I keep hearing CL has a lot, maybe that's true but I am 50/50 there; judging by your attitude -- "it took me a day to roll it myself" -- I remain unconvinced that the library story is good, it's more like some pie-in-the-sky goodness that's eternally out of reach. Still, if I reach for LISP again in the future I'll evaluate that aspect in detail and will know for a fact.

So yeah, on the "LISP is quick to prototype stuff with" I agree completely. To me it doesn't go all the way however, hence my initial comment.

You can think of me as "dislikes anything that looks like shilling".

There is no place for feelings in our work. When I retire and if I still want to code then, maybe I'll make decisions based on feelings. Before that -- no.

Re: Why Lisp?

#283
post #280

Earlier quoted context omitted.

> I want Erlang-style concurrency OK, but you must want something besides that because... > an ideal model (Erlang) but if that's not available It is available. In Erlang. So if that's what you want, why are you not just using Erlang? Why even bother with the contingency of "if that's available"? Why are we having this discussion at all? This is the reason that Erlang-style concurrency is not available off-the-shelf…

> So if that's what you want, why are you not just using Erlang? I do. > Why are we having this discussion at all? I saw an article praising LISP, I decided to chime in with realism because certain fandoms (LISP's included) seem very unaware of the realities of the commercial programming outside of their niche hobby language. As a senior dev (who also worked as a CTO a few times) I have learned to evaluate technology…

> I saw an article praising LISP, I decided to chime in with realism because certain fandoms (LISP's included) seem very unaware of the realities of the commercial programming outside of their niche hobby language.

Lisp's detractors often seem equally unaware. I've been using Lisp in a commercial setting for the last ten years. And before that I used it in a research setting for 15 years, and even got Lisp sent into space. It worked great.

> LISP is not cutting it for commercial work in general

Lisp is rarely tried for commercial work nowadays, in no small measure because people like you keep taking pot shots at it from the side lines. Have ever actually tried using Lisp in a commercial setting? I have. It works great.

> > There's no market for it.

> You're doing post-hoc rationalization. You don't know that for a fact.

Well, I pitched the idea to you and you didn't bite, so there's a data point.

Yes, it's possible that there's a huge untapped market for Lisp out there if only it had Erlang-style concurrency. But I'll give you long odds against that being the limiting factor. The limiting factor from where I sit is ignorance and prejudice.

> To me it doesn't go all the way however

That's fine. But please don't assume that because it doesn't go all the way for you that it can't go all the way for others. Different goals give rise to different requirements.

Re: Why Lisp?

#284
post #255

Earlier quoted context omitted.

It's possible that you have experienced an enlightenment that I have yet to, but ultimately I like lisp because parenthesis are pretty, I hate remembering syntax, keywords/symbols are nicer than immutable strings, and typing out commas makes me sad (not that you'd know it from the way I abuse them in this comment). I mean, lots of languages have REPLs now- people get that they're really useful! This isn't secret know…

Those REPLs aren’t even close to Common Lisp. Common Lisp borrowed parts of the smalltalk development strategy. You can start a process and gradually update it in very sophisticated ways as you live code against it. You wouldn’t dream of packaging up your Python REPL and shipping it to users. You certainly wouldn’t open a Python REPL on your production server and start redefining functions and data structures on the…

I know, I enjoy CL quite a bit. I actually currently have REPLs running for a few services, because I like managing them from the inside. But while you can, if you want, deploy major changes by redefining a bunch of stuff on production servers without version control or backups, you...should not.

It's really nice to be able to redefine classes while you're playing around- but CL's handling of class redefinition just isn't up to snuff on a production server. It's just like doing live changes to your schema, only you see, rather more so. Compared to scp->shutdown->mv->start, if you can possibly tolerate If you had to pick between having REPL access in production and REPL access locally, would it be close? Because I value being able to mess around with a REPL while developing thousands of times as much as I like a neat toy in production. And that ability is exactly what Python or Ruby or Erlang give you. Technically lacking compared to the full suite? Perhaps. But we're talking 0.999, not 0.5.

Re: Why Lisp?

#285

Earlier quoted context omitted.

Honestly you're defending this a little too much. Nobody cares about an unfinished LISP spin-off that may be production ready some day. The OP's point still stands, CL lacks static types. This is frustratingly common with niche languages (and I am not saying CommonLisp is not productive, itself). If people are criticizing a missing feature in a language and the response is "Yeah, but we have some bespoke third-party…

Common Lisp, as defined by the standard, does not have static types. As such, Common Lisp will never have static types as a built-in language feature. For the people who care about built-in languages features alone, and not what the library ecosystem has to offer, the discussion could very well end there. Most programmers seem to care what the library ecosystem has to offer, though, so long as said libraries are actu…

Thanks for the thoughtful reply

Re: Why Lisp?

#286
post #250

Earlier quoted context omitted.

It's possible that you have experienced an enlightenment that I have yet to, but ultimately I like lisp because parenthesis are pretty, I hate remembering syntax, keywords/symbols are nicer than immutable strings, and typing out commas makes me sad (not that you'd know it from the way I abuse them in this comment). I mean, lots of languages have REPLs now- people get that they're really useful! This isn't secret know…

Nothing you say is in any way incorrect and I agree with it. However, for me, the experience of writing Lisp is very different from that of writing Ruby, or Perl, despite the latter languages having a great many Lispy features. In fact I jokingly call Perl a Lisp-6ish, because of how typeglobs let you mess with the symbol table directly and it has separate namespaces for SCALAR, ARRAY, HASH, CODE (I think that's the…

I think this is mostly an issue of tooling! I admit I often find myself recompiling a full file because SBCL is just so goddamn quick it doesn't make a difference, so perhaps I'm missing something essential. But with tree sitter you could totally write a plugin to, say, run the literal content of a python expression in the REPL. It's just shuffling text around after all. The fact that people haven't done this may indicate, and I stress may, that this is not something that people are missing.

I personally can't use anything without vim bindings. I have evil mode in Emacs, vimium while I'm in Firefox, vim bindings in Nyxt, and an aversion to using any program that isn't one of the above. This is not just hipsterism- on 10 occasions while writing this comment I've had to delete a kj or jk as I tried to exit edit mode. That doesn't really mean non-vim bindings are defective, if you catch my drift. No judgement here! But it's a possibility you might consider.

Re: Why Lisp?

#287
post #94

A point the authors didn't make is that Common Lisp compilers are quite fast compared to e.g. C++ compilers. So even in rare cases where you do need to recompile everything, the cycle time is short. CCL's compiler is lightning-fast. I can recompile an entire system in CCL almost as fast as I can load the compiled object code. SBCL's compiler is slower (while often generating faster code because it does more work at c…

Comparing it to C++ compilers... does Lisp have zero-cost abstractions?

Not sure about Common Lisp, but Julia (which is a Lisp in all ways except surface syntax) definitely does.

Re: Why Lisp?

#288

Earlier quoted context omitted.

There's a place for both even with a REPL I think. Sometimes when I'm tracking a bug down or writing a new function against an old one, I find that I'm writing little one-off functions or worse, replicating a function body line by line in a let block to simulate arguments. Once I opened up a project and realized I wanted one of them, but it was lost when the REPL closed. I literally got as far as opening another file…

> Once I opened up a project and realized I wanted one of them, but it was lost when the REPL closed. You don't type directly in the REPL most of the time. Send lines and functions to it instead.

Ohhh, I wondered why people were so hyped about that! In my head I rounded it off to not wanting to recompile the whole file- I should have realized how dumb that was. This actually makes a lot of sense. When I helped a friend set up Calva, a part of me was really just assuming it was misconfigured- but no, it's designed to facilitate this kind of editing.

Though, I must ask, is it really that much better? I do keep functions around if I think I'll have a use for them again- the vast vast majority really are one-offs. Plus, most of my REPL usage is iterating on an expression. Obviously it's handy to edit it in place, but it's nice having multiple versions, even multiple trees, without having to relocate a cursor or undo unrelated changes.

Re: Why Lisp?

#289
post #262

Earlier quoted context omitted.

In Lisp, we can embed a lower-level language, and macro over it. Like the defx86lapfunction forms in this file: https://github.com/Clozure/ccl/blob/master/level-0/X86/x86-a... It would be useful to have a more abstract, portable form of this (vaguely analogous to WebAssembly): a way to write code for a low level virtual machine that translates to native code.

You're basically describing C++. Nothing in your link suggests a practical way of constructing unboxed arrays of structs in CL. And even if it did, it would presumably be one that worked only on a specific architecture.

The C++ that we have can only be used as an external tool: we write a character-level program into a pipe or file, which is read by an external program. This drops an object file that we have to process. I'm saying that we could have some Algol-like sublanguage with value semantics, and unboxed types. It could output code for a virtual machine, which could be further translated to native code. It would all be in Lisp, not requiring any external tools unrelated to Lisp to be installed.

The source file I linked to shows how you can write native code without leaving Lisp. In that native code, you can move the stack to allocate an unboxed array, and whatever else. But from that it's not a huge leap into having a similar thing but at a higher, and machine-independent level.

Re: Why Lisp?

#290

Earlier quoted context omitted.

There's a place for both even with a REPL I think. Sometimes when I'm tracking a bug down or writing a new function against an old one, I find that I'm writing little one-off functions or worse, replicating a function body line by line in a let block to simulate arguments. Once I opened up a project and realized I wanted one of them, but it was lost when the REPL closed. I literally got as far as opening another file…

I almost always do my repl work in a source code file. That way I never lose it when the repl closes and I can copy it into a test when I know what’s going on.

[see cousin comment for my admission of stupidity]
Post reply on HN