Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A road to Lisp: Why Lisp

scotto.me

Post reply on HN
Print view View original

41–50 of 322 posts

Re: A road to Lisp: Why Lisp

#41

Post by dismalaf »

iLemming wrote: post #39
dismalaf wrote: post #21

Earlier quoted context omitted.

You've been able to do this in Ruby since I can remember. Not a lot of editors take advantage of it though...

No. There is real, palpable, practical, functional difference between working a Lisp REPL and a REPL in a non-homoiconic languages - Ruby, Python, Haskell, etc. Every single stage there in Read-Eval-Print-Loop differs. Man, it gets so exhausting trying to convince every PL critic who grabs a single (or a couple) of axis of any language and tries to dispute the value of a language without ever understanding the holist…

Tell me your knowledge of Ruby is surface level without telling me...

I used Clojure when it first came out, I've used Common Lisp for years, I've also used languages like Smalltalk and many others.

Yes, Lisp environments are nice, but sometimes I think Lispers are so insular they don't realize that other languages have similar things. R, Julia and Ruby have similar environments. Smalltalk is next level.

And homoiconicity is great for macros and parsing but it's late-binding that enables the live programming behaviour, which isn't exclusive to Lisp.

Also if you'd ever gotten deep into say, SB-ALIEN, you'd know the limitations too; Common Lisp isn't magic, it can't just redefine say, instantiated structs in memory. It relies on pointers then switching references on the fly.

Re: A road to Lisp: Why Lisp

#42

Post by iLemming »

gentooflux wrote: post #30
malkia wrote: post #25

I've been wondering - Is lisp (common lisp, clojure, scheme) easier for iterative work with LLMs?

I've found LLMs to be bad at balancing parenthesis. I've also found them to be less likely to hallucinate library types in dynamic languages, they tend to hallucinate arguments to library functions/methods instead.

> LLMs to be bad at balancing parenthesis

Because you treating Lisp just like any other (non-homoiconic) PL. Give an agent a true Lisp REPL to mess around, and you'd be surprised. Things get very interesting. I still don't understand why more people don't do that - isn't that obvious first thing anyone should figure out? Like I can't even imagine working with Lisp without a REPL and structural editing - I'd immediately fail at balancing parens. Why do you expect a [dumber] machine would do any better?

Re: A road to Lisp: Why Lisp

#43

Post by zbentley »

iLemming wrote: post #39
dismalaf wrote: post #21

Earlier quoted context omitted.

You've been able to do this in Ruby since I can remember. Not a lot of editors take advantage of it though...

No. There is real, palpable, practical, functional difference between working a Lisp REPL and a REPL in a non-homoiconic languages - Ruby, Python, Haskell, etc. Every single stage there in Read-Eval-Print-Loop differs. Man, it gets so exhausting trying to convince every PL critic who grabs a single (or a couple) of axis of any language and tries to dispute the value of a language without ever understanding the holist…

I wrote GGP as a Lisp user and enjoyer—not pretending to deep experience, but definitely am well acquainted. And neither the REPL nor live reloading are important differentiators. Neither is the ability to attach a REPL to a running program: plenty of languages have that built in (Erlang, Ruby), and many others support it through popular third party tooling (e.g. Pyrasite for Python, and—ironically—the class executor for the Clojure REPL for arbitrary non-Clojure JVM programs). Many Lisps’ REPL tooling is very nice, and the language lends itself well to REPL-oriented development. But those aren’t “uniquely Lisp” features as you and many others claim.

Re: A road to Lisp: Why Lisp

#44

Post by Jtsummers »

iLemming wrote: post #39
dismalaf wrote: post #21

Earlier quoted context omitted.

You've been able to do this in Ruby since I can remember. Not a lot of editors take advantage of it though...

No. There is real, palpable, practical, functional difference between working a Lisp REPL and a REPL in a non-homoiconic languages - Ruby, Python, Haskell, etc. Every single stage there in Read-Eval-Print-Loop differs. Man, it gets so exhausting trying to convince every PL critic who grabs a single (or a couple) of axis of any language and tries to dispute the value of a language without ever understanding the holist…

> There is real, palpable, practical, functional difference between working a Lisp REPL and a REPL in a non-homoiconic languages

Smalltalk is not homoiconic, and it's REPL experience is equivalent (I'd argue somewhat better, but that's mostly a tooling thing, see the commercial CL implementations as examples of improvements over SBCL + Emacs + Slime). Homoiconicity is not the trait that makes the CL REPL experience better than others, it's that it includes a very good debugger, the compiler, hot code reloading, the ability to redefine classes and update current instances, and so on.

That's the tooling, not the language, that provides the experience. Nothing about being non-homoiconic prevents other languages from having a comparable (or even better) experience.

Re: A road to Lisp: Why Lisp

#45

Post by iLemming »

dismalaf wrote: post #41
iLemming wrote: post #39

Earlier quoted context omitted.

No. There is real, palpable, practical, functional difference between working a Lisp REPL and a REPL in a non-homoiconic languages - Ruby, Python, Haskell, etc. Every single stage there in Read-Eval-Print-Loop differs. Man, it gets so exhausting trying to convince every PL critic who grabs a single (or a couple) of axis of any language and tries to dispute the value of a language without ever understanding the holist…

Tell me your knowledge of Ruby is surface level without telling me... I used Clojure when it first came out, I've used Common Lisp for years, I've also used languages like Smalltalk and many others. Yes, Lisp environments are nice, but sometimes I think Lispers are so insular they don't realize that other languages have similar things. R, Julia and Ruby have similar environments. Smalltalk is next level. And homoicon…

> they don't realize that other languages have similar things

Yes they do. God, how did you (and apparently you're not alone) read my rant and still got it 100% backwards? I specifically hinted about not picking a single aspect of a language - REPL or whatever. What is so confusing about my wording on "holistic, overall experience working with it"?

Re: A road to Lisp: Why Lisp

#46

Post by dismalaf »

iLemming wrote: post #45
dismalaf wrote: post #41

Earlier quoted context omitted.

Tell me your knowledge of Ruby is surface level without telling me... I used Clojure when it first came out, I've used Common Lisp for years, I've also used languages like Smalltalk and many others. Yes, Lisp environments are nice, but sometimes I think Lispers are so insular they don't realize that other languages have similar things. R, Julia and Ruby have similar environments. Smalltalk is next level. And homoicon…

> they don't realize that other languages have similar things Yes they do. God, how did you (and apparently you're not alone) read my rant and still got it 100% backwards? I specifically hinted about not picking a single aspect of a language - REPL or whatever. What is so confusing about my wording on "holistic, overall experience working with it"?

Apart from your rant, this is the most pertinent part of what you said:

> There is real, palpable, practical, functional difference between working a Lisp REPL and a REPL in a non-homoiconic languages

And it's false. There's nothing special about a REPL in a homoiconic language. Homoiconicity has nothing to do with a REPL or tools.

I do however think SBCL has a very nice environment with great tools (especially it's compiler) and that's why I've used it a lot over the years, but I really think you underestimate the environments in other languages (including the "holistic, overall experience").

Re: A road to Lisp: Why Lisp

#47

Post by iLemming »

sph wrote: post #14
arikrahman wrote: post #10

All roads lead to Lisp

What has Lisp ever done for us?

> What has Lisp ever done for us?

phanitathion, roaphs, aqueduphs, mediphine, wphine...

I'm sorry. Couldn't resist - I watch Python and do Lisp. Or the other way around, sometimes. And, no, I'm not from Barthselona.

Re: A road to Lisp: Why Lisp

#48

Post by iLemming »

dismalaf wrote: post #46
iLemming wrote: post #45

Earlier quoted context omitted.

> they don't realize that other languages have similar things Yes they do. God, how did you (and apparently you're not alone) read my rant and still got it 100% backwards? I specifically hinted about not picking a single aspect of a language - REPL or whatever. What is so confusing about my wording on "holistic, overall experience working with it"?

Apart from your rant, this is the most pertinent part of what you said: > There is real, palpable, practical, functional difference between working a Lisp REPL and a REPL in a non-homoiconic languages And it's false. There's nothing special about a REPL in a homoiconic language. Homoiconicity has nothing to do with a REPL or tools. I do however think SBCL has a very nice environment with great tools (especially it's…

> And it's false. There's nothing special about a REPL

You are wrong. You might be correct about the workflow but still wrong about the semantics. Pedantically, your notion is false, because homoiconism gives the REPL a genuine capability (program-as-manipulable-data across the read/eval boundary) that non-homoiconic REPLs lack.

Re: A road to Lisp: Why Lisp

#49

Post by iLemming »

Jtsummers wrote: post #44
iLemming wrote: post #39

Earlier quoted context omitted.

No. There is real, palpable, practical, functional difference between working a Lisp REPL and a REPL in a non-homoiconic languages - Ruby, Python, Haskell, etc. Every single stage there in Read-Eval-Print-Loop differs. Man, it gets so exhausting trying to convince every PL critic who grabs a single (or a couple) of axis of any language and tries to dispute the value of a language without ever understanding the holist…

> There is real, palpable, practical, functional difference between working a Lisp REPL and a REPL in a non-homoiconic languages Smalltalk is not homoiconic, and it's REPL experience is equivalent (I'd argue somewhat better, but that's mostly a tooling thing, see the commercial CL implementations as examples of improvements over SBCL + Emacs + Slime). Homoiconicity is not the trait that makes the CL REPL experience b…

> Nothing about being non-homoiconic

Nothing about being statically/dynamically typed. Nothing about being functional/OOP/relational/logic. Nothing about being pure/side-effecty/strict/lazy. Nothing about being compiled/interpreted. Nothing about imperative/procedural/stack-oriented.

You can pick just about any single or (few) aspects about any language. Heck, it doesn't even have to be a programming language and you can find things to complain about.

You know that there are three genuine, true, legit ways to build robust, bug-free, performant software? Three! The problem? Nobody knows what they are and that's why we are all doomed to keep bashing on everyone else's choices and opinions.

"Better experience" is not dictated by "features". Better experience comes, well, with experience.

I suppose it's my own fault. I tried focusing on "holistic, overall experience", yet still picked a single aspect to chime in.

Re: A road to Lisp: Why Lisp

#50

Post by boho_derogatory »

dismalaf wrote: post #41
iLemming wrote: post #39

Earlier quoted context omitted.

No. There is real, palpable, practical, functional difference between working a Lisp REPL and a REPL in a non-homoiconic languages - Ruby, Python, Haskell, etc. Every single stage there in Read-Eval-Print-Loop differs. Man, it gets so exhausting trying to convince every PL critic who grabs a single (or a couple) of axis of any language and tries to dispute the value of a language without ever understanding the holist…

Tell me your knowledge of Ruby is surface level without telling me... I used Clojure when it first came out, I've used Common Lisp for years, I've also used languages like Smalltalk and many others. Yes, Lisp environments are nice, but sometimes I think Lispers are so insular they don't realize that other languages have similar things. R, Julia and Ruby have similar environments. Smalltalk is next level. And homoicon…

[flagged]
Post reply on HN