Microsoft Losing Interest in C#?

D

Daniel O'Connell [C# MVP]

Mike Schilling said:
The compiler is not in C#? Odd; it's actually quite common for a compiler
to be written in the language it compiles; javac, for instance, is in
Java, most C compilers are in C, etc. There's obviously some
bootstrapping involved, but once that's done, there are many advantages,
e.g. when trying to improve the generated code, you have an instant test
case: the compiler itself.

The C# compiler is, currently, basically the first generation compiler.
While bootstrapping does come in handy, its a bit difficult to do while
writing a whole new compiler, I would expect.
Also, don't forget that the C# compiler probably shares a decent amount of
base code with the rest of the companies compilers, making C# itself a less
attractie option.

I do hope that eventually the C# compiler will be written in C#, but one can
live without it for the moment.
 
T

Tom Shelton

You are aware that the JSR for generics in Java has been worked on since
1999 (see http://www.jcp.org/en/jsr/detail?id=14) . When, exactly, did
Microsoft begin putting them into C#?

MS planned generics from the begining... You can look at this research
paper from May 02, 2001:

http://research.microsoft.com/projects/clrgen/generics.pdf

And yes, it does mention the proposed generics implementation for Java.
But, my questions to you is - why has it taken Sun almost 6 years to
implement that JSR? Was it the fact that MS was planning to implement
generics in 2.0?

I won't even go into all the other stuff that have been added to Java 1.5 -
i.e. extended for syntax (basically foreach), boxing, and enums.

There is no doubt in my mind that 1.5 is getting many of it's features as a
direct result of competition from .NET.
 
M

Mike Schilling

Tom Shelton said:
MS planned generics from the begining... You can look at this research
paper from May 02, 2001:

http://research.microsoft.com/projects/clrgen/generics.pdf

And yes, it does mention the proposed generics implementation for Java.

Let's be precise here. It mentions *actual* implementations of generics
in Java extensions and Java-like languages, and their uses as starting
points for the design of .NET generics. That is, the Java-ish generics came
first. Likewise, the official Java support for generics has come out before
the official .NET support.
 
M

Mike Schilling

Daniel O'Connell said:
The C# compiler is, currently, basically the first generation compiler.
While bootstrapping does come in handy, its a bit difficult to do while
writing a whole new compiler, I would expect.
Also, don't forget that the C# compiler probably shares a decent amount of
base code with the rest of the companies compilers, making C# itself a
less attractie option.

One would hope they share a lot of code, but the differing command-line
options, defaulrs, behavior, etc. at least of ILASM and CSC makes you
wonder.
 
T

Tom Shelton

Let's be precise here. It mentions *actual* implementations of generics
in Java extensions and Java-like languages, and their uses as starting
points for the design of .NET generics. That is, the Java-ish generics came
first. Likewise, the official Java support for generics has come out before
the official .NET support.

That is not relevant to the point, afict. Yes, they mention various
implementations of Java generics (all of them in 3rd party projects) - but,
Why did it take so long to implement them in the official Java language?
I'll tell you why, because until very recently Sun had no reason improve
Java as a language. The Java language has been realtively stagnate for
many year now (not talking the libraries, just the language) - and
suddenly, in 1.5 it is getting a whole host of new language features that
either exist in C# or are part of the 2.0 spec - Genrics, boxing, extended
for, static imports (actually, this is from VB.NET), enums, etc. It seems
to me that the obvious conclusion is that Sun is reacting to a bit of
competiton - which, IMHO, is a good thing.
 
J

James Curran

Joerg said:
But isn't that true mostly because the usual turn-around times for
compiling and linking native code are much higher than compiling CIL?

The compile time is nothing. The real saving is the time it takes to
get the program back into the situation where the error occurs
 
J

James Curran

Daniel said:
The C# compiler is, currently, basically the first generation
compiler. While bootstrapping does come in handy, its a bit difficult
to do while writing a whole new compiler, I would expect.

Slogan in the Visual C++ team t-shirts: "My compiler compiled your
compiler"
 
D

Daniel O'Connell [C# MVP]

James Curran said:
Slogan in the Visual C++ team t-shirts: "My compiler compiled your
compiler"
LOL.

Guess you weren't kidding about making more of an appearance in the C#
group, either, ;).
 
D

Daniel O'Connell [C# MVP]

Mike Schilling said:
One would hope they share a lot of code, but the differing command-line
options, defaulrs, behavior, etc. at least of ILASM and CSC makes you
wonder.

I was thinking more along the lines of the VB compiler and perhaps the
portions of the C++ compiler that work with managed code, instead of ILASM.
However I would imagine the C#, C++, and VB compilers atleast share their PE
file writer code and unmanaged metadata lookup code with ILASM.

The external driver code may well be implemented by each compiler to suit
their purposes(C# doesn't want to be bogged down by the extensive, and
slightly strange, options C++ uses, for example).

I do know that MS Research was working on a project that may become the
backend for MS's entire compiler suite(I think its called phoenix or
somesuch), which might suggest that they aren't looking to implement the C#
compiler in C# for a long time.
 
M

Michael C

Drebin said:
if/then/else) - but did you know they retrofitted "line input"? and this
"My" namespace, which has functionality that is NOT in C# - not cool.


If and when they do decide to port the "My" namespace over to C#, they'll
definitely have to change the name. Apart from the capitalization, "My" is
just not a good solid C# name. So I've been thinking it over, and I came up
with "thy". This does sound a little close to the current "try" keyword
though. I don't suppose we could convince MS to change "try" to "attempt".
So my second option is "thine". It's short. It's sweet. It's to the
point. It's all lowercase. It sounds very academic. It should confuse the
heck out of non-C# programmers everywhere. As we all know, all of this is
very important in C-style languages.

Thanks,
Michael C., MCDBA
 
S

Scott Allen

That's cool.

Maybe c# could get a feature like the "With" keyword in VB. I vote for
"henceforth".

henceforth thy.Computer
{
Console.WriteLine(.Info.TotalMemory);
}
 
A

Andrey

That's cool.
Maybe c# could get a feature like the "With" keyword in VB. I vote for
"henceforth".

henceforth thy.Computer
{
Console.WriteLine(.Info.TotalMemory);
}

LOL :)
 
A

Andrey

James said:
The compile time is nothing. The real saving is the time it takes to
get the program back into the situation where the error occurs

Well, compiling time is nothing now, not a few years ago.
A few years ago when i was programing on Borland C++ Builder/VS C++ 6.0 and had only a Pentium 166
(!!!) laptop, just single compiling of a midsize app was taking up to 10 min of my time. So
obviously i tried to perform most of it + debugging on VS, where this Edit-Cotinue feature was enabled.

BUT!!! There were so many times when tis feature just worked wrong, messed with data and gave wrong
results that at some point it became not worth it.
I am not sure if the feature in VB working correctly, but if it is same 'reliable' as it was in VS
C++ 6.0 you will lose much more time to understand why after 'Edit' you still get wrong in
'Continue' than just repeat the situation or re-look your code...

My thumb down to 'Edit' -> 'Continue' in C#.

Andrey
 
A

Andrey

Mike said:
The compiler is not in C#? Odd; it's actually quite common for a compiler
to be written in the language it compiles; javac, for instance, is in Java,
most C compilers are in C, etc. There's obviously some bootstrapping
involved, but once that's done, there are many advantages, e.g. when trying
to improve the generated code, you have an instant test case: the compiler
itself.

Odd? Why?
You didn't forget that Windows was writetn in c and asm, did you?
So is't it logical that the new API layer (.NET) should be writen using OS's 'native' compiler?
At least for speed and transparency?
 
J

Jon Skeet [C# MVP]

Andrey said:
Odd? Why?
You didn't forget that Windows was writetn in c and asm, did you?
So is't it logical that the new API layer (.NET) should be writen
using OS's 'native' compiler?
At least for speed and transparency?

The C# compiler isn't the new API layer though, is it? It was the point
that the C# compiler is not written in C# which is being considered
odd, not the CLR itself.

(I believe most of the BCL is written in C#.)
 
N

Nick Malik

Ah, to curse the darkness, or to light a candle...

If you wish for the software development community to behave in a manner
that is regulated by professional standards, then promote the use of
professional organizations. Medicine and Law have them, and they work well
for them (not for us, per se, but for them :). Engineering, Architecture,
even trades work, have requirements/certifications/licenses that must be
earned.

My hairdresser has to go through more red tape to open a salon, than I do in
order to write software.

Britain has a good start on a real professional organization for software (I
believe it is called the BCS). We have the ACM and IEEE/CS. (My apologies
if I've left out a deserving organization).

On the other hand, we need a wide array of folks in the software field.
Don't look down on VB developers. After earning my BA in Computer Science,
I wrote in C for six years on the Unix and DOS platforms. One of my systems
was embedded in the hardware of telecommunications devices. Until you've
seen your code execute in an ICE environment, you haven't lived. I then
switched to VB, and programmed in VB for many years before moving into
management, and only took back up C# in the past few years after the crash.
My VB experience ran from VB 1.0 for DOS, all the way through about VB5. I
only dabbled in VB6. By then, I was in positions that didn't let me write
much code.

I pretty much skipped C++ entirely.

Does that mean, because I wrote exclusively in VB for many years, that I
would be painted with your statements about "schlocky" VB developers? I
hope not!

There are professional, thoughful, creative, insightful, detail-oriented
professional developers, in the best sense of the word, working in the VB
space today. There always have been. Be careful not to put them down.

--- Nick Malik, proud former VB developer
 
D

Drebin

See inline..

Nick Malik said:
If you wish for the software development community to behave in a manner
that is regulated by professional standards, then promote the use of
professional organizations. Medicine and Law have them, and they work well
for them (not for us, per se, but for them :). Engineering, Architecture,
even trades work, have requirements/certifications/licenses that must be
earned.

I don't know that this is the answer though, because there are still
incompetent doctors and lawyers. I like the current system that "the
competent are well paid" - where with this system, "the certified are well
paid", which isn't right - in my book.
Does that mean, because I wrote exclusively in VB for many years, that I
would be painted with your statements about "schlocky" VB developers? I
hope not!

No, not at all!! Let me be clear. I don't have a problem with inexperienced
developers or developers that just don't know a certain technology. I'm not
saying that at all!!

I have a problem with people that have been programming longer than I've
been alive in just a couple of languages - and suck at it. They are horrible
developers. I am a big fan of "know your job". And I am surrounded by people
that CHOOSE not to better themselves and be competent at what they do. They
are paid to be "professional" software developers. These are people that do
the absolute minimum to get by in their job. Given a choice I'd rather do
more work, than have to work with shoddy code and ignorant developers. And
sadly, this is by FAR the biggest demographic for VB developers (having
worked at several companies in a few regions of the U.S.)

Maybe you haven't had experience with this type of developer? VB is by FAR
the language of choice of these type of people because it has the least
rules and enables the lazy programmer to be as lazy as they want!! The
problem I have with that, is that "assumptions lead to bugs".. and when they
embrace things like the "variant" datatype that can be coerced into any data
type, that's just ASKING for trouble.

Anyhow, my point is, there is an entire subculture of incompetent VB
developers (I've seen at MANY companies) that are able to continue being
"developers" because Microsoft keeps enabling them with this sloppy
(loosely-typed) language. I guess I'd like to see Microsoft take a stance
and "thin the herd" as it were. :) but why would they, they are making
money of these jokers!!
There are professional, thoughful, creative, insightful, detail-oriented
professional developers, in the best sense of the word, working in the VB
space today. There always have been. Be careful not to put them down.

I agree!! I have met probably 3 in my career - and I agree, the people that
are good in VB, are VERY good.. Sadly, this is by far the exception, not the
rule. Again, I don't have a problem with the language or IDE, I have a
problem with the lazy people that take advantage of the worst parts of VB
and continue to put out shoddy code that I continue to have to maintain!!
 
M

Mike Schilling

Daniel O'Connell said:
The C# compiler is, currently, basically the first generation compiler.
While bootstrapping does come in handy, its a bit difficult to do while
writing a whole new compiler, I would expect.

Bootstrapping a C# compiler would be almost trivial:

Start with a Java compiler written in Java..
Use the JLCA to translate it to C#.
Make slight changes to the parser to parse C# instead of Java.
Make slight changes to the backend to generate MSIL instead of Java
bytecode.

Half a :)
 
A

Andrey

Jon said:
The C# compiler isn't the new API layer though, is it? It was the point
that the C# compiler is not written in C# which is being considered
odd, not the CLR itself.

(I believe most of the BCL is written in C#.)
Well, yeap, it's not, i just call it a new Win API layer - because it just literary adds
object-oriented interface to Windows. MFC or VCL were just libraries, as long as they didn't require
any addt'l runtime.

And about odd things - heh, if CLR was written on anything but C#, Microsoft should've fired all the
HR right away :) But speaking of csc.. Brrrr... i messed up!
I meant not a compiler, but whatever runs the .Net Framework runtime, traslating managed code to
whatever recognized by windows - for the sole purpose of speed, for example.
 
D

Daniel O'Connell [C# MVP]

Mike Schilling said:
Bootstrapping a C# compiler would be almost trivial:

Start with a Java compiler written in Java..
Use the JLCA to translate it to C#.
Make slight changes to the parser to parse C# instead of Java.
Make slight changes to the backend to generate MSIL instead of Java
bytecode.

LOL. I suppose its possible, but then, the JLCA may be partially based on
the C# compiler's code, ;).

*HOWEVER*, now that a C# compiler exists, writing a new one is pretty
trivial. Mono did it, hell, I've done it to some extent.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top