Interesting to see a theme emerge in my Pinboard account this week — lots of stuff about the idea of ‘programming language’. I’ve spent the last few weeks preparing to dive back into a personal interactive music project that I’ve been working on sporadically since I was in graduate school. I had recently realized that the conceptual roadblock I hit before my last hiatus was something that I’d need to address by adding some sort of little programming language into the system. After following Martin Fowler’s many blog posts over the years discussing domain specific languages, I finally broke down and bought his book on the topic. It’s too early yet for me to have much concrete to say about the book, but I remember getting enough out of those blog posts to be confident that it will be worth the money and time to read.
At the same time, these pertinent posts came through my feeds:
So what is a false cognate? Well consider your reaction if I held something out to you and said, “Gift?” Would you thank me or politely demur? Would your reaction change if you knew I was speaking German? (For those not in on the joke, “gift” in English is a synonym for “present” while in German “Gift” is “poison”.) The confusion of poison for present is an example of a false cognate. In natural language, especially in related languages, false cognates abound.
Interesting and important thoughts on languages borrowing from each other in deeply confusing ways. The note on Erlang’s use of
if is especially notable, considering how little concern there seems to have been given to making Erlang’s syntax look inviting and comfortable.
This paper presents a survey for programming language adoption principles drawn from various sociological fields. For example, many programming language features provide benefits that programmers cannot directly and immediately observe and therefore may not find compelling. From clean water to safe sex, the health community has long examined how to surmount similar observability barriers. We discuss how principles and techniques drawn from social sciences such as economics, public health, and historical linguistics relate to programming languages. Finally, we examine implications of our approach, such as for the design space of language features and even the expectations of scientific research into programming languages.
In related news, our grandchildren will still be listening to LISP advocates predicting that the whole world is about to finally understand the beauty and necessity of programming in LISP. They’ll also still be arguing about whether or not Scheme should be considered a dialect of LISP.
Rob Pike from Google talking about patterns of adoption of the Go language, and some thoughts behind the primary design philosophy of the language.
Python and Ruby programmers come to Go because they don’t have to surrender much expressiveness, but gain performance and get to play with concurrency.
C++ programmers don’t come to Go because they have fought hard to gain exquisite control of their programming domain, and don’t want to surrender any of it. To them, software isn’t just about getting the job done, it’s about doing it a certain way.
The issue, then, is that Go’s success would contradict their world view.
And we should have realized that from the beginning. People who are excited about C++11’s new features are not going to care about a language that has so much less. Even if, in the end, it offers so much more.