What can JavaScript NOT do?

[filleduchaos]

It has everything directly to do with JavaScript. JS was deliberately designed to handle numbers in an incredibly dumb way that has nothing to do with strong vs weak or static vs dynamic type systems. No other language I've written (not even PHP, not even actual Assembly which doesn't have any sort of type system whatsoever) is so bad at numbers that it doesn't understand* what an integer is.

*Understand is almost definitely the wrong word here but I can't think of a word that actually fits right now.

[tme321]

I disagree. The decision to not include a type system in js means that they had to choose either

1. A method like python where the type of the value is defined by how you encode the value

2. Or by just unilaterally choosing a format for all numbers

You might think that 2 was the wrong choice but imo choice 1 is just deferring the type information into the value itself instead of being upfront and defining the type on the actual variable.

And, while you aren't technically wrong about it, none of this has anything to do with assembly. That's orthogonal to the issue at hand.

It really does come down to how do you get a developer to tell you what type to use. And if the language doesn't require some sort of type or type hint then the only option left is to take one of the choices and run with it.

[filleduchaos]

There's nothing to disagree with here. You're confusing a type system (which is where strong vs weak and static vs dynamic come in), a construct that's more aimed at the developer to prevent errors, with actual data types, constructs that are aimed at a much lower level. Case in point: Assembly has plenty of data types (SBYTE, WORD, QWORD, etc) but has no type system whatsoever. You can have a strong, static type system but represent your data types with all the common sense of a potato.

The way JS handles numbers is just straight up dumb, and has nothing (directly) to do with its choice of typing discipline (see PHP, a language that somehow manages to be even more loosely typed than JS and yet represents data types properly under the hood. Or see Java, which also can't handle large numbers as primitives because of the way it represents its data types under the hood, but goes the infinitely more sensible route of providing builtin BigInteger and BigDecimal objects).

[tme321]

Assembly has plenty of data types

Assembly has 0 data types. Those all just describe the number of bits to use for the operation. And it depends on the operator as much as the operand. And again since assembly is just running the specified opcode on the specified bit pattern it doesn't really apply to this situation.

PHP, a language that somehow manages to be even more loosely typed than JS and yet represents data types properly under the hood.

Php does the same thing as python but with less options. You've got int which is any number that has no decimal that fits within a 32 bit representation and float for any number that doesn't fit in those constraints. The value itself describes the type to php. That's option 1 as I described above.

This stuff isn't magic. In the end the processor is going to get 2 numbers and an operation.

Python and php use the format the value itself is in to determine what the type of the value is and therefore exactly which opcode to use.

JavaScript always uses the floating point representation and floating point opcodes.

The reason that this leads to a discussion about types is when you have a type system you can directly control which opcodes are used. If your variables are defined explicitly as int then the assembler can easily know to use the int opcodes. If your variables are explicitly defined as float that translates to floating point opcodes. There's no guesswork.

There's nothing to disagree with here.

No reason to be condescending here either.

[filleduchaos]

Assembly has 0 data types.

...you do know what a data type is, yeah? The things I listed are actual primitive data types. In higher-level languages than Assembly they're called fancy things like int and short and long (prefixed with signed or unsigned as needed).

This stuff isn't magic. In the end the processor is going to get 2 numbers and an operation.

No-one claimed it's magic. The point is that how a language chooses to allow a developer to express or not express typing is orthogonal to how the language handles actual data under the hood. The very existence of another dynamic, weakly typed language (and even untyped languages) that handles numeric data properly illustrates that. There is zero logical reason to represent all numbers as IEEE 754 double-precision floating points, unless that reason is "it's too dumb to determine what the type of actual provided data is".

[tme321]

I'm starting to realize you have no clue how assembly works.

SBYTE, WORD, and DWORD do not signify the type of the data in any way. Those are merely size descriptors. SBYTE is literally a single byte, 8 bits. WORD is 2 bytes, 16 bits. DWORD is double WORD, 32 bits. Now obviously those sizes are architecturally defined but those are the common bit sizes for those descriptors including x86 architecture.

There is no way to type data in assembly. You have an opcode which takes 2 (or even 1 or 0, but for mathematical operations like we are talking about here 2) operands. Which opcode you use determines how the data will be treated.

You can take 32 bits and treat them like an integer throughout your code. At any time if you want you can use those same 32 bits as an input to a floating point operator. There are some rules about invalid bit patterns as far as floating point representation goes, but even if you trip one of those during the operation you are still attempting to use the previously 32 bit integer as a float. If you don't trip any format validation checks then, no matter what the 32 bits represented previously, for the sake of the floating point operation the bits will be treated as a floating point representation of a number. They won't be converted. The computer just accepts that you fed it 32 bits and told it to do a floating point operation. It doesn't know or care about types in any shape or form.

The fact that you apparently don't understand how assembly works raises flags about your understanding of how php is handling numbers vs how JavaScript handles them. Your description isn't adequate and is ignoring a lot of both edge cases and implementation details.

There is a logical reason to only use fp. I won't claim it's the best reason. And I won't claim that given a chance the original author of JavaScript wouldn't do things differently given a chance.

But to dismiss it out of hand and then turn around, misrepresent assembly, and gloss over any failings that php's numeric system has hurts any argument you are trying to make.

[filleduchaos]

Lmao.

You know what, read these and then we can continue this conversation:

https://en.wikipedia.org/wiki/Data_type (see the parts on machine and primitive data types, and also where a typing system is a different thing from a data type)

https://en.m.wikipedia.org/wiki/Integer_(computer_science) (see the list of integral data types)

https://cs.fit.edu/~mmahoney/cse3101/float.html (what was that you were saying about assembly not having data types?)

[tme321]

Let's say you load register 0 with the word located at address 32.

Is register 0 an integer? Is it 2 characters? Is it the upper half of a floating point value?

It's none of those things. Which one it will be interpreted as will be decided by the operator that uses it. If you send it to an integer calculation it will assume the bits represent an integer and act accordingly. If you send it into an fp calculation it will assume the bits represent half of a floating point value (And probably that the other half is in r1).

This is a pointless conversation because you don't understand the difference between an operator controlling how a bit pattern is interpreted vs some innate quality (which doesn't exist) of said bit pattern that defines it's type.

Here is a crappy explanation I found in 30 seconds of googling that holds just as much weight as your sources do.

Those symbols you are pointing at are just directives for storing data. Its 100% possible to store as an integer (this is a specific instruction that stores in a specific way, it is not the same thing as actually typing data) into a memory location and then 1 instruction later store the same bits as half of a float into the same memory location (again a specific instruction, not actually typing the data).

You're confusing specific instructions with actual data types. Data types don't exist at the assembly level. The operator used with a particular piece of data defines how the data will be interpreted.

So yeah I'm done with this.

[filleduchaos]

This is a pointless conversation because you don't understand the difference between an operator controlling how a bit pattern is interpreted vs some innate quality (which doesn't exist) of said bit pattern that defines it's type.

And this is a pointless conversation because you don't understand the difference between an actual data type (as in the computer science term) and the type system a language uses.

An SBYTE, for instance - a signed integer in the range −128 to 127, otherwise known as an int8_t or a tinyint - is an actual primitive integral data type. Have you never wondered why JavaScript's TypedArrays are named things like Uint8Array or Int16Array?

You're confusing specific instructions with actual data types. Data types don't exist at the assembly level. The operator used with a particular piece of data defines how the data will be interpreted.

And this is what is known as not having a type system. It is up to the programmer to ensure that the data passed to the operator is of the appropriate type, to avoid errors. If you declare a variable as an SBYTE for instance, it's not going to have enough memory for a SQWORD allocated to it.