[lispm]

> You can't really standardize something that evolves all the time

You standardize the meta-level and then use best practices. There are many possibilities to extend a language using macros, but actual macro mechanisms may favor a few (for example because some macros are straight forward, where others are more difficult to implement). Thus one now has to learn: how the macro mechanism works, what is the best way to write macros, how to debug macros, ... Working on and with this meta-level is more difficult.

> How do I build a library for a language that despite becoming more powerful for the particular purpose I started using it for, looks nothing like anything else out there?

Usually one would build macros in similar ways. There are some domain-independent principles.

[urs2102]

Absolutely! Oh, don’t get me wrong (again, Common Lisp/Scheme were instrumental in getting me into programming so you’re preaching to the choir), but I guess the point I was trying to make is that there is a real difference between the Lisp approach to standardization and of course C++. Apologies for not being more clear.

There are definite ways to standardize a Lisp, I mean look at all the awesome work Rich Hickey as done on building out Clojure. I just feel that the Lisp (huge generalization incoming) may not care for standardization in the same way Bjarne does when developing C++.

The point I was trying to make (let’s take an example Bjarne cared about that isn’t compatability) is that people in different language communities care about different things. I think it’s fair to say that Ruby developers don’t think about speed as much as people working on C++. It’s not that they don’t care, but ‘programmer happiness’ in the way Matz thinks about Ruby (having an ‘unless’ keyword for example) is more important to Matz than speed. Again, it would be crazy to say Matz doesn’t care about speed, but he, like Bjarne, obviously prioritizes some things over others.

For a college student taking the class, it may seem obvious (“well of course you should build a language focused on certain metrics”), but it’s easier said than done. I remember working on a compiler my junior year where I all I wanted to do was continually add features to my language. Often the problem with the language was with the goals I’d set forth and addressing the problem I was trying to solve, not simply adding more features.

Focus over features is the idea I think Bjarne got across super well.

[lispm]

Lisp has attempted to standardize (in the sense of writing standards) multiple times: Portable Standard Lisp, Common Lisp, ISLisp, Scheme (RXNS, IEEE Scheme).

There are/were different target communities. Common Lisp addressed the needs of (complex) application developers. Scheme had the both industrial and educational users. ISLisp had slightly different goals.

But what the standard limits is not so much the scope it wants to address, but the application areas with their demands and their capability to pay for it. Stroustrop (and many others) got paid over more than a decade to do standards work.

The Common Lisp standardization effort also wrote down what they care about: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node6.html#SE...

ISLisp also has written down about their scope: http://islisp.info/Documents/PDF/islisp-2007-03-17-pd-v23.pd...

But back to the original point. I don't think there is a problem to 'standardize' macros or extension languages which use a lot of macros. For the end user a macro is not different from other syntactic constructs, it's just that these syntactic constructs are coming with language updates or with new (embedded) languages. A Java developer learns the Java language and then she needs to learn various XML-based configuration language plus some another extension language. In Lisp this tends to be within one language with syntactical extensions, which share a common language base.