191–200 of 358 posts
Does java have a decent story on value types now e.g can I make an ArrayList and trust that it’s one array of longs on the heap and not an array of pointers to Longs? This was what made me ragequit Java 10 years ago.
Does java have a decent story on value types now e.g can I make an ArrayList and trust that it’s one array of longs on the heap and not an array of pointers to Longs? This was what made me ragequit Java 10 years ago.
Glad to see Java improve, but I still would like to see more ML features: - ~Exhaustive pattern matching~ it’s here! - Algebraic data types - Tail call optimisation - Do notation - Operator overload Why not use another language? Well, the name “Java” guarantees buy-in at this point. Maybe it will eventually be a Trojan horse for ML :)
I somewhat suspect Java is locked into its current approach to variance, but gosh, I much prefer Scala's approach here.
I imagine there's a reason it's necessary, but it's weird that "sealed" is basically "final" with the ability to do "permits" instead of just adding "permits" as a keyword that can be put on "final" classes
Earlier quoted context omitted.
Hmm yes I guess you might be right given Android. It's a shame in a way that Kotlin was invented as Scala could have filled the niche too imho but that ship has sailed. It's too similar to both Java and Scala and doesn't really bring anything new to the table. Is that fair or does it have a great USP other than massive Google backing?
I don't think Scala ever could have filled that niche, I say this as someone that wanted Scala to be successful. The truth of it is that Kotlin is incredibly easy to learn, even for non-Java devs. It is definitely focused on a very low barrier to entry. I don't think this was an original goal but it's become a significant focus of the language especially after being selected to be the next platform language for Andro…
That's not my truth.
I tried it, after not doing "real" programming for a while, and found it the most obfuscated, incomprehensible language I've ever run into. What new concepts are there in Kotlin that justify it?
"Expressiveness" sounds toxic to me - along the lines of "facilitates a personal idiom that makes your code impossible to understand and you irreplaceable".
After several days trying to do the simplest form of asynchronous processing in an "hello world" Android app, I switched back to Java, and everything made sense again.
I also wrote a small program in C# and that too was just as easy as I recall from ~10 years ago.
The “keep readability in mind” tip exposes more Java/OOP icebergs. var date = LocalDate.parse("2019-08-13"); var dayOfWeek = date.getDayOfWeek(); var dayOfMonth = date.getDayOfMonth(); > The first one is pretty intuitive, the parse method returns a LocalDate object. However, for the next two, you should be a little bit more familiar with the API: dayOfWeek returns a java.time.DayOfWeek, while dayOfMonth simply return…
Because dates are actually complicated, and so is the real world. You may be content in having just an int to display Sun 24-10-2021 to your users, but there are needs to get the actual weekday. From locale differences (US has the start of week on Sunday, most of the world on Monday), to locale differences (Country X nuked 43 days on year Y, your basic algorithm doesn't handle that because it's not working with tz-da…
My big assumption is that if a system cares about global timestamps, it should go all the way. If you have a “canonical system timestamp,” which I think is necessary, then you can operate on it functionally to get whatever local display that you need out of it. Your example with Country X means that dayOfWeek() AND dayOfMonth() are already both broken unless/until the language itself makes an emergency update to account for the change.
With dayOfMonth() I could substitute another function that handles the change. With dayOfWeek() I’d have to override the whole class, if possible.
I have seen this in action. A company I worked for was stuck with using outdated time libraries in Java because of IBM WebSphere (1.7? 1.8?). Those didn’t match the more recent libraries in Javascript (moment.js) and the differences caused significant problems, since the same locale keys had different time offsets.
Earlier quoted context omitted.
Yeah I think most Java devs are a bit in awe of Clojure, just not sure about the leap needed to get there.
Anyone who values static typing will never be in awe of Clojure. Or any dynamically typed language, for that matter. And Java developers care a lot about static typing.
With the amount of reflection and annotation-based magic I've seen in the ecosystem, I'm not sure I actually believe this? Maybe it's just lack of exposure, but most of the Java devs I've met seem very happy to undercut the type system whenever it's convenient.
Earlier quoted context omitted.
>Why does DayOfWeek have a class instead... B/c in most of the world, the 1st day of the week is Monday, unlike the US where it happens to be Sunday. Having it enum is a pretty decent choice.
Sure, someone’s got to make a numbering choice somewhere for the canonical value. Same thing goes for timestamps, and we settled on UTC, so all offsets can be calculated given that. Once you know that “Java says X is the first day of the week,” you can make your own calculations from it with modulo arithmetic. There is no need for a class here, or for it to build a whole subsystem of locale interpretations. That shou…
The basic assumption when designing anything is that you can never rely on assuming that other humans "will" know.
Unfortunately it looks like Java is going to evolve enough to take the wind out of the sails of Kotlin and Scala for most dev shops. I guess the positive take is that those improvements might not have happened without the efforts to develop better JVM languages.
A lisp-er would probably say that CL is so malleable that it hasn't needed to change, but I'm not so sure about that.
Earlier quoted context omitted.
Because dates are actually complicated, and so is the real world. You may be content in having just an int to display Sun 24-10-2021 to your users, but there are needs to get the actual weekday. From locale differences (US has the start of week on Sunday, most of the world on Monday), to locale differences (Country X nuked 43 days on year Y, your basic algorithm doesn't handle that because it's not working with tz-da…
Yeah. See my reply to your sibling comment: timestamps suck and it was maybe a foolhardy example that I’m not competent enough to defend. Here goes me trying to make my case anyway! =) My big assumption is that if a system cares about global timestamps, it should go all the way. If you have a “canonical system timestamp,” which I think is necessary, then you can operate on it functionally to get whatever local displa…