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

Java blunders

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

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

  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 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →

#29402

From	Josip Almasi <joe@vrspace.org>
Date	2014-07-28 21:56 +0200
Message-ID	<lr69t6$140$1@gregory.bnet.hr>
In reply to	#29227

On 07/23/2014 01:44 PM, Roedy Green wrote:
>
> I find sorting out braces is by far the most-time consuming busywork
> in preparing Java source. It is not fun. It is just irritating.
...

Uh, that's a bit silly.
If so, you should invest time to find and learn a better editor.

https://encrypted-tbn3.gstatic.com/images?q=tbn:ANd9GcRXxb1zTfQpP56NTXIRJb02qGB71QNryi1EI_r3oVfajhiV_9Ww

Regards...

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

#29232

From	Roedy Green <see_website@mindprod.com.invalid>
Date	2014-07-23 06:28 -0700
Message-ID	<03evs9tj9760dsk7o9cecldh27bkuinbme@4ax.com>
In reply to	#29219

On Tue, 22 Jul 2014 21:02:07 -0500, Joshua Cranmer ?
<Pidgeot18@verizon.invalid> wrote, quoted or indirectly quoted someone
who said :

>y IDE points out matching curly braces 
>and can even fold them based on appropriate matching, and it has been 
>able to do so since before Java was invented. 

What is your IDE?
-- 
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]

#29233

From	Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid>
Date	2014-07-23 08:33 -0500
Message-ID	<lqodjj$1u6$1@dont-email.me>
In reply to	#29232

On 7/23/2014 8:28 AM, Roedy Green wrote:
> On Tue, 22 Jul 2014 21:02:07 -0500, Joshua Cranmer ?
> <Pidgeot18@verizon.invalid> wrote, quoted or indirectly quoted someone
> who said :
>
>> y IDE points out matching curly braces
>> and can even fold them based on appropriate matching, and it has been
>> able to do so since before Java was invented.
>
> What is your IDE?

Vim. Although Emacs probably fits the description as well.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

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

#29248

From	Arne Vajhøj <arne@vajhoej.dk>
Date	2014-07-23 21:34 -0400
Message-ID	<53d0629b$0$291$14726298@news.sunsite.dk>
In reply to	#29219

On 7/22/2014 10:02 PM, Joshua Cranmer 🐧 wrote:
> C. On the balance, I think matching curly braces is superior to
> begin/end-ish constructs. If you're spending too much time trying to
> figure out where you have an extra or a missing curly brace, then, quite
> frankly, your IDE is defective. My IDE points out matching curly braces
> and can even fold them based on appropriate matching, and it has been
> able to do so since before Java was invented. Possibly since before I
> was born, even.

To me having an IDE make up for something missing in the
language does not excuse that the feature is missing.

An IDE is just not always present when reading code.

(and I think the readability is more of a problem than
the fixing one too few or one too many problems)

Arne

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

#29254

From	Roedy Green <see_website@mindprod.com.invalid>
Date	2014-07-23 19:06 -0700
Message-ID	<o4q0t95m4vjli57angv43c44n18f7b1jqr@4ax.com>
In reply to	#29248

On Wed, 23 Jul 2014 21:34:17 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :

>To me having an IDE make up for something missing in the
>language does not excuse that the feature is missing.

The advantage of putting a feature in a IDE/SCID is you sidestep the
political problem of convincing people the language needs to be
changed.  You can try an idea out.  If it is good one, it may spread.

With the SCID approach, everyone can do things their way. The Java
language is an interchange format. There is no reason you should have
to edit it as UTF-8 text any more than you have to edit HTML as text.

See http://mindprod.com/project/scid.html

for what you might do to change the language without actually changing
anything.

"I mean, source code in files; how quaint, how seventies!"
~ Kent Beck Born 1961 
-- 
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]

#29255

From	Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid>
Date	2014-07-23 22:11 -0500
Message-ID	<lqpthp$ccv$1@dont-email.me>
In reply to	#29248

On 7/23/2014 8:34 PM, Arne Vajhøj wrote:
> On 7/22/2014 10:02 PM, Joshua Cranmer 🐧 wrote:
>> C. On the balance, I think matching curly braces is superior to
>> begin/end-ish constructs. If you're spending too much time trying to
>> figure out where you have an extra or a missing curly brace, then, quite
>> frankly, your IDE is defective. My IDE points out matching curly braces
>> and can even fold them based on appropriate matching, and it has been
>> able to do so since before Java was invented. Possibly since before I
>> was born, even.
>
> To me having an IDE make up for something missing in the
> language does not excuse that the feature is missing.
>
> An IDE is just not always present when reading code.
>
> (and I think the readability is more of a problem than
> the fixing one too few or one too many problems)

If you're arguing that begin/end is superior for readability... it's 
not. It's no better, and could potentially be worse.

1. If you have deep nesting, it's almost certainly going to be mostly or 
all if statements at the bottom. Loops don't nest deep in practice (you 
could make a loop nest larger than 3 a compiler error and almost all 
production code would still compile). So distinguishing between all the 
different kinds of classes of block structures buys you very little, and 
nothing at all in the worst classes.

2. Close structures are less well-coordinated among different languages. 
Is it end, endif, end if, or fi?

3. When you do scans of code, you're almost certainly not looking for 
braces or begin/end-style keywords. You're looking at the indentation 
level primarily. The signal for a termination of a block, then, is a 
mostly-empty line that contains the close construct at the appropriate 
indentation level. end doesn't help you there.

4. The smaller '}' typing hides what is effectively not semantically 
valuable text, given the preference for indentation level instead. 
Seeing a word like 'end' means you have to parse it to make sure you can 
ignore it. This effect is probably very small and may not actually exist.

5. It's less typing. Not a strong argument, but given no strong argument 
for an end-like construct in the first place (see above), it does help 
tip the balance if you're undecided.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

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

#29261

From	Martin Gregorie <martin@address-in-sig.invalid>
Date	2014-07-24 07:36 +0000
Message-ID	<lqqd2j$l2m$2@dont-email.me>
In reply to	#29255

On Wed, 23 Jul 2014 22:11:35 -0500, Joshua Cranmer 🐧 wrote:

> On 7/23/2014 8:34 PM, Arne Vajhøj wrote:
>> On 7/22/2014 10:02 PM, Joshua Cranmer 🐧 wrote:
>>> C. On the balance, I think matching curly braces is superior to
>>> begin/end-ish constructs. If you're spending too much time trying to
>>> figure out where you have an extra or a missing curly brace, then,
>>> quite frankly, your IDE is defective. My IDE points out matching curly
>>> braces and can even fold them based on appropriate matching, and it
>>> has been able to do so since before Java was invented. Possibly since
>>> before I was born, even.
>>
>> To me having an IDE make up for something missing in the language does
>> not excuse that the feature is missing.
>>
>> An IDE is just not always present when reading code.
>>
>> (and I think the readability is more of a problem than the fixing one
>> too few or one too many problems)
> 
> If you're arguing that begin/end is superior for readability... it's
> not. It's no better, and could potentially be worse.
>
Yes - and you can always use comments if thye code is that complex:

    for (int i = 0; i < n; i++)
    {
        Deeply nested complex stuff, 
        eventually coming to and end.
    } /* end outer loop */
 


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

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

#29285

From	Arne Vajhøj <arne@vajhoej.dk>
Date	2014-07-24 19:39 -0400
Message-ID	<53d1993e$0$295$14726298@news.sunsite.dk>
In reply to	#29261

On 7/24/2014 3:36 AM, Martin Gregorie wrote:
> On Wed, 23 Jul 2014 22:11:35 -0500, Joshua Cranmer 🐧 wrote:
>
>> On 7/23/2014 8:34 PM, Arne Vajhøj wrote:
>>> On 7/22/2014 10:02 PM, Joshua Cranmer 🐧 wrote:
>>>> C. On the balance, I think matching curly braces is superior to
>>>> begin/end-ish constructs. If you're spending too much time trying to
>>>> figure out where you have an extra or a missing curly brace, then,
>>>> quite frankly, your IDE is defective. My IDE points out matching curly
>>>> braces and can even fold them based on appropriate matching, and it
>>>> has been able to do so since before Java was invented. Possibly since
>>>> before I was born, even.
>>>
>>> To me having an IDE make up for something missing in the language does
>>> not excuse that the feature is missing.
>>>
>>> An IDE is just not always present when reading code.
>>>
>>> (and I think the readability is more of a problem than the fixing one
>>> too few or one too many problems)
>>
>> If you're arguing that begin/end is superior for readability... it's
>> not. It's no better, and could potentially be worse.
>>
> Yes - and you can always use comments if thye code is that complex:
>
>      for (int i = 0; i < n; i++)
>      {
>          Deeply nested complex stuff,
>          eventually coming to and end.
>      } /* end outer loop */

That is sometimes used.

But to me that is a workaround not the optimal solution.

Arne

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

#29306

From	"Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org>
Date	2014-07-25 13:40 +0100
Message-ID	<DtqdnX7WstBFzE_OnZ2dnUVZ8tOdnZ2d@bt.com>
In reply to	#29285

Arne Vajhøj wrote:

> >      for (int i = 0; i < n; i++)
> >      {
> >          Deeply nested complex stuff,
> >          eventually coming to and end.
> >      } /* end outer loop */
>
> That is sometimes used.
>
> But to me that is a workaround not the optimal solution.

It can be a workaround and still part of an optimal solution.  If -- as I'd 
expect is true -- the impact of using a suboptimal, roll-your-own, solution 
with comments (for the rare cases where it actually beneficial) is less than 
the impact of using a more verbose notation /everywhere/, then you have a nett 
gain.

<insert obligatory condemnation of over-long methods here>

BTW, I have actually worked with code that used that convention (not in Java, 
but in a little-known language called VDF -- the chocolate teapot of Rapid 
Application Development).  Some of it was misapplied because it was flagging 
the end of a small compound statement.  Some of it was misapplied because --  
although it helped a tiny bit -- refactoring the method would help a Hell Of A 
Lot more.  Even at the best it wasn't much use because it only flagged the end 
of the syntactic construct (if condition, while loop, whatever), but not /what/ 
condition, loop, etc.  I.e. it was stuff like (using pseudo code):

    if (the person under consideration is dead)
    then
        ... complex operations...
    end // of if

rather than:

    if (the person under consideration is dead)
    then
        ... complex operations...
    end // of if the person is dead

And that's what's wrong with proposals to use separate keyword for the end of 
each different kind of compound statement -- not enough info to be useful.

BTW2: I cannot remember ever, in 30 years of computing, having used a code 
editor that couldn't identify matching/mismatching brackets.

    -- chris

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

#29284

From	Arne Vajhøj <arne@vajhoej.dk>
Date	2014-07-24 19:38 -0400
Message-ID	<53d19910$0$295$14726298@news.sunsite.dk>
In reply to	#29255

On 7/23/2014 11:11 PM, Joshua Cranmer 🐧 wrote:
> On 7/23/2014 8:34 PM, Arne Vajhøj wrote:
>> On 7/22/2014 10:02 PM, Joshua Cranmer 🐧 wrote:
>>> C. On the balance, I think matching curly braces is superior to
>>> begin/end-ish constructs. If you're spending too much time trying to
>>> figure out where you have an extra or a missing curly brace, then, quite
>>> frankly, your IDE is defective. My IDE points out matching curly braces
>>> and can even fold them based on appropriate matching, and it has been
>>> able to do so since before Java was invented. Possibly since before I
>>> was born, even.
>>
>> To me having an IDE make up for something missing in the
>> language does not excuse that the feature is missing.
>>
>> An IDE is just not always present when reading code.
>>
>> (and I think the readability is more of a problem than
>> the fixing one too few or one too many problems)
>
> If you're arguing that begin/end is superior for readability... it's
> not. It's no better, and could potentially be worse.
>
> 1. If you have deep nesting, it's almost certainly going to be mostly or
> all if statements at the bottom. Loops don't nest deep in practice (you
> could make a loop nest larger than 3 a compiler error and almost all
> production code would still compile). So distinguishing between all the
> different kinds of classes of block structures buys you very little, and
> nothing at all in the worst classes.

I very often see code with nested blocks. And especially if the
indentation is not perfect it can become a challenge to understand
what matches what.

> 2. Close structures are less well-coordinated among different languages.
> Is it end, endif, end if, or fi?

True.

But I have never seen it as a problem to remember what the language I am
current using want.

> 3. When you do scans of code, you're almost certainly not looking for
> braces or begin/end-style keywords. You're looking at the indentation
> level primarily. The signal for a termination of a block, then, is a
> mostly-empty line that contains the close construct at the appropriate
> indentation level. end doesn't help you there.

Perfect indentation solves the problem. But the world is not
always perfect.

Arne

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

#29323

From	Gene Wirchenko <genew@telus.net>
Date	2014-07-25 13:30 -0700
Message-ID	<oef5t9hui93mt6khfh5pqe8h3usstrs7j7@4ax.com>
In reply to	#29284

On Thu, 24 Jul 2014 19:38:56 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:

[snip]

>But I have never seen it as a problem to remember what the language I am
>current using want.

     It does not happen often, it has happened to me.

     I had a problem in some JavaScript code.  I had accidentally used
the Visual FoxPro line comment (&&) instead of JavaScript's //.  It
took a while to find.

[snip]

Sincerely,

Gene Wirchenko

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

#29241

From	taqmcg@gmail.com
Date	2014-07-23 11:26 -0700
Message-ID	<a4b9a521-1f38-4fc0-b131-fda06e47af68@googlegroups.com>
In reply to	#29201

> You might like to add to the list.

Here are a few possibly idiosyncratic issues I have. I don't anticipate that any except the last could conceivably be implemented.

- Integer promotion of byte, short and char types: This really aggravates the problem of bytes being signed. I've had to clear sign-extensions from promoted bytes or shorts countless times. The semi-supported status of these types has lots of ramifications. The special rules for x += y; where x is a byte and y is an integer is just one.

- The vast mess that is Java IO and NIO with a myriad of classes that do almost the same thing. Streams and Readers and Channels and RandomAccessFile off on its own, and Buffers and Formatters and Charsets and Selectors and .... My suspicion is the the underlying problem here is that we've decided that I/O somehow is read out of the language itself -- it's an add-on library. Doing I/O is critical to essentially all programs but thinking that some syntax beyond method calls might be useful in making what how program does I/O clear is beyond the pale. I suspect that the desire to support printf-like calls was one of the big drivers for variable length argument lists but that's not even scratching the surface.

- Statements with side effects: This infection has been virally grafted into core genes of many C-based languages. While the ability to do

a += b;

is a tremendous boon and quite clear, the added benefit of

a += b += c;
versus
b += c;
a += b;
is lost to me. The first suggests the wrong order. The second is clear and
unambiguous.

The prime vector in this contagion are the increment and decrement operators, which I completely eschew. (I use x += 1 or x -= 1 instead). So increments, decrements and assignments should (imho) be statements, not values.

4. The switch statement. The problems with fall through have already been noted, but it also seems silly that switches are restricted to a limited set of
types. One should be able to switch on any value: String, double, Objects, enumerations .... Just use == [for primitives] or equals() [for objects] to find the appropriate case. Sometimes this is just syntactic sugar for a
nested if, but that's fine. The nested if's hide the constraints, while a switch can be much clearer. I don't see why the compiler can't easily optimize the integer and enumeration switches but leave the language more powerful and simpler (i.e., there are fewer special cases).

Just a few of my pet peeves.

Regards,
Tom McGlynn

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

#29242

From	Eric Sosman <esosman@comcast-dot-net.invalid>
Date	2014-07-23 15:14 -0400
Message-ID	<lqp1it$s1g$1@dont-email.me>
In reply to	#29241

On 7/23/2014 2:26 PM, taqmcg@gmail.com wrote:
>> You might like to add to the list.
>
> Here are a few possibly idiosyncratic issues I have.  I don't anticipate that any except the last could conceivably be implemented.
>
> - Integer promotion of byte, short and char types:  This really aggravates the problem of bytes being signed.  I've had to clear sign-extensions from promoted bytes or shorts countless times.  The semi-supported status of these types has lots of ramifications.  The special rules for x += y;  where x is a byte and y is an integer is just one.

     As with C before it, this is a concession to the underlying
hardware.  Machines capable of 8-bit arithmetic exist, but nowadays
are found in microcontrollers and the like rather than in servers,
desktops, tablets, and phones.  The architectural tendency has been
to move away from memory-to-memory arithmetic and toward a style of
load-operate-store -- and when you load a "narrow" value into a
"wide" register, you can't just leave the other bits in a state
that's neither one nor zero!

     I'll also take issue with your use of "semi-supported:" Can you
find a Java implementation anywhere, even one implementation, on
which these operations are *not* supported as described in the JLS?

> - The vast mess that is Java IO and NIO with a myriad of classes that do almost the same thing.  Streams and Readers and Channels and RandomAccessFile off on its own, and Buffers and Formatters and Charsets and Selectors and ....   My suspicion is the the underlying problem here is that we've decided that I/O somehow is read out of the language itself -- it's an add-on library.  Doing I/O is critical to essentially all programs but thinking that some syntax beyond method calls might be useful in making what how program does I/O clear is beyond the pale.  I suspect that the desire to support printf-like calls was one of the big drivers for variable length argument lists but that's not even scratching the surface.

     The class libraries testify to the fact that their designers had
not yet read "Effective Java" or gained comparable experience.  Of
course, they would have to have been unusually prescient to do so ...

> - Statements with side effects: This infection has been virally grafted into core genes of many C-based languages.  While the ability to do
>
>     a += b;
>
> is a tremendous boon and quite clear, the added benefit of
>
>     a += b += c;
> versus
>     b += c;
>     a += b;
> is lost to me.  The first suggests the wrong order.  The second is clear and
> unambiguous.

     Seems clear enough to me -- although I can't recall, off-hand, a
situation where I'd have found the construct useful.  I think it's
more of a gotcha question for a snarky Java exam than something that
would arise much in practice.

     More broadly: Java is an imperative language.  In an imperative
framework it's hard to see how one could manage without side-effects:
No assignments, no methods that modify Collections, no I/O ... I guess
a language that did none of these things could compute, in a fashion,
but I'm not sure how you could prove that it had done so.

> The prime vector in this contagion are the increment and decrement operators, which I completely eschew.  (I use x += 1 or x -= 1 instead).  So increments, decrements and assignments should (imho) be statements, not values.

     De gustibus non disputandum est.  Java syntax is pretty obese
already; anything that liposuctions even a little fat away is something
I applaud.

> 4. The switch statement.  The problems with fall through have already been noted, but it also seems silly that switches are restricted to a limited set of
> types.  One should be able to switch on any value: String, double, Objects, enumerations ....  Just use == [for primitives] or equals() [for objects] to find the appropriate case.  Sometimes this is just syntactic sugar for a
> nested if, but that's fine.  The nested if's hide the constraints, while a switch can be much clearer.  I don't see why the compiler can't easily optimize the integer and enumeration switches but leave the language more powerful and simpler (i.e., there are fewer special cases).

     IMHO Java would be a better language if `switch' were removed
altogether, fall-through or not.  But that's just MHO, which (clearly)
is not widely shared.  Meanwhile, I oppose anything that encourages
the use of the construct.

> Just a few of my pet peeves.

     Here's one I haven't seen mentioned yet: I think the precedence
of `instanceof' w.r.t. `!' is wrong:

	// What I want:
	if (! thing instanceof T)   // if it's not a "T" ...

	// What I must write instead:
	if (!(thing instanceof T))  // if it's false that it's a "T" ...

Anybody else?

-- 
esosman@comcast-dot-net.invalid

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

#29296

From	thinbluernime <thinbluernime3@gmail.com>
Date	2014-07-25 04:07 +0000
Message-ID	<lqsl6k$46e$1@speranza.aioe.org>
In reply to	#29242

On Wed, 23 Jul 2014 15:14:34 -0400, Eric Sosman wrote:

>      I'll also take issue with your use of "semi-supported:" Can you
> find a Java implementation anywhere, even one implementation, on which
> these operations are *not* supported as described in the JLS?

I interpreted that as meaning that the capability exists in the language 
to do bitwise work with bytes, but that no particular effort was made to 
facilitate this, and it was allowed to get quite warty, suggesting that 
it's "supported" at the "it's technically possible" level but not at the 
"they cared about making this non-horrible to do, or even thought much 
about it specifically" level.

>      IMHO Java would be a better language if `switch' were removed
> altogether, fall-through or not.  But that's just MHO, which (clearly)
> is not widely shared.  Meanwhile, I oppose anything that encourages the
> use of the construct.

If Java existed in a vacuum, so one could always use polymorphism instead 
of "switch", then maybe. But Java does not exist in a vacuum and at the 
edge it will often be necessary to take a finite set of numbers, strings, 
or something such as a png compression-type magic number, an enum-like 
field from a database, or similar and react to that. And that is a place 
where switch is useful and polymorphism isn't. Switch can even be used to 
turn "which value was received" to "which class to instantiate" so you 
can use polymorphism in the rest of the code.

switch (compression-ID) {
  case C_DEFLATE:
    comp = new Deflater(<get some params from file header>);
    break;
  case C_ZLIB:
    comp = new ZLib(<get some other params from file header>);
    break;
  ...
}
return decodeRest(bulkOffset, comp, yadda yadda yadda);

...

rawData = comp.decompress(myByteBuffer);

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

#29305

From	Eric Sosman <esosman@comcast-dot-net.invalid>
Date	2014-07-25 08:35 -0400
Message-ID	<lqtivg$pe5$1@dont-email.me>
In reply to	#29296

On 7/25/2014 12:07 AM, thinbluernime wrote:
> On Wed, 23 Jul 2014 15:14:34 -0400, Eric Sosman wrote:
>[...]
>>       IMHO Java would be a better language if `switch' were removed
>> altogether, fall-through or not.  But that's just MHO, which (clearly)
>> is not widely shared.  Meanwhile, I oppose anything that encourages the
>> use of the construct.
>
> If Java existed in a vacuum, so one could always use polymorphism instead
> of "switch", then maybe. But Java does not exist in a vacuum and at the
> edge it will often be necessary to take a finite set of numbers, strings,
> or something such as a png compression-type magic number, an enum-like
> field from a database, or similar and react to that. And that is a place
> where switch is useful and polymorphism isn't. Switch can even be used to
> turn "which value was received" to "which class to instantiate" so you
> can use polymorphism in the rest of the code.
> [...]

     Sure.  I use `switch' myself, now and then.  But I find that I use
it less frequently in Java than in other languages, that there's simply
less need for it.  (Also, I've more than once reconsidered a `switch'
I'd written, and jettisoned it in favor of something else.)  Sure, the
construct is occasionally useful, but it's far from crucial.  I don't
think it is fruitful to over-ornament the language to encourage the use
of a rarely-applicable construct.

     By the way, have you taken a look at the byte code generated by
`switch' on String values?  Ye flippin' gods!  It compiles into *two*
`switch' statements, one sparse and one dense, sort of like

	int _case_;
	switch (string.hashCode()) {
	case "A".hashCode():
	    if ("A".equals(string)) _case_ = 1; else _case_ = 0;
	    break;
	case "B".hashCode():
	    if ("B".equals(string)) _case_ = 2; else _case_ = 0;
	    break;
	...
	default:
	    _case_ = 0;
	    break;
	}
	switch (_case_) {
	case 1:
	    /* "A" stuff */
	case 2:
	    /* "B" stuff */
	...
	case 0:
	    /* default stuff */
	}

Something like this would be necessary if any of the cases' hashCode()s
collided *and* the cases ran different code *and* there was fall-through
involved, but absent even one of these the compiler ought to be able to
generate something less cumbersome.  Even a smarter compiler, though,
would still have to compute hashCode() on the switch'ed String unless
it decided to abandon the `switch'-style strategy altogether.

-- 
esosman@comcast-dot-net.invalid

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

#29340

From	Roedy Green <see_website@mindprod.com.invalid>
Date	2014-07-26 09:41 -0700
Message-ID	<url7t9l4pklrba8bgf5hmmt17noiqgrcdk@4ax.com>
In reply to	#29305

On Fri, 25 Jul 2014 08:35:55 -0400, Eric Sosman
<esosman@comcast-dot-net.invalid> wrote, quoted or indirectly quoted
someone who said :

>     Sure.  I use `switch' myself, now and then.  But I find that I use
>it less frequently in Java than in other languages, that there's simply
>less need for it.  

If you did not have switch, you would need some sort of transform
operator that translated a set of objects, ints, ranges, into another.


It needs to be like a clever switch to handle the transform by
indexing, hashing, binary switch as appropriate, doing work at compile
time to create perfect hashes.

The object of the translation could be a lambda expression.  That
would give you ability like the switch.

It would probably also allow you do define or modify the transform at
run time. Most would be "final" and more fully optimised.

-- 
Roedy Green Canadian Mind Products http://mindprod.com
The art of strongly-typed language design is largely arranging 
that errors are automatically detected as soon as possible
in the compose, compile, run cycle.

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

#29516

From	Wanja Gayk <brixomatic@yahoo.com>
Date	2014-08-03 16:41 +0200
Message-ID	<MPG.2e48687eccb8efb02a@202.177.16.121>
In reply to	#29296

In article <lqsl6k$46e$1@speranza.aioe.org>, thinbluernime 
(thinbluernime3@gmail.com) says...

> >      IMHO Java would be a better language if `switch' were removed
> > altogether, fall-through or not.  But that's just MHO, which (clearly)
> > is not widely shared.  Meanwhile, I oppose anything that encourages the
> > use of the construct.
> 
> If Java existed in a vacuum, so one could always use polymorphism instead 
> of "switch", then maybe.

I'd be interested in one example of a switch statement that cannot be 
expressed with if statements. 

Kind regards,
Wanja


-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

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

#29518

From	Eric Sosman <esosman@comcast-dot-net.invalid>
Date	2014-08-03 11:31 -0400
Message-ID	<lrlkkv$ft8$1@dont-email.me>
In reply to	#29516

On 8/3/2014 10:41 AM, Wanja Gayk wrote:
> In article <lqsl6k$46e$1@speranza.aioe.org>, thinbluernime
> (thinbluernime3@gmail.com) says...
>
>>>       IMHO Java would be a better language if `switch' were removed
>>> altogether, fall-through or not.  But that's just MHO, which (clearly)
>>> is not widely shared.  Meanwhile, I oppose anything that encourages the
>>> use of the construct.
>>
>> If Java existed in a vacuum, so one could always use polymorphism instead
>> of "switch", then maybe.
>
> I'd be interested in one example of a switch statement that cannot be
> expressed with if statements.

     http://www.mickeymantle.com/

     (For those unacquainted with the National Game of the United States
of Insularity: Mickey Mantle was one of baseball's greatest hitters,
renowned for both his power and for his ability to bat both right- and
left-handed, an uncommon skill called "switch hitting."  Mantle had his
flaws, to be sure, but there was nothing iffy about him.)

     :)

-- 
esosman@comcast-dot-net.invalid

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

#29256

From	Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid>
Date	2014-07-23 22:41 -0500
Message-ID	<lqpv9p$llh$1@dont-email.me>
In reply to	#29241

On 7/23/2014 1:26 PM, taqmcg@gmail.com wrote:
> - The vast mess that is Java IO and NIO with a myriad of classes that
> do almost the same thing.  Streams and Readers and Channels and
> RandomAccessFile off on its own, and Buffers and Formatters and
> Charsets and Selectors and ....   My suspicion is the the underlying
> problem here is that we've decided that I/O somehow is read out of
> the language itself -- it's an add-on library.  Doing I/O is critical
> to essentially all programs but thinking that some syntax beyond
> method calls might be useful in making what how program does I/O
> clear is beyond the pale.  I suspect that the desire to support
> printf-like calls was one of the big drivers for variable length
> argument lists but that's not even scratching the surface.

Since you mentioned I/O in particular, I'll bring this up:

I/O is *hard.* If you have any pretense of supporting non-ASCII, you 
*need* to worry about charsets and not sweep them under the rug (notice 
how many NNTP clients appear to mangle the character in my From 
header--and this is a situation where the format literally shoves the 
charset information in your face. Java's blunder was that it attempted 
to hide the details and put both text and binary handling on streams 
instead of having separate Reader/Writer implementations beyond the past.

The other problem is synchronous via asynchronous streams, or support 
for select-like constructs. This is the sort of thing that is impossible 
to retrofit onto existing libraries without potentially breaking a lot 
of applications. It's also the sort of thing for which, looking at 
several other languages and libraries, there is no universally-accepted 
paradigm. Yes, it's a mess; yes, Java did it wrong. Then again, so did 
everybody else, so I can't fault Java for that.

java.util.Date on the other hand... WHY IS JANUARY ASSIGNED A NUMERICAL 
VALUE OF 0? DO YOU NOT HAVE AN OUNCE OF GREY MATTER IN YOUR SKULL? [Yes. 
I know the rational. But when strftime's %MM value outputs 1 for 
January, it's hard to argue that January doesn't have an intrinsic 
numerical value worth more than 0-based indexing].

-- 
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

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

#29274

From	taqmcg@gmail.com
Date	2014-07-24 10:09 -0700
Message-ID	<38c5efcc-315c-4b8d-a478-89e352af7143@googlegroups.com>
In reply to	#29256

On Wednesday, July 23, 2014 11:41:25 PM UTC-4, Joshua Cranmer 🐧 wrote:
> On 7/23/2014 1:26 PM, taqmcg@... wrote:
> 
> > - The vast mess that is Java IO and NIO with a myriad of classes that
> > do almost the same thing.  Streams and Readers and Channels and
> > RandomAccessFile off on its own, and Buffers and Formatters and
> > Charsets and Selectors and ....   My suspicion is the the underlying
> > problem here is that we've decided that I/O somehow is read out of
> > the language itself -- it's an add-on library.  Doing I/O is critical
> > to essentially all programs but thinking that some syntax beyond
> > method calls might be useful in making what how program does I/O
> > clear is beyond the pale.  I suspect that the desire to support
> > printf-like calls was one of the big drivers for variable length
> > argument lists but that's not even scratching the surface.
> 
> Since you mentioned I/O in particular, I'll bring this up:
> 
> I/O is *hard.* If you have any pretense of supporting non-ASCII, you 
> *need* to worry about charsets and not sweep them under the rug (notice 
> how many NNTP clients appear to mangle the character in my From 
> header--and this is a situation where the format literally shoves the 
> charset information in your face. Java's blunder was that it attempted 
> to hide the details and put both text and binary handling on streams 
> instead of having separate Reader/Writer implementations beyond the past.
> 
> 
> The other problem is synchronous via asynchronous streams, or support 
> for select-like constructs. This is the sort of thing that is impossible 
> to retrofit onto existing libraries without potentially breaking a lot 
> of applications. It's also the sort of thing for which, looking at 
> several other languages and libraries, there is no universally-accepted 
> paradigm. Yes, it's a mess; yes, Java did it wrong. Then again, so did 
> everybody else, so I can't fault Java for that.
> 

The bit that confuses me -- and I agree that Java is not the only place this happens -- is that everyone agrees that I/O is complex and difficult. And the first decision that seems to be made about it is that given this complex, difficult but critical element that all of our programs need, lets ensure that the only syntax that is available to address it is a method/function.  Maybe some of the complexity could be addressed more cleanly if we thought about I/O as fundamental element of what we are doing through the language design process rather than something to be bolted on as library (or libraries) at the end.

To illustrate this (and I'm designing this as I write it, trying to illustrate how we could integrate I/O within the language differently that we do now). suppose that we had the idea that all variables (both primitives and objects) in Java were emitters and receivers -- a basic property for all things.  Primitives emit their byte representation and can receive bytes to get new value.  Objects have some method defined for both operations.  Arrays emit/receive their elements.

We can also build filter objects that serve as receiver/emitters.  With this kind of framework, we might consider a filter statement of the form

  emitter,emitter,... <<filter,filter,...>> receiver,receiver,... ;

Now a write statement to an output stream could be of the form:

  x,y,z <<>> outputStream;

There's no filter because we want to write out the bytes directly.  If we want the equivalent of a Writer instead of an output stream we have

  x,y,z <<encoder>> outputStream;

Or maybe we need to first transform our data into some string representation and then make sure that the string is properly encoded.

  x,y,z <<toString,encoder>> outputStream;

I'm not proposing this syntax especially, but I think it illustrates the kind of syntactical constructs that might promote a cleaner representation of the users I/O needs than some ever more complex libraries of method calls.  Maybe some special callback syntax would fit in nicely with asynchronous I/O...

> 
> java.util.Date on the other hand... WHY IS JANUARY ASSIGNED A NUMERICAL 
> VALUE OF 0? DO YOU NOT HAVE AN OUNCE OF GREY MATTER IN YOUR SKULL? [Yes. 
> I know the rational. But when strftime's %MM value outputs 1 for 
> January, it's hard to argue that January doesn't have an intrinsic 
> numerical value worth more than 0-based indexing].
> 

True enough...  But I deal with I/O in every program and the arcane aspects of Java's time system in very few.

Regards,
Tom McGlynn

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

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

csiph-web

Java blunders

Contents

#29402

#29232

#29233

#29248

#29254

#29255

#29261

#29285

#29306

#29284

#29323

#29241

#29242

#29296

#29305

#29340

#29516

#29518

#29256

#29274