refactoring problem

[Arne Vajhøj]

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

 

[Arne Vajhøj]

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

 

[Lew]

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.

 

[Silvio]

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


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.

 

[Joerg Meier]

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

 

[Joshua Cranmer]

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.

 

[Gene Wirchenko]

AFAIAC, it is what happened to Java.

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.

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

 

[Joshua Cranmer]

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.

 

[Lew]

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.

 

[Jim Gibson]

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

"Opinion" != "taste".

I'll give you that one

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

 

[Lew]

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.

 

[Arne Vajhøj]

Not at all.


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

 

[Arne Vajhøj]

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

 

[markspace]

I hate that as well.

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

For what it's worth:

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

 

[Arne Vajhøj]

For what it's worth:

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

Interesting. Thanks.

Arne