pls lukas, give me an example where break & continue are really needed.
back to topic: I would really like to see modularization of the VM come true.
+1 for operator overloading.
Also ability to allocate temporary objects to the stack.
Modularisation would be very cool. It’s definitely coming, only a matter of time: http://mreinhold.org/blog/on-the-next-train
I’d actually prefer a protected default access modifier so that classes can be more easily extended and modified.
Java as a language is cool, but as a platform it really needs to get in the browser in a more satisfactory way than applets and webstart.
I’m hoping that with the incredible open-source movement in java and software in general right now and all of the associated language-converters/alternative VM’s/compilers/transpilers popping up (GWT, RoboVM, Avian and so on) that we’ll all be able to code in java using the standard java API library on any platform we want, whether it’s desktop window apps, browser based applets, embedded devices, consoles or whatever.
@lukasz1985
Optimization for functional programming is comming in Java 8.
Scala may not be a good choice for a game engine but no JVM language really is.
Having to maintain shared state yourself is like having to manage memory yourself. For most kinds of software it’s better to leave that to the compiler/runtime system.
I think immutable data is the perfect solution for multithreading. Compilers just have to get better at optimizing that stuff.
The lack of break/continue is not a big deal. The philosophy of Scala is that any loops that need break/continue should be written with recursion (Scala has nested methods and tail call optimization).
Functional programming has been around just as long as object oriented programming ( Look up Lisp). Scala is just another functional language that has a different structure like the rest. Check out F#, Haskell, or even OCaml. To say things like “Scala will never ever replace Java with that weirdness” just goes to show that you are trying to talk for a general population when in fact you don’t even know what you are talking about.
All that says is that you are very close minded to new programming methods and techniques. There is, in fact no “right and wrong” way to program, outside of what gives you errors and what doesn’t. From the sounds of it, you just dug yourself into a little hole of Java, and are too scared to come back out.
This applies only to object oriented and procedural programming. Again, get out of your little Java box and realize there are different ways to program that are just as viable and useful as OOP.
[quote=“lukasz1985”]
I couldn’t agree more.
If people simply wised up and started doing everything the "Right Way"™ many conflicts could by avoided.
http://www.asimovs.com/2012_08/ref.shtml
Scala is the Perl of the functional programming world: it’s an ugly colossal mess with lots of warts and weird features from legacy versions, but still damn useful, and every language that professes to repudiate it will still find a feature from it they want to borrow.
If Scala doesn’t turn your crank, maybe give Kotlin a try. Or hell, take Clojure out for a spin.
Scala is really good as it allow you to program (almost) literally as you like. Too bad NetBeans don’t support it too well and I am forced to use (much worse) Eclipse when I want to do something in it. 
Err…functional programming has been around MUCH longer than OOP. OOP came from LISP. I wonder if the original folks that working on OOP still want to bang their head on the wall when they hear people talk about “types”, much less “strongly typed OOP…and the OOP ‘way’ of doing things.”.
Comparing anything to Perl is cruel.
Got nothing new to say toward the topic that I haven’t already ad nausem.
Both paradigms were realized in the 50’s. Neither were fully implemented until the 60’s (LISP was considered a multi-paradigm language). To say functional programming was around a lot longer isn’t quite accurate.
One thing I would like is the ability to better fine tune the visibility of classes and methods. Often times I will want a class to be accessible by another class in a different package (maybe a sub package) but not publicly accessible.
C++ has this with friend classes. A feature I never use.
That said, the closest thing to a ‘friend’ class in Java is an inner class (which I use a lot)
I don’t know much but is friend classes something like partial classes of C#?
Well, partial classes in C# compile into one class from various other partial classes but they alone aren’t different classes. Friend classes are different classes but ‘friends’ have access to private members of their friends.
Partial Classes in C# are used a lot for partial code generation. I.e, to isolate generated code in a class from written code. For example, .Net has a form editor that edits a partial class of the form. Then the user programs into the other part for event handlers etc.
It’s a cool feature, and it would be nice if Java supported it. Especially because any Form editors in Java demolish any sense of maintainability to the code.
Thanks for that clarification. Can you also give some examples where friend classes can be useful? I don’t think they are used often.
I’ve honestly don’t use them that much. But they can be compared pretty well to Java Inner Classes; and now that I think of it, where ever I’ve used an inner class in Java I would probably translate that in C++ to a friend relationship with my parent class.
An example for where you’d use a friendship in C++ is when you wanted a private inner class. You could protect your inner class’s constructor and accesses with a friend relationship to it to instantiate it.
I’m not entirely sure if the logistics of that example are correct though, as I rarely ever use inner classes in C++.
I would like to see Java follow .Net in discarding checked exceptions. Allow them still be included as part of a method declaration, but not force them to be caught or declared. Far too often often novice programmers will take them option of catching and suppressing them, when that is quite often inappropriate. Java already has a mechanism in place for handling uncaught non-checked exceptions which should be used more often.
We’re taking different perspectives. LISP is meta, but it’s the first language that truly allowed writing in a functional style…at least in my option. Although bits-and-pieces of OO do indeed date to the 50s, SmallTalk is the first real OO language…and that’s much later…call it 1980, but only on a very limited scale. I suppose one could argue Simula, but (again IMHO) it was an important step along the way but not there yet.
It didn’t do anything to C++.
Bad programmers created operator overloading messes, not the language. It’s a shame such useful functionality for responsible programmers has to be excluded because they were afraid of people abusing it. Which is stupid logic, because there will always be ways to abuse a languages features and make it look dumb.
System.exit(1);
A fine example of code that should never be allowed… bah! An application should have a proper shutdown protocol so all resources are properly disposed, bah! /sarcasm
Anyway, here are things that Java won’t have with the newest version (which adds lots of things I’ve been drooling over) that I’ve been wanting:
- structs - by this I mean a fixed-size object in memory that can easily be written and read from streams. something that doesn’t get instantiated, it gets passed around by value. (ignore the fact that c++ classes are the exact same as structs, I’m using the term struct because many don’t realize in C++ they’re basically the same thing).
- passing primitives and structs by reference (optionally of course) - with parameters AND returned variables
- operator overloading - all overloadable operators that c++ currently provides
- manual memory management - two new operators called alloc and delete which creates objects on the heap outside of the JVM. these objects have to be structs (or just fixed-size) and have to have a destructor
- pointers
- templating - java generics are nice in many instances, but templating offers things generics can’t even come close to.
- methods that return more than one thing
Now that I think about it… I pretty much want C++ but with Java syntax and cross-platformness.
This is kinda the same kind of argument that “Guns don’t kill people, people do” (strawman, I know). In the end, it doesn’t matter, because we are left to clean up the mess.
This is the reason, I don’t want operator overloading: in the end, some of the code ends up in my workspace sooner or later and I will have to deal with it or clean up the mess or whatever comes.
What I would like to see, however, is modular JRE, which hopefully is coming.
And function pointers or method references.
Other than that, java is fine for me, not looking for a replacement nor has any other jvm language (that I have taken the liberty too look at) impressed me enough to try em out.
Edit: On some occasions I’ve missed multiple inheritance too.