61–70 of 168 posts
Earlier quoted context omitted.
Well, think of it this way. A seat belt cannot help you at all if an object flies through your windshield. Nevertheless, driving while wearing a seat belt is, overall, safer than driving without one.
This is HN, we don't need seat belt analogies. Very strict type systems forbid this class of errors during compilation, others do a best effort and fail at runtime.
From the examples: "String s = gridWrapper.get(0).get(0).get(0);" - Java type system is broken! Java is not perfect, but this looks to me like a broken code indeed ".get(0).get(0).get(0)". Could we rephrase the message of the article as "If you write really broken code in Java, you might be not guarded by the type system". And this is, well, uhm, well... acceptable?
> Could we rephrase the message of the article as "If you write really broken code in Java, you might be not guarded by the type system" The very idea of the type system is that it makes "broken code" of a certain type a compile error.
It’s pretty tragic how people respond to such criticism emotionally, instead of acknowledging the issues and working towards fixing them or educating others in the traps and compromises involved. HN is less prone to toxicity, but this is reminiscent of Reddit and it drives away the people that want to help. As a piece of advice, some type theory never harmed anyone ;-)
To apply a formal method to your work requires to acknowledge that your intuition might me wrong, your past decisions incorrect, and your knowledge of the subject area deficient. Often you have to step back, rethink, and rework.
This is a normal mindset for a scientist, and a pretty common mindset for an experienced engineer.
But this view is not automatically acquired with an engineering diploma, with obvious coding skills, or even with a couple successful open-source projects. It has to be nurtured consciously—or rammed down your throat by unforgiving reality; the latter is pretty traumatic.
Earlier quoted context omitted.
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.
Did C# really break backwards compatibility of their bytecode? What I understand is that C# generic and non generic APIs are completely different, and are not inter operable.
In Java's case, old bytecode using Map would correctly work with change to Map . C# introduced a new set of collections I believe.
> Everything is broken. Everything is fine. This is the correct conclusion. The people getting outraged over this are the same that will hold long and boring monologues about how everybody does REST wrong.
> Everything is broken. Everything is fine. This is the correct conclusion. The people getting outraged over this are the same that will hold long and boring monologues about how everybody does REST wrong.
Had a client just last month that were doing SOAP wrong somehow... Required a SOAP message, that contained no XML after the message tag, but instead the entire message body was to be a JSON, and responded with a JSON if something was wrong, and a fully formed SOAP message if things were Ok. That and the guys that handle your money use the Http status code as their personal error messages. Except when the error is on…
Earlier quoted context omitted.
> Could we rephrase the message of the article as "If you write really broken code in Java, you might be not guarded by the type system" The very idea of the type system is that it makes "broken code" of a certain type a compile error.
For certain and specific definitions of "broken code".
My favourite feature of Java's type system is that, because any object type also accepts null, the type system is unsound and you can convert anything to anything else: https://raw.githubusercontent.com/namin/unsound/master/doc/u...
It should be noted that soundness is not a common feature for type systems in the wild. It sounds kind of scary, "X programming language's type system is unsound", but that's pretty much been the status quo for most of programming.
Earlier quoted context omitted.
"Is X really worth it if it isn't perfect and doesn't cover every edge case?" I kinda feel like humanity has repeatedly decided the answer to this question is "yes". "Being valuable" isn't binary. There are relative amounts of value, I think.
Being valuable isn't binary, but you shouldn't stop in the middle if it's possible to do better easily.
Saying things like "do better easily" makes sense in the context of fixing something that's broken.
But for anyone who just sees it just as a limitation this comes off as presumptuous. What do you want to change? How do you want to overcome the limitation? At what cost?
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.
And conceivably a good deal faster, too. My understanding is that the JVM is required to constantly perform runtime type checks.