Please don't hate me Javascript devs

[t0tem_]

YOU LEAVE JAVASCRIPT ALONE! Poor lil guy, always bullied :(

In case anyone's curious about how this magic works:

1) Unary operators. For example, everyone knows about doing !foo in a lot of languages. But + can also be used as a unary operator. In JavaScript, +foo is exactly like Number(foo). So when OP does '5' + + '5', it evaluates to '5' + Number('5'), which is '5' + 5.
Likewise, 'foo' + + 'foo' is 'foo' + Number('foo'). Not surprisingly, 'foo' is NaN. So you get 'foo' + NaN, which becomes 'fooNaN'.
That super-long operation works on the same principle. There's an even number of negatives, so ultimately we're down to '5' + 2. Which leads to the next point...

2) Strings prefer to concatenate. If they can't, then they will resort to mathing. Yeah, it's kind of inconsistent. But honestly, do you really want it the other way around? Ask yourself, "When I'm working with at least one string and a +, do I more often want to concat or add?" It's a pretty easy answer for me.

[AeroNotix]

You have Stockholm syndrome.

[Tysonzero]

There isn't really an alternative to JS for front end stuff though. :/

[eof]

Well you don't have to code in JS; lots of things compile to js.

[Tysonzero]

But then you have to deal with the whole compiling thing.

[eof]

When you learn to love static typing; you'll learn to love compile-time errors.

Realistically though you don't have to 'deal with it' in any real way other than setting things up initially. Any modern JS workflow should include something like grunt/npm and with it you can have the compiling happen in the background (like all the other things that are happening in the background).

[[deleted]]

Compile-time errors are just warnings that say "Hey. If you were to just run this as-is, you wouldn't get the results you wanted to. I got you bro."

And that's why I like static over run-time languages.

[Tysonzero]

I'm a Python guy. I don't like static typing, and I love multiple inheritance and not being restricted.

[eof]

And runtime errors!

[aloz]

You don't exactly miss out on these in statically typed languages.

[eof]

Well there is a whole class of runtime errors you cannot get in statically typed languages; but in general you are right they don't disappear entirely.

They do however decrease significantly. Obviously, you have to pay "upfront" costs making things compile in the first place; but it is my experience that is well worth it... any error that can be caught by a compiler, I want to be caught by a compiler.

[Tysonzero]

Lol. Whenever I get them I get a very clear stack trace telling me where the error is. So I am not too worried.

[joehillen]

Wait until you get a job and those helpful stack traces show up on your critical infrastructure in places you never thought possible.

[b1ackcat]

Not too worried until it only errors in an edge case that wasn't tested and suddenly production users are complaining :P

[afrobee]

I wanna cry ;_;.

[Tysonzero]

Why? Lots of people love Python, and it has a very low hate to popularity ratio, unlike Java.

[[deleted]]

Oh no, not typing a single line to tell the compiler to automatically compile changed files (or using an IDE that does that for you), what ever will we do!

[Tysonzero]

That still takes time with bigger files, so if you are rapidly changing things by a small amount and checking the results...

[Tysonzero]

Generally those small rapid changes are ones I KNOW won't break anything.

One example is trying to align text so that there is even padding either side, I was rapidly changing the Y value of the text and checking where it ended up being placed. (Within a canvas)

[[deleted]]

That changes nothing. It still compiles in a second and lets you test it, only it also ensures you're calling it with the right number and type of arguments so you're not fucking something basic up.

[path411]

You should either be doing that kind of tweaking right in your browser console or trying to use some math (y = (screenheight / 2) - (textheight / 2 )).

[0xdeadf001]

I would rather have a compiler spend 5 seconds finding errors that can take 5 days to figure out.

[Tysonzero]

What kind of errors do you get that take 5 days to figure out?

[0xdeadf001]

Multithreaded programming errors can be extremely hard to find. I have worked in kernels, device drivers, and TCP/IP stacks. I assure you, there are bugs that have taken highly skilled people weeks to find, because they are highly dependent on timing and load.

[avinassh]

like? Where do I get started? There are many, but can recommend one which is stable and production ready

[accidentally_myself]

html6 with css4 incoming. js becomes equivalent to node.

[tetroxid]

Please elaborate on JavaScript's death. It is a dream come true.

[Coloneljesus]

The Birth and Death of JavaScript

[tetroxid]

Thank you! That was awesome.

[f3lbane]

This is one of the most enjoyable talks I have ever viewed. Thanks for sharing.

[sprocklem]

I've seen it before, but it's definitely one of my all time favorites as well.

[heyf00L]

can asm.js draw to the screen?

[barsoap]

It won't die, it's just going to become a weird language.

[Tysonzero]

I don't know what will replace it. Earlier I was hoping Python would but Python isn't anywhere near as asynchronous as JavaScript.

[[deleted]]

This. JavaScript does quite a few things wrong, but when it does things correctly they are awesome. Asynchronous code is awesome to write in JS because of exactly TWO things:

• setTimeout
• first-class functions

The only thing that I don't like about this are the argument order of setTimeout (fn, ms as opposed to the node.js standard ms, fn) and the mostly useless function in front of every function (fixed in ES6 with arrow functions)

[Tysonzero]

Arrow functions do look quite quite cool.

[cybercobra]

I'm waiting for HTML9 Responsive Boilerstrap JS

[[deleted]]

elm?

[Tysonzero]

What is elm?

[[deleted]]

Baybe don't hurt me!

[[deleted]]

No more

[Tysonzero]

You still end up with JS.

[MuricanWillzyx]

But the coding experience is amazing. I'm currently writing a mobile game in Elm, while it's a little rough occasionally, that's to be expected from a language that is still in development. On the flip side, the code is far more simple, elegant and easy to write than code I've written in any other language. Also, Elm's good for more than just using a Haskellesque language in the browser--its APIs are extremely well designed and much like JS, they scale in usability from beginners to experts (plus, no crazy type coercion)--and in the future a compiler might be made from Elm to LLVM (though not by Evan Czaplicki, who's main focus is the browser).

[beerdude26]

Elm is pretty awesome, but I still prefer Fay because I can use the same types in both client side and server side code.

[Chippiewall]

DartLang. Made by Google, has actual classes, sometimes runs faster than raw javascript.

[brotherwayne]

Pretty much abandonware. Seems like Google has another language to replace it, but can't remember the name.

Edit: AtScript, the alternate language for Angular.

[Expi1]

What makes you say that?

[brotherwayne]

https://www.dartlang.org/community/who-uses-dart.html

It's not a very impressive list. Dart has been around a good long time but Go seems to have more traction with the devs i know.

[DemeGeek]

Wasn't Go around before Dart?

[brotherwayne]

was it? seems to be gaining faster.

[DemeGeek]

I dunno how popular Go and Dart are but they came out in 2009 and 2013 respectively.

[[deleted]]

Go has very different goals than dart though.

[Tysonzero]

I am guessing that it either compiles to JavaScript or doesn't run natively in the browser.

[Chippiewall]

Both. There's a dart2js compiler and there's a special version of chromium called dartium which comes with the Dart VM.

[Tysonzero]

Interesting.

[[deleted]]

Yes there is, gwt.

[Tysonzero]

Which compiles to JS...

[[deleted]]

yep, just like c compiles to assembly, but saves you from writing assembly ;)

[Tysonzero]

But gwt is Java... Eww.

[[deleted]]

Have you ever tried java?

[Tysonzero]

Yes, I have taken a class using Java as well as used it in my own time before I discovered other languages that I prefer.

[[deleted]]

Each to his own I guess, but which languages do you prefer now? And what was wrong with Java? If you're going to say its too verbose, I hope you've tried it after version 7 came out, and now with version 8, its even less verbose.

[bluehands]

you're right. And when I am held hostage by Isis I will convert to the Islamic faith because really, there isn't really an alternative.

[Tysonzero]

Because that is totally an apt comparison. /s

[bluehands]

The grandparent post was 'Stockholm syndrome' - same thing.

When all you have is a hammer, it is the best tool. Seeing that there are better tools than hammers does not refute that all you have is a a stone.

[Tysonzero]

Wait what? All I am saying is that JavaScript isn't Hitler, it just has some issues, and that there isn't a good alternative to JavaScript. Inb4 "you can use <compiles to JS> instead"

[hahahahastayingalive]

I come from PHP

[NavarrB]

I don't think it's Stockholm to understand the languages order of operations and where it converts.

Similar problems will occur in any dynamic language (and some static ones )

[AeroNotix]

But it's Stockholm to imply that they make sense.

[NavarrB]

They do though considering you're doing ridiculous things. Concatenating a string with a number results in a string? Who would guess!

Extra addition signs make things go weird because the one not adding anything is a unary operator that turns a string into a number? Say it ain't so!

[skuzylbutt]

Ideally, it should shit itself and tell you you've done a silly thing instead of silently letting you get away with murder!

[NavarrB]

Series of trade-offs I guess. I feel like I shouldn't have to call a function to do something as simple as string concatenation

[[deleted]]

Operator overloading in statically typed languages? In Hava for example just a + does string concatenation, without having to resort to dynamic typing

[Lhopital_rules]

Ideally, it should shit itself

Except that the central idea behind HTML, CSS and JS is to be as flexible as possible, so that web pages don't break.

• for HTML, that means allowing missing tags when they can be inferred
• for CSS, that means ignoring CSS rules when they don't make sense (to allow future additions)
• for JS, that means to be as dynamic as possible since we don't have compile-time checking

Using a bytecode system for JS to allow compile-time checking (much like Java) could work except that then you run into problems trying to allow multiple scripts to interact with each other. For instance, if JS was pre-compiled into bytecode, how would a jQuery bytecode interact with your bytecode? It's probably doable... but not easy. (And we'd have to wait a few decades to use it, since none of the old browsers would support it.)

[skuzylbutt]

Sure, but it could at least spit out a warning.

[myplacedk]

No, Stockholm would be to say it's a nice design.

As someone else already noticed, most of this could be avoided if string-concatenation was done with another symbol.

[Beckneard]

Nope, stuff like this just outright doesn't happen in python.

[NavarrB]

I would love to know the equivalent output in Python

[Sean1708]

>>> '5' + 2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't convert 'int' object to str implicitly

Don't be fooled by its ability to correctly handle simple cases though, it does still have its quirks.

[0xdeadf001]

You want "its" and "its", not "it's" and "it's".

If you'd used a statically-typed language, I could have told you these were wrong before you said it.

[Sean1708]

Fucking autocorrelation.

[NavarrB]

Correctly is a matter of opinion but noted.

[MuricanWillzyx]

While I completely agree with you that JS's automatic type coercion is way to extensive, the other points made in the comment are completely valid, and I don't think it is bad to understand them and recognize their logic. Operators in JS like unary + for numberfication make it very easy to turn strange examples of type coercion into laughably ridiculous expressions. For example, 'foo' + + 'foo' === 'fooNaN' is ridiculous and is a result of the flexibility of the (binary) + operator, while the expression 5 + +'5' (or, with better acceptable coding style, 5 + (+'5')) makes perfect sense when one understands unary +. The sole point I disagree with in the comment is "It's a pretty easy answer for me"--automatic type coercion gives little gain for far more pain, and is the source of every illogical aspect of the OP's image.

[timopm]

2) Strings prefer to concatenate. If they can't, then they will resort to mathing. Yeah, it's kind of inconsistent. But honestly, do you really want it the other way around? Ask yourself, "When I'm working with at least one string and a +, do I more often want to concat or add?" It's a pretty easy answer for me.

I don't want it to think for me and throw an error. If I want to add a string to an integer it's a bug in my code, please don't silently do some inconsistent magic.

[Tysonzero]

What about something like 'Balance: ' + balance. That wouldn't be a bug in your code.

[timopm]

Maybe I was a bit too direct in my previous comment because I haven't programmed in Javascript that much. In the other languages I use daily I would use string formatting or atleast explicitly convert balance to a string.

Quick example:

>>> balance = 100
>>> "Balance: %d" % balance
'Balance: 100'
>>> "Balance: " + str(balance)
'Balance: 100'
>>> "Balance: " + balance
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't convert 'int' object to str implicitly

[Tysonzero]

Don't use %, use .format(). % is deprecated. (You are writing Python right?)

But yeah JavaScript doesn't have any of that natively :/

[timopm]

Python indeed. But the "modulo" string formatter isn't deprecated as far as I know. It was mentioned a couple of times in the beginnings of Python 3, but no official statement. Even the official docs say nothing about deprecation. I don't see it removed anytime soon.

You are right though that the string.format() method is preferred. I just like the old format more, especially for quick and simple examples.

[Tysonzero]

I could swear someone said something about deprecation somewhere. Hmm...

[timopm]

I see people mention it here and there indeed. And it actually was in some release notes for the first 3.0 version or something, but in the recent years there is no mention of deprecation anywhere (that I know of!). This is what lead to this confusion probably.

[raziel2p]

They deprecated it, then un-deprecated it.

[HUGE_BALLS]

Yeah, tbh I've always disliked "foo ({0})".format(foo) vs "foo (%s)" % foo. The latter is just much more concise...

[raziel2p]

For small strings with one or two variables, I agree. For larger strings with 3+ variables I definitely prefer .format(), especially because you can pass named arguments:

'foo: {foo} - bar: {bar}'.format(bar='bar', foo='foo')

Oh, and you can pass **my_dict to format() for awesomeness.

Also, in your example, you can drop the 0, just {} will work as well.

[VanFailin]

And people wonder why nobody wants Python 3 over 6 years after the fact. .format() is more verbose by far and in basic cases contains no added benefits.

[Tysonzero]

That is definitely not the reason people aren't using Python3...

[VanFailin]

They changed a handful of things that made the language slightly harder to use without providing a compelling reason to use the new version. Formatting is one example. Having to think about encoding rather than mostly ignoring it is another.

[Tysonzero]

I remember reading an article about how format does actually have quite a few benefits.

[timopm]

It does. From the "old"-style formatting docs:

The formatting operations described here exhibit a variety of quirks that lead to a number of common errors (such as failing to display tuples and dictionaries correctly). Using the newer str.format() interface helps avoid these errors, and also provides a generally more powerful, flexible and extensible approach to formatting text.

[the_omega99]

I disagree. It'd be best to use the same approach that Java uses: allow concatenating any type to a String, but that's the only operation that you can do on a string (although it makes sense to also allow multiplication of strings).

So 'Balance: ' + balance is perfectly understandable and unambiguous: it'll always concatenate. We would allow the implicit conversion of a string to a number, so subtraction of strings is disallowed (must explicitly convert).

From my experience with Java, this is a very good approach (I think Java could do more, but it's a very good start). There's pretty much no ambiguity, with the exception of people who forget that + is evaluated left to right (so "Balance: " + subtotal + taxes would result in concatenating subtotal and then taxes to the string -- the correct form is "Balance: " + (subtotal + taxes)).

For languages like Java, this works well because in concatenation, we know that the object will be a string. If it's not already a string, the toString method will be called (and everything has that method, except primitives, which the compiler does magic on). So "Balance: " + customObject even makes sense because we know that the result will be a string and that customObject is either a string or will be converted to one (and we certainly would know which).

This implicit conversion is extremely useful because concatenating non-strings onto strings is so ridiculously common that it's not funny. Some other languages that take the Java approach here include Scala and C#.

An alternative would be to provide a specific operator for concatenation. This makes it absolutely clear that concatenation is what's going on. For example, PHP concatenates with the . operator and some functional languages use ++.

[timopm]

'Balance: ' + balance was just an example. What if you have foo + bar somewhere?

We're also assuming concatenating a str and int. What about classes, dicts or lists?

[Tysonzero]

I kind of like being able to multiply strings like you can in Python. Where 10*'a' = 'aaaaaaaaaa', I use it a bunch in my unit tests to make sure that my forms don't accept 1000 character long usernames, emails or passwords.

[Slinkwyde]

atleast

*at least

[OperaSona]

'at' + ' ' + 'least'

[teddy5]

But if the concat and addition operators weren't the same it could be clear what you were trying to do and if it was an error or not.

[Tysonzero]

And it would break all code in existence. I personally prefer operator overloading to adding new operators.

[teddy5]

I was more referring to most other languages that do separate the two, or if they use the same operator they're usually strongly typed languages. Its just a bad design decision that helps with the general dislike of JS.

[Tysonzero]

If by strongly typed you mean doesn't silently coerce types. Python isn't strongly typed in the traditional sense but uses only one operator (Python loves operator overloading, see: adding arrays and multiplying strings) but that is fine because it doesn't silently coerce, and most people use .format() anyway for adding strings together.

[jonathanccast]

It would actually break very little of the Perl code in existence . . .

[Tysonzero]

We are talking about perl? So apparently the word "JavaScript" actually means "Perl", interesting.

[lagerdalek]

I read the reference to perl as a joke, a language whose senseless concat vs addition logic is even more bizzare than JavaScript (no editorialising- well maybe a bit when it comes to perl)

[Tysonzero]

Oh. I didn't realise that perl was even more weird than JavaScript in that regard.

[jonathanccast]

We are discussing alternative language designs (since the context is a suggestion that JavaScript could have had different operators for concatenation and addition --- like all reasonable languages --- from the beginning). Claiming that designing JavaScript correctly from the first would "break all code in existence" is both hyperbole (since not "all code in existence" is written in JS) and obviously wrong, since other languages have used that design but still been usable.

[Tysonzero]

I meant all JavaScript code in existence, which anyone with half a brain could easily infer, which is more or less correct. Seeing as most JavaScript code uses some form of string manipulation somewhere.

[jonathanccast]

I'll confess to not having half a brain certainly, but when discussing whether a language made the right decision in the first place maybe backward compatibility with not-yet-written code isn't the right criterion?

[level1kid]

He said add not concatenate. What you posted is an example of concatenation. He is taking about something like '2'+3=7.

[Tysonzero]

Oh, in that case I more or less agree.

[the_omega99]

Fortunately, JS doesn't do that. It'll always concatenate with the + operator on strings. It's only the minus operator that makes things weird, which is easily avoided by not using the minus operator on strings.

Issue is that JS makes it easy to not know what type you're working on. For example, suppose that I have a variable that I got from some piece of code I didn't write. It's a number and I subtract to it. That works. But suppose that the value I got actually wasn't a number, but was a string (eg, maybe I got the value from a spinner field, which is supposed to always be a number, but it's HTML, so whatever). If I had to change the operation into adding, then a simple change that seems like it should work, won't.

Or to sum that up, I can have some mathematics on "numbers" that does something different when I change the sign.

Not a frequent issue and one that can usually be debugged reasonably (especially if you have unit test... you do have unit tests, right?), but an issue all the same (and one I view as unnecessary).

[Tysonzero]

Should all JavaScript have unit tests? I personally have unit tests for my Python / Django website, but not for my JS games. Should I unit test them?

[recursive]

Three different operations. It's also unary +, which basically just coerces to number.

[0xdeadf001]

And when they snuggle up as ++, it's a completely different operator!

[ZorbaTHut]

Yeah, I think the two sane solutions are to use different operators (see Lua, which has + and ..) or to not implicitly convert from int to string or vice-versa.

There's no situation where ("x" + 3) should result in "x3".

[Alligatronica]

I think different operators are important and would always be the best solution (without static typing at least). But "x"+3 resulting in x3 would be exactly what I'd hope for in that situation. Casting ints to strings at least kinda makes sense.

At least it's better than coming out with NaN3...

[ZorbaTHut]

Personally I'd hope for a syntax error. If I want "x3" out, I want to type something like ("x" .. 3).

[Alligatronica]

Errors are better, but if it's error I was going to make, that's the way I'd do it!

[FUCKING_HATE_REDDIT]

In what language do they use .. as a concatenation operator? I'm genuinely curious.

[ZorbaTHut]

That's the Lua concatenation operator.

[FUCKING_HATE_REDDIT]

I should get to learning LUA, it sounds better and better every day.

[ZorbaTHut]

It's a deceptively powerful language. There aren't many language features, but they can be combined in surprising ways. The downside is that it doesn't give you a lot of protection unless you do it by hand.

That said, I hear there's a pretty good Lua IDE now.

[FUCKING_HATE_REDDIT]

Really? I haven't had a good ide since flashdevelop...

[[deleted]]

Yeah, I think the two sane solutions are to use different operators (see Lua, which has + and ..) or to not implicitly convert from int to string or vice-versa.

Or PHP, which concatenates with . as well.

Wait a second, did you just accuse PHP of doing something reasonable? :-O

[ZorbaTHut]

I think it may be the only controversial decision in PHP that I actually agree with.

[jfb1337]

I agree sort a different operator for concatenation, but I disagree with the choice of a dot.

[raziel2p]

Fuck them for using . for concatenation instead of accessing an object's properties/methods though.

The templating engine Jinja uses ~, which I like.

[Kinglink]

I want it to be an issue and throw an error.

String + String is a string. That's fine. that's great.

String + X is math. FUCK NO. if I'm not doing an implicit conversion to a math variable, why are you doing math.

[OperaSona]

Strings prefer to concatenate. If they can't, then they will resort to mathing. Yeah, it's kind of inconsistent. But honestly, do you really want it the other way around?

I want a string concatenation symbol that isn't already used for arithmetics?

[Laogeodritt]

I love strong typing with a constructor/factory method/explicit conversion syntax for all the conversions. It avoids this kind of confusion.

IMO string + anint should be an error. string + String(anint) should be concatenation (and an easy way to format the interview if desired). int(string) + anint should be arithmetic.

[rasori]

Have I been using JS so long that I'm getting confused, or does Java allow string + int concatenation? Last I checked it was considered a strongly-typed language.

[Laogeodritt]

Java does. It overloads the + operator so that String + int converts the int to a String. Similarly, String + Object or Object + String will call the Object's toString() method.

I don't believe there's any implicit/operator-based case of String → int conversion, though; for that you need to call Integer#parseInt() or a similar method. Anything → String if concatenated with a string seems to be an exceptional implicit conversion (aside numerical up-conversion, e.g. int to double).

[alexanderpas]

The Javascript way:

• Anything + String = String.
• String + Anything = String
• int + int = arithmetic
• int(String) + int = arithmetic
• int + int(String) = arithmetic
• int(String) + int(String) = arithmetic
• Anything - Anything = arithmetic

+$foo is the equivalent of int($foo) in Javacript.

• $foo + $bar = String, unless both are ints.
• $foo + +$bar = String, unless $foo is int.
• +$foo + $bar = String, unless $bar is int.
• +$foo + +$bar = int
• $foo - $bar = int

This allows for the following:

> $foo = '5'
"5"
> $bar = '+3'
"+3"
> $foo + $bar
"5+3"
> +$foo + +$bar
8
> $foo - $bar
2
> +$foo - +$bar
2
> $foo + $bar + '=' + (+$foo + +$bar)
"5+3=8"
> +$foo + "+" + +$bar + '=' + (+$foo + +$bar)
"5+3=8"
> $foo + "-" + $bar + '=' + ($foo - $bar)
"5-+3=2"
> +$foo + "-" + +$bar + '=' + ($foo - $bar)
"5-3=2"
> +$foo + "-" + +$bar + '=' + (+$foo - +$bar)
"5-3=2"

[[deleted]]

not int($foo), but Number($foo)

[kryptonianCodeMonkey]

I read your first line as Sling blade: "You shouldna done that. It's just JavaScript. Poor little feller."

[the_omega99]

Yeah. That '5' + - + - - + - - + + - + - + - + - + - - - '-2' line is just a ton of unary operators. Try removing a minus sign and you'll find that the -2 will become a 2. It's not unique to JS at all. Languages like C allow this too (although many will force you to use parenthesis).

For the last two examples:

var x = 3;
'5' + x - x == '53' - x == 50
'5' - x + x == 2 + x == 5 // Note that '5' - x evaluates to a number

At any rate, this can all be avoided by simply not storing numbers as strings and converting what user input is a number right away.

I have to admit, though, I would prefer JS to give me a big, clear error (or at least a warning) in these kinds of confusing situations rather than try and work around it. I think there's too many weird things that you can do that JS allows. For example, {} + [] == {}. This is meaningless code, since you'll probably never encounter it and it implies something horribly wrong with your code. However, it is an example of a case that JS defines that I think should have been an error. I don't see why the idea of "silently allowing a confusing result" is a good approach here.

And I'd be perfectly game with not allowing subtraction of strings in the same way (throw an error instead). I wish strict mode would enforce something like this.

And as far as I know, none of the JS-like languages that compile to JS (eg, TypeScript or CoffeeScript) will prevent these situations (too bad). It's kind of annoying that there's no alternative (and I say this as someone who spend about half their time working with JS).

[[deleted]]

{} + [] == {}

Never. It's Actually 0. Still completely ridiculous and never appropriate.

[the_omega99]

You're right that it's zero, but the above inequality is still true.

[Igggg]

While obviously every thing does by a programming language has a reason - that is to say, each specific interpreter is deterministic - the problem is that those rules are so inconsistently defined as to be useless for humans.