What I took from this post, is that we should keep working on compilers. They could provably optimize away most of the performance issues and move us closer to doing category theory instead of dealing with the metal.
I'd much rather deal with the metal than with category theory.
(I'm not trying to be snarky here, but I've studied category theory and it seems like a whole lot of effort for very little benefit. On the other hand, it's fun to figure out the metal. (Although silicon's not exactly a metal...))
Yes. To oversimplify, it seems like there are two schools of software: the car-mechanic school and the math-professor school. I happen to be of the car mechanic variety. That doesn't mean I'm not borrowing energetically from people pursuing the math-professor approach, but by now I'm pretty sure where my strengths lie. And given that computers (and cars) are mainly used for practical outcomes, I'm totally ok with that bias.
>the car-mechanic school and the math-professor school.
Heh heh. Having worked mostly with math professors, I would say the code they write almost exclusively belongs to the car-mechanic school. Math professors never deck up their code with CT. The majority of the time a math prof has to write code, its to do heavy-duty applied math, engg stuff ( solve pde's, fluid mechanics, EE math, fourier transforms, gradients etc. ) or to display some cool visualization to the students ( here's how a vector space looks! here is what happens when you apply linear transformation!! here are all the elements of a quotient group!!! ) - those tend to be done in Matlab/Mathematica/Maple/Gap...and these tools have zero CT. The applied stuff tends to use netlib, gams, gsl, colt, apache math...mostly a lot of gsl these days...again no CT there. Most of them are very happy to declare giant matrices & happily mutate away.
Heh. Yeah, a lot of the actual PhD-types I know are amateur coders on a mission, and their code matches that.
I'm sure you get it, but just for the record, by math-professor I meant "very focused on things that to most people seem incredibly abstract", with a side of "passionate about solving intellectual challenges for their own sake".
Agree with you there. Programmers need to understand the semantics of their language and use it to their advantage. I think this is especially the case in functional languages, especially in Haskell, where two seemingly similar pieces of code can execute in different ways, especially given the presence of lazy semantics. Knowing how to write efficient code in your language can be significantly different than knowing how to write code that works, depending on the language.
But that's why the abstraction is leaky. You no longer need to think at just the level of the abstraction, but also at the level of the implementation of the abstraction. This is fine, but it's one of the reasons abstractions tend to be less useful than they seem. If you're always thinking about what's really going on, you might as ditch the abstraction and only think about what's really going on. The less you have to think about its implementation, the better an abstraction is.
I sort of buried the lede in my comment... My main point was that while all abstractions are leaky, it's reasonable to judge them on the relative extent of their leakiness.
(I'm not trying to be snarky here, but I've studied category theory and it seems like a whole lot of effort for very little benefit. On the other hand, it's fun to figure out the metal. (Although silicon's not exactly a metal...))