Entries in JavaScript (2)



I'm writing this shortly after my bigfoot/werewolf expose. I'm assuming my revelations are not going to rock the scientific and para-scientific communities to their respective cores, so I should continue documenting my JavaScript odyssey and get a head start on closures.

This was a new and initially mystifying programming concept to me. In some ways it's still mystifying, but it's something that just seemed to make more sense as I thought about it, which is unusual for me. That doesn't sound good, but I mean that I usually only get something when I actually do it. Adding database content to a webpage is a good example of that. I first did that with PHP, and I copied sample code, substituting my own values where appropriate. It made no sense to me until I did it a few times.

I had a different experience with closures. When first learning about them, I found the concept incomprehensible. The basic idea is you write a function, and in that function you write another function, then you return the second function. The trick about it is that any variables you make in the first function are available in the one you return. Normally function variables disappear as soon as the function is over. In this case JS takes that environment created in the first function and tacks it on to the returned function for later reference.

For some reason that clicked in my head in a way that most other novel concepts don't. I did write some sample code to make sure I actually understood, and it worked. Stuff like that always makes me a little philosophical. Curious about how the brain works.

I discussed this a bit with mentor Adam, and he said closures don't come up a lot for him, and when they do it's usually somewhat esoteric, where he needs an original value of a variable that would otherwise be inaccessible. Neither of us could come up with an example of that, but I understand what he means.

I was a little surprised at that, because it seemed to me that closures were a great way to reuse simple variable names without having to worry that you've already used that variable name somewhere else. Admittedly, I'm approaching this from a theoretical position and he's approaching it from a functional one. It may well turn out that once I start really writing code that I don't turn to closures nearly as often as I think I will while learning about them.

I think the next step for me is going to be getting back into writing code. It's been tough lately. I think it's a combination of the weather changing and some personal family stuff. I've had a lot of trouble summoning the will or energy to do much of anything. Even writing this has been a struggle. I'm sure these feelings will pass, as they always do, I just wish I knew a way to speed things along.


JavaScript Types and Conversions

I figured, when I started on JavaScript, that there would be a point where the familiar turned into the unfamiliar, and I've definitely reached that point. About half of the book I've been using to learn JS has covered the familiar stuff. How to assign values to variables, how to make functions, loops, conditional checks, etc. While I hesitate to call it easy, it's the stuff that seems to be in common with all C-based languages. The syntax might be a little different, but the fundamental concepts are the same. But now I'm getting into new stuff, and I can't tell if this is just new ground for me in general, or if this stuff is unique to JS. I'm suspecting it's a little of both.

I recently finished a chapter that delved into JavaScript's...um...interesting approach to types. I had initially embraced JS partly because it's loosely typed. I can probably attribute that to starting with PHP. I found C# frustrating at times because there was no automatic type conversion, and I would frequently run into errors when trying to run code because I was trying to mix the wrong type. At the time I would admit that there are benefits to the C# approach, but secretly I was like "This is dumb, I miss PHP". Now that I've lifted up the rock, and seen all the creepy crawlies, I'm starting to think maybe a strongly typed system isn't so bad.

I had a thought when I was learning PHP. It was basically that it seemed like several people started working on different parts of the language, and sort of met up in the middle, but they didn't quite match up. So much of the language made good logical sense, except for a few odd patches. Naming is inconsistent, and sometimes built-in functions that seem very similar operate differently. JS seems more consistent, but there is one kind of rough patch, and that's all this types and conversion stuff.

The basic stuff isn't so bad, you just have to keep it in mind. Like with comparisons done using ==, JS will automatically try to convert strings into numbers to compare them. So "5" == 5 is true. The strict equality operator === has no time for such shenanigans. Numbers can only match numbers, strings can only match strings, etc. This is the same in PHP, so this stuff wasn't any big surprise. Booleans will convert to 1 for true, 0 for false, same deal. 1 == true may not look right, but it'll evaluate to true. The math operators are fun too. At least with comparisons you can always use === to suppress that fun conversion, but there's no way to make the math operators strict that I know of. So "8" - 7 will evaluate to 1. That's not so bad, except if you're trying to add. Then it flips and treats everything like a string. So "5" + 5 will evaluate to "55". It'll even work with empty strings. 5 + "" + 5 is 55.

Ok, that stuff is just fun messing around. Why I really wanted to write this was to talk about NaN. I don't think there's a NaN equivalent in PHP. NaN stands for Not a Number, and is used to represent numbers that are unrepresentable. This is all the stuff that would give you the error message on your calculator. 0/0, trying to find the square root of negative numbers, stuff like that (I totally knew that off the top of my head and didn't just peak at the book). The other thing that evaluates to NaN is trying to convert a string that isn't purely numbers into a number. See? Just trying to talk about this stuff is confusing. So "23" is a string because of the quotes, right? But it's all numbers, so that will convert if you try to subtract or multiply with it. Something like "monkey" though, will evaluate to NaN if you try to do math with it.

Now so far I'm with them. There are other ways to handle something like that, but this is the JS approach. That's fine. But then the rough patches start. For one, NaN isn't equal to anything, not even itself. So I wanted to try this for funsies, so I whipped up a quick page and script that would assign 0/0 to a variable, then compare the variable to itself, and spit out true or false. Sure enough, it's false. And that means that you can't even test for it how you normally would. If you need to check for null or undefined, you can just use the comparison operator. If you try that with NaN, you get false, because NaN isn't equal to anything. And the best part of all? If you use a function to test what type NaN is, it's a number. Yes, Not a Number is a number. This actually made me laugh when I read it. I have to admit, though, it does make sense, just not at first. NaN is supposed to numbers that can't be represented, so it makes sense it would be a number. It also makes sense that it can't equal itself because it can't be represented. It can't hold a value for 0/0 because we can't represent that value. And as soon as it does the comparison it's the new value, it doesn't retain the original formula used to derive it. So even if the formulas are identical it can't know that after the conversion. So even though it makes sense, it's counter intuitive enough to make it seem like 2 guys were working on different things, and realized they needed to stitch the whole thing together, and came up with NaN. I don't think that's the real story, but it reminded me of that thought I had about PHP.

Another example of that is null and undefined. Basically, both mean the same thing. "You made a thing, but haven't put anything in it yet". The rule of thumb is undefined is for empty variables, and null is for empty objects. But why have both? It feels like object guy and variable guy had a meeting when they were done and realized they used different words for the same thing. They will even evaluate to true if you compare them with the == operator. I feel like this isn't a huge deal once you're aware of it, but it is an extra pitfall in something that is, quite frankly, hard enough on its own. But then if this stuff easy then everyone would be doing it, right? Part of me writing this out is so I have to put it in my own words, which should hopefully help me remember it. I feel like my teen years of playing D&D and Magic the Gathering have primed me for remembering seemingly arbitrary and obscure rules, so I may even be ahead of the game on this one. But it never hurts to take extra measures, right? Right.