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

51–60 of 322 posts

Re: A road to Lisp: Why Lisp

#51

Post by boho_derogatory »

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…

[flagged]

Re: A road to Lisp: Why Lisp

#52

Post by iLemming »

boho_derogatory wrote: post #51
Jtsummers wrote: post #44

Earlier quoted context omitted.

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

[flagged]

Huh? First time I hear that my account is "regarded" and not just, but "widely" too. What part of your fragile ego my words hurt, I wonder?

Re: A road to Lisp: Why Lisp

#53

Post by erichocean »

abetusk wrote: post #32

There are many articles extolling the virtues of Lisp. I would like to see some articles that have a level-headed criticisms or critique of Lisp, it's ideas and it's place in the ecosystem of languages. Articles like this, and the PG articles it references, amount to "if you know, you know". I understand the appeal and I understand the explicit and implicit arguments this article is making. Computer programming has m…

Here you go: https://www.marktarver.com/bipolar.html

It's been discussed many times on HN.

Re: A road to Lisp: Why Lisp

#54

Post by dang »

sph wrote: post #36
vindarel wrote: post #33

Earlier quoted context omitted.

Flight search (Google's ITA Software), underground planning (SISCOG), CAD software (PTC Creo et all), the Gollum face (Mirai), automation of document extraction, renewable energies resource planning (3E), project management (planisware), games (Kandria), Maxima, a faster pgloader ( https://tapoueh.org/blog/2014/05/why-is-pgloader-so-much-fas... ), hackernews (was rewritten to SBCL: https://lisp-journey.gitlab.io/blog…

Yeah but apart from SBCL, Viaweb, Hacker News, Emacs, Clojure, Scheme, Racket, garbage collection, macros, homoiconicity, the REPL, S-expressions, symbolic computation, what has Lisp ever done for us?

...booleans, conditional expressions, first-class functions, lambdas, closures, eval...

Re: A road to Lisp: Why Lisp

#55

Post by dang »

erichocean wrote: post #53
abetusk wrote: post #32

There are many articles extolling the virtues of Lisp. I would like to see some articles that have a level-headed criticisms or critique of Lisp, it's ideas and it's place in the ecosystem of languages. Articles like this, and the PG articles it references, amount to "if you know, you know". I understand the appeal and I understand the explicit and implicit arguments this article is making. Computer programming has m…

Here you go: https://www.marktarver.com/bipolar.html It's been discussed many times on HN.

and strangely relevant again in the age of LLMs - https://news.ycombinator.com/item?id=48126840

Re: A road to Lisp: Why Lisp

#56

Post by erichocean »

sroerick wrote: post #4

I must admit - I still don't understand macros. I get that they're code that's generated at compile time. But I don't understand how that's different than a function which evaluates other functions. I guess the latter would actually be evaluated at runtime? I think I get it conceptually but I'm not sure I have the muscle memory to reach for them. Anybody here have an "ah hah!" Moment with macros?

The arguments presented to a macro don't have to be valid code. Your "function evaluating functions" are all individually valid functions you've composed at runtime.

    (defmacro foo [code] ,,,)
    (foo "")
=> actual, compiled Clojure function built up by `foo` parsing the string, producing a Clojure list, and calling `(eval the-list)` and returning it.

I passed a string to `foo` in the example, but it could actually be anything the Clojure reader can parse even if it is semantically invalid—arbitrary Clojure data.

Re: A road to Lisp: Why Lisp

#57

Post by patrickmay »

GMoromisato wrote: post #22

Programming is in tension between the Light Side and the Dark Side. The Light Side is about preventing the programmer from making mistakes: Get rid of go-tos! Add static types! Do not allow a bug to be expressible. The Dark Side is about giving power to the programmer: Macros? Obviously. Operator overloading? Self-modifying code? Multi-line reg-exps? Go to town! The Light Side knows programmers are flawed and imposes…

I like your metaphor but I'd argue that trusting programmers with power is the Light Side.

Relevant PG: https://paulgraham.com/langdes.html

Re: A road to Lisp: Why Lisp

#59

Post by Barrin92 »

GMoromisato wrote: post #22

Programming is in tension between the Light Side and the Dark Side. The Light Side is about preventing the programmer from making mistakes: Get rid of go-tos! Add static types! Do not allow a bug to be expressible. The Dark Side is about giving power to the programmer: Macros? Obviously. Operator overloading? Self-modifying code? Multi-line reg-exps? Go to town! The Light Side knows programmers are flawed and imposes…

for a while there's been a strong cultural tendency in programming to mistrust people and trust tools (often even blindly because tools are just assumed to make no mistakes), and so expressiveness has been sacrificed for safety. There can be something to this but it's also self-fulfilling, if you strip people of agency of course they'll unlearn to program.

I've always thought it's a misanthropic philosophy and sucked much joy out of programming but also there's something to be said that there's safety in the expressiveness of Lisp. I read an article a while ago that found a robust correlation simply between length of a code base and errors regardless of languages used. And given how succinct and clear Lisp codebases can be that's valuable in itself.

we're kind of at the logical endpoint of this now with gigantic slop codebases that nobody understands just held together by 20 different tools, and if you ask me if I had to pick one of those or something one tenth the size written by a guy or girl who has been writing Lisp for ten years I'd say thank you I'll go with #2

Re: A road to Lisp: Why Lisp

#60

Post by patrec »

abetusk wrote: post #32

There are many articles extolling the virtues of Lisp. I would like to see some articles that have a level-headed criticisms or critique of Lisp, it's ideas and it's place in the ecosystem of languages. Articles like this, and the PG articles it references, amount to "if you know, you know". I understand the appeal and I understand the explicit and implicit arguments this article is making. Computer programming has m…

https://www.tamaspapp.eu/post/common-lisp-to-julia/
Post reply on HN