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."
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!?
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: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.
Re:a dumb question
by
cperciva
·
· Score: 5, Insightful
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.
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?
No C# is getting attention because it is part of.NET (or at least an language binding for the common language runtime, the basis of.NET), and lots of people give a damn about.NET and think it has significance (either bad or good). Not many people care about new compilers for functional languages that will never get above %0.01 acceptance. Actually, I would rather Slashdot *not* post frivolous stories about every compiler on earth.
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.
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 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!?
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
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.
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
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?
No C# is getting attention because it is part of .NET (or at least an language binding for the common language runtime, the basis of .NET), and lots of people give a damn about .NET and think it has significance (either bad or good). Not many people care about new compilers for functional languages that will never get above %0.01 acceptance. Actually, I would rather Slashdot *not* post frivolous stories about every compiler on earth.
It's 10 PM. Do you know if you're un-American?
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.
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.