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

81–90 of 322 posts

Re: A road to Lisp: Why Lisp

#81

Post by tikhonj »

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…

It isn't nearly as much of a trade-off as people say. Languages like Haskell are both remarkably expressive and provide a lot of safety. (And, of course, languages like Python, Java and Go are the opposite.)

Re: A road to Lisp: Why Lisp

#82

Post by [deleted] »

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…

[deleted]

Re: A road to Lisp: Why Lisp

#83

Post by pfdietz »

rogue7 wrote: post #23
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…

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.

Re: A road to Lisp: Why Lisp

#84

Post by dang »

AnimalMuppet wrote: post #72
dang wrote: post #54

Earlier quoted context omitted.

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

Booleans? I think some guy named Boole might have prior art... (Yeah, OK, he didn't have a programming language ...)

booleans as values of course.

arguably redundant since GP did say symbolic communication, but Lisp had T before Algol 60 came out

Re: A road to Lisp: Why Lisp

#85

Post by GMoromisato »

tikhonj wrote: post #81
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…

It isn't nearly as much of a trade-off as people say. Languages like Haskell are both remarkably expressive and provide a lot of safety. (And, of course, languages like Python, Java and Go are the opposite.)

Haskell is currently at #18 in LangPop: https://langpop.com/rankings

Almost by definition that implies that it makes some trade-offs that turn off lots of programmers. Still more popular than Lisp, though.

Re: A road to Lisp: Why Lisp

#86

Post by malkia »

iLemming wrote: post #68
jsphweid wrote: post #58

Earlier quoted context omitted.

Why is this being downvoted? It's a reasonable question.

It is fashionable to misunderstand Lisp and hate AI.

I spent years (on my free time) coding Lisp, even had the aspiration (but I was younger then) to rewrite P4V (Perforce Client GUI) in it :) -

https://github.com/malkia/p4bee

but haven't touched it in years....

Re: A road to Lisp: Why Lisp

#87

Post by tmtvl »

lenkite wrote: post #75
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 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. Standardized Concurrency is basic table-stakes for a language today. CL does not have a standardized async/await or concurrency model. The standard hasn't been updated since 1995 so it will never happen.

> The standard hasn't been updated since 1995

The latest finalised submission to the Common Lisp Document Repository (confusingly called CDR instead of CLDR) dates from August 4, 2013. CDRs are the equivalent to the SRFIs from the Scheme world. You could argue that they are not THE standard, but they are A standard. And considering the original standardization supposedly cost 400,000 USD (about 900,000 USD in today's money), I can see why there hasn't been another official ANSI standard.

Post reply on HN