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

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

refactoring problem

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

Contents

  refactoring problem Roedy Green <see_website@mindprod.com.invalid> - 2013-02-03 06:30 -0800
    Re: refactoring problem Martin Gregorie <martin@address-in-sig.invalid> - 2013-02-03 16:23 +0000
    Re: refactoring problem Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-02-03 12:27 -0400
      Re: refactoring problem Roedy Green <see_website@mindprod.com.invalid> - 2013-02-03 12:35 -0800
        Re: refactoring problem Arne Vajhøj <arne@vajhoej.dk> - 2013-02-03 15:37 -0500
      Re: refactoring problem Leif Roar Moldskred <leifm@dimnakorr.com> - 2013-02-03 15:21 -0600
        Re: refactoring problem Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-02-03 17:38 -0400
        Re: refactoring problem Arne Vajhøj <arne@vajhoej.dk> - 2013-02-03 16:46 -0500
      Re: refactoring problem Lew <lewbloch@gmail.com> - 2013-02-03 14:36 -0800
    Re: refactoring problem Arne Vajhøj <arne@vajhoej.dk> - 2013-02-03 11:34 -0500
    Re: refactoring problem Joshua Cranmer <Pidgeot18@verizon.invalid> - 2013-02-03 11:54 -0600
      Re: refactoring problem Arne Vajhøj <arne@vajhoej.dk> - 2013-02-03 13:13 -0500
        Re: refactoring problem Knute Johnson <nospam@knutejohnson.com> - 2013-02-03 10:20 -0800
          Re: refactoring problem Arne Vajhøj <arne@vajhoej.dk> - 2013-02-03 13:32 -0500
            Re: refactoring problem Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-02-03 10:50 -0800
              Re: refactoring problem Robert Klemme <shortcutter@googlemail.com> - 2013-02-03 21:38 +0100
              Re: refactoring problem "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-02-04 08:11 +0000
                Re: refactoring problem Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-02-04 03:56 -0800
        Re: refactoring problem Silvio <silvio@internet.com> - 2013-02-04 13:21 +0100
          Re: refactoring problem Lew <lewbloch@gmail.com> - 2013-02-04 12:35 -0800
            Re: refactoring problem Silvio <silvio@internet.com> - 2013-02-04 22:15 +0100
              Re: refactoring problem Lew <lewbloch@gmail.com> - 2013-02-04 13:49 -0800
                Re: refactoring problem Silvio <silvio@internet.com> - 2013-02-04 23:51 +0100
              Re: refactoring problem Lew <lewbloch@gmail.com> - 2013-02-04 13:53 -0800
                Re: refactoring problem Silvio <silvio@internet.com> - 2013-02-04 23:48 +0100
                  Re: refactoring problem Lew <lewbloch@gmail.com> - 2013-02-04 17:08 -0800
                    Re: refactoring problem Silvio <silvio@internet.com> - 2013-02-05 10:07 +0100
                      Re: refactoring problem Lew <lewbloch@gmail.com> - 2013-02-05 13:13 -0800
                        Re: refactoring problem Jim Gibson <jimsgibson@gmail.com> - 2013-02-05 13:20 -0800
                          Re: refactoring problem Lew <lewbloch@gmail.com> - 2013-02-05 13:31 -0800
                            Re: refactoring problem Arne Vajhøj <arne@vajhoej.dk> - 2013-02-05 21:42 -0500
              Re: refactoring problem Arne Vajhøj <arne@vajhoej.dk> - 2013-02-04 18:33 -0500
            Re: refactoring problem Arne Vajhøj <arne@vajhoej.dk> - 2013-02-04 18:32 -0500
              Re: refactoring problem Martin Gregorie <martin@address-in-sig.invalid> - 2013-02-05 01:50 +0000
            Re: refactoring problem Joshua Cranmer <Pidgeot18@verizon.invalid> - 2013-02-05 10:04 -0600
              Re: refactoring problem Gene Wirchenko <genew@telus.net> - 2013-02-05 10:38 -0800
                Re: refactoring problem Joshua Cranmer <Pidgeot18@verizon.invalid> - 2013-02-05 13:53 -0600
              Re: refactoring problem Arne Vajhøj <arne@vajhoej.dk> - 2013-02-05 21:43 -0500
                Re: refactoring problem markspace <markspace@nospam.nospam> - 2013-02-05 19:15 -0800
                  Re: refactoring problem Arne Vajhøj <arne@vajhoej.dk> - 2013-02-08 23:58 -0500
    Re: refactoring problem Joerg Meier <joergmmeier@arcor.de> - 2013-02-05 11:09 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#22084

On 02/04/2013 09:35 PM, Lew wrote:
> Silvio wrote:
>> parameters. Nothing very dramatic that could not be added to the Java
>> compiler if so desired.
>
> People are never satisfied. They wanted delegates, didn't get them, never mind Java got another
> way to do the same thing. Then they wanted generics, and sorta got them. Then they wanted
> runtime generics and didn't get them, never mind Java already had another way to do the same thing.
> Then they wanted closures, and sorta got them, never mind Java already had another way to do the
> same thing. Now they want tuples, never mind that Java already has another way to do the same thing.
>
> "Oh, it's just one more little thing!" they always exclaim. For a thousand little things.
>
> This is what happened to C++.
>
> Java will get all these things and the programming community will abandon the language,
> bitching that it's gotten too "heavy".
>
> The argument "it's just one little change" is a well-known lie. It's how customers eat up the
> profit margin for custom software. One thing and another and another and another and another
> and the game is how long you can say, "I'm only just going to take Poland, nothing else" before
> people realize I just incurred Godwin's Law.
>

I am not arguing things SHOULD be added to Java, just pointing out that 
they COULD be added. In fact, I have expressed multiple times that I 
think Java should be left alone (and should have been for quite some time).

Java used to be a reasonably orthogonal minimalistic language. That made 
sense to me, just like languages like C++ or Scala which are 
feature-rich make sense to me.
Features that have been added to Java in more recent versions are all 
over the place. Now it is a somewhat minimalistic language with a random 
and incoherent set of not so minimalistic features.

But as always, tastes will differ.

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

#22085

On Monday, February 4, 2013 1:15:55 PM UTC-8, Silvio wrote:
> ... 

Please do not cc: your posts to my email address.

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

#22092

On 02/04/2013 10:49 PM, Lew wrote:
> On Monday, February 4, 2013 1:15:55 PM UTC-8, Silvio wrote:
>> ...
>
> Please do not cc: your posts to my email address.
>

Actually it was not a CC. Thunderbird has renamed the "Reply to group" 
button to "Follow up". Since then I mistakenly keep using the "Reply" 
button instead and then use the other one as soon as I realize my 
mistake. Sorry about that.

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

#22086

Silvio wrote:
> Lew wrote:
>> Silvio wrote:
>>> parameters. Nothing very dramatic that could not be added to the Java
>>> compiler if so desired.
> 
>> People are never satisfied. They wanted delegates, didn't get them, never mind Java got another
>> way to do the same thing. Then they wanted generics, and sorta got them. Then they wanted
>> runtime generics and didn't get them, never mind Java already had another way to do the same thing.
>> Then they wanted closures, and sorta got them, never mind Java already had another way to do the
>> same thing. Now they want tuples, never mind that Java already has another way to do the same thing.
>>
>> "Oh, it's just one more little thing!" they always exclaim. For a thousand little things.
>>
>> This is what happened to C++.
>>
>> Java will get all these things and the programming community will abandon the language,
>> bitching that it's gotten too "heavy".
>>
>> The argument "it's just one little change" is a well-known lie. It's how customers eat up the
>> profit margin for custom software. One thing and another and another and another and another
>> and the game is how long you can say, "I'm only just going to take Poland, nothing else" before
>> people realize I just incurred Godwin's Law.
> 
> I am not arguing things SHOULD be added to Java, just pointing out that 
> they COULD be added.

That was perfectly clear, and the context to which I spoke.

Unless you are also pitching that maybe it SHOULD be part of Java, stating that it 
COULD be added to Java is a noop. Anything COULD be added to Java. I'm in favor of an 
ENVIRONMENT section myself. 

Simply stating that something COULD be added to Java is pretty much an empty statement.

> In fact, I have expressed multiple times that I 
> think Java should be left alone (and should have been for quite some time).

And yet you suggest another feature anyway.

> Java used to be a reasonably orthogonal minimalistic language. That made 
> sense to me, just like languages like C++ or Scala which are 
> feature-rich make sense to me.
> 
> Features that have been added to Java in more recent versions are all 
> over the place. Now it is a somewhat minimalistic language with a random 
> and incoherent set of not so minimalistic features.
>  
> But as always, tastes will differ.

Well, the decisions as to what actually makes it into Java or not are not made on the basis 
of taste.

Which is arguably the worst of seemingly plausible criteria for inclusion.

-- 
Lew

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

#22091

On 02/04/2013 10:53 PM, Lew wrote:
> Silvio wrote:
>> Lew wrote:
>>> Silvio wrote:
>>>> parameters. Nothing very dramatic that could not be added to the Java
>>>> compiler if so desired.
>>
>>> People are never satisfied. They wanted delegates, didn't get them, never mind Java got another
>>> way to do the same thing. Then they wanted generics, and sorta got them. Then they wanted
>>> runtime generics and didn't get them, never mind Java already had another way to do the same thing.
>>> Then they wanted closures, and sorta got them, never mind Java already had another way to do the
>>> same thing. Now they want tuples, never mind that Java already has another way to do the same thing.
>>>
>>> "Oh, it's just one more little thing!" they always exclaim. For a thousand little things.
>>>
>>> This is what happened to C++.
>>>
>>> Java will get all these things and the programming community will abandon the language,
>>> bitching that it's gotten too "heavy".
>>>
>>> The argument "it's just one little change" is a well-known lie. It's how customers eat up the
>>> profit margin for custom software. One thing and another and another and another and another
>>> and the game is how long you can say, "I'm only just going to take Poland, nothing else" before
>>> people realize I just incurred Godwin's Law.
>>
>> I am not arguing things SHOULD be added to Java, just pointing out that
>> they COULD be added.
>
> That was perfectly clear, and the context to which I spoke.
>
> Unless you are also pitching that maybe it SHOULD be part of Java, stating that it
> COULD be added to Java is a noop. Anything COULD be added to Java. I'm in favor of an
> ENVIRONMENT section myself.
>
> Simply stating that something COULD be added to Java is pretty much an empty statement.
>
>> In fact, I have expressed multiple times that I
>> think Java should be left alone (and should have been for quite some time).
>
> And yet you suggest another feature anyway.
>
>> Java used to be a reasonably orthogonal minimalistic language. That made
>> sense to me, just like languages like C++ or Scala which are
>> feature-rich make sense to me.
>>
>> Features that have been added to Java in more recent versions are all
>> over the place. Now it is a somewhat minimalistic language with a random
>> and incoherent set of not so minimalistic features.
>>
>> But as always, tastes will differ.
>
> Well, the decisions as to what actually makes it into Java or not are not made on the basis
> of taste.
>
> Which is arguably the worst of seemingly plausible criteria for inclusion.
>

Well, what where those decisions based on then? Something else than the 
personal taste of a small group of influential insiders?

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

#22100

Silvio wrote:
>Lew wrote:
>> Silvio wrote:
>>> But as always, tastes will differ.
>> Well, the decisions as to what actually makes it into Java or not are not made on the basis
>> of taste.
>>
>> Which is arguably the worst of seemingly plausible criteria for inclusion.
> 
> Well, what where those decisions based on then? 

Engineering considerations. Logic. Estimated utility. Cost of implementation vs. expected benefit.

> Something else than the personal taste of a small group of influential insiders?

Yep.

-- 
Lew

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

#22109

On 02/05/2013 02:08 AM, Lew wrote:
> Silvio wrote:
>> Lew wrote:
>>> Silvio wrote:
>>>> But as always, tastes will differ.
>>> Well, the decisions as to what actually makes it into Java or not are not made on the basis
>>> of taste.
>>>
>>> Which is arguably the worst of seemingly plausible criteria for inclusion.
>>
>> Well, what where those decisions based on then?
>
> Engineering considerations. Logic. Estimated utility. Cost of implementation vs. expected benefit.
>
>> Something else than the personal taste of a small group of influential insiders?
>
> Yep.
>

Well, no. I closely followed a number of the discussions about language 
additions (among which the endless series of discussions about closures) 
and personal preference of a small group of people is definitely a major 
factor.

Of course their preferences will have been influenced by such factors 
but since these are either subjective or estimates personal opinions 
remain important.

I am not saying this is bad per se. That was your opinion.

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

#22127

Silvio wrote:
> Lew wrote:
>> Silvio wrote:
>>> Lew wrote:
>>>> Silvio wrote:
>>>>> But as always, tastes will differ.
> 
>>>> Well, the decisions as to what actually makes it into Java or not are not made on the basis
>>>> of taste.
>>>>
>>>> Which is arguably the worst of seemingly plausible criteria for inclusion.
> 
>>> Well, what where those decisions based on then?
> 
>> Engineering considerations. Logic. Estimated utility. Cost of implementation vs. expected benefit.
> 
>>> Something else than the personal taste of a small group of influential insiders?
> 
>> Yep.
> 
> Well, no. I closely followed a number of the discussions about language 
> additions (among which the endless series of discussions about closures) 
> and personal preference of a small group of people is definitely a major 
> factor.

"Preference" != "taste".

> Of course their preferences will have been influenced by such factors 
> but since these are either subjective or estimates personal opinions 
> remain important.

"Opinion" != "taste".

> I am not saying this is bad per se. That was your opinion.

You have not shown that their influence or thoughts were influenced by taste.

What I've read of those discussions were all motivated by engineering considerations.

I did not detect anything of taste in the justifications.

-- 
Lew

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

#22128

In article <e80ad67a-75d7-4794-ab76-b1004a983d1b@googlegroups.com>, Lew
<lewbloch@gmail.com> wrote:

> Silvio wrote:
> > Lew wrote:
> >> Silvio wrote:
> >>> Lew wrote:
> >>>> Silvio wrote:
> >>>>> But as always, tastes will differ.
> > 
> >>>> Well, the decisions as to what actually makes it into Java or not are
> >>>> not made on the basis
> >>>> of taste.
> >>>>
> >>>> Which is arguably the worst of seemingly plausible criteria for
> >>>> inclusion.
> > 
> >>> Well, what where those decisions based on then?
> > 
> >> Engineering considerations. Logic. Estimated utility. Cost of
> >> implementation vs. expected benefit.
> > 
> >>> Something else than the personal taste of a small group of influential
> >>> insiders?
> > 
> >> Yep.
> > 
> > Well, no. I closely followed a number of the discussions about language 
> > additions (among which the endless series of discussions about closures) 
> > and personal preference of a small group of people is definitely a major 
> > factor.
> 
> "Preference" != "taste".

You are splitting hairs. 

From my online dictionary (copyright, Apple, Inc.):

taste:
"a person's tendency to like and dislike certain things"

preference:
"a greater liking for one alternative over another or others"


> > Of course their preferences will have been influenced by such factors 
> > but since these are either subjective or estimates personal opinions 
> > remain important.
> 
> "Opinion" != "taste".

I'll give you that one :)

opinion:
"a view or judgment formed about something, not necessarily based on
fact or knowledge"

-- 
Jim Gibson

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

#22129

Jim Gibson wrote:
>  Lew wrote:
>> "Preference" != "taste".
> 
> You are splitting hairs. 

Not at all.

> From my online dictionary (copyright, Apple, Inc.):
> taste:
> "a person's tendency to like and dislike certain things"
> 
> preference:
> "a greater liking for one alternative over another or others"

I meant "preference" in the sense of "showing a greater cost-benefit ratio on the basis 
of evidence than other alternatives", not "touchy-feely random psychological bias".

You're the one splitting hairs. My point is that it isn't a matter of esthetics, as "taste" 
is usually understood to denote, but of rational assessment of alternatives, a point you 
choose to overlook in your determination to be a troll.

-- 
Lew

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

#22151

On 2/5/2013 4:31 PM, Lew wrote:
> Jim Gibson wrote:
>>   Lew wrote:
>>> "Preference" != "taste".
>>
>> You are splitting hairs.
>
> Not at all.
>
>>  From my online dictionary (copyright, Apple, Inc.):
>> taste:
>> "a person's tendency to like and dislike certain things"
>>
>> preference:
>> "a greater liking for one alternative over another or others"
>
> I meant "preference" in the sense of "showing a greater cost-benefit ratio on the basis
> of evidence than other alternatives", not "touchy-feely random psychological bias".

I don't think I have ever seen a cost-benefit analysis for
a suggested change to the Java language.

Do you have a link to one?

Arne

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

#22097

On 2/4/2013 4:15 PM, Silvio wrote:
> On 02/04/2013 09:35 PM, Lew wrote:
>> Silvio wrote:
>>> parameters. Nothing very dramatic that could not be added to the Java
>>> compiler if so desired.
>>
>> People are never satisfied. They wanted delegates, didn't get them,
>> never mind Java got another
>> way to do the same thing. Then they wanted generics, and sorta got
>> them. Then they wanted
>> runtime generics and didn't get them, never mind Java already had
>> another way to do the same thing.
>> Then they wanted closures, and sorta got them, never mind Java already
>> had another way to do the
>> same thing. Now they want tuples, never mind that Java already has
>> another way to do the same thing.
>>
>> "Oh, it's just one more little thing!" they always exclaim. For a
>> thousand little things.
>>
>> This is what happened to C++.
>>
>> Java will get all these things and the programming community will
>> abandon the language,
>> bitching that it's gotten too "heavy".
>>
>> The argument "it's just one little change" is a well-known lie. It's
>> how customers eat up the
>> profit margin for custom software. One thing and another and another
>> and another and another
>> and the game is how long you can say, "I'm only just going to take
>> Poland, nothing else" before
>> people realize I just incurred Godwin's Law.
>>
>
> I am not arguing things SHOULD be added to Java, just pointing out that
> they COULD be added. In fact, I have expressed multiple times that I
> think Java should be left alone (and should have been for quite some time).
>
> Java used to be a reasonably orthogonal minimalistic language. That made
> sense to me, just like languages like C++ or Scala which are
> feature-rich make sense to me.
> Features that have been added to Java in more recent versions are all
> over the place. Now it is a somewhat minimalistic language with a random
> and incoherent set of not so minimalistic features.

Language development is sometimes more politics than science.

Arne

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

#22096

On 2/4/2013 3:35 PM, Lew wrote:
> Silvio wrote:
>> parameters. Nothing very dramatic that could not be added to the Java
>> compiler if so desired.
>
> People are never satisfied. They wanted delegates, didn't get them, never mind Java got another
> way to do the same thing. Then they wanted generics, and sorta got them. Then they wanted
> runtime generics and didn't get them, never mind Java already had another way to do the same thing.
> Then they wanted closures, and sorta got them, never mind Java already had another way to do the
> same thing. Now they want tuples, never mind that Java already has another way to do the same thing.
>
> "Oh, it's just one more little thing!" they always exclaim. For a thousand little things.
>
> This is what happened to C++.
>
> Java will get all these things and the programming community will abandon the language,
> bitching that it's gotten too "heavy".

I agree.

Even though I think that PL/I and Ada95 may be better examples than C++.

Arne

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

#22101

On Mon, 04 Feb 2013 18:32:28 -0500, Arne Vajhøj wrote:

> On 2/4/2013 3:35 PM, Lew wrote:
>> Silvio wrote:
>>> parameters. Nothing very dramatic that could not be added to the Java
>>> compiler if so desired.
>>
>> People are never satisfied. They wanted delegates, didn't get them,
>> never mind Java got another way to do the same thing. Then they wanted
>> generics, and sorta got them. Then they wanted runtime generics and
>> didn't get them, never mind Java already had another way to do the same
>> thing. Then they wanted closures, and sorta got them, never mind Java
>> already had another way to do the same thing. Now they want tuples,
>> never mind that Java already has another way to do the same thing.
>>
>> "Oh, it's just one more little thing!" they always exclaim. For a
>> thousand little things.
>>
>> This is what happened to C++.
>>
>> Java will get all these things and the programming community will
>> abandon the language,
>> bitching that it's gotten too "heavy".
> 
> I agree.
> 
> Even though I think that PL/I and Ada95 may be better examples than C++.
>
I don't know Ada, but I have done a fair amount of work in PL/I (Subset G 
on a Stratus) and some prototyping work with it on an AS/400. IIRC IBM 
designed PL/I to replace all other high level languages but all they 
produced was a dogs breakfast with:
- Fortran/Algol and COBOL style data declarations.
- Procedural statements resulting from a forced marriage between 
  Algol and COBOL.
- A preprocessor stolen from COBOL.
- A perverse and overused exception trapping mechanism, e.g. end of file
  or key not found as well as true exceptions such as field overflows.
  Perverse because there was no try/catch syntax and the exception trap
  didn't have to be anywhere near the statement that caused the exception.

If you think PL/I wasn't my favourite language you're right. I rate it 
slightly above RPG III and a fair way below COBOL and Perl.


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

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

#22115

On 2/4/2013 2:35 PM, Lew wrote:
> Silvio wrote:
>> parameters. Nothing very dramatic that could not be added to the
>> Java compiler if so desired.
>
> People are never satisfied. They wanted delegates, didn't get them,
> never mind Java got another way to do the same thing. Then they
> wanted generics, and sorta got them. Then they wanted runtime
> generics and didn't get them, never mind Java already had another way
> to do the same thing. Then they wanted closures, and sorta got them,
> never mind Java already had another way to do the same thing. Now
> they want tuples, never mind that Java already has another way to do
> the same thing.
>
> "Oh, it's just one more little thing!" they always exclaim. For a
> thousand little things.
>
> This is what happened to C++.
>
> Java will get all these things and the programming community will
> abandon the language, bitching that it's gotten too "heavy".

For what it's worth, I would say the biggest mistake that Java made was 
in the exclusion of unsigned integer types, or, most perniciously, the 
decision to make the byte datatype be signed. That doesn't necessarily 
mean I would want to see it changed at this point, however.

Java is its own programming language, and the fact that you can't 
program in it like you can in $LANGUAGE should be considered a feature, 
not a bug.

> The argument "it's just one little change" is a well-known lie. It's
> how customers eat up the profit margin for custom software. One thing
> and another and another and another and another and the game is how
> long you can say, "I'm only just going to take Poland, nothing else"
> before people realize I just incurred Godwin's Law.

I think it might be worth filtering out feature requests by asking
requestors to list at least one drawback of including their feature. If 
they can't think of any, then they are going to be totally clueless 
about how easy or hard a feature is to implement.

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

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

#22121

On Tue, 05 Feb 2013 10:04:11 -0600, Joshua Cranmer
<Pidgeot18@verizon.invalid> wrote:

>On 2/4/2013 2:35 PM, Lew wrote:
>> Silvio wrote:
>>> parameters. Nothing very dramatic that could not be added to the
>>> Java compiler if so desired.
>>
>> People are never satisfied. They wanted delegates, didn't get them,
>> never mind Java got another way to do the same thing. Then they
>> wanted generics, and sorta got them. Then they wanted runtime
>> generics and didn't get them, never mind Java already had another way
>> to do the same thing. Then they wanted closures, and sorta got them,
>> never mind Java already had another way to do the same thing. Now
>> they want tuples, never mind that Java already has another way to do
>> the same thing.
>>
>> "Oh, it's just one more little thing!" they always exclaim. For 
>> thousand little things.
>>
>> This is what happened to C++.

     AFAIAC, it is what happened to Java.

>> Java will get all these things and the programming community will
>> abandon the language, bitching that it's gotten too "heavy".

     It already is.  It is a maze.

>For what it's worth, I would say the biggest mistake that Java made was 
>in the exclusion of unsigned integer types, or, most perniciously, the 
>decision to make the byte datatype be signed. That doesn't necessarily 
>mean I would want to see it changed at this point, however.

     I did not like that either.  On my degree, I had to write some
networking code in Java.  Because of no unsigned integers, I had to do
a song and dance to handle IP address conversion.

>Java is its own programming language, and the fact that you can't 
>program in it like you can in $LANGUAGE should be considered a feature, 
>not a bug.

     Depending on what it is, it might be a feature, but it might be a
bug.

>> The argument "it's just one little change" is a well-known lie. It's
>> how customers eat up the profit margin for custom software. One thing
>> and another and another and another and another and the game is how
>> long you can say, "I'm only just going to take Poland, nothing else"
>> before people realize I just incurred Godwin's Law.

     No, it is not a lie for each case, but the end result of just one
more repeated many times is worse than if all of the items were dealt
with at once.

>I think it might be worth filtering out feature requests by asking
>requestors to list at least one drawback of including their feature. If 
>they can't think of any, then they are going to be totally clueless 
>about how easy or hard a feature is to implement.

     That is too easy.  Make it at least three drawbacks.

     And then, there is the question, "How have you managed to survive
without this feature you are asking for?  Why not just keep doing
that?"  That might shake out a good use case for the proposed feature.
Or show that the feature is not worth the trouble.

Sincerely,

Gene Wirchenko

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

#22123

On 2/5/2013 12:38 PM, Gene Wirchenko wrote:
>> I think it might be worth filtering out feature requests by asking
>> requestors to list at least one drawback of including their feature. If
>> they can't think of any, then they are going to be totally clueless
>> about how easy or hard a feature is to implement.
>
>       That is too easy.  Make it at least three drawbacks.

In my experience, most people coming up with inane feature requests 
can't articulate one drawback. Most of them that can rationalize at 
least one drawback can come up with several more if pressed, so it's 
only the first batch that's really useful as a filter.

I will point out that my experience is largely limited to open-source 
projects' RFE pages, and some conversations thereof. Among such 
inanities as I have actually seen people opine are gems such as:
* Integrating 16MB extensions will magically make that size disappear [1]
* It is easier to ask novice users to install a custom shell program and 
then write out ssh automatic upload scripts than it is to make a simple 
SFTP plugin (in terms of UI)
* A userspace program should distribute a custom filesystem driver that 
it uses internally for all of its state [2]
* If the "From" header identifies X as a sender, a message can only have 
come from X

I am, of course, excluding the hundreds of variants of "how had can it be?"

[1] "Surely there's some code savings to be had by integration, right?" 
was the response I got after pointing out that this doesn't work.
[2] To be fair, a devotee who thought that Plan 9 was the greatest thing 
since sliced bread.

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

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

#22152

On 2/5/2013 11:04 AM, Joshua Cranmer wrote:
> On 2/4/2013 2:35 PM, Lew wrote:
>> Silvio wrote:
>>> parameters. Nothing very dramatic that could not be added to the
>>> Java compiler if so desired.
>>
>> People are never satisfied. They wanted delegates, didn't get them,
>> never mind Java got another way to do the same thing. Then they
>> wanted generics, and sorta got them. Then they wanted runtime
>> generics and didn't get them, never mind Java already had another way
>> to do the same thing. Then they wanted closures, and sorta got them,
>> never mind Java already had another way to do the same thing. Now
>> they want tuples, never mind that Java already has another way to do
>> the same thing.
>>
>> "Oh, it's just one more little thing!" they always exclaim. For a
>> thousand little things.
>>
>> This is what happened to C++.
>>
>> Java will get all these things and the programming community will
>> abandon the language, bitching that it's gotten too "heavy".
>
> For what it's worth, I would say the biggest mistake that Java made was
> in the exclusion of unsigned integer types, or, most perniciously, the
> decision to make the byte datatype be signed.

I hate that as well.

>                                               That doesn't necessarily
> mean I would want to see it changed at this point, however.

ulong/uint/ushort/ubyte would actually not be that intrusive.

Arne

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

#22153

On 2/5/2013 6:43 PM, Arne Vajhøj wrote:

> On 2/5/2013 11:04 AM, Joshua Cranmer wrote:
>> For what it's worth, I would say the biggest mistake that Java made was
>> in the exclusion of unsigned integer types, or, most perniciously, the
>> decision to make the byte datatype be signed.

>
> I hate that as well.
>

>>                                               That doesn't necessarily
>> mean I would want to see it changed at this point, however.

>
> ulong/uint/ushort/ubyte would actually not be that intrusive.


For what it's worth:

<https://blogs.oracle.com/darcy/entry/unsigned_api>

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

#22245

On 2/5/2013 10:15 PM, markspace wrote:
> On 2/5/2013 6:43 PM, Arne Vajhøj wrote:
>
>> On 2/5/2013 11:04 AM, Joshua Cranmer wrote:
>>> For what it's worth, I would say the biggest mistake that Java made was
>>> in the exclusion of unsigned integer types, or, most perniciously, the
>>> decision to make the byte datatype be signed.
>
>>
>> I hate that as well.
>>
>
>>>                                               That doesn't necessarily
>>> mean I would want to see it changed at this point, however.
>
>>
>> ulong/uint/ushort/ubyte would actually not be that intrusive.
>
>
> For what it's worth:
>
> <https://blogs.oracle.com/darcy/entry/unsigned_api>

Interesting. Thanks.

Arne

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web