Bits and Behavior

> this sounds more like an artsclass to me.

Indeed, it is, and that's the point! Being interfaces to computers for humans, programming languages sit at the intersection of computer science and humanities. Lots of people like to treat programming languages like they're math class, but that's only half the picture. The other half is usability, ergonomics, learnability, and especially community. Not to mention the form of the language is all about aesthetics. How many times has someone on Hacker News called a language "beautiful" or "ugly" referring to the way it looks? When people praise Python they talk about how easy it is to read and how pleasant it is to look at compared to C++. Or look at what people say about Elm error messages versus C++ template errors. Actually a lot of what's wrong with C++ could have been averted if the designers had paid more attention in art class.

> But these days we would need greater insights into higher-level language semantics and inherent tradeoffs to guide language-design and language evolution.

Here's a talk that argues there's much more fertile languages ground for ideas outside of the "programming languages are math" area, which has been thoroughly strip-mined for decades:

https://medium.com/bits-and-behavior/my-splash-2016-keynote-81cc802f5f6e

This author takes the perspective that programming languages are much greater than the sum of the syntax + semantics + toolchain + libraries, and treating them as such is limiting their…

I'm a university professor in CS. I don't teach people how to problem-solve, and I have never known what other people are talking about when they claim they teach that in their courses. I teach fundamental skills, and then I put my students in front of lots of problems. In an ideal world, they transfer that experience to new problems. My most important role is providing the motivation and structure to go tackle assignments that might be similar to the ones they tackle later on in their careers. I really like Amy Ko's take on the process: https://medium.com/bits-and-behavior/the-transfer-problem-in-computing-education-501d4f129897

All of that pales to the real process going on: good students were matriculated into my program, and I credential them via a bunch of assessments that I wrote despite never having any classes on formal assessment design. If you gave us a random sample of the population, I doubt we'd be that great at turning them into Computer Scientists.

I encourage you to watch this talk by Amy J. Ko called A Human View of Programming she gave at SPLASHCon a couple years ago [0]. It makes that case that the predominant view of programming languages as math or tools is not the only valid view, and that by holding this narrow definition for programming languages, the PL community has left a huge design space untapped.

I think it's fine for you to expect repeatability and precision from the languages you use if you are using them as tools. But not everyone uses programming languages that way, so I don't think a PL that is not repeatable and precise is any less of a programming language. It may not be a good tool, but as the talk argues, that's okay, as this is only one a narrow view of programming languages.

https://medium.com/bits-and-behavior/my-splash-2016-keynote-81cc802f5f6e

I agree with you. To put it simply, papers are optimized for the scientific community and making them "more accessible" to outsiders has a cost. I'd settle for better writing and presentations within the scientific community for now. If you ever find researchers that blog about their research in simple terms, I think it's safe to assume they're using their personal time to do that (I know of very few; Andy Ko [1] comes to mind).

[1] https://medium.com/bits-and-behavior