Get what a number is in javascript

Why JavaScript is unusable ...

Despite all Google skepticism, I am amazed by Google's idea of ​​establishing an alternative to JavaScript.

For years I have been looking at the fact that people consider a web browser to be an application platform and use it to implement increasingly complex applications - in JavaScript, of course.

The browser is not a good application platform, nor is JavaScript a programming language suitable for complex programming.

  • A browser is an incredibly bloated »runtime« for an application. In addition, it has (although they become more and more invisible over time, and this also makes the browser more difficult to use) controls that were designed for the actual function of the browser before it became the "runtime" for a few small programs that it in Ten times better form (and with less memory footprint and better performance) than desktop applications - these cheerful buttons for scrolling forward, scrolling back and calling up the set start page, for example, which are pointless in such an application. I don't even want to talk about the security of web browsers.
  • JavaScript is an incredibly poorly designed programming language. It contains syntactic filths that outnumber the chaos of the C shell in their illogic. It is easy to make mistakes that are difficult to detect; it is difficult and time-consuming to program even relatively simple things; it's a hell of a headache when JavaScript has to be programmed with normal, everyday complexity. It could be punished as a punishment for someone who killed their father and mother. If you don't believe it, download any JavaScript library for AJAX and analyze the code. You could also use that as a punishment for someone ... oh, I'll repeat myself.

Anyone who knows me knows that I avoid JavaScript whenever possible. Sometimes it doesn't work, however, and then I try to avoid any unnecessary complexity. Others see it differently and find it crazy coolwhen things are implemented in an HTML page displayed in the browser with several thousand lines of code that would be a trifle in a conventional programming language. If such code goes "into production", however, then you have to think about how the functionality can be realized without JavaScript, because security-conscious users (i.e. people who are not on Facebook and who know the difference between the words "interactive" and "interesting." «Know), for damn good reasons, not every website that has been visited allows code to be executed in the browser. The result is that extensive server-side programming is then required to implement the basic functions a second time. The programming is double, the tests are double, the possible errors are double ... for a bit of showmanship. A desktop application with the same range of functions, even one with a complex GUI with the aid of a suitable toolkit, could be created in a fraction of the time.

The syntactic chaos of JavaScript also requires learning that goes beyond any other programming language. Not only is JavaScript hard to write, it's hard to read too. The following examples of the immaturity and perfidious malevolence of JavaScript are far from complete, they are more of a cabinet of curiosities that I have collected in the course of my existence.

Those who do not program will hardly be able to enjoy it. 😉

The ambige + operator and the dynamic type concept

quux = ‘4‘ + 2;

This statement assigns the string.

quox = ‘4‘ - 2;

This instruction assigns the integer (result of subtracting 2 from the number 4).

Unfortunately, it was not enough for a separate string concatenation operator when designing JavaScript, and it can behave very strangely. It is not always clear that it is a string, it can be a variable. Which of course has no static type. Which can be initialized from an instance, for example. Real code is much more difficult to understand than these little examples that just want to get to the point. If you are confronted with code that sometimes runs correctly and sometimes behaves incorrectly in completely incomprehensible ways, you have a very unpleasant session ahead of you.

Leading zeros

Anyone who has understood what kind of problems strings with numerical content can cause if one counts on them, is of course grateful for the function, with which one can easily convert strings into integers. Unfortunately, this can also lead to errors that are very difficult to find in some situations:

var quux = parseInt (‘06 ‘);

Here the value is assigned to the variable.

var quox = parseInt (‘09 ‘);

And here the value (zero) is assigned to the variable.

Take a deep breath and then pick up the hammer! A sequence of digits that begins with a is interpreted as an octal number by default. (C-programmers already guessed it.) And breaks off the conversion at the first illegal digit. For obvious reasons of nastiness, of course, completely without a way to somehow recognize the error in the program, this complicated fiddly stuff with exceptions is not for JavaScript programmers. is not a valid octal digit, logically comes out as the result of the conversion. Anyone who gets data with leading zeros from some legacy and has to deal with it (or even just wants to get rid of the annoying zeros) must therefore specify base 10 as the second parameter.

That he the can easily forget ... oh, I don't need to say that.

The instruction should be returned

function quix () {return 4 + 2; }

The function returns the value.

function quax () {return 4 + 2; }

Unlike in any other language with C-like syntax, this is a syntactic error. Or, in this case, a syntactically permitted construct that does not behave as expected.

The designers of the language said to themselves that the last statement in a function is almost always (which doesn't have to be right). Therefore, on a line with an -statement before the line break, a implicit semicolon inserted that concludes the statement. So, if you are happy about such illogical inconsistencies, you could omit the semicolon after the final in a function. A statement cannot be continued on the next line. However, this does not apply if you want to return a value that is enclosed in curly brackets, for example an object with a list of properties. To do this, however, the opening bracket must be on the same line as the statement. So the following construction behaves as expected:

function quox () {return {one: 1, two: 2, three: 3}; }

The following construction, however, returns - and this mistake is extremely easy for C programmers to make:

function quux () {return {one: 1, two: 2, three: 3}; }

Unfortunately, I can't answer the question of who shit in the brains of the language designers either. You probably said to yourself that unformatted languages ​​are so ubiquitous that you can even talk to people with a almost format-free language that only expects a certain line format for a statement. As an exception that is easy to remember, if you know. Just because they were a little crazy. If you have problems understanding something like this, you can take comfort in the fact that the programmers of web browsers had similar problems. In many older browsers, the following construction took place erroneously Behave "as expected":

function quatsch () {return / * start of comment end of comment * / 4 + 2; }

Incomparably stupid comparisons

Not in the mood for a lot of text, just a few comparisons with the result:

6 == 6; / * true, as expected * / 6 == [6]; / * true, WTF? * / 6 == [[6]]; / * true, WTHF? * / ‘‘ == ‘0‘; / * false, as expected * / 0 == ‘‘; / * true, huh? * / false == null; / * false, as expected * / false == undefined; / * false, that's right * / false == ‘0‘; / * true, oh executioner! * /

It is clear that these comparisons also "work" when variables are compared with each other rather than literal constants. And that dynamic typing does not make the processes more transparent in such a case, too.

By the way, this also comes out when you compare a string of any length, which consists only of whitespace characters, with the integer. If you have a little more experience with JavaScript, of course, write three equal signs to compare - a healthy example of sick syntax that has now broadcast to several other programming languages.

Did I actually mention that just a variable name for a global variable is, to which one could theoretically assign another value - let's say - ... 😈

If something like this is ever necessary, or even useful in a particular situation, you should rewrite your project. Right away. And don't even think long about how to undo the assignment, i.e. how to reassign the value to the variable with certainty. The return value of a function with no return - should actually work, but I guarantee nothing. I've never used it before. I will never need it. And if I do need it, I have to look around immediately to see if I'm already in hell. Then maybe I can shorten my eternal punishment by doubling my suffering, because it is also a global variable.

(Hopefully do you have at least that removed from the ECMAScript specification! And if not, let the hangman get them!)

Numbers are objects if the parser recognizes them as numbers

Granted, this is an exotic proposition that you don't normally come across. But everything is not always normal, and then you come across this little thing.

quux = "Hello" .toUpper ();

As expected, the variable is set to. This is a method for string instances. But…

quox1 = 42.toString ();

... is a syntactic error and in no way assigns the string. In order for the parser to parse the number correctly in such a construction, it must contain a decimal point, i.e. it must be written something like this (zeros can be left out):

quox2 = 42..toString (); / * Ouch, my head! * /

If you have a more detailed style - that should be good for the legibility of the tormenting texts - will of course write it like this:

quox3 = 42.0.toString (); / * Ouch, my eyes! * /

😥

Unexpected non-local local variables

var quux = 42; function quax () {quux = 23; / * Maybe a few hundred lines of code in between * / if (some condition) {/ * A local variable in this block should be ... * / var quux; / * Maybe some more code here * /}} quax ();

Every programmer who knows any other programming language (i.e. not something like COBOL) expects that the global variable was set to after calling the function. But it wasn't. In JavaScript, the local variables do not have the block as a scope as in other programming languages, but rather the function - and the later definition of a local variable in a function therefore prevents the presumably desired overwriting of the global variable of the same name. I looked for a bug like this in other people's code for a damn long time, and since then my relationship with JavaScript has deteriorated for a long time.

I don't need to mention that such an error occurs preferentially in somewhat longer functions with a lot of code. It would be wise to adhere to a naming convention for global variables ... and you have lost if you "inherited" code that did not.

and the

This can within an object have different values ​​depending on the context in which the object is used.

<input type="button" value="Aua!" id="auaknopf" /> <script> var einObjekt = function() { this.anzeigeText = "Tut doch nicht weh!"; this.clickHandler = function() { alert(this.anzeigeText); } }(); document.getElementById("auaknopf").onclick = einObjekt.clickHandler; </script>

Apart from the crazy syntax for object orientation in JavaScript, it still looks straightforward enough. In real applications, of course, a lot of common functionality would be encapsulated in such an object for event handling and not just an instance variable and a method.

Unfortunately, in this example, the behavior of the method depends on how it is called. After clicking on the "Ouch" button, a message box appears with the text "undefined", but if the method is called directly, it says "Doesn't hurt". The value of in a handler refers to the element, not to the object - in the example, to the button with the ID "auaknopf". Needless to say, this completely idiotic context-dependent behavior doesn't exactly make it easier to encapsulate the complexity of applications that respond interactively to user input in objects.

By the way, I've heard peaceful people say very unpeaceful words when they fell for this JavaScript design problem.

Who needs error handling, negative zeros are better

The instruction…

var quux = 1/0;

…relies on . That is much better than a message that is completely incomprehensible for programmers like ... let's say .... Or maybe even an error condition that can somehow be caught in the program. Instead, there is just one program that does not work properly in some situations and fails completely without any hint. Of course, this is usually a variable that is not in every situation. You are happy about the sessions with a debugger because there is no helpful message; you are happy about a long, step-by-step passage of code until you finally hit the palm of your hand in your face. And then you might wonder what better things you could have done with that depraved day if you had one correct programming language would use for his applications.

But JavaScript has at least one concept that is rare and that is based directly on the phenomena of the world: the concept of negative zero, which can also be expected. The instruction…

var quox = 1 / -0;

... namely assigns the value. 😎

Oh, by the way, it's all very dynamic

An array like that is great because it's an object. You just usually don't notice that because you use it in an admittedly good syntax like an array:

var quux = [2, 3, 5, 7, 11]; var product = 1; for (var quox in quux) {product * = quux [quox]; }

An elegant way to calculate the product of the first five prime numbers, isn't it? You write such code all the time, and iterating with a loop is really nice too. It supplies each array index in a variable. This also works with hashes. And of course also with class instances, which, by the way, are nothing more than hashes. But you know that when you program in JavaScript, and that's all insane elegant. Especially insane.

Until the above-mentioned loop suddenly stops working while you continue to develop in a larger application.

You haven't changed anything about it, you say to yourself ... and suddenly you see an error message stating that you cannot multiply an object by a number. Well, then you just use a good debugger (which you can use imperative needed when programming in JavaScript) and take a look at what's going on. And oh dear, suddenly the array not only contains the first five prime numbers, but also a few function objects.

Well, this practical library that was used to save work, it has, among other things, expanded the interface of the array class. It's great that it's just as easy as it is in Ruby. You don't have to inherit the array to add a useful method, you can define your arrays afterwards in square brackets and stick to the normal, pretty JavaScript syntax. It's completely legal (and yes: even elegant) JavaScript, and I've seen code like this more than once:

Array.doSomething = function () {/ * Useful code here * /};

And then you notice that there is an element with the index in every array, because every array is a hash. This element is the newly defined method. For obvious reasons of nastiness, the standard methods such as and are not implemented in this way and are never seen in an iteration.

And then you start to do it all to hate

Enough said

One should give JavaScript and the idiotic idea of ​​an application running in the web browser - in my humble opinion - to the Chinese in order to bring their IT technology back to the state of Maoism. This could perhaps give the economy of the western world a certain advantage over the emerging state of the coming period for another decade.

Unfortunately nobody does that. Although it would be best.

Unfortunately, there are tons of programmers walking around here who waste their limited lifespan programming applications that are supposed to run in a web browser. You are not bothered by the fact that your "runtime" (ie the web browser) is stubborn, fat and insecure; they are also not bothered by the small incompatibilities between the popular browsers and often incorporate thousands of lines of proven codes in an interpreted programming language, which for the most part are nothing more than a collection of workarounds for these incompatibilities. They don't care that something like this is at most the third-best solution from the user's point of view, because they don't care about the users of their hack. They don't care that the programming language used is unusable, illogical, broken, a cramp in the ass. They sit there and are as happy as little children when they have implemented a single application in incredibly complex AJAX gestrokel, something like »The user enters a word in an input field and presses input, and the word is stored in the database on the server saved and, if successful, appears in a word list without reloading the page ”- something that would be almost trivial and incomparably more powerful in the context of a normal desktop application, even with a“ bitchy ”toolkit. It doesn't bother them that they are reinventing wheels ... and that the result is worse wheels. You are fascinated by the technical feasibility of such an undertaking, but are not interested in anything else. Doesn't it run well on computers that are more than three years old? Computers cost nothing, the old to the garbage dump and buy the new; may the poisonous mountains in front of the cities grow to heaven! Does it take up an unbelievably large amount of memory? It looks suspiciously like showmanship? Does it add a complexity to simple activities that is difficult to control even for experienced programmers? No matter. It is possible, it will be done. Without meaning or understanding.

If Google succeeds in replacing JavaScript with a better language, that would really be a step forward. Because JavaScript is unusable (if you want to do something other than a quick, little hack with it).

It would be even better if Google succeeded in replacing the current "web programmers" with better programmers.

This post was filed under Technical and tagged Absurd, AJAX, Browser, Google, JavaScript, Rant, Scrap, Web. Set a Bookmark the permalink.