11 July 2016

JavaScript OOP inheritance explained with diagrams

We're not talking about ES6 classes today.  Just ES5 JavaScript object-oriented programming.

## Prototypal inheritance

People say there's at least these **3 big features of OOP** that distinguishes OOP from other styles of programming:

1. Encapsulation
2. Polymorphism
3. Inheritance

We're going to focus on the last item today.

OOP in JavaScript isn't intrinsically class-based in the style of Java.  I assume you already know a thing or two about OOP in terms of Java or Python, or similar though.

Instead, **JavaScript OOP is prototype based**.

That means you'd just make an object `c` as you like it, no class definition required --- but if you must think in classes, imagine making a class `C` and using it to create exactly the one object `c`.

Then when you want another object `s` to inherit from object `c`, you'd just do it, *no class required* --- again if you must, imagine making a class `S` that inherits from `C`, and using `S` to create exactly the one object `s`.

Conceptually, it's simple, but trying to use it productively, with constructors and everything else, and it can get confusing.

Rather than learning how to do class-based OOP in JavaScript (for that, see MDN's [Introduction to Object-Oriented JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Introduction_to_Object-Oriented_JavaScript) instead), let's try to really understand what JavaScript is doing --- from the bottom up.

## Diving in, bottom up

In JavaScript, everything are objects, even functions.

OK, some things are primitives... forget that, let's just see some code.

By the way, I'm running all the code in the Firefox Console.  Explanations and diagrams are interwoven into the code as comments.

## Cosmic Super Object
Let's start with the "cosmic super" object that all objects
usually inherit from, namely the object stored at 

typeof(Object.prototype); // is an object

Object.prototype.prototype === undefined; // true
Object.prototype.__proto__ === null; // true

So `Object.prototype` doesn't have a `prototype`, and it doesn't
"`__proto__`-inherit" from anything.  The buck stops here.

In JavaScript, each object `o` has a `__proto__` property that
points to the object that `o` **prototypely-inherits** from
(as opposed to "inherit" in the class-based sense).

So from here on, if `s.__proto__ === k` then we say `s` **proto-inherits** from `k`.  I use the term "proto-inherit" to distinguish from the Java-style, class-based, concept of inheritance.

Yes, `__proto__` is deprecated, but it works (for now) and is easier to think with.

We're going to start diagram out the relationship
between the various objects we're exploring in JavaScript.

| Object.prototype  |
| __proto__ (null)  | recall __proto__ is defined but null
|                   |

As described before, if you must think in classes, then making an object
in JavaScript is like writing a class and instantiating exactly one object
from it, so we'll draw objects in the style of UML classes.

| object name       |
| properties        |
| methods           | of course methods are just 
+-------------------+ functions stored in properties

21 December 2015

Computer Science: a diluted term, soon to be meaningless

I just saw a grade 6 school teacher's course web page.  He teaches a "Computer Science" course wherein students learned to type and format letters in Microsoft Word and Apple Pages.

There's a high school teacher who teaches "Computer Science".  His course emphasizes drawing and painting in Photoshop, and animating things in Flash.  Yes, I know you can do a lot of programming in Flash.  No, they don't do very much programming in that course.

Teachers: Please, don't call typing and formatting a letter in a word processor "Computer Science". Please don't call a multimedia class "Computer Science".  It's confusing students into thinking "Computer Science" is what used to be called "Computer class".

If your class has a mix of subject matters, call it "Computer class", then within it you can have units on "Business Applications" or "Information Processing", "Multimedia", and maybe even a unit on "Computer Science" (which would only have programming and/or the more "math side" of computer science).

Otherwise, students will one day step foot in a real Computer Science class, be it in a high school with a real CS focused teacher, or in college or university.  And they're going to go "WTF, this isn't CS", when in fact they were duped in earlier grade school.

I've seen this happen before in a different subject: engineering.  Schools started offering "engineering" courses that were really just the old electro-technologies courses, which were closer to engineering-technician courses.  Imagine the surprise when some students who took those courses and got into university engineering then faced down the barrage of engineering math and physics courses.

Actually, who am I kidding.  It's already happening with Computer Science.  The term is meaningless among many junior high students.  Many of them think it's Photoshop, PowerPoint, or photography.

This is brand dilution.  And it's too late.

20 December 2015

Governments mandating which programming language to teach

Over the years, I've been asked to provide some suggestions regarding what programming language should be mandated by government curriculum for teachers to teach.

One excuse for having a curriculum mandated programming language is that it'd help teachers with less knowledge tap into a bigger wealth of information as all teachers would be teaching the same language.  Or at least having a main, recommended language would help curricula development, again because everyone would teach the same thing.

I can't agree with that position.

The government mandated curriculum should be language and vendor neutral, or else it'll be captured by greed, special interest lobbies, and corporations.  It'll be technologically held back while the rest of the world moves forward until the next curriculum update (in about 10 years time --- that's more than one lifetime in technological progress).

Of course, the next curriculum update won't change much in the curriculum because of path dependence.  Because so much resources has been created for the old outdated stuff, and so the curriculum would lock in a specific technology for decades at a time even if it gets outdated.

Do we want to lock into the curriculum for decades at a time: COBOL?  FORTRAN?  C?  Java?  C#?  Python?

15 September 2015

SMART Notebook 11.4 on Mac OS X 10.10 Yosemite requires Ruby 1.8

I upgraded my Mac to OS X 10.10 Yosemite and SMART Notebook 11.4 started to crash upon opening it.  SMART doesn't provide a patch or any information on why that is, except that you'd basically need to buy a newer version of Notebook (which I wasn't about to do).

So with some investigation it turns out SMART Notebook 11.4 requires Ruby 1.8 to work.  Except installing Ruby 1.8 from, e.g., Homebrew doesn't work.  I guess SMART had statically linked Notebook 11.4 against the particular Ruby library that was distributed by Apple.

A bit of research online turns up a post describing the same problem and the solution: copy Ruby 1.8 from a pre-Yosemite Mac over to Yosemite in the same directory.

The directory is /System/Library/Frameworks/Ruby.framework/Versions/.

Someone even made an installer and posted a link in the comments in that post, although I can't say whether you should trust using that installer...  Not feeling comfortable using that installer, I dug up an older Mac and zipped up the 1.8 folder from the above directory and copied it over to my Yosemite machine.

Leave a comment here or message me if you want a zipped copy of the Ruby 1.8 folder.  Or else if you feel comfortable with using that unvetted installer, then go download it from that comment.

Problems with this fix

Note that this method of making SMART Notebook 11.4 work will make the program less stable.  I've had crashes from time to time.  It also makes the toolbar unusable, and in fact, it won't even show up on the screen!  So get used to picking tools the long way via the menubar instead.

I do wish there was a better software solution to what I'll call the "Projector Transparency Roll - Writable (50 feet)".

08 September 2015

Worries over losing deep conceptual knowledge: Better teaching in any subject, part 4

A concern some may have with facilitating learning through the inner game of meaning-as-uses is that it seems to turn everything into decomposed techniques and skills, lacking in holistic, deep, conceptual, or otherwise "meaningful" knowledge.

A moment's thought should give you comfort that that's very far from the truth.

Imagine complaining that by breaking tennis up into the various forehand and backhand techniques, players will lose sight of the holistic meaningful concepts required to understanding tennis.

I'd imagine a lot of the worry comes about from not "seeing" the holistic concepts being taught or learned when seeing only the individual techniques being learned.  Traditionally, we'd see the worksheets for practicing factoring quadratics but never see the worksheets for learning what quadratics are conceptually, or what the meaning of factoring is.  From that, we might be led to believe that there must be something wrong with worksheets or with not teaching concepts and meanings (as if we could even directly teach concepts or meanings at all).