Move to Kotlin?

What would have been much more useful to my mind was implicit casts instead:


String s = thing.getObject();

Cas :slight_smile:

In the context of pattern-matching, definitely! Then we can finally get rid of the damn visitor pattern.

Outside pattern-matching, yuck!

http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html

You have to pardon me, but I honestly think that you may “read” things, but neither are you open minded, nor are you trying to understand the core statements. I try to show you why I think this way with your second statement:

Counter-question: It’s not the list, but the list’s item that has the consume method. Doesn’t matter. How would you even know it in your example?


List<Item<Parameterization>> itemList = getItemList();

you can only know if you have documentation or the source code of the Item class. Now you could argue that it’s easier on the command line/text editor of your choice to find a file called Item.java than to find a string getItemList() and afterwards a file called Item.java (because you have to lookup the class on the getItemList method)… but honestly - you are only talking about text editors and not having an IDE and stuff. I don’t know your working place, but there are very few reasons to NOT code Java with an IDE. If this scenario is your foundation, than sorry, I am completely wrong and additionally, I feel compassion for how you have to work :slight_smile:

Ever browsed github repositories looking for something useful while trying to understand what’s going on in the sources ?

Further example… do source code search for Gubbin to find everywhere it’s being used. (I do this a lot). Won’t show up at all with var.

Removing information about intention from code is bad. Always bad, IME.

Cas :slight_smile:

Good god, are you serious!? I begin to think that you just make fun of us in this thread^^

Very serious indeed. I am beginning to suspect there may be some language or cultural misunderstanding between you and me.
In any case, I realise that this is basically a rehash of Typical Language Ideology Wars and that there can be no winners. I might as well complain that Americans spell colour wrongly.

Cas :slight_smile:

True, but you have admit that’s kind of pretentious (?)

Just think about it… shall we really evaluate a language based on how much we can understand by reading foreign code displayed via a browser outside an IDE?

Ignoring of course for a moment all conditions such as quality and style code and programming skills of the reader, that might play a very big role…

Or maybe it’s the difference between seeing a language as a tool to implement ideas vs. seeing a language as an idea of itself. Personally, most of the time a discussion like this comes up, I somehow don’t get the point. Mainly, because I just don’t care too much. When writing code in any language, I usually think about the problem to solve and for that, I’m using the means that the language provides. I almost never think something like “Boy, wouldn’t it be so much better, if I could do … instead” (except of course, when I have to use PHP, which I would trash entirely…). That’s true for Java as well as for 6502 assembly.

The difference comes when you spend 30 years of your life maintaining some other bugger’s code and only 5 years actually writing your own. That’s when it becomes painfully obvious why some languages are better than others.

Cas :slight_smile:

With or without IDE is not the point.
A major part of my last 22 years as developer was reading other people’s code. And one thing’s for sure: that sucked. Everybody’s thinks he’s such a great coder. Which is rarely the case. Not to speak of producing readable code.

Yeah, usually the ones with compile-time type safety, which is one reason your suggestion above surprises me!

… and Americans can’t spell colour … and unfortunately after years of programming languages written in American “English”, neither can I! :wink:

My suggestion still has compile-time safety - the cast is just implied. If a cast is impossible the compiler’s still going to barf. Can’t assign a Float to a String. But in most other cases the cast is totally superfluous repetition of something that you’ve literally just typed a few characters earlier.

btw, my code still sucks, even after 37 years doing it, no harm in me admitting that and most people have seen or can go take a look at just how sucky it is :slight_smile: But you know, after a lifetime of looking at other peoples’ mistakes, it certainly helps you avoid making more of your own after a while…

Cas :slight_smile:

There is a difference between writing 1 file game script 300-1000 lines of code
and maintaining project 30k-50k+ lines of code - filled by “val”
same about functional languages – fluffy for kids and nightmare for real projects

Up:
But why even bother when future for TDD
MTD -> MTF -> MTE (MTIF)
(M for Module, D for Data Res {“3” “+” “4” “7”}) XDDDDD ::slight_smile:

What I mean is you’ve made the syntax for normal assignment and an explicit casting assignment the same! With explicit casting you at least have to tell the compiler you think you know better. That’s why I like the implicit casting in pattern matching, because it’s effectively an enforced instanceof and cast. Tighten up the compile-time checks, don’t loosen them. One of the new languages I find most interesting is Rust, and things like the borrow checker.

Once again I am Not Sure if i am Missing Something totally fundamental, or … In your example we have a downcast. This is never safe, that is why an instanceof check is done before at runtime. I can’t See anything that would be compile time safe here. Kotlin for example gives you the automatic cast if you made sure the cast is safe. https://kotlinlang.org/docs/reference/typecasts.html
Heavy (over)use of generics could solve this problem in Java too. Upcasts are less problematic i think.

It’s never safe, and throws CCE at runtime. But as we’re assigning something to a String we may as well assume we’re casting to a String to allow it to happen as we’ve effectively said exactly that we want to do that by declaring the destination to be of String. If the cast is possible, then why not? If the cast is not possible, javac will complain anyway.


String s = (String) x; // Why bother with a cast? "String s =" says all we need to know about what we want to happen.

Cas :slight_smile:

In two weeks this thread has more posts than WIDT.

You’re missing the point! Or deliberately ignoring it? :slight_smile: You’re proposing a syntax where something that can never throw a CCE and something that can are the same. The pattern matching or Kotlin typecasts actually ensure at compile time that you won’t get a CCE.

That made me laugh a lot! Not only are there loads of real projects in functional programming languages, but most of the big developments in the Java space at the moment are “functional”. One of the reasons being that your 30k-50k line project starts to become something that’s 5k-10k. More succinct and readable expression of program logic is a massive aid to maintainability.

Omg. I won’t comment this as it seems you are simply not interested in getting better. I can’t bei the only one who finds this hilarious.

To Bring this back to topic, i can only say that Kotlin makes writing good code (as of modern standards) easy while maintaining most of java’s good sides, including Performance.