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

151–160 of 322 posts

Re: A road to Lisp: Why Lisp

#151

Post by bigpeopleareold »

pfdietz wrote: post #83
rogue7 wrote: post #23

Earlier quoted context omitted.

Kind of agree, but in my view preventing the programmer to make mistakes is futile. I have seen awful stuff in languages made to prevent errors. It's much better to give all the power to the programmer, to allow him to fix his mistakes rather than fantasising about preventing them.

I'm not big on static type checking in most situations -- adequate testing should find the type errors too -- but one place it looks very useful is avoiding data races in multithreaded programs. See Rust.

... or Ada.

Re: A road to Lisp: Why Lisp

#152

Post by gf000 »

throwaway81523 wrote: post #105
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 sid…

If you squint enough, JS is a lisp..

Define a goddamn language, syntax is not enough to define one! What are the semantics? Without that you are just talking about syntax trees like they would mean anything

Re: A road to Lisp: Why Lisp

#153

Post by sph »

throwaway81523 wrote: post #105
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 sid…

> Erlang, which if you squint is another Lisp dialect

Prolog disagrees. IIRC the first versions of Erlang were written in Prolog, and you can still see its influence in the syntax.

Re: A road to Lisp: Why Lisp

#154

Post by vaylian »

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…

The lisp curse: https://www.winestockwebdesign.com/Essays/Lisp_Curse.html

Re: A road to Lisp: Why Lisp

#155

Post by sph »

akkartik wrote: post #116
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…

You mixed up Light and Dark. Creator-knows-best bondage-and-discipline is the Dark side. Trusting people with power is the Light side.

Light and dark is propaganda depending on which side you're on.

I'm with you, on the dark side I've seen people slowly turn into crabs, screeching about memory safety and static types. Can you imagine that? Now stick those wings on me, I'm going to fly close to the sun.

Re: A road to Lisp: Why Lisp

#156

Post by gf000 »

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…

What idea? S-expressions?

Because that's all these languages share. What's common in CL and Clojure? They are as dissimilar as C and Scala.

Re: A road to Lisp: Why Lisp

#157

Post by throwaway81523 »

gf000 wrote: post #152
throwaway81523 wrote: post #105

Earlier quoted context omitted.

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

If you squint enough, JS is a lisp.. Define a goddamn language, syntax is not enough to define one! What are the semantics? Without that you are just talking about syntax trees like they would mean anything

> If you squint enough, JS is a lisp..

Yes, that is true. I'm not big on the idea that Lisp is defined by parentheses. The implementation strategies are another way to look at it. That doesn't capture it either, but it's an angle to try.

Re: A road to Lisp: Why Lisp

#158

Post by gf000 »

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…

Why do you think other people who have fallen in love with, say, Ruby, are less experienced in other languages? They just have less of a cult.

Re: A road to Lisp: Why Lisp

#159

Post by gf000 »

iLemming wrote: post #48
dismalaf wrote: post #46

Earlier quoted context omitted.

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.

Can you parse code into an in-memory representation and can you eval?

If yes, then you can do everything that Lisp repls can.

The parser being slightly more complex than parsing s-expressions doesn't materially change anything.

Re: A road to Lisp: Why Lisp

#160

Post by gf000 »

veqq wrote: post #66
jolt42 wrote: post #20

Earlier quoted context omitted.

But with Clojure and immutable by default, hot reload is a real thing, it sounds like not just on JVM but even among lisps.

Clojure barely let you import packages without restarting the JVM recently in its life.

Can you expand on that? I am mildly experienced with Clojure, and much more so with the JVM and I see no reason for that to happen (besides perhaps some kind of module shenanigans or importing stuff that requires special flags?)
Post reply on HN