Episode 14: Set My Language Free!
Christoph and Keith explore the intersection between the technological bedrock we take as given when we develop software systems, such as operating systems, TCP/IP networks, files, automatic memory management (and maybe even HTTP), and the free floating ideas we have before we ever write a line of code.
Say ‘technological bedrock’ represents constraints (or the reality) you can’t change, and ideas represent imaginitive worlds you want to bring into being. If that’s the case, then programming languages become the means by which you move from imagination to reality. They’re artistic materials: the raw stuff out of which a representation is made.
If so, why do language developers (and perhaps more earnestly, language users) insist on hardening languages to a sub-set of possibilities? This language requires built-in unit tests, that one doesn’t. The one over there insists that everything is an object, while this one insists that everything is a value. Finally, we have a language with a type system so rich it’s turing complete, while over there, a string is a number, depending on what it contains.
Wouldn’t it be great to have a language in which you can build just the OO you needed, when you needed it? Or what about one in which compile-time static typing were optional for just those areas where it provides real benefit?
What if we think of programming languages more like poets think of words, or painters of paint?
This and more on Flipping the Bozo Bit Episode 14.
Some fun stuff mentioned (sometimes in spirit) in Episode 14:
A programming language in which unit tests are part of a function’s definition.
An expressive, minimilist Lisp for the JVM.
A scalable, multi-paradigm language.
Narcissism of small code differences:
A wonderful post about how developers interact with each other and code. The comments are an excellent example of the principle in action.
Narcissistic Design - Stuart Halloway:
Stuart illustrates how, often, the “best practices” baked into our languages, techniques and assumptions are, in fact, worst practices.