Hacker News Reader

Comment by nickpsecurity | Hacker News Reader

I said the same thing in my comment. You get max productivity with selective use. Nine times out of 10 you don't need them. Overuse of them led to LISP code being hard to read like you said. We don't need to repeat mistakes of history. So, I said add them with a warning to minimize them for maintainability if language is trying to be like Go.

On the other hand, they should be most of the code if taking a DSL- or MOP-like approach. The people using those will be very familiar with the higher-level language. There's a solid, lower-level language underneath for when the VHLL's don't work out. The macros help there.

View on HN

> Overuse of them led to LISP code being hard to read like you said

I don't think that's the case.

That poster your comment goes to claimed that there are types of macros which make debugging harder - not code reading.

Debugging code which makes use of macros is more complicated than code without. There is no doubt about it. One part of it is that debugging happens in a different place -> code transformations with side-effects are running in a compiler or with interpreters at runtime.

You're right. I glazed right over that. No offense intended.

First, it's Lisp not LISP. Using "LISP" immediately flags you as someone with a superficial (if at all there) understanding of the language.

Second, unsubstantiated proclamations like "Overuse of them led to LISP code being hard to read" reinforce the previous point. Could you provide a clear reference where Lisp macros are considered "mistakes of history"? Clear references where overuse of Lisp macros turned out to be a problem?

I'm curious if you've ever used a Lisp development environment with facilities such as interactive macroexpanders or if you're just assuming things based on your (incomplete, suspect) understanding of the domain.

This seems unnecessarily harsh.

Capitalization isn't a deep signal.

There are lIsPs like Clojure that argue (> data functions macros). Although I mostly disagree (for example I love Racket macros), I understand and appreciate the sentiment. I have heard it from other people who have worked with a variety of LiSp code bases over the years. TL;DR: Any form of non-trivial DSL needs supporting materials like documentation and a simple, clear design.

Although it is nice to be able to expand macros, fully-expanded macro-generating macros are clear in approximately the same way as assembly language. It is impressive if you can navigate that, but even more impressive if can manage not to need to do so.

Clojure argues that (> data functions macros), but it still has macros and accepts that they are not only useful, but sometimes necessary. Clojure's core.async would have had to be built into the compiler, if it wasn't for macros. Just because it prefers data to functions and functions to macros, doesn't mean that it doesn't recognise the importance or usefulness of all three.

> lIsPs like Clojure that argue (> data functions macros).

That's not really Lisp related. It's more like how the community likes to see code being written.

For example I would regularly make use of macros to provide more declarative syntax various programming concepts.

There are Lisp dialects which are light on macros and some which are using macros a lot more. For example the base language of Common Lisp already makes use of many macros by providing them to the user as part of the language (from DEFUN, DEFCLASS, ... INCF, upto LOOP).

>First, it's Lisp not LISP. Using "LISP" immediately flags you as someone with a superficial (if at all there) understanding of the language.

Actually both versions are valid.

You seem to not know historical information about Lisp/LISP. While Common Lisp is spelled "Lisp" and more modern use is Lisp, historically LISP has been prevalent (and tons of Lisp dialects prefer the capitalized version, e.g. like "fooLISP" or "barLISP").

Second, you are concerned with superficial details people don't and should not care about. We're programmers, we care about the code and what you can do with it, not about whether some language is "properly" spelled in caps of mixed case.

Third, you are rude, which is worse than both of the above.

"historically LISP has been prevalent"

I learned about it from old books, often on AI, I could scrounge up when I didn't have the Internet or a computer. LISP as in LISt Processor. An acronym. Due to broken memory, I sometimes forget which term to use on stuff that's faded away. I end up about randomly using LISP or Lisp unless its Common Lisp where I usually see "Lisp" in write-ups.

So, good guess.

Reply on news.ycombinator.com