Bjarne Stroustrup Awarded 2017 Faraday Medal
cs.columbia.edu
cs.columbia.edu
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!
I haven't yet read "The Idea Factory" by Jon Gertner, which covers Bell Labs.
It was an absolute delight to learn from Prof Stroustrup!
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].
Are there other examples of cultures focused on particular metrics that have flourished? Or faded away?
Super curious...
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.
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
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.
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.
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.
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
edit: you cannot, I am equally disappointed and relieved.
Say what you want about modern C++, but Bjarne is an incredible person.
Ok, if you want. Then I will.
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.
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.
He is one of the reasons I keep liking C++, in spite of spending most of my time in other languages.
Well deserved.