In comp.lang.java.advocacy, Roedy Green
<see_website@[EMAIL PROTECTED]
>
wrote
on Wed, 19 Mar 2008 08:30:04 GMT
<50j1u3dk2rhh723unvf9ut53lu8bb681hk@[EMAIL PROTECTED]
>:
> There are many irritating things about Java, mostly a ascetic lack of
> syntatic sugar that makes it overly verbose. However, I don't think
> any language like Java but with a prettier syntax will prevail. That
> is not a big enough carrot to justify a move.
>
> Java itself might gradually evolve programmer conveniences like
> Delphi-like properties to replace the voluminous explicit getters and
> setters.
>
> The successor to Java will have to do something major that Java
> cannot.
>
> What might that thing be?
>
> 1. Visual creation and MAINTENANCE of GUIs.
Factored into #5, methinks. I think this is what Java
was trying to do with JavaBeans at the time, but failed
pretty miserably at, since it didn't separate presentation
from data, but rather merged the two...a pattern that is
(hopefully) rarely used today.
>
> 2. the logical equivalent of what CSS style sheets did for HTML,
> applied to Java GUIs -- a stronger separation of business logic from
> appearance. Programs should not have to deal with the petty details
> of displaying, layout and validation of common business data types.
Actually, I'd say programs should not, but programs should
be able to -- a careful distinction. In other words, a program
should be able to do the equivalent of Javascript's
do***ent.getElementById("t_12_34").setAttribute("class","red")
though it would be far easier to simply write
<tr><td id="t_12_34" class="red">...</td>...</tr>...
in the output -- assuming that this new language even does
output in the traditional sense. I'm not sure DOM is the
final end here, and XSL throws some interesting twists into
the final output.
Ideally, the program would not use HTML as such, but
just use GUI elements such as Table. Other possibilities
include a restricted JSP (no assignment statements, just
expressions and properties; not sure if the expressions
should have function calls beyond getters and setters)
or a standardized "BeanXML" which would be fed into an
XSL translator. Such is already implemented in Strutscx
(although not all that well; for a more complicated solution
you might look at Castor at www.castor.org .)
I'm not sure which is best, and I'm not beholden to HTML;
I think HTML stands for Hacked, Trashed, Muddled Lump
at times. Still, it's a standard...
>
> 3. a typing system for primitives based on units of measure and
> dimensionality.
For that matter, elimination of "boxing" and typing that
treats primitives as full Objects. I would also like to
see some sort of method by which one could write
Length a = 1 inch;
Length b = 2.54 cm;
Length c = 4 light ns;
Length d = a + b + c;
and have the expression a + b + c come up with a somewhat
meaningful answer. The syntax is of course negotiable, but
requiring "inch", "cm", and such as reserved words isn't
really to my liking, although one might modify the lexer
to allow a token after the number, reducing the token into
something with metadata. The Length type could then check
that metadata at runtime, and possibly at compiletime.
System.out.println(d);
would ideally generate something in meters (since meters
is the defined SI unit), but one could also contemplate
System.out.println(d / (1 cm));
which would print out the result in centimeters, as a
dimensionless number (124.9969832, if my computations
are correct).
The 7 SI units would be represented here. We'd also have
to contemplate derivative units, and I have no idea how
one would accomplish that neatly beyond some sort of metatype:
Mass mass = 1 kg;
Physical<meter/(second*second)> acceleration = 1 meter/(second*second);
Physical<kilogram*meter/(second*second)> force = mass * acceleration;
Another possibility would of course be
Physical<Mass * Length/(Time * Time)>
which might make a little more sense.
Ideally we'd also be able to define the type Force somehow.
In C there's the typedef construct; Java doesn't have
an equivalent. (SI defines the derived unit Newton
for force.)
And then there's expressions such as
v = Math.sqrt(g * r)
(the standard speed of a circular orbit) which actually
works (since g is an acceleration) but one has to wonder
how Math.sqrt() or other such functions is going to handle
all this. A simple solution is to throw an exception unless
one feeds it a unitless number, requiring expressions such as:
v = 1 meter/second * Math.sqrt(g*r/ (1 meter*meter/(second*second) ))
Messy. (The even simpler solution of converting them
to dimensionless numbers using the default SI units will
probably result in much confusion.)
>
> 4. unification of client, server, database server so you can write
> code that runs partly on all three, but appears as a unified piece of
> logic.
Actually, one would write the code exactly *once*.
The code parts, however, could be designated, in a side
file somewhere (probably in the Jar's metafile descriptor)
to run at different levels, connected with JaxRPC.
This facility would be available for all cl*****
(which means all cl***** are de facto serializable),
and singletons would have to be handled very carefully.
Of course singletons are a mess to handle anyway.
>
> 5. a language where there is no source code, but rather SCID and
> dynamic version control think of the program as structured data that
> can be displayed in hundreds of different possible ways.
> see http://mindprod.com/project/scid.html
> http://mindprod.com/project/dynamicversioncontrol.html
>
>
> 6. A language designed to exploit CPUs with thousands of cores.
The only way I can think of that is to allow various
odd constructs, somewhat a la the Illiac IV's dialect
of FORTRAN. Basically, the entire problem has to be
specified in a way such that it can fragment easily.
For a simple example:
String[] ary = new String[1000];
for(int i = 0; i < 1000; i++)
{
if(foo(ary[i],i))
{
bar(ary[i]);
}
}
can be trivially unrolled into 1000 separate IF statements, and each of
same fed into its own core, provided that foo() and bar() have no side
effects that trod on each other's results. Java does not have such
specifiers although one could add metadata elements such as @[EMAIL PROTECTED]
an impure function with a @[EMAIL PROTECTED]
metadata would of course be a
no-no; unclear as to who would catch it, if anybody.
Other issues involve reordering of statements -- an issue
already extant for contem****ary compilers. Briefly put,
a = 1;
b = 2;
c = 3;
d = 4;
e = a+b;
f = c+d;
g = e+f;
might not be evaluated in the specified order (since
clearly -- to us humans, anyway -- it doesn't matter which
of e and f is done first). Many compilers will preevaluate
g using constant folding, in fact, as though one had specified
g = 10;
instead. Such makes for runtime efficiency, but woe to
any program decompiler/disassembler trying to make any
sense of all this.
Assuming a compiler doesn't do constant folding, a
sufficiently sophisticated compiler could set up two cores
for evaluation of e and f, and then have one of them wait
for the other to evaluate g. Such complexities make for
interesting challenges.
--
#191, ewill3@[EMAIL PROTECTED]
Not a text file
--
Posted via a free Usenet account from http://www.teranews.com
|
