31–40 of 82 posts
Horrible headline. Was relieved this wasn't about following the footsteps of the supposed New Zealand shooter.
Earlier quoted context omitted.
I would agree with this if C# didn't definitively show you can have a successful enterprise/"LTS" language that doesn't move at a glacial pace and spend several years doing little to nothing (pre Java 8) It's implemented features Java had just gotten much earlier, in much more useful forms (see: generics, lambdas) without them being "haphazard" about it. - To me tasteful is what C# did, breaking changes when needed,…
These C# issues arguably demonstrate haphazard additions that didn't align with good taste: * Too many overlapping concepts for referring to code by value and defining them inline: events, delegates, anonymous delegates, and lambdas. * Lambdas that generate magic types rather than slotting into SAM types. This works great for functional languages, sure, but doesn't fit well into a class-based OOP language. * `ref` an…
Nullable Reference Types (NRTs) is released, so it's important to talk about what exists in an LTS form today rather than something from a draft proposal.
Firstly, there's the surface-level stuff. Reference types can be explicitly be marked as `foo?` to indicate to the compiler that the type is nullable. Mismatches are warnings to ensure backwards compatibility, since billions of lines of perfectly valid code today can't just start emitting errors across an entire codebase.
But the far more interesting side of NRT isn't that, but the compiler analysis that goes into it. It's an incredibly advanced and thorough flow-based typing system that catches numerous complicated scenarios, and a system that can be (and is) improved over time without incurring a risk of a breaking change. This analysis is equally applied to the existing nullable value types, so it's a unified model.
The other interesting side of NRT is that isn't a one-and-done feature. There's a long rollout period where the .NET ecosystem adopts this way of dealing with reference types, and to do so there need to be tools for component authors and application developers to adopt it incrementally and at their own pace. Everything in the design is incredibly deliberate and well thought-out, with numerous past designs (such as a "sidecar" format for annotations and a mechanism for managing updates to that in parallel with a package or framework!). It is imperfect, but perhaps the best that can be done given the constraints a 20 year old language imposes.
That said, I really the world could be different. Since I prefer (and work on) a typed functional language where `null` isn't much of a problem due to a different core language design, the incredible amount of engineering effort that went into NRT for C# feels slightly strange to me. But my only reasonable alternative to not making progress on this problem is, "just use a different language", which most developers do not find reasonable.
Additionally, the pedantic side of me doesn't feel that Java's optional is an any way reminiscent of monadic programming. Java simply lacks numerous features to enable this style of programming in a way that the majority of Java developers would utilize.
While Java's slow and cautious evolution frustrates developers, it still arguably demonstrates longer-term thinking than the constant accrual of features in its contemporaries such as JavaScript and C#. That isn't to say the designers of JavaScript and C# don't think carefully about the addition of new features; indeed, was it Anders Heljsberg who made the point about all new proposed features starting with negative…
While that is interesting to hear, is there a single book that brings someone who hasn't used Java in the last 5 years upto speed, like the book Bjarne Stroustroup's 'A tour of c++' does for c++.
Earlier quoted context omitted.
I would agree with this if C# didn't definitively show you can have a successful enterprise/"LTS" language that doesn't move at a glacial pace and spend several years doing little to nothing (pre Java 8) It's implemented features Java had just gotten much earlier, in much more useful forms (see: generics, lambdas) without them being "haphazard" about it. - To me tasteful is what C# did, breaking changes when needed,…
These C# issues arguably demonstrate haphazard additions that didn't align with good taste: * Too many overlapping concepts for referring to code by value and defining them inline: events, delegates, anonymous delegates, and lambdas. * Lambdas that generate magic types rather than slotting into SAM types. This works great for functional languages, sure, but doesn't fit well into a class-based OOP language. * `ref` an…
Earlier quoted context omitted.
The .NET CLR (VM) has had proper generics and value types since 2002. Java did not implement generics until 2004 and to this day does not have user-defined value types. There was an opportunity to do it right in 2004 before this became "baked in". There is really no good excuse. Many developers have abandoned java due to the glacial progress with both the language and the VM. It is legacy now. The main benefit (IMO)…
Well, some companies still write many of their new projects in the Java language (not to mention use the Java platform), like Apple, Amazon, Alibaba, Google, Netflix, and, of course, banks, governments, airports, militaries, hospitals, utility companies, factories, robotic warehouses [1], and most Fortune 500 companies. [1]: https://www.infoq.com/presentations/java-robot-swarms/
Of course any language could be legacy in the future but historically the probability that one of those future legacies is a hot new language now is at least equal with that of an established language currently still widely used to write significant production software.
Earlier quoted context omitted.
I won't argue over particular features because clearly it's a matter of personal preference and, working on OpenJDK, I'm biased, but a couple of points: Since Java was introduced in 1995 until today, Microsoft's software framework has had about three or four drastic backward-incompatible "generations", depending how you count. Most Java code written in 1995 will run, with little or no change, on the current JDK 13, a…
>Since Java was introduced in 1995 until today, Microsoft's software framework has had about three or four drastic backward-incompatible "generations", depending how you count. Most Java code written in 1995 will run, with little or no change, on the current JDK 13, and would compile on JDK 13 with only minor changes. That's exactly what's wrong with Java. That's why we got "functional interfaces" instead of proper l…
To the point that in 2016 I got a couple of RFP to port from C# into Java for UNIX portability, in spite of .NET Core also being an option already.
Their reasoning being that with Java it would be a safer bet, while they couldn't be sure if .NET Core would ever be the last rewrite.
While Java's slow and cautious evolution frustrates developers, it still arguably demonstrates longer-term thinking than the constant accrual of features in its contemporaries such as JavaScript and C#. That isn't to say the designers of JavaScript and C# don't think carefully about the addition of new features; indeed, was it Anders Heljsberg who made the point about all new proposed features starting with negative…
Wait, why do we care about the JVM?? This whole article appears to address concerns that, while fundamental to programming, are also fundamentally irrelevant to shipping products.
Earlier quoted context omitted.
I think it might actually end up the other way around. For example, primitives are going to be able to have methods now. In the end, the numbers just aren't there for certain types of computations without them. And people have been complaining about them missing for years.
Also generic specialization-- which will allow generics over primitive types (and value types). That'd eliminate one major source of pain for performance-sensitive code (no more writing your own collection classes if you need to, for example, contain a bunch of ints).
Earlier quoted context omitted.
Well, some companies still write many of their new projects in the Java language (not to mention use the Java platform), like Apple, Amazon, Alibaba, Google, Netflix, and, of course, banks, governments, airports, militaries, hospitals, utility companies, factories, robotic warehouses [1], and most Fortune 500 companies. [1]: https://www.infoq.com/presentations/java-robot-swarms/
To make your comment more explicit: The parent states that Java is legacy now . But given your examples above that would mean that java and many other languages are legacy now. Of course any language could be legacy in the future but historically the probability that one of those future legacies is a hot new language now is at least equal with that of an established language currently still widely used to write signi…