Comment by nabla9 | Hacker News Reader

Comment by nabla9 | Hacker News Reader

Parent Full thread

>..inventing your own little dialect of the language which is opaque to any 3rd party reading your code unless they take the time to unravel your...

And that, ladies and gentlemen, is called a framework.

Macros or no macros, if the problem domain is large and you stay on it long time, you end up with framework. Macros can make that framework easier, not harder.

In most languages you end up with large configuration files and huge number of strings as parameter. The program semantics might be defined by interpreting JSON structures, template languages and ungodly amount of string parameters that are in effect reserved words. If you persist long enough, you have code generators and state machines and define execution semantics with petri nets.

What you want to do us use the programming language that is best suited to solving the problems you have. Growing the language towards the problem you have is great opportunity to make the programming interface simpler to understand.

With Lisp, especially with Common Lisp it's possible to grow the language so that it stays familiar as much as possible.

I don't understand your post at all. Can you give some examples maybe?

>In most languages you end up with large configuration files and huge number of strings as parameter.

Not in the languages I'm familiar with at least. I don't understand what configuration files and macros have to do with each other.

>Growing the language towards the problem you have is great opportunity to make the programming interface simpler to understand.

Simpler to use, not to understand. You know what it does, you don't know how it does it or how it can be extended because it doesn't play by the language's usual rules. It's nice if you're copy/pasting stack overflow snippets or your use case is very standard, it sucks if you want to modify the code to do something a bit different and out of the box because now you have to learn the rules of this custom DSL.

>With Lisp, especially with Common Lisp it's possible to grow the language so that it stays familiar as much as possible.

So adding custom constructs to the language makes it stay familiar? That doesn't make a lot of sense to me

Basically you evolve the language into the domain of the application. Rather than lowering the application into the domain of the language.

Emacs-lisp is one example of a Lisp that has evolved into the domain of text editing.

> So adding custom constructs to the language makes it stay familiar?

There are rules and conventions for writing macros. If you follow them, their usage will be clear for anyone who knows the language - because the language itself includes a lot of macros and they all follow the same set of rules. Common Lisp, Clojure and Elixir are very good examples of this (with Racket taking it up to 11).

Of course, you can write macros which work and behave in unexpected, weird ways. In practice, though, you don't - why the heck would you?

Because you don't use them in weird ways, surely, but whoever wrote this code did.

... which often includes yourself a year later.

I don't have enough experience with macros to agree/disagree, but parent's comment stood out to me because of the particular framework I've been using lately.

> It's nice if you're copy/pasting stack overflow snippets or your use case is very standard, it sucks if you want to modify the code to do something a bit different and out of the box because now you have to learn the rules of this custom DSL.

This basically describes Spring, and I'm not just being snarky. To someone from the outside, Spring's annotations seem to have all the problems you list. I have trouble imagining that heavy use of macros could be much worse, and I can certainly see the overlap between macros and frameworks.

Every program is a DSL. What do you think you're doing when you define types and functions except make a little DSL of your own? Granted, your "DSL" is somewhat semantically restricted in that it has to conform to the limitations of its host environment, but this limitation doesn't free readers from having to learn how your "DSL" works and imagine ways to manipulate it.

Seen in this light, the kind of DSL you can create with a full-blown macro system isn't all that different.

Programming, in large part, is an exercise in language creation.

If you need new constructs, it's more familiar to do that in the same language than to go to a different language.

> And that, ladies and gentlemen, is called a framework.

It's different. Macros can change the language grammar (it's like inventing a new way to structure a sentence in English, instead of the usual object-verb-complement). Libraries just provide new vocabularies (new names, new verbs, etc.).

Too often frameworks end up also changing the grammar, but doing it in a clunky unnatural way, shoehorning it into the language with tons of boilerplate code that could have been eliminated with a few simple macros.

A framework cannot change a programming language grammar without using macros. Most framework provide new types, functions, classes, constants, etc., which are expanding the vocabulary, not the grammar.

You can use the English language to express ideas on very different topics (food, law, engineering, romance, etc.) without changing its grammar.

> It's different. Macros can change the language grammar

But that's the point. When you can't change the grammar, you instead end up writing in a different language that doesn't even have a grammar, and encoding it in the base language plus a bunch of horrible configuration.

Look at Spring for an example.

Reply on news.ycombinator.com