3 ms·

> Code as concise as javascript, with inheritance and typesafety and more Extremely minor potential nitpick: correct me if I'm wrong, but I think this sentence

by tines 12y ago

> Code as concise as javascript, with inheritance and typesafety and more Extremely minor potential nitpick: correct me if I'm wrong, but I think this sentence implies that Javascript is not type-safe, when it is indeed type-safe; it's just dynamically typed, and its type system gives meaning to all expressions (where that meaning is to signal an error in some cases).

RussianCow 12y ago
Having types does not imply type safety. I think you're confusing "type safe" and "typed".
- vezzy-fnord 12y ago
  The terms are evidently murky: http://www.pl-enthusiast.net/2014/08/05/type-safety/#comment-500 http://www.pl-enthusiast.net/2014/08/05/type-safety/#comment...
developer-mike 12y ago
Correct, there is runtime typesafety in javascript. However, type-safety is a spectrum; truthiness and falsiness for instance is not very typesafe. I will revise this to be clearer (your nitpick is valid) but I think the heart of the issue is still 100% correct.
gliptic 12y ago
I wouldn't call JavaScript type-safe by any type-theoretic definition. It allows operations that really make no sense for the types involved ([]+{} ??).
- tines 12y ago
  I think that whether the semantics of the language make sense to a particular person isn't really the criterion for type-safety. The language does define what should happen in the case of the expression ([]+{}), so no violation of the type system occurs and the behaviour of the program is well defined.
  - grey-area 12y ago
    More examples of js insanity here (1:20): https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat How about {} + [], is that deliberately zero, and why is addition not commutative in this case if it is allowed? Or {} + {}? I think most people would infer type safety to mean that attempts to coerce types which are meaningless result in an error, not meaningless output, like the result of "string" - 1, or {} + "string" or {} + []. Otherwise your type system isn't going to stop you doing something insane by mistake, and is therefore not adding any safety. {} + "string" or similar just shouldn't be allowed, and in most languages (let alone type safe ones), it is not.
_random_ 12y ago
JS is type-safe in a way that is not useful in any way.
iopq 12y ago
That's true for everything by your definition. "But wait a minute, Assembly is not type safe!" But yes it is, just every type is a binary number. It's not Assembly's fault that you're trying to use binary numbers to print characters to the screen or point to regions of memory and somehow get the two mixed up.
ahoge 12y ago
http://en.wikipedia.org/wiki/Type_safety http://en.wikipedia.org/wiki/Type_safety Aggressive type coercion is not type safety. It does not prevent type errors. It just sweeps them under the rug. 5 - 'foo' That's a type error. It's not a convenient shortcut for `NaN`.
zak_mc_kracken 12y ago
A language that allows var a = 1; a = "foo"; is not type safe.

by tines 12y ago

RussianCow 12y ago

Having types does not imply type safety. I think you're confusing "type safe" and "typed".

vezzy-fnord 12y ago
The terms are evidently murky: http://www.pl-enthusiast.net/2014/08/05/type-safety/#comment-500 http://www.pl-enthusiast.net/2014/08/05/type-safety/#comment...

developer-mike 12y ago

Correct, there is runtime typesafety in javascript. However, type-safety is a spectrum; truthiness and falsiness for instance is not very typesafe. I will revise this to be clearer (your nitpick is valid) but I think the heart of the issue is still 100% correct.

gliptic 12y ago

I wouldn't call JavaScript type-safe by any type-theoretic definition. It allows operations that really make no sense for the types involved ([]+{} ??).

tines 12y ago
I think that whether the semantics of the language make sense to a particular person isn't really the criterion for type-safety. The language does define what should happen in the case of the expression ([]+{}), so no violation of the type system occurs and the behaviour of the program is well defined.
- grey-area 12y ago
  More examples of js insanity here (1:20): https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat How about {} + [], is that deliberately zero, and why is addition not commutative in this case if it is allowed? Or {} + {}? I think most people would infer type safety to mean that attempts to coerce types which are meaningless result in an error, not meaningless output, like the result of "string" - 1, or {} + "string" or {} + []. Otherwise your type system isn't going to stop you doing something insane by mistake, and is therefore not adding any safety. {} + "string" or similar just shouldn't be allowed, and in most languages (let alone type safe ones), it is not.

_random_ 12y ago

JS is type-safe in a way that is not useful in any way.

iopq 12y ago

That's true for everything by your definition. "But wait a minute, Assembly is not type safe!" But yes it is, just every type is a binary number. It's not Assembly's fault that you're trying to use binary numbers to print characters to the screen or point to regions of memory and somehow get the two mixed up.

ahoge 12y ago

http://en.wikipedia.org/wiki/Type_safety http://en.wikipedia.org/wiki/Type_safety Aggressive type coercion is not type safety. It does not prevent type errors. It just sweeps them under the rug. 5 - 'foo' That's a type error. It's not a convenient shortcut for `NaN`.

zak_mc_kracken 12y ago

A language that allows var a = 1; a = "foo"; is not type safe.