I’m having a conversation with some people about JavaScript.  A friend of mine is a veteran C++ coder, and is and  indie game developer working in that language.  He’s also learning JavaScript via codecademy.com. In some ways Codecademy is a bit oversimplified for us, as mature developers we can see through to where we’re going and skip steps to go there, but the learning process wants us to make a few obvious (to us, anyway) missteps in order to help justify the better way later.

I’m reminded of when I was trying to teach Algebra students in college.  I’d started my time as a math tutor teaching Calculus (which was a course or two behind where I was), but as time went on, the needs of the group I was working with moved more into the Basic Algebra area.  At the time, I wasn’t very good at it — I had trouble breaking down my thought processes into those basic blocks that the teacher required.  “Show all work” is an interesting directive, but it’s not very specific. If I can add three numbers, or do a factorization in my head, then what I’m showing is all my work, but it’s not enough for the teacher.  Plus, it didn’t help my students any when I could explain how I got to something.  {I think I’ve learned how to do this better in the 20+ years since then, but I have some empathy for those students I tried to help back then.}

That’s a bit of a digression from the online discussion, however. The discussion was about the OO properties of JavaScript.  Now, JavaScript is an object based language.  However, it doesn’t follow the typical OO model, with it’s inheritance, polymorphism, and other traits.  JavaScript uses object composition and prototypal inheritance instead.   It’s a functional language in the since that functions are an object type in JS (but not in the since that J or Haskell are functional languages — JS isn’t immutable, for example.)

Of course, you can do typical OO inheritance with JS.  the Dojo Toolkit does this.  They created a new function to inherit and extend classes. (IIRC it’s actually called extend in Dojo, I’ve also seen it called create in other libraries.)   If you are disciplined and use the function, you get behavior out of JS that mimics the way C++ or Java might work if they were loosely typed.

This was actually my original introduction to the language, and Dojo’s model spoke to me, as I’ve been working with OO languages for most of my career. (My first industry job was developing with PowerBuilder, for instance.)   As I’ve worked, I’ve moved more towards the lighter, more flexible jQuery. It seems to work more the way I need it to, particularly when I’m working with HTML— with jQuery I’m using a tool that fits with what I’m doing already; with Dojo, I’m using a tool that wants me to be working with its own paradigm.  The advantage of jQuery is that I can drop it and most of my apps will keep working.  They won’t be as nice or as responsive, but they’d still function — and that’s an important point.

I remember when I was first working with directX, writing a simple Concentration type game for my niece. One of the common questions on the directX mailing lists (this was a long time ago) was “How do I keep people from pressing Alt-Tab, and leaving my game?”  There were game-balance reasons to do this, at the time Ultima Online had a problem with people writing tools that could play the game for you — and to initialize those tools, you had to alt-tab out of the program and start them.  So by breaking alt-tab they could go back to the way games used to run pre-windows, as the only thing around with no game-breaking tools or processes running.

Of course, to break it back into the shape they were used to, they had to break Windows. So, very often, the response on the mailing lists was simply, “Don’t do that.”  Not that it deterred them, IIRC pressing Alt-tab wasn’t possible in early builds of EverQuest. There might have been one MMO that actually quit if you alt-tabbed.

In general, breaking something so it’ll work the way you want means you’ve got a bad technology fit to your design.  You either need to adapt to your technology by changing your design, or you need to change what technology you are using.  Some of the worst kludges and messed up, fragile code comes from not doing one of these things, and forcing these things to work together in ways they weren’t intended to.

I admit that while I’m pretty competent in JavaScript, I’m still learning how to work with the language. It’s like I’ve made it up the first couple flights of stairs — I can read and edit code; I can competently write code in the language.  And now I’m looking at the next flight which is a deeper understanding of how it works.  I’m sure there’s another stairwell after that, and so on.  You never stop learning.  But getting to grok how object composition and prototypal inheritance work at a fundamental level is my next stairway.

I think my boards project will really help with that, and it’s something I’m keeping in mind while I work on it.