Comment by sdegutis | Hacker News Reader

Comment by sdegutis | Hacker News Reader

The main feature Go was missing that took away most of the usefulness of writing a Lisp in it was FFI. If you can't dynamically get identifiers (constants, functions, variables) by a string at runtime, you lose most of the interesting desktop possibilities. It's probably still useful as a server-side language but Lisps seem the most useful in the GUI space.

Also it says this in the author's latest blog post:

> "Yes, there are a lot of parens, but that is a small price to pay for a language that is capable of morphing itself into nearly anything you need it to be. And the way that Lisp does that is with a macro system that puts #define to shame!"

I'm convinced this is not the real benefit of a Lisp. The only thing macros can do that functions can't is hide control flow. And 99% of the time that's a bad thing that library authors should not use. It could be used to make other language features such as concurrency, but that's a slippery slope.

The real benefit of macros in my opinion is a balanced syntax that makes things like Emacs + paredit possible, which increases your productivity like 5x-10x. It's on another level, definitely worth trying for a few months if you work with a Lisp already. But I don't see any other real value in Lisp's syntax or in macros.

Nah man,macros are the bee's knees! Being able to add new constructs to a language is neat. My favourite examples are match.scm - a pattern matcher that produces zero overhead code - and racket's for loops, which are just regular macros.

Being able to add features like that is amazing. Clojure'sarrow syntax? No problem. Python's list comprehensions? Can be done! A library for Pattern matching? Many to chose from!

Pattern matchers that were added to other languages as libraries are often weird to use. Match.scm has the same syntax as cond or case.

Unpopular opinion that doesn't even disagree with you. LOOP is superior to rackets for loops.

The minimizing and maximizing constructs are surprisingly readable.

I agree to some extent. To get the same power from rackets loops you have to do a lot more work using for/fold.

I have an implementation of rackets loops for guile scheme, and I'm currently rewriting it to allow arbitrary transformations in the loop clauses.

Say I want to write a Fibonacci loop, currently I can't do this:

    (for/list ((a :first 0 :then b) (b :first 1 :then (+ a b))) a)

I forgot to mention that loop requires a lot of mutation, which sort of sucks in scheme world where you can use multi-shot continuations and ruin the fun. There are loop implementations for racket (which produce decent code and all that), but they are rarely used.

Lisp always sounds cool to me until someone starts talking about macros. What's it like inheriting a lisp code base, finding out its full of homemade macros like list comprehensions, and that they're not documented? Inheriting a code base is always scary, but I feel like it kicks it up a notch when your predecessors can customize the language itself. Are my fears justified?

> What's it like inheriting a lisp code base, finding out its full of homemade macros like list comprehensions, and that they're not documented?

If such a macro is used in more than two places, it's generally a relief that the author did that instead of doing copy and paste by hand.

The author had some coding idea, and formalized it into a little robot that writes that idea, which has a name.

Even if that thing isn't accompanied by documentation, it can serve as a kind of documentation to what it's doing.

Code is going to be full of homemade functions that are not documented; whether they are functions that write code at compile time, or whether they are run-time functions, is kind of a minor concern.

Macros look the same as functions in lisp, the only difference is that you can't pass them as function arguments. Unless there is a bug in the macro you just spend the same time understanding the macro that you would understanding a function.

Most macros are just simple syntactic abstractions that expands simple code to more lines of relatively simple code to avoid boilerplate. Very rarely do people write complex beasts without documentation.

> The only thing macros can do that functions can't is hide control flow.

Syntactic flexibility is valuable, sometimes. Not often, I'll give you.

Reply on news.ycombinator.com