'. '

JavaScript

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(OOP Assembly Set)
Line 23: Line 23:
This is a common construct in classical [[OOP|object oriented languages]], not only in Java. It makes it easy to do something programmers do frequently – for example, specializing behavior when subclassing. However '''super''' has its limitations: you cannot call '''super'''.'''super'''.aMethod() – e.g. skip level of inheritance. You cannot call '''super'''.aMethod on some completely different object, etc.
This is a common construct in classical [[OOP|object oriented languages]], not only in Java. It makes it easy to do something programmers do frequently – for example, specializing behavior when subclassing. However '''super''' has its limitations: you cannot call '''super'''.'''super'''.aMethod() – e.g. skip level of inheritance. You cannot call '''super'''.aMethod on some completely different object, etc.
-
JavaScript does not have concept of “super” – however it has something more powerful: there is a “call” function where you can specify the actual method/function to call, on what object (e.g. “this”) and with what arguments. You can use the “call” concept to simulate “super”, but you can also use it in a number of other ways. It is flexible, but low-level. It is something that belongs to assembly language, but not something regular developers should use when coding their business logic.
+
JavaScript does not have concept of '''super''' – however it has something more powerful: there is a ''call'' function where you can specify the actual method/function to call, on what object (e.g. '''this''') and with what arguments. You can use the ''call'' concept to simulate '''super''', but you can also use it in a number of other ways. It is flexible, but low-level. It is something that belongs to assembly language, but not something regular developers should use when coding their business logic.
-
 
+
-
I have to repeat myself: if you keep coding in JavaScript, you end up like everyone who’s using assembler: feeling powerful at first, but constrained in the years to come.
+
 +
I have to repeat myself: if you keep coding in [[JavaScript]], you end up like everyone who’s using assembler: feeling powerful at first, but constrained in the years to come.
== Every Generation Needs Its Own Assembler! ==
== Every Generation Needs Its Own Assembler! ==

Revision as of 18:08, 5 April 2015

JavaScript is was designed as a scripting language. As such it was for a long time considered an outsider among languages. However its presence in browsers and its ability to give HTML pages life makes it more and more attractive. But let's be honest - JavaScript is weird and nobody would use it, if it hadn't had its browser presence advantage. Real projects deserve real languages and as such I am huge supporter of Toni Epple's DukeScript idea.

Contents

Yet Another Assembly Language

For me personally, JavaScript is just another assembly language. An object oriented assembler people were seeking for in 80-ties. JavaScript as of 2015 is a famous target instruction set (just like Z80 or i386). Many languages compile to it. The reason is simple: if you want your program run everywhere, you need it to run in a browser and JavaScript is the language all modern browsers speak. As such we have a way to translate C (via Asm.js) to JavaScript as well Java (via my bck2brwsr VM or TeaVM). I don’t see any reason why people should code in assembler anymore. And certainly I am not going to do so myself – I rather spend a year to create a framework than to write directly in JavaScript.

I know large group of people that are fine with JavaScript, but face it: It’s a “write once and throw away” language. You write your code once and ship it when it works. Later, when you are asked to change something in it, you are afraid to touch it. No refactorings, as no tool can guarantee that your code will behave the same after refactoring (unlike in more restricted languages like Java), no huge changes – touch it only lightly and with care. It is often easier to start from scratch.

I hear complaints of this kind from executives everywhere. Especially if they have one gang of Java programmers and another of JavaScript developers in-house. They tend to see the latter as less reliable geeks always trying something new, but never delivering long lasting product. It may be a clash of generations (as JavaScript guys are usually younger), but I believe the root cause is the assembly nature of JavaScript.

OOP Assembly Set

To illustrate why I believe JavaScript is another assembly language, let’s think about a way to invoke original implementation in an overwritten method. In Java you’d use “super” keyword:

protected void aMethod() {
   // do something before inherited behavior
   super.aMethod(); // invoke original behavior
   // do something after inherited behavior
}

This is a common construct in classical object oriented languages, not only in Java. It makes it easy to do something programmers do frequently – for example, specializing behavior when subclassing. However super has its limitations: you cannot call super.super.aMethod() – e.g. skip level of inheritance. You cannot call super.aMethod on some completely different object, etc.

JavaScript does not have concept of super – however it has something more powerful: there is a call function where you can specify the actual method/function to call, on what object (e.g. this) and with what arguments. You can use the call concept to simulate super, but you can also use it in a number of other ways. It is flexible, but low-level. It is something that belongs to assembly language, but not something regular developers should use when coding their business logic.

I have to repeat myself: if you keep coding in JavaScript, you end up like everyone who’s using assembler: feeling powerful at first, but constrained in the years to come.

Every Generation Needs Its Own Assembler!

The history of mankind is repeating. In circles. Yet, according to Karl Marx it is repeating in spiral - the new generations are about to do the same mistakes as the previous ones, just on new (hopefully) higher level. A bit too optimistic conclusion, but as far as JavaScript goes, probably true.

I learned programming while coding in the Karel language. But it felt not like a real programming language, Karel was a programming language for children. Still, everything I ever learned about programming I owe to Karel. Those who know the two sides essay by Dijkstra can imagine what was my computer to execute my programs. Yes, I was simulating all the computations in hand. How does a computer of young generation looks like? Right, it is a browser. And JavaScript runs naturally in a browser. What kind of impact this can have on like-to-be-programers?

Every Generation Needs to Repeat Previous Mistakes

Tim Boudreau: really get the feeling JavaScript guys are trying to replay the last 20 years of server-side development, but inside a browser window, and feel like they have to make every mistake again for themselves.

Tim Boudreau: 90% of the project's problems come from broken attempts to modularize *inside* a giant single HTML page application, and not being able to actually keep things from interfering with each other. I believe in modularization, but I also think the web comes with a great tool for modularization, and its called web pages.

Me: That is result of missing encapsulation. There is not much of it in JavaScript - only require.js comes to my mind.

Impossible

Using JavaScript is impossible - maybe not impossible in the finite automata sense, but certainly as impossible as getting threading right.

TBD

Personal tools
buy