I’ll let him tell you his situation, but you don’t know the people behind the screen names. You can’t make assumptions about people without any background. Sure, your own utopia sounds fine and dandy, but it simply doesn’t work like that, especially for other people with an entirely different life.
IMHO he has given perfectly reasonable reasons as to why he “persists” with Java, and I have never seen any faulting of others for personal “issues” from him.
I’m not trying to judge his soul or worth as a human. If he says he is sick of programming, I will tell him to at least consider giving it a rest and trying something else for a change. There are minimal personal assumptions being made.
Since this thread is about JDK 8 programming language and syntax innovation: you can’t counter a point about type inference or types on the right vs C-style with all kinds of personal issues.
If/when he replies, you will likely see the massive irony here.
Pretty sure you can, given that the use of any programming language is a personal choice, at least if you are your own boss. (Spoiler: Cas is.)
Especially since he never said either was objectively ‘better’ than the other, he merely is stating his opinion. Everyone has the right to their opinion.
If you want to help with on-topic discussion, let’s talk objectively why the new JDK is better than what it was.
I eagerly await the unveiling of this massive irony 
[quote=“BurntPizza,post:125,topic:47533”]
Ideally the opinions shared are interesting or relevant. If you don’t like Scala syntax because it involves change and you have some dark personal trauma to deal with… You should probably be dealing with the dark trauma and not posting on this board.
Didn’t I just post on several specific JDK 8 features that I feel are really useful: map, filter, fold, and Optional?!?! No one commented on those.
Be nice, or I’ll MAKE you nice! :cranky:
(wait wut?)
On topic: structs coming from Oracle will be 2-3 years away. Besides, if you don’t control whether they are stack allocated, heap allocated or mapped to a ByteBuffer, it’s of little use, as the JVM has a pretty bad track record on escape analysis, and being able to map structs is pretty much mandatory to achieve any high performance goals. The issue however is that the JVM has to somehow guarantee that the backing buffer of the struct(s) isn’t janked from underneath, resulting in memory violations or (worse?) undefined behavior.
We saw how they enforced these guarantees with MappedByteBuffers, which as a result are pretty much useless. I fear we’ll be dealing with garbage collected structs.
Wow, you are truly a veteran. Respect that you managed to hang on for so long, I’m pretty sure I’m going to stop doing programming for a living when I hit the 20 year mark to prevent becoming busted, cynical and jaded before I get old. Maybe because I want to stop or maybe because the market forces me, I don’t like the way its evolving right now.
I think the last thing I want to do before I go out is design a user interface scheme for tablets and phones (or whatever device they come up with by then; maybe laptops will be back in fashion) which you operate by banging your head against the screen.
Interesting subject, but completely off topic from JDK 8. I’ll start a new thread…
Hmmm… Interesting discussion. So Java 7 is to if-else as Java 8 is to ternary operator? :point:
There is a subtle truth to what Cas said. If you want a new language, you just switch to it. But, it is unproductive to continue learning new languages every time a small feature is wanted. Java is very close to perfection, but I feel its connection to its legacy code is what is keeping us from getting all we want from the language.
I mean, Java has flexibility on its side. We are able to leverage C, JavaScript, Python, and other languages easily without being a dreaded glue language. There is a novelty that other languages can’t match. Structs is and always will be the most wanted feature for me. Seriously, I can survive without much else… But the speed that it offers when programming C is just… unmatched and hard to replicate in Java.
Honestly, Java 8 is just a weak update. We got a few syntax improvements and a little bit of JVM improvements. In the grand scheme of things, I feel we are in no better position than we were in Java 7. The bigger looming problems still remain, like how people still have security issues. Also how Java is just getting harder to deploy due to them completely ridding of Applets and Webstart.
Languages are made so we have it easier to deploy applications. With Java, the amount of hoops we have to jump through is just making it harder for us as well as our user base to run something. Honestly, making Java easier to deploy for end users is the most important thing.
In my opinion, I am tired of celebrating syntax improvements. They are nice, but I feel as a development community for Java, we are grasping at straws. We should fight to make Java more accessible. It is shameful that a language that runs everywhere has so much problems with easy deployment. It is shameful that we can’t even guarantee each user will be able to share a similar experience due to them blocking Java completely.
This thread was doomed to derail. I mean, to me… I just feel as though Java 8 is a very small step, but it lacks direction. The update doesn’t change anything for users. It barely changes anything for us, other than helping our programs be a little smaller and faster for less readable code. I just hope our user base stays long enough to hit Java 9…
Well, syntax improvements are important in one area: advanced concurrency code. The anonymous inner class syntax really got in the way of writing maintainable code. Barely anybody uses Java for this usecase, but we’ll have to see whether that was a chicken and egg problem.
It seems to me that there is some pretty big blowing off the changes in this release makes in terms of things you can now easily do in plain old java. It’s not too surprising since, quite frankly, examples you’ll find floating around a very boring.
Java isn’t a rewriting language. Neither is scala (unless I misread the spec or it’s been added since). So the only choice is for this to go into a compiler. You suggestion shows you don’t understand why it’s an issue. And a pretty minor one on it’s own…more interesting if we got flattened into the container and field accessors for elements.
I understand languages pretty well. Don’t underestimate people’s knowledge.
It’s a pity that Oracle charge companies for distributing commercial java programs on ARM devices.
What kappa linked to about asm JavaScript is pretty amazing. That sounds like the way forward
Reified types would be nice, but I don’t think they’re going to happen. Too many problems with backwards compatibility.
Maybe…maybe not. There’s been some talk about killing off String identity…that’ll certainly break some things. For real generics all you’d really need is an option to suppress the verifier from puking.
Java applets are dead and that’s a good thing. Users should block Java in their browser. But users are fine with embedded runtimes and libraries that they don’t have to think about. Look at games like Wakfu that embed a Java runtime where most users don’t even realize the game was completely written in Java.
If you are waiting for a new version of Java or some other external factor to make the product that you want, you are just making excuses for yourself.
Nothing should be holding you back today from making the product you want to create.
Type erasure sucks. Again: type refinement as an example. The real problem isn’t the coding (which is easy) of the thing…it’s that it would have required a change in the verifier. As since the verifier isn’t enforcing we have to jump through dumb hoops that everyone (compiler & runtime) “know” aren’t needed.
For me: nothing is holding me back. That product just doesn’t run on the JVM. 
Are you sure about this? If so, it seems that all I’m missing expect operator overloading is scheduled for java 9. Happy times (in 3-4 years)!
I don’t follow what you are saying at all. The verifier internal to the JDK? Are you talking about performance issues?
“barely anybody” == less than 1% / a tiny minority, I stick by that statement, as very, very few Java developer actually grasp advanced concurrency theory and behavior in the JVM.
I never said it wasn’t awesome, or not full featured. The code to use these gems, however, extremely verbose and hairy, which was what I identified as a problem…