btw I wonder if the “adjective before the noun” style is less pleasant to non-English natives than not because that’s how we do our natural language?
Eg. we have green apples, not pommes vertes, in the same way that we have Colored fruits not fruits: Colored.
Cas 
I guess type on the right was needed also because of inferred types, which I deep use and love
val i = 0
5 (or 10?) years ago they promised us annual releases - that didn’t quite happen
I certainly hope we get 6-month releases, but odds are we should be happy if we get 24-month schedules.
I’m a massive hater of val types.
Cas
Considering Java is getting inferred types in March, that doesn’t seem a correct assertion. Sorry @princec, you’ll just have to ignore them! 
I actually think we will get 6-monthly releases this time around, because it’s linked to changing the development model.
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.
Cas
Ah, thats very nice 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.
I’m also not believing this 6-month release cycle. It’ll likely be either:
Yes, 2. This is what I meant by the development model also changing. We will just see features dropping back when not ready. Remember there’s also an LTS aspect to this. And I can think of a few big projects that do keep their release cycles!
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.
The 6 month release cycle commitment is a realistic solution to the disastrous release cycles of Java 7 and Java 9, where hundreds of useful smaller features were held back by a couple of massive epic features. 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)
Cas
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!
I dunno, that blog post does not really conflict with how I see them running it.
Cas
Haha, what a whish 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 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.
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.
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
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 fucking dumb. I don’t want lazy kids foisting their half-thought out crap on me.
Cas
Well, you should see first how that will play nice with the type on the left… and I have my doubts
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…
@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
Gubbin gubbin = thing.getGubbin();
then it’s badly written anyway! ;D
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
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 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 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
val itemList = getItemList();
itemList.forEach { it.consume() }
would be better than
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.
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:
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