like a university professor, dusting off some old notes for a 'new' lecture. Students are meanwhile doing crazy exciting stuff out there.
while the university professor earns per month what the students get per year.
Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler
101–110 of 149 posts
Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler
#102Earlier quoted context omitted.
There are languages on the JVM as well with far less boilerplate, that still give you static typing, performance that is compatible with Java, and the whole ecosystem. For instance, Scala and Kotlin.
Scala's compilation was really slow the last time I tried. It's also a really complex language and I found some parts ugly.
I find most of it ugly. But I'm looking forward to Kotlin. I believe Kotlin is what most of us had hoped Scala would be when it first came out, before it turned into the unholy Java-Haskell-Lisp-C++-Javascript hybrid that it is today.
Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler
#103Oh, shucks. I was expecting to see an article on compiling Java to machine code, not bytecode.
Just look for a compiler design book.
Compiling some form of bytecode into machine code, is part of any compiler design course worth its name.
Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler
#104Earlier quoted context omitted.
I think calling Go a simplified Java is pretty far off the mark. Aside from both aiming at the niche of being sort of "medium-level" languages, for lack of a better term, Go's approach seems very different from Java's. Objects vs structs and functions, exceptions vs multiple return values, required static vs required dynamic linking, implicit vs explicit subtyping/interfaces, etc. Go is C with added convenience.
Structs + interfaces in Go are a re-interpretation of Java interfaces (albeit a major one). It's a different path, but the same philosophy (dynamic dispatch over receiver type + mutable state). Exceptions vs. multiple return values are two different local decisions made by Go's designers: multiple return values and lack of exceptions. Multiple return values are handy (might find their way to Java one day), but I woul…
Not so! Go explicitly exposes indirection, while every Java object is a pointer. The result is that control of what is in L1 with Java is impossible, while memory locality can be forced in Go.
Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler
#105Earlier quoted context omitted.
> Its next impossible to deal with any large Java project without an IDE True, but I don't see it as a problem (for me). > The verbosity of the code is mind boggling. I don't find Java that verbose (especially with lambda functions in Java 8). > method calls are 4 - 6 layers deep I don't understand, do you mean nested method calls? > 90% of that is machine generated through eclipse. Definitely not 90% and lot of the…
I like working with Java too. I'm only pointing out the problems, which I see are pretty clear. The only problem is from the perspective of using and developing a new skill, I would rather use a newer language which is better built for problems of our time than something 20 years back. Java has had its day in the sun. Its primary purpose was to become an easy C++ for people who didn't get memory management and people…
Ok, what language would you suggest as an alternative?
I've written code in lots of different languages and I haven't found a replacement yet (C# is closest, but I mostly do Android development, on Linux).
Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler
#106Earlier quoted context omitted.
> I really want type inference, lightweight objects, properties (vs JavaBean accessor convention), switch for 'instanceof', etc. I believe you're asking for Scala. For example, switching on types: trait Foo class Bar extends Foo class Baz extends Foo val thing = // could be either bar or baz, don't know thing match { case f: Foo => println("Got foo") case b: Bar => println("Got bar") }
:) Our study group has done two Scala tracks (and currently studying Akka and reactive programming). Ruby and Scala make my head hurt. I don't have a mental model for what's happening under the hood. Unlike LISP, Forth, Java, etc. I really do want a refined, simplified Java. My wishlist of features are gleened from Boo (minus the duck typing), Nice, and Kava (lightweight objects). http://boo.codehaus.org http://nice.…
You're not alone. Scala has the features you're looking for, but it's also a mashup of Haskell and Lisp and C++ and a few other mismatched languages. As I said in another comment, Scala is for people who find Haskell too simple, and want to add mutability, inheritance and macros on top of it.
I think that what you're really looking for is Kotlin: http://kotlin.jetbrains.org/
Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler
#107One of the things I see with Java today, how difficult things have gotten with the language. Its next impossible to deal with any large Java project without an IDE. The verbosity of the code is mind boggling. Often method calls are 4 - 6 layers deep, which in itself makes is very difficult to remember or even implement even if you read the documentation well. The resulting code is massive walls of text. 90% of that i…
> Its next impossible to deal with any large Java project without an IDE True, but I don't see it as a problem (for me). > The verbosity of the code is mind boggling. I don't find Java that verbose (especially with lambda functions in Java 8). > method calls are 4 - 6 layers deep I don't understand, do you mean nested method calls? > 90% of that is machine generated through eclipse. Definitely not 90% and lot of the…
> I don't find Java that verbose (especially with lambda functions in Java 8).
Honestly: use something better for a while and come back and say that. Java is verbose. There is a ton of ceremony around anything in it, from ill-considered defaults that require lots of specification (see Scala's remarkable ability to strip bullshit out of its equivalent to Java code) to the cultural design-pattern mess.
It's a lowest-common-denominator programming language, and it shows because it takes such pains to spell everything out every time. JDK8 lambdas sort-of help, but the language is still fat.
> I don't understand, do you mean nested method calls?
I think that's pretty straightforward and that these two go together.. You basically have to use an IDE (and while I am comfortable in an IDE this is a negative in the general case due to the complexity it implies) because you need go-to-definition all the time due to what is, frankly, class and method bloat. This method hands off to this manager class method which hands off to this class that exists just as a temporary stateful container and all of them add more boilerplate and force you to maintain more mental state and blurgh. I was guilty of it as a younger programmer, but I've aggressively tried to move away from that; some people don't seem to ever grow out of it.
> What language would you suggest as a Java alternative?
Scala. I'm a former Java web dev, current Android developer, and if I could shoot all my Java code between the eyes and replace it tomorrow with Scala I'd be a happy man. It's a language that aggressively attacks the idea of design patterns by making the language more expressive (whereas Java just codifies them).
My new projects are exclusively Scala, and I'm turning out better, more readable code in shorter time. The JVM is fine, but Java-the-language and Java-the-culture are toxic as hell. And while it's no doubt harder to hire Scala programmers, the floor on quality is going to be a lot higher than Java programmers when I need to hire them.
Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler
#108Earlier quoted context omitted.
Scala's compilation was really slow the last time I tried. It's also a really complex language and I found some parts ugly.
I find most of it ugly. But I'm looking forward to Kotlin. I believe Kotlin is what most of us had hoped Scala would be when it first came out, before it turned into the unholy Java-Haskell-Lisp-C++-Javascript hybrid that it is today.
I quite like Kotlin at first sight but I currently use Eclipse... (looks much better on Linux than IDEA) I'm also looking forward to Ceylon.
Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler
#109Earlier quoted context omitted.
My impression was that e.g. support for multiplatform GUIs or Mono's speed wasn't as good as Java.
Mono's speed is a valid point, but I think that's more of a Mono implementation issue than a C# problem.
Yes, C# as a language is without question better than Java but in terms of the whole ecosystem, it's not that clear...
Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler
#110Earlier quoted context omitted.
One problem of many is that Java is quite verbose, and while IDEs like Eclipse help with this, there's a significant contingent of open source developers who both refuse to use typical IDEs and who also like to manually manipulate their code rather than let an IDE tweak it about. Languages like Ruby and Python make that easily manageable in a way Java doesn't.
This is one of the reasons I use Go in favour of pretty much anything running on the JVM stack. I don't have to change my workflow at all between working in Python, C, Go and JS. I can use vim for all of the above and none of them force me to have years of experience with an IDE in order to be productive.
I'm learning Go right now by writing a small part of my current project in it. I like it quite a lot (mostly for its concurrency features) but it is actually a surprisingly verbose language compared to Java.
First of all you have this on about every second line:
if err != nil {
return err
}
Go:
func (MyType* mt) myMethod(s string, i int) (string, error)
String myMethod(String s, int i)
You can't specify default values for structs, so you often need an extra function that constructs a default instance of the struct and initializes its fields.
And the lack of generics means you have to write a lot of things several times for different types.
Lambdas are very verbose as well. You get no type inference even in contexts where it would be simple to do:
Go:
filter(func(s string, n int) { return len(s) filter((s, n) -> s.length Go's simplicity is a double edged sword. Lack of verbosity is definitely not its strength.
Obviously there are many counter examples where Java is more verbose than Go. But they are very well known by now so I'm not going to repeat them here.