[senex]

This is really interesting. What kind of metrics is the culture focused on? How were they established. Can you think of examples when critical/deliberate decisions were made to pursue the integrity of the culture (rather than shifting or broadening focus)? Has cultural orientation or measurements changed over time? How and why?

Are there other examples of cultures focused on particular metrics that have flourished? Or faded away?

Super curious...

[urs2102]

So there are a number of examples, but Bjarne used to stress 'compatibility' for example. It was a really important idea for him, that despite the really clean and smaller language that he could have developed, it was very important for him to have tighter compatibility with C.

In many ways, he discussed how he hasn't built a 'perfect language', and that as languages operate as tools, it's very important to be focused and decide what matters over what doesn't.

Sure you could have a prettier language, but as programmers there is a cost to everything and sometimes we are so eager to see the benefits in any new tool, it's easy to forget to measure the costs (he also really, really enjoyed having us benchmark things to see the cost in using x method over y method).

Making it explicitly clear what you intend to focus on, and setting a standard for not just yourself, but your community encourages the language to grow in a way that it remains useful and sustainable. He mentioned that if he built out this tighter/cleaner language, it's also possible that the language would have failed to generate any traction at all.

I'm not entirely sure of cultures that have flourished or faded particular ideas, but if you look at how despite newer languages are constantly taking old ideas from Lisp, how come Lisp didn't take off (and I say this as a true fan of Lisp)? Again, I'm totally hypothesizing, but it may have to do with compatibility.

You can say that Lisp's syntax (or lack thereof) is really important to not just how macros are developed, but for Lisp programmers to have a language that evolves. Yet at the same time, Lisp's greatest strength is often its biggest weakness. You can't really standardize something that evolves all the time, and as such, can't really have compatability. 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?

I think his main point tended to be, pick things that matter to you: metrics that matter to you, ideas that matter to you, a mission that matters to you and just really work on that. It's easy to get distracted and just add features "just because", but make sure they conform to the metrics you set forth for yourself.

[pjmlp]

He was quite right, this is what attracted me to C++ after Turbo Pascal, in spite of disliking C.

I could have the type safety of Turbo Pascal, its scope of language features and spend less time writing my own FFI wrappers to the OS APIs, that were adopting C as their new systems language.

Of course to achieve that safety like level, I still had to write my own wrapper classes, but it was less effort than full blown FFI code in languages that have completely difference concepts.

EDIT: Typo, was -> as

[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.

[DonHopkins]

Guido van Rossum also has a similar wisdom and attitude, though very different goals and priorities than Bjarne Stroustrup of course, when he judges Python extension proposals by how "Pythonic" they are.

Even if somebody can come up with a clever syntactically valid way of changing python syntax or semantics (like in all heated discussions about lambda), it still might lack the proper "Pythonicity" that makes it fit in with the rest of the language, and would spoil the Zen of Python's [1] "There should be one -- and preferably only one -- obvious way to do it."-ness of the language.

[1] The Zen of Python: https://www.python.org/dev/peps/pep-0020/

Bjorn's April Fools joke paper "Generalizing Overloading for C++2000" paper [2] was so hilarious and self-aware because it elegantly conformed to and perfectly parodied the C++ way of doing things, yet showed what can happen if taken to extremes: you get 💩++ [3]

[2] Generalizing Overloading for C++2000: http://www.stroustrup.com/whitespace98.pdf

[3] Unicode Character 'PILE OF POO' (U+1F4A9): http://www.fileformat.info/info/unicode/char/1F4A9/index.htm

Guido's ramble on the nature of Pythonicity and comparison of language design to user interface design is very insightful: [4]

[4] All Things Pythonic: Language Design Is Not Just Solving Puzzles, by Guido van van Rossum, February 9, 2006: http://www.artima.com/weblogs/viewpost.jsp?thread=147358

"Summary: An incident on python-dev today made me appreciate (again) that there's more to language design than puzzle-solving. A ramble on the nature of Pythonicity, culminating in a comparison of language design to user interface design."

... I'm not saying that one language or design philosophy is superior to the other, but that they're both quite aware of and well focused on their own different goals. (Virtues lacking from dazzled magpie design of PHP, for example.)

So it can be delicious when you combine them together [5] [6] like chocolate and peanut butter [7]:

[5] Boost.Python: http://www.boost.org/doc/libs/1_65_1/libs/python/doc/html/in...

[6] SWIG: http://www.swig.org/

[6] Reese's Peanut Butter Cups: https://www.youtube.com/watch?v=GuENAWds5B0