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...:)
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.
You may well be wrong about the functional languages.
It won't be long before the overheads of FP will be pretty negligible compared to the increased programmer productivity and software robustness. This advantage will gradually start to overcome inertia in the marketplace and start to make a real impact.
Also, with the incresing use of Virtual Machines as an execution platform it's going to get a lot easier to use functional languages and integrate them into larger projects. My bet is that something like Haskell will suddenly start to make headlines in the next couple of years on the.NET platform.
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
MagPulse
·
· Score: 3, Interesting
Horrible analogy. Being able to port C# programs written in VS.NET is only a part of the reason for Mono. And MS won't stray far from the ECMA standard, which is what the first release of VS.NET follows. It's taken until now to break free of some legacy "features" like incorrect for-scoping introduced way back in VC++ 4, just for backward compatibility.
Right now, all Linux has for standard middleware is CORBA. Sure there are Linux die-hards that will stand by CORBA, but most will agree that COM is superior. Now with Mono, Linux will finally have a decent object technology with which to build large OO projects that will work together.
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.
This might make it a bit more intriguing
by
f00zbll
·
· Score: 3, Offtopic
There have been several post in the last year about C#, but they were only mildly interesting (ie it only got me to read whitepapers, articles and sample code). Now that mono is progressing forward it is more interesting.
I don't remember all the differences between C# and Java, but it does make it more appealing. Unfortunately, SOAP is a bit heavy for the most simple web services (what ever it means to microsoft). The cost of using soap means the XML has to use DOM and it has to validate the required nodes. From W3C spec on SOAP, it states:
A SOAP message is an XML document that consists of a mandatory SOAP envelope, an optional SOAP Header, and a mandatory SOAP Body.
Anyone working with XML knows that validating DOM structure can be very costly for complex tree structures. For a simple document like SOAP, it's not bad until you realize it is intended for business to business processes, which could mean millions a day. The argument that SOAP is "as simple as it can/should be" ignores the fact that systems that would benefit from SOAP or other XML RPC (remote procedure calling) the most have complex distributed processes. Most of the.NET whitepapers I've read so far recycle ideas others developed. Microsoft's innovation was repackaging it as a platform.
It's too bad microsoft's whitepapers don't credit the orginal authors, since a lot of people worked to push XML forward. In some ways, it feels like SOAP and.NET is a bastardized version of Burners Lee's vision of a semantic web using XML web services and RDF. Perhaps all the press.NET has generated for XML services will help create the critical mass needed to get semantic web moving.
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.
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?
Cautionary Tale
by
devnullkac
·
· Score: 3, Interesting
Well, it's not a tale, really, but don't forget Ken Thompson's musings on the dangers of compiling compilers without knowing their full pedigree: the binary compiler can be a trojan horse factory that inserts weaknesses into programs it thinks should be targeted (e.g. "login"), including copying its trojan generation code into the next version of the compiiler.
-- What do you mean they cut the power? How can they cut the power, man? They're animals!
A compiler is basically a program which converts a program in a source language (A) to a target langage (B). The compiler itself is written in a language (C) which may or may not be equal to A or B.
Therefore lot of compilers can never compile themselves, since they are written in a langauage other than the one that they compile. I suspect, for example, that the Visual Basic compiler is written in C++, and therefore cannot self-compile.
In the case that A = C, the compiler can compile itself assuming that it supports a sufficiently large feature set from the language. This is the point that the Mono project has apparently reached. This is a decent achievement for a complex compiler, since it suggests that the project is getting near to being feature complete.
You could probably write a self-hosting toy compiler relatively quickly if that was your goal. Especially if you chose a "nice" target language, i.e. something like Scheme rather than x86 assembler.....
Warning: The above post is clueless
by
Carnage4Life
·
· Score: 3, Informative
Unfortunately, SOAP is a bit heavy for the most simple web services (what ever it means to microsoft).
SOAP is the standard protocol accepted INDUSTRY WIDE for web services. This is not just across companies from Microsoft to Sun to Oracle, etc. but across programming languages from C# to Java to Perl.
The cost of using soap means the XML has to use DOM and it has to validate the required nodes.
One does not need a DOM to validate an XML document. There are many validating SAX readers and in fact there also validating Pull-based XML APIs like Microsoft's XmlValidatingReader or XPP.
It's too bad microsoft's whitepapers don't credit the orginal authors, since a lot of people worked to push XML forward. In some ways, it feels like SOAP and.NET is a bastardized version of Burners Lee's vision of a semantic web using XML web services and RDF. Perhaps all the press.NET has generated for XML services will help create the critical mass needed to get semantic web [w3.org] moving.
Now it is clear you have no idea what you are talking about. The push for the semantic web is a push for a richer web experience by adding more meta data to the content of the web.
SOAP is a distributed computing protocol similar to predefined protocol the Internet Inter-ORB Protocol (IIOP) for CORBA, the Object Remote Procedure Call (ORPC) for DCOM, and the Java Remote Method Protocol (JRMP) for Java/RMI but defined in XML instead of a binary format.
Re:Warning: The above post is clueless
by
zulux
·
· Score: 3, Funny
The push for the semantic web [w3.org] is a push for a richer web experience by adding more meta data to the content of the web.
Uh ohh... You just said 'richer web experience.' Please, shut down the Balmer-Monkeyboy video and step away from the XP box. Put away the Microsoft Actimates Barney and refrain from using Microsoft products untill your marketing bullshit filter comes back on-line.
--
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
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
duffbeer703
·
· Score: 3, Informative
You are right and wrong.
Most Windows 2000 implementations run in compatability mode to allow legacy NT 3.51/4.0 and Windows 9x clients to connect.
If Windows 2000/Active Directory is running in native mode, these clients will be unable to connect. Many of the more advanced features of AD can only work in native environments.
-- Conformity is the jailer of freedom and enemy of growth. -JFK
You can load code dynamically into your application . You can even generate code on the flight and execute it (with System.Reflection.Emit).
C# does not have inner classes, but it has delegates, which can be thought as closures. They basically encapsulate a method plus its object.
Miguel.
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.
I don't remember all the differences between C# and Java, but it does make it more appealing. Unfortunately, SOAP is a bit heavy for the most simple web services (what ever it means to microsoft). The cost of using soap means the XML has to use DOM and it has to validate the required nodes. From W3C spec on SOAP, it states:
Anyone working with XML knows that validating DOM structure can be very costly for complex tree structures. For a simple document like SOAP, it's not bad until you realize it is intended for business to business processes, which could mean millions a day. The argument that SOAP is "as simple as it can/should be" ignores the fact that systems that would benefit from SOAP or other XML RPC (remote procedure calling) the most have complex distributed processes. Most of the .NET whitepapers I've read so far recycle ideas others developed. Microsoft's innovation was repackaging it as a platform.
It's too bad microsoft's whitepapers don't credit the orginal authors, since a lot of people worked to push XML forward. In some ways, it feels like SOAP and .NET is a bastardized version of Burners Lee's vision of a semantic web using XML web services and RDF. Perhaps all the press .NET has generated for XML services will help create the critical mass needed to get semantic web moving.
[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?
Well, it's not a tale, really, but don't forget Ken Thompson's musings on the dangers of compiling compilers without knowing their full pedigree: the binary compiler can be a trojan horse factory that inserts weaknesses into programs it thinks should be targeted (e.g. "login"), including copying its trojan generation code into the next version of the compiiler.
What do you mean they cut the power? How can they cut the power, man? They're animals!
A compiler is basically a program which converts a program in a source language (A) to a target langage (B). The compiler itself is written in a language (C) which may or may not be equal to A or B.
Therefore lot of compilers can never compile themselves, since they are written in a langauage other than the one that they compile. I suspect, for example, that the Visual Basic compiler is written in C++, and therefore cannot self-compile.
In the case that A = C, the compiler can compile itself assuming that it supports a sufficiently large feature set from the language. This is the point that the Mono project has apparently reached. This is a decent achievement for a complex compiler, since it suggests that the project is getting near to being feature complete.
You could probably write a self-hosting toy compiler relatively quickly if that was your goal. Especially if you chose a "nice" target language, i.e. something like Scheme rather than x86 assembler.....
Unfortunately, SOAP is a bit heavy for the most simple web services (what ever it means to microsoft).
.NET is a bastardized version of Burners Lee's vision of a semantic web using XML web services and RDF. Perhaps all the press .NET has generated for XML services will help create the critical mass needed to get semantic web [w3.org] moving.
SOAP is the standard protocol accepted INDUSTRY WIDE for web services. This is not just across companies from Microsoft to Sun to Oracle, etc. but across programming languages from C# to Java to Perl.
The cost of using soap means the XML has to use DOM and it has to validate the required nodes.
One does not need a DOM to validate an XML document. There are many validating SAX readers and in fact there also validating Pull-based XML APIs like Microsoft's XmlValidatingReader or XPP.
It's too bad microsoft's whitepapers don't credit the orginal authors, since a lot of people worked to push XML forward. In some ways, it feels like SOAP and
Now it is clear you have no idea what you are talking about. The push for the semantic web is a push for a richer web experience by adding more meta data to the content of the web.
SOAP is a distributed computing protocol similar to predefined protocol the Internet Inter-ORB Protocol (IIOP) for CORBA, the Object Remote Procedure Call (ORPC) for DCOM, and the Java Remote Method Protocol (JRMP) for Java/RMI but defined in XML instead of a binary format.
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"
You are right and wrong.
Most Windows 2000 implementations run in compatability mode to allow legacy NT 3.51/4.0 and Windows 9x clients to connect.
If Windows 2000/Active Directory is running in native mode, these clients will be unable to connect. Many of the more advanced features of AD can only work in native environments.
Conformity is the jailer of freedom and enemy of growth. -JFK
You can load code dynamically into your application . You can even generate code on the flight and execute it (with System.Reflection.Emit).
C# does not have inner classes, but it has delegates, which can be thought as closures. They basically encapsulate a method plus its object.
Miguel.
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.