Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail
From: supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com>
Newsgroups: comp.lang.java.programmer
Subject: Re: StringBuilder Difficulties
Date: Tue, 05 Jul 2011 14:13:58 -0400
Organization: supercalifragilisticexpialadiamaticonormalizeringelimatisticantations
Lines: 76
Message-ID: <iuvk96$3bq$1@speranza.aioe.org>
References: <c4tk07dv1pq7u8k32qd6b7o1brc2rj8r30@4ax.com> <irln07dveti624e71v8viderf0hjtudue5@4ax.com> <9744m8FpnhU3@mid.individual.net> <6cqp07tiug2nu8u6ififvvek1694fkpfi1@4ax.com> <976q3jF3etU2@mid.individual.net> <e9ps07h56utkftkp8fcarm7uhkk5t999le@4ax.com> <978bv1FnqaU1@mid.individual.net> <gfk317di8imjcuvfgrn2mgtug1cne9m1m9@4ax.com> <97ejjfFrh1U1@mid.individual.net> <iuu9ka$o4p$1@speranza.aioe.org> <iuveal$r32$1@dont-email.me>
NNTP-Posting-Host: 3YDAuD+aHzH3oDO5mYkDPw.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: WinVN 0.99.12z (x86 32bit)
X-Notice: Filtered by postfilter v. 0.8.2
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5860

On 05/07/2011 12:32 PM, markspace wrote:
> On 7/4/2011 11:06 PM, super... wrote:
>>
>> public foobar (int a, String b) {
>> x = a + b.length();
>> y = 1.3*x;
>
>
> You go through quite a bit of verbiage to justify not typing int and
> double in front of those last two lines.

Toy example.

And the JLS goes through a lot more veriage to explain the exact 
semantics of every little construct in Java. With good reason.

> (Incidentally, while we're talking excess verbiage, your nom de usenet
> broke my reply button. Do you think you could adopt something that's
> less than 40 characters?)

Do you think you could adopt a newsreader that doesn't have glaring 
errors in it such as fixed-size char* buffers instead of 
java.lang.Strings or similarly non-woefully-primitive implementation 
datatypes? ;)

> Here at least we agree--Perl is too "compact" to the extreme that it's
> almost unreadable. Sure, I wouldn't mind if the Java compiler were a bit
> smarter, but at the same time I don't feel your examples were exactly
> compelling either.
>
> It's just not that hard to specify the type of a variable explicitly.

Not when there are only two of them and they're "int" and "double".

It starts to seem a bit more tedious the fifty-thousandth time you type

ConcurrentNavigableMap<QuuxscapeTuttifrutticatorGUIDInstance<String>,
List<FrobnicatorFactoryServiceProviderFactoryImpl<Integer,String>>>
foo

in a three million LOC project. Particularly when you frequently follow 
it up with

= new ConcurrentSkipListMap<QuuxScapeTuttifrutticatorGUIDInstance<String>,
List<FrobnicatorFactoryServiceProviderFactoryImpl<Integer,String>>>(new 
Comparator<QuuxScapeTuttiFrutticatorGUIDInstance<String>>() {
     public int compare (QuuxscapeTuttiFrutticatorGUIDInstance<String>
     x, QuuxscapeTuttiFrutticatorGUIDInstance<String> y) {
         ; use the reverse of the usual order in this one
         return compare(y.getToken(),x.getToken());
     }
};

and then the damn thing won't compile because you have the wrong 
capitalization for QuuxScape (or is it Quuxscape?) here and there.

> No one's fingers will fall off from typing.

I beg to differ; I'm sewing two of mine back on right after I hit "send" 
and that's just from writing a mere 12 lines of typical Java. Just 
imagine how many times I'll have reattached them by the third million 
LOC or so. ;)

> I understand you don't care for it, but it's not odious either.

*ahem* ConcurrentNavigableMap<QuuxscapeTuttifrutticatorGUIDInstance<String>,
List<FrobnicatorFactoryServiceProviderFactoryImpl<Integer,String>>>
*cough*

> Those of you who really like this sort of thing should check out
> lambda expressions for Java 8, there's some additional type
> inference coming where it's really needed.

Oh, goody. Progress at last. At this rate maybe we'll even have type 
inference in "new" expression initializations by about 2020 or so. Just 
in time for my retirement. ;)