Took a class with him in college, perhaps one of the smartest people I've had the opportunity to meet.
Nobody tells a story quite like Bjarne, and nothing beats the classes he would open with a story straight out of Bell Labs. Him and his brilliant TA, David (if you're reading this definitely send me a message!), were awesome in showing not just how C++ has been built over the years, but how a steadfast approach to building a culture focused on particular metrics was crucial to C++'s development (and to the development of any other project as well).
Congratulations Bjarne; learned a lot about benchmarking from your class!
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?
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.
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.
> 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.
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.
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.
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.
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.
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]
"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]:
Haha! Don't let that deter you from attending the lectures! I unfortunately didn't get past the waitlist but was still able to attend the lectures and learn a lot.
It was an absolute delight to learn from Prof Stroustrup!
Good to see you here (again) Prakhar! Didn't know you audited Prof. Stroustrup's class.
If I can recommend a project for the HN community to check out, it's krat0sprakhar's JSJS project. One of the prettiest projects I've seen in my time at college as well [0].
Bjarne himself has written/spoke about that era quite a lot, I can't direct you into anything specific but he usually weaves a lot of tidbits from the past into his talks.
At cppcon this morning he spent 10s expressing his gratitude, and followed up with a talk on "Teaching Modern C++". In the talk, he explained how C++ needed textbooks/teachers to focus on the message they're trying to pass to students, because he believes that putting ideas in peoples heads is more important than showing off new features.
Say what you want about modern C++, but Bjarne is an incredible person.
Modern C++ is one of my favorite programming languages I've ever used. Some years, I write it exclusively, others not so much. Depends on the work. But in my memory I have a particularly fond spot for those periods in which I was writing C++14.
That's an excellent book. I remember reading it without knowing much about C++ and at the end I had a pretty good idea why things work the thing they do. You can debate about C++ in general but Stroustrup's writing is a big part of C++'s success.
Of course his books and wider accomplishments show that he's very smart; he manages to explain everything he writes about, in detail, with the least amount of words necessary - no less, not more. In that sense, his books are a bit like "The C Programming Language" - concise, yet don't read as 'abbreviations'; but also complete, often answering the questions that pop into your head as you're reading something in the next sentence.
But I only got a real appreciation for how much he truly 'masters' programming from his description of an n-dimensional data structure in the 4th edition of 'The C++ Programming Language'. There, he transfers those qualities into software design; very clearly laying out requirements, and writing a beautifully concise implementation as he goes along. There is so much to be learned from that chapter alone.
First time I met him was at an OOPSLA conference when C++ was just starting to get traction, while Smalltalk80 still ruled - so at the end, he's sagged back against a pole and we're all excited, asking if this ain't just grand - his response was priceless - 'It's terrible. Damn thing is too small to get any money for and too big to kill."
I remember to have interviewed him long time ago for a radio/tv show. Very smart person, and kind too. By then I was very young so my questions were most probably a bit dumb though (I think I even asked if C++ wasn't a bit "too much" :-)) :-( I hope I didn't waste his time.
Nobody tells a story quite like Bjarne, and nothing beats the classes he would open with a story straight out of Bell Labs. Him and his brilliant TA, David (if you're reading this definitely send me a message!), were awesome in showing not just how C++ has been built over the years, but how a steadfast approach to building a culture focused on particular metrics was crucial to C++'s development (and to the development of any other project as well).
Congratulations Bjarne; learned a lot about benchmarking from your class!