161–168 of 168 posts
Earlier quoted context omitted.
That's incorrect. It would have been possible to implement reified generics while preserving backward compatibility, Neal Gafter had actually a proposal to do just that. In the end, erasure won simply because it's the superior solution.
Erasure is superior to a system that would be typesafe? Please elaborate.
Earlier quoted context omitted.
That's incorrect. It would have been possible to implement reified generics while preserving backward compatibility, Neal Gafter had actually a proposal to do just that. In the end, erasure won simply because it's the superior solution.
Erasure is superior to a system that would be typesafe? Please elaborate.
Erasure gives you a little less flexibility to express certain constructs than reification allows, but from a type safety standpoint, the two approaches are equivalent.
If you want widen the meaning of "type safe" a bit, I would argue that reification is "less" type safe in the sense that it allows you to perform additional runtime type checks / type casts, which basically means you are second guessing the compiler and invalidating all the type soundness that it has provided you by accepting to compile your code.
Earlier quoted context omitted.
Erasure is superior to a system that would be typesafe? Please elaborate.
Erasure is just as type safe as reification. Erasure gives you a little less flexibility to express certain constructs than reification allows, but from a type safety standpoint, the two approaches are equivalent. If you want widen the meaning of "type safe" a bit, I would argue that reification is "less" type safe in the sense that it allows you to perform additional runtime type checks / type casts, which basically…
Earlier quoted context omitted.
I prefer my type errors at compile time. You have to reason about types in any language because passing the wrong type to a function can result in errors. You have to do all of that mental work by yourself in a dynamic language because there isn't a system to do it for you.
There are tools roughly similar to C's "lint" that can warn you about suspicious-looking code. While compile-time checking can be nice, compiler-oriented languages often result in more verbose code. Verbosity introduces errors also. But the benefit weighing also depends on the kind of applications. I didn't mean to trigger a "holy war" of static versus dynamic languages.
The purpose of types is to introduce errors in the first place - at compile time, if you messed up.
Wrong code causes errors regardless. Annotating with types just moves this event from runtime to compile time.
Earlier quoted context omitted.
There are tools roughly similar to C's "lint" that can warn you about suspicious-looking code. While compile-time checking can be nice, compiler-oriented languages often result in more verbose code. Verbosity introduces errors also. But the benefit weighing also depends on the kind of applications. I didn't mean to trigger a "holy war" of static versus dynamic languages.
> Verbosity introduces errors also. The purpose of types is to introduce errors in the first place - at compile time, if you messed up. Wrong code causes errors regardless. Annotating with types just moves this event from runtime to compile time.
Earlier quoted context omitted.
> And this is, well, uhm, well... acceptable? It is not. The only purpose of a type system is to prevent broken code from compiling. When it fails to do so, it is broken.
Typescript with its explicitly unsound type system show that a "broken" type system is immensely valuable, especially when you get something in return for that [1] [1]: https://www.typescriptlang.org/docs/handbook/type-compatibil...
The mess that is the current Java type system makes me skeptical when proponents of languages like Go say not to worry, that generics can be added later. If Java had generics in the beginning, it would look a lot different and the type system would be more powerful and safe.
Unlike Java, Go doesn't have to worry about bytecode backwards compatibility. That was the main issue that had them reaching for type erasure. Take a look at C# which added it without many issues (because they were willing to break back compat of their bytecode). Go fits this model a whole lot better.
I was thinking of more fundamental changes to Java idiom and the standard library had generics been part of the design (e.g., how arrays work).