I will say, I'm only back into Java for a week, and even in spite of Java 
generics and inner classes and all that, I'm already much more appreciative 
of how much crap MS fixed in C#. :-)  Stuff that's taking me 4 or 5 lines, 
with the types repeated three times each, is a one-liner in C#, even without 
LINQ.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

Darren New escreveu:
> I will say, I'm only back into Java for a week, and even in spite of 
> Java generics and inner classes and all that, I'm already much more 
> appreciative of how much crap MS fixed in C#. :-)  Stuff that's taking 
> me 4 or 5 lines, with the types repeated three times each, is a 
> one-liner in C#, even without LINQ.

yeah, I like it how MS took ideas from Python and Haskell too.

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

On 22/09/2011 06:56 PM, Darren New wrote:
> I will say, I'm only back into Java for a week, and even in spite of
> Java generics and inner classes and all that, I'm already much more
> appreciative of how much crap MS fixed in C#. :-) Stuff that's taking me
> 4 or 5 lines, with the types repeated three times each, is a one-liner
> in C#, even without LINQ.

Now you know why I dislike using languages which aren't Haskell...

Post a reply to this message

On 22/09/2011 06:56 PM, Darren New wrote:
> I will say, I'm only back into Java for a week, and even in spite of
> Java generics and inner classes and all that, I'm already much more
> appreciative of how much crap MS fixed in C#. :-)

Last time I used Java, we did a little dance. It went like this:



"Object-oriented programming allows you to use facilities such as 
subclassing to extend the application in ways the original designers 
never anticipated."

"By declaring your class 'final', you can prevent anybody subclassing it."



"Multiple inheritance is EVIL! We support only single inheritance."

"We support multiple inheritance using 'interfaces'. They're like 
classes, but not as good."



"For receiving input, use the InputStream classes. For output, use the 
OutputStream classes."

"For receiving input, use the Reader classes. For output, use the Writer 
classes. The InputStream and OutputStream classes are now formally 
deprecated. (Even though System.in, System.out and System.err mention 
them explicitly.)"



"We will never deprecate the AWT."

"The AWT is now deprecated. Please use Swing in new applications."



"To create a horizontal scrollbar, create a Scrollbar object passing the 
SCROLLBAR_AXIS_HORIZONTAL static constant. To create a vertical 
scrollbar, create a Scrollbar object passing the SCROLLBAR_AXIS_VERTICAL 
static constant. To determine whether a given scrollbar is horizontal or 
vertical, call getAxis() and compare against these static constants. Do 
not hard-code the numerical values, as more may be added in future."



"The 'int' type is not a class."

"If you want 'int' to be a class, you must wrap it using the 'Int' class."

"The int[] type is a class."



"For structuring complex applications, use the ApplicationFactory class."

"The ApplicationFactory class is now deprecated. Please use 
ApplicationCenter for new."

"The ApplicationCenter class is now deprecated. The ApplicationFactory 
class has been formally UNdeprecated. Please use ApplicationFactory for 
new applications."


Basically, the language is loaded with hypocrisy, and the libraries were 
huge, bloated, overly complex, insufficiently documented, and prone to 
radical alterations every minor point release. (In fact, I gather that 
these days, they don't even call it Java 1.5.x any more. They just call 
it 5.x...)

Last time I checked, java.awt.Component has about 80+ methods. Every 
single AWT widget inherits these 80+ methods. Any guesses what the hell 
the difference between widget.init(), widget.start() and widget.begin() 
is? The documentation helpfully fails to say. (E.g., "start() - starts 
the widget." Yeah, thanks for that. I gathered.)



It still amuses me how almost every statically-typed programming 
language lacks parametric types, /except/ for arrays, which are 
hard-wired into the language.

(It still makes me cry that Haskell to this day still doesn't support 
parametric unboxed arrays - you know, like what almost every programming 
language known to man /does/ provide, out of the box...)

In Java, "int" is not a class. But "int[]" is. In fact, every array is a 
class. And you cannot ever subclass it.

> Stuff that's taking me
> 4 or 5 lines, with the types repeated three times each, is a one-liner
> in C#, even without LINQ.

I love the way that with the JDK, compiling a class compiles every class 
it depends on, but declaring two mutually-dependent classes is enough to 
break the compiler. I wonder if they fixed that yet?

I love how you run your Java applet in IE and it works perfectly, and 
when you run it in Netscape it dies with java.lang.NullPointerException.

I love how we have System.err (because System.error would be far too 
verbose), and yet we have java.lang.ArrayIndexOutOfBoundsException. 
Because, say, java.language.exception.ArrayIndex would be too hard?

I still think that Java is a great /idea/ - you specify a programming 
language and a library of classes which is guaranteed to work the same 
on *all* platforms. That's a very neat idea.

I also still think that the actual Java /design/ and /implementation/ 
utterly suck. Nice idea, too bad it went so drastically wrong from 
thereon in.

(I suppose you could argue that C# is the same. You know, if it actually 
worked on more than one platform...)

Post a reply to this message

On 9/23/2011 10:28 AM, Invisible wrote:

> (I suppose you could argue that C# is the same. You know, if it actually
> worked on more than one platform...)

Mono.

-- 
~Mike

Post a reply to this message

On 23/09/2011 05:43 PM, Mike Raiford wrote:
> On 9/23/2011 10:28 AM, Invisible wrote:
>
>> (I suppose you could argue that C# is the same. You know, if it actually
>> worked on more than one platform...)
>
> Mono.

Does Mono support more than 0.2% of what .NET supports yet?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Fri, 23 Sep 2011 18:25:07 +0100, Orchid XP v8 wrote:

> On 23/09/2011 05:43 PM, Mike Raiford wrote:
>> On 9/23/2011 10:28 AM, Invisible wrote:
>>
>>> (I suppose you could argue that C# is the same. You know, if it
>>> actually worked on more than one platform...)
>>
>> Mono.
> 
> Does Mono support more than 0.2% of what .NET supports yet?

Yes.  Go read the mono page and see what compatibility is.

Jim

Post a reply to this message

On 9/23/2011 8:28, Invisible wrote:
> Last time I used Java, we did a little dance. It went like this:

I agree with every one of these rants.

Now, throw in Eclipse, as well as code that generates java code, which the 
IDE doesn't know about.

> "For receiving input, use the InputStream classes. For output, use the
> OutputStream classes."
>
> "For receiving input, use the Reader classes. For output, use the Writer
> classes. The InputStream and OutputStream classes are now formally
> deprecated. (Even though System.in, System.out and System.err mention them
> explicitly.)"

And now there's a third set, NIO, or "New I/O".  I wonder what they'll call 
the fourth set.

> "We will never deprecate the AWT."
> "The AWT is now deprecated. Please use Swing in new applications."

Yeah, I remember that one.

> "For structuring complex applications, use the ApplicationFactory class."
>
> "The ApplicationFactory class is now deprecated. Please use
> ApplicationCenter for new."
>
> "The ApplicationCenter class is now deprecated. The ApplicationFactory class
> has been formally UNdeprecated. Please use ApplicationFactory for new
> applications."

Oh, wait until you use some "dependency injection". Then you'll have *no* 
idea how your code is structured. You not only get the indirection of 
factories making other factories, but the factories you're depending on 
aren't even compiled at the same time as everything else. Good luck figuring 
out what you're trying to instantiate.

> documentation helpfully fails to say. (E.g., "start() - starts the widget."
> Yeah, thanks for that. I gathered.)

Yep, yep. Altho MS has been starting to do that sort of crap lately too, 
I've noticed.  The first release of Java had identical documentation for 
StreamReader and StreamWriter, because they did the cut-and-paste and forgot 
to change "read" to "write" everywhere.

> I love the way that with the JDK, compiling a class compiles every class it
> depends on, but declaring two mutually-dependent classes is enough to break
> the compiler. I wonder if they fixed that yet?

Nope.

> I love how we have System.err (because System.error would be far too
> verbose), and yet we have java.lang.ArrayIndexOutOfBoundsException. Because,
> say, java.language.exception.ArrayIndex would be too hard?

I did some code yesterday where I had to break one type name over multiple 
lines to keep within the 80-character line limit standard. It doesn't help 
when you have stuff like
   FastPersistentLinearCollection<OrganizationIndividualRelationshipEntity>

I kid you not.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

>> "For receiving input, use the InputStream classes. For output, use the
>> OutputStream classes."
>>
>> "For receiving input, use the Reader classes. For output, use the Writer
>> classes. The InputStream and OutputStream classes are now formally
>> deprecated. (Even though System.in, System.out and System.err mention
>> them
>> explicitly.)"
>
> And now there's a third set, NIO, or "New I/O". I wonder what they'll
> call the fourth set.

*facepalm*

>> "We will never deprecate the AWT."
>> "The AWT is now deprecated. Please use Swing in new applications."
>
> Yeah, I remember that one.

Was it you that said something about "committing to backwards 
compatibility way too early"?

>> "For structuring complex applications, use the ApplicationFactory class."
>>
>> "The ApplicationFactory class is now deprecated. Please use
>> ApplicationCenter for new."
>>
>> "The ApplicationCenter class is now deprecated. The ApplicationFactory
>> class
>> has been formally UNdeprecated. Please use ApplicationFactory for new
>> applications."
>
> Oh, wait until you use some "dependency injection". Then you'll have
> *no* idea how your code is structured. You not only get the indirection
> of factories making other factories, but the factories you're depending
> on aren't even compiled at the same time as everything else. Good luck
> figuring out what you're trying to instantiate.

It just amuses me that they thought the current design was bad, so they 
deprecated it and build a better replacement. And then they decided the 
repliacement was worse than the original, so they UNdeprecated it. I 
mean, WTF?

>> documentation helpfully fails to say. (E.g., "start() - starts the
>> widget." Yeah, thanks for that. I gathered.)
>
> Yep, yep. Altho MS has been starting to do that sort of crap lately too,
> I've noticed.

I notice Office no longer comes with any documentation at all, just a 
link to an online forum. (So if you have no Internet access, there's no 
documentation AT ALL.) That's a nice touch... Why pay for experts to 
write correct documentation when you can get your users to spread 
erroneous twiddle for free?

> The first release of Java had identical documentation for
> StreamReader and StreamWriter, because they did the cut-and-paste and
> forgot to change "read" to "write" everywhere.

Yep. That's the great thing about embedding documentation in the source 
code; it keeps the two in sync.

Oh, wait...

>> I wonder if they fixed that yet?
>
> Nope.

LOL. At least VisualStudio J++ got that right... (Oh, wait, Sun sued 
Microsoft to make them discontinue that product.)

> I did some code yesterday where I had to break one type name over
> multiple lines to keep within the 80-character line limit standard. It
> doesn't help when you have stuff like
> FastPersistentLinearCollection<OrganizationIndividualRelationshipEntity>
>
> I kid you not.

That's just silly...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 9/24/2011 6:33, Orchid XP v8 wrote:
> Was it you that said something about "committing to backwards compatibility
> way too early"?

Yep. That was the fundamental failure, caused by the whole "write once" 
marketing campaign.

> I notice Office no longer comes with any documentation at all, just a link
> to an online forum.

It has documentation. It just mixes it in with the online forum. I think you 
have to chose to install it locally, tho, which is what you might be seeing.

>> I did some code yesterday where I had to break one type name over
>> multiple lines to keep within the 80-character line limit standard. It
>> doesn't help when you have stuff like
>> FastPersistentLinearCollection<OrganizationIndividualRelationshipEntity>
>>
>> I kid you not.
>
> That's just silly...

It makes perfect sense in context. It's just absurdly verbose.

What would be in C#

   var z = from y select z where z.id = myID

in java becomes

   List<OrganizationIndividualRelationshipEntity> z =
     Lists.ImmutableCopyOf(
       Lists.filter(y, new 
Predicate<List<OrganizationIndividualRelationshipEntity>() {
      @override boolean apply(OrganizationIndividualRelationshipEntity x) {
      return x.id = myID;
      }
     }
     )
     }

I've lost track of closing braces....
     )

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

>> Was it you that said something about "committing to backwards
>> compatibility way too early"?
>
> Yep. That was the fundamental failure, caused by the whole "write once"
> marketing campaign.

I wouldn't mind, but it didn't even /work/.

Like I said, I wrote an applet. It worked fine in IE. When I tried it 
with Netscape, it crashed with a null pointer exception. And, since it's 
an applet, I have no idea /where/ it crashed. You don't get a stack trace.

I suspect this is probably related to the vagueness of the 
documentation. That means that others don't really know how to implement 
it correctly. Or, hell, maybe the documentation just doesn't actually 
match what Sun implemented...

>> I notice Office no longer comes with any documentation at all, just a
>> link to an online forum.
>
> It has documentation. It just mixes it in with the online forum. I think
> you have to chose to install it locally, tho, which is what you might be
> seeing.

Oh well. Almost never non-trivial Office task usually involves finding 
an Office MVP anyway...

> I've lost track of closing braces....

...which is why every open bracket should always start a new indentation 
level...

Post a reply to this message

On 9/23/2011 12:25 PM, Orchid XP v8 wrote:
> On 23/09/2011 05:43 PM, Mike Raiford wrote:
>> On 9/23/2011 10:28 AM, Invisible wrote:
>>
>>> (I suppose you could argue that C# is the same. You know, if it actually
>>> worked on more than one platform...)
>>
>> Mono.
>
> Does Mono support more than 0.2% of what .NET supports yet?
>

Yeah, at least more than 0.2% probably by a substantial amount. But I 
can't be bothered to target the Mono framework, honestly, I'll just 
stick with MS's CLR.

-- 
~Mike

Post a reply to this message

On 9/24/2011 10:37 AM, Darren New wrote:
> On 9/24/2011 6:33, Orchid XP v8 wrote:
>> Was it you that said something about "committing to backwards
>> compatibility
>> way too early"?
>
> Yep. That was the fundamental failure, caused by the whole "write once"
> marketing campaign.
>
>> I notice Office no longer comes with any documentation at all, just a
>> link
>> to an online forum.
>
> It has documentation. It just mixes it in with the online forum. I think
> you have to chose to install it locally, tho, which is what you might be
> seeing.
>
>>> I did some code yesterday where I had to break one type name over
>>> multiple lines to keep within the 80-character line limit standard. It
>>> doesn't help when you have stuff like
>>> FastPersistentLinearCollection<OrganizationIndividualRelationshipEntity>
>>>
>>> I kid you not.
>>
>> That's just silly...
>
> It makes perfect sense in context. It's just absurdly verbose.
>
> What would be in C#
>
> var z = from y select z where z.id = myID
>
> in java becomes
>
> List<OrganizationIndividualRelationshipEntity> z =
> Lists.ImmutableCopyOf(
> Lists.filter(y, new
> Predicate<List<OrganizationIndividualRelationshipEntity>() {
> @override boolean apply(OrganizationIndividualRelationshipEntity x) {
> return x.id = myID;
> }
> }
> )
> }
>
> I've lost track of closing braces....
> )
>


Java: It's like pounding your head against a brick wall. Repeatedly.

-- 
~Mike

Post a reply to this message

Le 2011/09/26 04:44, Invisible a écrit :
>>> Was it you that said something about "committing to backwards
>>> compatibility way too early"?
>>
>> Yep. That was the fundamental failure, caused by the whole "write once"
>> marketing campaign.
>
> I wouldn't mind, but it didn't even /work/.
>
> Like I said, I wrote an applet. It worked fine in IE. When I tried it
> with Netscape, it crashed with a null pointer exception. And, since it's
> an applet, I have no idea /where/ it crashed. You don't get a stack trace.
>
> I suspect this is probably related to the vagueness of the
> documentation. That means that others don't really know how to implement
> it correctly. Or, hell, maybe the documentation just doesn't actually
> match what Sun implemented...

It may be that some bug in the implementation under IE is effectively 
hiding another bug...
It may be that you get the crash on the correct implementation and you 
did something wrong that made it work on a faulty implementation.

Remember the imfamous "it's not a bug, it's a feature" that Microsoft 
spun to cover actual IE bugs instead of correcting them.

>
>>> I notice Office no longer comes with any documentation at all, just a
>>> link to an online forum.
>>
>> It has documentation. It just mixes it in with the online forum. I think
>> you have to chose to install it locally, tho, which is what you might be
>> seeing.
>
> Oh well. Almost never non-trivial Office task usually involves finding
> an Office MVP anyway...
>
>> I've lost track of closing braces....
>
> ...which is why every open bracket should always start a new indentation
> level...
>

Post a reply to this message

On 9/26/2011 15:34, Alain wrote:
> It may be that some bug in the implementation under IE is effectively hiding
> another bug...

 From experience in exactly this field (java applets in the early days) I 
can pretty much guarantee f'ups were Mozilla and not Microsoft.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 27/09/2011 01:11 AM, Darren New wrote:
> On 9/26/2011 15:34, Alain wrote:
>> It may be that some bug in the implementation under IE is effectively
>> hiding
>> another bug...
>
>  From experience in exactly this field (java applets in the early days)
> I can pretty much guarantee f'ups were Mozilla and not Microsoft.

Considering the applet only makes a handful of AWT calls before doing 
lots of compute-bound stuff to generate a fractal... I'm pretty sure it 
was just some unimplemented library call returning null or something 
like that.

Post a reply to this message

On 24/09/2011 04:37 PM, Darren New wrote:

> What would be in C#
>
> var z = from y select z where z.id = myID
>
> in java becomes
>
> List<OrganizationIndividualRelationshipEntity> z =
> Lists.ImmutableCopyOf(
> Lists.filter(y, new
> Predicate<List<OrganizationIndividualRelationshipEntity>() {
> @override boolean apply(OrganizationIndividualRelationshipEntity x) {
> return x.id = myID;
> }
> }
> )
> }
>
> I've lost track of closing braces....
> )

Haskell has crazy type signatures too.

Haskell also has mechanisms for defining shortcuts. :-P

Post a reply to this message

On 11/17/2011 1:26, Invisible wrote:
> On 24/09/2011 04:37 PM, Darren New wrote:
>
>> What would be in C#
>>
>> var z = from y select z where z.id = myID
>>
>> in java becomes
>>
>> List<OrganizationIndividualRelationshipEntity> z =
>> Lists.ImmutableCopyOf(
>> Lists.filter(y, new
>> Predicate<List<OrganizationIndividualRelationshipEntity>() {
>> @override boolean apply(OrganizationIndividualRelationshipEntity x) {
>> return x.id = myID;
>> }
>> }
>> )
>> }
>>
>> I've lost track of closing braces....
>> )
>
> Haskell has crazy type signatures too.
>
> Haskell also has mechanisms for defining shortcuts. :-P

You don't understand. Those *are* the shortcuts in Java.
No, I am not exaggerating.  For example, "Lists" is nothing but a static 
class full of static routines that are shortcuts for actually shortcuts for 
the more full-bodied declarations including all the generic types.

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.

Post a reply to this message

>> Haskell has crazy type signatures too.
>>
>> Haskell also has mechanisms for defining shortcuts. :-P
>
> You don't understand. Those *are* the shortcuts in Java.

IT BURNS!! >_<

Post a reply to this message

Darren New escreveu:
> On 11/17/2011 1:26, Invisible wrote:
>> On 24/09/2011 04:37 PM, Darren New wrote:
>>
>>> What would be in C#
>>>
>>> var z = from y select z where z.id = myID
>>>
>>> in java becomes
>>>
>>> List<OrganizationIndividualRelationshipEntity> z =
>>> Lists.ImmutableCopyOf(
>>> Lists.filter(y, new
>>> Predicate<List<OrganizationIndividualRelationshipEntity>() {
>>> @override boolean apply(OrganizationIndividualRelationshipEntity x) {
>>> return x.id = myID;
>>> }
>>> }
>>> )
>>> }
>>>
>>> I've lost track of closing braces....
>>> )
>>
>> Haskell has crazy type signatures too.
>>
>> Haskell also has mechanisms for defining shortcuts. :-P
> 
> You don't understand. Those *are* the shortcuts in Java.
> No, I am not exaggerating.  For example, "Lists" is nothing but a static 
> class full of static routines that are shortcuts for actually shortcuts 
> for the more full-bodied declarations including all the generic types.

problem is that you're trying to make java look worse than it is (and I 
agree it is bad) by programming it in a functional style it simply is 
not meant to.  Java is all about imperative programming at its worse, 
but at least it makes some sense when programmed that way.

I'm not quite natural to java, but I guess the correct way to program:

var z = from y select z where z.id = myID

in it would be something like:

List<OrganizationIndividualRelationshipEntity> y, z;
for (OrganizationIndividualRelationshipEntity x : y)
   if (x.id = myID) z.add(x);

that doesn't look half as bad as trying to program C in Object-Oriented 
fashion.  Still, not as fun as without type declarations.  I suppose if 
the code snippet was inside some generics method you could call 
"OrganizationIndividualRelationshipEntity" "T" and have:

List<T> y, z;
for (T x : y)
   if (x.id = myID) z.add(x);

Post a reply to this message

On 11/18/2011 7:55, nemesis wrote:
> problem is that you're trying to make java look worse than it is

Well, it's the way this particular project at google was written. But yes, 
making Java functional without lambdas is messy.

I went thru something like 300 classes in this particular hugely 
overengineered project and didn't find a single noun in the bunch of them. 
They were all stuff like "CustomerUpdater" and "StorageManagerImplementor" 
and such.  I think it comes from doing too much networking, since networks 
don't do a real good job of shipping objects around. I've been trying to 
introduce the team to the wonders of actually having the code and the data 
in the same class. :-)

> var z = from y select z where z.id = myID
>
> in it would be something like:
>
> List<OrganizationIndividualRelationshipEntity> y, z;
> for (OrganizationIndividualRelationshipEntity x : y)
> if (x.id = myID) z.add(x);

Yep.

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.

Post a reply to this message

Le 19/11/2011 07:07, Darren New nous fit lire :
> I've been trying to introduce the team to the wonders of actually having
> the code and the data in the same class. :-)

Well, from the old relational database experience... they shouldn't.
At least, they shouldn't be too tighly coupled until the code is
specific to the data and the data are usable only by the code.

Have a SQL schema (data) and only stored procedures usually ends up in
nightmare.

Data should have their invariants and rules.
Code should be in charge of transforming the data with respect to the
rules and adding new pieces of data which also match the rules.

But you're right, having data in very distant classes from the ones
which have the code is also a PITA. (and from an isolation point of
view, the code classes should not be friend of data class, so no ugly
shortcuts...)

Post a reply to this message

On 11/19/2011 1:33, Le_Forgeron wrote:
> Le 19/11/2011 07:07, Darren New nous fit lire :
>> I've been trying to introduce the team to the wonders of actually having
>> the code and the data in the same class. :-)
>
> Well, from the old relational database experience... they shouldn't.
> At least, they shouldn't be too tighly coupled until the code is
> specific to the data and the data are usable only by the code.

Well, the data in the database shouldn't be exposed to the user at all, any 
more than if your web site is stored in a database the browser should need 
to know that.

What I'm saying is that if you have a routine that (for example) marks a 
video as having been watched by the current user, it shouldn't be in some 
third class called "VideoWatcherRecorder" taking an integer video number and 
a long user ID. It should be in the video class and take a reference to a 
user object, or vice versa. Otherwise, you're just writing procedural code 
in Java.

> Data should have their invariants and rules.

Yep. And that's very hard to do without doing OO programming. Or relational 
programming. And if you're using an OO language like Java, it should be 
enforced in the objects that interface to the database (along with the 
database, if possible, which it isn't in this case).

> Code should be in charge of transforming the data with respect to the
> rules and adding new pieces of data which also match the rules.

Sure. But the difference is where that code live. Is it in some other 
package or compilation unit, or is it in the same class that reads and 
writes the database?

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.

Post a reply to this message