If You Don't Get It, Go And Get It!

Oh well, a rant against another one ... how lovely is this? Just trying to make your week end, right?
I am talking about this misleading post with indeed 29530+ views and just 1 Favorited entry (right now) that must be the post author itself since I can't even check and click that red link ... anyway ...

At the very beginning I thought that was a sarcastic post .. like, the opposite of reality, then I have realized it wasn't ... or was it?

V8 is not server-class ?

Define "server class programming language" first ... 'cause I have tried to search it in Google (with quotes) and result was like a single entry that indeed pointed to some Java stuff ...
This argument is kinda boring in 2012, specially against a general purpose programming language as JS is, you don't say?

I mean, doooooode, should I remind you the Java Applet joke early in the Web era? So it was fine for a server-class programming language to do client side stuff? Or it's just a matter of core functionalities, where a project that never even landed in its 1.0 status keeps growing like hell and already showed its high performances muscles against all other modern scripting oriented languages such PHP (without HipHop), Ruby or Python, and others?

Maybe I should simply mention that via C++ you can write your own modules ... just in case ...

Callback spaghetti is bad ?

Let me guess your thoughts, wizard of multiple threads developer ... how you handle asynchronous stuff and how many headaches this caused? I bet you are big fun of races and non-trustable lines of code, isn't it?
Well, with node you'll never have this problem within the language itself, but of course you can write your own module able to use all possible cores and cause yourself headaches about emitting events with consistent and ordered, if necessary, results. You know strongly typed languages so deal with them if you want to improve modules performances.

its nigh-on-impossible to follow the code 6 months later

Oh ... really? There you are server framework pattern developer, you don't understand your own code if the language is JavaScript ... let's blame the chosen technology that caused your frustration: achievement unlocked!

Non-blocking != fast != scalable

As well as
blocking != fast != scalable
but I see you have valid points here, such

• scalability has very little to do with raw speed, of course it has nothing to do with raw speed if architecture is over-bloated
• Just because you're fast does not mean you're scalable ... thanks captain obvious, so how come you underline scala performances later on?
• Node.js isn't even that fast. You can do much better with Scala and its a much nicer language, to boot ... my brain simply tried to divide by zero here ... your argument is that node is not that fast 'cause scala is faster but node performances should not matter?

Performances

The only reliable tests I know about different programing languages is The Computer Language Benchmarks Game.
Now, the only test that makes a concrete difference there, able to screw up final score in a meaningful way, is pidigits, a test that penalizes JavaScript with the inclusion of /home/dunham/shootout/bench/Include/javascript/biginteger.js that gosh knows how badly big integers could perform once simulated in JavaScript.
What you should care about the whole test page, is that not a single test has more code than scala equivalent, preserving in any case performances with basically irrelevant performances gap in real world scenarios.
This is the beauty of V8, the first engine that pushed JS so freaking far away known performances and before it was cool!
I would rather respect it, rather than blame it ... but that just me I guess ...

JavaScript doesn't even have namespaces ?

After you talk about modularity? Do you know that in node.js everything is basicallyy a module? Do you know that any namespace starts from a root, which is called global object in Javascript world, where the community nowadays is freaking aware of namespaces conflicts?
Do you know that every time you define your own object in Javascript you basically create a namespace so that JS had namespace since the very beginning of his concrete history?
it's clear to me you don't ... so please, stop talking about stuff you don't know!
JavaScript namespaces have been there since ever and the best part is that JavaScript supports multiple inheritance through prototypal nature where you don't even need to write kilometrics namespaces to obtain a single bloody "class" out of it.
it's true that in 2000 JavaScript was abused, it's absolutely a lie that nowadays any sort of well known library isn't aware of namespace possibility.
I would add modularity that resolves namespaces automatically, and in an ordered way as Java guys like in folders structure, through any sort of loader that has been developed from a developer as skilled as you are.

people who are really crazy about Node.js are people who only knew JavaScript to begin with

for a project entirely based on C++? Sure, node.js guys are all freaking idiots developers that do not deserve anything in the server side ... isn't it?
I am Zend Certified Engineer and an AS2 (ECMAScript 4th + C#) Certified Developer with some C, C++, Python, and Java background experience that sticked with JavaScript the day ActionScript 3 became a Java like programming language ... and guess what? I am happily writing JavaScript on daily basis and I am sick, programming since year 2000, to hear developers from one language complaining about other programming languages blaming developers that are using them as if they don't know what are doing.

Respect JavaScript

... and stop thinking as if it's a toy language you, in first place, is not able to get. I have no hacking idea about scala and I am blogging since ever without complaining a single time about Scala developers.
You think Scala is what you need? You think scala is what you know? Go Scala, for gosh sake, but don't ever even try to blame another community if you didn't spend at least 2 years behind that programming language, and with a decent programming background, specially if you can't even get your own code after 6 months.
Let's stop this, cause programming today is way too far from perfect, and rather than picking best things out of every language, we keep blaming others and acting like 5 years old kids.
Enough!

Excellent About node.js

Performances are good enough, and code and skills reusability, something anyone with an IT related BSC learned, is absolutely awesome, fresh, new, and productive, without even considering potentials for companies budget.
It's true in JS community itself that the fragmentation of engines never made things easy, the reason a cross platform JS developer should be valued as much or more than a JVM one rather than usually less, due background knowledge per each environment, imo, but it's true as well that node.js makes things eventually easy for new comers in client/server programming world too.
As a Zend engineer, I have complained many times about PHP as programming language due intrinsic non-sense all over, and as JavaScript developer I keep complaining about lack of proper knowledge of the language, still rarely studied properly in Universities, basically the most important language ever in the Web, client and server, field.
Being easy to learn, same success PHP had years ago, many developers from any sort of language are first of all welcome, secondly have an easy way to do things via patterns that, once learned, may not look so smart from other languages point of view, but take care already of many common bottlenecks or problems the web has seen so far.
As summary, Node.js is a great technology that eventually made it where Rhino, Cocoon, and other JS server side related projects, failed. Node.js is easy, fast enough, natural, and junior to senior prone when it comes to server side development.
Scalablity, once again, is not a programming language feature, is a developer mind-set plus skills related matter so think about it any time you decide to blame a technology you don't really understand.

The Missing Tool In Scripting World

Few days ago I was having beers with @aadsm and @sleistner and we were talking about languages and, of course, JavaScript too.
That night I have realized there is a missing process, or better tool, that could open new doors for JavaScript world.

The Runtime Nightmare

The main difference between scripting languages and statically typed one is the inability to pre optimize or pre compile the code before it's actually executed.
Engineers from different companies are trying on daily basis to perform this optimization at runtime, or better Just In Time, but believe me that's not easy task, specially with such highly dynamic language as JavaScript is.
Even worst task is the tracing option: at runtime each reference is tracked and if its type does not change during its lifecycle, the code could be compiled as native one.
The moment a type, an object structure, or a property changes, the tracer has to compile twice or split the optimizations up to N exponential changed performed in a single loop so that this tracer has to be smart enough to understand when it's actually worth it to perform such optimization, or when it's time to drop everything and optimize only sub tasks via JIT.

Static Pros And Cons

As I have said, statically typed languages can perform all these optimizations upfront and create, as example, LLVM byte code which is highly portable and extremely fast. As example, both C and C++ can be compiled into LLVM.
There is also a disadvantage in this process ... if some unexpected input occurs runtime, the whole logic could crash, be compromised, or exit unexpectedly.
Latter part is what will rarely happen in scripting world, but it can be also a weak point for application stability and reliability since things may keep going but who knows what kind of disaster an unexpected input could cause.

What If ...

Try to imagine we have created unit tests for a whole application or, why not, just for a portion of it (module).
Try to imagine these tests cover 100% of code, a really hard achievement on web due feature detections and different browsers behaviors, but absolutely easy task in node.js, Rhino, CouchDB, or any JS code that runs in a well known environment.
The differential Mocking approach to solve the web situation requires time and effort but also what JS community is rarely doing, as example, is to share mocks of same native objects in both JS and DOM world. This should change, imo, because I have no idea how many different mocks of XMLHttpRequest or document we have out there and still there is no standard way to define a mock and listen to mocked methods or properties changes in a cross platform way.
Let's keep trying imagine now ... imagine that our tests cover all possible input accepted in each part of the module.
Try to imagine that our tests cover exactly how the application should behave, accordingly with all possible input we want to accept.
It's insane to use typeof or instance of operator per each argument of each function .... this will kill performances, what is not impossible is to do it in a way that, once in production, these checks are dropped.
Since with non tested input we can have unexpected behaviors, I would say that our application should fail or exit the moment something untested occurs .... don't you agree?
How many less buggy web apps we would have out there ? How much more stable and trustable could we be ?
The process I am describing does not exist even in statically typed languages since in that case developers trust unconditionally the compiler, avoiding runtime misbehavior tests ... isn't it ?

The Point Is ...

We wrote our code, we created 100% of code coverage and we created 100% of expected inputs coverage. At this point the only thing we are missing to compile JavaScript into LLVM is a tool that will trace, and trace only, the test while it's executed and will be able to analyze all cases, all types, all meant behaviors, all loops, and all function calls, so that everything could be statically compiled and in separate modules ... how great would this be if possible today?

Just try to imagine ...

Technical Reviews: Bestsellers!

Just a quick one about two technical reviews out of two I have recently done for @stoyanstefanov and @cjno for these completely different books: JavaScript Patterns and Test-Driven JavaScript Development.

Right now these are both Top 10 Bestsellers and trust me: other JavaScript Jedis have been involved, you won't regret these lectures! ;-)

Io programming language List for JavaScript

Io is a small, prototype-based programming language. The ideas in Io are mostly inspired by Smalltalk (all values are objects, all messages are dynamic), Self (prototype-based), NewtonScript (differential inheritance), Act1 (actors and futures for concurrency), LISP (code is a runtime inspectable/modifiable tree) and Lua (small, embeddable).

This programming language is really interesting, starting from syntax, throw the entire guide.

One of its primitive type is called List, and this is a summary of this type:

A List is an array of references and supports all the standard array manipulation and enumeration methods.

It seems that List is all we need when we think about an Array of elements ... so why couldn't we have something similar in JavaScript?

// Io programming language List example
// followed by my JavaScript List implementation
a := List clone
a = List.clone()

a := list(33, "a")
a = list(33, "a")

a append("b")
a.append("b")
==> list(33, "a", "b")

a size
a.size
==> 3

a at(1)
a.at(1)
==> "a"

a atPut(2, "foo")
a.atPut(2, "foo")
==> list(33, "a", "foo", "b")

a atPut(6, "Fred")
a.atPut(6, "Fred")
==> Exception: index out of bounds

a remove("foo")
a.remove("foo")
==> list(33, "a", "b")

a atPut(2, "foo")
a.atPut(2, "foo")
==> list(33, "a", "foo", "56")

a := list(65, 21, 122)
a = list(65, 21, 122);

a foreach(i, v, write(i, ":", v, ", "))
a.foreach(function(i, v){alert(i + ":" + v + ", ")})
==> 0:65, 1:21, 2:122,

a foreach(v, v println)
a.foreach(function(v){document.writeln(v)})
==> 65
21
122

numbers := list(1, 2, 3, 4, 5, 6)
numbers = list(1, 2, 3, 4, 5, 6)

numbers select(x, x isOdd)
numbers.select(function isOdd(x){return !!(x%2)})
==> list(1, 3, 5)

numbers select(i, x, x isOdd)
numbers.select(function isOdd(i, x){return !!(x%2)})
==> list(1, 3, 5)

numbers map(x, x*2)
numbers.map(function(x){return x*2})
==> list(2, 4, 6, 8, 10, 12)

numbers map(i, x, x+i)
numbers.map(function(i, x){return x+i})
==> list(1, 3, 5, 7, 9, 11)

The map and select methods return new lists. To do the same operations in-place, you can use selectInPlace() and mapInPlace() methods.

and my implementation has mapInPlace and selectInPlace as well :)

Am I forgetting something? ... of course, the source!

P.S. because of nature of List, you can do stuff like this one:

list(1,2,3).append(4).remove(2).size;
// 3

an so on ;)