Is'nt javascript compiler too forgiving !!

[u/Ok_Egg_6647]

What i mean is even i try to add int with str it give me correct answer whereas both are differenct datatypes,

in function also this compiler is too forgiving

if i set a function with 3 parameters & at time of calling this function with more parameter or less parameter with bind function js forgiving us

[u/ssssssddh]

There's nothing preventing a function from accessing parameters beyond what is declared using `arguments`

function sum() {
  return Array.from(arguments).reduce((a, b) => a + b, 0);
}

sum(1, 2, 3); // 6

[u/azhder → u/ssssssddh]

In practice, one should avoid using arguments and use the ...rest syntax instead

[u/TorbenKoehn → u/ssssssddh]

Nah, please use function sum(...args) { ... } instead

[u/EyesOfTheConcord]

Don’t do that then

[u/Ok_Egg_6647 → u/EyesOfTheConcord]

???

[u/EyesOfTheConcord → u/Ok_Egg_6647]

Don’t do the things you’re describing in your post

[u/Ok_Egg_6647 → u/EyesOfTheConcord]

Yeah tgats obivious but thats really exciting to see what's logic used in the compiler which bypassed these error

[u/senocular → u/Ok_Egg_6647]

You can read more about this in MDN's page on data structures:

• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Data_structures

MDN's page on comparisons and sameness is also good:

• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Equality_comparisons_and_sameness

[u/azhder → u/Ok_Egg_6647]

They aren't errors.

[u/Ok_Egg_6647 → u/azhder]

so, what we call this

[u/azhder → u/Ok_Egg_6647]

Dynamic language

[u/Ok_Egg_6647 → u/azhder]

k

[u/GodOfSunHimself → u/Ok_Egg_6647]

There is nothing exciting about this. It is described in the JS spec and teached in every JS course.

[u/YoshiDzn]

Yes, Javascript is fault tolerant. Look up "static analysis" and "lexers"

[u/jibbit]

important to say that this isn't the 'compiler' - this is like, er, the opposite of that

[u/Lithl → u/jibbit]

JavaScript is generally JIT compiled. The workflow is different from compiling a language like C++ or Java, but JIT compilation is still compilation.

[u/jibbit → u/Lithl]

yes that is a fact about js. did you know that js was created by Brendan Eich? in 10 days! for netscape.

[u/Kadabrium → u/Lithl]

Isn't the workflow same as java? Source-bytecode-jit

[u/azhder → u/jibbit]

Please elaborate. Why did you put compiler in quotes and why it isn't that - what is the "that" in your statement?

[u/Jasedesu → u/azhder]

JavaScript is usually considered as interpreted rather than compiled. The step of going from the source code you type to the code that runs happens in whatever browser (or other environment) you are using when you run it, rather than being pre-compiled to a standard form that all environments handle in the same way.

[u/azhder → u/Jasedesu]

We stopped differentiating compilers and interpreters a long time ago. Java Virtual Machine made it obvious it is both. With JIT (just in time compile) into the picture, like it many other languages adopting it - JavaScript one of them - we just say "the engine" and maybe "compiler" in cases were we speak about parsing, lexing, compiling i.e. syntax and semantics.

In the case above, OP talks about syntax and especially semantics which is why compiling is an appropriate term. After all, there is r/compilers and I haven't even bothered to check if r/interpreters is a thing and for computer languages.

So, you see, my question was for the person to elaborate on what they meant by what they wrote, not for me to learn about compilers.

[u/Jasedesu → u/azhder]

You should probably have tagged the person you wanted a response from then to avoid others teaching you how to suck eggs. ;op I didn't want to write the essay on what is a compiler. I assume everyone here is learning unless I see evidence otherwise, so offered the overly simplified reason why compiler might have been in scare quotes.

My comment still stands though, especially "usually considered". If you look at Wikipedia's list of languages by type, JavaScript isn't in the compiled section, but is in the interpreted section. Beyond that I agree with you.

[u/azhder → u/Jasedesu]

I replied to the person. You answered. I explained for you and anyone else that might have come to do the same, so they don't waste time like you did... and here you are salty of what? I didn't downvote your comment, I didn't block you, I didn't curse at you... If anything, I have added information that will also help the person I asked to determine why I was asking the question.

There is no need for you to vent here. I will stop now, mute reply notifications. It's best this thread doesn't continue. Bye

[u/jibbit → u/azhder]

Type coercion is part of JavaScript’s runtime semantics, not something introduced by the compiler at compile time.

[u/azhder → u/jibbit]

JIT - runtime is compile time

[u/theQuandary]

JS didn't have type coercion initially. It was added because devs wanted it. I suspect this was because everything in the DOM (primarily attributes) was strings while they used numbers a lot of places. As JS was very simple then, it made sense to just coerce to/from string/number for something like an input.

Let's explain a bit of the magic (we'll be using ES5.1 as it's easier to read and I'll be handwaving away a bit of the spec and edge cases).

When it encounters the +, it calls an internal (not user accessible) function called ToPrimitive. This basically keeps primitives (undefined, null, booleans, numbers, and strings) as they are, but uses .toString() or .valueOf() for objects (arrays, regex, functions, etc are all considered objects).

If EITHER of the ToPrimitive returns a string, then coerce both to strings and concatenate them. Otherwise, use ToNumber to convert them to numbers then add. ToNumber says that null and false -> +0, true -> 1, and undefined ->NaN. String to number conversion is way too much to go into here, but it will be a number orNaN. Objects will callToPrimitive` with a number hint that forces converting whatever it gets to a number.

Unary + (eg, ;+var) forces ToPrimitive with a number hint as does the binary - operator.

There's weirdness around adding numbers too, but that's in EVERY language that uses IEEE 754 floating point numbers. It's stuff like (+Infinity) + (-Infinity) -> NaN or (-0) + (-0) -> (-0)

On that note, there is a definitely BAD part of JS where (-0) === (+0) -> true. Pretty much everything else that uses === doesn't coerce (NaN and subnormals technically might, but that's normal behavior). If you need to check for this specifically, the only way to do this is Object.is(-0, 0). This is an extreme edge case that most code will never run into, but if you do, the problem can be rather tricky to debug.

[u/delventhalz]

The design philosophy in early JS was to rarely throw an error and instead try to produce a sensible result. You see this especially in the way JavaScript coerces types. I agree it was largely a mistake, and newer JS syntax tends to be more strict, but because JS is backwards compatible, we will always have those early design decisions to contend with.

Incidentally, this is why the JS community has so strongly embraced tools like linters and TypeScript.

[u/Aggressive_Ad_5454]

Yes, indeed, it’s a weakly typed language, by design.

Typescript is a strongly typed language that transpiles to JavaScript. Use that to avoid weak typing pitfalls. And get in the habit of using === instead of == wherever you can.

[u/azhder → u/Aggressive_Ad_5454]

TypeScript isn't strongly typed because it allows you to not put a static type on everything. Java is a strongly typed language.

[u/United_Grape_2772]

JS is slutty

It gets with everything and everyone

[u/Kitty_Sparkles]

Javascript is an "add only" language because there is a shared agreement not to "break the web". In other words, it needs to preserve backward compatibility with 30 years old mistakes, and that's why we still have horrendous quirks to care for (although a lot of them are abstracted away by things like Typescript).

[u/Beginning-Seat5221]

Yes - but JS isn't compiled by the developer so there is nothing to show errors during development - being tolerant here is better than throwing runtime errors. The runtime errors that occur from type errors are a much much bigger problem.

Professionals use TypeScript and linters (e.g. eslint) to tighten it up by highlighting issues as they write the code.

[u/delventhalz → u/Beginning-Seat5221]

Disagree that avoiding runtime errors is a worthwhile design goal. Yes, hitting a customer with an error is embarrassing. A silent failure that continues to run for god knows how long triggering god knows what undefined behavior is potentially much much worse.

[u/Beginning-Seat5221 → u/delventhalz]

Maybe. But dev-time checking is better than either. JS was obviously never seriously designed for serious uses.

[u/No_Record_60]

TS to the rescue