Language and Idiom in Programming Languages
Usually we talk about programming languages in their literal syntax - BNF trees, keywords, all that raw characters on the buffer. “Dialects” would be something like gcc vs Visual C++, or the “ML family”. We talk about “style” as the perennial flame war elements like braces and variable names. Compare the Linux style guide to something like AS Style or Oxford. It’s all about the elements on the page, not the content.
I’m thinking this is the wrong idea (or at least too low a level). Each programmer has their own style of writing, patterns they use, the structures they prefer, techniques they use, architecture and code organization. It’s like a writer in English or any other language: just because you know vocab and syntax doesn’t make you Shakespeare.
Like most languages, we learn primarily by imitation. You learn your idioms from your peer group - if they talk a certain way, you will too. I often feel like a fish out of water because my colleagues are speaking one dialect or broken English, and I’m speaking something more formal. I can understand them, but it’s not particularly elegant. I certainly have my own idiosynchrasies and biases in my personal style. Maybe we fight so much about braces because it’s as much a proxy for the real dialect differences.
Frameworks gain an additional facet when you consider them in the context of writing. The 3 paragraph essay is the strongest example I can think of. The writer is “filling in the form” when they write. I always wanted to push beyond the format. Freeform writing is quite hard for many people. Starting with a blank page or buffer is paralyzing. Something like Rails or another strongly opinionated framework fits the same concept. Hiring someone who “knows Rails” is implicitly hoping that they write the same idiom. Consider a sonnet as more of an “architecture” - constraining to a structure. More freeform writing takes more discipline and skill to prevent it from jumbling into a mess - and it can still be difficult to understand. Writing spaghetti is just some crazy dude shouting at people you can’t see. We as an industry do a lot of raving and shouting.
In the end, one person is not going to affect any significant change in idiom or dialect of another, except through osmosis. The only way you learn is reading good code. Any writer who claims don’t read other writer’s work so they can maintain their own idependence is a third rate hack. Code reviews or pairing are the most direct way to get exposure. Reading other’s code, especially open source. Use terminology from the state of the art. Don’t anthropomorphise the machine. Introspection is the final key technique - critical reading of your own writing.
Setting the pace initially for an organization really makes a difference. One Shakespeare doesn’t make the whole crew writers, but it will set pace, and give something to emulate. Also for rising stars, their best bet is to apprentice to a good writer so they learn all the good habits and not the bad ones. Your first job is probably the most formative experience.
I do believe there are masters out there with a high level of language and idiom. Given that our discipline is highly technical, I don’t expect flowery prose. But clear, concise, well architeched code is a critical aspiration.
“Expressiveness” is a word bandied about a lot. I think there are a couple meanings.
- High information content. DSLs and scripting languages, especially Python (one way to do it). Jargon and idiom are there to condense information. Higher level languages attempt to remove boilerplate and legwork like memory management so the focus is on the information. DSLs are supposed to be even more information dense. A frequent complaint is that you don’t have full ability to express anything you want if it isn’t in the vocab. Failure mode is something like Perl and regex - so informationally dense it becomes impossible tangle.
- Flexibility. C is ur-example, but dynamic programming languages or macros make the cut. You can skin the crap out of that cat. Information density may be low, but granularity is high. Failure mode is basically reinventing a DSL, or losing the high level information in the boilerplate; illegibility becomes a problem. Good for telling the machine exactly what to do (see next item), or being clever.
- Working in the wrong paradigm. Trying to write functional programming in Java, OOP Java in Scala, or any other way of talking crosswise. Usually a complaint rather than an expression of support. The language doesn’t provide structures or features to write code in a certain way, or they are more verbose. Usually someone ends up trying to write the missing functionality into the language.
- programming