Follow me on Twitter

#functions

I’m enjoying the work that Kyle Simpson has done on understanding how the compiler (yes, he says JavaScript is a compiled language not an interpreted one) declares and hoists functions and values. A cool thing about it is that functions do not hoist in a stacked way, they hoist in a mutual way and he has an awesome example to prove it. “As always this is more for my sanity than yours”.

I have a huge goal of understanding JavaScript better. Digging deep into it is really helping my confidence and understanding of larger concepts. “Every thing below is my interpretation and you should do your own research”.

First there is a difference between function declarations (statements) and function expressions.

function b(){} //function DECLARATION(statement)

var a = function(){} //the left is a variable DECLARATION, the right is a function EXPRESSION

The code below is a great example the start with. Hoisting is really something we made up to explain a complex feature that the Engine executes. But, at the running of this code the engine will run all the way through the code identifying all DECLARATIONS and assign them positions in memory then, during execution the engine will run through the code line by line assigning values.

So the above code basically (how we see it) runs like below:

“Var a” and “var b” are both declared and set with a value of undefined (yes it’s a value). Then the code will run line by line. Above you can see that “a” is set to “b” while “b = undefined”, then “b” is set to “2”, “a” when logged is still “undefined”.

Now, function declarations (some call them statements) are hoisted ABOVE variables when declared and function expressions are not hoisted. Simpson talks about the LEFT of EQUALS is Declared at compile and the RIGHT is Assigned at execution.

Above code basically hoists (how we see it) like the code below.

From what we know about how variables hoist we would think that functions would hoist in the same manner. A function declaration (statement) hoisted below the above function declaration (statement) should not be able to be called.

Simpson argues that if this language was a truly interpreted language that read line for line then the above would not work. Functions declarations (statements) are actually hoisted at a “MUTUAL LEVEL”.

He proves this with a Computer Science concept called Mutual Recursion, where multiple functions are calling each other. PS. sorry if you read the link and now your brain hurts!

Here is his example (the code works fine):

The answer should be 39. I worked the problem out free hand below.

a() is checking for completion (foo > 20) and returns a call to b() while adding +2 to foo.

b() is returning a call to c() and adding + 1 to a stack that will grow due to closure

c() is calling a() and passing foo * 2

after 3 rounds a checks that foo(36) > 20 and returns foo which in turn will grab the b stack (3) “that b stack is sitting in memory I think due to closure, I need to do more research”

a(36) + b(3) = 39

*Side note: this might also explain why primitive variables passing to other variables are copies. eg “a = 5;”, “b = a”, “a = 1”, “log b & log a”, “a=1”, “b = 5”. Where as “function a () {return ‘car’}”, “var b = a;”– these are pointing at the same function, so if function a is changed then function b is changed. I need to do more digging.

Kyle talks about this compiler in much more detail, talking about how the compiler looks at Left Hand Statements vs Right Hand Statements among other concepts. It’s really good stuff and he has a course on Plural Sight which goes into a lot of depth.

Awesome time at my first NodeJS Atlanta Meetup. I was a much smaller group than they usually have so it allowed a lot of young developers to ask questions. Having only ran up simple NodeJS servers so far it was a great experience to hear from some who sit on the backend all the time. Here are a couple takeaways:

“As always this is for my sanity, not yours”

ARE PROMISES CURRIED FUNCTIONS?

I dig Promises, they make things simple to understand. If something resolves .then() do this next thing. New work on Promises and ES6 HERE (not sure I understand it all).

Function currying is creating a function that takes # variables and creating a copy of that function that takes a different # of variables:

MY TAKE IS YES?…….MAYBE?

Yes, if we look at both currying and promises as guaranteeing something to be passed to the next function from a function that has finished executing (Closure).

Fix a problem for me. Show me you can fix a problem I have in the interview. When you get in the door keep doing that for EVERYONE! The Business Dev guy had a $2 Million presentation on the line and his computer went down. Rather than shrug it off, I set him up on my computer. It took me off line for 3 hours, but I fixed a problem, helped him and I in the long run.

Also, there is a huge separation in opinions on the value of GitHUB with younger developers and hiring managers focusing on it and older developers not feeling that it has much value.

LEARNING FROM THE VETS

I enjoyed connecting afterwards with long time developers. Couple things on the list to check out: