This issue becomes even more pressing with there being no Java7 (which is even more relevant after Snorcle - I wonder if javac is gonna be replaced with jdkc? :). So I guess javac has kinda reached its pinacle; closures look unlikely as does any kind of simplification or progression...
Though my tip though for the long term replacement of javac is Scala...
I'm very impressed with it! I can honestly say if someone had shown me the Programming Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy.
In the rest of his blog post, Strachan highlights some of the reasons he thinks Scala can serve as a long-term replacement for Java. For instance:
Scala seems to hit the perfect sweet spot between the consise feel of a dynamic language, while actually being completely statically typed. So I never have to remember the magic methods that are available - or run a script in a shell then inspect the object to see what it really looks like - the IDE/compiler just knows while you edit.
Yet Scala has type inference - so its typically as concise as Ruby/Groovy but that everything has static types. This is a good thing; it makes code comprehension, navigation & documentation much simpler. Any token/method/symbol you can click on to navigate to the actual implementation code & documentation. No wacky monkey patching involved, or doubting of who added a method, when and how - which is great for large projects with lots of folks working on the same code over long periods of time...
Another advantage of Scala Strachan mentions is that Scala allows one to gradually migrate from Java-style OO programming to a hybrid functional-OO style that can be especially helpful when writing concurrent applications:
It also lets folks gradually migrate from a traiditional OO/Java way of coding to a more functional way - which is particularly relevant for folks writing concurrent or asynchronous code (which due to the GHz of chips no longer going up but instead we're getting more cores is becoming more necessary). You can start the OO way and migrate to using immutable state if/when you need its benefits. Increasingly functional programming is becoming more and more important as we try and make things more concise and higher level (e.g. closures, higher order functions, pattern matching, monads etc) as well as dealing with concurrency and asynchrony via immutable state etc.
Scala options are an example how hard it is to create a clean language *and* remain compatible with an existing platform :)
If there was no need to interoperate with Java (or JVM in general), null could be abandoned and options used instead. This way, one cannot rely on a non-option value never being null, and that really reduces the usefulness of options. I ran into the same problem with F# and its option types.
> James, > > The more one studies Scala, the more nits one may find.
There are many things about Scala that I would change but I think people are getting the idea that I am hostile towards Scala (which is not the case) so I'm holding back. In the past my pleas that certain features be reconsidered have been summarily dismissed so I'm slowly coming to the conclusion that Scala just isn't for me.
> > James, > > > > The more one studies Scala, the more nits one may find. > > There are many things about Scala that I would change but > I think people are getting the idea that I am hostile > towards Scala (which is not the case) so I'm holding back. > In the past my pleas that certain features be > e reconsidered have been summarily dismissed so I'm slowly > coming to the conclusion that Scala just isn't for me.
I'll be the "hostile to scala" guy for this thread.
Scala has its place, but a *replacement* for Java? I don't know...
Aside from platform neutrality, the primary reasons Java became mainstream were familiarity and simplicity. Java's imperative OO foundation provided the necessary welcome mat to attract the leagues of existing C++ and VB programmers. It was relatively painless for most programmers to switch to Java.
In contrast Scala is a *functional* OO language. If the past 30+ years have anything to say about programming languages, it's that the vast majority of programmers prefer imperative ones over functional ones. Functional langauges had many opportunities to win us over, but they never did. They remain the sideshow. Why is that?
I can't speak for anyone else, but I think more in terms of the imperative OO model. I appreciate functional languages, but the best language for me is one in which I can easily express my mental model of the world. I don't think I'm alone. In my college days I recall students having significant difficulty grasping functional concepts. For instance, everyone had a rougher time with LISP than with Pascal (this was in the 80s). I don't recall anyone *choosing* LISP for projects. I don't think LISP is a bad language; it's relatively powerful and expressive. It's just not as natural to us as Pascal or Java.
The reason we switched to Java in the late 90s wasn't because it was like C++. We switched to take advantage of what Java had to offer above and beyond C++: plaform independence, it ran in browsers, servlets, garbage collection, etc. Big major huge features that we could not get from C++. Why would we switch to Scala? Why would a bottom line oriented business switch?
Eventually, I'd like to see Java evolve in the direction of C#. Feature-wise C# passed Java years ago. It's not perfect, but C# to me has the right balance: imperative OO with closures where they make sense. If Java gets there, fine. If not, well, some other language just might replace Java, but Scala? Nah.
> Eventually, I'd like to see Java evolve in the direction > of C#. Feature-wise C# passed Java years ago.
I believe Java will go the way of Python 3 at some point in its future i.e. break with the Java 1.X series and will provide an upgrade path for old code. That's probably even simpler for Java than for Python because it doesn't depend on tons of C extensions that have to be ported as well.
I don't think it'll ever replace Java, but it's nice to have some alternative languages. I personally find the Java language too restrictive, so it's nice when languages like Scala can widen the blinders a little bit more on what's possible within programming languages.
I also believe the "simple" Java syntax it given too much credit for the success of the Java platform. Just contrast library handling in Java with C++.
> I also believe the "simple" Java syntax it given too much > credit for the success of the Java platform. Just contrast > library handling in Java with C++.
Java made it simpler to program that C++ did, by giving us a C-like language that had GC. GC was the killer feature at first. After that, the libraries that built up in Java ended up dominating the landscape: they are complete and usually professional, although they are often overly technical and lacking the simple-API-for-simple-problems elegance of other languages like Ruby.
This is why I don't think Scala will be the next java. The next programming language should make it *simpler* for day-to-day developers to get work done. Scala certainly addresses many of the problems with Java and has some innovative and interesting ideas in it, but I can't help but feel that, when I look at a lot of Scala code, things are *more* complicated than Java, not less.
As an example, the implicit closure parameter syntax is a cute way to address the last few flits of closure syntax that might be objected to, but it is hard to read. Underscore's are small and difficult to see and there is no place where the underscore is declared. You just have to know. Similarly, allowing arbitrary operator overloading calls into question what exactly every operator in the language does. And so on.
Scala is certainly a more powerful language than Java, but it is more complicated as well. This will make it attractive to some thought-leaders, but I think it will ultimately limit its adoption amongst a wider audience.
> This is why I don't think Scala will be the next java. > The next programming language should make it *simpler* > * for day-to-day developers to get work done.
The problem I see is that we have almost contradictory language design requirements. We want languages that aid us in organizing code in the large, that lets us verify invariants, provide declarative elements that work uniformly, simplify concurrent programming etc. and we want languages that are easy to use, can flexibly adapt to heterogeneous environments and invite for metaprogramming which is against the grain of a rich default semantics.
And what can I say? We have those languages already. They are just not unified in one kitchen sink language which attempts to be all for every purpose. On platforms like the JVM or the CLR they are even well integrated with a preference for the static model but this is going to change right now.
Each language designer might try to invent the final language which turns the whole of programming into a single intellectual province and relieve us from being polyglot. More than one programming language is an anomaly that has to be corrected.
However reality isn't going to confirm this dream that was dreamed at least since the early 80s with Ada and Common Lisp and C++ and later with Java. Now Scala shall reinforce the fantasies of the monoglot and the inevitable responses are "uh, but it's not as simple as Ruby" which is not Scalas fault but a consequence of design decisions that make sense for a different kind of tool.
> Each language designer might try to invent the final > language which turns the whole of programming into a > single intellectual province and relieve us from being > polyglot. More than one programming language is an anomaly > that has to be corrected.
I believe that it is likely the case that no such language can be created. While it's true that there is a lot of unnecessary complexity in programming languages (in general) I think there's essential complexity to any given problem. When a programming language is simple, it's easier to master but takes more code to solve a given problem. When the language is more complex, it can take less code but the tool is harder to master. I don't think it's possible to change that. I can't prove this (even informally) but I feel that there should be some way to do so.
Flat View: This topic has 69 replies
on 5 pages