Programming languages: Comparative Spookiness
This is going to be a long, rambling, nerdy post. Non-CS people can safely TLDR it.
Writing a lot of haskell recently has got me thinking about spooky things in programming languages.
Haskell programs have the very surprising property that if you can get the damned thing to compile, it will almost invariably work. I can count on one hand the number of times I've had a unit test fail. It is frankly strange -- it's like a whole chunk of my normal programming life is missing, and I can't tell where it went.
This is not theoretically surprising -- a sufficiently obnoxious type system will force your code to a level of overspecification where there are only half a dozen wrong ways to write a given piece of code and have it compile, as opposed to a more lenient language that might give you a few hundred; haskell goes so far in this direction that at least half of the standard library functions can be described as "the only nontrivial operation with this type signature." But it is alarming -- one has the persistent feeling of having gotten away with something unsavory, as though one's programming karma is being consumed and one will spend one's next life reincarnated as a GOTO.
It reminds me very much of first encountering perl -- you remember, you were blown away, totally amazed, dumbfounded at how much expressive power could be packed into such a small space. (Of course eventually you realized that this spooky conciseness was the same sort of spookiness as a doctor conducting a burnt offering to Mauthe Dhoog in mid-surgery: Malpractice. But in the moment it seemed more profound.)
Perhaps a closer analogy would be to haskell's seeming opposite: Python. Python is spooky because of how precisely the code resembles the plan in one's head -- it is very nearly pseudocode. One sometimes feels that one has sidestepped that whole "figure out how to represent this thing" step.
(Of course a number of my curmudgeonly former coworkers would note that python and haskell, in spite of their opposite approaches to types, have in common that they are fairly obvious rip-offs of Common LISP. But they would also say that reinventing Common LISP is what language design is about, so that doesn't prove much. Also, LISPs are in no way spooky; LISP is the C of non-C-like languages.)
I have to say that I am partial to less-spooky languages for "the real stuff". I have spent enough time doing trench warfare for milliseconds of pseudo-realtime that I will always come back to the reassuring non-spookiness of C or C++ (which is, I say with regretful certainty, a deeply terrible language). Forcing a particular SIMD layout in haskell means changing, rather than merely fighting, the compiler, and there's no in-language way to screw with the allocator at all, and don't even get me started on the IO monadstrosity. And python is downright interpreted -- I shouldn't be a compilation bigot, but I am (perhaps I was abused by microsecond tight-loop-performance regressions in my youth?).
Java occupies a weird place here. It's non-spooky at the micro level -- you don't get anything for free, there are no fundamental conceptual leaps. Its spookiness is more macro -- that it spookily draws in an incredible host of programming stupidities from its practitioners, for example, or that it spookily infects everything with Design Pattern Cancer until your codebase has been replaced with dynamic factory methods taking XML configuration objects and abusing themselves via reflection. I mean, you could write this code in C++, but in your heart you know you'd see it in Java first
(Or C#, which is basically Java in drag, except that that code could manage to have mysterious side effects. I mean "spooky" here in the sense of how the language behaves during development, not how the eventual code behaves under execution...)
I'm going to have to look at Ruby one of these days.
Ah well, back to the haskell. Perhaps I will inject a bug deliberately just to see how it's done.
Writing a lot of haskell recently has got me thinking about spooky things in programming languages.
Haskell programs have the very surprising property that if you can get the damned thing to compile, it will almost invariably work. I can count on one hand the number of times I've had a unit test fail. It is frankly strange -- it's like a whole chunk of my normal programming life is missing, and I can't tell where it went.
This is not theoretically surprising -- a sufficiently obnoxious type system will force your code to a level of overspecification where there are only half a dozen wrong ways to write a given piece of code and have it compile, as opposed to a more lenient language that might give you a few hundred; haskell goes so far in this direction that at least half of the standard library functions can be described as "the only nontrivial operation with this type signature." But it is alarming -- one has the persistent feeling of having gotten away with something unsavory, as though one's programming karma is being consumed and one will spend one's next life reincarnated as a GOTO.
It reminds me very much of first encountering perl -- you remember, you were blown away, totally amazed, dumbfounded at how much expressive power could be packed into such a small space. (Of course eventually you realized that this spooky conciseness was the same sort of spookiness as a doctor conducting a burnt offering to Mauthe Dhoog in mid-surgery: Malpractice. But in the moment it seemed more profound.)
Perhaps a closer analogy would be to haskell's seeming opposite: Python. Python is spooky because of how precisely the code resembles the plan in one's head -- it is very nearly pseudocode. One sometimes feels that one has sidestepped that whole "figure out how to represent this thing" step.
(Of course a number of my curmudgeonly former coworkers would note that python and haskell, in spite of their opposite approaches to types, have in common that they are fairly obvious rip-offs of Common LISP. But they would also say that reinventing Common LISP is what language design is about, so that doesn't prove much. Also, LISPs are in no way spooky; LISP is the C of non-C-like languages.)
I have to say that I am partial to less-spooky languages for "the real stuff". I have spent enough time doing trench warfare for milliseconds of pseudo-realtime that I will always come back to the reassuring non-spookiness of C or C++ (which is, I say with regretful certainty, a deeply terrible language). Forcing a particular SIMD layout in haskell means changing, rather than merely fighting, the compiler, and there's no in-language way to screw with the allocator at all, and don't even get me started on the IO monadstrosity. And python is downright interpreted -- I shouldn't be a compilation bigot, but I am (perhaps I was abused by microsecond tight-loop-performance regressions in my youth?).
Java occupies a weird place here. It's non-spooky at the micro level -- you don't get anything for free, there are no fundamental conceptual leaps. Its spookiness is more macro -- that it spookily draws in an incredible host of programming stupidities from its practitioners, for example, or that it spookily infects everything with Design Pattern Cancer until your codebase has been replaced with dynamic factory methods taking XML configuration objects and abusing themselves via reflection. I mean, you could write this code in C++, but in your heart you know you'd see it in Java first
(Or C#, which is basically Java in drag, except that that code could manage to have mysterious side effects. I mean "spooky" here in the sense of how the language behaves during development, not how the eventual code behaves under execution...)
I'm going to have to look at Ruby one of these days.
Ah well, back to the haskell. Perhaps I will inject a bug deliberately just to see how it's done.