Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > refactoring problem

Reply
Thread Tools

refactoring problem

 
 
Arne Vajh°j
Guest
Posts: n/a
 
      02-04-2013
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


 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      02-04-2013
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


 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      02-05-2013
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
 
Reply With Quote
 
Silvio
Guest
Posts: n/a
 
      02-05-2013
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.
 
Reply With Quote
 
Joerg Meier
Guest
Posts: n/a
 
      02-05-2013
On Sun, 03 Feb 2013 06:30:40 -0800, Roedy Green wrote:

> Consider the following refactoring problem.


> There is a hunk of almost identical code that appears multiple times.
> It sets up 6 local variables.


> I would like to encapsulate it.


If you don't mind going to hell, you can always return Object[]

Liebe Gruesse,
Joerg

--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.
 
Reply With Quote
 
Joshua Cranmer
Guest
Posts: n/a
 
      02-05-2013
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
 
Reply With Quote
 
Gene Wirchenko
Guest
Posts: n/a
 
      02-05-2013
On Tue, 05 Feb 2013 10:04:11 -0600, Joshua Cranmer
<(E-Mail Removed)> 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
 
Reply With Quote
 
Joshua Cranmer
Guest
Posts: n/a
 
      02-05-2013
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
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      02-05-2013
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
 
Reply With Quote
 
Jim Gibson
Guest
Posts: n/a
 
      02-05-2013
In article <(E-Mail Removed)>, Lew
<(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
a class refactoring problem. Roedy Green Java 3 05-03-2009 10:04 PM
What does "refactoring" of a project mean ? Anan H. Samiti Java 33 07-30-2004 08:07 PM
Odd Multi-thread behavior when refactoring Christian Bongiorno Java 1 06-22-2004 07:46 AM
Survey on refactoring activities using IDEs Sebastian Jekutsch Java 5 06-09-2004 06:15 AM
come learn all about refactoring Refactorit Java 0 02-22-2004 06:36 PM



Advertisments