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


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

Java blunders

Started byRoedy Green <see_website@mindprod.com.invalid>
First post2014-07-22 11:41 -0700
Last post2014-07-30 10:22 -0500
Articles 20 on this page of 145 — 24 participants

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


Contents

  Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-22 11:41 -0700
    Re: Java blunders Daniele Futtorovic <da.futt.news@laposte.net> - 2014-07-22 21:12 +0200
      Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-22 19:46 -0400
        Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 04:14 -0700
    Re: Java blunders Joerg Meier <joergmmeier@arcor.de> - 2014-07-22 23:47 +0200
      Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 04:23 -0700
        Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-23 12:32 +0000
          Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-23 08:55 -0400
            Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 06:21 -0700
          Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-23 19:53 -0400
            Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 18:49 -0700
        Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-23 19:52 -0400
    Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-22 19:44 -0400
      Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 04:27 -0700
        Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-23 19:55 -0400
          Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 18:53 -0700
            Re: Java blunders Joerg Meier <joergmmeier@arcor.de> - 2014-07-24 11:24 +0200
              Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-25 06:34 -0700
            Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-24 19:31 -0400
              Re: Java blunders Gene Wirchenko <genew@telus.net> - 2014-07-25 13:22 -0700
                Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-25 17:17 -0400
                  Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-25 23:12 +0000
                  Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 09:06 -0700
                    Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-26 20:11 +0000
                      Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-26 17:27 -0400
                        Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-27 10:49 -0700
                      Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-27 10:10 -0700
                        Re: Java blunders Gene Wirchenko <genew@telus.net> - 2014-07-28 13:53 -0700
                          Re: Java blunders Stuart <DerTopper@web.de> - 2014-07-30 08:05 +0200
                            Re: Java blunders Sebastian <news@seyweiler.dyndns.org> - 2014-07-30 11:12 +0200
                      Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-27 10:13 -0700
                        Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-27 18:28 +0000
                          Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-27 14:46 -0400
                            Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-27 21:18 +0000
                              Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-27 18:10 -0400
                                Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-28 01:25 +0000
                                  Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-28 08:02 -0400
                                Re: Java blunders Mike Amling <mamling@chaff.us> - 2014-07-31 13:26 -0500
                                  Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-31 14:48 -0400
                          Re: Java blunders "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-07-28 13:22 +0100
                            Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-28 12:52 +0000
                            Re: Java blunders Joerg Meier <joergmmeier@arcor.de> - 2014-07-28 23:38 +0200
                              Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-28 23:17 +0000
                                Re: Java blunders Silvio <silvio@internet.com> - 2014-07-29 13:34 +0200
                                  Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-29 12:45 +0000
                                    Re: Java blunders Silvio <silvio@internet.com> - 2014-07-29 17:10 +0200
                                      Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-29 16:29 +0000
                                        Re: Java blunders lipska the kat <lipskathekat@example.com> - 2014-07-29 20:15 +0100
                                          Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-29 22:02 +0000
                                        Re: Java blunders Silvio <silvio@internet.com> - 2014-07-29 22:43 +0200
                                          Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-29 22:10 +0000
                        Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-27 19:18 -0500
                        Re: Java blunders Gene Wirchenko <genew@telus.net> - 2014-07-28 13:54 -0700
                      Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-31 23:07 -0400
                        Re: Java blunders James Hostick <james.hostick@gmail.com> - 2014-08-01 22:10 -0700
              Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 08:31 -0700
                Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-26 21:04 +0000
                  Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-27 10:51 -0700
                  Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-28 08:50 -0700
                    Re: Java blunders Joerg Meier <joergmmeier@arcor.de> - 2014-07-28 23:42 +0200
                Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-31 23:04 -0400
            Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-28 22:23 +0200
              Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-28 16:39 -0400
                Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-29 00:11 +0200
                Re: Java blunders Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2014-07-30 12:07 +0300
                  Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-30 08:05 -0400
      Re: Java blunders Wanja Gayk <brixomatic@yahoo.com> - 2014-07-25 01:34 +0200
        Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-24 19:43 -0400
    Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-22 21:02 -0500
      Re: Java blunders Leif Roar Moldskred <leifm@huldreskog.lan> - 2014-07-23 02:01 -0500
        Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 18:58 -0700
        Re: Java blunders thinbluernime <thinbluernime3@gmail.com> - 2014-07-25 03:55 +0000
          Re: Java blunders Leif Roar Moldskred <leifm@huldreskog.lan> - 2014-07-25 00:32 -0500
            Re: Java blunders thinbluernime <thinbluernime3@gmail.com> - 2014-07-26 07:28 +0000
              Re: Java blunders "Gavino" <invalid@invalid.invalid> - 2014-07-26 19:43 +0200
          Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-25 06:36 -0700
            Re: Java blunders "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-07-25 15:47 +0100
              Re: Java blunders David Postill <david.postill@gmail.com> - 2014-07-25 18:29 +0200
              Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 09:27 -0700
          Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-25 06:37 -0700
      Re: Java blunders Joerg Meier <joergmmeier@arcor.de> - 2014-07-23 13:17 +0200
        Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 06:27 -0700
      Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 04:44 -0700
        Re: Java blunders Silvio <silvio@internet.com> - 2014-07-23 16:23 +0200
          Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-23 12:02 -0400
            Re: Java blunders Silvio <silvio@internet.com> - 2014-07-24 11:37 +0200
              Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-28 22:37 +0200
          Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 09:33 -0700
            Re: Java blunders thinbluernime <thinbluernime3@gmail.com> - 2014-07-25 03:57 +0000
          Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-23 21:38 -0400
            Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 18:59 -0700
              Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-24 07:33 +0000
            Re: Java blunders Silvio <silvio@internet.com> - 2014-07-24 11:47 +0200
              Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-24 19:34 -0400
                Re: Java blunders Silvio <silvio@internet.com> - 2014-07-25 08:48 +0200
                  Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-25 08:07 -0400
                    Re: Java blunders "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-07-25 13:54 +0100
                  Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-31 22:53 -0400
              Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-25 07:04 -0700
          Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-28 22:01 +0200
        Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-28 21:56 +0200
      Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 06:28 -0700
        Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-23 08:33 -0500
      Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-23 21:34 -0400
        Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-23 19:06 -0700
        Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-23 22:11 -0500
          Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-24 07:36 +0000
            Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-24 19:39 -0400
              Re: Java blunders "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-07-25 13:40 +0100
          Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-24 19:38 -0400
            Re: Java blunders Gene Wirchenko <genew@telus.net> - 2014-07-25 13:30 -0700
    Re: Java blunders taqmcg@gmail.com - 2014-07-23 11:26 -0700
      Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-23 15:14 -0400
        Re: Java blunders thinbluernime <thinbluernime3@gmail.com> - 2014-07-25 04:07 +0000
          Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-25 08:35 -0400
            Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 09:41 -0700
          Re: Java blunders Wanja Gayk <brixomatic@yahoo.com> - 2014-08-03 16:41 +0200
            Re: Java blunders Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-03 11:31 -0400
      Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-23 22:41 -0500
        Re: Java blunders taqmcg@gmail.com - 2014-07-24 10:09 -0700
          Re: Java blunders "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-07-25 13:22 +0100
          Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-25 20:34 -0500
            Re: Java blunders "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-07-28 13:33 +0100
              Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-28 08:35 -0500
          Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 09:44 -0700
            Re: Java blunders Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-26 23:36 +0000
    Re: Java blunders Gene Wirchenko <genew@telus.net> - 2014-07-23 20:48 -0700
      Re: Java blunders Silvio <silvio@internet.com> - 2014-07-24 11:56 +0200
        Re: Java blunders Silvio <silvio@internet.com> - 2014-07-24 16:07 +0200
          Re: Java blunders Gene Wirchenko <genew@telus.net> - 2014-07-25 13:38 -0700
            Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 10:02 -0700
      Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-24 19:29 -0400
        Re: Java blunders Gene Wirchenko <genew@telus.net> - 2014-07-25 13:45 -0700
      Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 10:53 -0700
    Re: Java blunders Wanja Gayk <brixomatic@yahoo.com> - 2014-07-25 01:28 +0200
    Re: Java blunders "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-07-25 14:16 +0100
    Re: Java blunders Joerg Meier <joergmmeier@arcor.de> - 2014-07-25 17:39 +0200
    Re: Java blunders Roedy Green <see_website@mindprod.com.invalid> - 2014-07-26 16:21 -0700
    Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-28 23:59 +0200
      Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-29 00:41 +0200
        Re: Java blunders Josip Almasi <joe@vrspace.org> - 2014-07-29 01:54 +0200
      Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-31 22:38 -0400
      Re: Java blunders Arne Vajhøj <arne@vajhoej.dk> - 2014-07-31 22:39 -0400
    Re: Java blunders w.tom.adams@gmail.com - 2014-07-30 07:57 -0700
      Re: Java blunders Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-07-30 10:22 -0500

Page 1 of 8  [1] 2 3 4 5 6 7 8  Next page →


#29201 — Java blunders

FromRoedy Green <see_website@mindprod.com.invalid>
Date2014-07-22 11:41 -0700
SubjectJava blunders
Message-ID<jvbts91r2f9onj1e3dbr5lvqp70hmofkum@4ax.com>
I have composed an essay about what I consider were the blunders in
the design of Java.  I hold out hope many of them will eventually 
be fixed. You might like to add to the list.


see http://mindprod.com/jgloss/javablunders.html
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Science is what we understand well enough to explain to a computer.
Art is everything else we do. 
~ Donald Ervin Knuth (born: 1938-01-10 age: 76)

[toc] | [next] | [standalone]


#29205

FromDaniele Futtorovic <da.futt.news@laposte.net>
Date2014-07-22 21:12 +0200
Message-ID<lqmd2l$mq8$1@dont-email.me>
In reply to#29201
On 2014-07-22 20:41, Roedy Green allegedly wrote:
> I have composed an essay about what I consider were the blunders in 
> the design of Java.  I hold out hope many of them will eventually be
> fixed. You might like to add to the list.
> 
> 
> see http://mindprod.com/jgloss/javablunders.html
> 

> for each requires you to specify the type of the indexing variable.
> The compiler knows that from the type of the set it iterates over.
> This means needlessly propagating type information in more than one
> place in your program.
> 
> The syntax to invoke a callback with an anonymous class instance
> delegate is embarrassingly verbose. Lambda expressions in Java 1.8+
> fix this.
> 
> You should be able to declare a temporary variable as having the same
> type as some other variable, so that for example if the original
> variable changes from int to long, the temporary will automatically
> change too.

On these three at least I strongly disagree. Java is strongly typed and
is a stringent language. Stringency can be a pain sometimes, but overall
is a good thing. It provides clarity as to the inner workings and logic
of the language, and hence a firm (mental) basis to work on. It
discourages wild coding -- the kind of euphoric coding you engage in
when you have to be weary of what's going on below the hood because you
don't and can't know it.

-- 
D.F.

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


#29213

FromArne Vajhøj <arne@vajhoej.dk>
Date2014-07-22 19:46 -0400
Message-ID<53cef7c4$0$291$14726298@news.sunsite.dk>
In reply to#29205
On 7/22/2014 3:12 PM, Daniele Futtorovic wrote:
> On 2014-07-22 20:41, Roedy Green allegedly wrote:
>> I have composed an essay about what I consider were the blunders in
>> the design of Java.  I hold out hope many of them will eventually be
>> fixed. You might like to add to the list.
>>
>> see http://mindprod.com/jgloss/javablunders.html
>>
>> for each requires you to specify the type of the indexing variable.
>> The compiler knows that from the type of the set it iterates over.
>> This means needlessly propagating type information in more than one
>> place in your program.
>>
>> The syntax to invoke a callback with an anonymous class instance
>> delegate is embarrassingly verbose. Lambda expressions in Java 1.8+
>> fix this.
>>
>> You should be able to declare a temporary variable as having the same
>> type as some other variable, so that for example if the original
>> variable changes from int to long, the temporary will automatically
>> change too.
>
> On these three at least I strongly disagree. Java is strongly typed and
> is a stringent language. Stringency can be a pain sometimes, but overall
> is a good thing. It provides clarity as to the inner workings and logic
> of the language, and hence a firm (mental) basis to work on. It
> discourages wild coding -- the kind of euphoric coding you engage in
> when you have to be weary of what's going on below the hood because you
> don't and can't know it.

Type inference does not imply less type safety.

C# var is just as type safe as explicit declaration of type.

C# dynamic is not, but I don't think Roedy is asking for that.

Arne

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


#29222

FromRoedy Green <see_website@mindprod.com.invalid>
Date2014-07-23 04:14 -0700
Message-ID<j06vs9111hd9aro63tud8jbfg0ev5ft70u@4ax.com>
In reply to#29213
On Tue, 22 Jul 2014 19:46:10 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :

>Type inference does not imply less type safety.
>
>C# var is just as type safe as explicit declaration of type.
>
>C# dynamic is not, but I don't think Roedy is asking for that.

I am a strong advocate of very tight type safety.  It catches so many
bugs at compile time.  I don't think any of the changes I request
reduce type safety. They do reduce specifying the type explicitly over
and over.  So they do reduce awareness of what type something is.


The problem I am trying to fix is having to specify the same type in
many places.  If you change you mind, you have to change it is many
places.  Usually the compiler's complaints will find the places that
need fixup, but not always.  The notion of encapsulation is that any
decision should specified in one and only one place. When you change
it, it is changed. You don't have to manually keep multiple copies of
that decision in sync.  Currently Java makes you propagate the type.

One mitigating factor is using interfaces for references and concrete
classes to construct. That lets you change the type in only one place.
There is nothing comparable for primitives.

-- 
Roedy Green Canadian Mind Products http://mindprod.com
Science is what we understand well enough to explain to a computer.
Art is everything else we do. 
~ Donald Ervin Knuth (born: 1938-01-10 age: 76)

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


#29211

FromJoerg Meier <joergmmeier@arcor.de>
Date2014-07-22 23:47 +0200
Message-ID<7yf7pbm3gs9r$.1kq8rlnls3wt5$.dlg@40tude.net>
In reply to#29201
On Tue, 22 Jul 2014 11:41:24 -0700, Roedy Green wrote:

> I have composed an essay about what I consider were the blunders in
> the design of Java.  I hold out hope many of them will eventually 
> be fixed. You might like to add to the list.

It's disturbing that you would think there is any chance that many of them
would be "fixed" which would break backwards compatibility with every
single Java program out there. You seriously think they will some day make
byte unsigned, change precedence, change {}, change the existing JFC APIs,
the behaviour of + or import static ?

"Hey guys, here is Java 1.9, enjoy the zero Java programs it can run!".

Your list of demands is also quite schizophrenic, complaining about too
much complexity on one topic while demanding special behaviour for select
scenarios to be added to save a few keystrokes in others.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

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


#29224

FromRoedy Green <see_website@mindprod.com.invalid>
Date2014-07-23 04:23 -0700
Message-ID<k96vs957b3ndhqi7v0k10me7sqa9re7dgf@4ax.com>
In reply to#29211
On Tue, 22 Jul 2014 23:47:11 +0200, Joerg Meier <joergmmeier@arcor.de>
wrote, quoted or indirectly quoted someone who said :

>It's disturbing that you would think there is any chance that many of them
>would be "fixed" which would break backwards compatibility with every
>single Java program out there. You seriously think they will some day make
>byte unsigned, change precedence, change {}, change the existing JFC APIs,
>the behaviour of + or import static ?

Obviously changing precedence would break everything.  I said that in
my essay.  That would require a new language, or some sort of
annotation to declare the new rules are in effect.  You cannot make
existing code have different semantics.

You would not make byte unsigned. It is far too late for that. You
would add a ubyte unsigned type.

The {} change does not even need a change in Java. It could be
implemented in IDEs, where there are unique visual markers for various
types of block. All the compiler ever sees are {}.  The balancing of
block types is used to localise unbalancing problems, or perhaps make
them impossible.

To fix import static, just make the word "static" optional. 

To fix plus, again this could be done by IDEs using two different +
glyphs (different fonts/shapes/colours/glyphs) The compiler would see
both as ordinary +.



-- 
Roedy Green Canadian Mind Products http://mindprod.com
Science is what we understand well enough to explain to a computer.
Art is everything else we do. 
~ Donald Ervin Knuth (born: 1938-01-10 age: 76)

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


#29228

FromMartin Gregorie <martin@address-in-sig.invalid>
Date2014-07-23 12:32 +0000
Message-ID<lqoa14$43a$1@dont-email.me>
In reply to#29224
On Wed, 23 Jul 2014 04:23:44 -0700, Roedy Green wrote:

> You would not make byte unsigned. It is far too late for that. You would
> add a ubyte unsigned type.
>
Or introduce an 'unsigned' qualifier that would only be valid for numeric 
primitives. Its not a big change to the language because Java already 
uses qualifiers, e.g. static and final. I'd prefer this to introducing a 
new primitive type.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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


#29229

FromEric Sosman <esosman@comcast-dot-net.invalid>
Date2014-07-23 08:55 -0400
Message-ID<lqobbm$j0f$1@dont-email.me>
In reply to#29228
On 7/23/2014 8:32 AM, Martin Gregorie wrote:
> On Wed, 23 Jul 2014 04:23:44 -0700, Roedy Green wrote:
>
>> You would not make byte unsigned. It is far too late for that. You would
>> add a ubyte unsigned type.
>>
> Or introduce an 'unsigned' qualifier that would only be valid for numeric
> primitives. Its not a big change to the language because Java already
> uses qualifiers, e.g. static and final. I'd prefer this to introducing a
> new primitive type.

     ... except it *would* be a new primitive type, just spelled with two
words instead of one:

     - The `unsigned x' could represent values a plain `x' could not,
       and vice versa,

     - Arithmetic on identical `unsigned x' and `x' values could yield
       different results,

     - There would need to be new rules for mixed-mode arithmetic (for
       example, what is `-6 % (unsigned int) 3'?), or a prohibition
       against such expressions.

Different values, different behavior, different rules -> different
types.

-- 
esosman@comcast-dot-net.invalid

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


#29230

FromRoedy Green <see_website@mindprod.com.invalid>
Date2014-07-23 06:21 -0700
Message-ID<pjdvs9t693aln8tg3ga3ckticdm3pcgj3n@4ax.com>
In reply to#29229
On Wed, 23 Jul 2014 08:55:14 -0400, Eric Sosman
<esosman@comcast-dot-net.invalid> wrote, quoted or indirectly quoted
someone who said :

>     - There would need to be new rules for mixed-mode arithmetic (for
>       example, what is `-6 % (unsigned int) 3'?), or a prohibition
>       against such expressions.

IIRC I asked Bill Joy about this. He said they left out unsigned int
and long because the rules get weird and the corner cases
pathological.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Science is what we understand well enough to explain to a computer.
Art is everything else we do. 
~ Donald Ervin Knuth (born: 1938-01-10 age: 76)

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


#29245

FromArne Vajhøj <arne@vajhoej.dk>
Date2014-07-23 19:53 -0400
Message-ID<53d04af9$0$291$14726298@news.sunsite.dk>
In reply to#29228
On 7/23/2014 8:32 AM, Martin Gregorie wrote:
> On Wed, 23 Jul 2014 04:23:44 -0700, Roedy Green wrote:
>> You would not make byte unsigned. It is far too late for that. You would
>> add a ubyte unsigned type.
>>
> Or introduce an 'unsigned' qualifier that would only be valid for numeric
> primitives. Its not a big change to the language because Java already
> uses qualifiers, e.g. static and final. I'd prefer this to introducing a
> new primitive type.

It is still a new type, because the JVM would need to treat unsigned
differently from signed.

Arne

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


#29250

FromRoedy Green <see_website@mindprod.com.invalid>
Date2014-07-23 18:49 -0700
Message-ID<1cp0t9hlt0cch1chugv6kebupak4g73tqp@4ax.com>
In reply to#29245
On Wed, 23 Jul 2014 19:53:27 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :

>It is still a new type, because the JVM would need to treat unsigned
>differently from signed.

You could implement it by not changing the JVM.  Just have Javac
automatically add "and 0xff" after every signed byte load.

I would hope that HotSpot looks for that pattern now and converts it
to an assembly unsigned byte load.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Science is what we understand well enough to explain to a computer.
Art is everything else we do. 
~ Donald Ervin Knuth (born: 1938-01-10 age: 76)

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


#29244

FromArne Vajhøj <arne@vajhoej.dk>
Date2014-07-23 19:52 -0400
Message-ID<53d04aa3$0$291$14726298@news.sunsite.dk>
In reply to#29224
On 7/23/2014 7:23 AM, Roedy Green wrote:
> The {} change does not even need a change in Java. It could be
> implemented in IDEs, where there are unique visual markers for various
> types of block. All the compiler ever sees are {}.  The balancing of
> block types is used to localise unbalancing problems, or perhaps make
> them impossible.
>
> To fix import static, just make the word "static" optional.
>
> To fix plus, again this could be done by IDEs using two different +
> glyphs (different fonts/shapes/colours/glyphs) The compiler would see
> both as ordinary +.

That is not a change to Java but a change to the IDE.

Arne

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


#29212

FromArne Vajhøj <arne@vajhoej.dk>
Date2014-07-22 19:44 -0400
Message-ID<53cef75d$0$291$14726298@news.sunsite.dk>
In reply to#29201
On 7/22/2014 2:41 PM, Roedy Green wrote:
> I have composed an essay about what I consider were the blunders in
> the design of Java.  I hold out hope many of them will eventually be
> fixed. You might like to add to the list.
>
> see http://mindprod.com/jgloss/javablunders.html

# byte is signed. You almost never want a signed byte. Further,
# there is no unsigned byte. ubyte would be trivial to implement. It
# would require no changes to the JVM (Java Virtual Machine). It would
# catch all manner of bugs forgetting to do & 0xff after a byte load.

I completely agree.

#    for each requires you to specify the type of the indexing
# variable. The compiler knows that from the type of the set it
# iterates over. This means needlessly propagating type information in
# more than one place in your program.

# You should be able to declare a temporary variable as having the same
# type as some other variable, so that for example if the original
# variable changes from int to long, the temporary will automatically
# change too.

You are really asking for the ability to use var/val and let the compiler
determine the type via type interference.

That is quite popular in languages today.

It could certainly be added to Java.

But I am so conservative that I think it would go against some
core Java principles.

# Java overuses {}. If you drop a } you can spend 15 minutes trying to
# get them balanced again. If methods, classes, loops, etc had unique
# end markers, there would be no problem. If methods, classes, loops
# etc had unique visual markers at begin and end, (perhaps small icons
# generated on the fly by the IDE (Integrated Development
# Environment)), code would be much easier to read and scan.

There are languages that use:
   if ... end if
   for ... end for
   while ... end for
   record ... end record
   class ... end class
   function ... end function
   procedure ... end procedure
   etc.

And I actually like that syntax.

But this can not be changed in Java without creating total
confusion.

Next language!

# Java uses + for both concatenation and addition. The ambiguity leads
# to all kinds of strange bugs.

Really?

That is not my impression.

> You should be able to have arrays of Objects, not just arrays of
 > references to Objects so you could do an efficient Complex class.

You are asking for value types.

It could be added.

But it is a big chunk of complexity to add.

And I somewhat question whether the benefits are big enough
to outweigh the complexity.

Arne

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


#29226

FromRoedy Green <see_website@mindprod.com.invalid>
Date2014-07-23 04:27 -0700
Message-ID<7s6vs9p395bretqrtdvh9i6til83vfk52p@4ax.com>
In reply to#29212
On Tue, 22 Jul 2014 19:44:23 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :

># Java uses + for both concatenation and addition. The ambiguity leads
># to all kinds of strange bugs.
>
>Really?

I once did a lecture at the Colorado software conference. I created
some pathological examples using + both as addition and concatenation.

NOBODY in the audience got them right guessing what the result was.
Most of the people in the audience were more experienced programmers
than I was.

The compiler does not catch it.  The run time does not catch it.  You
just get some strange output.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Science is what we understand well enough to explain to a computer.
Art is everything else we do. 
~ Donald Ervin Knuth (born: 1938-01-10 age: 76)

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


#29246

FromArne Vajhøj <arne@vajhoej.dk>
Date2014-07-23 19:55 -0400
Message-ID<53d04b5f$0$291$14726298@news.sunsite.dk>
In reply to#29226
On 7/23/2014 7:27 AM, Roedy Green wrote:
> On Tue, 22 Jul 2014 19:44:23 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>
>> # Java uses + for both concatenation and addition. The ambiguity leads
>> # to all kinds of strange bugs.
>>
>> Really?
>
> I once did a lecture at the Colorado software conference. I created
> some pathological examples using + both as addition and concatenation.
>
> NOBODY in the audience got them right guessing what the result was.
> Most of the people in the audience were more experienced programmers
> than I was.
>
> The compiler does not catch it.  The run time does not catch it.  You
> just get some strange output.

I am sure funky examples can be created.

But is it a problem in real world programming?

I have never seen a problem due to this.

Arne

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


#29251

FromRoedy Green <see_website@mindprod.com.invalid>
Date2014-07-23 18:53 -0700
Message-ID<sip0t9dqg0c77e7u4o7vo2brs8chsdqok7@4ax.com>
In reply to#29246
On Wed, 23 Jul 2014 19:55:09 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :

>But is it a problem in real world programming?
>
>I have never seen a problem due to this.


The most common error is like this:

out.println ( "the answer is " + 
a + b
+ ".");

you must write that as:

out.println ( "the answer is " + (a + b) + ".");

-- 
Roedy Green Canadian Mind Products http://mindprod.com
Science is what we understand well enough to explain to a computer.
Art is everything else we do. 
~ Donald Ervin Knuth (born: 1938-01-10 age: 76)

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


#29264

FromJoerg Meier <joergmmeier@arcor.de>
Date2014-07-24 11:24 +0200
Message-ID<1h7kvqdeyjf6v.1cxg33cieg1ym.dlg@40tude.net>
In reply to#29251
On Wed, 23 Jul 2014 18:53:40 -0700, Roedy Green wrote:

> On Wed, 23 Jul 2014 19:55:09 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>>But is it a problem in real world programming?

>>I have never seen a problem due to this.
> The most common error is like this:

> out.println ( "the answer is " + 
> a + b
> + ".");

> you must write that as:

> out.println ( "the answer is " + (a + b) + ".");

That is indeed a sort of common error. But so what ? Forgetting a ; is a
common error too. It's common, but it is very easy to debug, so why is this
such a big deal ?

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

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


#29309

FromRoedy Green <see_website@mindprod.com.invalid>
Date2014-07-25 06:34 -0700
Message-ID<n6n4t99bpsjn0pef82c9u93btj8u0niug4@4ax.com>
In reply to#29264
On Thu, 24 Jul 2014 11:24:58 +0200, Joerg Meier <joergmmeier@arcor.de>
wrote, quoted or indirectly quoted someone who said :

>That is indeed a sort of common error. But so what ? Forgetting a ; is a
>common error too. It's common, but it is very easy to debug, so why is this
>such a big deal ?

 It is not easy to debug. The compile thinks it is fine. It does not
cause a run time exception. You have to find it by noticing the bad
output.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Science is what we understand well enough to explain to a computer.
Art is everything else we do. 
~ Donald Ervin Knuth (born: 1938-01-10 age: 76)

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


#29281

FromArne Vajhøj <arne@vajhoej.dk>
Date2014-07-24 19:31 -0400
Message-ID<53d19752$0$295$14726298@news.sunsite.dk>
In reply to#29251
On 7/23/2014 9:53 PM, Roedy Green wrote:
> On Wed, 23 Jul 2014 19:55:09 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>> But is it a problem in real world programming?
>>
>> I have never seen a problem due to this.
>
> The most common error is like this:
>
> out.println ( "the answer is " +
> a + b
> + ".");
>
> you must write that as:
>
> out.println ( "the answer is " + (a + b) + ".");

But that is not a problem due to reuse of operators.

That is a problem due to lack of understanding of order
of evaluation.

A new concatenation operator would not solve that problem
in all cases.

Arne

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


#29322

FromGene Wirchenko <genew@telus.net>
Date2014-07-25 13:22 -0700
Message-ID<jve5t99ju3dgui6974n0tfh6u8jk4nnqet@4ax.com>
In reply to#29281
On Thu, 24 Jul 2014 19:31:29 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:

>On 7/23/2014 9:53 PM, Roedy Green wrote:
>> On Wed, 23 Jul 2014 19:55:09 -0400, Arne Vajhøj <arne@vajhoej.dk>
>> wrote, quoted or indirectly quoted someone who said :
>>> But is it a problem in real world programming?
>>>
>>> I have never seen a problem due to this.
>>
>> The most common error is like this:
>>
>> out.println ( "the answer is " +
>> a + b
>> + ".");
>>
>> you must write that as:
>>
>> out.println ( "the answer is " + (a + b) + ".");
>
>But that is not a problem due to reuse of operators.

     But it is.  There are effectively two + operators, and the effect
is a confusing result.

>That is a problem due to lack of understanding of order
>of evaluation.

     IOW, confusion.

>A new concatenation operator would not solve that problem
>in all cases.

     Raising the bar to all cases?

     A concatenation operator would allow the precedence to be
different from +.

Sincerely,

Gene Wirchenko

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


Page 1 of 8  [1] 2 3 4 5 6 7 8  Next page →

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


csiph-web