Javaaaarrghhscript

Geeky post…sorry if you get lost.

I’m still playing with Web Development languages and tools.  A few days in Devon with not much to do is a good time to invest in some self-learning and I’ve been given the O’Reilly JavaScript and DHTML Cookbook for Christmas too, so I’m working through that.

I’m pretty proficient with server-side scripting now, but it had limitatations and performance issues.  I’ve been so impressed by some of the Web 2.0-type sites out there (www.letsfreckle.com, www.twitter.com, www.facebook.com) that I feel I really need to get a handle on client-side scripting too.  That’s where JavaScript and DHTML come in.

But I’m really not liking JavaScript.  See, I was educated with a quite deep knowledge of programming languages.  I’ve studied both imperative (statement-based) and declarative (logic-based) languages.  I’ve studied compiler construction and language structure and analysis.  I understand object-orientation.  I know what’s going on under the hood, and I know the pitfalls of various programming languages styles.

I’ve also got a background in safety-critical software engineering.  Writing programs where you know what must happen and if that doesn’t happen then people’s lives are at risk.  I like to know what my programs are doing.

And with JavaScript, most of the time, I don’t have a clue what’s going on!  The language makes so many guesses on your behalf, allows you to pass objects and functions as data and doesn’t (appear to) contain notation for distinguishing between passing parameters by value and by reference.

To the uninitiated this will mean nothing…let’s take an example.  Lets say we want to write a little computer program called “add-one”.  This program has one input, a number, and one output, which will be the number plus one.

The preferred way to do this is to write what’s called a “function”.  A function is a little program which gives you back a value.  Like this:

function add-one ( x )
begin
  return x + 1
end

Here, x is the input and we “return” x + 1.  Simple.  So we can now do:

a = 1
print a
b = add-one ( a )
print b

I hope you can see (I’m racing ahead) that this will print “1” then “2”.

But you can also write this as what’s called a procedure.  A procedure does some “stuff” but doesnt return a value.  Like this:

procedure add-one ( x )
begin
  x = x + 1
end

So what happens if we do the following with the procedure?:

a = 1
print a
add-one ( a )
print a

“That’s easy!” you may say, “it prints 1 then 2 again”.  But it’s not that easy.  Sometimes the language will take a “copy” of x into the procedure and modify the copy, leaving the original untouched.  This is called “pass-by-value”.  Why would you want to do this?  Well, let’s write a procedure that has someone’s full name as an input and prints their first name:

procedure print-first-name ( name )
begin
  remove surname from name
  print name
end

In this case we only want “name” to change within the procedure or the following would not work:

my-name = "Fred Flintstone"
print-first-name ( my-name ) 
print-surname ( my-name )

Here, print-surname would not work because the print-first-name removed the surname from my-name.

Your head probably aches now.

Anyway, JavaScript does LOTS of this sort of thing where pass-by-vaue and pass-by-reference really make a difference.

Another complication is that there’s two ways to create strings that return different types:

my-name1 = "Fred Flintstone";

and

my-name2 = new string("Fred Flintstone");

But these actualy do different things.  One creates a string value and one creates a string object.  And we find that:

my-name1 == my-name2

is true because the interpreter automatically converts the type but

my-name1 === my-name2

is false because it does type comparison too.

It has a variable called “this”, which refers to different things in different contexts.

And it doesn’t enforce important bits of syntax.  You’re supposed to end statements with a semi-colon, but if you split a statement over a line, then it will add the semi-colon at the line end (if that’s a valid place to end a statement).

These are all very minor examples of how this is a complex, weakly-typed, language the enforces very little checking on the programmer, makes lots of assumptions about what you mean in your program, and doesn’t seem to give you ways to enforce the meaning that you want.

All in all, I can see why so many web applications are so liable to not working.

Perhaps with a proper JavaScript tutorial, rather than just a cookbook, I might get a better grasp of the language and find some strong typing and better structures.

But for the moment it’s looking pretty complicated and chaotic!