The Official JavaScript Religious War Thread.
Martin_H
Posts: 4,051
This is the official JavaScript Religious War Thread. If the topic comes up in another thread, please feel free to reply to this post. But me first because I started it.
JavaScript follows a "maximum surprises" design philosophy that rejects years of accumulated programming wisdom, only to serve as the anti-pattern to prove that wisdom correct. Let me enumerate a few of its toxic flaws:
Numbers in JavaScript are "double-precision 64-bit format IEEE 754 values", according to the spec. This has some interesting consequences. There's no such thing as an integer in JavaScript, so you have to be a little careful with your arithmetic if you're used to math in C or Java (i. e. a real programming language).
A central value of programming is to find mistakes as early as possible. JavaScript's lack of type safety means that a number of trivial errors won't be found until runtime, or worse production.
Modern programming patterns (e. g. inheritance, interfaces, encapsulation) are missing, instead it uses a prototype based object system that is brittle, and fits its "maximum surprises" philosophy.
It doesn't have the concept of multiple threads, but uses event handling with embedded lambda functions. This results in daisy chained function definitions that get ugly quickly.
A variable can be undefined, defined and null, or defined and have a value. As if null pointer exceptions weren't bad enough. But for extra joy a knuckle head can define the word "undefined" and now your test against undefined will fail. Surprise!
It's such an unsafe language that companies that are some of its biggest users are looking to improve or replace it. Microsoft with its typescript preprocessor and Google's new scripting language Dart.
I can come up with more, but I hope to convince young professionals that although they have use this language in a browser, please understand that it is completely broken and should be avoided otherwise.
JavaScript follows a "maximum surprises" design philosophy that rejects years of accumulated programming wisdom, only to serve as the anti-pattern to prove that wisdom correct. Let me enumerate a few of its toxic flaws:
Numbers in JavaScript are "double-precision 64-bit format IEEE 754 values", according to the spec. This has some interesting consequences. There's no such thing as an integer in JavaScript, so you have to be a little careful with your arithmetic if you're used to math in C or Java (i. e. a real programming language).
A central value of programming is to find mistakes as early as possible. JavaScript's lack of type safety means that a number of trivial errors won't be found until runtime, or worse production.
Modern programming patterns (e. g. inheritance, interfaces, encapsulation) are missing, instead it uses a prototype based object system that is brittle, and fits its "maximum surprises" philosophy.
It doesn't have the concept of multiple threads, but uses event handling with embedded lambda functions. This results in daisy chained function definitions that get ugly quickly.
A variable can be undefined, defined and null, or defined and have a value. As if null pointer exceptions weren't bad enough. But for extra joy a knuckle head can define the word "undefined" and now your test against undefined will fail. Surprise!
It's such an unsafe language that companies that are some of its biggest users are looking to improve or replace it. Microsoft with its typescript preprocessor and Google's new scripting language Dart.
I can come up with more, but I hope to convince young professionals that although they have use this language in a browser, please understand that it is completely broken and should be avoided otherwise.
Comments
At least with Forth, the short-comings point you toward learning to program in PASM. With JavaScripts, I suspect the short-comings will point you toward seeking extra-terrestrial extra-sensory assistance.
There are is a lot of inflammatory language there and biased value judgements along with some factual inaccuracies, as is fitting of a language war post
About those integers:
Those 64 bits doubles can hold integers up to 53 bits. Not bad. It's not so hard to ensure they are integers at all times.
If you do integer arithmetic in C, Java, Spin etc you have to be a little careful, A + B may well give the correct answer C. Unless there is an overflow of course, which you won't know about until run time or production because the compiler cannot help you. If you are finding type errors in production then your testing is grossly inadequate. If you testing is grossly inadequate the compile time checks of a statically typed language won't save you. You will have plenty of other errors compilers cannot detect. It just promotes a false sense of security.
The lack of threads saves you from a lot of hard to find race conditions that often don't show up till production. The lack of threads saves a lot of resources and overheads of context switching. It may require a programming style one is not used to.
I hope to convince young professionals that although they can use JavaScript:
In the browser.
On the server.
In their embedded apps for mobile devices (See Qt QML)
As a scripting language in their game engines etc.
In their micro-controller applications.
They should be broad minded and aware of many available technologies, selecting the best one for the job at hand.
They should be aware that when skimping on testing the compile time checks of a statically typed language do not help you much. There are many more logical errors you could have made that it cannot check. BUT then if you are testing properly those compile time checks are redundant.
Logically compile time checks are not required.
Did you say "Java".
Now there is a language that has no reason to exist.
Continuing on my war against JavaScript.
A popular JavaScript defense is to claim that the language is misunderstood. For example: http://javascript.crockford.com/javascript.html which is clever misdirection. But they often prove many criticism correct in the process by showing their work arounds to valid criticism.
You do realize how this is bad for any processor that doesn't have a built-in floating point unit? It's like the designer never thought of anything other than an x86.
If this is true then we should have spent the 90's programming in BLISS and FORTH over C and C++. Why did languages with type checking catch on over languages that didn't?
Also threads and cogs are conceptual peers, as are events and interrupts. I like cogs over interrupts as they are more flexible.
According to forum rules, discussing other languages would be off topic, but I suppose that's up to Martin.
My only real problem with Javascript is lack of uniformity. That is needing to code around "I.E." specific issues
There are several ways to define a class. Which one works best? I usually use something like:
function classname () { var this.somevar; this.method1 = function(a,b) {} this.method2 = function(a,b) {} /* blah blah for constructor */ }By the way I have a micro-controller here, smaller than my thumb nail, that includes an FPU. I would not say he was stuck on x86. He just realized that having a multitude of types all different sizes and signedness was confusing and error prone. With that in mind big floats are the best choice. I said "Logically compile time checks are not required." This is self evidently true. The proof goes like this:
1) A type error, for example comparing a signed to an unsigned, is just an other error like any other, putting a minus where a plus should be for example.
2) There are a huge, uncountably huge, number of such errors you can make in a program.
3) Compile time type checking only catches a very small proportion of possible errors.
4) You have to test to find all of the much bigger ocean of logical errors.
5) Such testing would naturally catch all type errors if the compiler did not do the type checking.
6) Ergo, if you do the testing you don't need the compile time checks. God forbid. Clearly the huge volumes of security vulnerabilities that have been showing up for decades now in C/C++ and Java demonstrate that type checking does not help. Clearly everyone was as misled into a false sense of correctness as you:)
Note: Ada is the only language I know that does type checking properly and it was soundly rejected by all those otherwise claiming to be in favour of compile time checks. No, they are not.
A thread of execution is a software concept. A COG is a piece of hardware.
In common parlance now a days a "thread" shares memory space with other threads. A "process" is operating in it's own memory space.
What of a COG executing code and using data with it's registers only? That is isolated like a process. On the other hand if it is executing LMM code or using HUB for data it is more like a thread. No, they are not.
An interrupt handler can potentially divert execution of your code at any point. This can be disastrous, causing race conditions, data corruption, and crashes, if you don't take steps to guard against that. All the perils of threaded code.
There are no interrupts in event based software. Everything runs to completion and the the event queue is inspected to see if there is further work to do. In this way order is maintained. There are no possibilities for data races.
(Yes, yes, there may be interrupts underneath an event based system. Though not necessarily as the XMOS micro-controllers demonstrate) Me too. Given the misunderstandings of common computer science concepts you demonstrate in the above statements perhaps you should revisit the Crockford pages
Let's not be confused. There is the language "JavaScript" as defined my ECMA standards. Then there is the environment that it runs in, the browsers, node.js, QML, Espruino, and so on.
Turns out that Microsoft did an very good job of reverse engineering the JavaScript that Netscape put in Netscape Navigator. They implemented all the bugs and quirks of that original JS. When it came time to get the thing standardized at ECMA the Netscape guys wanted to fix many of the quirks. Those things Martin has mentioned above for example. Microsoft of course bullied the ECMA committee into standardizing JS as is, bugs and all.
In short, the result of all that is that JavaScript, the language, is one of the most uniform languages among implementations from different vendors ever !
It's the browser interface screw ups that cause all that apparent lack of uniformity.
Who me? I would never fire the first shot
I'm surprised you didn't mention variable scope and the affect of not using var.
Not a fan of?
<script> if (typeof(myvar) == 'undefined') { alert('Hello World!') } </script>I learn something, or obtain a reference for later reading on just about every one of these BTW. All good, IMHO.
I baited him in another thread because he mentioned that fetid swamp of a language.
@Heater, not much time for a better response. Threads can be software concepts, but they can be implemented in hardware too. Threads have thread local storage (they keep the thread stack and thread local variables here) and access to a shared memory space. This is not unlike a cog's RAM and the Hub RAM. Intel's hyperthreaded processors can also be thought of as hardware support for threading because a single core implements some of the thread local storage and context switching.
@all JavaScript's overloading the + operator should have been enough to consign it to the programming dustbin. But again it was saved by being the only game in town.
Don't be lured by Heater's call for lack of type safety. It's the demon rum of programming!
@Mike G, I got paid for writing some of that JavaScript. But I held my nose the whole time.
Imagine, all those JavaScript engines were written in C++.
What a glorious paradox.
Really I don't see the value of JavaScript without DOM. Maybe you can offer some useful examples where it excels over the alternatives.
Cheers.
...unless one does their testing apparently.
Was having a discussion about SPIN along those same lines. Came down to testing and doing that properly comes down to understanding the various cases and what is happening... which includes the type check by inference.
Additionally, it can actually account for type abuses that will be just fine, tested to be so.
A childhood friend works for a rather prominent software company. They use a LOT of Javascript, and he's head of testing. They also deploy on a ton of platforms, all of which requires testing too. He's in the job he's in, because he has asserted for basically ever that testing is what matters most. Authoring tests right alonside code is the optimal case in his view.
Their product, incidentally is something people use to better optimize server side web applications and their interactions on various client platforms. Let's just say that product rarely fails. It can't given it's use case. Well, it can, but very bad things happen and people cry.
Some additional advocacy on this would be enlightening. You've not yet met your burden Martin.
I humbly request we don't kill this one off. So long as there are no serious bitings, I expect this discussion to have some value. Thanks.
That's a common claim, but weak typing expands the number of test cases you need to write. I'd rather know up front that I blew it than have to write a test to find out. For the record, I tolerated Spin as the only game in town, but now that Propgcc is here I probably won't use it for new projects.
At the time the big thing in the browser was supposed to be Java, hence the Sun/Netscape hook up to make that happen. Turns out Java is hopeless. Also I seem to remember MS had "Active X controls" or whatever. And lets not forget FLASH. JavaScript won out over much competition. By all means use a "type safe" language. But don't forget that testing is the only way to know if your code works as desired.
"Type safe" is mostly that is a misnomer anyway. In most languages they may be happy that all my variables are floats, say. But they will quite happily let me add kilograms to hertz. How dumb is that?
If you want to be "type safe" be aware of what that means and then use Ada.
PS the other things you mentioned are plug in technologies. JavaScript is integrated with the browser. Sun and MS fighting over Java is a big reason applet failed. Flash was actually pretty successful. ActiveX was an insane idea.
Most of the JS I have ever written drives animated 2D and 3D data presentations in using webgl libraries. I try and keep as far away from the DOM as possible.
JS is used to good effect on the server with node.js. No DOM there.
JS is used to create user interfaces using Qt for mobile applications, see Qt Quick.
JS is used to program micro-controllers. See Espruino and Tessel.
JS is used in game engines.
It's pretty much everywhere !
Let's take an example, here is some code that needs testing (pseudo code): How many tests do we need to be sure this works as planned ?
Let's try and map out some example tests:
Clearly if that code is to be known to behave as you would like it has to pass those tests, and more. Also clearly if it passes those tests it has also done the type checking for you. Comparing signed and unsigned would fail for example.
As I said given the number of security vulnerabilities we have see all around in recent decades it seems that level of testing is needed anyway.
Also, "type safe" languages are not. Remember the "kilos + hertz" thing. Except possibly Ada. This is way off topic. What you are saying is that the Windows evented API is broken. No surprise there
All events from timers, or I/O or whatever are placed on an event queue. The event queue is only checked when the event loop has completed whatever code it had to run due to the previous event.
Which is a scary thought. Fortunately I expect people will get burned by it and realize their mistake.
Really?
The tests are to insure it works. What if the language itself has some trouble, or gets an update? Failure to write inclusive tests leave those regressions wide open. Happens every day.
Perhaps being a browser plugin is a pain and a hindrance to acceptance. Well, that's tough for them. I'm here to debate the language and dynamic vs static languages.
Chuckle, used to think thoughts like that about BASIC when it was all the rage on 8 bit machines. BASIC went on to be huge anyway.
In many industries you would never get the time in your schedule to verify the compiler. You barely get the time to do decent edge case unit tests.
My setInterval bug was in 2009 and we had to support IE6. So broken was a distinct possibility.
You never update your language or runtime in the middle of a project. Only the beginning so that all the regression testing and ad hoc testing isn't invalidated.
It's also why there are all those security vulnerabilities and millions of people complaining about buggy software every day.
It's also why people turn to dynamic languages like JS, PHP, Python, etc etc etc. So that they can get stuff out the door in time with out fighting with the compiler all day.
(Errr, that is not one of my arguments for JS by the way)