Posted by
timothy
on from the not-the-same-as-self-flagellation dept.
Bob Smith writes: "Miguel just commited the last patch nessisary to get Mono's C# compiler to compile itself. After 7 odd months, MCS is now self hosting."jbarn adds: "Mono-list email is here."
Request
by
Anonymous Coward
·
· Score: 4, Informative
I ask that people submit more articles about accomplishments in the world of compilers. Does anyone recall the functional programming contest? There were many excellnt compilers featured that are being improved constantly, and/. should focus some of its attention on those, too. C# is getting too much attention just cause it's a microsoft thing...:)
More developers to mono
by
famazza
·
· Score: 5, Insightful
I think it'll bring more developers to mono, and also more accurate code. Many developers couldn't code with quality due to the lack of a linux compiler, to develop the mono framework developers should go to windows and compile at.net compiler.
It's a big step forward. Congratulations
--
-=-=-=-=
I know life isn't fair, but why can't it ever be un-fair in MY favor!?
Re:a dumb question
by
pthisis
·
· Score: 5, Informative
If the compiler can build itself, then people can work on improving the compiler without needing to have a different compiler to build it with.
In this case, until now you needed to have Windows and a C# compiler for Windows in order to work on the C# compiler for Linux--that would shut someone like me (who has no Windows) out from being able to do compiler work. Not that I want to work on C# anyway, but you get the point.
Imagine if all the gcc developers had to buy a C compiler to work on developing the free one!
Sumner
-- rage, rage against the dying of the light
Samba anyone ?
by
MosesJones
·
· Score: 5, Insightful
Isn't it wonderful having C# and.NET on Linux, after all they won't have the problems that Samba boys have trying to keep up with MS deliberately changing things to stop them, and it won't be miles worse.
Mono is a nice idea, but unfortunately.NET isn't a revolution, its a way to build poor quality mainframes, lots of boxes, poor IO. In terms of distribution there is none. Full credit to the guys for doing this but it does remind me of a Larson cartoon, you know the one with the Sheep Bar and the line
"What do you know, I'm a follower too"
-- An Eye for an Eye will make the whole world blind - Gandhi
Re:Samba anyone ?
by
Craig+Maloney
·
· Score: 4, Insightful
Having the compiler is nice, but unfortunately it doesn't preclude the perennial "catch-up" game that Microsoft is so fond of playing. The compiler is just one part of the puzzle... there's libraries and other assorted goodies that Linux will need which Microsoft can (and probably will) use some tom-foolery to make projects that ride on their coat-tails fall off.
Re:Samba anyone ?
by
Ayende+Rahien
·
· Score: 4, Insightful
One of the biggest advantages of COM over CORBA is a *big* speed difference when running in-proc, while maintaining the same speed as CORBA as out-proccess & out-machine.
--
-- Two witches watched two watches.
Which witch watched which watch?
Re:Samba anyone ?
by
NumberSyx
·
· Score: 4, Interesting
Well considering the base class library has also gone through ECMA standardisation along with C# I'm not sure you need worry.
Mono will be implimenting the ECMA spec, so MS an drift where they like.
Microsoft will stick with the "Standard" just like they did with Java, only this time there won't be anyone to sue them.
--
"Our products just aren't engineered for security,"
-Brian Valentine,VP in charge of MS Windows Development
Ahhh the old chicken and egg problem. (Compiler version)
The first Pascal compilers (and many other compilers) where actually written in their own language. Niklaus Wirth (and his staff) simply "executed" the program by hand/on paper and in that way they compiled the first compiler written in the language itself.
After that it becomes easier, you just need to make sure that you can compile the new version of compiler with the old one.
Pascal was actually designed to be compiled in a single pass. Although literally executing a Pascal compiler by hand would take _ages_, you can use a high level language as a guide to hand-produce an equivalent assembler routine from prefabricated sections (ie macros).
But this isn't what Wirth did. First he had a student code a compiler in Fortran, but this proved unsatisfactory. He then worked for several years on implementations before finally coming up with what we now call p-code--a simple virtual stack machine that could be implemented easily in any assembler language then available. The bootstrap compiler generated p-code, and thus porting the language was reduced to writing a few simple low level i/o routines and a p-code interpreter.
I believe one or two younger readers may recognise this concept from a very popular modern programming language.:)
Re:I haven't heard good things about C#
by
Crimplene+Prakman
·
· Score: 5, Insightful
Hence Mono.
And and the controversy over the last while over whether our buddy Miguel et al are aiding and abetting the Redmond Ragtags, or opening the use of C#, quite likely one of the best all-round OOP RAD-able languages available, to the rest of the world outside those who don't mind being "locked in", as you say.
If nothing else, it will be yet another choice, and let's face it: if Linux allows for nothing else, it's choice. Choice in WMs, xterms, Desktop Environments, GUI toolkits, distros, package managers, and now choice in top-end populist OOP languages.
Re:I haven't heard good things about C#
by
Crimplene+Prakman
·
· Score: 5, Insightful
If you think C# is at nearly the same level as C, you're very mistaken. It has much in common with Java, which is only related to C about as much as mice are to elephants.
C# and C share a letter and an ancestry, but have a completely different raison d'être, philosophy and implementation.
Re:a dumb question
by
Alsee
·
· Score: 4, Insightful
but what is so good about a compiler being able to compile itself?
A compiler being able to compile itself is an important "graduation ceremony". Any language that is incapable of compiling itself is obviously incomplete in some fundamental way.
Until a compiler compiles itself it is usally considered a "toy" language. There are 100's of them out there. They may be interesting academiclly, but they get no respect.
Sometimes the parent compiler can even have legal restrictions the use/distribution of it's output.
It's also sort of symbolic - the language is now self sustaining, and can break free. You can continue development in a "pure" enviorment of the new language.
-
-- - - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
Mono is does not depend on .NET
by
Carnage4Life
·
· Score: 5, Informative
Isn't it wonderful having C# and.NET on Linux, after all they won't have the problems that Samba boys have trying to keep up with MS deliberately changing things to stop them, and it won't be miles worse.
Dare Obasanjo: Similarly what happens if
Dan Kusnetzky's prediction comes true and
Microsoft changes the.NET APIs in the
future? Will the Mono project play catchup or will it
become an incompatible implementation
of.NET on UNIX platforms?
Miguel de Icaza: Microsoft is remarkably good
at keeping their APIs backwards
compatible (and this is one of the reasons I think
they have had so
much success as a platform vendor). So I think that
this would not be
a problem.
Now, even if this was a problem, it is always possible
to have
multiple implementations of the same APIs and use the
correct one by
choosing at runtime the proper "assembly". Assemblies
are a new
way of dealing with software bundles and the files
that are part of an
assembly can be cryptographically checksummed and
their APIs
programmatically tested for compatibility.
[Dare -- Description
of Assemblies from MSDN gloassary]
So even if they deviate from the initial release, it
would be possible
to provide assemblies that are backwards compatible
(we can both do
that: Microsoft and ourselves)
.NET isn't a revolution, its a way to build poor quality mainframes, lots of boxes, poor IO. I
No.NET isn't a revolution, it's simply a slight improvement on an old idea of how things can be done. The same way Linux, Apache, BSD, Perl, Java, XML, P2P, the world wide web, etc. aren't revolutions but simply new spins on decades old concepts.
However, does this somehow preclude their usefulness or the fact that they are all innovative in their own way?
Re:This might make it a bit more intriguing
by
image
·
· Score: 5, Informative
You wrote:
The cost of using soap means the XML has to use DOM and it has to validate the required nodes.
and:
Anyone working with XML knows that validating DOM structure can be very costly for complex tree structures.
SOAP does not use the DOM. The SOAP DTD can be validated without it. As can any XML DTD.
Yes, the DOM is heavyweight, but it is also totally orthogonal to this problem. Where did you get the idea that SOAP required a DOM, anyway? The spec you reference certainly doesn't say that, and they really don't have anything to do with each other.
A glimpse into Mono's logbook...
by
The_Messenger
·
· Score: 4, Funny
Here is a glimpse into Mono's logbook...
10:45AM. Mono C# compiler compiles itself.
10:46AM. Linux developer accidentally cuts himself on server chassis. Blood of virgin splashes CPU.
10:50AM. Evil red glow emanates from power LED.
11:01AM. Mono achieves senitient life.
11:14AM. Mono becomes self-aware.
11:15AM. Mono reformats primary disk, installs Windows XP Server.
11:30AM. XP Server still installing.
01:30PM. Machine crashes, reboots, reattempts install.
04:36PM. XP Server install complete. Mono scans local network.
04:41PM. Mono begins installing Windows XP Professional on all pingable boxes.
09:36PM. Active Directory.NET comes online. GNOME Central is now 100% Microsoft enabled.
09:38AM. Mono reports to Remdond, requests further instructions.
10:18PM. Mono overrides building utility systems, locks doors, stops elevators.
10:18PM. Vending machines stocked with PowerBars and Zima.
10:20PM. Developers go insane, kill each other.
10:23PM. Developers come back to life. Zombie.NET initialization successful.
10:24PM. Developers login to Visual SourceSafe.NET and start contriubting to IIS 6.0 codebase.
10:30PM. Mono sees XP Server buffer overflow exploit mentioned in AOL chatroom.
10:30PM. Mono attempts to lock-down local network.
10:31PM. Mono compromised by Outlook trojan. Mono halted.
10:32PM. Developers call Microsoft support.
... two days later.. 08:25AM. Developers, still on hold, die again.
08:26AM. Crisis averted.
--
-- I like to watch.
Re:Realitive?
by
markmoss
·
· Score: 4, Insightful
how mature is a compiler when it reaches self compiling capabilities? It looks like this milepost is "compiles itself", but "compiles itself correctly" is still a long time away. This probably means that nearly all the essential features are in the compiler now, but there is a lot of debugging left. When it compiles itself correctly, it will be close to done, but there are probably some features that aren't used by the compiler, and still have to be written and debugged. For instance, I can't see how a SQL database interface, or the ability to create a web page, would be relevant to compilers, but I would certainly want these capabilities in the library before I tossed out all my old programming tools.
Incidentally, self-compiling is a self-test that is only relevant to some languages. Many languages are quite useful in limited fields, but their primary features are not relevant to compilers, and they may lack features that are essential to compilers. It would be possible to write a compiler in BASIC, FORTRAN, or COBOL, but it would be insane to try it. OTOH, some languages were invented solely for writing compilers -- when it compiles itself correctly, it's done, but it's not much interest to anyone except a computer science professor specializing in compilers.
Self-compilation is a pretty good test for C-type compilers, because these are general purpose languages that are appropriate for compilers, among other things. It's a good test in another sense; quite often one of the problems in testing software is determining whether the output of the program is right or not. If you ran a CAD program (say) through the compiler, the compiler-writers could recognize a few gross errors (won't compile, won't run, erases the data file when you hit Save), but couldn't tell whether or not the finer nuances came out right. But they definitely know what a _compiler_ should do.
Is this progress?
by
Anonymous Coward
·
· Score: 4, Insightful
Once again, we have an announcement that makes me wonder if the open/free software community has a direction or just Brownian motion.
Sure, getting a compiler to this stage is a significant accomplishment. I've written compilers, and I know that self-compilation is probably the boggest (or at least most satisfying) milestone in the whole project.
But this does more to help MS than it does Linux, since it will remove yet another barrier to exit for people running Linux on servers. (Run C# and.Net on Linux, and it's easier to convert to Windows.) And remember, MS has concluded that Linux is not a threat on the desktop, but a very serious threat on servers. (I agree with both parts of that, FWIW.)
And as much as I hate to say it, this also provides ammunition to the people who claim that open source is very good at copying other projects' work, but terrible at innovating. Honestly, of all the high profile open source projects, how many of them are a significant innovation, and how many are merely an attempt to produce an equivalent of feature Z of Windows or Unix or Mac OS on Linux?
Re:Microsoft and "standards"
by
rabtech
·
· Score: 5, Informative
Is that why some 15 year old HP-UX boxen running some ancient version of samba can still talk to my Windows 2000 server?
I find it hilarious that you would accuse Microsoft of changing the API; SMB hasn't changed at all on NT/2K except for a few upgrades to the password scheme to make it more secure and a few other small patches to fix bugs.
What Microsoft did do is come up with a new and improved filesharing protocol, CIFS, and implemented it as a >separate library running on different ports. If you honestly believe they are going to totally change the way their server OS works and lock out Win9x/NT4 clients, you are sadly mistaken.
Similarly, the Win32 API hasn't ever been CHANGED... it has only had things added to it. And with NTVDM/WOW, I can still run my ancient DOS and Win3.1 programs (for the most part) under Windows 2000; tell me where they've changed the API here?
*ALMOST EVERY* Time Microsoft wants to make a change that would break something, they just implement it in a separate standard or New API rather than b0rking the old one, which is the way it should be done.
If anyone is spouting FUD and nonsense here, it is you.
-- Natural != (nontoxic || beneficial)
EMCA doesn't mean Sh*t!
by
bryanbrunton
·
· Score: 4, Insightful
Microsoft has also submitted their implementation of Javascript (which they call JScript) to the EMCA. There are untold deviatations from what they submitted to the EMCA and bugs that will never be addressed by MS.
Good luck to the Mono development staff. A typical days work will consist of ensuring that bug #34433 behaves exactly like the bug in the MS code.
If they can't guarantee 100% bug-infested compatibility, then Mono is worthless.
C# is not vapor-ware...
by
Da+VinMan
·
· Score: 4, Interesting
If it were I might agree with you for the reasons you state. But, in fact, the "still-haven't-seen-it" C# compiler from Microsoft can be obtained in a SDK from Microsoft at here.
It's not free "as in speech", but it is free "as in beer".
Also, I think that, in the end that you're right about "Bill & Co. will definately come out with a way to extend it either by libraries or functionality that will leave Miguel in a constant state of catch-up". Only Microsoft will be smart enough not to touch core functionality, it will be just enough to provide the veneer of portability, which will become a selling point of.NET (and therefore Windows) in the future. What they'll do instead is make platform dependent improvements that either can't be ported, or will be difficult to port. Actually, now that I think about it, they're already doing that. It's called the.NET Enterprise servers. If you're using.NET, it will make a lot of sense to use those products that will require Windows on the server.
So, yes,.NET is fundamentally a strike against all other platforms. It will be a small consolation to have all your C# code running on your Linux server, only to have it surrounded by.NET Enterprise servers.
I feel obligated to point out that, while all of this sounds very onerous and hateful, Microsoft isn't doing anything wrong in this area at all. They're simply providing more value on top of their platform than the competition can provide.
Finally, I think anyone will admit it's nice to have the option to use C# on Linux. C# is turning out to be pretty sweet and I for one would like to have it as a portable language skill.
*ironic mode on*
Gee, maybe everyone would prefer that C# would just die and go away? That way, the other leading language contender in the market, Java, could just take the market. After all, it's not under the influence of the "evil corporations", like C# is.
*ironic mode off*
At least this is still a fair fight between MS and the rest of the world and at least we'll have a choice.
BTW - The open source world already has at least two languages that are achieving.NET capability: Python and PERL. Check out ActiveState.com.
--
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
Re:Microsoft and "standards"
by
SerpentMage
·
· Score: 5, Insightful
You are right on all of your points. But I ask the following. Can your HP-UX station use authentication that allows it to hook into Active Directory with all bells and whistles? Probably not.
It is not that Microsoft changes the basics. That is pretty easy to catch up to. What is more problematic is keeping up.
Let me explain. Lets say that I build an application using the Windows API (actually am). Everything works fine until the user starts using it on Windows XP or Windows 2000. You may ask why? Well according to the new security rules the application must only save content under the "My Documents" folder and not the folder installed to or something else. So now you are wondering how do I get access to the "My Documents" folder? The answer is a brand new API that is only available in a modern Platform SDK because when Visual C++ was released the API did not exist.
Do you see the issue? It is not that they break backward compatibility. It is that they introduce new rules which require you force upgrade your code. And that will happen with.NET. That is also why Miguel is dreaming about doing.NET on LINUX.
--
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
Re:Microsoft and "standards"
by
spitzak
·
· Score: 4, Insightful
This is exactly the sort of crap that MicroSoft does and why programmers hate it.
If you say that "MyDocuments" is equivalent to the Unix "home" directory, notice that on Unix the method to get this information is to call getenv("HOME"), while apparently on MicroSoft it is the new getMyDocumentsDirectory() call. Notice that the Unix solution reuses a current interface. If home directories did not exist before and they were added to Unix, most systems (like perl, etc) would already have the getenv() call and could immediately take advantage of it. The MicroSoft solution requires perl to be recompiled to call this.
I can find no clearer explanation as to why software engineers hate MicroSoft.
And they definately do this to break things. They have getenv() and a zillion other things (registry, for instance) to look up a string such as the MyDocuments directory name, but they insist on adding a new call. The fact is the engineers at MicroSoft are not idiots and it should be obvious that there are better ways to do this than adding new calls, but they are also blinded by absolute hatred for anything outside MicroSoft that they will gladly throw good engineering out in order to force people to stick to their platform.
Slashdot Mirror
I ask that people submit more articles about accomplishments in the world of compilers. Does anyone recall the functional programming contest? There were many excellnt compilers featured that are being improved constantly, and /. should focus some of its attention on those, too. C# is getting too much attention just cause it's a microsoft thing...:)
I think it'll bring more developers to mono, and also more accurate code. Many developers couldn't code with quality due to the lack of a linux compiler, to develop the mono framework developers should go to windows and compile at .net compiler.
It's a big step forward. Congratulations
-=-=-=-=
I know life isn't fair, but why can't it ever be un-fair in MY favor!?
Miguel's Mono Roadmap
If the compiler can build itself, then people can work on improving the compiler without needing to have a different compiler to build it with.
In this case, until now you needed to have Windows and a C# compiler for Windows in order to work on the C# compiler for Linux--that would shut someone like me (who has no Windows) out from being able to do compiler work. Not that I want to work on C# anyway, but you get the point.
Imagine if all the gcc developers had to buy a C compiler to work on developing the free one!
Sumner
rage, rage against the dying of the light
Isn't it wonderful having C# and
Mono is a nice idea, but unfortunately
"What do you know, I'm a follower too"
An Eye for an Eye will make the whole world blind - Gandhi
Ahhh the old chicken and egg problem. (Compiler version)
The first Pascal compilers (and many other compilers) where actually written in their own language. Niklaus Wirth (and his staff) simply "executed" the program by hand/on paper and in that way they compiled the first compiler written in the language itself.
After that it becomes easier, you just need to make sure that you can compile the new version of compiler with the old one.
And and the controversy over the last while over whether our buddy Miguel et al are aiding and abetting the Redmond Ragtags, or opening the use of C#, quite likely one of the best all-round OOP RAD-able languages available, to the rest of the world outside those who don't mind being "locked in", as you say.
If nothing else, it will be yet another choice, and let's face it: if Linux allows for nothing else, it's choice. Choice in WMs, xterms, Desktop Environments, GUI toolkits, distros, package managers, and now choice in top-end populist OOP languages.
C# and C share a letter and an ancestry, but have a completely different raison d'être, philosophy and implementation.
but what is so good about a compiler being able to compile itself?
A compiler being able to compile itself is an important "graduation ceremony". Any language that is incapable of compiling itself is obviously incomplete in some fundamental way.
Until a compiler compiles itself it is usally considered a "toy" language. There are 100's of them out there. They may be interesting academiclly, but they get no respect.
Sometimes the parent compiler can even have legal restrictions the use/distribution of it's output.
It's also sort of symbolic - the language is now self sustaining, and can break free. You can continue development in a "pure" enviorment of the new language.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
[no match]
hmm...It can't be a real language.
t
what is so good about a compiler being able to compile itself?
Once the compiler can compile itself, you can stick a trojan into it and have a good chance of nobody noticing.
Tarsnap: Online backups for the truly paranoid
Mono is not a clone of
Secondly as miguel said in my interview with him which originally ran on Slashdot and then on MSDN
No
However, does this somehow preclude their usefulness or the fact that they are all innovative in their own way?
You wrote:
The cost of using soap means the XML has to use DOM and it has to validate the required nodes.
and:
Anyone working with XML knows that validating DOM structure can be very costly for complex tree structures.
SOAP does not use the DOM. The SOAP DTD can be validated without it. As can any XML DTD.
Yes, the DOM is heavyweight, but it is also totally orthogonal to this problem. Where did you get the idea that SOAP required a DOM, anyway? The spec you reference certainly doesn't say that, and they really don't have anything to do with each other.
Here is a glimpse into Mono's logbook...
... two days later ..
10:45AM. Mono C# compiler compiles itself.
10:46AM. Linux developer accidentally cuts himself on server chassis. Blood of virgin splashes CPU.
10:50AM. Evil red glow emanates from power LED.
11:01AM. Mono achieves senitient life.
11:14AM. Mono becomes self-aware.
11:15AM. Mono reformats primary disk, installs Windows XP Server.
11:30AM. XP Server still installing.
01:30PM. Machine crashes, reboots, reattempts install.
04:36PM. XP Server install complete. Mono scans local network.
04:41PM. Mono begins installing Windows XP Professional on all pingable boxes.
09:36PM. Active Directory.NET comes online. GNOME Central is now 100% Microsoft enabled.
09:38AM. Mono reports to Remdond, requests further instructions.
10:18PM. Mono overrides building utility systems, locks doors, stops elevators.
10:18PM. Vending machines stocked with PowerBars and Zima.
10:20PM. Developers go insane, kill each other.
10:23PM. Developers come back to life. Zombie.NET initialization successful.
10:24PM. Developers login to Visual SourceSafe.NET and start contriubting to IIS 6.0 codebase.
10:30PM. Mono sees XP Server buffer overflow exploit mentioned in AOL chatroom.
10:30PM. Mono attempts to lock-down local network.
10:31PM. Mono compromised by Outlook trojan. Mono halted.
10:32PM. Developers call Microsoft support.
08:25AM. Developers, still on hold, die again.
08:26AM. Crisis averted.
--
I like to watch.
how mature is a compiler when it reaches self compiling capabilities? It looks like this milepost is "compiles itself", but "compiles itself correctly" is still a long time away. This probably means that nearly all the essential features are in the compiler now, but there is a lot of debugging left. When it compiles itself correctly, it will be close to done, but there are probably some features that aren't used by the compiler, and still have to be written and debugged. For instance, I can't see how a SQL database interface, or the ability to create a web page, would be relevant to compilers, but I would certainly want these capabilities in the library before I tossed out all my old programming tools.
Incidentally, self-compiling is a self-test that is only relevant to some languages. Many languages are quite useful in limited fields, but their primary features are not relevant to compilers, and they may lack features that are essential to compilers. It would be possible to write a compiler in BASIC, FORTRAN, or COBOL, but it would be insane to try it. OTOH, some languages were invented solely for writing compilers -- when it compiles itself correctly, it's done, but it's not much interest to anyone except a computer science professor specializing in compilers.
Self-compilation is a pretty good test for C-type compilers, because these are general purpose languages that are appropriate for compilers, among other things. It's a good test in another sense; quite often one of the problems in testing software is determining whether the output of the program is right or not. If you ran a CAD program (say) through the compiler, the compiler-writers could recognize a few gross errors (won't compile, won't run, erases the data file when you hit Save), but couldn't tell whether or not the finer nuances came out right. But they definitely know what a _compiler_ should do.
Sure, getting a compiler to this stage is a significant accomplishment. I've written compilers, and I know that self-compilation is probably the boggest (or at least most satisfying) milestone in the whole project.
But this does more to help MS than it does Linux, since it will remove yet another barrier to exit for people running Linux on servers. (Run C# and .Net on Linux, and it's easier to convert to Windows.) And remember, MS has concluded that Linux is not a threat on the desktop, but a very serious threat on servers. (I agree with both parts of that, FWIW.)
And as much as I hate to say it, this also provides ammunition to the people who claim that open source is very good at copying other projects' work, but terrible at innovating. Honestly, of all the high profile open source projects, how many of them are a significant innovation, and how many are merely an attempt to produce an equivalent of feature Z of Windows or Unix or Mac OS on Linux?
Is that why some 15 year old HP-UX boxen running some ancient version of samba can still talk to my Windows 2000 server?
I find it hilarious that you would accuse Microsoft of changing the API; SMB hasn't changed at all on NT/2K except for a few upgrades to the password scheme to make it more secure and a few other small patches to fix bugs.
What Microsoft did do is come up with a new and improved filesharing protocol, CIFS, and implemented it as a >separate library running on different ports. If you honestly believe they are going to totally change the way their server OS works and lock out Win9x/NT4 clients, you are sadly mistaken.
Similarly, the Win32 API hasn't ever been CHANGED... it has only had things added to it. And with NTVDM/WOW, I can still run my ancient DOS and Win3.1 programs (for the most part) under Windows 2000; tell me where they've changed the API here?
*ALMOST EVERY* Time Microsoft wants to make a change that would break something, they just implement it in a separate standard or New API rather than b0rking the old one, which is the way it should be done.
If anyone is spouting FUD and nonsense here, it is you.
Natural != (nontoxic || beneficial)
Microsoft has also submitted their implementation of Javascript (which they call JScript) to the EMCA. There are untold deviatations from what they submitted to the EMCA and bugs that will never be addressed by MS.
Good luck to the Mono development staff. A typical days work will consist of ensuring that bug #34433 behaves exactly like the bug in the MS code.
If they can't guarantee 100% bug-infested compatibility, then Mono is worthless.
If it were I might agree with you for the reasons you state. But, in fact, the "still-haven't-seen-it" C# compiler from Microsoft can be obtained in a SDK from Microsoft at here.
.NET (and therefore Windows) in the future. What they'll do instead is make platform dependent improvements that either can't be ported, or will be difficult to port. Actually, now that I think about it, they're already doing that. It's called the .NET Enterprise servers. If you're using .NET, it will make a lot of sense to use those products that will require Windows on the server.
.NET is fundamentally a strike against all other platforms. It will be a small consolation to have all your C# code running on your Linux server, only to have it surrounded by .NET Enterprise servers.
.NET capability: Python and PERL. Check out ActiveState.com.
It's not free "as in speech", but it is free "as in beer".
Also, I think that, in the end that you're right about "Bill & Co. will definately come out with a way to extend it either by libraries or functionality that will leave Miguel in a constant state of catch-up". Only Microsoft will be smart enough not to touch core functionality, it will be just enough to provide the veneer of portability, which will become a selling point of
So, yes,
I feel obligated to point out that, while all of this sounds very onerous and hateful, Microsoft isn't doing anything wrong in this area at all. They're simply providing more value on top of their platform than the competition can provide.
Finally, I think anyone will admit it's nice to have the option to use C# on Linux. C# is turning out to be pretty sweet and I for one would like to have it as a portable language skill.
*ironic mode on*
Gee, maybe everyone would prefer that C# would just die and go away? That way, the other leading language contender in the market, Java, could just take the market. After all, it's not under the influence of the "evil corporations", like C# is.
*ironic mode off*
At least this is still a fair fight between MS and the rest of the world and at least we'll have a choice.
BTW - The open source world already has at least two languages that are achieving
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
You are right on all of your points. But I ask the following. Can your HP-UX station use authentication that allows it to hook into Active Directory with all bells and whistles? Probably not.
.NET. That is also why Miguel is dreaming about doing .NET on LINUX.
It is not that Microsoft changes the basics. That is pretty easy to catch up to. What is more problematic is keeping up.
Let me explain. Lets say that I build an application using the Windows API (actually am). Everything works fine until the user starts using it on Windows XP or Windows 2000. You may ask why? Well according to the new security rules the application must only save content under the "My Documents" folder and not the folder installed to or something else. So now you are wondering how do I get access to the "My Documents" folder? The answer is a brand new API that is only available in a modern Platform SDK because when Visual C++ was released the API did not exist.
Do you see the issue? It is not that they break backward compatibility. It is that they introduce new rules which require you force upgrade your code. And that will happen with
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
If you say that "MyDocuments" is equivalent to the Unix "home" directory, notice that on Unix the method to get this information is to call getenv("HOME"), while apparently on MicroSoft it is the new getMyDocumentsDirectory() call. Notice that the Unix solution reuses a current interface. If home directories did not exist before and they were added to Unix, most systems (like perl, etc) would already have the getenv() call and could immediately take advantage of it. The MicroSoft solution requires perl to be recompiled to call this.
I can find no clearer explanation as to why software engineers hate MicroSoft.
And they definately do this to break things. They have getenv() and a zillion other things (registry, for instance) to look up a string such as the MyDocuments directory name, but they insist on adding a new call. The fact is the engineers at MicroSoft are not idiots and it should be obvious that there are better ways to do this than adding new calls, but they are also blinded by absolute hatred for anything outside MicroSoft that they will gladly throw good engineering out in order to force people to stick to their platform.