[HN Gopher] New language features since Java 8 to 17
___________________________________________________________________
New language features since Java 8 to 17
Author : dmitryminkovsky
Score : 264 points
Date : 2021-10-24 15:50 UTC (7 hours ago)
(HTM) web link (advancedweb.hu)
(TXT) w3m dump (advancedweb.hu)
| tomcam wrote:
| Fantastic article for a language-curious person who doesn't know
| Java well.
| filoeleven wrote:
| 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 returns an int.
|
| Java.time.dayOfWeek takes a TextStyle and a Locale, both of which
| have a list of properties and methods I have to read all about
| before using. dayOfMonth returns an int, and I can see if it's 0-
| or 1-indexed then do what I want with it from there. Why does
| DayOfWeek have a class instead of being a function that I can
| throw a number at like dayOfMonth?
|
| I'm also skeptical about Java.LocalDate being "pretty intuitive,"
| having worked on local vs server vs data-store timestamps, as
| most of us have. At least LocalDate doesn't have mutable setter
| methods like other Java dates...
| xxs wrote:
| >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.
| filoeleven wrote:
| 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
| should be the responsibility of a library. Maybe even the
| standard library, but it should not mask the core data values
| in the system by default.
|
| dayOfWeek(n) should be something that you apply to a value,
| not something that returns a value with no args based on your
| locale. Or, if it does, the function itself should accept an
| override locale instead of assuming it from a higher level.
|
| Timestamps are hard and maybe not the best example. It was
| what's in the article though, and I'm also pretty salty about
| them after some recent work stuff.
| jcelerier wrote:
| > Once you know that "Java says X is the first day of the
| week,"
|
| The basic assumption when designing _anything_ is that you
| can never rely on assuming that other humans "will" know.
| ohgodplsno wrote:
| 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-data, and
| it's broken now), to locale differences (how do you plan on
| displaying it? Short form? Translated?), to infinitely more
| date fuckeries that _have_ to be handled if you want your Date
| API to be credible.
| filoeleven wrote:
| 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
| 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.
| riwsky wrote:
| Why are you blaming a class called "LocalDate" for not
| giving you global timestamps? The java doc for the class
| has an entire paragraph on how it is not a time. If you
| want to model a specific instant in time, use Instant.
| popotamonga wrote:
| Still no property literals
| bobbyi wrote:
| 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
| Twisol wrote:
| I suspect it has something to do with classfile format
| backwards compatibility. From a pure syntax standpoint, I would
| agree with you, but there's probably some value to making a
| very clear separation for classfile loading.
| JulianMorrison wrote:
| It's good to see Java starting to waive a lot of the boilerplate.
| (And frustrating, when stuck on v8.)
| xxs wrote:
| A friendly advice: dont be afraid to use public final immutable
| fields and omit the getters (and setters since you cant have
| them w/ finals).
| JulianMorrison wrote:
| I do. It bothers me this wasn't the Java Way from day one.
| What is with getters and setters - who subclasses and
| substitutes the implementation of their data carrier objects?
| [deleted]
| xxs wrote:
| Initially java didn't favor getter and setters. They came
| with java 1.1 and the attempt bean model (and reflection)
| to catch visual language designers. The core java packages
| java.lang; java.util; java.io they dont feature
| getter/setters, either. If you look at the ancient AWT,
| there were not getter/setters - they were introduced with
| 1.1 and the bean stuff, most of the existing methods were
| deprecated.
|
| So in essence it was the original design, some book
| authors/design concept promoted it... Personally I have not
| written 'bean alike classes' for years.
| vips7L wrote:
| Probably should just use records and get all that for free.
| xxs wrote:
| JulianMorrison uses java8, no 'record' there. Not
| everything fits being a record, either way. The advice is
| sound for pretty much any class and development, use final
| fields in the c-tor; make them public if you have to, and
| dont bother w/ getters.
| r0f1 wrote:
| Is there something similar for Python? They are releasing new
| Python standards with a crazy fast speed. Would be really helpful
| for me.
| moffkalast wrote:
| It would sure be helpful if they took some effort to focus less
| on adding crazy new stuff every 2 days and instead on
| maintaining older versions for a change.
|
| Maintaining a python dependant system these days is an absolute
| nightmare, at least with C++ you know that new compilers will
| be backwards compatible, gah.
| afandian wrote:
| How does this feel with Python being dynamic? I always felt
| very uneasy writing Python precisely because if some random
| module became incompatible, especially via a transitive
| depndency, I might not find out until it was running in
| production.
| aldanor wrote:
| What's to be uneasy about? Lock your environments, pin your
| dependencies, _especially_ in production.
| moffkalast wrote:
| Until your LTS OS gets to end of life and you need to
| switch to the next one which conveniently deprecates old
| python versions so you have to rewrite everything.
| aldanor wrote:
| Why use system Python base environment for production
| stuff, especially knowing that it will EOL eventually and
| mayhem may follow? Again, pin your environments using
| conda, pipenv or whatever else, in which case your base
| Python version wouldn't matter.
| bradbeattie wrote:
| https://docs.python.org/3/whatsnew/index.html, each subpage of
| which has summary highlights.
| temporallobe wrote:
| I'm stuck on 8 and 11 in my current projects, so I haven't seen
| much of these in the field other than the new record feature.
| What I am really surprised about is the var construct. Honestly,
| this leaves me a little conflicted since it seems to be
| antithetical to the principles of a strongly-typed language. So
| does this now reclassify Java as a weakly- or dynamically-typed
| language? I would perhaps argue against it being dynamically-
| typed since by definition type inference happens at runtime, but
| it certainly leaves Java in a sort of limbo. I don't personally
| care, but I know at some point the topic will come up amongst my
| dev peers, at which point there will sure to be a (mostly
| friendly) debate.
| dunefox wrote:
| > seems to be antithetical to the principles of a strongly-
| typed language. So does this now reclassify Java as a weakly-
| or dynamically-typed language?
|
| Var and type inference are neither antithetical to static
| typing nor do they make a language dynamically typed. They're
| antithetical to the verboseness of Java.
| irl_chad wrote:
| We must have a "new features since Java 8" post every other day.
| pjmlp wrote:
| Because plenty of people judge Java by their pre-Java 8 frozen
| knowledge.
|
| At least it isn't yet another link to re-written in Rust
| headlines.
| junon wrote:
| I must be in the minority of thinking java 7 was the last
| great version of Java. What I see today is a nearly different
| language.
| Consultant32452 wrote:
| Honestly, I don't see anyone using any of the new features.
| Oddly enough I do get asked about them in interviews.
| shepherdjerred wrote:
| I use the new language features all of the time. Variable
| type conferencing with the var keyword is incredible. The
| new Java 11 module system allows me to write code more
| safely without accidentally crossing levels of
| abstraction. Java 17's text blocks are a really nice
| enhancement. Pattern matching with switch statements
| makes code a little more concise, and reduces the chance
| of forgetting to update switch statements when a new
| value to an enum is added. Record classes add immutable-
| by-default data structures which make packages like
| Lombok less necessary. Pattern matching with instanceof
| reduces verbosity and makes code feel a little more
| modern -- it feels more similar to writing Swift or Rust.
|
| I've used all of these features. They're all great.
| johnisgood wrote:
| This just makes me hate interviews even more. Why ask
| questions that are supposed to be looked up anyway, or
| once used, are known? I mean, certainly if you saw a new
| feature being used in a codebase at that workplace then
| you would be able to use it, too.
|
| I probably would not be able to answer it with regarding
| to Kotlin, for example, but I would certainly be able to
| notice (or at the very least look it up), understand, and
| use. Would it make me fail the interview?
| vbezhenar wrote:
| I liked Java 1.4. Generics were a mess. And Java before
| generics was so wonderfully simple. Yes, you had to cast,
| but that wasn't a big issue.
|
| My favourite language would be Java 1.4 with carefully
| redesigned standard library (because old standard library
| was not very nice).
| pharmakom wrote:
| Isn't that almost Go? Well, before Go generics land.
| pjmlp wrote:
| Indeed.
| manishsharan wrote:
| Whenever we read about new improvement in Java,it is always
| inevitably followed by concerns for viability of Kotlin or Scala.
| However these concerns are never applicable for Closure. I am
| glad I went all in on Clojure.
| The_Colonel wrote:
| It's not applicable, because Clojure already lost the momentum
| and sinks deeper and deeper into its niche.
| e40 wrote:
| Can you explain that for the Java noobs here, like me?
| dunefox wrote:
| Clojure has many functional features and properties that are
| unique to Lisps and functional languages and aren't shared by
| Java. Kotlin and Java are much more similar than either to
| Lisp, so when Java gets more modern features it might cut
| into Kotlins 'market share' since it makes it less powerful
| when compared to Java.
| nikanj wrote:
| Scala and Kotlin tried to be a better Java (i.e. Algol-esque
| syntax). Clojure tries to be a better Lisp, an entirely
| different family of language.
|
| Though a good flamewar can be had on 1) Is Scala closer to
| Pascal 2) Is Pascal Algol-descendant
| JulianMorrison wrote:
| Clojure tries to be an immutable-data, copy-on-write,
| threadsafe by default dialect of Lisp, which none of the
| other Lisps do.
| filoeleven wrote:
| It's not really copy-on-write though. That implies
| greater systemic performance losses than what Clojure
| provides, because it uses HAMTs (Hash Array Mapped Trie)
| internally. They enable much faster copies of immutable
| data than copy-on-write does.
|
| Your other points are good ones, I just don't want people
| to be put off by copy-on-write performance assumptions.
| You take a ~50% performance hit from choosing Clojure
| over Java, but the gains in dev speed, maintenance,
| robustness, and flexibility to changing requirements are
| supposed to outweigh that. Especially when you include
| simpler parallelization, which you covered with thread
| safety.
| JulianMorrison wrote:
| There was an issue I ran into with regular Java, JDOM 2
| Documents, One thing saves a reference, the other thing
| snips a piece out to use in the response... oops, the
| first reference points to a snipped Document. Worse, that
| behaviour changed without interface changes between JDOM
| 1 and 2, and it mattered to the code I was editing. Easy
| enough to fix with a ".clone()" but still... it's not
| just parallelisation. Immutable data would mean immutable
| to weird action at a distance like that. Thankfully the
| unit tests caught it before it could have gone live.
|
| (More precise issue... JDOM 1 lets you splice a piece of
| A into B while it still is part of A. JDOM 2 insists it
| be detached first. Detaching it removes it, and that
| removal can be seen through a reference.)
| filoeleven wrote:
| Huh. I don't know enough about JDOM to ask more than
| stupid questions, especially when we're talking about two
| different languages on the same VM. So please bear with
| me or ignore at your leisure.
|
| This all happened within Clojure? Their Java interop is
| reportedly good, but the docs also say you lose the
| immutability safeguards when you interact directly with
| Java classes. I dunno if "regular Java" means literally
| that, or while working with Java inside of Clojure. Which
| is it?
|
| "One thing saves a reference" - if this was interop, did
| you convert that to a Clojure data structure as early as
| possible, and do no more interop after that until a final
| return?
|
| I've avoided deep interop so far, so I don't understand
| the mechanics of the interface, and I'm not clear if your
| response is about that.
| sgt wrote:
| Yeah I think most Java devs are a bit in awe of Clojure, just
| not sure about the leap needed to get there.
| hota_mazi wrote:
| 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.
| Twisol wrote:
| > 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.
| Thaxll wrote:
| Isn't closure on its way out though, not like Perl level but
| going downhill? Kotlin on the other hand is raising.
| pjmlp wrote:
| Most of which unavailable on Android Java flavour, sorry Google's
| J++.
| hn_throwaway_99 wrote:
| If you're on Android I'd be programming in Kotlin in any case.
| evacchi wrote:
| Shameless plug: I recently wrote a blog post on Java 17's new
| features using the implementation of a tiny actor runtime as
| the running example. If you are interested you can find it
| here https://evacchi.github.io/java/records/jbang/2021/10/12/
| lear...
| evacchi wrote:
| Apparently I mistakenly posted this as a reply...
| pjmlp wrote:
| I rather do Android Java and C++ in what concerns my use
| cases.
|
| https://developer.android.com/games/agdk
| mabbo wrote:
| Is there a reason for that?
|
| I'd really love to get into android development, but I'm loathe
| to give up some of the nicer language features in Java. What
| version of Java is android supporting? At least 8, right?
| hota_mazi wrote:
| Java's supported version on Android is a moot point: all new
| Android development should be made in Kotlin.
| pjmlp wrote:
| Pity that Kotlin builds on Java ecosystem and uses that as
| selling point for adoption.
|
| Kotlin libraries on the JVM cannot take advantage of JVM
| ecosystem, and require KMM to be portable across runtimes,
| or be constrained to the Android Java flavour.
|
| It is like having a flavour of Typescript that only works
| on Edge.
| hota_mazi wrote:
| > Kotlin libraries on the JVM cannot take advantage of
| JVM ecosystem
|
| This makes literally no sense since Android apps are
| built using not just Gradle but actually the entire Maven
| Central repo that all Java apps use.
|
| Without any changes.
|
| If what you said was remotely close to accurate, Android
| would have its own Maven Central repo.
| pjmlp wrote:
| Many got sold on the idea that they adopted OpenJDK, but that
| is quite far from the truth, so in reality they cherry pick
| the features and standard library classes/methods that are
| somehow relevant to port key Java libraries into Android.
|
| Currently they support a Java 11 subset.
|
| You can track them on AOSP Gerrit commits.
|
| Apparently starting with Android 12 , ART can be updated via
| Play Store and they should provide better updates.
|
| Although there is also the question how they were naive to
| think Java would never require updates, or possibly related
| to the Oracle dispute, which anyway proves the point that
| they behave just like Microsoft did with J++.
| cageface wrote:
| 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.
| 5e92cb50239222b wrote:
| This happens all the time with "guest" languages. A few old
| salts have been prophesying this right here on HN since Kotlin
| first came out. I think it'll still be used on Android though,
| it's hard to see Google pushing Android development back to
| Java.
| leroman wrote:
| Scala still has a better design at its base, which is missing
| from Java and I don't see how Java can retro-fit it into the
| language, Immutability is a big part of being functional and
| doing safe multi-threading stuff, java is doing all the good
| syntactic stuff (case class, switches with guards etc) but
| without immutability it's a far cry from the same facility in
| Scala land. Having said that, this trend is welcome for every
| time I have to write Java and makes it feel more natural to me
| as an old time Scala developer.
| armchairhacker wrote:
| Kotlin is still way ahead of Java with IMO essential features
| like:
|
| - Explicit null
|
| - Extension methods
|
| - Getters/setters which use property syntax
|
| - == instead of Object.equals confusion
|
| Also Kotlin's this-scoping and delegated properties, while they
| take a while to get used to, can be incredibly useful. They
| make it possible for to write typesafe DSLs like kotlin-html.
|
| Moreover, Kotlin is usually very easy to integrate with
| existing Java projects. Setting up Kotlin in Gradle is just
| adding a plugin, and Kotlin automatically imports and exports
| java code. And it runs on the JVM so it will support most
| platforms that also support Java. And one of the top Java IDEs
| and contributors (JetBrains) maintains and prioritizes Kotlin.
| jmfldn wrote:
| This is great not unfortunate. If Java improves because of
| Scala and Kotlin then so much the better, this is how languages
| evolve. If it really does evolve to remove the need for a
| better Java then it would be nice if people switched away from
| Kotlin and back to it. Scala can then carry on cementing its
| niche as a powerful commercial FP language. No hate for Kotlin
| at all but it seems like in that world, there might be no need
| for it. Scala is better for FP and if Java 17 is the better
| Java then great.
| jpgvm wrote:
| To be honest I see Kotlin continuing to exist because of it's
| multi-platform nature and it's focus being on different
| things to Java.
|
| So even if feature wise the 2 equalize (a good thing not a
| bad thing IMO) stylistic differences will remain. Many of
| Kotlins syntactic differences are unlikely to make it to Java
| for instance.
|
| I'm ok with this. I use both for different things. Kotlin for
| most app level development, Kotlin for libraries that are
| only useful in the context of Kotlin, Java for everything
| else so it has minimal dependencies and can be used from
| Kotlin/Scala/Java/Clojure equally well.
| jmfldn wrote:
| 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?
| jpgvm wrote:
| 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 Android.
|
| This isn't true of Scala at all. Beyond things like SBT,
| comparatively poor IDE support (less of an issue these
| days) it is also just a very complex language, with many
| complicated semantics in it's standard library and even
| more complex/fancy 3rd party libraries piled on top of
| that.
|
| Scala became an incredibly powerful language, not a
| simple or easy to use one however.
|
| Kotlin is a very user friendly language that is easy to
| learn but still has enough power to keep most
| expressiveness focussed devs happy.
|
| Beyond the learning curve Kotlin integrates with Java a
| lot better, calling in both directions.
|
| These 2 factors alone probably account for why it was
| chosen over Scala for Android and in general why it has
| value over both Java and Scala.
|
| I think with Gradle moving from Groovy -> Kotlin, Android
| obviously and big companies adopting Kotlin w/Spring on
| the backend the ship has indeed sailed for Scala, it
| doesn't really have a place outside of places that
| specifically want a more FP lang.
| jmfldn wrote:
| I hear this a lot about Scala, and I am a Scala dev so
| maybe I'm biased, but I don't get the difficulty angle
| particularly. I'm in no way exceptional as a programmer
| or IQ-wise but I picked up Scala easily as part of my
| first job. The difficulty thing doesn't compute to me but
| it could just be that I'm well-suited to the language. It
| works beautifully as a better Java if that's how you wish
| to use it. Granted, it might be hard if you start with a
| "pure FP" codebase but most devs don't struggle picking
| things up on most code bases even as juniors.
|
| The point about tooling and developer experience I'll
| concede. It has been at times patchy in Scala in the past
| but it's pretty good these days.
|
| As I say, I have no hate for Kotlin, and I'll possibly
| use it one day being a JVM developer familiar with Java
| as well, I just find it unfortunate that a language which
| is so similar to the languages it's influenced by was
| invented.
| jpgvm wrote:
| It's difficult because the language is gigantic compared
| to Java, it has all the OOP bits Java has (and Scala
| needs in order to be relevant) then a whole bunch of FP
| stuff on top. This is a lot for newer programmers and
| while they might be able to do "hello world" equally
| quickly I do feel like they soon hit a wall of "I don't
| understand why this works" when looking at idiomatic
| Scala.
|
| It can be used as a better Java but requires discipline.
| Things like implicits can easily cause an unnecessary
| amount of pain. Kotlin on the other hand implemented
| extension methods in a way that doesn't detract from the
| better Java paradigm. This is only one example though,
| there are many many reasons why Kotlin is more suited for
| the "better Java" role. Namely it's simply not that
| different to Java. It's effectively Java with a more
| modern syntax and polished extensions to the Java
| standard library.
| jmfldn wrote:
| It does require discipline, or at least one person on the
| team who can set a style guide for the newcomers to
| follow, this is true.
| grogs wrote:
| Scala 3 somewhat simplies implicits by the way.
| Especially w.r.t to extension methods, which are now a
| first class construct in the language:
| https://docs.scala-
| lang.org/scala3/reference/contextual/exte...
| grumpyprole wrote:
| The first time I tried Scala, I got a type error based on
| the result of an implicit conversion, which succeeded
| locally but not for the entire expression. It took me a
| while to figure out what had happened. Advanced (mis)
| features such as this combined with encoding everything
| into objects with subtyping make Scala very complex. F#
| and OCaml are examples of much simpler languages that
| have most of the advantages (albeit no JVM).
| perl4ever wrote:
| >The truth of it is that Kotlin is incredibly easy to
| learn
|
| 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.
| grishka wrote:
| You could soon be able to use modern Java on Android,
| too. Remember that most of the new syntax features don't
| need changes to the JVM.
| cutler wrote:
| Android will always be Kotlin-first. That's a pretty huge
| market.
| jpgvm wrote:
| I think people underestimate how deep this integration is
| going. Compose relies on extensions to the Kotlin compiler.
| The future of Android and Kotlin are pretty much tied
| together at this point.
| jayd16 wrote:
| Android used to be always Java first. It could change
| again.
| vbezhenar wrote:
| Most likely to Flutter. When Google will be ready to
| ditch Android API.
| hota_mazi wrote:
| Android is based on the JVM, it will never switch to
| Flutter (and an aggravating factor is that Dart is an
| inferior version of Kotlin).
| pjmlp wrote:
| If you want some fun watching Jake Wartorn's opinion on
| it,
|
| https://youtu.be/VX6nAvRWQg4
| morelisp wrote:
| The JVM is specifically the part of Java Android _didn
| 't_ use, and the layer Google has already completely
| replaced once.
| pjmlp wrote:
| DEX must be able to represent everything on the Java
| ecosystem, otherwise it is a hit and miss what can be
| consumed from Maven central.
|
| Also it is quite common on embedded Java for the vendors
| to have their own implementation with code translation.
|
| What isn't normal is having stagnant compatibility.
| Smaug123 wrote:
| I think one could argue exactly the same thing for the same
| reasons about C# vs F# on .NET, which is my area of expertise -
| but honestly I'm not so sure it's true. C# has grown into an
| _enormous_ language as it tries (consciously or not) to subsume
| F#, and F# is always going to remain so much cleaner just
| because you aren 't having to ignore 90% of the language
| features when you code in it.
| pron wrote:
| The cause and effect are quite right, though. The reason Kotlin
| was designed in 2009-2010 was because Java became stagnant, not
| by choice, but due to Sun's demise. After the acquisition and
| an adjustment period, Oracle gradually increased investment,
| and the evolution pace got back to it's "normal" course. So
| Java's "revival" and Kotlin's existence are, indeed, related,
| but one did not cause the other; rather, they both have a
| common cause.
| whyenot wrote:
| I don't see it as unfortunate. It shows that Java is a living
| language that continues to improve and change to match the
| needs of its users. Compare this to Common Lisp, which has not
| change in any meaningful way since 1984.
|
| 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.
| 66fm472tjy7 wrote:
| I don't think this is going to happen with Brian Goetz as
| language architect. He refuses to add many features that would
| address everyday pain points such as:
|
| * null safe navigation operator
|
| * properties
|
| * mutable records
|
| * a way to ignore checked exceptions (or at least having the
| stream API take functional interfaces that can throw
| exceptions)
|
| * adding functional methods like .filter()/.map() directly to
| collections instead of having to
| .stream().map(..).collect(toList())
| krzyk wrote:
| He does not refuse, but needs to look at bigger picture.
|
| Some features are low hanging fruit, some are proposed small
| changes that actually should be defined a bit differently to
| be better and they will take more effort.
|
| But even small hanging fruits means that they need to chose
| which ones to do. Should they delay pattern matching by 6
| months to get elvis operator? I wouldn't like it, pattern
| matching is more important.
|
| Basically they have limited resources and have to chose what
| to work on.
| bestinterest wrote:
| Is that true though? nullability is a area I've heard /u/pron
| mention may be tackled in the future, mutable records seem
| like they will be tackled with the 'withers' concept in the
| future. Checked exceptions + changing the sugar of
| .stream().map I don't see ever changing. Properties I am
| unsure of.
| laurent92 wrote:
| Why should it be in the future. The syntax of .stream() has
| been awfully verbose since Java 8: in the middle of
| ".stream()....collect(toList())", you need to squint to
| find the actual function name being applied between the
| flood of polluting calls, which loses the appeal of
| functional programming.
|
| In my company we have f(list).map(...), which is a wrapper
| for the streams. But newcomers don't like it because it's
| not the standard.
| cogman10 wrote:
| AFAIK, the fate of nullability is tied pretty directly to
| Valhalla. It's constantly being brought up there.
| oftenwrong wrote:
| Stream has been given a `toList()` convenience method:
|
| https://docs.oracle.com/en/java/javase/17/docs/api/java.base.
| ..()
| pron wrote:
| Thank god for that, because those feature are either horrible
| on their own or superseded by better ones. You're getting a
| car and complaining for not getting faster horses. The
| features Java has adopted -- specifically, algebraic data
| types and pattern-matching -- will lead to better development
| practices, rather than making it easier to work with inferior
| ones.
| xpressvideoz wrote:
| I can understand the hate behind null-safe operators, but
| why properties? Why is bad to have an ability to "upgrade"
| a member variable into a property, without breaking any
| existing contracts? I really hate that I need to resort to
| using setters and getters in Java because those are bad for
| searchability.
| nikeee wrote:
| IMHO Safe navigation only makes sense when the compiler is
| Abe to reason about nullability, meaning nullability is
| rooted in the type system. That's the case for Kotlin and not
| for Java.
|
| Otherwise, you've got a high risk of developers inserting a ?
| to fix a bug, which only fixes the symptoms.
| mavelikara wrote:
| Java's implementation of generics was heavily influenced by a
| language called Pizza. Sun hired the author of the language,
| Martin Odersky, to write the compiler for Java. Odersky later
| went on to develop Scala.
|
| Java improving borrowing ideas from other JVM languages had
| happened in the past, and that has made the ecosystem stronger.
| Nothing unfortunate about it.
| hocuspocus wrote:
| Scala is fine. People understood it's not really worth it as a
| "better Java". Companies that choose Scala in 2021 are using
| either big data frameworks (where Python bindings are the most
| common alternative to Scala, not Java), or functional
| ecosystems (Typelevel, Zio). Scala 3 has taken an interesting
| direction and to me it seems that Odersky wants to win Python
| developers over rather than Java shops using Spring.
|
| New features in Java and the JVM (records, loom, valhalla, ...)
| are directly going to benefit Scala and make it even better.
|
| On the contrary, Kotlin's essence has always been threatened by
| the fact it's nothing more than a better Java. I assume there's
| still a big demand for that on Android, but if you're running
| on a recent JVM, I would certainly consider Java over Kotlin.
| zorr wrote:
| Kotlin started out as a better Java but it's more than that
| now. With Kotlin multiplatform you can compile to JVM,
| Javascript and Native from the same repository.
|
| Java has been catching up on language features but I'm not
| sure if I'm ready to switch back to Java for Spring projects
| yet. Mostly because of nullability, extension methods and
| coroutines in Kotlin.
| hocuspocus wrote:
| Targeting multiple platforms is orthogonal to the core
| language design goal, which has always been to be more like
| C# on the JVM, with 100% Java interop and no need for a big
| standard library.
|
| I give you nullability, however extension methods without
| proper typeclasses is just syntactic sugar, and coroutines
| will be superseded by Loom.
|
| Java hasn't only been catching up, it now supports pattern
| matching which Kotlin still lacks.
| tunesmith wrote:
| Which is a bummer for folks that loves the cleanliness and
| power of "basic Scala" (pure functions, immutability) without
| wanting to get into deep FP theory (typelevel, zio). That has
| been a really nice pocket to be in for teams that have the
| discipline to not get clever with it. Same with teams wanting
| to integrate with Akka on scala.
| hocuspocus wrote:
| Zio is pretty much what you want. No need to understand
| category theory, no over-reliance on implicit resolution,
| ...
|
| That said you don't need to understand that much to use
| high-level libraries in the Typelevel ecosystem. And when I
| do need to reach for low-level constructs, I find nice that
| everything is built upon clean and composable abstractions.
|
| You mention Akka, it's kind of its own beast. The inner
| workings go definitely way beyond "better Java", yet
| Lightbend needs to provide a surface API that plays nice
| with Java interop. It's not an ecosystem easy to navigate
| in my opinion.
| Zababa wrote:
| I think between Scala 3 and the Li Hayoi ecosystem, there
| is a path to simplicity. But that usually means you lose
| part of the appeal of the language, since you can't use
| some parts of the ecosystem.
| hota_mazi wrote:
| Interestingly, I have the exact opposite opinion.
|
| Scala has been declining steadily for a decade now, and Scala
| 3 is going to precipitate this state of affairs by splitting
| the shrinking community even further.
|
| Kotlin, on the other hand, has done nothing but grow for the
| past five years, no doubt helped by Google's formidable
| support for it. I just took a quick look at one of its Slack
| channels, "getting-started", and it has over 38,000 people on
| it. And that's just one channel among dozens more.
|
| I don't think Java's latest additions are anywhere near
| threatening Kotlin's rise to dominance since Java is moving
| at a very slow pace, by design, while Kotlin supports some
| features and design directions that will never happen in
| Java.
| pjmlp wrote:
| Dominant outside Android? Keep dreaming, where is the KVM
| implementation by JetBrains?
|
| Yeah right they had to reboot it.
| jmfldn wrote:
| It's not in decline imho, it has settled as middle ranking
| language in terms of popularity and is v popular in its
| niche. It depends where you are of course but in London
| it's used in loads of places from major corporations to
| startups. The market is hot.
| Waterluvian wrote:
| I don't follow why this is unfortunate?
| jacoblambda wrote:
| A lot of people have migrated away from Java to better JVM
| languages. If Java actually keeps improving, there's a
| reasonable likelihood that people will stop migrating and
| those that have may come back to Java from these other langs.
|
| Long term this could lead to a loss of maintenance for tools
| and libraries for these languages which could kill them and
| leave those that migrated with a dead & decaying ecosystem.
|
| Of course this is a bit of a stretch but it's not unheard of.
| ISL wrote:
| If people left Java for other language(s), wouldn't that
| leave Java with a decaying ecosystem?
| spockz wrote:
| Most of them stayed somewhere on the jvm though. Still in
| the ecosystem.
| Sevaris wrote:
| Maybe worry about leveling the playing field first?
| There's so much money and research and development going
| into Java that there's no possible way for Java to end up
| with a "decaying ecosystem" inside the next twenty years.
| It's like pointing out DuckDuckGo and worrying about
| Google.
| pjmlp wrote:
| A tiny drop, an endless collection of guest language that
| goes back to Beanshell, many of which now forgotten.
| tunesmith wrote:
| Over the last short while I've seen Lightbend announce
| ceasing support for Play, others express that Slick is
| likely abandonware, and also seen my chosen Play
| authentication library, silhouette, get archived on github.
| All of this has impacted my favorite side project that I've
| been slowly plugging away on.
|
| Silhouette is probably just because of one guy's schedule,
| but Play/Slick seems like after-effects of lightbend's
| layoffs many months ago, and while I don't know the cause
| of those it seems plausible it's because of the kind of
| thing you describe above.
| tablespoon wrote:
| > I don't follow why this is unfortunate?
|
| I'm guessing Java hate, which is kind of fashionable. If Java
| evolves to stay relevant, it won't be usurped and fade away.
| atomicnumber3 wrote:
| I assume OP prefers Kotlin or Scala.
|
| Personally, I think one of my favorite things about Java is
| that, all things considered, it's a small-ish language. So
| I'm glad that Java is both willing to evolve (slowly, letting
| other people try stuff out first) but also clearly focused on
| a curated feature set and resistant to letting new stuff in
| to bloat it. I am very happy to deal with minor things like
| no multiline string support if it means we get to avoid being
| a terrible mess of language features that ruby, scala,
| python, etc have accrued in a relatively quicker timescale.
|
| I was fairly sad around the java 6-7 days where we went quite
| a long time with no visibly major new language features
| (diamond inference was 7's big thing, lol). So it is nice
| that we're moving a bit faster than that, now.
| pooya72 wrote:
| By multiline strings are you referring to text blocks?
| Those have been added to the language in Java 15:
| https://docs.oracle.com/en/java/javase/15/text-
| blocks/index.... .
| atomicnumber3 wrote:
| Oh, sorry, I know, I mentioned it specifically because it
| was "only" just added in Java 15 (which is basically
| "now" in Java timescales heh, and has only literally just
| now (with 17) made it into LTS AdoptOpenJDK releases,
| which also haven't quite landed on many distros package
| repositories, etc etc.). So for some weird value of
| "right now" Java still doesn't quite have multi line
| strings due to its newness.
| cageface wrote:
| What I don't want to see happen is innovation stop in JVM
| languages and then Java, no longer under threat, also stops
| innovating.
| pjmlp wrote:
| Except without Java they are meaningless.
| jayd16 wrote:
| Kotlin is still run by the company that makes the best Java
| ide, no? I don't expect kotlin to get pushed out so easily.
| dmitryminkovsky wrote:
| I just want to add that while this is a really nice post in its
| own right, I found this blog because its author created this:
| https://github.com/dodie/vim-fibo-indent
| weatherlight wrote:
| Java sucks, and should stop being taught as the defacto language
| in computer science curriculums. It's extremely busy and verbose.
| There are _better_ OO languages out there, if the point is to
| teach OO.
|
| (I'm ready for this post to get downvoted into oblivion)
| ptstomp wrote:
| Regardless of OO 'quality' of a language, if you consider that
| most university degrees are an avenue to successful employment
| then it's easily one of the best ones to learn due to the
| current market alone.
| dang wrote:
| Please don't take HN threads on boring generic tangents (by
| making grand shallow claims), and especially please don't take
| HN threads into tedious programming language flamewar.
|
| Also, you broke the site guideline asking people not to go on
| about downvotes in the comments. Would you mind reviewing
| https://news.ycombinator.com/newsguidelines.html and sticking
| to them in the future? We'd be grateful.
| grishka wrote:
| Being verbose is a plus. I really really really hate the
| terseness of Kotlin and how it's basically unreadable without
| an IDE.
|
| Languages should be dumb. Standard libraries should be smart.
| Not the other way around. The number of _syntax constructs_
| that generate standard library calls when compiled should be
| minimized as much as possible.
|
| Edit: one more thing, operator overloading is extremely harmful
| for readability.
| BMorearty wrote:
| Being verbose is one of the biggest negatives a programming
| language can have. When you're working on a team with other
| programmers and reading someone else's code, verbose code
| takes much longer to read and grok because you have more
| boilerplate code to read.
| grishka wrote:
| But reading terse code requires a lot more prior knowledge,
| which you might not have. You learn to recognize patterns
| in the boilerplate and just glance over it, taking no
| additional time.
| edoloughlin wrote:
| I think I could make the same argument for terse code.
| weatherlight wrote:
| garbage collected programming languages are for people,
| not computers.
|
| Kotlin isn't terse.
| BMorearty wrote:
| It definitely does not take "no" additional time to read
| verbose boilerplate code.
|
| As for prior knowledge, that argument doesn't fly. A lot
| of the verboseness of Java could be addressed VERY easily
| with clear syntax that doesn't require a lot more prior
| knowledge. An example is getters and setters, which are
| very easy to understand in languages that have built-in
| support for concise syntax but Java has somehow ignored
| the advantage of concise syntax for 25 years.
|
| Besides, if your argument is that Java doesn't require
| "prior knowledge," I beg to differ. E.g., correct usage
| of arrays vs. ArrayList.
| skneko wrote:
| > E.g., correct usage of arrays vs. ArrayList.
|
| Arrays vs lists is a thing in all languages, not Java.
| They just have different names (list, vector,
| sequence...)
| kayodelycaon wrote:
| I don't think Ruby or Python have linked lists, only
| arrays.
| skneko wrote:
| ArrayList is not a linked list, it's an array-backed list
| like List in C# or other languages, like the name
| implies. Linked list is `java.util.LinkedList`.
| mattnewton wrote:
| Ruby and python only have an equivalent to Java's "array
| list." It's not in the standard library, but you can
| trivially make linked list nodes yourself if the problem
| calls for it; I don't remember encountering a need for
| the data structure over the built in array-list type
| outside of interview questions anyways.
| grishka wrote:
| Heh, getters and setters. An unpopular opinion, but imo
| you don't need them most of the time. Usually, a getter
| just returns a field and a setter just assigns it. If
| that's the case, and unless you're writing a public API
| of a library, just make the field public. Make it public
| final if it's read-only.
|
| The difference between arrays and ArrayList is simple: an
| array has a constant size known at the time of
| allocation.
| V-2 wrote:
| If Kotlin is unreadable without an IDE, it's Kotlin done
| badly. You can misuse its features to obfuscate the code, but
| in and of itself it's an extremely clear language.
| grishka wrote:
| Kotlin relies on the developer to write readable code, and
| just generally offers way too many ways of doing the same
| thing. Too much freedom of expression. Java, by virtue of
| being more verbose, requires writing everything out
| explicitly, so you really have to expend some extra effort
| to make your code unreadable.
| filoeleven wrote:
| > Languages should be dumb. Standard libraries should be
| smart. Not the other way around.
|
| This is a strong argument for Clojure. The language makes
| helpful and readable guarantees about data shape, and
| provides a wealth of functions that operate on its core data
| structures.
|
| Kotlin has a bunch of inferred classes, and Java has a bunch
| of explicit ones. Clojure recognizes that data does not look
| like either of those: it's fundamentally a sequential list of
| things or a key/value map of things. Everything else is a
| special case that only your program cares about, and it gives
| you the tools to build a system to work with them as
| generally or specifically as you need it to.
| wyager wrote:
| The tradeoff space you're describing doesn't reflect reality.
| Adding more brackets and pointless keywords to a language
| doesn't meaningfully improve the programmer experience in any
| way. There are plenty of terse languages that don't require
| an IDE to understand. If anything, Java effectively requires
| an IDE to use _because_ it's so verbose.
|
| The things that I write in a computer program's code should
| correspond as closely as possible to what the program _means_
| - nothing more and nothing less. Java is terrible at this.
| BMorearty wrote:
| Excellent counterpoint about Java requiring an IDE because
| it's so verbose. In fact when I complain about Java's
| verboseness, Java fans tell me "who cares, just use your
| IDE's ability to auto-generate code!" But of course that
| doesn't help with the _reading_ of verbose code.
| goatlover wrote:
| "The utility of a language as a tool of thought increases
| with the range of topics it can treat, but decreases with the
| amount of vocabulary and the complexity of grammatical rules
| which the user must keep in mind. Economy of notation is
| therefore important." - Notation as a Tool of Thought by
| Kenneth Iverson
| vletal wrote:
| There is still a huge market demand for Java. Moreover the
| recent releases are doing a great job adding features following
| recent trends. If thought using JDK 16+ a student will be able
| to move to Kotlin, Swift, Scala, ... much more easily than few
| years ago. IMO it's more about updating the curricula than
| dropping Java.
| dukeyukey wrote:
| I agree with everything here except the "should stop being
| taught as the defacto language in computer science
| curriculums". Realitically, a CS curriculum needs to at least
| vaguely prep a student for life in the industry, and Java is
| not only massively popular, but is also a great way of showing
| how OO is used in practice i.e. kinda badly. No point teaching
| everyone about beautifully architected Smalltalk programs just
| to have them work on hacky Java monoliths from 2003 (not to
| mention BusinessObjectTpyeFactoryGenerator.java).
| weatherlight wrote:
| teach javascript, ruby, rust, go, kotlin....scheme.
|
| literally anything else.
| hawk_ wrote:
| how's javascript better than java in its design or
| elegance?
| cyberbanjo wrote:
| I think a well rounded course would touch all the popular
| paradigms, and logic.
| ksec wrote:
| Apart from Javascript. Ruby, Rust, Go, Kotlin and Scheme
| _combined_ wouldn 't equal to half the market Java has to
| offer.
| 123jay7 wrote:
| university is not meant to teach what the market is
| offering, rather hopefully shape and dictate it
| weatherlight wrote:
| thats the status quo fallacy.
|
| You _can_ get work in those other languages, nor is an
| understanding of Java a prerequisite for understanding
| how to use those other langs, etc.
| ksec wrote:
| >if the point is to teach OO.
|
| Is it really the point to teach OO though?
|
| Java is being used everywhere. And you get to learn the basic
| as well as the huge ecosystem behind it. Apart from possibly
| Python, are there any language that get you both in terms of
| market and learning?
|
| And Java have make _huge_ improvement in every part of the
| ecosystem, from languages, standard library, VMs. While I still
| dont like the language much, but I have gotten off the so
| called busy and verbose code view as I age. As they do serve
| some purpose. We need better balance, right now languages
| design are binary and polarised options.
| leetcrew wrote:
| strictly from a pedagogical perspective, sure, there are better
| choices. but java is at least decent for most of the core cs
| curriculum, and it's widely used in industry. when you're
| trying to get your first internship with no work experience,
| it's nice to be familiar with the language you'll be using at
| work.
| lordnacho wrote:
| Java sucking could be a good reason to teach it, no? It's
| instructive to know what bad choices have been made. Much like
| your first job, it can be unfortunate to work in a place where
| everything functions properly, because you won't know what
| makes it work.
|
| Java is also a good base for looking at other JVM languages,
| and for looking at the JVM itself. That's gotta be part of a
| good curriculum too, doesn't it?
| dunefox wrote:
| That's a _horrible_ reason to use a language for teaching.
| imheretolearn wrote:
| Could you please support your statement with reasons?
| weatherlight wrote:
| https://thenextweb.com/news/universities-finally-realize-
| jav...
|
| https://en.wikipedia.org/wiki/Criticism_of_Java#:~:text=The%.
| ..
|
| https://www.quora.com/Why-did-Alan-Kay-dislike-Java
|
| https://vic.nightfall.moe/2016/04/03/Some-reasons-why-I-
| hate...
|
| https://developers.slashdot.org/story/08/01/08/0348239/profe.
| ..
| dvdkon wrote:
| Lots of other good arguments have been posted, but I'd like
| to say something to the teaching aspect. In high school, we
| had four years of Java. I already knew most of the curriculum
| at the start, so others would sometimes ask me for help with
| assignments. Quite a few times, even after years of school,
| I'd run into people being confused by classes, instances,
| what curly braced blocks meant on a class vs on a control
| statement...
|
| You could say the class should've been taught better, or that
| the students just weren't good enough, but I think a good
| tool (programming language) should help users, not be a
| barrier to overcome. Programming in Java doesn't require too
| many concepts, but you have to start with all of them at
| once, and I think some students just never got over that
| initial step.
|
| It's of course debatable whether another language would have
| been better or whether Java really contributed to the
| problem, but I think we can agree there are languages that
| better lend themselves to teaching complete beginners.
| Longhanks wrote:
| public class Main { public static void
| main(String[] args) {
| System.out.println("Hello, world!"); } }
|
| vs print("Hello, world!")
|
| Please comment again if you still cannot see the
| bloat/unnecessary verbosity.
| grishka wrote:
| Global scope is a terrible invention. The less implicitness
| there is, the better.
| weatherlight wrote:
| then write assembly.
| grishka wrote:
| What I'm trying to say that at some point in piling up
| abstraction layers, abstractions stop being helpful and
| start getting in the way.
| BMorearty wrote:
| "It's extremely busy and verbose" were the reasons.
|
| I agree with those reasons and I've always felt Java sucks
| because of them. When Java first came out I was a C/C++
| programmer and was excited to learn it. Very quickly became
| disillusioned because it was incredibly verbose. I hoped the
| language would evolve quickly but it took FOREVER. Meanwhile
| Microsoft introduced C#, whose v1 looked like a copy of Java,
| and very quickly evolved the language to make it much better.
| They did what I hoped Sun Micro would do. But Sun just sat
| there and twiddled their thumbs.
| ronri19 wrote:
| Not sure about the person above but the following are my
| opinion on why I don't like Java:
|
| 1. no unsigned integers
|
| 2. no freestanding functions
|
| 3. pom files are a huge pain
|
| 4. the com.blah.blah.blah ridiculously long package path
| precedent makes it awful to work with if you don't have an
| ide
|
| 5. you can't actually use javac to compile your code.
| everything is so big and complicated you have to use ant,
| gradle, maven, etc.
|
| 6. too much boilerplate. "public static void main" etc.
|
| There's a few more, but they'd take more than a sentence to
| explain.
| xxs wrote:
| >no unsigned integers
|
| technically, char is unsigned. For practical purposes use
| ByteBuffer.
|
| >no freestanding functions
|
| you can "import static" all the static functions you want;
| it's not any different than C, where you need to include
| the headers.
|
| > pom files are a huge pain
|
| That has nothing to do w/ java, itself, like at all.
|
| >you can't actually use javac to compile your code.
| everything is so big and complicated you have to use ant,
| gradle, maven, etc.
|
| If you use ant, how did you get to use pom? That's pretty
| much saying that using 'make' is terrible. For personal
| projects that involve no web, I don't quite need anything
| else but the JDK, itself. In that case, it's totally doable
| to call javac form the command line.
| karmakaze wrote:
| Great (unintended) straw-man comment. These are all minor
| reasons in the context of an introduction to developing
| software. Yes, there's some initial setup, but once that's
| done and you're learning how programs are constructed with
| classes, objects, methods and where static typing can help
| you, they're all the important things that will carry you
| well into a career.
| dunefox wrote:
| Just because you can have a career in Java despite the
| disadvantages does not mean that they're not
| disadvantages that most other languages don't have.
| karmakaze wrote:
| Wasn't suggesting that one make a career of Java, but
| rather apply the knowledge learned in using a statically-
| typed, compiled language with OO and functional bits.
| Hopefully advancing to using languages with type-
| inference as one progresses.
| [deleted]
| brundolf wrote:
| Counterpoint: it's become a fairly multi-paradigm language at
| this point, and a multi-paradigm language is exactly what
| should be the defacto language in curriculums
|
| Whether or not Java is the best one for this purpose is up for
| debate, but I think it's no longer a bad one
| dunefox wrote:
| > it's become a fairly multi-paradigm language at this point
|
| It's still very much an OO language with borrowed features.
|
| > a multi-paradigm language is exactly what should be the
| defacto language in curriculums
|
| Debatable. Multi-paradigm languages without a strong focus
| can overwhelm someone completely new.
| weatherlight wrote:
| Is it though? just because it has lambdas, does that make it
| functional?
| Athas wrote:
| > Counterpoint: it's become a fairly multi-paradigm language
| at this point, and a multi-paradigm language is exactly what
| should be the defacto language in curriculums
|
| I'm surprised you would say this, as it is the exact opposite
| of my experience as university teacher. I think we should
| teach _concepts_ , and concepts appear much more crisply in
| small and focused languages. I think students gain more from
| being exposed to specialised languages than to more muddled
| multi-paradigm languages. For example, functional programming
| is much clearer in a language such as SML or Haskell than in
| Scala or F# (although the latter isn't that bad), because you
| can actually teach the whole language without any part of it
| muddling the concepts. Similarly, I would rather teach
| object-oriented design and implementation with, say,
| Smalltalk than OCaml.
|
| Now, industrial usage is a different matter - here I have no
| problem with multi-paradigm languages.
| brundolf wrote:
| An assortment of specialized languages in different
| paradigms would probably be better than a single multi-
| paradigm language. But I was assuming the "CS 101" case,
| where you're just trying to get a feel for code and
| probably don't want to be overwhelmed with learning several
| different languages at once. In this context I think laying
| a foundation with a single versatile language makes the
| most sense - a "sample platter", if you will - and then
| later courses could dive deeper into different paradigms
| using more specialized languages (where those paradigms
| would already be familiar because of that base language,
| but they'd get brought into more clarity).
|
| Another advantage of laying this kind of foundation is that
| even if the initial course stuck to a limited set of
| features, students could then go out and use the things
| they've learned and explore other features adjacent to them
| at their leisure, without going too far outside of that
| initial comfort zone (and - maybe most importantly - using
| the same tooling/environment setup, which can be the
| biggest barrier to new programmers who want to try out
| different technologies)
|
| I'll admit though that this is mostly speculation on my
| part
| Athas wrote:
| I suppose it depends on how long that CS 101 course would
| be. At our department, we used to have an initial half-
| semester course that taught computational problem solving
| and programming using Standard ML. It was necessarily
| based on functional programming, although Standard ML is
| impure enough that we could also do simple IO. In the
| next course, they were taught object-oriented design and
| programming in Java. This has been replaced with a single
| course that uses F# (a multi-paradigm language) to teach
| a mixture of functional, imperative, and object-oriented
| techniques. It is not my impression that the students are
| left with a very clear conception of these ideas
| afterwards. Mostly they just seem to loathe F# - more
| than prior generations loathed Standard ML, even though
| F# is far more practical and has far better tools.
|
| There can be many reasons for this, but I think people
| completely new to programming do not have the maturity to
| juggle multiple paradigms within such a short period of
| time, and within the same language. Perhaps switching to
| a materially different language when switching concepts
| actually helps them, so they don't mix up things too
| much.
| brundolf wrote:
| Interesting. I guess my thinking was that "paradigms" are
| mostly artifacts of a) history, and b) ways of describing
| ideas which at production scale may lend themselves
| better or worse to a given problem space (in terms of
| maintainability, etc), both of which are good to learn
| eventually, but neither of which matter that much when
| you're just trying to figure out what code is.
|
| But I guess when you're just trying to figure out what
| code is, it helps to be able to form very consistent and
| concrete understanding around basic atoms like "what is a
| variable?". So if a language has different syntaxes that
| look similar but don't follow the same rules, that could
| get bewildering fast. Especially in languages that have
| sprawled over time and have competing ways of doing the
| same things.
|
| Maybe the best answer is a language that was designed
| holistically to be cross-paradigm from the outset? In
| contrast with a kitchen-sink language that's gathered
| features over the years
|
| Edit: Another thought; there may be a distinction to be
| made between "mixed-paradigm" and "cross-paradigm", where
| one takes the best pieces from multiple paradigms and
| works them together into a complete whole, while the
| other just dumps multiple _entire_ paradigms into the
| same language. Rust for example does a great job of
| mixing-and-matching without sprawling (not that it would
| necessarily be a good first language, but for the sake of
| example)
| alkonaut wrote:
| Does java have a decent story on value types now e.g can I make
| an ArrayList<long> 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.
| bradleyjg wrote:
| No. You can't make an ArrayList<long> at all. You can make an
| ArrayList<Long> and trust the JVM to optimize as it may or you
| can use c++.
| Twisol wrote:
| Not yet. You can track Project Valhalla [0], the incubator for
| value/inline types in OpenJDK. But I don't get the sense it's
| landing particularly soon.
|
| https://openjdk.java.net/projects/valhalla/
| silvestrov wrote:
| The FastUtil library is very good for this:
| https://fastutil.di.unimi.it
| rdpintqogeogsaa wrote:
| I've been bitten by bitwise operations on signed integers a few
| too many times. Are there any plans on having normal unsigned
| integer types yet?
| recursive wrote:
| Other than sign-extension on right shift, I can't think of a
| bitwise operator that has a different implementation between
| signed/unsigned. What scenarios are you thinking of?
| xxs wrote:
| reading and processing bytes mostly. Many people get confused
| due to the need of bitwise and, yet even if that would be
| removed I can't quite see the intrinsic benefits, given how
| difficult would be having another primitive type.
| recursive wrote:
| So, when processing bytes, can you name an operation where
| the existence of an unsigned type would even make a
| difference? I'm still not seeing it.
| xxs wrote:
| java virtually has only 2 integer types int and long, or
| 4 and 8 bytes one. So all operations are converted to int
| (or long) 1st, even when they involve byte/short, etc.
|
| Imagine you try to combine a 4bytes (from an array) into
| a single int. If you just bitwise OR and shift left, e.g.
| something like (b[0] << 24) | (b[1] <<
| 16) | (b[2] << 8) | b[3]
|
| it won't work, you need ((b[1] & 0ff) << 16), etc. The
| byte values greater than 127 would have the sign bit set
| (and all other higher bits to make the 2complimentary
| form)
|
| That part is somewhat alleviated by wrapping byte arrays
| into ByteBuffers that would the right thing, or even
| better using only ByteBuffers (preferably the direct
| version of them when reading from input/output)
| eMSF wrote:
| Java bytes are signed. They aren't useful when working
| with unsigned 8-bit values (say, a scaling factor or an
| index in whatever binary format you are trying to parse).
| You need a larger integer type, and indeed _that_ bitwise
| and operation to get the range of values you need.
| rzzzt wrote:
| Java has both >> and >>> operators for sign-extending and
| zero-extending right shift, respectively.
| sorokod wrote:
| They are present in Kotlin
|
| https://kotlinlang.org/docs/basic-types.html#unsigned-intege...
| xxs wrote:
| What exactly do you have in mind. Using '&0xff' is annoying but
| well whatever. Perhaps 23y ago, applying the bitwise and would
| be a novelty but now it's a minor inconvenience.
|
| The way java is built in internally I can quite see another
| primitive type popping up.
| chrisseaton wrote:
| Java already has everything you need for unsigned integers
| doesn't it? You just use the normal int type, and then use
| methods like Integer#compareUnsigned instead of language
| operators.
| da_chicken wrote:
| This reads like, "VisualBasic already has everything you need
| for pointers. You can define your own classes and pass by
| reference."
| chrisseaton wrote:
| Not sure what you mean, sorry?
|
| Are you just objecting to the verbosity of method calls
| over operators? Yes it's a bit annoying, but the
| functionality is all there.
| pkolaczk wrote:
| It is very easy to mess up signed with unsigned then -
| because they are the same static type. You have to put
| comments in the code to clarify the interpretation of
| bits.
| chrisseaton wrote:
| So yes it's also error-prone. But there's no overhead, as
| the original comment implied.
| 5faulker wrote:
| Same here. Can be downright confusing sometimes.
| didip wrote:
| To be honest, what I really need is a list of backward
| incompatible changes and a list of projects that can shim those
| incompatible changes.
|
| Just like Javascript.
| InsaneOstrich wrote:
| There are very, very few backward incompatible changes in Java
| sushsjsuauahab wrote:
| Missing var in java 9?
| teh_klev wrote:
| Introduced in Java 10:
|
| https://advancedweb.hu/new-language-features-since-java-8-to...
| sushsjsuauahab wrote:
| Wow, my memory failed me! I could have sworn it was 9.
| teh_klev wrote:
| You can't remember everything :)
|
| I've been a C# developer since v1 and I couldn't tell you
| specifically what version a feature appeared in. It's all a
| bit of a blur.
| nooorofe wrote:
| https://advancedweb.hu/new-language-features-since-java-8-to...
|
| > Available since: JDK 11 (Without lambda support in JDK 10)
|
| TOC is missed up, there is no java-10 at all.
| bobthedino wrote:
| I also recently found this site, which for example can show you
| an API diff between Java 8 and 17:
| https://javaalmanac.io/jdk/17/apidiff/8/
| pharmakom wrote:
| 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 :)
| Twisol wrote:
| For myself, I'd like to see use-site variance replaced with
| declaration-site variance. It's really painful sometimes to
| have type arguments within generics more than one level deep;
| you have to start adding `? extends` (usually; or `? super`
| occasionally) at all the intermediate levels.
|
| I somewhat suspect Java is locked into its current approach to
| variance, but gosh, I much prefer Scala's approach here.
| karmakaze wrote:
| The unfortunate stance on ADTs is that Java doesn't want them
| generalized. The standard answer is use Records and Sealed
| classes.
|
| What does this mean? Well with generics we can have two
| libraries that know about Map<> and concrete types TypeA and
| TypeB and can interface type-safely using Map<TypeA, TypeB>.
|
| What we can't do is have two libraries that know about TypeA
| and TypeB interface type-safely using a sealed type of TypeA
| and TypeB. Even without considering libraries, another use we
| may want to talk about a sealed type of TypeA and TypeC, but of
| course TypeA can only be in one of the sealed class trees.
|
| The worst part is that Java already has a Union type that's
| only ever used in multi catch(ExceptionA|ExceptionB e).
| cyberbanjo wrote:
| What would do notation add to Java?
| pharmakom wrote:
| There are lots of places where it can help, but to give one
| example consider the Java 8 Optional type.
|
| It's great for avoiding nulls, but you get excessive nesting
| with many isPresent checks. Do notation can fix this.
|
| The language even provides a bind function, but no reasonable
| way to use it!
| emptysea wrote:
| Not the parent, but presumably it would allow for fancy monad
| stuff like Scala's Cats Effects[0] and Zio[1] which can make
| async programming easier to follow without having to
| introduce async/await
|
| [0]: https://typelevel.org/cats-effect/ [1]: https://zio.dev
| mhh__ wrote:
| Not specifically for Java but I have found myself wanting do-
| notation in non-functional languages so that I can basically
| write a very expressive library while also forcing users of
| that library to go down my road i.e. I hacked around it in
| the end as I didn't have a do-like abstraction but I had (in-
| effect, it wasn't quite a DSL) written a DSL that represented
| certain constructs just fine using operator overloading, but
| you can't overload control flow. Therefore building the
| notions I wanted to in code was very painful without some
| kind of (equivalent notion to) do-notation.
| seanmcdirmid wrote:
| Can you do something similar in Kotlin using this function
| scopes (that let you change the meaning of this in a
| lambda)? I've found those ok at defining EDSLs.
| mhh__ wrote:
| I've only ever done a hello world in Kotlin I'm afraid.
___________________________________________________________________
(page generated 2021-10-24 23:00 UTC)