Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (775)
Games in Android Showcase (230)
games submitted by our members
Games in WIP (856)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3 4 ... 6
  ignore  |  Print  
  Move to Kotlin?  (Read 27942 times)
0 Members and 1 Guest are viewing this topic.
Offline nsigma
« Reply #30 - Posted 2017-11-07 12:36:10 »

They can easily hit a 6 month cadence and just ensure that no feature is ever designed to take longer than 6 months to implement. (If it does - it needs to be broken down into releasable steps)

That's not really the plan, though!  This is worth a read - gives a good insight into why this is different to what's happened before - https://mreinhold.org/blog/forward-faster

In particular as to why it's not about features only taking 6 months to implement!

Quote
New features will be merged only when they’re nearly finished, so that the release currently in development is feature-complete at all times

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #31 - Posted 2017-11-07 12:38:51 »

I dunno, that blog post does not really conflict with how I see them running it.

Cas Smiley

Offline h.pernpeintner

JGO Ninja


Medals: 106



« Reply #32 - Posted 2017-11-07 12:57:32 »

Yes, at least I can ignore them in my own code. Not looking forward to having to decipher everyone else's code though - which is exactly what I hate about them. It removes yet another bit of self-documentation from code and means I have to figure something out painstakingly for myself. And then assume the originator got their thinking right in the first place. Grr. Hopefully not too many serious library maintainers will use them.

Haha, what a whish Smiley Seriously, everybody will use it everywhere. And honestly, how can there be a problem about that? Okay, I agree that it shouldn't be used blindly everywhere - no feature should ever. But most of the times when you have local variables, it is perfectly fine to apply val/var, because it reduces the noise overall. I totally agree that there are situations where the usage might not be appropriate, but seriously, this is most often an issue with the surrounding code and not with type inference. Most cases are like final List<Item> itemList = getList(); which can now be val itemList = getList() . If you ever ask for the type, it is a list of items. No need to specify it any further. It would be even better if the method would be named getItemList(). Athough this should nowhere ever influence anything you do, because interfaces and javadoc and everything else stays the same... the only situation where you have to deal with it, is if you change sourcecode of someone else or if you debug someone else's code with sourcecode. But even then, if you want detailled info about the moethod and types etc, why not just press ALT-whatever and look up the type info in the IDE? Completely refusing to use a feature that the majority of the worlds developers found out to be very nice for both readers (in cases) and writers seems to be strange for me. But of course, you could always type the complete type if you like to.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline h.pernpeintner

JGO Ninja


Medals: 106



« Reply #33 - Posted 2017-11-07 13:14:07 »

I believe JetBrains themselves are responsible for the Kotlin support, so perhaps ask there?  In terms of NetBeans issues, better to file in the Apache NetBeans JIRA.  Things a bit in flux at the moment around the old NetBeans site.

They host the repository, but they say that after the initial release it's the community's job to do further development. It seems that cross language projects simply are specifically problematic for netbeans, as it didn't work for groovy for me either. Since the eclipse plugin doesn't have these problems, my guass is strengthened. There is a issue https://github.com/JetBrains/kotlin-netbeans/issues/124 but not yet a response. I took a coarse look at the code and I simply can't figure out what the problem might be without investing way too much time on netbeans intrinsics.
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #34 - Posted 2017-11-07 13:31:48 »

Completely refusing to use a feature that the majority of the worlds developers found out to be very nice for both readers (in cases) and writers seems to be strange for me. But of course, you could always type the complete type if you like to.
Never make the mistake of trusting the majority to make a wise decision.

I'm far older and far wiser than the vast majority of programmers on the planet today. I know a lot of things they don't. And I know why this feature is a crap idea, because it removes self-documentation from the code to gain... what? Typing a few less characters? Do we end up with people writing
1  
2  
val gubbin = thing.getWotsit();
gubbin.doTheThing();

Look at that code. Tell me what doTheThing() does, and to what. I quite fancy changing it to doTheOtherThing() but I've no real idea whether gubbin might actually support that without going digging in the docs for getWotsit().

It's f**king dumb. I don't want lazy kids foisting their half-thought out crap on me.

Cas Smiley

Offline elect

JGO Knight


Medals: 60



« Reply #35 - Posted 2017-11-07 14:08:02 »

Considering Java is getting inferred types in March, that doesn't seem a correct assertion.

Well, you should see first how that will play nice with the type on the left.. and I have my doubts

Ah, thats very nice Smiley So you can explain, why Netbeans isn't able (is it?) to handle multi language projects? I tried to do a project in Kotlin and Java and afterwards in Groovy and Java and neither worked. It told me there are symbols that can't be found. Pretty much the only issue I had in an IDE with Kotlin. Sadly, I can't find any info on this and the corresponding issue is ignored heavily.

Unfortunately they shut down the development of the netbeans plugin..


@princec, I also had your worries at the begin, but now that I'm used to, I can tell you that it's hardly a problem. I'd say it's just a matter of thinking and getting used to..
Offline nsigma
« Reply #36 - Posted 2017-11-07 14:14:27 »

@princec so I assume you don't use lambdas or explicitly type all the lambda parameters?!  Good self-documenting code also requires sensible variable and method names, so unless your example is actually equivalent to

1  
Gubbin gubbin = thing.getGubbin();


then it's badly written anyway!  Grin

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #37 - Posted 2017-11-07 14:23:20 »

I use lambdas all the time and actually they suffer some of the same problems. Fortunately they remove so much boilerplate it's more of a win than not.

Cas Smiley

Offline h.pernpeintner

JGO Ninja


Medals: 106



« Reply #38 - Posted 2017-11-07 14:53:34 »

Never make the mistake of trusting the majority to make a wise decision.

It's not about making a decision, it's about being open for anything but one's own experience. You should never be that ignorant that you position yourself to know everything better then all the other people. You should always ask yourself carefully, if the problems you are pointing out may be the problems of your own inflexibility. And if some new aspects that may not fit in your workflows maybe don't do it because your workflows are not as efficient as you think, because you didn't change them for a long time. That makes you closed for positive new influences, makes you blindly not listening to others - see below why I think this is happening to you.

I'm far older and far wiser than the vast majority of programmers on the planet today. I know a lot of things they don't. And I know why this feature is a crap idea, because it removes self-documentation from the code to gain... what? Typing a few less characters? Do we end up with people writing
1  
2  
val gubbin = thing.getWotsit();
gubbin.doTheThing();

Look at that code. Tell me what doTheThing() does, and to what. I quite fancy changing it to doTheOtherThing() but I've no real idea whether gubbin might actually support that without going digging in the docs for getWotsit().

It's f**king dumb. I don't want lazy kids foisting their half-thought out crap on me.

I don't know why you are a programming god, but I know that it seems that you didn't even read what I wrote. That's a thing of personality, not of programming profession Smiley I gave a clear example, that most of the times type inference is not a good choice (like in your example as well), the reason is not type inference itself, but bad surrounding code. Would you agree, that in my example
1  
2  
val itemList = getItemList();
itemList.forEach { it.consume() }

would be better than
1  
2  
List<Item<Parameterization>> itemList = getItemList();
itemList.forEach { it.consume() }


This is not about being lazy - it's about being appropriate. If people have the choice to use type inference where appropriate, you can always critisize one's code if it's not appropriate, like with every other coding construct before.
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #39 - Posted 2017-11-07 15:15:14 »

I absolutely did read what you wrote, and disagreed with it. Your example was clear - and it clearly showed me what I don't like.

In your example:
1  
2  
val itemList = getItemList();
itemList.forEach { it.consume() }

How do I know itemList has a consume() method? I don't know what type it is, just by looking at it. This is a trivial single example but now reckon on it being used everywhere, throughout the entire codebase. And then look at it in TextPad because you don't have Eclipse handy to ctrl-click about all the definitions and Javadoc. It makes my brain, the reader and maintainer of the code's brain, work harder for the entire rest of the lifetime of that code, and I don't want it to work harder, whilst saving you, the author, a few moments of thinking.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #40 - Posted 2017-11-07 15:27:14 »

What would have been much more useful to my mind was implicit casts instead:
1  
String s = thing.getObject();


Cas Smiley

Offline nsigma
« Reply #41 - Posted 2017-11-07 15:35:01 »

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

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

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline h.pernpeintner

JGO Ninja


Medals: 106



« Reply #42 - Posted 2017-11-07 15:37:48 »

I absolutely did read what you wrote, and disagreed with it. Your example was clear - and it clearly showed me what I don't like.

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:

In your example:
1  
2  
val itemList = getItemList();
itemList.forEach { it.consume() }

How do I know itemList has a consume() method? I don't know what type it is, just by looking at it. This is a trivial single example but now reckon on it being used everywhere, throughout the entire codebase. And then look at it in TextPad because you don't have Eclipse handy to ctrl-click about all the definitions and Javadoc. It makes my brain, the reader and maintainer of the code's brain, work harder for the entire rest of the lifetime of that code, and I don't want it to work harder, whilst saving you, the author, a few moments of thinking.

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?
1  
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 Smiley
Offline 65K
« Reply #43 - Posted 2017-11-07 15:42:50 »

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

Lethal Running - a RPG about a deadly game show held in a futuristic dystopian society.
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #44 - Posted 2017-11-07 15:48:30 »

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 Smiley

Offline h.pernpeintner

JGO Ninja


Medals: 106



« Reply #45 - Posted 2017-11-07 16:35:15 »

What would have been much more useful to my mind was implicit casts instead:
1  
String s = thing.getObject();

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

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #46 - Posted 2017-11-07 16:41:03 »

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 Smiley

Offline elect

JGO Knight


Medals: 60



« Reply #47 - Posted 2017-11-07 16:42:17 »

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

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..
Offline EgonOlsen
« Reply #48 - Posted 2017-11-07 16:51:28 »

Very serious indeed. I am beginning to suspect there may be some language or cultural misunderstanding between you and me.
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.

Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #49 - Posted 2017-11-07 16:53:59 »

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 Smiley

Offline 65K
« Reply #50 - Posted 2017-11-07 17:03:23 »

shall we really evaluate a language based on how much we can understand by reading foreign code displayed via a browser outside an IDE?
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.

Lethal Running - a RPG about a deadly game show held in a futuristic dystopian society.
Offline nsigma
« Reply #51 - Posted 2017-11-07 17:48:25 »

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.

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

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #52 - Posted 2017-11-07 18:45:11 »

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 Smiley 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 Smiley

Offline Icecore
« Reply #53 - Posted 2017-11-07 18:50:26 »

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  Roll Eyes

Last known State: Reassembled in Cyberspace
End Transmission....
..
.
Journey began Now)
Offline nsigma
« Reply #54 - Posted 2017-11-07 18:51:11 »

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.

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.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline h.pernpeintner

JGO Ninja


Medals: 106



« Reply #55 - Posted 2017-11-07 19:07:15 »

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 Smiley 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 Smiley

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.
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #56 - Posted 2017-11-07 19:15:20 »

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.
1  
String s = (String) x; // Why bother with a cast? "String s =" says all we need to know about what we want to happen.


Cas Smiley

Offline KaiHH

JGO Kernel


Medals: 636



« Reply #57 - Posted 2017-11-07 19:17:31 »

In two weeks this thread has more posts than WIDT.
Offline nsigma
« Reply #58 - Posted 2017-11-07 19:26:12 »

It's never safe, and throws CCE at runtime.

You're missing the point!  Or deliberately ignoring it?  Smiley  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.

same about functional languages – fluffy for kids and nightmare for real projects

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.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline h.pernpeintner

JGO Ninja


Medals: 106



« Reply #59 - Posted 2017-11-07 19:32:25 »

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.

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.
Pages: 1 [2] 3 4 ... 6
  ignore  |  Print  
 
 

 
hadezbladez (43 views)
2018-11-16 13:46:03

hadezbladez (47 views)
2018-11-16 13:41:33

hadezbladez (25 views)
2018-11-16 13:35:35

hadezbladez (19 views)
2018-11-16 13:32:03

EgonOlsen (1896 views)
2018-06-10 19:43:48

EgonOlsen (1930 views)
2018-06-10 19:43:44

EgonOlsen (1285 views)
2018-06-10 19:43:20

DesertCoockie (1716 views)
2018-05-13 18:23:11

nelsongames (1404 views)
2018-04-24 18:15:36

nelsongames (2038 views)
2018-04-24 18:14:32
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!