Re:The limits of my language are the limits of my world (2011)
by sparkie on Tuesday December 23, 2014 @03:53PM
(#8790149)
We write with lots of DULs (Domain unspecific languages) in our "blessed" language of Unix, which even Windows speaks a dialect of. The unix language is the one which speaks of "files" and "processes", with a grammar known as "the shell", which is what we use to glue together our DULs (which happen to be files and processes). The reason we need "metaprogramming" in the first place is because there's this artificial boundary called "runtime" where all code must be put into a file, because once you warp the file into a process, it's too late to change the code. Fortunately, some clever people have found a way around this, by making processes which can read other files and simulate the operating system.
When writing code, your world is limited by your operating system too. Heck, we're even limited by the hardware, which hasn't changed conceptually since it was created in the 1940s. We're all under the spell of "instructions to the beat of a clock".
I've spent quite a bit of time recently branching out into new programming languages, writing significant works in each one. And each time I do so, I come back to my day job and realize just how limiting it is to only work in one "blessed" language. There are things which are can be eloquently expressed in Rust or Haskell which do not translate nicely over to Python. Sometimes I can do in a single expression what it would take an entire module of confusing metaprogramming to achieve in Python!
Sadly, that street runs both ways. Some of these new languages want to be so safe that they hobble you down with the chains of explicit types and memory protection; making you write pages of boilerplate to do some of the simplest things.
It's true, when writing code, your world is limited by your language. The flip side of that is also true: by choosing a language, you define the world in which you live.