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

101–110 of 322 posts

Re: A road to Lisp: Why Lisp

#101

Post by BeetleB »

janalsncm wrote: post #99
BeetleB wrote: post #79

Earlier quoted context omitted.

> But I don't understand how that's different than a function which evaluates other functions. You want a function that takes in arguments, but does not evaluate the arguments when called. So: func(foobar(), foobar()) Normally, foobar() will be called twice - at the time of the call. With macro expansion, you can ensure that it's not the result of calling foobar that goes into the func, but this expression. A canonic…

(I think you meant “if condition is false”) Technically you can accomplish the same thing in languages with first class functions if the caller wraps their code in a lambda.

No, I meant "if condition is true".

The point is that in most/all languages, if the condition is true, the else branch is not evaluated. And it's usually OK to put code in there that can crash when the condition is true, because we know it won't be evaluated.

But if you make an if function like I did above in, say, Python, both the then_path and the else_path are evaluated before the decision is made.

> Technically you can accomplish the same thing in languages with first class functions if the caller wraps their code in a lambda.

True. For languages that have lambdas (which I guess is most of them nowadays).

Re: A road to Lisp: Why Lisp

#102

Post by ux266478 »

frwrfwrfeefwf wrote: post #88

[dead]

In an awkward, error-prone, non-mathematically rigorous and easily subverted manner. That whole "make invalid states unrepresentable" thing relies upon the fact the semantic structures you're doing it with can't be shadowed silently by other parts of the code, and the safety constraint itself is guaranteed to be completely pure and deterministic. Lisp macros and reader macros fail at that criteria. They aren't any different from any other collection of procedures and their collective interface. Actually, they're a fair bit worse since the natural cognitive overhead from juggling multiple layers of evaluative indirection lends itself to blindspots of edge cases and unsoundness.

I think "macros are a safety mechanism" might qualify for the top 3 "new lisper mania" things I've ever read.

Re: A road to Lisp: Why Lisp

#103

Post by ux266478 »

zbentley wrote: post #12

There are some truly powerful and unique things about Lisps, but I wish articles like this would stop including REPLs and hot-reloading. The former have been table stakes for interpreted languages (and some compiled ones!) for years, and the latter is neither unique nor particularly widely used (hot reloads have to tangle with state and patching, so resetting the world for ease of reasoning is considered a best pract…

Generally speaking, the pain of handling hot patching depends highly on the structure of your codebase and the reason for hot patching to begin with. For a structure-of-arrays architecture, or for fixing logic errors at run-time, it's really no big deal at all.

It is limited utility, but if you start out from the mindset it's something you'll use a lot, those limitations start disappearing rather quickly.

Re: A road to Lisp: Why Lisp

#104

Post by enfield-argent »

adamddev1 wrote: post #64
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 think the big thing is that Lisp is (aside from mutable variable assignment) basically all declarative, rather than the imperative paradigm. Even without static types, and even allowing macro craziness, there's just such a stronger baseline of declarative and functional thinking, you're off to such a good start in clearer thinking and reasoning about a program.

I think this depends on the Lisp, no? AFAIK Common Lisp supports a lot of imperative style programming--besides all the mutation/assignment functions, there's the `prog` macro that lets you use goto, `do`/`do*` to iterate over groups of statements, or even the `loop` macro. OTOH the Scheme-style Lisps are much more declarative thanks to TCO and a community that prefers the functional/declarative programming style.

But again, I suppose all the Lisp forms return values, and quibbling about the declarative : imperative :: expressions : statements mapping is just petty semantics

Re: A road to Lisp: Why Lisp

#105

Post by throwaway81523 »

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…

Lisp generally has precise GC, which I'd say makes it light side. It's even relatively type-safe if you count runtime type-checking.

Highly reliable systems are written in Erlang, which if you squint is another Lisp dialect. There's even a sexp-based version called LFE, for Lisp-flavored Erlang. Erlang's key to reliability is error recovery, rather than exceptional levels of error prevention.

I do like your light side/dark side classification.

Re: A road to Lisp: Why Lisp

#106

Post by throwaway81523 »

GMoromisato wrote: post #38
busfahrer wrote: post #28

Earlier quoted context omitted.

> Or maybe Lisp is so pure that it embodies both Light Side and Dark Side, like a god that spawned the programming universe. This isn't so far off, considering that some people consider the "Lisp in Lisp" bit from the 1.5 manual to be the "Maxwell's Equations in Software": https://michaelnielsen.org/ddi/lisp-as-the-maxwells-equation...

Maybe machine language is the formless chaos and Lisp is the purest manifestation of order. All other languages are points in between.

See Cardelli's breakdown in his famous article "Typeful programming":

http://www.lucacardelli.name/Papers/TypefulProg.pdf

Page 52 perhaps.

Re: A road to Lisp: Why Lisp

#107

Post by throwaway81523 »

GMoromisato wrote: post #95
frwrfwrfeefwf wrote: post #88

[dead]

Of course you feel this way. You just finished reading SICP or maybe you binged PG essays last weekend. But eventually you'll read Simon Peyton Jones and start screaming about functional programming and algebraic type systems. Then, if you're lucky, you'll get a real job and realize that languages are just a tiny part of software engineering. I'm excited for you to experience that journey.

Wadler's old article comparing Miranda (a Haskell forebear) to Scheme might be a better place to start.

https://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87....

Re: A road to Lisp: Why Lisp

#108

Post by throwaway81523 »

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…

I mentioned this already but you might like: https://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87....

Re: A road to Lisp: Why Lisp

#109

Post by throwaway81523 »

iLemming wrote: post #94
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…

> programming has matured quite a bit Your wording sounds like it implies that Lisp "got stuck" somewhere in the past, no? Clojure, Clojurescript, Clojure-Dart, Fennel, Jade, Jank, Jolt, Coalton - these are relatively recent (and still developing) languages, and this is just off the top of my head, there are so many more. Lisp is not a programming language (in a sense), it's an idea. It influenced pretty much every s…

> Your wording sounds like it implies that Lisp "got stuck" somewhere in the past, no?

Pretty much. See pg's famous "Blub Paradox" where he sees Lisp as the top of a tower of lesser languages. He doesn't recognize that Lisp might at best be called a limit ordinal, to use math jargon. That is, Lisp is just another Blub, and the Lisp zealots haven't figured that out.

You don't necessarily want to keep going further and further up, of course. Lisp still has fascination. But e.g., in Common Lisp (I mean just the stuff in the CL spec, no ad-hoc extensions allowed) you can't write anything resembling an OS. You can in Scheme, using continuations to handle process switching.

Going further up, Lisp doesn't make it easy to ensure the absence of particular behaviours in a program, what TAPL calls the purpose of a type system. Tony Morrison has a semi-realistic example of what static types can get you:

http://blog.tmorris.net/posts/understanding-practical-api-de...

Link still works but TLS certificate expired in 2025, tsk tsk.

Re: A road to Lisp: Why Lisp

#110

Post by janalsncm »

BeetleB wrote: post #101
janalsncm wrote: post #99

Earlier quoted context omitted.

(I think you meant “if condition is false”) Technically you can accomplish the same thing in languages with first class functions if the caller wraps their code in a lambda.

No, I meant "if condition is true". The point is that in most/all languages, if the condition is true, the else branch is not evaluated. And it's usually OK to put code in there that can crash when the condition is true, because we know it won't be evaluated. But if you make an if function like I did above in, say, Python, both the then_path and the else_path are evaluated before the decision is made. > Technically y…

Ok yeah looking at it again I understand now. Still learning to read.
Post reply on HN