Java Fucking Script

File: asynch.png (35KB, 1920x358px) Image search: [Google]

35KB, 1920x358px

>>55197303
asych

nothing to see here

File: 1442006802219.png (86KB, 600x1200px) Image search: [Google]

86KB, 600x1200px

>>55197303
>Google Fucking Chrome
NO comment

>>55197893
are you meming or just retarded?

OP's code is not asynchronous in any way.

>>55197303
You are shit programmer. Use ===

>>55200868
You have shit eyes.

>>55197303
Why does this happen?

>>55201558
known V8 bug
op is a fag

File: image.jpg (2MB, 3264x2448px) Image search: [Google]

2MB, 3264x2448px

>>55201558
I second this

>>55201558
can't be reproduced in waterfox or in chrome.
OP is a faggot

File: javascript.png (12KB, 553x174px) Image search: [Google]

12KB, 553x174px

>>55201729
>>55201777
Happens for me

Every language should be statically typed and define generic equality as forall a. a -> a -> Boolean with no type coercion. If a language designer can't get something so basic correct they have no business designing languages. Comparison should also be generic and defined as forall a. a -> a -> EQ | GT | LT and definitely not a -> a -> Int.

>>55202024
What's with your arrow shit? Are you trying to prototype a function in haskell or something? Or are you trying to define a grammar?

>>55202024

Equality between two objects may have definitions that differ widely based on the programmer's desires. You can define equality on all builtin types, but a generic equality operation on compound types is stupid.

Less than and greater than do not make sense for all types, and therefore the language should not default provide such comparison operations as a builtin generic.

int is fine for minimalist type systems, rather than an enumerated type, because it nonetheless encapsulates the idea well. If the result negative, it means less. If it's positive, it means greater, and 0 means equal. Not every language needs to be Haskell.

>>55202196

Haskell's arrow syntax actually makes little sense for describing a large number of languages, because most languages do not use currying by default. Taking an argument of type a, and returning a function that takes an argument of type b, and returns an argument of type c, is not the same thing as taking two arguments -- the first being of type a, and the second being of type b -- and returning a value of type c.

C's strcmp function isn't a const char* -> const char* -> int, it's more like a (const char*, const char*) -> int. You can't call the function with only one argument.

>>55204090
> and therefore the language should not default provide such comparison operations as a builtin generic.

The existence of a generic comparison operation doesn't automatically mean it's provided for all types you retard. Even equality doesn't make sense for all types.

>Haskell's arrow syntax actually makes little sense for describing a large number of languages, because most languages do not use currying by default

Academic CS and certain math disciplines have used a similar syntax for describing function signatures long before Haskell even existed. It has absolutely nothing to do with currying.

Absolutely everything you said was idiotic. Please stop posting retarded trip faggot.

>>55202024
Sometimes you want equality between values of two different types.

>>55205918
>Academic CS and certain math disciplines have used a similar syntax for describing function signatures long before Haskell even existed.
a → b → c always means currying.
a × b → c means a pair argument.
a b → c means multiple arguments.

>>55206088
>a → b → c always means currying.
No it doesn't.

>>55206206
I'd like to see one example where it isn't the same as

a → (b → c)

.

I have seen a left-associative arrow like

(a → b) → c

, but you obviously didn't mean that.

More like Jawadscript.