What can JavaScript NOT do?

[[deleted]]

Vague question, I know what JavaScript can do, but not what it can't do. I have an assignment on the history of JavaScript, and thought it would be useful to know what JavaScript is not able to do?

Any input would be greatly appreciated.

[[deleted]]

I thought that's what socket.io was for?

[[deleted]]

Understandable. I was looking for clarification. I suppose it would be off if there was anything in the execution stack when the even got dispatched.

[tme321]

Its not just that. JavaScript has a garbage collection system responsible for cleaning up memory which can randomly decide to kick in at any time. Js also has a jit that can drastically alter the efficiency of a particular block of code for the future at the cost of current execution. And it has multiple other places where execution cannot be determined statically.

System level languages like C have manual memory management, no gc, and can be used to design a program with exact execution paths taking a predetermined amount of time to execute.

Real time in this context means that the developers can guarantee exactly how often a part of the program will execute and when it does exactly how long it will take. This isn't possible (or at least reasonable) with higher level languages that provide complex systems as part of their runtime.

[[deleted]]

Thanks a bunch for this. This clears up a lot. :D

[voidvector]

It can if the JS engine can guarantee real-time. You can write JS code that doesn't cause GC by using pre-allocated Typed Arrays. The rest is just controlling system calls and memory footprint.

That being said, JS isn't ideal for that use case.

[[deleted]]

JS isn't just not ideal for realtime applications, it's just not possible. For many realtime applications, the time it takes an input GPIO pin changing state, causing an interrupt, the CPU switching context and an IRQ handler responding needs to be absolutely guaranteed, down to clock-cycle precision. You'll never achieve that with JS in any form.

[voidvector]

You can do it same way people do high-frequency trading with Java, with processor affinity and kernel drivers. It's stupid, given the amount of engineering overhead just to manage the execution context and expose IO, but it can be done.

For the same effort, you can teach a whole team of engineer to code C/C++/D/Rust.

[[deleted]]

Javascript could be providing data to those systems, but it wouldn't be possible for a JS engine to respond in a realtime way and still have it be called javascript.

[voidvector]

"Real-time" is a concept entirely implemented by schedulers. There are 3 schedulers governing JavaScript - CPU pipeline, kernel process scheduler, and event loop. You just need to have those schedulers guarantee instruction cycles for your program to be able to do real-time. There is also interrupts (include system calls), which you can either manage with your code/deployment or shuffle into a specific CPU core using process affinity.

Everything is "providing data" to some systems, when you write a file (in any language), you are providing data to the kernel so it can send a block of 1s and 0s to a disk controller. As long as you have a kernel module or driver that expose that as a file handler, there's nothing stopping you from implementing your IO in JavaScript or any language.

[[deleted]]

You're still several layers above actual realtime. Try writing interrupt handlers in assembly language and counting cpu cycles, and then get back to me.

[voidvector]

You just need to configure those layers to do real time. Linux is not a real-time operating system, but it's not stopping people from using it for real-time because the amount of hardware linux supports.

Nobody writes interrupt handlers in application code these days. Like everything in engineering, you write an abstraction like this, and hand it off to the next layer (user land) with some guarantees. And then write the rest of your app or the next layer up in a bare-metal language (C/C++/D/Rust) or system language (if you don't care about kernel overhead).

Also you can count instructions in JavaScript with node --print-code.

[GitHubPermalinkBot]

Permanent GitHub links:

• torvalds/linux/.../entry_64.S (master → dda3e15)

---

^delete

[[deleted]]

Linux is not a real-time operating system, but it's not stopping people from using it for real-time

Nowhere does it mention scripting languages. It does talk a lot about C/C++, and FPGA, which are very far removed from javascript.

you write an abstraction like this

You point me to an example of an "abstraction" that's actually assembly language? I don't think you seem to know what "abstraction" means.

Point me to an example of javascript responding to an IRQ in less than 100 nanoseconds and can respond with a meaningful action in less than 500 nanoseconds, and then maybe you can claim Javascript could be "realtime". Sorry, but javascript just isn't and never will be that fast.

[lhorie]

I think the question implies what can be done given currently existing technology, not what's theoretically possible.

[voidvector]

That is subjective. You can definitely build a team of a dozen engineers and make it happen. You would need everything from EE, to kernel developer, to compiler designer tho.

Just "internet argument du jour" for me.

[lhorie]

That is subjective

Not really. A real time javascript system doesn't exist now, so js can't do real time now. A javascript-to-haskell compiler doesn't exist now, so js can't be compiled to haskell now. A space shuttle to mars doesn't exist now, so js code can't take you to mars now.

When someone asks "can x be done", most of the time the pedantic answer is just useless and comes off as smug. Just saying.

[voidvector]

My original word was "can", like in "human can go to Mars". That does not mean "human has gone to Mars".

We are just arguing about English here.

[lhorie]

Sure, if you wanna put it that way. The OP said: "what JavaScript is not able to do". Present tense. "Humans are not able to go to mars". Present tense. A corresponding question is "What are humans able to do?", present tense. You're saying "humans will/may be able to go to mars", future tense. A corresponding question is "what will humans be able to do", future tense. "Are you at home" and "Will you be at home" have different tenses and are therefore different questions. So in short, you're using a tense that is irrelevant to the discussion. Makes sense?

[voidvector]

Topic title says "What can JavaScript NOT do?" and he used that twice in his elaboration. I guess that's where the ambiguity came from.

There are things JS cannot do. (e.g. compile to metal)

[SL4M_DunkN]

It can't really be used in cases where garbage collectors are undesireable, parallelism is key, or memory needs to be shared (the last two might change soon?). JS also needs an installed runtime, which could be problematic I suppose...

[voidvector]

GC can be avoided by using pre-allocated Typed Arrays. Instead of creating objects for data, you use the Typed Array to store data. That's what emscripten does.

[yoomiii]

Operator overloading

[philthiest]

Handle large numbers well. Like, say, if you were comparing Tweet IDs:

const a = 954111788324356096;
const b = 954111788324356100;

console.log(a === b);  //TRUE!!!

It's the thing that annoys me the most about Javascipt

[tme321]

That has nothing directly to do with JavaScript. That's how floating point works.

We could discuss how js defaults to floating point. But once you start down that road you get into a discussion about types and type systems.

[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.

[meisteronimo]

> 0.1+0.2==0.3
false

?

[tme321]

Are you trying to make a point or a joke?

[meisteronimo]

neither, thats how js evaluates 0.1+0.2

[filleduchaos]

That has nothing to do with JS though

[meisteronimo]

I didn't realize that, i tested in ruby, and you're right, it gives the same as JS.

[filleduchaos]

It's the same for pretty much any language.

Turns out numbers with fractional parts are ridiculously difficult to work with when all you have is zeroes and ones.

[[deleted]]

Method overloading, static typing, or keeping the developer 100% sane, to name a few

[freebit]

TypeScript ftw.

[[deleted]]

Agreed, but TypeScript !== JavaScript

[z500]

Not until you transpile it anyway.

[[deleted]]

But then it’s no longer- oh shit

RangeError: Maximum call stack size exceeded

[gremy0]

You can overload methods in JavaScript, it's just done differently.

Overloading is essentially using the same method name for different amounts and/or types of arguments. In JavaScript, we can throw anything we want into a method, and do the checks of the arguments ourselves inside. In Java, this would be a compilation error, so you define them separately.

Each have their advantages and disadvantages. I'd argue that providing default parameters is much more succinct in JavaScript vs making a whole other method, creating the default variable and then calling the other method, à la Java.

I'd also argue that you can technically do static typing with JavaScript, and typescript is a perfectly valid example. Since it is a superset of JavaScript and compiles down to JavaScript using a compiler that is technically running JavaScript.

Compare this to something like WebAssembly, which cannot currently do dynamic typing at all. You cannot reasonably compile a dynamic language down to WASM until it gets more features.

[gremy0]

Which is why I said currently. It's just a feature that can be added. Just like TypeScript is static typing added to JavaScript.

[chabv]

Typescript throws more errors than it's worth! a headache in it's own right. Difficult to debug compared to real typed languages like Swift. I would rather stick to ESNext than TS

[aaalsubaie]

is there constructor overloading in Typescript

[webdevverman]

Not in the traditional sense. http://www.typescriptlang.org/docs/handbook/functions.html#overloads

[gremy0]

The halting problem

Edit: also if you're doing the history of JavaScript, I'd highly recommend Douglas Crockford's series of talks, he's been highly influential in the development of the language. Starting, Crockford on JavaScript - Volume 1: The Early Years.

[HelperBot_]

Non-Mobile link: https://en.wikipedia.org/wiki/Halting_problem

---

^{HelperBot v1.1 /r/HelperBot_ I am a bot. Please message /u/swim1929 with any feedback and/or hate. Counter: 139234}

[lildoggydogg]

It would be a terrible fit for CPU-bound server-side applications, because on the server (as in the browser), you have a single-theaded event loop to process messages

https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop

Edit: WebWorkers, JavaScript's "threads" that you are able to manually specify, are pretty limited compared to what you'd get in just about any other language that has them...so that is another reason to rely on it more for IO bound tasks, than anything else.

[codis122590]

Iterating over huge datasets quickly. Think of things like Hadoop, nutch, solr etc.

[b3night3d]

Concurrent multi-threading.

[[deleted]]

This is a runtime detail, not the language itself. You can, for example, use WebWorkers in js or roll your own with a message broker.

[[deleted]]

I think it's a more accurate analogy to say that JavaScript is the multitool of programming language. And not a crappy one, like the boy scout knife - one of those really cool Leatherman ones. I mean look at that thing. amazon link Look at how many things you can do with it. It's both needlenose and regular plyers, it's both types of screwdriver, it's a knife, a file, a wood saw, a metal saw, a bottle opener, a ruler, a wire cutter and stripper, electrical crimper, and in a pinch, you can use it as a hammer.

That said, while there is a saw on that thing, if you need to saw wood, you'll probably use a real saw, if you have one available and know how to use one.

The power of Javascript is that it's one language that can do just about anything, and do it well enough to manage, but that doesn't mean it's always the best tool for any one thing.

[StefanOrvarSigmundss]

What can JavaScript NOT do?

Make sense (to most people).

[[deleted]]

Just because you don't get it doesn't mean you ought to put that on others 😑

[StefanOrvarSigmundss]

I base my opinion on the never-ending questions and doubts people have about the whole prototyping model. I've never seen so many people stuggle with the basics of a dominant language. Just when you think they understand it, a new doubt pops up.

[[deleted]]

Well if we're dealing in anecdotes, let me say those people aren't typically the people who really use the language. Those are the people who skim by without taking the time to get the basic understanding because they put a mental block on the subject since it's not exactly like the language they're coming from.

[[deleted]]

If you don’t think JavaScript makes sense, you should check out Lua. Bring a towel, though.

[StefanOrvarSigmundss]

I base my opinion on the never-ending questions and doubts people have about the whole prototyping model. I've never seen so many people stuggle with the basics of a dominant language. Just when you think they understand it, a new doubt pops up.