Microsoft Losing Interest in C#?

[Mike Schilling]

When I do this in Java, the output looks like:

2CFFFF1E-0CB4-11D9-A4BE-C3134102AA77
2CFFFF1F-0CB4-11D9-A4BE-C3134102AA77
2CFFFF20-0CB4-11D9-A4BE-C3134102AA77
2CFFFF21-0CB4-11D9-A4BE-C3134102AA77
2CFFFF22-0CB4-11D9-A4BE-C3134102AA77
2CFFFF23-0CB4-11D9-A4BE-C3134102AA77
2CFFFF24-0CB4-11D9-A4BE-C3134102AA77
2CFFFF25-0CB4-11D9-A4BE-C3134102AA77
2CFFFF26-0CB4-11D9-A4BE-C3134102AA77
2CFFFF27-0CB4-11D9-A4BE-C3134102AA77
2CFFFF28-0CB4-11D9-A4BE-C3134102AA77
2CFFFF29-0CB4-11D9-A4BE-C3134102AA77

C# output will be different from Java (due to the random numbers), but
if you run them at more or less the same time,

all UUIDs should be unique. The difference will be an increment in
the first group
the first, time-based, group should be larger for whichever is run
second
the second and third, also time-based, groups, should be identical
the last group should still end in AA77


My results:
D556A42D-0CA5-11D9-8D09-00000000AA77
D556A42E-0CA5-11D9-8D09-00000000AA77
D556A42F-0CA5-11D9-8D09-00000000AA77
D556A430-0CA5-11D9-8D09-00000000AA77
D556A431-0CA5-11D9-8D09-00000000AA77
D556A432-0CA5-11D9-8D09-00000000AA77
D556A433-0CA5-11D9-8D09-00000000AA77
D556A434-0CA5-11D9-8D09-00000000AA77
D556A435-0CA5-11D9-8D09-00000000AA77
D556A436-0CA5-11D9-8D09-00000000AA77
D556A437-0CA5-11D9-8D09-00000000AA77
D556A438-0CA5-11D9-8D09-00000000AA77

The straight 0's at the end seems a little odd, but that may just be an
aspect of my partiuclar machine.

It's definitely a bug. It appears to be in the translation of:

/** randomly generate a node ID. make the last two bytes
* 0xAA77, which cannot conflict with a real Ethernet address */
private void initializeNodeId()
{
byte barr[] = new byte[2];

Random r1 = new Random();
Random r2 = new Random(r1.hashCode());
r1.nextBytes(barr);
nodeId[0] = barr[0];
nodeId[1] = barr[1];

r2.nextBytes(barr);
nodeId[2] = barr[0];
nodeId[3] = barr[1];

nodeId[4] = (byte)0xaa;
nodeId[5] = 0x77;
}

I'll hazard a guess: that the nextBytes call translates to
System.Random.NextBytes(), which fills an array of *unsigned* bytes, and
that the results don't get copied back to barr, which is an array of
*signed* bytes. If so, it's the same bug I saw in 2002.

That does appear to be the case, and, frankly, I would be surprised if any
translator got this right. It seems like something only a person who knew
what the code was supposed to be doing could do.

I disagree. The translator knows enough to convert
Java.Util.Random.nextBytes(byte[]) to System.Random.NextBytes(byte[]); it
should also know the semantics of the call, i.e. that the call changes the
byte array. Even without that detailed knowledge, the default behavior
should be something like:

byte tempArr = new byte[barr.Length];
CopyToByteArray(barr, tempArr);
System.Random.NextBytes(tempArr);
CopyFromByteArray(tempArr, barr);

At any rate, the fact that JLCA silently produces errors like this is reason
enough for me not to use it.

 

[Daniel O'Connell [C# MVP]]

message
When I do this in Java, the output looks like:

2CFFFF1E-0CB4-11D9-A4BE-C3134102AA77
2CFFFF1F-0CB4-11D9-A4BE-C3134102AA77
2CFFFF20-0CB4-11D9-A4BE-C3134102AA77
2CFFFF21-0CB4-11D9-A4BE-C3134102AA77
2CFFFF22-0CB4-11D9-A4BE-C3134102AA77
2CFFFF23-0CB4-11D9-A4BE-C3134102AA77
2CFFFF24-0CB4-11D9-A4BE-C3134102AA77
2CFFFF25-0CB4-11D9-A4BE-C3134102AA77
2CFFFF26-0CB4-11D9-A4BE-C3134102AA77
2CFFFF27-0CB4-11D9-A4BE-C3134102AA77
2CFFFF28-0CB4-11D9-A4BE-C3134102AA77
2CFFFF29-0CB4-11D9-A4BE-C3134102AA77

C# output will be different from Java (due to the random numbers), but
if you run them at more or less the same time,

all UUIDs should be unique. The difference will be an increment in
the first group
the first, time-based, group should be larger for whichever is run
second
the second and third, also time-based, groups, should be identical
the last group should still end in AA77


My results:
D556A42D-0CA5-11D9-8D09-00000000AA77
D556A42E-0CA5-11D9-8D09-00000000AA77
D556A42F-0CA5-11D9-8D09-00000000AA77
D556A430-0CA5-11D9-8D09-00000000AA77
D556A431-0CA5-11D9-8D09-00000000AA77
D556A432-0CA5-11D9-8D09-00000000AA77
D556A433-0CA5-11D9-8D09-00000000AA77
D556A434-0CA5-11D9-8D09-00000000AA77
D556A435-0CA5-11D9-8D09-00000000AA77
D556A436-0CA5-11D9-8D09-00000000AA77
D556A437-0CA5-11D9-8D09-00000000AA77
D556A438-0CA5-11D9-8D09-00000000AA77

The straight 0's at the end seems a little odd, but that may just be an
aspect of my partiuclar machine.

It's definitely a bug. It appears to be in the translation of:

/** randomly generate a node ID. make the last two bytes
* 0xAA77, which cannot conflict with a real Ethernet address */
private void initializeNodeId()
{
byte barr[] = new byte[2];

Random r1 = new Random();
Random r2 = new Random(r1.hashCode());
r1.nextBytes(barr);
nodeId[0] = barr[0];
nodeId[1] = barr[1];

r2.nextBytes(barr);
nodeId[2] = barr[0];
nodeId[3] = barr[1];

nodeId[4] = (byte)0xaa;
nodeId[5] = 0x77;
}

I'll hazard a guess: that the nextBytes call translates to
System.Random.NextBytes(), which fills an array of *unsigned* bytes, and
that the results don't get copied back to barr, which is an array of
*signed* bytes. If so, it's the same bug I saw in 2002.

That does appear to be the case, and, frankly, I would be surprised if
any translator got this right. It seems like something only a person who
knew what the code was supposed to be doing could do.

I disagree. The translator knows enough to convert
Java.Util.Random.nextBytes(byte[]) to System.Random.NextBytes(byte[]); it
should also know the semantics of the call, i.e. that the call changes the
byte array. Even without that detailed knowledge, the default behavior
should be something like:

byte tempArr = new byte[barr.Length];
CopyToByteArray(barr, tempArr);
System.Random.NextBytes(tempArr);
CopyFromByteArray(tempArr, barr);

At any rate, the fact that JLCA silently produces errors like this is
reason enough for me not to use it.

While I can accept that is correct in this circumstance, I would find it
troubling in the general case for this behavior. Neither choice is going to
be correct all of the time. In alot of cases this behavior would be quite
useless, and potentially costly with regards to performance (imagine a call
to a socket, writer, or stream with a large buffer, copying it twice would
be ghastly and buggy, IMHO. Worse yet, compound that over 40k lines. What
good is code which has a tripled memory copy rate).

However, I do think that such calls should be flagged by the //UPGRADE_TODO
tag they add to potential errors or changes, I just don't think either
default is a very good choice.

 

[Mike Schilling]

I disagree. The translator knows enough to convert
Java.Util.Random.nextBytes(byte[]) to System.Random.NextBytes(byte[]); it
should also know the semantics of the call, i.e. that the call changes
the byte array. Even without that detailed knowledge, the default
behavior should be something like:

byte tempArr = new byte[barr.Length];
CopyToByteArray(barr, tempArr);
System.Random.NextBytes(tempArr);
CopyFromByteArray(tempArr, barr);

At any rate, the fact that JLCA silently produces errors like this is
reason enough for me not to use it.

While I can accept that is correct in this circumstance, I would find it
troubling in the general case for this behavior. Neither choice is going
to be correct all of the time. In alot of cases this behavior would be
quite useless, and potentially costly with regards to performance (imagine
a call to a socket, writer, or stream with a large buffer, copying it
twice would be ghastly and buggy, IMHO. Worse yet, compound that over 40k
lines. What good is code which has a tripled memory copy rate).

If the translator knows how to map a Java SDK call to a .NET framework call,
part of that mapping should be knowing which direction(s) to copy the array
in. In this case, it needed to be copied out but not in, and JLCA generated
the precise opposite. Sorry, but it's a low-quality product.

 

[Daniel O'Connell [C# MVP]]

I disagree. The translator knows enough to convert
Java.Util.Random.nextBytes(byte[]) to System.Random.NextBytes(byte[]);
it should also know the semantics of the call, i.e. that the call
changes the byte array. Even without that detailed knowledge, the
default behavior should be something like:

byte tempArr = new byte[barr.Length];
CopyToByteArray(barr, tempArr);
System.Random.NextBytes(tempArr);
CopyFromByteArray(tempArr, barr);

At any rate, the fact that JLCA silently produces errors like this is
reason enough for me not to use it.

While I can accept that is correct in this circumstance, I would find it
troubling in the general case for this behavior. Neither choice is going
to be correct all of the time. In alot of cases this behavior would be
quite useless, and potentially costly with regards to performance
(imagine a call to a socket, writer, or stream with a large buffer,
copying it twice would be ghastly and buggy, IMHO. Worse yet, compound
that over 40k lines. What good is code which has a tripled memory copy
rate).

If the translator knows how to map a Java SDK call to a .NET framework
call, part of that mapping should be knowing which direction(s) to copy
the array in. In this case, it needed to be copied out but not in, and
JLCA generated the precise opposite. Sorry, but it's a low-quality
product.

I'm not arguing its quality, Idon't really care, I just think its overly
arrogant to assume that any application can know every API's purpose and
make decisions based on that, especially those which coudl be in, out, or
in\out depending on other parameter values. This case *could* have, I
suppose, but I doubt the entire SDK is that clean cut. Your general case
scenario is just bad and wrong-minded, IMHO.

Also, I think translating Java into C# is a pretty bad idea. The two are
terribly different, and I wouldn't think that java code would be something I
would want in C#(or vice versa, for that matter).

 

[Mike Schilling]

I disagree. The translator knows enough to convert
Java.Util.Random.nextBytes(byte[]) to System.Random.NextBytes(byte[]);
it should also know the semantics of the call, i.e. that the call
changes the byte array. Even without that detailed knowledge, the
default behavior should be something like:

byte tempArr = new byte[barr.Length];
CopyToByteArray(barr, tempArr);
System.Random.NextBytes(tempArr);
CopyFromByteArray(tempArr, barr);

At any rate, the fact that JLCA silently produces errors like this is
reason enough for me not to use it.

While I can accept that is correct in this circumstance, I would find it
troubling in the general case for this behavior. Neither choice is going
to be correct all of the time. In alot of cases this behavior would be
quite useless, and potentially costly with regards to performance
(imagine a call to a socket, writer, or stream with a large buffer,
copying it twice would be ghastly and buggy, IMHO. Worse yet, compound
that over 40k lines. What good is code which has a tripled memory copy
rate).

If the translator knows how to map a Java SDK call to a .NET framework
call, part of that mapping should be knowing which direction(s) to copy
the array in. In this case, it needed to be copied out but not in, and
JLCA generated the precise opposite. Sorry, but it's a low-quality
product.

I'm not arguing its quality, Idon't really care, I just think its overly
arrogant to assume that any application can know every API's purpose and
make decisions based on that, especially those which coudl be in, out, or
in\out depending on other parameter values. This case *could* have, I
suppose, but I doubt the entire SDK is that clean cut. Your general case
scenario is just bad and wrong-minded, IMHO.

Gee, and we were getting along so well.

Actually, it wouldn't be that hard. There's a finite list of API calls it
tries to convert, and for each of them, determining whether the inputs are
modified or not is just a question of reading the documentation. JLCA
already has API mappings, or it couldn't have gotten that far. Annotating
them with some simple semantic information doesn;t add much more work. And
it's a perfect opportunity to use unit tests to verify the behavior: write
tests in Java, translate them, and ensure that both versions act
identically. (More difficult with a random number generator than with most
calls, I admit.)

Actually, copying byte arays is a bad idea. In the array, the byte is
simply an octet; it makes no difference whether it's signed or unsigned. It
isn't until the byte comes out of the array that it matters, and then it can
be cast to sbyte before any arithmetic gets done on it.

Also, I think translating Java into C# is a pretty bad idea. The two are
terribly different, and I wouldn't think that java code would be something
I would want in C#(or vice versa, for that matter).

C# is bigger, since it has events, delegates, unmanaged pointers, etc. But
for the common subset, 99% of the difference between the two languages is
syntax. The object models are close to identical, and the common APIs are
awfully similar too; notice how Random.nextBytes(0 translated to
Random.NextBytes(). It's actually not all that difficult to do correctly.

 

[Daniel O'Connell [C# MVP]]

Gee, and we were getting along so well.

Sorry, I came across a little gruff, . Honestly I wasn't *that* impressed
by it, myself, though I do think v3 is considerably better than v1.

Actually, it wouldn't be that hard. There's a finite list of API calls it
tries to convert, and for each of them, determining whether the inputs are
modified or not is just a question of reading the documentation. JLCA
already has API mappings, or it couldn't have gotten that far. Annotating
them with some simple semantic information doesn;t add much more work.
And it's a perfect opportunity to use unit tests to verify the behavior:
write tests in Java, translate them, and ensure that both versions act
identically. (More difficult with a random number generator than with
most calls, I admit.)

It might not be terribly hard, I'm just more concerned with the possiblity
that both choices will be wrong in some cases, can that semantic information
express all possibliities or only a most common scenario? Can the analyzer
determine which possibility is in use? If not, chances are you are going to
get hidden, subtle bugs that upset someone. It just may not happen to be
either of us, .

Actually, copying byte arays is a bad idea. In the array, the byte is
simply an octet; it makes no difference whether it's signed or unsigned.
It isn't until the byte comes out of the array that it matters, and then
it can be cast to sbyte before any arithmetic gets done on it.

I tend to agree, I think array covariance of primative types(or atleast
signed\unsigned alternatives of one type) is something worht having in the
langauge. But that goes well beyond the JLCA, it is stuck using what it can.
I suppose it could convert to a byte array, but that wouldn't be very
literal and may upset people as well, .

C# is bigger, since it has events, delegates, unmanaged pointers, etc.
But for the common subset, 99% of the difference between the two languages
is syntax. The object models are close to identical, and the common APIs
are awfully similar too; notice how Random.nextBytes(0 translated to
Random.NextBytes(). It's actually not all that difficult to do correctly.

While most of the api's are similar, personally I think it is the eventing
model that changes things. I write very few substantial pieces of code in C#
that doesn't use an event here or there, and I doubt there is alot of
extensive java code that doesn't use and\or expose event sinks.

However, the other issue is weird bugs like this one. While this particular
bug is a semantic one due to the JCLA, I don't think the application is
capable of definitivly assuring no changes in behavior. Like I said, JJ2k
was something like 350 issues. While I certainly couldn't write a jpeg2000
implementation in the period of time it would take the maintainer to fix
those issues, the time for me personally to learn enough about jpeg2000 and
java to fix those errors without causing issues and keep the java baggage
would probably be high enough to consider a native implementation using .NET
platform conventions. Thus, for the uninitiated, its a pretty useless tool

For me, personally, architectural conventions can go along way towards
productivity. While I don't have many particular problems with java's
conventions, seeing them all of a sudden within .NET code is a shocker and
breaks the mindset somewhat.

 

[Mike Schilling]

It might not be terribly hard, I'm just more concerned with the possiblity
that both choices will be wrong in some cases, can that semantic
information express all possibliities or only a most common scenario? Can
the analyzer determine which possibility is in use? If not, chances are
you are going to get hidden, subtle bugs that upset someone. It just may
not happen to be either of us, .

I think that it's well-defined for a given method that a parameter is an
input, an output, or both.

I tend to agree, I think array covariance of primative types(or atleast
signed\unsigned alternatives of one type) is something worht having in the
langauge. But that goes well beyond the JLCA, it is stuck using what it
can. I suppose it could convert to a byte array, but that wouldn't be very
literal and may upset people as well, .

Only if they're very literal-minded Seriously, converting to a byte
array rather than an sbyte array doesn't cause any problems, and avoids any
need to copy them.

While most of the api's are similar, personally I think it is the eventing
model that changes things. I write very few substantial pieces of code in
C# that doesn't use an event here or there, and I doubt there is alot of
extensive java code that doesn't use and\or expose event sinks.

GUI code, certainly. I think auto-conversion of Swing or awt is hopeless.
I write mostly server code or command-line programs, and there eventing is
either much less common or hidden inside frameworks.

However, the other issue is weird bugs like this one. While this
particular bug is a semantic one due to the JCLA, I don't think the
application is capable of definitivly assuring no changes in behavior.
Like I said, JJ2k was something like 350 issues. While I certainly
couldn't write a jpeg2000 implementation in the period of time it would
take the maintainer to fix those issues, the time for me personally to
learn enough about jpeg2000 and java to fix those errors without causing
issues and keep the java baggage would probably be high enough to consider
a native implementation using .NET platform conventions. Thus, for the
uninitiated, its a pretty useless tool

I agree. Its design point, I think, is people with a substantial
application who are considering dropping their Java development and do a
one-time conversion to .NET, and the goal is to make that feasible by saving
them time over rewriting from scratch. That isn't me; I need to keep a Java
version and a .NET version moving forward together, and JLCA is not useful
for that.

 

[Daniel O'Connell [C# MVP]]

I think that it's well-defined for a given method that a parameter is an
input, an output, or both.

It is, however, in a circumstance where its both, at times only input or
only output matters to the caller, the other result is simply unimportant
for whatever reason(usually because an API does too much, I suspect output
is ingnored more often than the input). How do you determine that with a
code analyzer?

Only if they're very literal-minded Seriously, converting to a byte
array rather than an sbyte array doesn't cause any problems, and avoids
any need to copy them.

Unless, for some reason, mathematics is involved. I am actually somewhat
surprised that java used signed bytes in this circumstance.

GUI code, certainly. I think auto-conversion of Swing or awt is hopeless.
I write mostly server code or command-line programs, and there eventing is
either much less common or hidden inside frameworks.

I primiarly write components, which often expose events that are eventually
listend to by GUI applications. However, I find within the .NET framework,
there are *quite* a few instances where an event or atleast a delegate is
used. Threading, asynch IO, .NET 2.0 generic methods, etc.

Swing and awt are pretty unlikely, although with the new layout manager ins
..NET 2.0 it would be much easier than it would have been before that,
atleast for basic code.

I agree. Its design point, I think, is people with a substantial
application who are considering dropping their Java development and do a
one-time conversion to .NET, and the goal is to make that feasible by
saving them time over rewriting from scratch. That isn't me; I need to
keep a Java version and a .NET version moving forward together, and JLCA
is not useful for that.

I tend to agree. The only real way to achieve this is to implement a full
java compiler and runtime for .NET (or a full C# compiler and .NET runtime
for java) which allows cross compilation. Otherwise, its simply not possible
to do.

Anyway, for unified version, I just don't think the differing design models
is going to work well, atleast not for component code.

 

[Mike Schilling]

It is, however, in a circumstance where its both, at times only input or
only output matters to the caller, the other result is simply unimportant
for whatever reason(usually because an API does too much, I suspect output
is ingnored more often than the input). How do you determine that with a
code analyzer?

By looking at the API definition. Really. If you can find an exmple where
it's unclear whether an array parameter is input, output, or inout, I'd be
very interested in seeing it.

Unless, for some reason, mathematics is involved.

Never true of byte arrays. True of individual bytes in well-defined
circumstances, e.g when the bytes is used in an arithmetic expression or
converted to a wider type. Casts take care of these.

There's a reason I'm stating these things authoritatively. And it's
possible to do a much better job than the JLCA.

 

[Daniel O'Connell [C# MVP]]

By looking at the API definition. Really. If you can find an exmple
where it's unclear whether an array parameter is input, output, or inout,
I'd be very interested in seeing it.

Knowing if its in, out, or inout is one thing, but knowing if the code
actually cares about the out is quite another. Perhaps the first call to
nextBytes is simply a primer, to throw away the first result set, or
whatever.

By looking at the code, we can know otherwise, but the answer isn't *as*
obvious to an analyzer.

And, of course, you get designers who think its clever to use a bool that
defines if the method puts out output or not, etc.

I'm not saying its not possible, just too much to expect of this particular
product. As you've pointed out, its not really meant for people maintaining
both branches.

Never true of byte arrays. True of individual bytes in well-defined
circumstances, e.g when the bytes is used in an arithmetic expression or
converted to a wider type. Casts take care of these.

You've got a point. I was thinking of matrix transformations, but in
retrospect, either there would be a standard transform and the converter
could fix the outputted code so that it behaves properly or the matrix
method would be ported by the JLCA anyway, thus no need for an array
conversion.

There's a reason I'm stating these things authoritatively. And it's
possible to do a much better job than the JLCA.

Its always possible, yes, almost anything is possible if you are willing to
put the time into. The question is more: Is it worth it? One would hope so,
but I certainly don't have a vote on the product itself.

 

[Mike Schilling]

Knowing if its in, out, or inout is one thing, but knowing if the code
actually cares about the out is quite another. Perhaps the first call to
nextBytes is simply a primer, to throw away the first result set, or
whatever.

By looking at the code, we can know otherwise, but the answer isn't *as*
obvious to an analyzer.

And, of course, you get designers who think its clever to use a bool that
defines if the method puts out output or not, etc.

I'm not saying its not possible, just too much to expect of this
particular product. As you've pointed out, its not really meant for people
maintaining both branches.

My last comment, I think, since we've pretty much beaten this subject to
death:

Between performance and correctness, I'd choose correctness every time.
It's much eaiser, given an application that works, to find and fix
bottlenecks, than, given a program with randomly introduced bugs, to find
all of them.

 

[Daniel O'Connell [C# MVP]]

My last comment, I think, since we've pretty much beaten this subject to
death:

Agreed

Between performance and correctness, I'd choose correctness every time.
It's much eaiser, given an application that works, to find and fix
bottlenecks, than, given a program with randomly introduced bugs, to find
all of them.

However, on the same page, I wouldn't trust the application in any
circumstance. After a port like that, you really *need* to analyze eveyr
line, run every unit test, or there may be other, subtle bugs.

Correctness just isn't something definatly attainable, even if the tool, in
theory, should be perfect.

 

[John Bailo]

I don't know if you have noticed, but it seems like Microsoft is losing
interest in C#, and putting their energy into Visual Basic.NET instead.

Maybe it's time for C# people to speak up.

Michael

If anything, they seem to be sliding back towards VC++ and COM.

I think they couldn't crack the java market, so they will retreat and
concentrate on hard coded ( rather than soft coded ) applications.

 

[Saras Asnani]

why do yhou make grammatical mistakes ? "a well programmed monkey could

do *its* not their job". Syntax and grammar mean almost the same thing,
you know. If you make English grammatical mistakes, do you also make
syntactical mistakes ? It is worth correcting, you know.

Listen Mr thankless, South Indian. Just because South Indians are
stealing our US JOBS does not mean crap about my grammar! Second,
just because Idians without open minds can talk about grammar and
their high literacy rate does equate to activity of the mind/brain
proudcing good output (even if the output was themsevles)... So f****k
off with the grammar stuff. let me tell you, it will take a long time
for you to understand America and the New Found Lands/Thought (We
have some problems) but we are okay. We values ideas not just good
f***ken grammar. So, be happy mofo, that Columbus never found the
real India.... just look what we did to natives of America. All I am
saying is the idea/soultion/questions matter... If you are concerned
about spelling and grammar... go watch spellbound, you bribed &
converted corrupt mofo!
....yeah.. and peace out
.......If you are not from the likes of woziack, jobs, or the xerox
palo-alto your reaction is not wanted here!

 

[Saras Asnani]

John, I agree. Even if my fist love SUN, Inc goes down the drain,
you will still have one of my favs like IBM to take care of the Java
Ball.

I have to say Write Once Run Anywhere + J2EE + better security are the
most appealing reasons for Java.

I wish Java performed well on the front end (without have to know the
exact details or spending hours on optimizing the code... if this was
true I would still just use C++/MSVC++)

The other thing I wish that there was an IDE for Java for front end
general windows (wins for apple, unix x, ms-win etc..) and for web
page development.

I have used Jbuilder, and (ucky!) Sybase's PowerJ.
Ofcourse when I first say C# and still do now, I belive C# is nice
copy of Java with additions. But you have to give MS the compliments
on creating a very nice IDE (Visual Studio). The down side to IDEs is
that non-technology or people without a good understading of
engieering (both hardware/software) when they come out with a
solution, there is no thought... it just wirte code, test-debug in
many cycles, then as the year goes by.... they say this was the right
way of doing it.

For me the bigger problem is that most of the people do not have
software engineering concepts. or lets say common sense. Think
before you code. Architect + Civil Engieer for building instead of
okay boys dig the hole, pour the cement, build the building with
rainbow color bricks.... oh yeah whats the problem.... It works it
stands... till one day Hurrican Jeane comes along and the building
falls.....
Its like IRAQ. They have WMDS.. Sure they are hidding it up their
butts. They dont have any, so get sadam. No thought.
Its the Act first, think later what distingues between a MS oriented
solutions provider and a more open-minded, effective, & efficent
solutions provider.
I think Bush, Chenney, Gates, and BALL...AMMER were programmed by the
same people... Or it was Gates you did BALL and BALL in turn Did Bush,
and Bush did Dick... so its pretty f'ed up...