www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Java's development cycle

reply Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:
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
Dec 09 2008
next sibling parent "Nick Sabalausky" <a a.a> writes:
"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).
Dec 09 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
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.
Dec 09 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Dec 09 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Dec 09 2008
parent Leandro Lucarella <llucax gmail.com> writes:
bearophile, el  9 de diciembre a las 23:08 me escribiste:
 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).

I loooove XLR[1] ideas in this matter. [1] http://xlr.sourceforge.net/ -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Tired of lying in the sunshine staying home to watch the rain. You are young and life is long and there is time to kill today. And then one day you find ten years have got behind you. No one told you when to run, you missed the starting gun.
Dec 10 2008
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== 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.
Dec 09 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
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.
Dec 09 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Dec 09 2008
parent naryl <cyNOSPAM ngs.ru> writes:
Walter Bright 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.

Tcl is also quite extensible. It has *very* few syntax rules but looks a lot like C. C: for (int i = 0; i < strlen(str); i++) { char c = str[i]; if (isupper(str[i])) { printf("%c\n", str[i]); } } Tcl: for {set i 0} {i < [string len $str]} {incr i} { set c [string index $str i] if {[string is upper $c]} { puts $c } } or foreach c [split $str {}] { if {[string is upper $c]} { puts $c } }
Dec 10 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
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
Dec 09 2008
prev sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
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.
Dec 09 2008