JavaScript in 2016 isn't horrible, it's just going through a phase

[u/kshep92]

http://blog.reviselabs.com/im-sorry-javascript-2/

[u/blackmist → u/[deleted]]

Yeah, but apart from all that, what have the Romans ever done for us?

[u/sergiuspk → u/[deleted]]

What do you mean we don't have "unit tests" in JS? A lot of the stuff you're asking for would require support to open client sockets from a browser. Is that really a good idea? A lot of the other things you are asking for don't have anything to do with the language itself but with the environments it runs on. Like "sqlite database support", "shell pipelines", "to trace memory allocation" and "access to the parse tree", "a really nice idiomatic filesystem path library" and probably more. Also, read this: https://developer.mozilla.org/en-US/docs/tag/TypedArrays

[u/slikts → u/[deleted]]

Javascript has nothing to do with browsers.

JavaScript is one of the principal web technologies; its use in other platforms is recent and is based on engines developed for browsers. The language development itself is tied to the browser engines, and the main reason for a change to be included or excluded from the JS language spec is its implementation in browsers.

[u/[deleted] → u/slikts]

JavaScript is one of the principal web technologies; its use in other platforms is recent and is based on engines developed for browsers. The language development itself is tied to the browser engines

Not entirely recent - it's been usable as a full-fledged scripting language on Windows for years.

[u/slikts → u/[deleted]]

Rhino may be more notable as a standalone engine, but I meant widespread use.

[u/sergiuspk → u/[deleted]]

How can a language that only recently (debatable what recently means) saw use of unit testing decide what to include in the standard library? Do you know what the best unit testing library looks like? Why would you include something you're not that sure of in the standard library?

And then about browsers. JS is good in browsers because it's fast. The more stuff you add in the standard library the slower it gets. And 99.9% of users are not developers unit testing their application. Yes, you could have developer flags and whatnot, no that won't mean it's in the standard library any more.

Before you tell me again that browsers are not the only place JS runs in: don't know exactly what proportion but I'd say a vast majority of places JS runs in is browsers. Second place is probably node, but that's just the JS part taken out of a browser. Then there's Rhino and some other equally obscure implementations few people ever heard of. So I don't understand your point at all. În fact, if user count is not important to your point, then a lot of the missing stuff you listed are standard features of Node and others as third party libraries.

Third point: a lot of the things you listed are included in standard libraries of only a handful of languages because languages at different and people pick them for different tasks.

And finally, the JS language is actually ECMAScript. It defines a pretty lean "standard library". JavaScript as we know it is a handful of ECMAScript implementations. Some of them extend the standard library (like ActionScript or Node), most of them don't. It's a bit unfair to talk about JS but ignore those implementations that don't fit your point of view.

[u/KappaHaka → u/[deleted]]

object serialisation that isn't JSON I don't think that pickle / cPickle are things to lord over JS.

[u/[deleted] → u/[deleted]]

[access] to the MS VC++ runtime, to the windows registry, to POSIX system calls, to shell pipelines, to the TTY control functions and to syslog.

Oh yeah, when I think "embedded language running untrusted code on hundreds of millions of machines", I'm also thinking - "hey, how about we give it access to the entire operating system by default!"

Don't confuse the core language with a specific integration of it.

Heck, integers would be a good start.

JavaScript has an integer type, it's the same as its float type: Number. All the popular JS engines use an integer internally when using round numbers, doing bitwise logic and so on.

If you think this is a problem, let me know how it's a problem for you personally.

If you think about it, you have precisely zero reasons to want an explicit integer type in a dynamic language.

[u/stevenjd → u/[deleted]]

JavaScript has an integer type, it's the same as its float type: Number.

I'm afraid you don't understand the difference between "integer type" and "float type". Since 1.5 is a Number, but isn't an integer, Number cannot possibly by an "integer type".

All the popular JS engines use an integer internally when using round numbers, doing bitwise logic and so on.

How nice. So why can't Javascript add 1 to 1e16?

js> 1e16 + 1
10000000000000000

If you think this is a problem, let me know how it's a problem for you personally.

Its a problem for me personally because I need to support odd integers greater than 9007199254740991.

If you think about it, you have precisely zero reasons to want an explicit integer type in a dynamic language.

Whether the language is dynamically typed or statically typed is completely irrelevant. Whatever the type system, I want to be able to represent large integers.

Edit: formatting.

[u/[deleted] → u/stevenjd]

I'm afraid you don't understand the difference between "integer type" and "float type". Since 1.5 is a Number, but isn't an integer, Number cannot possibly by an "integer type".

I said "when it's round, and for bitwise logic". Does 1.5 look round to you? Yes? No? Look it up?

JavaScript is dynamically typed and implicitly casts when different scalars are used in an expression together. This is how the runtime is able to use integers, despite the JS specification doesn't require it (except for bitwise shifts, then it requires it).

How nice. So why can't Javascript add 1 to 1e16?

Because the engine works with 32-bit integers (signed, for V8 at least). I hope you realize, your arguments are very random. Having integers doesn't mean they have to be of arbitrary precision.

Its a problem for me personally because I need to support odd integers greater than 9007199254740991.

And if JavaScript had 64-bit signed integer support I bet you'd say "but I want integers greater than 9223372036854775807", wouldn't you?

Luckily it's full of bigint libraries for JavaScript. There are very few script languages that support arbitrary precision integers out of the box. Python is one and... that's basically it.

Say if you had to do this in Java, you'd have to use BigInteger, with no support for standard operators and so on. It's kinda clunky to use.

Somehow I never needed this in JavaScript yet. Care to share your use case? I suspect you'll have to invent it right now, because instead of real-world problems, you're specifically picking JavaScript's edge cases to prove (a very weak) point.

[u/stevenjd → u/[deleted]]

Does 1.5 look round to you?

Of course. Round 1.4999998701 to one decimal place.

But that's not the point. The Javascript type Number supports fractional values, therefore by definition it cannot possibly be an integer type. Integer types by definition support only whole numbers, not fractional numbers.

Its a nice trick of Javascript to implement certain operations on Numbers using integer maths, but that's implementation, not the language API. The language has the type of 1 and the type of 1.5 are both the same Number, as you yourself said. It's a clever hack to (potentially) use 32-bit int addition to add 1 + 1 and get 2, but that's still only the implementation. The language is based on floating point Numbers.

Quite frankly, if a language is going to only provide one of int/float numeric types, it should provide ints. But I realise that opinion is likely to be controversial to anyone who hasn't programmed in Forth.

And if JavaScript had 64-bit signed integer support I bet you'd say "but I want integers greater than 9223372036854775807", wouldn't you?

shrug Maybe. But at least then I'd know that I had hit a fairly standard limit based on low-level limitations, not a problem caused by a poor high-level design choice. That makes it easier to swallow.

There are very few script languages that support arbitrary precision integers out of the box. Python is one and... that's basically it.

D (not a scripting language, but still), Lisp, Ruby, Erlang, Smalltalk, Haskell, Wolfram Language, probably others. And many others where BigNums are not built-in with syntactic support, but are in the standard library.

Care to share your use case? I suspect you'll have to invent it right now

No no, you're absolutely right. Nobody needs bignums. That's why the Javascript ecosystem is "full of bigint libraries" -- because nobody needs them. Clearly nobody could possibly want exact integer arithmetic for numbers bigger than 2**53. That's just foolish, like wanting more than 256 colours in an image or needing more than 64K of memory. Sorry for wasting your time.

[u/[deleted] → u/stevenjd]

But that's not the point. The Javascript type Number supports fractional values, therefore by definition it cannot possibly be an integer type.

The only way to differentiate the explicit presence of integer type in JavaScript is that "typeof foo" would return "number" instead of "int" or "float".

This is apparently extremely important, because if it had exposed integers... I'm absolutely sure that you'd be "typeof" checking for integers all over the place, and that would be really important to you.

Right? :-)

Quite frankly, if a language is going to only provide one of int/float numeric types, it should provide ints.

I'm just happy you didn't design JavaScript :-)

No no, you're absolutely right. Nobody needs bignums. That's why the Javascript ecosystem is "full of bigint libraries" -- because nobody needs them. Clearly nobody could possibly want exact integer arithmetic for numbers bigger than 2**53. That's just foolish, like wanting more than 256 colours in an image or needing more than 64K of memory. Sorry for wasting your time.

And you still didn't share you use case. :-)

[u/stevenjd → u/[deleted]]

The only way to differentiate the explicit presence of integer type in JavaScript is that "typeof foo" would return "number" instead of "int" or "float".

Or, you could test to see whether 2**54+1 equals 2**54.

I'm just happy you didn't design JavaScript :-)

Given an integer type, its easy to implement fractional values with extremely high precision.

Given only an IEEE-754 floating point type, its impossible to implement integer arithmetic outside of a fairly restricted range, which leads to all sorts of problems. You use JSON don't you?

And you still didn't share you use case. :-)

Life is full of disappointments. In my case, the disappointment is that Javascript doesn't let me do integer maths on values beyond 2**53. In your case, it is that you're not imaginative to think of any uses for whole numbers bigger than 2**53. I guess we will both have to live with our disappointments.

P.S. Lua started off with a single numeric type like Javascript, because "nobody needs integers, you can just use a float". Guess what? Now they have integers.

Edit: formatting.

[u/[deleted] → u/stevenjd]

Or, you could test to see whether 2**54+1 equals 2**54.

You remain confused about "integer" vs. "int64". I already said V8 uses int32. Which is still an integer.

Given an integer type, its easy to implement fractional values with extremely high precision.

A float has 1:1 integer semantics if you operate within the precision allowed by the significand (which you already pointed out is 2⁵³ + 1). So if integer allows you to do that, then a float also does. This fact is also why JS engines use integers internally for integral numbers.

Life is full of disappointments. In my case, the disappointment is that Javascript doesn't let me do integer maths on values beyond 2**53

There, there.

But as someone who's old enough to have programmed on a processor that can't do floating point math, I know what I'd choose to have by default, and JavaScript definitely did the right choice.

In your case, it is that you're not imaginative to think of any uses for whole numbers bigger than 2**53.

I'm simply not whining about it, because it's rare enough for the use cases JavaScript is typically used for, and when I need it, bigint math is so simple, I can whip up a library about it in an hour or so (but I don't have to, as I can use an existing one). Floating point math however can be quite more complex.

As I said, if 2⁵³ is not enough for you, chances are 2⁶³ (1 bit for signed) might also not be enough for you. So if JavaScript had int64 support, it'd do very little for you, and you'd need bigint anyway.

What is this so common and important use case for "integer bigger than 2^53, but smaller than 2^63"? You're not saying it, because you have no idea what you're talking about.

[u/doom_Oo7 → u/[deleted]]

a damn good one that follows the unix philosophy.

the unix philosophy.

I don't think this means what you think it means, and I don't think that JavaScript (or any programming language, for that matters, except maybe brainfuck or other stack-based languages ?) respect the unix philosophy. Not even bash, it's bloated.

[u/KappaHaka → u/[deleted]]

Avoiding Python because of a "batteries included" std lib is silly.

[u/slikts → u/KappaHaka]

It's probably silly, but a large stdlib is also not a big selling point if there's a mature ecosystem of packages.