Live data from Hacker News

A road to Lisp: Why Lisp

scotto.me

131–140 of 322 posts

Re: A road to Lisp: Why Lisp

#131

The website seems to have a bug with syntax highlighting. Pieces of code included in the post text are black, you can still see the actual text if you select it with your mouse. Same bug on Chrome desktop and on Safari on iPad

Thanks for reporting. I fixed the error as soon as I read your comment.

Re: A road to Lisp: Why Lisp

#132

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…

Check out Clojure spec. The light dark bifurcation doesn’t hold up.

Re: A road to Lisp: Why Lisp

#133
post #81

Earlier quoted context omitted.

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.

Language design has almost nothing to do with language popularity.

People learn JavaScript or TypeScript because they want to write web apps. Swift or Objective C to write iOS or Mac apps. SQL because there’s a database they need to get data out of. Python because there’s a machine learning library they need to use. Etc etc.

Language design is far down the list of priorities.

Re: A road to Lisp: Why Lisp

#134

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…

> The former have been table stakes for interpreted languages I used to think so too back in the day when I was getting into Clojure. It was much later when I realized that when Lisp people talk about the REPL they’re usually talking not so much about the interactive CLI where you can evaluate commands easily but more so the ability to connect your program to a live session where you can quickly evaluate forms within…

you can do that in a python debugger?

Re: A road to Lisp: Why Lisp

#135

Earlier quoted context omitted.

You do not need macros for anything. They are not the tool to "extend the language", but instructions for the compiler. And if the system does not even have a compiler, macros are useless, often incredibly stupid.

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

Re: A road to Lisp: Why Lisp

#136

Earlier quoted context omitted.

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

This was a very pleasant read.

Re: A road to Lisp: Why Lisp

#139

[dead]

I would be very interest in seeing how "getting lisp" enables you to write software that is more successful than the C and C++ software that runs the world. Perhaps you have written software in Lisp demonstrating this? Something you can show us?

Re: A road to Lisp: Why Lisp

#140
It's really fun: I read so many propaganda on Lisp here that by now we should all be coding in it. Don't we get perhaps weekly posts like this?

But ... somehow almost everyone simply ignores this propaganda --- that's actually the way we ought to handle propaganda! Funny that it works with Lisp, but not with many political topics where it can be shown that propaganda really works.

My experience with Lisp is somewhat special-cornered. I only know Emacs-Lisp, and that not great. And for me, Lisp an out, outdated and confusing thing.

I don't know ANY other programming language that elected assembler mnemonics to be "high"-level expression: car and cdr.

While I love Emacs, they claim all the time that is has 100% discovery through build in doc. But that is only 70% true. It doesn't exist in Lisp like it does in other languages. For example, I have an association list. Now, what functions exist that uses them? I can't use the equivalent for (dir alist), alist.dir(), or use some LSP for that. I can't even look in the symbols, because operators are written like assoc or assq with not logic. And then there are either prefixes to them (rassoc) or postfixes (assoc-string).

That there is no namespace is soooo 1970. I mean, even Turbo-Pascal had namespaces.

Typechecking is nonexistant.

At least we have byte-compiling.

And note that I don't croak about the parenthesis. While I find it mildy weird that I as a human program in almost-AST, Emacs has superp support for the parenthesis. So people croaking about them just had never had a good editor IMHO.

Now, one can argue that Emacs Lisp != Common Lisp. But these propaganda articles don't tend to promote one specific Lisp, they only talk in generals. So I can apply this general principle and compare it to the tiny corner of these awful language family.

Post reply on HN