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

291–300 of 322 posts

Re: A road to Lisp: Why Lisp

#291

Post by tehjoker »

Jtsummers wrote: post #119
tehjoker wrote: post #117

I played a little bit around with LISP but I was astounded when I saw that you run programs using the live REPL. I thought, how can you reliably deploy a finished program if it can get messed with at any time? Why isn't there a way to compile to a binary?

> I was astounded when I saw that you run programs using the live REPL. That's one way, you stopped too early in your investigation though. You can produce binaries, though the precise mechanism will vary by your implementation. And there's no reason to use the REPL for it. You can create an executable file with something like this: (defun main () ...) ; do whatever you need in here for program launch (sb-ext:save-li…

Thank you, that's very helpful to know!

Re: A road to Lisp: Why Lisp

#292

Post by iLemming »

zbentley wrote: post #290
iLemming wrote: post #67

Earlier quoted context omitted.

Homoiconicity is a "uniquely Lisp" feature and it doesn't seem like you've fully grokked the implications and differences between homoiconic and non-homoiconic. I'm not making this up - every step there in Read-Eval-Print-Loop does differ. That is easily verifiable info.

Eval differs very slightly from, say, an interpreter with a very non-syntactic AST, due as you say to homoiconicity. Neither read, print, nor loop differ in any Lisp-specific or qualitative way. And the differences in eval’s behavior don’t change anything significant about the REPL user’s experience (other than that they’re writing Lisp). So what do you mean? Specifically, cached state and behaviors still need to be…

> don’t change anything significant about the REPL user’s experience

Perhaps you have never tried/heard of nextjournal/clerk, scicloj/clay, djblue/portal, vlaaad/reveal or just simply tried building a simple web scraper with Playwright running on nbb. Oh, and hyperfiddle/electric - something like that would not be very trivial without homoiconicity.

Re: A road to Lisp: Why Lisp

#293

Post by iLemming »

throwaway81523 wrote: post #145
hajile wrote: post #141

Earlier quoted context omitted.

Your lisp criticism is orthogonal to the idea of lisp itself. Lisps like Coalton (lambda calculus) or Shen (sequent calculus) are strongly typed. AI is an interesting point too where being closer to a raw AST is likely an advantage because it can focus more on the semantics instead of the syntax.

You can wrap parentheses around anything and call it Lisp, but I specified Common Lisp and pg's article clearly wasn't contemplating anything like Shen. Surface syntax is near irrelevant though.

I feel you're now contradicting your own statements now. You said: "[maybe] Lisp is just another Blub", but when pointed out that Lisp (and Lispers) is evolving, you're saying "pg clearly meant [the other Lisp]"...

Of course we're not talking about "parenthesis". Clojure even added square brackets for arguments and destructuring, it's not about the syntax, I agree on that.

Re: A road to Lisp: Why Lisp

#294

Post by GMoromisato »

James_K wrote: post #126
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 dislike when people use the term “power” to describe making code slightly shorter to type. Operator overloading is not in any meaningful sense more powerful than a language which lacks it.

Maybe you've never been in a codebase that overloads the comma operator.

Re: A road to Lisp: Why Lisp

#296

Post by drob518 »

GMoromisato wrote: post #277
astrobe_ wrote: post #190

Earlier quoted context omitted.

I'll paraphrase someone who commented on HN once (about dynamic vs static typing, IIRC): permissive languages are enablers for solo programmers, but you need more restrictive languages for team programming. This matches my experience because you don't chose who you work with. Skill level is uneven among the team. Less skilled co-workers will make mistakes that will have more consequences when the language is more per…

I agree with you. Though I wonder if the divide is more about the size of the program. I've got a couple of large (>100K LoC) solo projects and I like using C++ because it is much easier to catch bugs at compile time. Static typing is a huge advantage in refactoring, and if you don't refactor a large program as it grows, you end up with a mess.

Clojure programmer here. Refactoring is the only time I miss static typing.

Re: A road to Lisp: Why Lisp

#297

Post by drob518 »

pjmlp wrote: post #203
sph wrote: post #153

Earlier quoted context omitted.

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

Correct, although I would assert Prolog shares many concepts with Lisp.

It does. In Prolog, data is code is data as well.

Re: A road to Lisp: Why Lisp

#298

Post by vindarel »

Charon77 wrote: post #187

I really love the idea of lisp but feels like the learning curve is steep. Sure you can learn basic lisp in an hour or so but then? You need to learn emacs, all of the plugins, module systems. Maybe I just don't know where to start.

Start here with Common Lisp 8-) https://lispcookbook.github.io/cl-cookbook/getting-started.h... To learn the language, look at the good books out there (Touretzky's etc).

ps: you don't need to learn Emacs. A terminal even is enough. See the Cookbook/ Editors section.

Re: A road to Lisp: Why Lisp

#299

Post by dismalaf »

iLemming wrote: post #292
zbentley wrote: post #290

Earlier quoted context omitted.

Eval differs very slightly from, say, an interpreter with a very non-syntactic AST, due as you say to homoiconicity. Neither read, print, nor loop differ in any Lisp-specific or qualitative way. And the differences in eval’s behavior don’t change anything significant about the REPL user’s experience (other than that they’re writing Lisp). So what do you mean? Specifically, cached state and behaviors still need to be…

> don’t change anything significant about the REPL user’s experience Perhaps you have never tried/heard of nextjournal/clerk, scicloj/clay, djblue/portal, vlaaad/reveal or just simply tried building a simple web scraper with Playwright running on nbb. Oh, and hyperfiddle/electric - something like that would not be very trivial without homoiconicity.

Lol equivalents to all those exist in at least half a dozen non-Lisp languages.

Re: A road to Lisp: Why Lisp

#300

Post by kazinator »

timonoko wrote: post #135
kazinator wrote: post #65

Earlier quoted context omitted.

If you have an interpreter only, no compiler, using macros for metaprogramming anwyay at least prepares you for the eventuality that one day there will be a compiler. The macros will Just Work as before, only the expanded code is now processed by compiling. Suppose you reject the idea that there will ever be a compiler. Macros are still useful for doing "compiler-like things" in the context of interpretation, like tr…

TLDR, but you are (probably) describing somekind of builtin property. I am just saying that the end-user do not need macros for much anything, unless she has some specific optimization in mind. Bloody annoying when they start making cryptic macros to "extend the language".

"Need" is a very tenuous word, because most of any tool stack consists of benefits.

End users benefit from things that they don't strictly need.

Once you start talking about what people don't need, it's hard to do it in a way such that they need Lisp but don't need macros.

Sometimes "need" is about dependencies; i.e. things you "need" are provided by upstreams; you stop needing things that you made yourself.

E.g. "I don't need objects. Because, well, I have lambdas and macros, and with that control over syntax and semantics, I made my own objects. So, strictly speaking, I do need objects, just don't need them from you or anyone else."

People disagree over what constitutes a benefit; something someone finds beneficial in their work is crap to someone else, and the easiest way to disparage someone else's beneficial thing is resort to the necessity rhetoric.

"Everything that I found beneficial in conducting my successful XYZ project, which got to a level of complexity and quality in so many years of effort and lines of code, was obviously necessary; all else is unnecessary."

A really sneaky way to do that is to repeatedly acknowledge the benefit of something while emphasizing the lack of necessity. With a sprinkle of FUD about possible harms that outweigh benefits ...

Post reply on HN