Archive for May, 2016

Flying Scope and The Great Dinosaur Divide.

Monday, May 23rd, 2016

I’ve recently had occasion to do some work in a javascript-like language and it reminded me of something I thought of years ago.

Javascript and this javascript-like thing I’m using supports closures.
Closures seem to me like one of those things that’s handy for the programmer, and really hard on the computer, or the compiler/interpreter at least.

I never understood why they were called closures. I’ve heard the phrase “close around the variables” or something like that but it seems to me, the concept would better be described as “Flying Scope.” The scope of local variables exists here, then goes away, then magically reappears at a later point in time as if that code had flown away and come back. But that’s me.

At some point I learned how that stuff was implemented and I remember it being not as bad as I thought it had to be, but still, the very concept rubs me the wrong way a bit.

I am a dinosaur, I come from the land of 6502 where there were 56 instructions and 13 addressing modes, and that was it. Everything in the universe had to be implemented through some combination of those 56 instructions. And if you realize that NOP is one, and 7 of them are for setting and clearing particular bits from the flags register, you start to realize how little the dinosaurs had to work with.

So when I see things like flying scope, I feel grief trying to imagine what the poor little computer has to do to make it work. But when I start using closures, because in some cases frameworks force you to use them, I start to see why they appeal to people.

And this is where there great dinosaur divide begins.

I am a very good dinosaur. I understand all the layers of programming from transistors to high level languages. And while it allows me to truly appreciate what’s going on, and offers me a good understanding of bit-twiddling, I think it holds me back in some cases.

People who have no idea the pain that the CPU has to suffer to make closures work can only possibly see the upside. It’s a handy way to write localized stateful code. And it’s very useful. So people use it. It makes sense and it is good.

And here’s the divide.

We can’t go on forever writing software the way we always have. I take into consideration what the compiler comes up with when I write something, because I know what it’s doing. (I’m not saying I understand the gnu c++ optimizer, but the more basic stuff, I get.) And this might encumber me when considering a more abstract design. But the reality is, we’re never going to be able to write really smart software if we concern ourselves with what the computer has to do to make it go.

It is up to the generation after me who would have to go way out of their way to learn what I know, to leave all the low level baggage behind and dream up far crazier constructs than flying scope to enable them to write really really high level abstracted software that can do even more abstract problem solving than we do today.

And the generation after them won’t be encumbered by flying scope or move semantics or any other goofy constructs that will be invented in the near future, because they will have something even better.

The only problem is, you still need somebody to write the compilers, you still need somebody who understands the video hardware so they can write device drivers for them. So not all the dinosaur technology will be lost forever.

But as somebody pointed out to me not too long ago: All the people who have any real first hand experience at landing people on the moon are retired or dead. When they’re gone, that will be it. Experience that can not be replaced by reading a book or watching a video, will be gone forever.

And I figure I can always get into the high frequency trading game. You just can’t do that in javascript.