Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> JavaScript is a weakly typed language without much type safety

This is a little inaccurate. JavaScript is dynamically typed. Values carry strong, unforgeable type information (tags), though tags for numbers are extremely cheap and optimized away whenever possible. It is not possible that JavaScript "forgets" that 1.0 is a number and allows a program to use it as a "pointer".



Strong and weak are ill-defined, but JS is generally considered weakly typed. It's about how the language treats the results of expressions on mixed types and whether it permits implicit conversions or not. Contrast with Python, which is also dynamically typed but is strongly typed (by default, you could add in your own operations to weaken these runtime type checks).

JavaScript: https://tio.run/##bdBBCoMwEIXhfU4xuNFG01C6K3iYF2tLixhREXr6NJ...

Python: https://tio.run/##K6gsycjPM/7/P1HBVkHdUJ0rCUgbc3EVFGXmlWgkKm...

Few languages are truly strongly typed (zero implicit conversions, numeric operations commonly allow them without requiring explicit casts) so it's really more of a spectrum. How much does a language allow in comparison to other languages.


Most of the well thought out writeups on types that I've seen put them on two different scales

- Strong vs Weak - how does the language convert between types

- Static vs Dynamic - Does type information apply "early" or "late" (not sure what the right term here, but generally "when it's compiled" vs "when it's run"). I've also seen this as whether the type information is applied to the variable (name of/thing that points at the value) or the value itself; which tends to work out to the same thing.

Which is, I think, more or less saying here. Just with more words.


Re: conversion between types

Most languages can be placed somewhere on a strong-weak spectrum, but JavaScript is an outlier. Two "equal" values can implicitly convert to opposite boolean values, or different numeric values, or different string values. Not just weak... maybe pathological is a better term.


In static languages, variables have types. In dynamic languages, values have types.


I think this is referring to JS's unfortunate habit of doing nonsensical things with types unless the user takes special precautions.

For years I thought I needed explicit static typing, until I tried Python, which is also dynamically typed, and found that I had none of the problems I had in JS. This is because Python is strongly typed.

Indeed Python has the opposite problem of being a bit too pedantic with the type conversions. I thought it was interesting that C#, which is also strongly typed, lets you do string + number. (IIRC it has something to do with how they both descend from Object...)

Worth mentioning that I do think static typing is a very good idea in any nontrivial program, and I wish more languages forced the programmer to be explicit here — TypeScript and even Rust have both bitten me in the ass with the type system making incorrect assumptions instead of just asking me (i.e. forcing me to actually specify the program and eliminate guesswork).


> IIRC it has something to do with how they both descend from Object...

It's far less interesting than that. The truth is that the symbol + means a wide variety of different things in the language, and it uses compile-time type information to select exactly which of those things it means. In the case where either operand is a string, it means string concatenation, with string conversion for a non-string operand if one exists.

That specific conversion part is the only thing that cares that stuff descends from Object. The conversion algorithm is "call ToString() and let dynamic dispatch sort it out."

(For completeness, the other meanings are various forms of addition, but adding two doubles is a different machine instruction than adding two floats. It really does still need to use type information to figure out which of those operations it is.)


Static typing provides different benefits to strong typing. Both are useful in their own ways. And both can get in the way (and not be worth it) in some cases.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: