Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #13664 > unrolled thread

no more primitive data types in Java (JDK 10+). What do you think?

Back to article view | Back to comp.lang.java.programmer

Contents

  no more primitive data types in Java (JDK 10+). What do you think? "Nasser M. Abbasi" <nma@12000.org> - 2012-04-19 18:27 -0500
    Re: no more primitive data types in Java (JDK 10+). What do you think? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-19 20:02 -0400
      Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <lewbloch@gmail.com> - 2012-04-19 17:31 -0700
        Re: no more primitive data types in Java (JDK 10+). What do you think? Robert Klemme <shortcutter@googlemail.com> - 2012-04-20 15:45 +0200
          Re: no more primitive data types in Java (JDK 10+). What do you think? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-20 15:05 +0000
            Re: no more primitive data types in Java (JDK 10+). What do you think? Robert Klemme <shortcutter@googlemail.com> - 2012-04-20 19:32 +0200
          Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-20 20:47 -0700
      Re: no more primitive data types in Java (JDK 10+). What do you think? Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-04-19 17:45 -0700
        Re: no more primitive data types in Java (JDK 10+). What do you think? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-19 21:22 -0400
        Re: no more primitive data types in Java (JDK 10+). What do you think? "Nasser M. Abbasi" <nma@12000.org> - 2012-04-19 21:16 -0500
          Re: no more primitive data types in Java (JDK 10+). What do you think? Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-04-19 23:11 -0700
    Re: no more primitive data types in Java (JDK 10+). What do you think? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-19 21:35 -0300
      Re: no more primitive data types in Java (JDK 10+). What do you think? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-19 21:31 -0400
      Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <lewbloch@gmail.com> - 2012-04-19 19:22 -0700
        Re: no more primitive data types in Java (JDK 10+). What do you think? Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-04-19 23:15 -0700
          Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-20 07:45 -0700
            Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <noone@lewscanon.com> - 2012-04-20 08:20 -0700
              Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-20 19:57 -0700
                Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <noone@lewscanon.com> - 2012-04-21 04:25 -0700
                  Re: no more primitive data types in Java (JDK 10+). What do you think? Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-04-21 07:05 -0500
                    Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-21 07:42 -0700
                      Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <noone@lewscanon.com> - 2012-04-21 12:55 -0700
                        Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-21 13:27 -0700
                          Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <noone@lewscanon.com> - 2012-04-21 13:34 -0700
                            Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-21 14:01 -0700
                            Re: no more primitive data types in Java (JDK 10+). What do you think? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-21 23:48 +0000
                              Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <noone@lewscanon.com> - 2012-04-21 17:46 -0700
          Re: no more primitive data types in Java (JDK 10+). What do you think? Gene Wirchenko <genew@ocis.net> - 2012-04-20 08:08 -0700
            Re: no more primitive data types in Java (JDK 10+). What do you think? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-20 16:46 +0000
              Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <lewbloch@gmail.com> - 2012-04-20 12:52 -0700
          Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <noone@lewscanon.com> - 2012-04-20 08:17 -0700
            Re: no more primitive data types in Java (JDK 10+). What do you think? Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-04-20 09:02 -0700
              Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <lewbloch@gmail.com> - 2012-04-20 12:48 -0700
              Re: no more primitive data types in Java (JDK 10+). What do you think? David Lamb <dalamb@cs.queensu.ca> - 2012-04-20 21:08 -0400
                Re: no more primitive data types in Java (JDK 10+). What do you think? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-21 01:55 +0000
                  Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <noone@lewscanon.com> - 2012-04-21 04:28 -0700
    Re: no more primitive data types in Java (JDK 10+). What do you think? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-04-19 19:36 -0500
    Re: no more primitive data types in Java (JDK 10+). What do you think? Tsukino Usagi <usagi@tsukino.ca> - 2012-04-20 15:27 +0900
      Re: no more primitive data types in Java (JDK 10+). What do you think? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-20 07:04 -0300
        Re: no more primitive data types in Java (JDK 10+). What do you think? Tsukino Usagi <usagi@tsukino.ca> - 2012-04-20 22:17 +0900
          Re: no more primitive data types in Java (JDK 10+). What do you think? Robert Klemme <shortcutter@googlemail.com> - 2012-04-20 15:59 +0200
        Re: no more primitive data types in Java (JDK 10+). What do you think? Thufir <hawat.thufir@gmail.com> - 2012-04-20 14:21 -0700
        Re: no more primitive data types in Java (JDK 10+). What do you think? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-20 19:11 -0400
      Re: no more primitive data types in Java (JDK 10+). What do you think? Tsukino Usagi <usagi@tsukino.ca> - 2012-04-20 22:16 +0900
        Re: no more primitive data types in Java (JDK 10+). What do you think? Robert Klemme <shortcutter@googlemail.com> - 2012-04-20 15:55 +0200
      Re: no more primitive data types in Java (JDK 10+). What do you think? Patricia Shanahan <pats@acm.org> - 2012-04-20 07:49 -0700
        Re: no more primitive data types in Java (JDK 10+). What do you think? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-20 19:19 -0400
          Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-21 07:58 -0700
      Re: no more primitive data types in Java (JDK 10+). What do you think? rossum <rossum48@coldmail.com> - 2012-04-20 20:08 +0100
        Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <lewbloch@gmail.com> - 2012-04-20 12:54 -0700
          Re: no more primitive data types in Java (JDK 10+). What do you think? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-20 21:48 +0000
            Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <lewbloch@gmail.com> - 2012-04-20 16:45 -0700
              Re: no more primitive data types in Java (JDK 10+). What do you think? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-21 01:56 +0000
                Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <noone@lewscanon.com> - 2012-04-21 04:35 -0700
        Re: no more primitive data types in Java (JDK 10+). What do you think? Jim Janney <jjanney@shell.xmission.com> - 2012-04-20 16:24 -0600
      Re: no more primitive data types in Java (JDK 10+). What do you think? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-20 19:08 -0400
      Re: no more primitive data types in Java (JDK 10+). What do you think? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-04-20 18:14 -0500
        Re: no more primitive data types in Java (JDK 10+). What do you think? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-20 19:22 -0400
        Re: no more primitive data types in Java (JDK 10+). What do you think? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-20 20:36 -0400
    Re: no more primitive data types in Java (JDK 10+). What do you think? Roedy Green <see_website@mindprod.com.invalid> - 2012-04-20 05:33 -0700
      Re: no more primitive data types in Java (JDK 10+). What do you think? Bernd Nawothnig <Bernd.Nawothnig@t-online.de> - 2012-04-20 20:53 +0200
        Re: no more primitive data types in Java (JDK 10+). What do you think? Gene Wirchenko <genew@ocis.net> - 2012-04-20 13:36 -0700
          Re: no more primitive data types in Java (JDK 10+). What do you think? Bernd Nawothnig <Bernd.Nawothnig@t-online.de> - 2012-04-21 10:20 +0200
            Re: no more primitive data types in Java (JDK 10+). What do you think? Gene Wirchenko <genew@ocis.net> - 2012-04-23 10:24 -0700
              Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-24 14:39 -0700
                Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <lewbloch@gmail.com> - 2012-04-24 15:06 -0700
                  Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-24 17:07 -0700
                    Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <noone@lewscanon.com> - 2012-04-25 00:48 -0700
                      Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-25 08:20 -0700
                        Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <noone@lewscanon.com> - 2012-04-25 08:59 -0700
                          Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-25 10:32 -0700
                Re: no more primitive data types in Java (JDK 10+). What do you think? Tsukino Usagi <usagi@tsukino.ca> - 2012-04-29 23:03 +0900
                  Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-29 10:28 -0700
        Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-21 08:55 -0700
          Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <noone@lewscanon.com> - 2012-04-21 12:56 -0700
            Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-21 13:41 -0700
    Re: no more primitive data types in Java (JDK 10+). What do you think? Silvio Bierman <silvio@moc.com> - 2012-04-20 16:50 +0200
      Re: no more primitive data types in Java (JDK 10+). What do you think? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-20 19:04 -0400

Page 4 of 4 — ← Prev page 1 2 3 [4]

#13706

On 2012-04-20, Roedy Green wrote:
> On Thu, 19 Apr 2012 18:27:43 -0500, "Nasser M. Abbasi" <nma@12000.org>
> wrote, quoted or indirectly quoted someone who said :
>
>>    "Unified type system (JDK 10+)
>>     No more primitives, make everything objects"
>
> This is the way Eiffel works,

The same for Python.

> but under the covers there are still primitives. Perhaps what they
> have in mind for Java, more intelligent boxing. At least at the low
> levels of the JVM you need primitives.

These implementation details should better be hidden and invisible for
most cases. Let the compiler automatically detect and generate
possible optimisations.

A programming language should be as simple and orthogonal as possible.




Bernd

-- 
"Die Antisemiten vergeben es den Juden nicht, dass die Juden Geist
haben - und Geld." [Friedrich Nietzsche]

[toc] | [prev] | [next] | [standalone]

#13715

On Fri, 20 Apr 2012 20:53:46 +0200, Bernd Nawothnig
<Bernd.Nawothnig@t-online.de> wrote:

[snip]

>These implementation details should better be hidden and invisible for
>most cases. Let the compiler automatically detect and generate
>possible optimisations.

     If you complicate things, the compiler then has to work to
decomplicate (optimise).  Why not just keep it simple?

>A programming language should be as simple and orthogonal as possible.

     One application of keeping it simple would be to use primitives
where possible -- since they are simpler than objects -- and only use
objects where they are needed.

Sincrely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#13735

On 2012-04-20, Gene Wirchenko wrote:
>>These implementation details should better be hidden and invisible for
>>most cases. Let the compiler automatically detect and generate
>>possible optimisations.
>
>      If you complicate things, the compiler then has to work to
> decomplicate (optimise).  Why not just keep it simple?

My proposal was quite the contrary: simplification of things, i.e.
removal of unnecessary data types by unifications.

Keep in mind: the compiler is not the programmer!

>>A programming language should be as simple and orthogonal as possible.
>
>      One application of keeping it simple would be to use primitives
> where possible -- since they are simpler than objects -- and only use
> objects where they are needed.

See above: don't mix up the compiler, the machine, and implementation
details with the programmer. Things should be simple for the
*programmer*, not necessarily for the compiler or the machine, even if
that maybe preferable. But preferable is not necessary ...




Bernd

-- 
"Die Antisemiten vergeben es den Juden nicht, dass die Juden Geist
haben - und Geld." [Friedrich Nietzsche]

[toc] | [prev] | [next] | [standalone]

#13820

On Sat, 21 Apr 2012 10:20:41 +0200, Bernd Nawothnig
<Bernd.Nawothnig@t-online.de> wrote:

>On 2012-04-20, Gene Wirchenko wrote:
>>>These implementation details should better be hidden and invisible for
>>>most cases. Let the compiler automatically detect and generate
>>>possible optimisations.
>>
>>      If you complicate things, the compiler then has to work to
>> decomplicate (optimise).  Why not just keep it simple?
>
>My proposal was quite the contrary: simplification of things, i.e.
>removal of unnecessary data types by unifications.
>
>Keep in mind: the compiler is not the programmer!
>
>>>A programming language should be as simple and orthogonal as possible.
>>
>>      One application of keeping it simple would be to use primitives
>> where possible -- since they are simpler than objects -- and only use
>> objects where they are needed.
>
>See above: don't mix up the compiler, the machine, and implementation
>details with the programmer. Things should be simple for the
>*programmer*, not necessarily for the compiler or the machine, even if
>that maybe preferable. But preferable is not necessary ...

     I am not confusing them, but one does have to consider them all.
If a language can not be easily compiled, that creates problems.  Even
if the compilation is simply slower, that may discourage use of it.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#13870

On 4/23/2012 10:24 AM, Gene Wirchenko wrote:
> On Sat, 21 Apr 2012 10:20:41 +0200, Bernd Nawothnig
> <Bernd.Nawothnig@t-online.de>  wrote:
>
>> On 2012-04-20, Gene Wirchenko wrote:
>>>> These implementation details should better be hidden and invisible for
>>>> most cases. Let the compiler automatically detect and generate
>>>> possible optimisations.
>>>
>>>       If you complicate things, the compiler then has to work to
>>> decomplicate (optimise).  Why not just keep it simple?
>>
>> My proposal was quite the contrary: simplification of things, i.e.
>> removal of unnecessary data types by unifications.
>>
>> Keep in mind: the compiler is not the programmer!
>>
>>>> A programming language should be as simple and orthogonal as possible.
>>>
>>>       One application of keeping it simple would be to use primitives
>>> where possible -- since they are simpler than objects -- and only use
>>> objects where they are needed.
>>
>> See above: don't mix up the compiler, the machine, and implementation
>> details with the programmer. Things should be simple for the
>> *programmer*, not necessarily for the compiler or the machine, even if
>> that maybe preferable. But preferable is not necessary ...
>
>       I am not confusing them, but one does have to consider them all.
> If a language can not be easily compiled, that creates problems.  Even
> if the compilation is simply slower, that may discourage use of it.

yep...

(pardon any exaggeration... this can be taken purely as personal 
opinion...).


programmer considers whether to use C or C++ for something:
tries compiling code with a C compiler, kind of slow, but livable (well, 
my project rebuilds in about 20 seconds);
tries compiling code with a C++ compiler, takes a while, programmer 
wanders off, gets coffee, comes back, compiler is still churning 
along... (and maybe continues to take an additional 30 minutes).

programmer concludes, regarding C++: "no... this just isn't worth it...".

OTOH: Java compiles fairly fast...
(but, admittedly, Java isn't really perfect either).

so, ultimately, the programmer chooses things based on a mixture of what 
they are most comfortable with, and what annoyances they are inclined to 
put up with, ...


so:
the C++ programmer lives with absurdly long build times (and says "but 
at least I have, features!").

the C programmer lives with a world where doing OO stuff/... is 
generally painful, and thinks "what problem is there which can't be 
solved with a little pointer arithmetic?" (maybe followed by using an 
#ifdef to check the CPU type, writing a few bytes into a buffer, and 
then calling it as if it were a function pointer...), and concluding 
"all this OO stuff is nothing really beyond syntax sugar over a few 
structs and function pointers anyways... so why care?...".


and the Java programmer lives in a world where writing code in general 
is painful (and then thinks, "well at least I have this giant class 
library, just have to find the relevant SomeClassWhichDoesTaskX", 
nevermind should anyone go through the pain of having to write some 
actual code to do something...). but, it is all good, "for safety!".


say:

C:
void *p;
long long j;
int i;
...
i=p;	//compiler: warning: I don't like the way this looks, but ok...
i=j;	//compiler: <remains silent>

C++:
void *p;
long long j;
int i;
...
i=p;	//compiler: error: you need to cast this crap...
i=j;	//compiler: <remains silent>

Java:
Void p;
long j;
int i;
...
i=j;	//compiler: error: OMG WTF!
... (error message spanning several lines)
...                 i=j;
... (gotta make sure, ^, programer sees this crap)
...

so user has to remember to type "i=(int)j;" or they might cut themselves 
on the sharp edges of numeric precision, and meanwhile "i=(int)p;" 
doesn't even come close to working (but, to be fair, there is little in 
the language design to say what the value "should" be, if it were 
in-fact to work).


and maybe some of:

C:
printf("Have you seen this? %f\n", sin(M_PI));

C++:
cout << "Have you seen this?" << sin(M_PI) << endl;
( somewhere in history: "hey, have you seen the spiffy new feature, I 
can make these operators do whatever random crap I want!", someone else: 
"hard-core yeah! using shift for printing! why don't we make this a 
standard feature!" ).

Java:
System.out.println("Have you seen this? " + Math.sin(Math.PI));
("no one will notice...").

well, and:
C:
#include <stdio.h>
int main()
{
     printf("yay!\n");
     return 0;
}

C++:
#include <iostream>
using namespace std;
int main()
{
     cout << "yay!\n" << endl;
     return 0;
}

Java:
public class MyClass
{
     public static void main(String[] args)
     {
         System.out.println("yay!");
     }
}

just saying is all...


(decided to leave out some other examples here, potentially more likely 
to create controversy, which isn't really my intent here).


or such...

[toc] | [prev] | [next] | [standalone]

#13873

BGB wrote:
> so user has to remember to type "i=(int)j;" or they might cut themselves 
> on the sharp edges of numeric precision, and meanwhile "i=(int)p;" 
> doesn't even come close to working (but, to be fair, there is little in 
> the language design to say what the value "should" be, if it were 
> in-fact [sic] to work).

There is, too, such a statement in the language spec - the value should be a compiler error.

The notion of 'what the value "should" be' is not mentioned because, naturally enough, it's not a valid construct. If it were to work, it wouldn't be Java any more. It's such a fundamentally opposed construct to the Java ethos that such a thing cannot happen in Java, ever. It's part of the foundational type-safe approach that is the heart of Java. So put aside such self-contradictory absurdities as, "what that which is utterly forbidden and anathema to the language philosophy would look like if it were allowed."

or such...

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#13878

On 4/24/2012 3:06 PM, Lew wrote:
> BGB wrote:
>> so user has to remember to type "i=(int)j;" or they might cut themselves
>> on the sharp edges of numeric precision, and meanwhile "i=(int)p;"
>> doesn't even come close to working (but, to be fair, there is little in
>> the language design to say what the value "should" be, if it were
>> in-fact [sic] to work).
>
> There is, too, such a statement in the language spec - the value should be a compiler error.
>

well, either way, it doesn't work (a compiler error isn't really a value).


> The notion of 'what the value "should" be' is not mentioned because, naturally enough, it's not a valid construct. If it were to work, it wouldn't be Java any more. It's such a fundamentally opposed construct to the Java ethos that such a thing cannot happen in Java, ever. It's part of the foundational type-safe approach that is the heart of Java. So put aside such self-contradictory absurdities as, "what that which is utterly forbidden and anathema to the language philosophy would look like if it were allowed."
>

doesn't seem like a relevant argument, because such things *are* defined 
in various ways in other languages, and a language is more about 
specific syntax, behaviors, and semantics than it is about constructs 
being "anathema" or having a "philosophy" (unless of course the spec 
were to define this as well).


I am not saying it has to do the same thing as C or C++, and should have 
been implied from context that I was implying that it not do the same 
thing as in C or C++, but infact probably something very different 
(like, say, implement an interface for coercing the type to a number or 
something).


so, the thing is, the compiler rejects it, and the spec doesn't define 
semantics for what should happen in this case (apart from an error 
condition).

this doesn't mean that semantics for this case couldn't be defined, say 
for example, it implementing a "ConvertsToNumber" interface or similar.

example:
public interface ConvertsToNumber {
	public int intValue();
	public long longValue();
	public float floatValue();
	public double doubleValue();
}

but, yes, given it is not defined in the language spec, it is sort of a 
moot argument.


granted, yes, this makes about as much sense as implementing "structs" 
in Java via a sort of magic "ValueType" class or interface, say:

public interface ValueType {
public ValueType copyValue();
public void dropValue();
}

with any object implementing such an interface effectively gaining 
pass-by-value semantics (say, if done internally via invoking the 
"copyValue()" method to get a new copy, and the "dropValue()" method 
whenever an instance goes out of scope).

taken slightly further, and combined with some syntax sugar, a person 
could *also* implement an interface for support for things resembling C 
pointer operations as well, but with no actual pointers involved... (and 
then maybe use it for things like walking strings or arrays or similar).


or something...

[toc] | [prev] | [next] | [standalone]

#13892

BGB wrote:
> Lew wrote:
>> The notion of 'what the value "should" be' is not mentioned because,
>> naturally enough, it's not a valid construct. If it were to work, it
>> wouldn't be Java any more. It's such a fundamentally opposed construct to
>> the Java ethos that such a thing cannot happen in Java, ever. It's part of
>> the foundational type-safe approach that is the heart of Java. So put aside
>> such self-contradictory absurdities as, "what that which is utterly
>> forbidden and anathema to the language philosophy would look like if it were
>> allowed."
>>
>
> doesn't seem like a relevant argument, because such things *are* defined in
> various ways in other languages, and a language is more about specific syntax,
> behaviors, and semantics than it is about constructs being "anathema" or
> having a "philosophy" (unless of course the spec were to define this as well).

What do other languages have to do with it?

This is Java.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#13901

On 4/25/2012 12:48 AM, Lew wrote:
> BGB wrote:
>> Lew wrote:
>>> The notion of 'what the value "should" be' is not mentioned because,
>>> naturally enough, it's not a valid construct. If it were to work, it
>>> wouldn't be Java any more. It's such a fundamentally opposed
>>> construct to
>>> the Java ethos that such a thing cannot happen in Java, ever. It's
>>> part of
>>> the foundational type-safe approach that is the heart of Java. So put
>>> aside
>>> such self-contradictory absurdities as, "what that which is utterly
>>> forbidden and anathema to the language philosophy would look like if
>>> it were
>>> allowed."
>>>
>>
>> doesn't seem like a relevant argument, because such things *are*
>> defined in
>> various ways in other languages, and a language is more about specific
>> syntax,
>> behaviors, and semantics than it is about constructs being "anathema" or
>> having a "philosophy" (unless of course the spec were to define this
>> as well).
>
> What do other languages have to do with it?
>
> This is Java.
>

languages don't exist in a vacuum.

most borrow features, syntax, and semantics, from other languages, 
particularly when in similar domains.

if something is useful, and the next guy over does it, the usual answer 
is simple: do likewise.

[toc] | [prev] | [next] | [standalone]

#13904

BGB wrote:
> Lew wrote:
>> BGB wrote:
>>> Lew wrote:
>>>> The notion of 'what the value "should" be' is not mentioned because,
>>>> naturally enough, it's not a valid construct. If it were to work, it
>>>> wouldn't be Java any more. It's such a fundamentally opposed
>>>> construct to
>>>> the Java ethos that such a thing cannot happen in Java, ever. It's
>>>> part of
>>>> the foundational type-safe approach that is the heart of Java. So put
>>>> aside
>>>> such self-contradictory absurdities as, "what that which is utterly
>>>> forbidden and anathema to the language philosophy would look like if
>>>> it were
>>>> allowed."
>>>>
>>>
>>> doesn't seem like a relevant argument, because such things *are*
>>> defined in
>>> various ways in other languages, and a language is more about specific
>>> syntax,
>>> behaviors, and semantics than it is about constructs being "anathema" or
>>> having a "philosophy" (unless of course the spec were to define this
>>> as well).
>>
>> What do other languages have to do with it?
>>
>> This is Java.
>>
>
> languages don't exist in a vacuum.

That's not germane here.

> most borrow features, syntax, and semantics, from other languages,
> particularly when in similar domains.

That process happened for Java a long time since, and having made certain 
choices it's not going to reverse them now.

> if something is useful, and the next guy over does it, the usual answer is
> simple: do likewise.

Big ifs, especially for Java. The construct in question, casting 'Void' to 
'int', is vanishingly unlikely to be adopted, because it is oppositional to 
the fundamental structure of the language, i.e., rigid type safety. 
Consequently that change would break just about everything. Unless the 
stewards of the language have utterly lost their minds, this won't happen.

All your fine but unrelated generalities notwithstanding.

And how is that answer "usual"? Have you looked at how slowly Java adopts the 
latest groovy fads?

Backwards compatibility and the cost-benefit analysis of feature changes, much 
less core paradigm-shifting changes like breaking Java's basic promise of type 
safety, are much stronger forces than you credit. Languages do not willy-nilly 
adopt features "usually" as you claim.

Or such...

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#13911

On 4/25/2012 8:59 AM, Lew wrote:
> BGB wrote:
>> Lew wrote:
>>> BGB wrote:
>>>> Lew wrote:
>>>>> The notion of 'what the value "should" be' is not mentioned because,
>>>>> naturally enough, it's not a valid construct. If it were to work, it
>>>>> wouldn't be Java any more. It's such a fundamentally opposed
>>>>> construct to
>>>>> the Java ethos that such a thing cannot happen in Java, ever. It's
>>>>> part of
>>>>> the foundational type-safe approach that is the heart of Java. So put
>>>>> aside
>>>>> such self-contradictory absurdities as, "what that which is utterly
>>>>> forbidden and anathema to the language philosophy would look like if
>>>>> it were
>>>>> allowed."
>>>>>
>>>>
>>>> doesn't seem like a relevant argument, because such things *are*
>>>> defined in
>>>> various ways in other languages, and a language is more about specific
>>>> syntax,
>>>> behaviors, and semantics than it is about constructs being
>>>> "anathema" or
>>>> having a "philosophy" (unless of course the spec were to define this
>>>> as well).
>>>
>>> What do other languages have to do with it?
>>>
>>> This is Java.
>>>
>>
>> languages don't exist in a vacuum.
>
> That's not germane here.
>

I disagree, I have seen frequent references by others to, among other 
languages: C#, Ruby, Scala, ...


>> most borrow features, syntax, and semantics, from other languages,
>> particularly when in similar domains.
>
> That process happened for Java a long time since, and having made
> certain choices it's not going to reverse them now.
>

taken over a longer time period, they have kept adding features.

for example, Generics, and more recently, Lambdas, ...


some of the features mentioned in the referenced document also seemed to 
have some amount of vague similarity to those in C#, ...


>> if something is useful, and the next guy over does it, the usual
>> answer is
>> simple: do likewise.
>
> Big ifs, especially for Java. The construct in question, casting 'Void'
> to 'int', is vanishingly unlikely to be adopted, because it is
> oppositional to the fundamental structure of the language, i.e., rigid
> type safety. Consequently that change would break just about everything.
> Unless the stewards of the language have utterly lost their minds, this
> won't happen.
>

except, it doesn't have to be by violating type-safety.

yes, granted, the Void case would probably remain an error (it was used 
merely as an example of "something which doesn't work for a good number 
of reasons", and not as an example of "something I think should actually 
work"), but there are other cases where such a cast could be allowed for 
other object types without necessarily violating type safety (so long as 
an interface is defined for which sensible behavior can also be defined 
and implemented).


the point would *not* be that of expecting Java to suddenly become some 
loosely-typed dynamic language, abandon static type-checking, or turn 
into C or C++, as that would be missing the point (and kind of pointless 
/ stupid as well).


anyways, the original comment was not meant to say whether or not 
certain things were actually good or bad, but how they are often 
perceived by developers of the other languages. hence, presentations of 
all 3 languages (C, C++, and Java), were more intended as straw-men than 
as accurate presentations (hence, why it was mentioned up-front that it 
was exaggerated).



> All your fine but unrelated generalities notwithstanding.
>
> And how is that answer "usual"? Have you looked at how slowly Java
> adopts the latest groovy fads?

yes, I have noticed.

this is not to say there is a specific time-frame, or that it 
necessarily happens quickly, but it can also be noted that to some 
extent this has still been the practice (if slowly).
likewise goes for C and C++ as well.

a faster-moving language is C#, which to some extent would be a much 
more direct example of this practice (and them doing so much more quickly).


> Backwards compatibility and the cost-benefit analysis of feature
> changes, much less core paradigm-shifting changes like breaking Java's
> basic promise of type safety, are much stronger forces than you credit.
> Languages do not willy-nilly adopt features "usually" as you claim.

it takes years, but it is worth noting that such a change would be 
unlikely to impact backwards compatibility, FWIW.

how or why it impacts type-safety would depend in large part on how the 
feature were defined and implemented.


given nothing has been actually defined for what would or would not 
happen here, how can it be said what if any impact there will by on 
either the type-safety, or on the semantics?

to know the impact requires first knowing what the feature *is*, and not 
simply how it may be expressed.

[toc] | [prev] | [next] | [standalone]

#14021

On 4/25/2012 6:39 AM, BGB wrote:
> On 4/23/2012 10:24 AM, Gene Wirchenko wrote:
>> On Sat, 21 Apr 2012 10:20:41 +0200, Bernd Nawothnig
>> <Bernd.Nawothnig@t-online.de> wrote:
>>
>>> On 2012-04-20, Gene Wirchenko wrote:
>>>>> These implementation details should better be hidden and invisible for
>>>>> most cases. Let the compiler automatically detect and generate
>>>>> possible optimisations.
>>>>
>>>> If you complicate things, the compiler then has to work to
>>>> decomplicate (optimise). Why not just keep it simple?
>>>
>>> My proposal was quite the contrary: simplification of things, i.e.
>>> removal of unnecessary data types by unifications.
>>>
>>> Keep in mind: the compiler is not the programmer!
>>>
>>>>> A programming language should be as simple and orthogonal as possible.
>>>>
>>>> One application of keeping it simple would be to use primitives
>>>> where possible -- since they are simpler than objects -- and only use
>>>> objects where they are needed.
>>>
>>> See above: don't mix up the compiler, the machine, and implementation
>>> details with the programmer. Things should be simple for the
>>> *programmer*, not necessarily for the compiler or the machine, even if
>>> that maybe preferable. But preferable is not necessary ...
>>
>> I am not confusing them, but one does have to consider them all.
>> If a language can not be easily compiled, that creates problems. Even
>> if the compilation is simply slower, that may discourage use of it.
>
> yep...
>
> (pardon any exaggeration... this can be taken purely as personal
> opinion...).
>
>
> programmer considers whether to use C or C++ for something:
> tries compiling code with a C compiler, kind of slow, but livable (well,
> my project rebuilds in about 20 seconds);
> tries compiling code with a C++ compiler, takes a while, programmer
> wanders off, gets coffee, comes back, compiler is still churning
> along... (and maybe continues to take an additional 30 minutes).
>
> programmer concludes, regarding C++: "no... this just isn't worth it...".
>
> OTOH: Java compiles fairly fast...
> (but, admittedly, Java isn't really perfect either).
>
> so, ultimately, the programmer chooses things based on a mixture of what
> they are most comfortable with, and what annoyances they are inclined to
> put up with, ...
>
>
> so:
> the C++ programmer lives with absurdly long build times (and says "but
> at least I have, features!").
>
> the C programmer lives with a world where doing OO stuff/... is
> generally painful, and thinks "what problem is there which can't be
> solved with a little pointer arithmetic?" (maybe followed by using an
> #ifdef to check the CPU type, writing a few bytes into a buffer, and
> then calling it as if it were a function pointer...), and concluding
> "all this OO stuff is nothing really beyond syntax sugar over a few
> structs and function pointers anyways... so why care?...".
>
>
> and the Java programmer lives in a world where writing code in general
> is painful (and then thinks, "well at least I have this giant class
> library, just have to find the relevant SomeClassWhichDoesTaskX",
> nevermind should anyone go through the pain of having to write some
> actual code to do something...). but, it is all good, "for safety!".
>
>
> say:
>
> C:
> void *p;
> long long j;
> int i;
> ...
> i=p; //compiler: warning: I don't like the way this looks, but ok...
> i=j; //compiler: <remains silent>
>
> C++:
> void *p;
> long long j;
> int i;
> ...
> i=p; //compiler: error: you need to cast this crap...
> i=j; //compiler: <remains silent>
>
> Java:
> Void p;
> long j;
> int i;
> ...
> i=j; //compiler: error: OMG WTF!
> ... (error message spanning several lines)
> ... i=j;
> ... (gotta make sure, ^, programer sees this crap)
> ...
>
> so user has to remember to type "i=(int)j;" or they might cut themselves
> on the sharp edges of numeric precision, and meanwhile "i=(int)p;"
> doesn't even come close to working (but, to be fair, there is little in
> the language design to say what the value "should" be, if it were
> in-fact to work).
>
>
> and maybe some of:
>
> C:
> printf("Have you seen this? %f\n", sin(M_PI));
>
> C++:
> cout << "Have you seen this?" << sin(M_PI) << endl;
> ( somewhere in history: "hey, have you seen the spiffy new feature, I
> can make these operators do whatever random crap I want!", someone else:
> "hard-core yeah! using shift for printing! why don't we make this a
> standard feature!" ).
>
> Java:
> System.out.println("Have you seen this? " + Math.sin(Math.PI));
> ("no one will notice...").
>
> well, and:
> C:
> #include <stdio.h>
> int main()
> {
> printf("yay!\n");
> return 0;
> }
>
> C++:
> #include <iostream>
> using namespace std;
> int main()
> {
> cout << "yay!\n" << endl;
> return 0;
> }
>
> Java:
> public class MyClass
> {
> public static void main(String[] args)
> {
> System.out.println("yay!");
> }
> }
>
> just saying is all...
>
>
> (decided to leave out some other examples here, potentially more likely
> to create controversy, which isn't really my intent here).
>
>
> or such...

Whats your point?

[toc] | [prev] | [next] | [standalone]

#14032

On 4/29/2012 7:03 AM, Tsukino Usagi wrote:
> On 4/25/2012 6:39 AM, BGB wrote:
>> On 4/23/2012 10:24 AM, Gene Wirchenko wrote:
>>> On Sat, 21 Apr 2012 10:20:41 +0200, Bernd Nawothnig
>>> <Bernd.Nawothnig@t-online.de> wrote:
>>>
>>>> On 2012-04-20, Gene Wirchenko wrote:
>>>>>> These implementation details should better be hidden and invisible
>>>>>> for
>>>>>> most cases. Let the compiler automatically detect and generate
>>>>>> possible optimisations.
>>>>>
>>>>> If you complicate things, the compiler then has to work to
>>>>> decomplicate (optimise). Why not just keep it simple?
>>>>
>>>> My proposal was quite the contrary: simplification of things, i.e.
>>>> removal of unnecessary data types by unifications.
>>>>
>>>> Keep in mind: the compiler is not the programmer!
>>>>
>>>>>> A programming language should be as simple and orthogonal as
>>>>>> possible.
>>>>>
>>>>> One application of keeping it simple would be to use primitives
>>>>> where possible -- since they are simpler than objects -- and only use
>>>>> objects where they are needed.
>>>>
>>>> See above: don't mix up the compiler, the machine, and implementation
>>>> details with the programmer. Things should be simple for the
>>>> *programmer*, not necessarily for the compiler or the machine, even if
>>>> that maybe preferable. But preferable is not necessary ...
>>>
>>> I am not confusing them, but one does have to consider them all.
>>> If a language can not be easily compiled, that creates problems. Even
>>> if the compilation is simply slower, that may discourage use of it.
>>
>> yep...
>>
>> (pardon any exaggeration... this can be taken purely as personal
>> opinion...).
>>
>>
>> programmer considers whether to use C or C++ for something:
>> tries compiling code with a C compiler, kind of slow, but livable (well,
>> my project rebuilds in about 20 seconds);
>> tries compiling code with a C++ compiler, takes a while, programmer
>> wanders off, gets coffee, comes back, compiler is still churning
>> along... (and maybe continues to take an additional 30 minutes).
>>
>> programmer concludes, regarding C++: "no... this just isn't worth it...".
>>
>> OTOH: Java compiles fairly fast...
>> (but, admittedly, Java isn't really perfect either).
>>
>> so, ultimately, the programmer chooses things based on a mixture of what
>> they are most comfortable with, and what annoyances they are inclined to
>> put up with, ...
>>
>>
>> so:
>> the C++ programmer lives with absurdly long build times (and says "but
>> at least I have, features!").
>>
>> the C programmer lives with a world where doing OO stuff/... is
>> generally painful, and thinks "what problem is there which can't be
>> solved with a little pointer arithmetic?" (maybe followed by using an
>> #ifdef to check the CPU type, writing a few bytes into a buffer, and
>> then calling it as if it were a function pointer...), and concluding
>> "all this OO stuff is nothing really beyond syntax sugar over a few
>> structs and function pointers anyways... so why care?...".
>>
>>
>> and the Java programmer lives in a world where writing code in general
>> is painful (and then thinks, "well at least I have this giant class
>> library, just have to find the relevant SomeClassWhichDoesTaskX",
>> nevermind should anyone go through the pain of having to write some
>> actual code to do something...). but, it is all good, "for safety!".
>>
>>
>> say:
>>
>> C:
>> void *p;
>> long long j;
>> int i;
>> ...
>> i=p; //compiler: warning: I don't like the way this looks, but ok...
>> i=j; //compiler: <remains silent>
>>
>> C++:
>> void *p;
>> long long j;
>> int i;
>> ...
>> i=p; //compiler: error: you need to cast this crap...
>> i=j; //compiler: <remains silent>
>>
>> Java:
>> Void p;
>> long j;
>> int i;
>> ...
>> i=j; //compiler: error: OMG WTF!
>> ... (error message spanning several lines)
>> ... i=j;
>> ... (gotta make sure, ^, programer sees this crap)
>> ...
>>
>> so user has to remember to type "i=(int)j;" or they might cut themselves
>> on the sharp edges of numeric precision, and meanwhile "i=(int)p;"
>> doesn't even come close to working (but, to be fair, there is little in
>> the language design to say what the value "should" be, if it were
>> in-fact to work).
>>
>>
>> and maybe some of:
>>
>> C:
>> printf("Have you seen this? %f\n", sin(M_PI));
>>
>> C++:
>> cout << "Have you seen this?" << sin(M_PI) << endl;
>> ( somewhere in history: "hey, have you seen the spiffy new feature, I
>> can make these operators do whatever random crap I want!", someone else:
>> "hard-core yeah! using shift for printing! why don't we make this a
>> standard feature!" ).
>>
>> Java:
>> System.out.println("Have you seen this? " + Math.sin(Math.PI));
>> ("no one will notice...").
>>
>> well, and:
>> C:
>> #include <stdio.h>
>> int main()
>> {
>> printf("yay!\n");
>> return 0;
>> }
>>
>> C++:
>> #include <iostream>
>> using namespace std;
>> int main()
>> {
>> cout << "yay!\n" << endl;
>> return 0;
>> }
>>
>> Java:
>> public class MyClass
>> {
>> public static void main(String[] args)
>> {
>> System.out.println("yay!");
>> }
>> }
>>
>> just saying is all...
>>
>>
>> (decided to leave out some other examples here, potentially more likely
>> to create controversy, which isn't really my intent here).
>>
>>
>> or such...
>
> Whats your point?


that there may be relative tradeoffs between using languages, some of 
which may be seen as non-issues by one developer, but as critical 
failings by another (as well as multiple ways in which a given language 
may be percieved by developers using a different language, ...).

compilation speed was one example, but there are many other possibilities.

for example, type-semantics / type-safety, which may be seen as an 
important feature by one developer, and an annoyance or hindrance by 
another (and may even be defined differently for each developer), ...


so, in effect, language perceptions tend to be relative, to some extent, 
and it isn't really possible to design a "one true language" for which 
everyone will be happy, or which necessarily applies equally well to 
every use-case.

[toc] | [prev] | [next] | [standalone]

#13748

On 4/20/2012 11:53 AM, Bernd Nawothnig wrote:
> On 2012-04-20, Roedy Green wrote:
>> On Thu, 19 Apr 2012 18:27:43 -0500, "Nasser M. Abbasi"<nma@12000.org>
>> wrote, quoted or indirectly quoted someone who said :
>>
>>>     "Unified type system (JDK 10+)
>>>      No more primitives, make everything objects"
>>
>> This is the way Eiffel works,
>
> The same for Python.
>

ironically, in my case I went differently:
the root of the tree is not "objects", it is "variants", of which both 
the primitive/value types and objects are subtypes.

variants have the funky behavior that anything can be stored in a 
variant (no casting needed), but going the other way may throw an 
exception (the language does not require explicit up-casts in most 
cases, but is much more inclined to give warnings about them).

an "object" type also exists, but is generally considered an alias for 
"variant".

"Object" is not the root of the type-system, it is only the root of the 
class hierarchy (the class hierarchy and type-system are not regarded as 
equivalent in this language).


the ability to use ".toString()" on pretty much everything still exists 
though, except it doesn't currently do much useful for some types (many 
types which lack a sensible string representation will show up in a form 
like "#<typename:address>", which is the default syntax for anything 
lacking a known "toString()" method).


>> but under the covers there are still primitives. Perhaps what they
>> have in mind for Java, more intelligent boxing. At least at the low
>> levels of the JVM you need primitives.
>
> These implementation details should better be hidden and invisible for
> most cases. Let the compiler automatically detect and generate
> possible optimisations.
>
> A programming language should be as simple and orthogonal as possible.
>

actually, I personally think it should be as "useful" and "usable" as 
possible, with simplicity and orthogonality coming second.

otherwise, people could be off using very awkward toy languages in the 
name of simplicity and orthogonality, and this would hardly be a better 
outcome.

so, it is more of a set of trade-offs.

[toc] | [prev] | [next] | [standalone]

#13751

BGB wrote:
> Bernd Nawothnig wrote:
>> Roedy Green wrote:
>>> Nasser M. Abbasi wrote, quoted or indirectly quoted someone who said :
>>>> "Unified type system (JDK 10+)
>>>> No more primitives, make everything objects"
>>>
>>> This is the way Eiffel works,
>>
>> The same for Python.
>>
>
> ironically, in my case I went differently:

How exactly is that ironic?

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#13757

On 4/21/2012 12:56 PM, Lew wrote:
> BGB wrote:
>> Bernd Nawothnig wrote:
>>> Roedy Green wrote:
>>>> Nasser M. Abbasi wrote, quoted or indirectly quoted someone who said :
>>>>> "Unified type system (JDK 10+)
>>>>> No more primitives, make everything objects"
>>>>
>>>> This is the way Eiffel works,
>>>
>>> The same for Python.
>>>
>>
>> ironically, in my case I went differently:
>
> How exactly is that ironic?
>

because not everything goes in the same direction, sometimes things go 
in different directions.


for example:
language A has primitives as a subtype of Class/Instance Objects;
language B has Class/Instance Objects a subtype of primitives and 
value-types.

the irony is that a difference in organization of this sort (related to 
a type-ontology) goes against the basic assumptions of such an ontology 
(that there is a hierarchical relationship between the types in question).

or such...

[toc] | [prev] | [next] | [standalone]

#13695

On 04/20/2012 01:27 AM, Nasser M. Abbasi wrote:
> According to
>
> "To Java SE 8, and Beyond! Simon Ritter Technology Evangelist, Oracle"
>
> (Google the string "To Java SE 8 and Beyond!" and click on
> the PDF file, about the 5th link down the page)
>
> On page 42, it says:
>
> "Unified type system (JDK 10+)
> No more primitives, make everything objects"
>
> I've seen very little discussion on this very important
> subject.
>
> What do the experts here think of the idea?
>
> For me, and I am no expert, I think it will be good to have
> a consistent type model (everything is an object), but I am
> worried that the performance will take a hit (computational finite
> elements methods, large meshes, etc...), unless PC's and computers
> will become 1000 times faster by the time JDK 10+ comes in few years
> from now, which might be possible.
>
> Any one knows more information about this item?
> Any truth to it? Do you think it will really happen?
>
> --Nasser

Scala already works this way. There is a common super type Any with 
subclasses AnyRef (akin Object) and AnyVal. The "primitives" reside 
under AnyVal.

[toc] | [prev] | [next] | [standalone]

#13719

On 4/20/2012 10:50 AM, Silvio Bierman wrote:
> On 04/20/2012 01:27 AM, Nasser M. Abbasi wrote:
>> According to
>>
>> "To Java SE 8, and Beyond! Simon Ritter Technology Evangelist, Oracle"
>>
>> (Google the string "To Java SE 8 and Beyond!" and click on
>> the PDF file, about the 5th link down the page)
>>
>> On page 42, it says:
>>
>> "Unified type system (JDK 10+)
>> No more primitives, make everything objects"
>>
>> I've seen very little discussion on this very important
>> subject.
>>
>> What do the experts here think of the idea?
>>
>> For me, and I am no expert, I think it will be good to have
>> a consistent type model (everything is an object), but I am
>> worried that the performance will take a hit (computational finite
>> elements methods, large meshes, etc...), unless PC's and computers
>> will become 1000 times faster by the time JDK 10+ comes in few years
>> from now, which might be possible.
>>
>> Any one knows more information about this item?
>> Any truth to it? Do you think it will really happen?
>
> Scala already works this way. There is a common super type Any with
> subclasses AnyRef (akin Object) and AnyVal. The "primitives" reside
> under AnyVal.

Which is also the C#/.NET way.

Arne

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | comp.lang.java.programmer

csiph-web