Sun has announced that their next language release, Java 7, which was expected in 2008 will now occur sometime in 2010. The big changes that were expected were the additions of closures and properties. Neither of those seems likely now. The focus for the next release now seems to be modularity, but it looks to me like it's one of those "everybody thinks it's a good idea, but nobody wants to do it the same way" kind of problems, which was the big problem with closures.

To be fair, they have released a significant update, Java 6 update 10, and a new scripting language, Java FX Script,  built on the JVM. But it just seems like the language and the community have gotten so big  and unwieldly that it can't evolve any more. Like everyone else, Sun is looking for "the next Java".

Of course, participants in this forum know that "the next Java" is already here...

Paul

"Paul D. Anderson" <paul.d.removethis.anderson@comcast.andthis.net> wrote in message news:ghmqs6$1g9c$1@digitalmars.com...
> Sun has announced that their next language release, Java 7, which was expected in 2008 will now occur sometime in 2010. The big changes that were expected were the additions of closures and properties. Neither of those seems likely now. The focus for the next release now seems to be modularity, but it looks to me like it's one of those "everybody thinks it's a good idea, but nobody wants to do it the same way" kind of problems, which was the big problem with closures.
>
> To be fair, they have released a significant update, Java 6 update 10, and a new scripting language, Java FX Script,  built on the JVM. But it just seems like the language and the community have gotten so big  and unwieldly that it can't evolve any more. Like everyone else, Sun is looking for "the next Java".
>
> Of course, participants in this forum know that "the next Java" is already here...
>
> Paul
>

Java was dead to me the moment I discovered C# (which was before I came across D). And even before that, I considered Java a suitable replacement for C++ *only* in occasional circumstances. Ever since then, Java's enourmous popularity has just sickened me. Although, to it's credit, there are certainly worse languages in heavy use (PHP, VBScript).

Paul D. Anderson wrote:
> Sun has announced that their next language release, Java 7, which was expected in 2008 will now occur sometime in 2010. The big changes that were expected were the additions of closures and properties. Neither of those seems likely now. The focus for the next release now seems to be modularity, but it looks to me like it's one of those "everybody thinks it's a good idea, but nobody wants to do it the same way" kind of problems, which was the big problem with closures.
> 
> To be fair, they have released a significant update, Java 6 update 10, and a new scripting language, Java FX Script,  built on the JVM. But it just seems like the language and the community have gotten so big  and unwieldly that it can't evolve any more. Like everyone else, Sun is looking for "the next Java".
> 
> Of course, participants in this forum know that "the next Java" is already here...
> 
> Paul

There are better languages than Java. And the way Java seems to be used these days is as an enterprisey elephant, not the lithe "Smalltalk with C syntax" it was originally imagined to be. But that's mostly a reflection on the current development environment than anything else. I'm glad Java isn't "evolving" a huge amount. There are a lot of great language features, but C# and D are starting to look like monsters with their "everything in the kitchen sink" approach (c.f. C++). In Java, there's usually one way to do something. Sure, occasionally that way doesn't fit, but more often than not, it's better than having 10 ways, none of which are used consistently.

Robert Fraser wrote:
> There are a lot of great language features, but C# and D are starting to look like monsters with their "everything in the kitchen sink" approach (c.f. C++). In Java, there's usually one way to do something. Sure, occasionally that way doesn't fit, but more often than not, it's better than having 10 ways, none of which are used consistently.

I wish it were possible to have a language with just a small set of features that can do everything. C++'s problem is it can approximately do everything but with a boatload of gotcha's, like a const system that almost works but doesn't deliver. Java threw out too much.

It's like when I was a kid working on my car. I only had the barest basic set of tools, as I had no money. Most of the work I did was twice as difficult as it needed to be because I had to make do with basic tools. Now that I'm older, I just go buy the right tools, and man that makes things easier. And yes, I have a shop with a lot of tools in it <g>.

For example, it's so nice to have an actual *drill press* rather than a cheapo electric drill.

On Wed, Dec 10, 2008 at 12:34 PM, Walter Bright <newshound1@digitalmars.com> wrote:
> Robert Fraser wrote:
>>
>> There are a lot of great language features, but C# and D are starting to look like monsters with their "everything in the kitchen sink" approach (c.f. C++). In Java, there's usually one way to do something. Sure, occasionally that way doesn't fit, but more often than not, it's better than having 10 ways, none of which are used consistently.
>
> I wish it were possible to have a language with just a small set of features that can do everything. C++'s problem is it can approximately do everything but with a boatload of gotcha's, like a const system that almost works but doesn't deliver. Java threw out too much.
>
> It's like when I was a kid working on my car. I only had the barest basic set of tools, as I had no money. Most of the work I did was twice as difficult as it needed to be because I had to make do with basic tools. Now that I'm older, I just go buy the right tools, and man that makes things easier. And yes, I have a shop with a lot of tools in it <g>.
>
> For example, it's so nice to have an actual *drill press* rather than a cheapo electric drill.

Sounds like you're asking for Lisp.  Small number of features with which you can do just about anything.  All using only oatmeal and toenail clippings!   Lua is a bit like that too, except the toenail clippings part.

--bb

Walter Bright:
> I wish it were possible to have a language with just a small set of features that can do everything. C++'s problem is it can approximately do everything but with a boatload of gotcha's, like a const system that almost works but doesn't deliver. Java threw out too much.

Today lot of people think that the (close) future of programming is in languages that run on a VM, like Clojure (a kind of Lisp for the JavaVM fitter for multi-core programming). (While I think the far future is in things like OMeta and the like).

Java was a way to simplify C++, because in lot of applications most of the code doesn't need the level of detail (for example regarding memory allocation) that C and C++ require. Today I don't see many desktop applications written in Java, the Java applets are vanished (replaced by JavaScript and Flash), but Java is more to write applications, while today lot of high performance things or kernels are often in C still (often with lot of ugly things added to make it use the vector capabilities of modern CPUs). They have also recently released a kind of standard CUDA (OpenCL) that will probably lead to some change in the way high-performance code is written.

D isn't much a system language (I don't see people writing Linux with it, despite a couple attempts of writing a kernel with it), it looks more like an application language designed for people that like more modern things, a language cleaner and simpler to use than C++, but want to keep the old-style memory management, static compilation, etc.

In the future I think D has to remove some of its features, to have less ways to do one thing (even removing some of the C ways, if necessary), and make some of its features more consistent, more flexible, with fewer "gotchas".

I don't know in what direction D has to go. Maybe OpenCL to gain more high-performance? Has to gain few more functional features? To have better ways to manage multi-cores (see F# and Clojure)? To become more like C# (and become more an applicative language)? To switch most of its development to the LLVM platform and become a little more dynamic too (the new dynamic feature of C#4)? Are old-school statically compiled languages a thing of the past?

Even if D will not grow to become a very widespread language, it can give a significant help to the history of programming anyway. There are several languages that have a large legacy (es. Simula) despite they haven't had much diffusion. D can explore and invent ideas that later can be stolen and adopted by very common languages (for example new C# may be copying few things from D too).

One thing I like of Walter is that (beside being very good in programming), despite being old-school in several things (D2 is currently developed, yet, it's already old compared to several features of Scala and Clojure, and D is designed like ignoring several design features that today lot of programmers think as a given, like some of the features of the IDEs, that change how a language has to be designed too!) is open to learn and to change his original assumptions (and desires, regarding D design too) along the way. It's a long way, but so interesting to follow :-)

Bye, and thank you,
bearophile

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> I wish it were possible to have a language with just a small set of features that can do everything. C++'s problem is it can approximately do everything but with a boatload of gotcha's, like a const system that almost works but doesn't deliver. Java threw out too much.

Agreed.  The problem with C++ isn't so much that it's just complex.  Its problem is that its complexity comes in the form of lots of cruft inherited from C, from technological limitations that existed during its development but are no longer relevant and from just plain bad design decisions that can't be undone without massively breaking backwards compatibility.

Java went so far in the quest for simplicity that, since the irreducible complexity of a program has to go somewhere, it ends up being expressed in lots of "design patterns" that should be replaced by language features.  Worse yet, Java's solution to C++'s complexity is to force one level of abstraction, namely the class, to fit every problem, no matter how awkward that is.  For example, let's say I wanted to write a simple function to sort an array by an arbitrary comparison function in Java:

void sort(ArrayList<T> stuff, Comp comp) {...}

I have to define an interface called Comp and a class that inherits from it, which under the hood is using arrays of function pointers, because Java doesn't trust me with function pointers.  This is called abstraction inversion.

Most programs have some subproblems that are pretty run-of-the-mill and should
just be solved in the most expedient way possible, and others that require more
thought, either to make them generic enough or fast enough.  Mixing languages in
one project is generally a pain, especially if you want to do so on a fine-grained
level.  Therefore, the thing D gets right that few if any other languages do is
that it has a "keep it simple, stupid" layer for the run-of-the-mill subproblems
and a ridiculously complex but powerful boot-with-a-gun-built-in layer for the
more challenging ones, *in one language*.  The simple layer includes builtin
arrays, builtin associative arrays, garbage collection, the ~= operator, good
string handling, and a reasonably powerful standard lib, at least if you're using
either Tango or the D2 version of Phobos.  The complex layer includes templates,
manual memory management, unions, casting, operator overloading, and inline assembler.

The way I usually write my D code is to use the complex layer for relatively
generic, performance-critical code near the bottom of my abstraction hierarchy,
and then use the simple layer in the higher levels of my programs to call this
code.  That way, I get C++-like performance when I need it, and Python-like safety
and ease of coding when I don't.  Frankly, this works amazingly well.  Being able
to do this in one language, so seamlessly, is a perfect example of useful complexity.

Bill Baxter wrote:
> Sounds like you're asking for Lisp.  Small number of features with
> which you can do just about anything.  All using only oatmeal and
> toenail clippings!   Lua is a bit like that too, except the toenail
> clippings part.

I know about lisp. My problem with it is the syntax. I just don't like it.

dsimcha wrote:
> Most programs have some subproblems that are pretty run-of-the-mill and should
> just be solved in the most expedient way possible, and others that require more
> thought, either to make them generic enough or fast enough.  Mixing languages in
> one project is generally a pain, especially if you want to do so on a fine-grained
> level.  Therefore, the thing D gets right that few if any other languages do is
> that it has a "keep it simple, stupid" layer for the run-of-the-mill subproblems
> and a ridiculously complex but powerful boot-with-a-gun-built-in layer for the
> more challenging ones, *in one language*.  The simple layer includes builtin
> arrays, builtin associative arrays, garbage collection, the ~= operator, good
> string handling, and a reasonably powerful standard lib, at least if you're using
> either Tango or the D2 version of Phobos.  The complex layer includes templates,
> manual memory management, unions, casting, operator overloading, and inline assembler.

I probably shouldn't admit it, but one of my inspirations for the kiss subproblem was BASIC. Nobody did the keep simple programs simple better than BASIC. The string handling in BASIC in particular - strings are just an endless misery in C.

On Wed, Dec 10, 2008 at 12:13 AM, Walter Bright <newshound1@digitalmars.com> wrote:
> Bill Baxter wrote:
>>
>> Sounds like you're asking for Lisp.  Small number of features with which you can do just about anything.  All using only oatmeal and toenail clippings!   Lua is a bit like that too, except the toenail clippings part.
>
> I know about lisp. My problem with it is the syntax. I just don't like it.

I'll agree with you that "no syntax" seems to be taking syntactic simplicity a bit too far ;)  But I've also found that with Lisp, a reasonable (read: C-like) bracketing style goes a long way towards readability.  I was looking at some of BCS's code that's part of his BackMath library on dsource and was surprised at how much more readable the Lisp code was when it didn't stack up every freakin' right paren at the end of the line, and when it used a "normal" indentation style.

http://www.dsource.org/projects/scrapple/browser/trunk/backmath/do.lisp

I still prefer different things looking different, though.