On: Lisp as the Maxwell’s Equations of Software (2012)

[afiori]

That for sure, but what I mean is that syntactic simplicity does not translate to simplicity of meaning.

In the case of lisp and its rich macros system the only thing I can see is that anything could cause any kind of effect; I see this as a significant source of complexity in practice. I am sure that library/implementation authors made a fantastic job in refining wonderful abstraction so that this is not a problem in practice.

Julia offers also has rich macros but there the messaging there is different, macros are intended to be used in library code to allow for greater ergonomics. Users of the language to be able to write an idiomatic library as that involve language features that are not necessary in normal scripting.

(I just now realize that I never heard of an Obfuscated Lisp Contest, things could get quite crazy there)

[evdubs → afiori]

Have you written lisp code? As a Racket programmer, I almost never think about macros, readers, code transformers, or whatever could interfere with what I think should happen in the same way that I would write Java code. To give an example, the only time I thought macros might be useful was when defining class types (contracts) and default values.

In https://github.com/evdubs/interactive-brokers-api/blob/maste..., there is plenty of:

  (define/contract some-class%
    (class/c (init-field [class-member-a integer?])))

  (class* some-class%
    (init-field [class-member-a 0]))

Maybe it would have been nice to have:

  (define/contract/class* some-class%
    (init-field [class-member-a integer? 0]))

All this would be doing is defining a class with both a type (contract) and a default value without having to first define/contract for types (contracts) and later defining class member defaults.

It's great that Julia has messaging that macros should be reserved for libraries. I can't say that I've seen Racket messaging be the same, but I also don't see a proliferation of macros in libraries that I choose to use for projects, either. Especially in such a manner that makes me concerned that, "will this completely screw up my intention?" If you have a different experience, I am curious to hear it.

[afiori → evdubs]

> As a Racket programmer, I almost never think about macros, readers, code transformers, or whatever could interfere with what I think should happen in the same way that I would write Java code.

This is exactly what I mean, Racket is not a nice language because it has a minimal syntax, it is a nice language because it is powerful, well thought, and its features work well together. Homoiconicity and macros are tools that Racket uses internally to define itself and they are essential to how many of the language features work, but often they are not directly relevant to the (non-library-writing) user.