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



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 

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
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Robert Fraser wrote:

 There are a lot of great 

 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 "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Dec 10, 2008 at 12:34 PM, Walter Bright
<newshound1 digitalmars.com> wrote:

 Robert Fraser wrote:


 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
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
next 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
prev sibling 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 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

more an applicative language)? To switch most of its development to the LLVM

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

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 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