231–240 of 246 posts
Earlier quoted context omitted.
Pity that the Streams functions don't support checked exceptions.
It's the only sane way. Checked exceptions were a fundamental mistake which basically makes it impossible to actually use (non-RuntimeException derived) exceptions reliably for their intended purpose. As soon as you introduce any higher-order programming (e.g. functions that take other functions as parameters) you start to have to wrap e.g. IOException... but that means that calling code can no longer catch that wrap…
Earlier quoted context omitted.
It's the only sane way. Checked exceptions were a fundamental mistake which basically makes it impossible to actually use (non-RuntimeException derived) exceptions reliably for their intended purpose. As soon as you introduce any higher-order programming (e.g. functions that take other functions as parameters) you start to have to wrap e.g. IOException... but that means that calling code can no longer catch that wrap…
It's not impossible, it would just require type inferencing/unification on the checked exceptions as part of the function signature.
Anyway, the key point is that any implementation of a method will (almost by definition) need to be able to throw more types of errors than the writer of the original interface anticipated. That is the fundamental problem and unless you get rid of overriding there's no solution for that. The only solution is to force everything into a single super-type... but that just leads to "throws Exception" and we've been there before.
(I mean, there's approximations to solutions as in OCaml's polymorphic variants, row types, intersection types, etc. .. but those only work when variance isn't involved... or do away with most of the touted benefits of the "checked" part of checked exceptions, so...)
Earlier quoted context omitted.
It is not really innovating, if it has been battle-tested by other languages, is it? While modern Java sometimes makes me think about reviving and modernizing an old project of mine, if Java is simply always behind by design of its evolution process, that makes it less likely, that I want to spend time with it.
Your mileage may vary, but I went from liking simple languages like Java, to very expressive, complex ones (Scala, Haskell, Rust) back to Java. I mean, I like all those languages (and many more), but the thing is, most programs really don’t need all that many language features — an okayish type system, OOP for encapsulating private vs public state, and preferring immutable public APIs have served me well in almost ev…
Earlier quoted context omitted.
Your mileage may vary, but I went from liking simple languages like Java, to very expressive, complex ones (Scala, Haskell, Rust) back to Java. I mean, I like all those languages (and many more), but the thing is, most programs really don’t need all that many language features — an okayish type system, OOP for encapsulating private vs public state, and preferring immutable public APIs have served me well in almost ev…
Smalltalk should be a no-brainer then. Arguably one of the simplest languages with merely 6 keywords and immense power. The ecosystem is of course a question. I think I can understand the journey from Java -> other -> Java, because as you learn more about programming, you become more capable of solving problems properly in a simpler language. But there might be a point, when you get fed up again with writing the same…
Earlier quoted context omitted.
Right, and that's why Java introduced checked exceptions in 1.0. A feature which wasn't proven back then and remains unproven now. Another example being overengineered streams. Parallel streams look really cool as a demo, but have been proven dangerous in their default configuration (they can exhaust the default thread pool).
I, for one, like checked exceptions.
Earlier quoted context omitted.
> STR."My name is \{name}"; What is the method call ? Agree with grandparent this looks too inconsistent for Java STR.format(“”) would be more Java with import as Alias
StringTemplate t = RAW.”My name is \{name}”; STR.process(t)
System.out.print.”hello” isn’t a thing
Earlier quoted context omitted.
StringTemplate t = RAW.”My name is \{name}”; STR.process(t)
That’s special magic if I recall my Java syntax correctly System.out.print.”hello” isn’t a thing
Earlier quoted context omitted.
It doesn't eventually add the same stuff (even in this case, the feature is quite different from C#'s) as it will never add most of the stuff C# has because we want to keep Java as minimal as possible. But if your point is that Java usually only adds features that other languages already have, that is absolutely true and we'd like to keep it that way. We believe most programmers generally prefer languages with fewer…
I don't think that's working out so well for you, because developers disagree https://survey.stackoverflow.co/2022/#section-most-loved-dre...
When you've followed such polls for many, many years, you see that programmers report they "love" languages that they pick more than those that are picked for them, that they tend to use for hobby more than work, that they tend to use in newer/greenfield projects, that they tend to use in smaller projects, and that they tend to use alone or in a small team. But the languages that end up working out well -- for the kinds of projects where Java is used -- are those that gain wide adoption in industry, that scale to large codebases and large teams, and yield programs that are maintained for many years. The languages that have managed to achieve that best are Java and C, and, to a lesser degree, C++.
If you've lived through the BASIC and later VisualBasic craze of the eighties and nineties, the SmallTalk craze of roughly the same era, the Haskell craze in academia in the mid to late nineties, the PHP craze of the early oughts, and the Ruby craze of the mid oughts, you see that the most "loved" languages are rarely the ones that end up working well.
Aside from a short ~5 year period (its first five years), Java was never a particularly "loved" language. Hell, James Gosling designed it to be a boring, conservative, "blue collar" language for work, and this work-in-teams-on-large-import-projects has been the main focus of Java's evolution. It's hard to argue that this hasn't worked out really well for Java. Even if Java isn't your cup of tea, you should appreciate the need for a language you can safely bet on to build a very important codebase that should be maintained for twenty years or more.
Having said that, I believe we should work on making Java more suitable for smaller, more fun projects without giving up its scalability. That's a difficult challenge, and, as far as I know, no language has ever achieved it, but perhaps Python is a reasonable source of inspiration.
Earlier quoted context omitted.
we should probably also not blow this "problem" out of proportion. If you actively maintain your things, you can probably handle swapping a few strings out that are garantueed to give buildtime errors. If you dont maintain your application and run on antiquated runtimes? well good news, it keeps totally unchanged... edit: okay, i guess if you do some funky stuff like reflection or having stuff in various config files…
It's more involved than just "swapping a few strings". You also need to make sure that all the libraries you depend on are on the same side of the divide, that is, you have to "swap a few strings" and update all your dependencies at the same time (and these updates could bring unrelated breaking changes with them). And some of these dependency changes might be unexpected; you might not expect a general-purpose loggin…