The "enterprise-grade" designation
If after all this time Plato still fully deserves to be mentioned with awe today, it is also for his masterpiece dialogue Cratylus, on the nature of language and, of course, the corruption of language.
Another, more contemporary expert in the field, was George Orwell. He attained stardom in the world of literature with his novel 1984, in which introduces the alarming terms The Ministry of Truth, Big Brother, Doublespeak, and Thoughtcrime. To me, Orwell's masterpiece is his essay Politics and the English Language, where he elaborates on the definition of the term meaningless word.
Orwell writes: ...Many political words are similarly abused. The word Fascism has now no meaning except in so far as it signifies ‘something not desirable’. The words democracy, socialism, freedom, patriotic, realistic, justice have each of them several different meanings which cannot be reconciled with one another. In the case of a word like democracy, not only is there no agreed definition, but the attempt to make one is resisted from all sides. It is almost universally felt that when we call a country democratic we are praising it: [...]. Words of this kind are often used in a consciously dishonest way.
Meaningless words are excellent tools for praising and justifying a favoured point of view, blackmouthing alternatives, while making it difficult to impossible to argue the contrary of statements that are in essence meaningless.
Indeed, how could anybody argue that a statement is not true, if the statement simply has no meaning?
In the IT world, the term enterprise-grade is used to praise programming languages such as Java and C#, while resisting every possible attempt to define the term. Javascript would be not enterprise grade and therefore a programming language that is not desirable.
Commercial and promotional literature in the IT world is as rife with meaningless words as the news on television.
By counting the number of meaningless words per 100 words in a message, even a simple computer program can completely objectively and automatically flag such message as mostly connotative: The message has hardly any other purpose than praising or blackmouthing, and is the work of someone we can suspect to be a professional liar.
I am indeed quite convinced that the propensity to lie and the likelihood that a statement contains lies, can be calculated mechanically from simply observing a dangerous level of meaningless words. The vocabulary gives away the liar.
Let's move on to the subject of Javascript versus the so-called enterprise-grade languages Java and C#. Let's debunk the empty and deceptive marketing statements that have been touting, for so long, the elusive benefits of using Java or C#.
Definition of object orientation
A simple function call expression, such as fn(x1,x2,x3,...), invokes a designated function fn, which accepts a particular number of parameters.
An expression is object-oriented, when its corresponding representation as a function call expression, requires looking up the actual function to call, using its first function argument:
(find_function(f, a))(a,x1,x2,x3,...)
Using syntactic sugar -- the programming language permitting -- we usually simplify its representation to:
a->f(x1,x2,x3,...)
The function to call, itself, is the result of a function call.
In other words, the system must first calculate which function to call, before it can call it. It is this polymorphic nature of the object-oriented function call, that is, the method call, that gives object-oriented software its cherished versatility.
Traditional object-oriented languages
Without inheritance, the find_function() function can be implemented in a relatively simple way:
(a->class->prototype->f)(a,x1,x2,x3,...)
With inheritance, the function f could, however, be defined in a parent class. Therefore, finding which function to call usually requires looking in the parent classes too, until the function can be found:
a->class->prototype->f
a->class->parent->prototype->f
a->class->parent->parent->prototype->f
...
Object->prototype->f
The last possible class to search, is the root class for all objects, here simply called Object. As you can see, just searching for which function to call, is potentially a costly operation, in terms of performance.
Addressing this performance issue, is one of the main reasons why object-oriented languages such as Java and C# introduce static typing. It allows the compiler to use type information to reduce the effort in searching for the right method to call.
Note: You can often read that static typing would also useful, because it allows the compiler to validate data types at compile time; while in the case of dynamic typing, validation is delayed until runtime. Such argument therefore conjectures that the disadvantage of increased complexity resulting from static typing, would be offset by the benefit of early validation. This is highly debatable. In my impression, static typing increases complexity dramatically, while there is no evidence that early validation contributes noticeably to the correctness of the source code. Furthermore, without introducing the complex language construct of templates, static typing does nothing to validate the content of generic container data structures. Above a relatively low treshold of complexity, static typing stops trapping issues at compile-time.
Prototype-based languages
During the research project for the Self programming language, the researchers experimented with the following idea: Why not attach the prototype directly to the object, instead of defining classes to attach the prototype to?
They simplified the general object-oriented method call expression:
(find_function(f, a))(a,x1,x2,x3,...)
to:
(a->prototype->f)(a,x1,x2,x3,...)
As you can see, there are potentially advantages in doing this:
- It cuts out the potentially costly search to find the function to call, through a class hierarchy
- It increases flexibility, because each object could potentially have its own different prototype
However, it also increases the size of the object, because each object now has its own copy of its prototype.
A programming language, implemented in this way, would inherently be substantially faster, if it were not that the object prototype has to be stored in a flexible data structure (such as a hashtable), because methods can be added dynamically to the object prototype. An inflexible class prototype, however, can be stored in a fixed-size table (such as a fixed-size array).
As a result, early javascript implementations were relatively slow and memory hungry.
The Google v8 javascript implementation addresses these issues, by introducing several optimizations.
Since typical object prototypes tend to be stable, it makes sense to store object prototypes in fixed-size tables anyway. If they happen to change anyway, the fixed-size table is re-created. This may indeed look like a costly operation, but in the typical usage pattern of objects, it happens so infrequently, that this performance penalty can be ignored.
Just like in traditional object-oriented languages, v8 makes the objects share the same prototype. V8 only creates a new copy for the prototype, if the prototype has changed. This is a judiciously crafted copy on write strategy.
Javascript versus Java and C# in terms of performance, flexibility, and complexity
Prototype-based languages are more flexible than traditional object-oriented languages. This flexibility does pay off. For example, the ability to replace method implementations at runtime, allows for duck punching, that is, patching source code without actually changing the source files.
Static typing is labour-intensive, inconvenient, and vastly complicates the source code with workarounds such as templates, to maintain performance while allowing for flexible data types. Prototype-based languages do not need to introduce static typing for performance reasons. It is because of static typing that Java and C# have astonishingly complicated grammars, compared to Javascript.
As v8 demonstrates, when their implementation is sufficiently optimized, prototype-based languages such as Javascript, are even inherently faster than traditional object-oriented languages such as Java or C#.
Conclusion
When implemented properly, prototype-based languages such as Javascript, are inherently much simpler, potentially faster, and obviously more flexible than the so-called "enterprise-grade" languages, Java and C#.
The C language will inevitably remain the low-level, native system language of choice. Java, and C# have never been able to compete with C in that field. C will always remain faster.
If they have ever been able to compete with scripting languages for building high-level applications, in terms of performance, this was only because nobody made the effort to create a seriously optimized scripting engine until recently.
There are good theoretical reasons to believe that the Javascript implementation of an algorithm that requires an important dose of polymorphic flexibility, will be substantially faster, than its Java and C# counterparts. At the same time, the C implementation of deeply nested innermost loops, will always be substantially faster, than its C++, Java, and C# counterparts. Consequently, the combination of correctly chosen doses of Javascript-cum-C will always do better than Java and C#, on every possible benchmark of performance, flexibility, and code simplicity.
Now that these so-called "enterprise-grade" languages -- besides being already more complex, more unwieldy, and more inflexible -- even start losing the performance battle to unaided Javascript (no help of C) there is absolutely no justification for using them for anything any longer. They have become evolutionary dead ends, and Ousterhout wll have been proven right.
|
