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

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

Java blunders

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

#29304

taqmcg@gmail.com wrote:
> 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.

I'd like to turn this around and suggest that the problem is not that language 
designers "bolt-on" IO after the fact, but that the languages aren't expressive 
enough for that not to be a problem.  Personally I think (and it's a pretty 
widely shared view ASAICT) that it's a /good/ thing if IO is expressed as 
library code /written in/ the language rather than being hardwired into the 
language design.  However, if the language can't directly express IO in some 
transparent way, then that's an indication that the language itself is not 
expressive enough, and that -- presumably -- other libraries (including 
different approaches to IO) will also suffer from the same lack of 
expressiveness.

Java is -- of the mainstream or semi-mainstream languages I know even a little 
about -- the least expressive[*].  That may improve as more "stuff" gets hacked 
into the language design, but there's little sign of it yet.

But, OTOH...

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

If you don't already know Icon (dead as a language, AFAICT, but very much alive 
as a /design/ for a language) you might find that interesting.  In Icon all 
value-producers conceptually produce a /stream/ of values, which gives it a 
unique(-sh[**]) flavour for several not-obviously-connected problems from IO to 
search.  It's not quite the same as your proposal, but anyone who (like me) 
finds virtue in yours should find Icon interesting too.

    -- chris

[*]  Fortran and Cobol are also contenders for the title, I assume, but I don't 
know anything like enough about their modern incarnations to be sure.

[**] Not so unique for Prolog users, but Icon is a traditional imperative 
language. 

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

#29331

On 7/24/2014 12:09 PM, taqmcg@gmail.com wrote:
> 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.

You are making some presumptions here that I don't think are entirely 
true. The problem with I/O is, in part, there's no one-size-fits-all 
solution. Recursive descent parsers, for example, often really need 
blocking, "synchronous" [1] I/O to make them readable and maintainable. 
Many servers might care about zero-copy file-to-network streams, which 
requires different infrastructure. A database would rather just treat an 
entire file as a large block of memory (perhaps with detailed hints to 
kernel prefetching and page table management). Sometimes people want 
combinations of these approaches.

Library features tend to be preferred over language features because 
it's really easy to distribute libraries that have newer, "better" 
stuff. Baking things into the language requires a language update to be 
able to use them, and updating the compiler can take long times. It took 
a few years for the AP CS exam to start teaching Java 5, for example.

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

The underlying belief here is that all I/O is essentially a "stream", 
which is perhaps unsurprising considering that most I/O libraries are 
exposed in some form of stream-y like nature. Yet, as mentioned above, 
that is not sufficient to model all forms of I/O.

[1] There exists techniques to use coroutine functionality to write 
asynchronous code like synchronous code (look up MS's async/await 
proposal for C++). Most languages only have "stackless" coroutines, 
though, which make it harder to use these techniques on parsers, much 
less use them performantly.

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

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

#29390

Joshua Cranmer ?? wrote:

> You are making some presumptions here that I don't think are entirely
> true. The problem with I/O is, in part, there's no one-size-fits-all
> solution. Recursive descent parsers, for example, often really need
> blocking, "synchronous" [1] I/O to make them readable and maintainable.
> Many servers might care about zero-copy file-to-network streams, which
> requires different infrastructure. A database would rather just treat an
> entire file as a large block of memory (perhaps with detailed hints to
> kernel prefetching and page table management). Sometimes people want
> combinations of these approaches.

I think that most of the cases you mention would be handled perfectly well by 
normal method based syntax.  After all there's no reason to use the same style 
of design or notation for such completely different kinds of IO.

One exception is stream handling, which would -- IMO -- benefit from deeper 
support in the language.  But still done at library level (and hence 
"supported" by making the language more expressive), if only because there are 
at least two styles of stream handling, Push and Pull, and it's not clear which 
is "better".

The other case I can think of is where you want to "map" a file into memory in 
the style of memmap() -- but not necessarily restricting yourself to 
OS-supplied features.  In such cases it would be most natural to present the 
mapped data as if it were a large byte[] array.  Again Java lacks the 
expressivity to support that.

    -- chris 

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

#29392

On 7/28/2014 7:33 AM, Chris Uppal wrote:
> Joshua Cranmer ?? wrote:
>
>> You are making some presumptions here that I don't think are entirely
>> true. The problem with I/O is, in part, there's no one-size-fits-all
>> solution. Recursive descent parsers, for example, often really need
>> blocking, "synchronous" [1] I/O to make them readable and maintainable.
>> Many servers might care about zero-copy file-to-network streams, which
>> requires different infrastructure. A database would rather just treat an
>> entire file as a large block of memory (perhaps with detailed hints to
>> kernel prefetching and page table management). Sometimes people want
>> combinations of these approaches.
>
> I think that most of the cases you mention would be handled perfectly well by
> normal method based syntax.  After all there's no reason to use the same style
> of design or notation for such completely different kinds of IO.

I don't disagree. There's room for disagreement on how to design or 
notate I/O, but it seems fairly clear that it's nothing that the 
extremely versatile way of method notation can't handle. The GP's 
proposal to bake it into the syntax does generally imply a more 
one-true-way discipline, though, which is what I was objecting to.

> The other case I can think of is where you want to "map" a file into memory in
> the style of memmap() -- but not necessarily restricting yourself to
> OS-supplied features.  In such cases it would be most natural to present the
> mapped data as if it were a large byte[] array.  Again Java lacks the
> expressivity to support that.

<http://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileChannel.html#map(java.nio.channels.FileChannel.MapMode,%20long,%20long)> 
might care to disagree.

If I may tie this in with the other ongoing discussion on operator 
overloading, ByteBuffer sounds like one of those cases where overloading 
operator[] might make sense. :-)

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

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

#29341

On Thu, 24 Jul 2014 10:09:45 -0700 (PDT), taqmcg@gmail.com wrote,
quoted or indirectly quoted someone who said :

>ntegrate I/O within the language 
I remember looking for the I/O in Algol and discovered there was none
defined. I was horrified. How could programs be exchanged?

The advantage of keeping it as a library is you can ignore it and
start over without breaking old code.
-- 
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]

#29358

On Sat, 26 Jul 2014 09:44:05 -0700, Roedy Green wrote:

> On Thu, 24 Jul 2014 10:09:45 -0700 (PDT), taqmcg@gmail.com wrote, quoted
> or indirectly quoted someone who said :
> 
>>ntegrate I/O within the language
> I remember looking for the I/O in Algol and discovered there was none
> defined. I was horrified. How could programs be exchanged?
>
That was the worst feature of Algol 60 and IIIRC the language definition 
was criticised for that. The variety I was most familiar with extended 
the language by adding  'input' and 'print' reserved words but most 
implementations just added a set of library procedures. In doing this 
this they were about 10 years ahead of C, though unlike the C standard 
library, there was little or no commonality between the i/o libraries 
supported by the various Algol 60 dialects.

This was where Algol 68 scored bonus points: it had a standard library 
defined as part of the language specification. Its usually referred to as 
the 'standard prelude' rather than as a library.

> The advantage of keeping it as a library is you can ignore it and start
> over without breaking old code. 
> 
True, but portability requires that the library APIs are standardised, at 
least at the source code level. IOW, you can change the implementation, 
but not the call interface, error codes or externally visible behaviour.


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

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

#29257

On Tue, 22 Jul 2014 11:41:24 -0700, Roedy Green
<see_website@mindprod.com.invalid> 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

     I would like:

  1) unsigned integer types.  I once spent a bunch of time debugging
code to convert a.b.c.d to a 32-bit integer for a network program
because of this lack.

  2) a switch that allows for arbitrary expressions.

  3) a well-performing String type.  String has + and += which suit
what I like to do, but Strings have a performance penalty.

  4) less reptition.  This is horridly verbose when the typename is
long:
          SomeType a=new SomeType();

  5) == for string values that compare string values.  a.equals(b) is
silly.

Sincerely,

Gene Wirchenko

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

#29267

On 07/24/2014 05:48 AM, Gene Wirchenko wrote:
> On Tue, 22 Jul 2014 11:41:24 -0700, Roedy Green
> <see_website@mindprod.com.invalid> 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
>
>       I would like:
>
>    1) unsigned integer types.  I once spent a bunch of time debugging
> code to convert a.b.c.d to a 32-bit integer for a network program
> because of this lack.
>
>    2) a switch that allows for arbitrary expressions.
>
>    3) a well-performing String type.  String has + and += which suit
> what I like to do, but Strings have a performance penalty.
>
>    4) less reptition.  This is horridly verbose when the typename is
> long:
>            SomeType a=new SomeType();
>
>    5) == for string values that compare string values.  a.equals(b) is
> silly.
>
> Sincerely,
>
> Gene Wirchenko
>

1, 4 and 5 makes me suspect you are a Scala enthousiast.

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

#29272

On 07/24/2014 11:56 AM, Silvio wrote:
> On 07/24/2014 05:48 AM, Gene Wirchenko wrote:
>> On Tue, 22 Jul 2014 11:41:24 -0700, Roedy Green
>> <see_website@mindprod.com.invalid> 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
>>
>>       I would like:
>>
>>    1) unsigned integer types.  I once spent a bunch of time debugging
>> code to convert a.b.c.d to a 32-bit integer for a network program
>> because of this lack.
>>
>>    2) a switch that allows for arbitrary expressions.
>>
>>    3) a well-performing String type.  String has + and += which suit
>> what I like to do, but Strings have a performance penalty.
>>
>>    4) less reptition.  This is horridly verbose when the typename is
>> long:
>>            SomeType a=new SomeType();
>>
>>    5) == for string values that compare string values.  a.equals(b) is
>> silly.
>>
>> Sincerely,
>>
>> Gene Wirchenko
>>
>
> 1, 4 and 5 makes me suspect you are a Scala enthousiast.
>

Sorry, make that 2, 4 and 5.

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

#29324

On Thu, 24 Jul 2014 16:07:27 +0200, Silvio <silvio@internet.com>
wrote:

>On 07/24/2014 11:56 AM, Silvio wrote:
>> On 07/24/2014 05:48 AM, Gene Wirchenko wrote:

[snip]

>>>       I would like:

[snip]

>>>    2) a switch that allows for arbitrary expressions.

[snip]

>>>    4) less reptition.  This is horridly verbose when the typename is
>>> long:
>>>            SomeType a=new SomeType();
>>>
>>>    5) == for string values that compare string values.  a.equals(b) is
>>> silly.

>> 1, 4 and 5 makes me suspect you are a Scala enthousiast.

     No.  I tried it once briefly, but no.

>Sorry, make that 2, 4 and 5.

     2: A switch with expression values is very useful when one has
ranges of values or when the expression is complex.  I have one
program that has a giant switch handling the cases with the
combinations of three types of values.

     4: It really does not add much to repeat a typename.

     5: I have a sense of a mathematical aesthetics.

Sincerely,

Gene Wirchenko

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

#29342

On Fri, 25 Jul 2014 13:38:20 -0700, Gene Wirchenko <genew@telus.net>
wrote, quoted or indirectly quoted someone who said :

>     2: A switch with expression values is very useful when one has
>ranges of values or when the expression is complex.  I have one
>program that has a giant switch handling the cases with the
>combinations of three types of values.

I wrote my switch for Abundance in less than a day.
It had ranges, boolean expressions, matches, multiple cases for the
same action...

It feels so hobbling to have to live without that in Java,
particularly ranges, and being able to do a list of "startsWith"
expressions.

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

#29280

On 7/23/2014 11:48 PM, Gene Wirchenko wrote:
>       I would like:

>    2) a switch that allows for arbitrary expressions.

String?

I can not see float/double used.

>    3) a well-performing String type.  String has + and += which suit
> what I like to do, but Strings have a performance penalty.

Given Strings immutability then I am not sure much can be done.

And making String mutable could create other problems.

>    5) == for string values that compare string values.  a.equals(b) is
> silly.

But then Strong would no longer be an Object or?

Arne

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

#29325

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

>On 7/23/2014 11:48 PM, Gene Wirchenko wrote:
>>       I would like:
>
>>    2) a switch that allows for arbitrary expressions.
>
>String?
>
>I can not see float/double used.

     Not type of expression, but expression.   HEre is an example in
Visual FoxPro:

***** Start of Code *****
      * The use cstn... line is the first use of an index in CBS2
startup.
      * If the index does not exist, assume that all indexes should be
      * created.  This will happen when a dataset is sent to GW.
      local saveerrh
      saveerrh=on("error")
      setupapperrh()
      use cstn alias (this.thiscode+"_cstn") order tag cstnc again
shared
      on error &saveerrh
      do case
      case inlist(syserrno,1707,12)
         * 1707: Structural .CDX is not found.
         *   12: Variable is not found.
         * Error 12 happens if the tag does not exist.
         datasetutil("I")
         use cstn alias (this.thiscode+"_cstn") order tag cstnc again
shared
         && (If there was an error, this table will not have been
opened.)
      case syserrno#0
         error syserrno     && Rethrow any other error.
      otherwise
         * No error: do nothing.
         endcase
***** End of Code *****

     Note that the cases are not for just one value.

>>    3) a well-performing String type.  String has + and += which suit
>> what I like to do, but Strings have a performance penalty.
>
>Given Strings immutability then I am not sure much can be done.
>
>And making String mutable could create other problems.

     Well, a mutable-string type that did allow that nicer (IMO)
syntax would be, well, nice.  When I converted some String-using code
to StringBuilder, I had a bunch of syntax to adjust; I would have
preferred only having had to change the type declarations.

>>    5) == for string values that compare string values.  a.equals(b) is
>> silly.
>
>But then Strong would no longer be an Object or?

     ???

     Oh, you meant String.

     No, I would like some clearer syntax.  I see no reason why not to
have both.

Sincerely,

Gene Wirchenko

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

#29345

On Wed, 23 Jul 2014 20:48:25 -0700, Gene Wirchenko <genew@telus.net>
wrote, quoted or indirectly quoted someone who said :

>  3) a well-performing String type.  String has + and += which suit
>what I like to do, but Strings have a performance penalty.


I have three ideas to improve the efficiency of the way String is
implemented:

When a String is created the JVM copies a char[] into a new char[]
attached to the String. It does not simply put a reference to the
char[] into the String because it is worried somebody might
subsequently change the contents of the char[], thus violating the
immutability contract of String. However, almost never does anyone
change a char[] after feeding it to new String. I think the JVM could
take advantage of that. If it knew for sure no one would change it, it
could safely and rapidly just insert a reference. If it was not sure,
it might just insert the reference anyway and put a lock on it, so
that if anyone ever did try to change it, they would be blocked, the
char[] could be copied, and the write completed to the old char[] and
the String could attach itself to the new copy of the char[].

Interned Strings are dangerous. Both interned and non-Interned Strings
have the same type — namely String. You must manually manage the
intern method to control precisely when the interning is done.  You
must use either == or equals.  If you get it wrong, there are no error
messages, just puzzling results. So I suggest using an Interned
separate type for interned Strings.  You would use == both for
interned and non-interned String compare. They are automatically
interned as appropriate (managed in much the way hashCode is).

There are two kinds of String:
sequential: Strings you either treat as an atomic whole, treat char by
char starting from the beginning.
random: Strings you operate on randomly with charAt or substring.
I suggest sequential Strings be stored internally in UTF-8 to conserve
RAM. I suggest random Strings be stored in 32-bit UTF-32 code points
for ease of processing. The compiler would have to guess which type a
given String should be. It might have to change its mind and convert
the String part way through run time. It might even store some Strings
in both forms. The readers and writers when using UTF-8 should be able
to take advantage of the fact no translation is necessary. You could
have two separate types for sequential  (UString) and random (String)
in the Java language, but would be to onerous for programmers.
-- 
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]

#29279

In article <jvbts91r2f9onj1e3dbr5lvqp70hmofkum@4ax.com>, Roedy Green 
(see_website@mindprod.com.invalid) says...
> 
> 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

None of that has mentioned the biggest blunder in my opinion:

Ihe introduction of "final" instead of "var". It should be exactly the 
other way round, as the majority of declarations can be made "final" 
anywy (note that I'm not talking about methods and classes): All 
declared references and values should be "final" by default, only if you 
declare them as "var" should the compiler allow to change them.

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]

#29308

Roedy Green wrote:

> I have composed an essay about what I consider were the blunders in
> the design of Java.

Oh well, I may as well have a go too...

- The problems caused by the lack of unsigned integer types.

- The Hell of broken Unicode "support".

- The mess created by hacking in Generics.

- The unreadability caused by the absence of any kind of support for embedded 
DSLs (even limited operator overloading would help).

- <nowAddressed>The verbosity caused by the lack of something like 
closures.</nowAddressed>

- The endless problem of an inside-out security architecture (based on 
forbidding rather than on permitting).

- Using machine integers /by default/ instead of unbounded ints (several 
languages have shown that this is perfectly viable from a time/space 
perspective).

The above list is in no particular order, and is anyway incomplete.  But 
head-and-shoulders above the rest, the winner is...

- new()

    -- chris

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

#29315

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.

> see http://mindprod.com/jgloss/javablunders.html

I meant to point this out for you the other day but forgot: Lombok has the
'val' type which will infer type information:

<http://projectlombok.org/features/val.html>

val example = new ArrayList<String>();
example.add("Hello, World!");
val foo = example.get(0);

...

for (val entry : map.entrySet()) {...

Fulfilling two of your requests.

Liebe Gruesse,
		Joerg

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

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

#29357

On Tue, 22 Jul 2014 11:41:24 -0700, Roedy Green
<see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :

> You might like to add to the list.

I have formatted and posted some of your ideas at
http://mindprod.com/jgloss/javablunders.html

If want to add/edit/remove, please let me know.
-- 
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]

#29414

On 07/22/2014 08: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

OK that's an interesting topic, thanks!:)
Let me add a few:

1) Multiple inheritance

Diamond problem, uh, it's hard, it's sooo haaaaard... let's skip it.
But you can extend two java classes in jython, and use new class in 
java. Problem solved.
And we have multiple inheritance in JavaFX, right?
So, why not in java SE?
That's feature critically lacking in java. But we are so used to live 
lacking it, we don't ever remember to mention it.

Note that ability to implement multiple interfaces has nothing to do 
with inheritance, it's multiple conformance.

2) Meta classes

Just a few times in quite a few years, most elegant design was parent 
class methods changing behaviour depending on subclass static variables.
Now, you can override them, but parent class method cannot access them!
There is no 'this' for class.
Obvious workaround is to use non-static member variables, thus wasting 
memory.
Better workaround is to use reflection to fetch subclass static 
variable/annotation value - reflection doesn't require 'this'.
Or, use Visitor, or... anyway, I ended with abstract method in 
superclass, and a lot of stupid copy&paste in all subclasses.
Well, it's ugly and stupid.

OK that's just one example, but one of many.
Better languages have meta classes to solve issues like this.

3) Beans, beans everywhere!

Using setters/getters for database access leads to retarded data models.
They don't do anything but accessing a private variable value.
Much the same with data transfer objects and many other applications of 
beans, but to lesser extent.
Only technical reason for this nonsense is Proxy, which is not available 
for variables, for public method call can be intercepted, and public 
variable access can not.
Err... waitaminit.
I always have a database access abstraction layer anyway.
That layer knows when anything is accessed, and has no need to intercept 
anything.
It only needs the ability to materialize a member variable.
So, what do we do?
But of course, we introduce JAXP, so we can generate java beans from 
XML. Then we break down JAXP compatibility with previous versions.
Or we introduce some other XMLization methods to generate data model and 
code.
Just awesome.

4) Error handling

Can I have central error handler please?
To get rid of division by zero once and for all.
(In addition to try/catch of course)

5) Resource bundles

... NPE, NPE, NPE.
BAD BAD BAD!
Only if it was checked exception.

Regards...

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

#29418

On 07/29/2014 12:12 AM, Stefan Ram wrote:
> Josip Almasi <joe@vrspace.org> writes:
>> 1) Multiple inheritance
> ...
>> That's feature critically lacking in java.
>
> interface Hello { default void hello()
>    { java.lang.System.out.print( "hello, " ); }}
>
> interface World { default void world()
>    { java.lang.System.out.println( "world" ); }}
>
> public class Main implements Hello, World
> { public static void main( final java.lang.String args[] )
>    { final Main main = new Main(); main.hello(); main.world(); }}

Ah that's interesting improvement, thanks!
Sure it will save us a lot of copy&paste... finally.

So I can access 'this' and members in default implementations, right?
I mean examples I see are all static implementations.

Regards...

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

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

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

csiph-web