“It ain’t what you don’t know that gets you into trouble, it is what you know for sure just ain’t so,” said Mark Twain. Actually, some dude named Josh Billings said it, but continuing to attribute it to Mark Twain is nicely ironic.
When it comes to programming, our assumptions give us blind spots. I talked about this in relation to code in a recent column, but it can be even worse when we work for years with an outdated certainty.
The specifics of programming change with every release of a library, and the challenge of software development as attempting to rapidly deliver value against the needs of our users is unchanging. But, in between deprecated APIs and “The Mythical Man-Month” are the beliefs that shape not only how we approach problems, but which problems we commit ourselves to tackling.
The quintessential example may well be how older developers put programming languages in two camps (interpreted vs. compiled) and then make a bunch of assumptions about the characteristics of both the language and any programs written in that language.
Shaders, such as those at shadertoy.com, demonstrate how little value the old model delivers (yes, shaders are compiled, but can be updated more or less instantly within the browser).
Probably the only useful distinction is whether there is a compilation step distinctly perceivable by the developer. Today, this is not so much about the structure of the program as it is about the type system. You probably have a strong belief that the type system of a programming language has a strong effect on its productivity. Did you learn to program in college? You likely feel that more formal type systems keep the developer on the straight and narrow, catching certain errors but, more importantly, keeping their code focused and clear. Did you learn to program on your own or in a code camp? Probably you feel that the speed with which you can modify a function (perhaps even while the program continues to run) keeps the developer immersed and that the kinds of errors that type systems catch are not the things that slow down development.
If you are the type of developer who likes to debate such things, you know that there is ample support for your position, and anyone who holds the opposite opinion is willfully obtuse. In reality, not so much.