Mono C# Compiler Compiles Itself

Th is is a serious question (slighty OT) by nervlord1 · 2002-01-03 23:44 · Score: 0

i remmeber reading an ad on the web saying it would tell you if c# is going to "be just another visual basic", when i went in there, the article just crapped one, can anyone please awnser me for this, if the gnome developer is taking it seriously im sure its very good but i want other opinions. Cheers Peter

--
Microsoft IIS is to webserving as KFC is to healthy eating

Re:Th is is a serious question (slighty OT) by Anonymous Coward · 2002-01-04 02:09 · Score: 1, Informative

I don't know why anyone would call it "just another visual basic". It's a C++/Java like language. What makes it interesting is that it's interpreted by a virtual machine, and mixing matching langages is easy. You can have a class, with the methods written in C#. Then you can inherit that class in VB. I think there's also a perl .net implementation.
Re:Th is is a serious question (slighty OT) by jmccay · 2002-01-04 05:42 · Score: 1

Just because a gnome developer is taking it seriously doesn't mean it is good. There is a lot of money to be made down the road with the whole .NET setup (internet applications), but the trick will be to get people to buy into paying for somehting that doesn't reside on your computer.
As for C#, I am not going to bother. Microsoft lost it's java case against Sun and now it is acting like a spoiled little baby and releasing it's own technology. I don't know anyone interested in learning it--especially given Microsoft's track record with propritary technology. I doubt C# will ever be public domain.

--
At the next eco-hypocrisy-meeting, count the private jets used to get to the meeting. Should be interesting to see that
Re:Th is is a serious question (slighty OT) by Anonymous Coward · 2002-01-04 07:08 · Score: 0

Great use of the run-on sentence!
Re:Th is is a serious question (slighty OT) by toriver · 2002-01-04 10:30 · Score: 1

As for C#, I am not going to bother. Microsoft lost it's java case against Sun and now it is acting like a spoiled little baby and releasing it's own technology. I don't know anyone interested in learning it--especially given Microsoft's track record with propritary technology. I doubt C# will ever be public domain.
Actually, it would be interesting for people accustomed to Delphi: Java is "Simplified C++ with a useful library", C# is "Simplified C++ with Delphi-like extensions".

good news, by betanerd · 2002-01-03 23:44 · Score: 0, Redundant

A Viable alternatve to Micro$oft is a very good thing

--
Insert sig here (slashdot) Insert cig here (Lewinsky)

Re:good news, by Ace+Rimmer · 2002-01-03 23:48 · Score: 2, Insightful

It depends on how this C# is intended to be use. If it is only to leech from MS .net it's not an alternative - you'll still be tied to MS thoughts of a row ahead...

--
:wq

Not the same as self-flagellation... by Snard · 2002-01-03 23:48 · Score: 0, Offtopic

... but perhaps the same as doing something else all by yourself, when no one's around?

--
- Mike

I haven't heard good things about C# by gmplague · 2002-01-03 23:48 · Score: 0, Redundant

I haven't heard very good things about C#, but this is a huge accomplishment none the less. Hats off to Miguel.

--
__________________________________________
Take comfort in your ignorance.
Grandmaster Plague

Re:I haven't heard good things about C# by Crimplene+Prakman · 2002-01-03 23:51 · Score: 2

I have heard good things about C# - it's apparently got all the good bits of Java, with some nice additions that would have made sense the first time :-)
There are some dodgys, but they have more to do with the platform than the language.
Re:I haven't heard good things about C# by Anonymous Coward · 2002-01-04 00:01 · Score: 0

Good things?
It's just another Microsoft's attempt to lock in the users.
Re:I haven't heard good things about C# by Anonymous Coward · 2002-01-04 00:03 · Score: 0

If it's good technology, then it's worthwhile. If they keep tied to only windows, then it sucks balls.
Re:I haven't heard good things about C# by Ace+Rimmer · 2002-01-04 00:05 · Score: 2, Insightful

Well if one needs to develop a new language why, for God's sake, must everyone reimplement language at the nearly-the-same level as C?

And (unlike C), most of this so-called-portable languages use a stack VM machine. We don't know much about optimizing it in hardware and we don't have compilers capable doing that.

Guess why ppc (which is slower than most x86 in real apps) wins in float SPECs that much. Guess why hammer and p4 have sse2. Hint - 80387 design ... which is ... yes you got it.

--
:wq
Re:I haven't heard good things about C# by Crimplene+Prakman · 2002-01-04 00:24 · 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 · 2002-01-04 00:27 · 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:I haven't heard good things about C# by Ace+Rimmer · 2002-01-04 01:24 · Score: 1
Of course it's similar to Java. My comment could apply to Java as well.
- It's not trully OO language - for example types - once you use a standard integer you can forget above doing OO above it. You'd have to use a standard object integer type (which is included) but nobody uses it (speed reason). It's kinda procedural language (not quite but ...)
- There are many similar-to-c type conversions...
- Data structures builtins? (String handling? Dictionaries? Weighted trees?) Oh,...
- More but I don't want to start flamebait here ...
If C/Java is mice/elefants what about Python,Smalltalk,Prolog,Mercury? Aliens?

At least java had RMI which was a great step ahead in terms of higher level of language. C# lacks this again ...
--
:wq
Re:I haven't heard good things about C# by PythonOrRuby · 2002-01-04 02:11 · Score: 0, Offtopic

Python,Smalltalk...

...Ruby
Re:I haven't heard good things about C# by Anonymous Coward · 2002-01-04 02:31 · Score: 1, Insightful

taken from http://www.sys-con.com/java/article.cfm?id=1259

"When BEA Systems, IBM, HP, Borland, Oracle, and Sun Microsystems combine forces, there can only be one reason...and it isn't just mutual admiration.

This "Six Pack" of software giants has just joined the so-called Open Mobile Architecture initiative, or OMA, under the terms of which these global companies, inspired by the lead of Finnish phone dynamo Nokia last month, now agree to work together to facilitate the creation of mobile services - by standardizing how mobile devices connect to the Internet.

One notable giant is missing from the OMA line-up to date...Microsoft Corp."

I respect gnome guys but still dont know why not go
with java that was tons of support from big companies.
We see more and more alliances agains Microsoft.Why are open source community chasing Microsoft ?

ctyu
Re:I haven't heard good things about C# by Anonymous Coward · 2002-01-04 03:08 · Score: 0

well, I have heard at least one good thing about C#. It optimizes tail calls! (very important for recursive algorithms). Java does not do this (yet, although they do promise it in the future :) )
Re:I haven't heard good things about C# by Jabes · 2002-01-04 05:23 · Score: 1

It's not trully OO language - for example types - once you use a standard integer you can forget above doing OO above it. You'd have to use a standard object integer type (which is included) but nobody uses it (speed reason). It's kinda procedural language (not quite but ...)

This isn't true. C# and the common runtime language uses a system called boxing to translate value types (like integers etc) into the generic objects when needed. So you get the speed of value types with the flexibility of any type being able to be represented as an object.

Best wishes
James
Re:I haven't heard good things about C# by Anonymous Coward · 2002-01-04 07:54 · Score: 0

C#, quite likely one of the best all-round OOP RAD-able languages available
Whaaaaaaaaaaaat? Well, I guess if you define "best" as proprietary, immature, incomplete, not supported by 3rd party tools, and expensive...
Re:I haven't heard good things about C# by SoftwareJanitor · 2002-01-04 08:49 · Score: 2

I respect gnome guys but still dont know why not go with java that was tons of support from big companies.

Perhaps because IBM and others are already working on Java for Linux, as well as official Java SDK support from Sun for Linux. I look at what the Gnome guys are doing more from the bet hedging aspect than anything else. The open source community can probably afford to work on two things at once more than a company could. That being said, I am still looking at the whole thing with a certain degree of suspicion.

Request by Anonymous Coward · 2002-01-03 23:49 · 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...:)

Re:Request by spottedkangaroo · 2002-01-04 01:10 · Score: 1

I would personally really like to see a whole section for this. There's what, like 10 million compilers out there? Not all the articles would have to go to the front page... I really enjoy the sience section for instance...

--
Imagine if you weren't allowed to use roads because a bus company complained about your driving 3 times. --skunkpussy
Re:Request by Hard_Code · 2002-01-04 02:27 · Score: 3, Insightful

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?
Re:Request by Anonymous Coward · 2002-01-04 02:43 · Score: 0

I don't think your assessment of functional languages eventual acceptance is correct. Functional languages tend to carry a bit more overhead with their increased power. I think that as computers become more powerful, so will the tools that programmers use to program them. I think functional languages will eventually gain acceptance because of their increased power in abstraction and other areas. Their extra overhead with be discounted because of the computers increased computational power..
Re:Request by mikera · 2002-01-04 03:32 · Score: 3, Interesting

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.
Re:Request by boltar · 2002-01-04 04:18 · Score: 0

Functional languages will never become popular because they don't mimic the way people think.
Procedural languages with their do A, then B, then C do. And lets face it your average 1GHz
PC is more than powerful enough to run a functional language. If those sorts of language
were going to make any sort of impact outside of research labs they would have done so by now.
Re:Request by Anonymous Coward · 2002-01-04 06:48 · Score: 0

the way which people think?

I, for one, tend to be more productive in a functional language, and studies have shown that students introduced to functional languages first are often more productive in a functional language than students introduced to imperative languages first are in their imperative language.
Re:Request by mrpotato · 2002-01-04 08:22 · Score: 1

I'd bet on Scheme too, for example Parrot (perl6 vm) already got an implementation of Scheme running on it. Scheme + Perl6 will rock my world.

--

cheers
Re:Request by Tony-A · 2002-01-04 12:06 · Score: 1

Yes, the way people think.
And yes, functional is more productive than procedureal. Composition of functions is associative, so you can sometimes see shortcuts.
Functional concentrates on what is to be done.
Procedural concentrates on the steps required to do it.
Functional is f(g(h(foo(bar))).
Procedural is take bar, then foo it, then h, then g, then f it.
Process file in procedural is CLOSE-FILE( Do-STUFF-in-Middle( Open-File)))
Procedural is prog-style LISP.
Functional is LISP without any variables.
You can do functional in procedural languages (with the possible exception of bare Assembler)
You can do procedural in probably all functional languages.
There are other stunts possible like data-binding.
Functional is nested 30-deep in function calls (ie shallow)
Procedural in the extreme is a Finite State Automaton loaded with gotos.
Program counter is very meaningful in Procedural.
Program counter can be almost all noise in Functional.
Re:Request by mikera · 2002-01-07 02:56 · Score: 1

True, Scheme a great language. Haven't used it much apart from skimming through SICP though :-)

If I remember correctly, Scheme doesn't have types or lazy evaluation? They are the two main reasons I would go for Haskell right now.

More developers to mono by famazza · 2002-01-03 23:55 · 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!?

Mono Roadmap by Shanes · 2002-01-03 23:56 · Score: 5, Informative

Miguel's Mono Roadmap

a dumb question by rm-r · 2002-01-03 23:56 · Score: 1

ok, some people are going to think I'm a complete idiot for asking this, and I may need that flame-proof hat... but what is so good about a compiler being able to compile itself?

--

J-aims
--
Yo, whatever happened to peas? Join T( H)GS

Re:a dumb question by Anonymous Coward · 2002-01-04 00:00 · Score: 1, Insightful

From a software development stance, it's basically just a fundamental benchmark to show that the code is solid, and the language is mature.

Obviously, it's not magic: you won't get a Lisp compiler that was written in C to compile itself, ever.
Re:a dumb question by pthisis · 2002-01-04 00:03 · 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
Re:a dumb question by Anonymous Coward · 2002-01-04 00:03 · Score: 0

It simply means that a compiler is good enough to compile "real" source code, not just toy examples.
Re:a dumb question by Yokaze · 2002-01-04 00:03 · Score: 1, Redundant

It doesn't rely on another (namely the MS C#-compiler) anymore.

The C#-Compiler is written in C#, therefor requires a C#-Compiler.

--
"Between strong and weak, between rich and poor [...], it is freedom which oppresses and the law which sets free"
Re:a dumb question by deltavivis · 2002-01-04 00:11 · Score: 2, Interesting

this just means that they have a compiler on their target platform that can compile the source code to the compiler. To compile something just means to put the high level language into a form that the metal+OS can deal with it. SO, by compiling the compiler on the target platform they are demonstrating that they have an effective compiler for at least that subset of the language that is used to write the compiler.

how do you think new versions of gcc get compiled anyway?
Re:a dumb question by Anonymous Coward · 2002-01-04 00:30 · Score: 0

In pracatice Lisp compilers are written in Lisp, or otherwise you'd have to make a separate interpreter to get the macro system work. On the other hand, Symbolics Lisp machines had a C compiler written in Lisp...
Re:a dumb question by Alsee · 2002-01-04 00:30 · 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 ymgve · 2002-01-04 00:37 · Score: 1

It means the compiler has reached its Break-even-point, which is a very important milestone in compiler/language developement.
Re:a dumb question by Anonymous Coward · 2002-01-04 00:42 · Score: 1, Interesting

I have another (dumb?) question about compilers. I remember once reading a statement saying that one of the keys to understanding how compilers work is to be able to write a program that prints it's own source code. Does anybody out there know how to do this?

I thought about it and kept hitting the same road block. I would write a program that looks like the following psudo-code:

#include stdio.h

int main()
{
printf("

#include stdio.h

int main()
{
printf(^INFINTE SERIES^); //This is the problem.

return 0;
}");

return 0;
}

I know there must be a way to short-hand the Infinte Series that occurs in the print statement, but for the life of me I can't figure out what it is.

Any insight would be help ease my troubled mind.

I know someone might mod this OT. But I figure, "Where's the harm?". And besides what is so wrong with a conversation naturely progressing and going off in a slightly diffrent but related direction?
Re:a dumb question by jejones · 2002-01-04 00:45 · Score: 2

Not a dumb question at all. As others have pointed out, if you user your own (software) tools, then you're that much more motivated to fix them when they break. Also, a compiler is a Big Program, and likely to exercise itself in ways that small sample programs from C# for Dummies and the like won't. The wider the variety of programs you can test a compiler with, the better--another canonical stress test for compilers is the output of program generators, which will do things humans typically won't. (Canonical example: parser generators like yacc, which churns out basically a for loop around a HUGE switch statement and a really big initialized array.)
Re:a dumb question by Anonymous Coward · 2002-01-04 00:50 · Score: 0

Silly question... has anyone written javac in java?
Re:a dumb question by cperciva · 2002-01-04 00:51 · 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.

--
Tarsnap: Online backups for the truly paranoid
Re:a dumb question by Anonymous Coward · 2002-01-04 00:58 · Score: 0

I was under impression that the Sun's Java compiler is indeed written in Java..?
Re:a dumb question by psamuels · 2002-01-04 00:59 · Score: 1

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.

Or just unsuited for writing compilers in. The gcc Fortran compiler is not written in Fortran, because C is a better language for that and the gcc developers know a C compiler will be available to build g77.

Apparently the Mono people decided to use C# for implementation even though it is interpreted (and JIT compiled) - an interesting decision IMO.

--
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
Re:a dumb question by Anonymous Coward · 2002-01-04 01:00 · Score: 0

Visit the quines page at http://www.nyx.net/~gthompso/quine.htm, it has source for self-printing programs in over 60 languages!
Re:a dumb question by Anonymous Coward · 2002-01-04 01:01 · Score: 0

The java language has built-in limitations that would prevent this. Also, what's the point? Java is a language that is equally poor on all platforms.

SCJP
Re:a dumb question by GigsVT · 2002-01-04 01:11 · Score: 1

Holy shit man, thanks for the link. I had not thought of that particuilar method of compiler binary trojaning. Kinda makes you wonder about how you can trust anything, open source or not!

Time to start disassembling all those sensitive programs and looking for suspicious JMPs :)

--
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Re:a dumb question by Anonymous Coward · 2002-01-04 01:31 · Score: 0

You used to be able to call it from a java program directly. It was somewhere under sun.* but I can't remember where exactly. It might just have been a thin interface to the real compiler in c.

Probably all changed by now since that was with 1.0
Re:a dumb question by Joseph+Vigneau · 2002-01-04 01:35 · Score: 1

The java language has built-in limitations that would prevent this. Also, what's the point? Java is a language that is equally poor on all platforms.
What is a Java compiler? It is a program that converts Java source code into a byte stream. You're claiming that you can't write a program in Java that can do this? The "javac" program that ships with the JDK is such a program...
Re:a dumb question by Scooter · 2002-01-04 01:41 · Score: 2, Insightful

Hmm interesting article - but having the compiler compile itself does not help you to do this - you could introduce such trojans to the compiler and then compile it with some other compiler - the result would be the same.
Re:a dumb question by Anonymous Coward · 2002-01-04 01:54 · Score: 0

Silly question... has anyone written javac in java?
It certainly could be done, but it would be far to slow to be usefull, thus they write them in C.
Re:a dumb question by Anonymous Coward · 2002-01-04 02:00 · Score: 0

What is a Java compiler? It is a program that converts Java source code into a byte stream. You're claiming that you can't write a program in Java that can do this? The "javac" program that ships with the JDK is such a program...
Right. That's why it takes an hour for it to "spool up" and run. Java the language (which is great) would be much more functional if java (the implementation) didn't suck so bad in many areas.
Re:a dumb question by bittmann · 2002-01-04 02:07 · Score: 2, Interesting

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.

...kind of like the COBOL compiler that's been putting food on my table for the past decade-and-a-half...Although I'm not certain I would call it "interesting"...and the academic applications are questionable...I certainly agree that I get no respect!

(grin)

Seriously, though...IMO, the best indication of the importance of a complier is in how many lines of code/how many executables the compiler has been used to...compile..., and not necessarily any artifical metric.

That being said, I'll consider Mono's C# implementation a success if and only if it will allow a sizable chunk of C# sourcecode to be *used* on non-Microsoft platforms. Anything less, and it becomes at best "just another Java", only not as portable.

Miguel has now produced a "real compiler"...but I still think the jury's out on it becoming a "real success." I'm rooting for them, though!
Re:a dumb question by jtdubs · 2002-01-04 02:41 · Score: 2

Haha. That's a very interesting topic. And it has two basic kinds of solutions. You have to end up using the data as code, or using the code as data. Regardless, the kind of program you are talking about is called a quine. Yes, a quine. If you google it you should get some good tutorials. Hehe. Oh the memories. Have fun,

Justin Dubs
Re:a dumb question by ReelOddeeo · 2002-01-04 02:41 · Score: 2

My (untested) solution.

First I'll define some terms. The "Program" is the whole thing. It consists of two major components, the "Code" and the "Data". Both the Code and the Data are written in the language of the Program. The "Payload" is some more code that is reproduced along with the Code, but is not used in printing the entire Program.

The Program starts out with a bunch of data declarations which are the Data. In C, this could be an array declaration with an initializer which contains a bunch of static strings. Then after the Data (in this example, a huge array declaration) comes the Code.

The way the Code works is that it has two sections, one that prints the Data declarations, using the Data declarations; and, a second section that uses the Data to print the Code.

Obviously, the Data is a bunch of strings which make up the source code of the Code and the Payload, but not the entire Program.

I hope this explanation is clear. I haven't actually implemented it, but the explanation should tell you how to do it in a fairly language-neutral way. I hope this wasn't your homework assignment. I hope I didn't make some major blunder due to insufficient caffine. If I have, I'm sure someone here will embarrass me or mod me as Stupid (-2) or something. I don't think you need to understand this to understand compilers. But understanding this is one element necessary to understand how to trojan a compiler's source code so that when the unmodified source of the compiler is recompiled using the compiler, that the trojan is inserted into the binary output (a new compiler), even though the trojan is no longer present in any of the compiler's source code. The Payload is then useful to further trojan the compiler such that when it compiles the source to the login program, it compiles in a back door, even though the source to the login program has no back door.

Can someone who has had more caffeine plese provide a link to the famous article describing this before I scream.

--

Those who would give up liberty in exchange for security and DRM should switch to Microsoft Palladium!
Re:a dumb question by wadetemp · 2002-01-04 02:50 · Score: 2, Interesting

Until a compiler compiles itself it is usally considered a "toy" language

Does Perl compile itself? Nice toy.
Re:a dumb question by ReelOddeeo · 2002-01-04 02:56 · Score: 2

The java language has built-in limitations that would prevent this. Also, what's the point? Java is a language that is equally poor on all platforms.

There is nothing particularly poor about the language. But that is a matter of opinion. The language certianly has lots of great features, from a certian perspective. Perhaps the implementations are equally poor, but I disagree with this premise also. Some implementations are not so poor as others.

--

Those who would give up liberty in exchange for security and DRM should switch to Microsoft Palladium!
Re:a dumb question by howardjp · 2002-01-04 03:03 · Score: 1

Okay, there have been quite a few answers here that are wrong. The javac Sun itself ships is written in Java. Sign up and download the source code. It is a fun read.
Re:a dumb question by howardjp · 2002-01-04 03:05 · Score: 0, Flamebait

Yes, Perl is a toy language. There is nothing useful that can be done in Perl that cannot be done better in C, Bourne, or PHP.
Re:a dumb question by ReelOddeeo · 2002-01-04 03:15 · Score: 2

but having the compiler compile itself does not help you to do this - you could introduce such trojans to the compiler and then compile it with some other compiler - the result would be the same.

You miss a critical point. Doing as you suggest requires that you keep the trojan in the source code of the compiler. With an open-source compiler, that trojan is in the source in front of God and everyone, plain for all to see.

Much better is to get the binary of the compiler trojaned in such a way that it will re-trojan subsequent compilations of the compiler; but the compiler source code has no evidence of a trojan.

--

Those who would give up liberty in exchange for security and DRM should switch to Microsoft Palladium!
Re:a dumb question by mikera · 2002-01-04 03:23 · Score: 2

There are quite a few Java compiler implementations other than the Sun reference version.

The IBM Java compiler (Jikes) is much much faster than javac, for example, and does exactly the same job.
Re:a dumb question by Anonymous Coward · 2002-01-04 03:26 · Score: 0

Is C++ a toy ? I haven't perused the compiler on gnu systems, but I would imagine it is in C.

Better is relative... save some CPU cycles by using C but take a month longer to get there.
Re:a dumb question by Paradise+Pete · 2002-01-04 03:37 · Score: 0

you could introduce such trojans to the compiler and then compile it with some other compiler - the result would be the same.

No it wouldn't. Then you'd have to have the trojan in the source. Thompson's point is that once you've "taught" the compiler about the trojan you can remove it from the source code and still have it inserted in new versions of the compiler. This requires, of course, that you don't use some other compiler to build it.
Re:a dumb question by arkanes · 2002-01-04 03:52 · Score: 1

It's trivial in perl :P But I don't think that was really the answer you wanted.
Re:a dumb question by elefantstn · 2002-01-04 03:56 · Score: 2

It's a standard part of the class library, I think. JSP's are converted to servlets and then compiled the first time they are run.

--
If it ain't broke, you need more software.
Re:a dumb question by arkanes · 2002-01-04 04:00 · Score: 1

Well, we don't really want to start a Perl flamewar, but your statement is untrue for many values of "better". Also, you can certainly write a perl compiler in perl. it's been done, in fact. You might even be able to write a perl interpeter in perl, but that'd just be wacky.
Re:a dumb question by mini+me · 2002-01-04 04:01 · Score: 1

What do you mean? It's simple! ;)

#!/usr/bin/perl
open(CODE, "$0");
print <CODE>;
close(CODE);
Re:a dumb question by coug_ · 2002-01-04 04:09 · Score: 2, Interesting

Any language that is incapable of compiling itself is obviously incomplete in some fundamental way.

You might want to be a little more specific here for those who don't know the difference between interpreted and compiled languages. Interpreted languages (Java, Perl, Python, etc.) won't compile themselves. Before all the Java programmers jump all over me.. yes, Java is "compiled", but the output is not a machine-code executable, it's bytecode that is interpeted by the JVM.
An interesting thought - In theory the Java compiler could be implemented using a JVM and a "Compiler" bytecode...
java com.sun.JavaCompiler1_2 com/sun/JavaCompiler1_3.java
Hmmm....
Re:a dumb question by Alsee · 2002-01-04 04:10 · Score: 2

Or just unsuited for writing compilers in. The gcc Fortran compiler is not written in Fortran, because C is a better language for that

I never said that every implementation of a compiler must be compiled by itself. I said:
A compiler being able to compile itself is an important "graduation ceremony"
I'm sure that someone somewhere has compiled a fortran compiler with a fortran compiler. Fortran is Turing complete. That means it can do anything any other Turing complete language can.

In an adjacent post someone mentioned Perl. I don't know much about Perl, but I'd hazzard a guess that it is also Turing complete, and therefore capable of compiling itself.

-

--
- - 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 ideut · 2002-01-04 04:42 · Score: 0

And we all know how sh is self-hosted. Dear oh dear. And PHP is also written in c. Both toys?

--
--
Re:a dumb question by ideut · 2002-01-04 04:49 · Score: 0

Interpreted languages (Java, Perl, Python, etc.) won't compile themselves.

There is absolutely no fundamental reason why this should be the case (though it often is). You are making an arbitrary and irrelevant distinction between "compiled" and "interpreted". Watch out for perl.. rumours are that it will soon be self hosting. As noted elsewhere in these comments, Sun's javac is written in java.
The only real requirement for a language to be self hosting is that it is Turing complete.

--
--
Re:a dumb question by puetzk · 2002-01-04 05:00 · Score: 2, Redundant

except that perl's not compiled :-) But yes, I think a perl interpreter in perl would be very easy.

open FILE,";
eval $code;

--
The Matrix is going down for reboot now! Stopping reality: OK. The system is halted.
Re:a dumb question by puetzk · 2002-01-04 05:06 · Score: 2

bleh, /. eat's <> when in plain old text? eww..
trying again.

except that perl's not compiled :-) But yes, I think a perl interpreter in perl would be very easy.

open FILE,"<$ARGV[0]";
$code = <FILE>
eval $code;

--
The Matrix is going down for reboot now! Stopping reality: OK. The system is halted.
Re:a dumb question by Alsee · 2002-01-04 05:10 · Score: 2

he difference between interpreted and compiled languages. Interpreted languages (Java, Perl, Python, etc.) won't compile themselves.

Pick pick pick pick pick.
(Don't mind me, I'm just irritated at the other posters who can't grasp the difference between me saying a language should be ABLE to complile itself, and every compiler MUST have been complied by itself.)

Ok, interperted languages symbolicly "graduate" when someone writes an interperter for that language in that language.

Coug - I know you get it, but for everyone else:
The point of the "graduation ceremony" is that someone demonstrates that (A) the language is complete enough for a significant task, (B) practical enough to actually write a significant task in it, and (C) functional enough to actually execute a significant task.

Toy languages fail either (A) completeness, (B) practicality, or (C) functionality.

-

--
- - 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 Sumocide · 2002-01-04 05:55 · Score: 1

Someone please add this to the Karmawhoring Guide: Whenever there's an article concerning compilers linke to the said ACM article, whoopy instant +5.
Re:a dumb question by Anonymous Coward · 2002-01-04 05:59 · Score: 0

Or just this:

#!/bin/cat
Re:a dumb question by Beatlebum · 2002-01-04 06:58 · Score: 1

OK. I am hereby releasing my new language. It is called "SuperLooper" and has a single instruction with no operand:

10: loopit!

Late last night the SuperLooper compiler was able to compile itself (since every SuperLooper program consists of a single instruction - "jmp" in x86, this was not too difficult). I'm working on ports to other processors.

Until the compiler was able to compile itself SuperLooper was indeed a toy language. SuperLooper has now arrived!
Re:a dumb question by Hornsby · 2002-01-04 07:42 · Score: 1

not quite... that would only read the first line of FILE. don't forget about the record separator variable, $/. correct code is as follows.

$/++;
open(FILE, "$ARGV[0]") || die("No input: $!");
$code = <FILE>;
eval $code;
close(FILE);

not trying to be a know-it-all... but it's important for such interpreters to work correctly.

--
A musician without the RIAA, is like a fish without a bicycle.
Re:a dumb question by Anonymous Coward · 2002-01-04 08:13 · Score: 0

> You miss a critical point. Doing as you suggest requires that you keep the trojan in the source code of the compiler. With an open-source compiler, that trojan is in the source in front of God and everyone, plain for all to see.

...and the last time that you reviewed (say) the gcc sources for such trojans was?...

...and the last time that the gcc team reviewed the gcc sources for such trojans was?...

Lots of sourcecode, lots of places to hide a modularly-designed trojan.
Re:a dumb question by Anonymous Coward · 2002-01-04 08:15 · Score: 0

> Apparently the Mono people decided to use C# for implementation even though it is interpreted (and JIT compiled) - an interesting decision IMO.

They'll flush out a Lot of bugs in the various runtimes & class libraries by doing the initial compiler development this way. A compiler's a complicated beast. A production compiler can always be done in C later on.
Re:a dumb question by Anonymous Coward · 2002-01-04 08:23 · Score: 0

> You might want to be a little more specific here for those who don't know the difference between interpreted and compiled languages. Interpreted languages (Java, Perl, Python, etc.) won't compile themselves. Before all the Java programmers jump all over me.. yes, Java is "compiled", but the output is not a machine-code executable, it's bytecode that is interpeted by the JVM.

Considering that the first javac compiler was included in one of the sun.* packages and was written in Java, I'd say you're dead wrong.

As for the javac output being JVM bytecode and not "real" machine language, what difference does that make to the compiler's ability to generate object code?
Re:a dumb question by Anonymous Coward · 2002-01-04 08:33 · Score: 0

And you'll note that Jikes is not written in java. Put that in your "Java JITs are as fast as C++" pipe and smoke it.
Re:a dumb question by damiam · 2002-01-04 08:51 · Score: 1

Better pseudocode:
main
{
//program opens code file and prints it
file sourcefile = open_file("sourcecode.whatever")
print(sourcefile)
close_file(sourcefile)
}
Maybe this is cheating though...

--
It's hard to be religious when certain people are never incinerated by bolts of lightning.
Re:a dumb question by damiam · 2002-01-04 08:57 · Score: 1

But how do you know the disassembler isn't trojaned?

--
It's hard to be religious when certain people are never incinerated by bolts of lightning.
Re:a dumb question by toriver · 2002-01-04 10:07 · Score: 1

The "javac" program that ships with the JDK is such a program...
Well, formally it's just a shell/executable which starts the VM using sun.tools.compiler.Main (or whatever) as an application class. This class is the main entry point of the classes which are the compiler application.
Re:a dumb question by rhysweatherley · 2002-01-04 12:47 · Score: 2

Which is precisely why Portable.NET's C# compiler is written in C, not in C#. It is a lot harder for someone to put a trojan in - if you trust your version of gcc, and then inspect the pnet code for problems, you can trust pnet. With a C# compiler written in C#, there is no way to be 100% certain.
Languages that are implemented in themselves suffer from the "magic binary" problem. You have to trust a magic binary version of the compiler to bootstrap. Since inspecting binaries for trojans is hard, this gives unscrupulous individuals an avenue of attack.
Portable.NET's Web Site
Re:a dumb question by GigsVT · 2002-01-05 06:34 · Score: 1

Man. :)

There IS no such thing as security. I always believed that, but I never realized how true it really was.

The only secure system is the one you built from the ground up, hardware and software, from basic components, and even that only gets you to the point where it can become secure, not a guarantee of security.

--
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Re:a dumb question by mikera · 2002-01-07 03:15 · Score: 1

True, although it is a fast Java compiler, which was what we were talking about. It's a bloody tool, so who cares what it's written in?
Re:a dumb question by puetzk · 2002-01-07 04:09 · Score: 1

oops, indeed.
actually, I meant to do join <FILE%gt;
but forgot to. Your solution's better anyway.

--
The Matrix is going down for reboot now! Stopping reality: OK. The system is halted.
Re:a dumb question by kigrwik · 2002-01-09 03:56 · Score: 1

from the Jargon:

Ken Thompson has since confirmed that this hack was implemented and that the Trojan Horse code did appear in the login binary of a Unix Support group machine. Ken says the crocked compiler was never distributed. Your editor has heard two separate reports that suggest that the crocked login did make it out of Bell Labs, notably to BBN, and that it enabled at least one late-night login across the network by someone using the login name `kt'.

--
-- don't discount flying pigs until you have good air defense
Re:a dumb question by ReelOddeeo · 2002-01-09 11:09 · Score: 2

It seems to me like there is a group of dedicated people doing active development on GCC.

--

Those who would give up liberty in exchange for security and DRM should switch to Microsoft Palladium!

Someone please? by Anonymous Coward · 2002-01-03 23:57 · Score: 0

Oky. compile itself? So it has a compiler in the exe, erm, why?

I know absolutely stuff all about C#. But I cannot see why an exe should have a compiler in it?? Is it so your exe can compile other C#? Im very confused, it just doesnt make any sense.

How does the build stage go?
Make C# source -> compile/link -> exe -> compile????? -> exe -> compile????? -> exe

And if the exe can run as a compiler, erm how do you run it as an exe??? command line options? or what?

Some please help me out here.

Re:Someone please? by xer.xes · 2002-01-04 00:03 · Score: 2, Informative

Okay:

c# compiler source + gnu c compiler = C# compiler
C# compiler source + c# compiler = another c# compiler
app source code + c# compiler = app

So it's not the application (exe?) that can compile, but it's the compiler that can compile...

Uhmm.. Yeah.. :)

--
xer.xes -- 4181
Re:Someone please? by xer.xes · 2002-01-04 00:18 · Score: 1

Hmmm thinking about that.. That would be something like:

father + mother = me
me + mother = me

Uhmm.. That can't be healthy... :)

--
xer.xes -- 4181
Re:Someone please? by headsling · 2002-01-04 00:19 · Score: 1

Actually its :

c# compiler source + MS c# compiler = Mono-C# compiler
Re:Someone please? by IntlHarvester · 2002-01-04 00:26 · Score: 0, Troll

Does anyone know if MS's C# compiler is written in C#?

--
Business. Numbers. Money. People. Computer World.
Re:Someone please? by xer.xes · 2002-01-04 00:36 · Score: 1

Duh, ofcourse... My bad.. I just woke up, you know :)

--
xer.xes -- 4181
Re:Someone please? by Big+Dogs+Cock · 2002-01-04 00:43 · Score: 1

Opening csc.exe with the dependency walker reveals a direct dependency on MSVCR70.DLL - ie the C++ runtime library.

Does that answer your question?

--
"Under the iron bridge, we fist" - The Smiths, Still Ill
Re:Someone please? by ymgve · 2002-01-04 00:48 · Score: 1

No.

It is written in Visual Basic

</sarcasm>
Re:Someone please? by dherron · 2002-01-04 11:48 · Score: 0

great thats all we need
a compiler with a oedipus complex.

Samba anyone ? by MosesJones · 2002-01-04 00:05 · 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 · 2002-01-04 00:13 · 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 Numen · 2002-01-04 00:20 · Score: 1

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.
Re:Samba anyone ? by Anonymous Coward · 2002-01-04 00:23 · Score: 0

Mono is not like samba because it doesn't need to be compatible. It solves problems that exist in Linux right now.

>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.

I don't think that you understand that mono is a c# compiler and not really related to the network aspects of .NET.

Sure, it's copying Microsoft, but Microsoft is dealing with the same problems as Linux so copying is valid. Just because it was Not Invented Here doesn't mean it's wrong.
Re:Samba anyone ? by MagPulse · 2002-01-04 00:37 · 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 Anonymous Coward · 2002-01-04 00:59 · Score: 0

Poor IO? Mainframes? Poor distribution? It's very, very obvious that you have no idea what .NET is. The whole purpose of .NET is distribution of components across heterogeneous environments, to the point where Microsoft has posted examples of how to cross communicate between Apache/SOAP and IIS/.NET (the difference lying entirely in the WSDL, which wasn't standardized until very recently, and Microsoft adheres to that standard.)

C# is a standardized language through ECMA, submitted to ISO. Not even Java can claim that. If Microsoft did change C# around, the original specification would still survive and be useful as a seperate entity. However, in this case, Microsoft has a very positive reaction to the existance of Mono.
Re:Samba anyone ? by griffits · 2002-01-04 01:06 · Score: 2, Informative

>>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.

Don't you mean COM+. CORBA encapsulates a wire protocol, transaction capabilities, security etc. COM is really just "IUnknown" and anyway if it is so superior, why is it being replaced by .NET?
Re:Samba anyone ? by Ayende+Rahien · 2002-01-04 01:16 · 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 · 2002-01-04 03:31 · 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
Re:Samba anyone ? by harlows_monkeys · 2002-01-04 04:07 · Score: 2

Microsoft will stick with the "Standard" just like they did with Java, only this time there won't be anyone pig-headed like Sun rejecting their improvements out of spite.
Re:Samba anyone ? by harlows_monkeys · 2002-01-04 04:16 · Score: 2

There's also the tools. Infoworld (I think), in a comparison of CORBA and COM (a couple years ago...things may be different now) concluded that CORBA was a little bit better technically, and COM was a lot easier to use, because Microsoft provided better tools.
The thing about Microsoft is that they often take two or three iterations to get it right, but when they get there, it's right for the programmer. Too many things in the Unix world are right in a theoretical sense, but a complete pain in the ass when you fire up your editor, start the caffeine IV, and try to crank out code.
Re:Samba anyone ? by NumberSyx · 2002-01-04 04:29 · Score: 2

Microsoft will stick with the "Standard" just like they did with Java, only this time there won't be anyone pig-headed like Sun rejecting their improvements out of spite.

I am not sure I'd classify what Microsoft wanted to do to Java as "improvements". Whether or not they were improvements, Microsoft broke the license agreement with Sun. The agreement specificly stated any Java implementation by Microsoft would be standards compliant. Microsoft purposly failed to do this and as a result lost in court because of it.

--
"Our products just aren't engineered for security,"
-Brian Valentine,VP in charge of MS Windows Development
Re:Samba anyone ? by Anonymous Coward · 2002-01-04 05:22 · Score: 0

solution: only support the libraries that have been submitted to ECMA and develop the rest in an MS incompatible way (port from gnome,kde, ...)
Re:Samba anyone ? by Anonymous Coward · 2002-01-04 06:24 · Score: 0

>Linux will finally have a decent object technology with which to build large OO projects that will work together.

Wait a minute? What about Java? Java is leaps and bounds ahead of C# and .NET / Mono right now. JBoss / Tomcat / Ant / Forte/NetBeans are all GREAT for large scale OO projects.

Why doesn't the Linux community/developers embrace Java? It's probably the only way to take over corporate US from Microsoft.

??? Please someone explain this to me!
Re:Samba anyone ? by Anonymous Coward · 2002-01-04 08:19 · Score: 0

"Why doesn't the Linux community/developers embrace Java? It's probably the only way to take over corporate US from Microsoft."

Because we don't want to hand it over to Sun, who is desperate to be a monopolist like MS, but even less competent and more expensive.

I'm my own mother and father. by NotAnotherReboot · 2002-01-04 00:08 · Score: 0, Redundant

In other, semi-related news, I am my own father and mother.

Re: eat your own dogfood by Anonymous Coward · 2002-01-04 00:10 · Score: 1, Insightful

Self-hosting is always a huge win from a quality point of view. If the C# compiler is used to build itself, you know the bugs will be discovered and worked out quickly. I try to do something similar with all of my projects. Basically it's the 'eat your own dog food' philosophy - if you need your own product every day, you're super-motivated to fix it ;-)

It's the chicken ... by Aceticon · 2002-01-04 00:14 · Score: 0, Redundant

Who came first - the egg or the chickey?

In this case it's the chicken, 'cause only now did it laid an egg.

Re:It's the chicken ... by FatRatBastard · 2002-01-04 00:26 · Score: 2

The Rooster.
Re:It's the chicken ... by ymgve · 2002-01-04 00:45 · Score: 1

But the duck-billed platypus (MS C#) came even earlier, because it birthed the chicken (mono).

And the chicken has made many eggs (programs) so far, but this is the first time a fertile egg (the compiler has been born) has been laid, which can produce another chicken without the aid of that dreaded platypus.

Compile itself by Hougaard · 2002-01-04 00:17 · Score: 5, Funny

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.

Re:Compile itself by ideonode · 2002-01-04 01:31 · Score: 3, Funny

Not to be pedantic, but doesn't that mean that the first Pascal compiler was actually Niklaus Wirth?
Re:Compile itself by SpinyNorman · 2002-01-04 01:38 · Score: 2

I find it hard to believe that Wirth "hand compiled" the firt Pascal compiler - the size of sych an effort would have been unbelieveable.

The history I dug up on Wirth does agree that the first compiler was written in Pascal (after an aborted attempt to do it in FORTRAN!), but I highly suspect that was only the first FULL compiler, and that it was in fact bootstrapped from ALGOL/W which was Wirth's prior creation (and which I actually used at college in the late 70's!).
Re:Compile itself by Scooter · 2002-01-04 01:51 · Score: 1

LOL :)

I dont think so though - I think it makes Wirth the computer, his pen and paper the BIOS etc etc. He "ran" the compiler on his "cpu/brain" and output the results onto /dev/notepad :-)

I can beleive this - those boys were mad - remember they weren't so much interested in the practical uses of programming languages - people like Wirth were far more interested in the aethetics of the language and some sort of logical purity - so it would have been important to him, that his compiler was not tainted by another....
Re:Compile itself by CatherineCornelius · 2002-01-04 02:26 · Score: 5, Informative

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:Compile itself by Anonymous Coward · 2002-01-04 02:40 · Score: 1, Interesting

Steve Wozniak wrote an integer basic interpreter in 6800 (IIRC) asm. Without having a computer to test it with. When he wrote integer basic for the Apple II, he couldn't afford a timesharing 6502 assembler, so he did the assembly by hand, and only introduced 1 error.
Re:Compile itself by Anonymous Coward · 2002-01-04 04:18 · Score: 0

I believe one or two younger readers may recognise this concept from a very popular modern programming language. :)

Are you trying to tell me Visual Basic was written in Visual Basic?
Re:Compile itself by SpinyNorman · 2002-01-04 04:52 · Score: 2

Yep, but while P-code eventually made the compiler easily portable, that doesn't help compiling the first compiler (which I beleieve generated CDC 6600 native code anyway). I'm still guessing the first self-compiling compiler was bootstrapped with help from another language such as ALGOL/W... but I wish Google had more to say on the matter!
Re:Compile itself by SpinyNorman · 2002-01-04 04:58 · Score: 1

Nope - she's trying to tell you that the UCSD P-system predated Java by 15-20 years, and achieved the same portability.
Re:Compile itself by p3d0 · 2002-01-04 05:41 · Score: 2

That's retarded. What did the first compiler translate into? P-code? Whatever it was, the esteemed Dr. Wirth could simply have written the first version of the compiler in that.

You bootstrap a new language by writing a compiler for a subset of that language in some existing language. Then you write a fuller version in the new language, compile it, and from then on you work in the new language alone.

You don't execute the compiler on paper. That's a useless exercise at the best of times; in this case, it's a pure waste of time.

--
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Re:Compile itself by Hougaard · 2002-01-04 06:46 · Score: 2

Maybe not now, but in 1968 computer cycles was quite expensive so must programming was done on paper.

And existing langauges was pretty useless, they tried for a period to do it in fortran but failed.
Re:Compile itself by Anonymous Coward · 2002-01-04 07:09 · Score: 0

That's retarded.
No, that's funny. What's retarded is you. It's a joke, get it? You know... Haha?
Re:Compile itself by p3d0 · 2002-01-04 09:55 · Score: 1

It's not a matter of compute cycles. My point is that whatever language they were translating into, why not just write the first version directly in that language? Be it assembly or p-code or whatever, what is the point of emulating a compiler on paper when you could just write the code in the target language to begin with?

--
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Re:Compile itself by dvdeug · 2002-01-04 10:16 · Score: 2

If they tried to write it in Fortran and failed, it doesn't say much for their programming ability. I have one of the first compilers for Algol68, a much more complex language than Pascal, and it was written in Fortran.
Re:Compile itself by Hougaard · 2002-01-04 22:53 · Score: 2

My dear Catherine,

Wirth DID hand compile the first pascal compiler, this was ofcause a subset of pascal, ~60% (Ref Dragon Book pg. 727 1986 ed.)

McCarthy did hand translate one of the first lisp interpreters into assembler in late 1958, and that should be one of oldest hand bootstrapping compilers. (Ref. Dragon book pg.725 1986 ed.)
Re:Compile itself by CatherineCornelius · 2002-01-06 19:22 · Score: 1

Wirth DID hand compile the first pascal compiler, this was ofcause a subset of pascal, ~60% (Ref Dragon Book pg. 727 1986 ed.)
Now you mention it, I recall reading a book in 1985/6 on compiler writing that used a compiler written in a subset of Pascal. I don't know whether this was the version that Wirth used, though.
I used to be quite a quiche-eating Pascalhead in those days. It was the best language available under VAX/VMS at the time.

This might make it a bit more intriguing by f00zbll · 2002-01-04 00:34 · 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 · 2002-01-04 01:02 · 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.
Re:This might make it a bit more intriguing by f00zbll · 2002-01-04 01:13 · Score: 2

My mistake, you're absolutely right SOAP doesn't require DOM. It's just because I prefer to use a DOM compliant parser to parse XML that has a structure and use DTD validation built into either a validating SAX or DOM parser.
In their case though, the parser has to validate, which does mean it has to load the entire document first before it can validate it contains the proper structure. Otherwise a bug in someone's code could accidentally have an envelope node inside a body node.
Re:This might make it a bit more intriguing by f00zbll · 2002-01-04 01:26 · Score: 2

I've only used IBM and apache SOAP parsers, so maybe microsoft has written an optimized SAX parser specifically for validating SOAP documents. I've written custom parser using JAXP 1.0 and Xerces 1. Even though I was wrong in my original post (oops no coffee), SOAP is still incomplete for complex distributed processes. If I had to implement a driver to charge credit cards for an E-commerce site (which is most likely the first use of SOAP), I would rather do it with XML RPC.
Just because my brain was caffiene deprived :), doesn't mean SOAP is any better for complex distributed processes, or light enough for simple web services.
Re:This might make it a bit more intriguing by rbeattie · 2002-01-04 02:46 · Score: 2

I don't know much about C# (being a Java developer myself) but is this saying that any program or class compiled in C# becomes, in effect, a SOAP server? All of it's public methods can be called via XML requests?

If so, that's kinda cool. Java should have something like that. I should be able to compile a Java class and have it accessible via XML instantly without having to write a wrapper - even RMI is a bit tedious with the skeletons and stubs...

-Russ

--
Me
Re:This might make it a bit more intriguing by borgboy · 2002-01-04 04:14 · Score: 2, Informative

but is this saying that any program or class compiled in C# becomes, in effect, a SOAP server?

Not quite, but that step is an insanely easy one:
You preface the methods that you wish exposed as web services with a declarative like this
[WebMethod]

like

public class Foo {
private void NotSeen {}
public void NotAService {}
[WebMethod]
public string imaWebService
{ return "Hello Dave"; }
}

If you want access to the http server context and stuff, you inherit from System.Web.Services.WebService

--
meh.
Re:This might make it a bit more intriguing by Furry+Ice · 2002-01-04 05:43 · Score: 1

Hold on there, chief. You don't need to load the entire document into memory to validate it. There are many validating SAX parsers out there that work incrementally. SOAP doesn't require validation, either. Certain pieces are required, but IIRC there isn't a DTD or schema for SOAP--it is the job of the SOAP implementation to validate the (relatively small) required sections. I wrote a simple SOAP implementation before the final spec was released and it's very highly efficient. It's also kind of a pain in the ass to use, but it has to handle streaming because I'm shuffling around documents that are tens of megabytes and won't fit into the memory of the small devices my company uses.

SOAP can be pretty lightweight, as long as you consider (basic, non-validating) XML parsing lightweight...
Re:This might make it a bit more intriguing by f00zbll · 2002-01-04 06:48 · Score: 2

Dude that is sweet. Now I wish it was open source back in 2000 (or that I knew of one) when I was working with SOAP for SMS related services. Since the early drivers for it didn't work (in beta), I just used DOM parser. I hadn't consider writing a specialized parser to handle SOAP the way you described it, credit to you for thinking of an efficient way to do it without the cost of loading the whole document. I honestly haven't kept up with all the SOAP drivers out there, so my mistake. I was researching the feasibiliy of using SOAP within a transactional message based system, so having valid message was a critical requirement as a non-valid message could potentially hang up the system.

nessisary? by Anonymous Coward · 2002-01-04 00:35 · Score: 0

/. should've spell check!

Realitive? by minusthink · 2002-01-04 00:36 · Score: 1, Interesting

Can someone who is more knowledgable give me a couple answers?

Generally, how mature is a compiler when it reaches self compiling capabilities? young? is it a main goal of the project?

also how does this compiler compare to the average lifeline of a compiler? is it on track, slow in development, etc.

thanks.

--
"when life gets complicated, I like to take a nap in a tree and wait for dinner" - Hobbes.

Re:Realitive? by mikera · 2002-01-04 01:18 · Score: 3, Interesting

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.....
Re:Realitive? by CatherineCornelius · 2002-01-04 01:45 · Score: 2, Informative

Generally, how mature is a compiler when it reaches self compiling capabilities? young? is it a main goal of the project?
One way of porting a language to a new architecture involves a kind of bootstrapping, wherein a compiler for a simple subset of the language is written in some host language (C, say) that is already available. Then more sophisticated parts of the compiler can be coded using the first generation of the compiler. Where the new language is already largely a superset of the porting language (as is the case with c-like languages), you can end up with a compiler that can compile itself.
So it's a feature of the method used to port the language. Obviously if a C# compiler were written in Pascal or Fortran, say, it would not ever be able to compile itself, no matter how mature it became.
The ability to write compilers is definitely a useful feature of any language, but producing a self-compiling compiler isn't necessarily a goal. If portability is important, a porting kit for the language should be provided in C or some other lingua franca.
Re:Realitive? by markmoss · 2002-01-04 01:46 · 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.

M-x mono-mode by haystor · 2002-01-04 00:40 · Score: 4, Funny

[no match]

hmm...It can't be a real language.

--
t

mono is a compiler, not a language by Anonymous Coward · 2002-01-04 00:48 · Score: 0

i hate stupid people

Re:mono is a compiler, not a language by Anonymous Coward · 2002-01-04 01:15 · Score: 0

What is any language without a compiler?
Of what use is a compiler of no language?

i hate stupid people
So do I.

congrats, you're stupid by Anonymous Coward · 2002-01-04 00:55 · Score: 0

*claps*

Mono is does not depend on .NET by Carnage4Life · 2002-01-04 00:58 · 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.

Mono is not a clone of .NET on Linux but an implementation of the ECMA standard on Linux. You do know that C# and the CLI are ECMA standards, right?

Secondly as miguel said in my interview with him which originally ran on Slashdot and then on MSDN

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:Mono is does not depend on .NET by loony · 2002-01-04 01:47 · Score: 1

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.

And SUN is very compatible too - thats why I run all my software programmed with swing and jdk 1.3 in any webbrowser!

Get real - M$ has been very good at being backwards compatible as in "Run old code on new OS" not "run new code on old OS"... You will see the same with .NET. yes, they will not change the exisiting API, but they'll put so many extensions in that you cannot run the new apps on old versions of the runtime...
Re:Mono is does not depend on .NET by Anonymous Coward · 2002-01-04 03:23 · Score: 0

software programmed with swing and jdk 1.3 in any webbrowser!

Actually you can do that, you just need to make attache the correct jar files. Unfortunately the extra few megabytes on a web page can be quite noticable.

"Run old code on new OS"

Well, that's what backward compatibility is..
Re:Mono is does not depend on .NET by JordoCrouse · 2002-01-04 04:18 · Score: 1

M$ has been very good at being backwards compatible as in "Run old code on new OS" not "run new code on old OS".

I know this irevelent, but I couldn't let this slip by....

THATS THE DEFINITION OF BACKWARD COMPATIBLE!!!!!

Geez...

--
Do you have Linux and a DotPal? Click here now!
Re:Mono is does not depend on .NET by HamNRye · 2002-01-04 06:00 · Score: 2

I could mention millions of things that have bandied about the moniker of "Just choose a different runtime assembly". One was Java, and that has been a nightmare.

The problem comes with inexperienced or lazy programmers. Most of the .NET programming will come from Windows programmers who will read this line in their book: "While it is easy to make C# code work across many different implementations, 90% of your user base is running Windows, so just comment out those lines about "if (OS != Win) {};".

Even if 90% of .NET services are written properly, the other 10% still stands a pretty good chance of alienating less technical users.

Microsoft is not the one making technology a pain in the buttinski, it's the legions of "Web Developers" who learned everything from two Sybex books and a weekend class at Comp USA.

MS never put a gun to your head and made you include that marquee tag did they??

Jason

LOTR and .NET by aprosumer.slashdot · 2002-01-04 01:01 · Score: 0, Offtopic

Of course the parallels are not perfect, but you get the idea:

Microsoft == Sauron, creates the One Ring (the CLR, the Common Language Runtime)

The Rings of Power == various implementations of programming language to C# parsers, for example C to C#

Miquel == Saruman, creates his own "Ring of Power" (MONO) to use against Sauron (Microsoft)

The question is, who/what will be the hobbit that will cast the .NET back into the fires of Mount Doom? ;)

One CLR to rule them all,
One .NET to find them,
One CLR to bring them all and in the darkness bind them

Cautionary Tale by devnullkac · 2002-01-04 01:05 · 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!

Re:Cautionary Tale by Corrado · 2002-01-04 01:48 · Score: 1

This is a very interesting viewpoint. Suppose Microsoft planted similar 'bugs' in .NET compilers. Could we use Mono's implementation to find them?

Let the Microsoft conspiracy war begin.

--
KangarooBox - We make IT simple!
Re:Cautionary Tale by ReelOddeeo · 2002-01-04 02:17 · Score: 2

This is a very interesting viewpoint. Suppose Microsoft planted similar 'bugs' in .NET compilers. Could we use Mono's implementation to find them?

Maybe not. After all, if mono was bootstrapped on C#, then there is the theoretical possibility to propagate stuff into the Free implementation.

Of course, this would require more foresight on MS part than I give them credit for. Plus there is the practical problem of how to you alter your compiler such that it can recognize that it is compiling a competitive but yet unwritten compiler.

Nonetheless, an amusing idea.

--

Those who would give up liberty in exchange for security and DRM should switch to Microsoft Palladium!

COM v CORBA... by MosesJones · 2002-01-04 01:08 · Score: 2

COM is superior to CORBA ? Sorry to be rude but on what planet is that true.

COM runs on one platform on one protocol.

CORBA, federated networks of loosely coupled elements are possible. Transactional mapping is better than in COM (new versions of CORBA).

CORBA is more established and has a better history.

If you meant COM+ rather than COM then there is a slight merit to actually having a debate but COM is a poor and simple mans version of CORBA, even MS realised this, hence the massive overhall for COM+.

CORBA IMO still remains the best of the bunch out there but it doesn't have the marketing might of EJB or .NET COM+. Smart ideas don't often win in the world of marketing technology.

--
An Eye for an Eye will make the whole world blind - Gandhi

Re:COM v CORBA... by partingshot · 2002-01-04 07:23 · Score: 2
- COM runs on one platform
Not so fast MosesJones!

XPCOM
--
Anonymous posts are filtered.

Microsoft and "standards" by MosesJones · 2002-01-04 01:13 · Score: 2, Troll

I am well aware that MS have submitted C# to ECMA, but then they also sat on the SOAP 1.1 expert group and their implementation didn't meet the standard.

Implementing ECMA on its own is pointless, .NET is the only implementation that matters. In the same way as JBoss and Enhydra have to stick to the J2EE spec because implementing just the language spec is pointless then Mono will have to implement .NET or just become a sideline.

MS don't have a great history of backwards compatibility, they have a great history of patches that upgrade their old stuff to match the new stuff. DR-DOS, Samba et al all demonstrate the changing nature of those supposedly backwards compatible APIs.

Not being a revolution isn't a problem, but it would be nice for once if we could actually move beyond a problem set that was effectively solved around 8 years ago rather than just spinning then same one over and over again.

--
An Eye for an Eye will make the whole world blind - Gandhi

Re:Microsoft and "standards" by rabtech · 2002-01-04 03:03 · 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)
Re:Microsoft and "standards" by Len · 2002-01-04 03:14 · Score: 1

MS don't have a great history of backwards compatibility, they have a great history of patches that upgrade their old stuff to match the new stuff. DR-DOS, Samba et al all demonstrate the changing nature of those supposedly backwards compatible APIs.

DR-DOS and Samba have had problems because they were relying on things that are not published API's or standards.

I have written lots of software on Win 3.1 that works fine on Win 95, and on Win 95 that works fine on Win XP.
Re:Microsoft and "standards" by MiniChaz · 2002-01-04 04:48 · Score: 0

Correct me if I'm wrong but CIFS (Common Internet File System?) is SMB (Server Message Block).

Things are deliberately changed by Microsoft to disrupt non-Microsoft projects such as Samba. Granted the basic SMB stuff is the same but they do like to break the domain and roaming profiles stuff every now and then. Windows2K SP2 contained a specific change that enabled roaming profiles to be downloaded successfully from Microsoft servers but not from a Samba server acting as a PDC (Primary Domain Controller).

Their main weapon is undocumented API's that they can change to their hearts content because no one knows about them (unless they have done some reverse engineering). These secret API's give Microsoft the stranglehold that they have.

Thanks.
Re:Microsoft and "standards" by Ewan · 2002-01-04 05:09 · Score: 1

CIFS is not SMB, it is the replacement for SMB which runs on different ports on Windows 2K and WindowsXP.

Win2K uses SMB to talk to older systems, and CIFS to talk to other new systems.
Re:Microsoft and "standards" by SerpentMage · 2002-01-04 05:55 · 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 ClosedSource · 2002-01-04 05:58 · Score: 1

"Their main weapon is undocumented API's that they can change to their hearts content because no one knows about them (unless they have done some reverse engineering). These secret API's give Microsoft the stranglehold that they have"

Thousands of sucessful applications have been written without the use of "secret API's". I think the problem that some MS competitors have had is that they didn't take advantage of the public API's that were available (WordPerfect 1.0's disdain for Windows printer drivers comes to mind).
Re:Microsoft and "standards" by ClosedSource · 2002-01-04 06:04 · Score: 1

"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."

There must be more to it than that. Certainly applications can save to other folders besides "My Documents" in Windows 2000 and Windows XP. Otherwise 99% of legacy applications wouldn't work.
Re:Microsoft and "standards" by duffbeer703 · 2002-01-04 06:15 · 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
Re:Microsoft and "standards" by Anonymous Coward · 2002-01-04 06:41 · Score: 0

You oviouisly don't know were the Win32 API came from or why it is stable. When you find the answer, you will realize that it is not to Microsofts credit. If they could have screwed with it, they would have.
Re:Microsoft and "standards" by ZxCv · 2002-01-04 06:44 · Score: 2

I would be very curious to see more specifics of that anecdote as well. I currently have 2 different apps written in VC++ that save lots of data to their own directories, as well as user-specified locations. I regularly test both on Win98,ME,2K, and XP, and have had 0 issues related to saving files.

This guy has to be trying to accomplish something much more involved than just "saving content". Either that, or he misunderstood Microsoft's recommendations (specifying that user data is stored under \Documents and Settings\User) as rules.

--

Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
Re:Microsoft and "standards" by Anonymous Coward · 2002-01-04 07:01 · Score: 0

*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.

It's too bad that they didn't do the above when they decided to drop the Netscape plug-in interface in IE. That broke a lot of stuff and forced web sites to even rewrite some pages because the new Active X plug-ins didn't alow for certain tags to be present in the page...
Re:Microsoft and "standards" by Anonymous Coward · 2002-01-04 07:04 · Score: 0

I think what the guy means is that unless you by default save to My Documents, you are not strictly compliant with the 2000/XP guidelines. IE, you can't have a Designed for XP stamp on your software box. Boohoo.

I actually hate when things default to My Documents, that's totally retarted, even on a multi-user machine. It should default to C:\ There is already a My Documents button on the common File Save dialog. Things get much worse when the application is misbehaved and doesn't remember the last directory selection, not just across sessions, but even in the same session! That's just fucking sloppy.
Re:Microsoft and "standards" by markj02 · 2002-01-04 07:10 · Score: 2

Similarly, the Win32 API hasn't ever been CHANGED... it has only had things added to it.
Yes, and a steady stream of unnecessary, incompletely documented additions to their APIs is exactly the problem. That is what has kept the Windows platform from being implemented successfully by any other vendor.
*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.
The way it should be done is that you spend some time ahead of time and work out APIs that you can live with for decades. When you do make significant API changes, you give people the tools to convert their code (deprecation, automatic translation). Saddling the platform and their code with dozens of incompatible variants is not the right approach. And the backwards compatibility doesn't really help anyway: you may be able to compile a program written for Windows 3.1 for your XP machine, but its behavior would be so oddball that nobod would want to use it.
If anyone is spouting FUD and nonsense here, it is you.
I don't see any "FUD" here: there is no fear, no uncertainty, and no doubt. As you yourself said, Microsoft constantly extends their APIs and keeps multiple incompatible versions around. Microsoft gets unclonable APIs, quick time to market, no complaints from people too lazy to update their code, and low engineering costs. The people who are screwed are the developers, who have limited choice, poorly thought-out APIs, need to update their code constantly to deal with Microsoft's latest fancies, and too much stuff to learn, and customers, who get locked into a single vendor and get poor quality software. Microsoft's low-quality approach works in terms of their business, but that doesn't make it good engineering.
Re:Microsoft and "standards" by Jeremy+Allison+-+Sam · 2002-01-04 07:19 · Score: 2

You're wrong.

CIFS is just a marketing name. The protocols on ports 445 and 139 are functionally identical, and you can call it CIFS or SMB or my favourite ("a hideous wart" :-) or whatever you like.

CIFS is not a replacement for SMB. CIFS *is* SMB.

Regards,

Jeremy Allison,
Samba Team.
Re:Microsoft and "standards" by spitzak · 2002-01-04 08:13 · 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.
Re:Microsoft and "standards" by ClosedSource · 2002-01-04 09:27 · Score: 1

"The way it should be done is that you spend some time ahead of time and work out APIs that you can live with for decades."

Once you have decades of experience you'll be qualified to evaluate the practicality of that statement.
Re:Microsoft and "standards" by ClosedSource · 2002-01-04 09:34 · Score: 1, Informative

Actually, you can use getenv to determine the user's HOMEPATH.
Re:Microsoft and "standards" by cyberkreiger · 2002-01-04 10:22 · Score: 1

In Linux i have the functions struct passwd *getpwnam(const char * name) and struct passwd *getpwuid(uid_t uid) to get an entry from the password file, which contains the users home directory.

According to my man-page, those conform to SVID 3, POSIX, and BSD 4.3.

--
Stumbling in the dark
I hear slavering of jaws
Eaten by a grue.
Re:Microsoft and "standards" by SerpentMage · 2002-01-04 11:10 · Score: 2

That is exactly the point I am trying to point out. MS has introduced new API to get the home directory.

While some folks have pointed out that you can save to other directories, try that on an enterprise release. Things break very quickly because of security priviledges.

While generally you can ignore Microsoft's rules you cannot do so if you want to be MS approved. And to sell to larger accounts you need to be MS approved. I just went through this as Program Manager for the XMLSpy product.

--

"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 SerpentMage · 2002-01-04 11:19 · Score: 1

In enterprise and large coporation situations things break very quickly. Especially with the release of Windows XP the security thing is becoming crucial. There are things that you cannot do anymore because of security.

To test what I mean log onto a Windows 2000 box. Create a user and make that user a part of the users group only. Log off and log on as that user. Next try to manipulate things in the file system. At this point only the My Documents directory is read write.

This behavior is identical to a UNIX user account. But the problem is that people are used to writing things all over the place. Now they cannot. So how do you retrieve the "My Documents" directory. Some folks say use GetEnv since that works. But the thing is that that is not the legal way and may break sometime in the future. So you use the MS API which resides in ShFolder

So now here you are a shareware programmer. Which way do you follow? Do you be a UNIX guy or do you be a Windows guy? Most likely a Windows guy because you are lead to the impression that this is the only legal way of doing things. Are you as a software developer going to release something that needs to be patched later? Not likely...

--

"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 SerpentMage · 2002-01-04 11:21 · Score: 1

I am doing nothing more than read and writing data. The problem is that having been in the past XMLSpy Program Manager I saw the problems of not doing things to the MS way. The problems have to do with rollout and security. A regular user has only user rights and hence limited read write abilities.

BTW the recommendations are not recommendations when trying to create a Windows Logo application.

--

"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 SerpentMage · 2002-01-04 11:27 · Score: 1

It is more than just the logo. Most users I have noticed now do not want to see the C:\ location. They actually want My Documents. The reason is because the Windows Explorer makes it really easy to reference. And when developing shareware you have to make it easy on the user.

--

"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 gregorio · 2002-01-04 13:59 · Score: 0

lol, Under Windows: Get the environment variable 'USERPROFILE'.
Re:Microsoft and "standards" by Tony-A · 2002-01-04 15:27 · Score: 1

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?
OK. Under DOS, when the CapsLock light is on on the keyboard, pressing an alphabetic key produces an upper-case letter. When the CapsLock light is off on the keyboard, pressing an alphabetic key produces a lower-case letter. Windows 2000 inconsistently reverses that behavior.
Re:Microsoft and "standards" by Tony-A · 2002-01-04 15:41 · Score: 1

Guessing, but if you actually did secure a windows box so that people couldn't write over anything they pleased, what's left for them to write to? Hidden files in \RECYCLER?
Re:Microsoft and "standards" by Suppafly · 2002-01-04 17:01 · Score: 2

OK. Under DOS, when the CapsLock light is on on the keyboard, pressing an alphabetic key produces an upper-case letter. When the CapsLock light is off on the keyboard, pressing an alphabetic key produces a lower-case letter. Windows 2000 inconsistently reverses that behavior.

you go to hell for lying.. and spreading FUD..
Re:Microsoft and "standards" by markj02 · 2002-01-04 18:02 · Score: 2

You are quite right. And once you have a couple of decades of experience in this industry, like me, you will appreciate the value of well-designed, stable APIs, as opposed to the stuff Microsoft is shipping.
Re:Microsoft and "standards" by cygnusx · 2002-01-04 19:44 · Score: 2

> 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.

Bull.

C:\>echo %HOMEDRIVE%%HOMEPATH% E:\Users\cz C:\>echo %USERPROFILE%\My Documents C:\Documents and Settings\cz\My Documents C:\>echo %USERPROFILE%\Application Data C:\Documents and Settings\cz\Application Data ...etc. The Win32 API is probably not the best possible design on earth. On the other hand, given the way it has evolved, I would challenge you to do a significantly better job. And no, we won't even talk about glibc-hell on Linux.
Re:Microsoft and "standards" by rabtech · 2002-01-04 20:05 · Score: 2

You are vastly mistaken, but it is a common misconception.

The only difference between a Native and Compatibility mode ActiveDirectory is which computers can be DOMAIN CONTROLLERS. It has no effect on member servers or clients. Win9x clients can auth to a Native AD domain, and NT4 servers can be members of a Native AD domain.

The only requirement to use the new features is that you have only W2K DCs... this is because the "Native" mode features do things that aren't allowable under NT4 and the old NetBIOS/SMB -- things like nesting domains inside of parent domains and so on. An NT4 DC wouldn't know how to replicate a nested domain and translate the security stuff without an insane amount of work.

--
Natural != (nontoxic || beneficial)
Re:Microsoft and "standards" by ClosedSource · 2002-01-04 21:53 · Score: 1

Sorry to disappoint you, but I do have a couple of decades of professional experience in this industry. You say you have that much experience as well, so I'll take your word for it.

You claim that a well-designed API should not have to change for a couple of decades. Can you give an example of API that hasn't changed since Jan of 1982?

Some of the worst software designs I've seen have been created by programmers that tried to predict future requirements and failed. I suspect the failure rate for predicting 20 years into the future is 100%.
Re:Microsoft and "standards" by markj02 · 2002-01-04 23:06 · Score: 2

Please be more careful when making statements about other people's claims. Here is what I wrote:
The way it should be done is that you spend some time ahead of time and work out APIs that you can live with for decades. When you do make significant API changes, you give people the tools to convert their code (deprecation, automatic translation). Saddling the platform and their code with dozens of incompatible variants is not the right approach.

This doesn't mean that nothing ever gets added or that all requirements are anticipated decades in advance. It means that when you add functionality, you try to do it in such a way that you won't have to add another variant of the same thing a couple of years later. And if you do make a mistake, you admit it and clean up the mess, rather than retaining junk for ever and ever.
Now, which APIs have those properties? Many actually: the core UNIX APIs, the C standard library, the UNIX/POSIX shell environment, X11, Motif, and Postscript, to name just a few. Well written C/UNIX code from the early 1980's is still functioning, well-written UNIX code today.
This is in contrast to the DOS/Windows approach, where, over the years, you got lots of different approaches for things like opening files, creating windows, handling events, etc. Code written for Microsoft platforms in the early 1980's looks nothing like code you would write for Microsoft platforms today, even if it may still compile in some cases. Heck, even most code written for Microsoft platforms in the mid-1990s looks nothing like what you would do today, using Microsoft's "new" APIs and "new" paradigms. This is particularly bad given that Microsoft's systems haven't been exactly breaking new ground--Microsoft had no excuse for getting any of this wrong in the first place.
Re:Microsoft and "standards" by Anonymous Coward · 2002-01-05 09:52 · Score: 0

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.
Excuse me, but you obviously are not on the samba developers' list if you believe such a ridiculous statement. Anyway, why do you think an API change doesn't count if it improves security or fixes bugs? It's still an API change.

Your HP works because the Samba developers have reverse-engineered the API changes. Go get a hideously old version of Samba and try again before posting such nonsense.

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?
That would be the place where you said FOR THE MOST PART, knucklehead. Go try to play Populous under Windows98, or any of hundreds of other programs.

For the record, I run HP-UX, linux, SCO, Solaris, VMS, and three versions of MSWindows. Samba runs on all the non-MS OSes.

--Charlie
Re:Microsoft and "standards" by ClosedSource · 2002-01-05 14:36 · Score: 1

Well, at least you've clarified what you mean by "APIs that you can live with for decades".

You can use the core UNIX APIs and the C standard library as they existed in the 1980's on their own to write applications that can do 1980's kind of stuff. If you want to write applications that take advantage of new technologies you need updated or additional APIs. There's nothing wrong with that but it's no great accomplishment and I suspect little thought was given to what was going to be needed in 20 years at the time C and Unix were created.

"Code written for Microsoft platforms in the early 1980's looks nothing like code you would write for Microsoft platforms today"

And code written for AT&T platforms prior to Unix and C looked nothing like what they were writing before - so what. Let's forget about "platforms" and talk about operating systems. Windows 1.0 wasn't released until November of 1985, so there really wasn't much Windows application development in the early 1980's to compare to.

I don't really see this as a Unix vs. Windows issue though, I was responding to what I believed to be a extravagant claim that I disagreed with.

By the way, Postscript, X11, and Motif are not decades old.

Warning: The above post is clueless by Carnage4Life · 2002-01-04 01:21 · 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 f00zbll · 2002-01-04 01:39 · Score: 2

I guess your right I am clueless, except that I worked with SOAP and other related XML services. When SOAP drivers first came out from IBM and apache, it was buggy and didn't work properly (ie, the driver wouldn't correctly get the header and body). It has improved since the early releases, atleast the last time I tried.
The argument that it is an industry standard isn't really valid in my mind. My point was in the context of .NET and what microsoft percieves as web services in their whitepapers, a lot of important details are left out.
As you mentioned SOAP is a distributed computing protocol and I agree with you at that level. The problem I have is it is not as complete as IIOP, or RMI. I haven't use JRMP or ORPC, so I'll take your word for it. I've read the SOAP spec atleast three times and I keep asking myself "why not just use XML RPC?"
In theory, a person could also use SOAP with any RPC framework, but for me it feels too much in the middle. I did some benchmarks on SOAP and I personally didn't find it worth while to add the weight.
Re:Warning: The above post is clueless by AixGE · 2002-01-04 02:48 · Score: 2
The fact that IBM and Apache's initial implementations of SOAP were buggy doesn't seem to have a lot of bearing on whether or not SOAP as a standard is a good idea. There's lots of buggy code out there, but that doesn't mean that its goal was flawed. Linux has bugs, does that make it a bad idea?
Furthermore, the very fact that you use IBM and Apache as your examples contradicts your point that SOAP was developed in the context of .NET. What interest does the Apache Group or IBM have in pushing a Microsoft-only technology? It is clear from having worked with several of the toolkits that Microsoft's implementation is the least useful one of all (At this point, anyway.).
Sure, for distributed computing that has the goal of increased performance, SOAP is not ideal due to the XML-parsing overhead, but to think that performance is the only reason to make a system distributed is shortsighted. The key in modern computing is authoritative information and SOAP can make it a great deal easier to create interfaces to it.
Remember, SOAP is not a distributed object implementation, it is merely a wire protocol. Even more importantly, you should make the distinction (When comparing it to XML-RPC) that it is not a raw RPC protocol. There are really three aspects of SOAP:
- Messaging - defines an XML-based way to send messages, without specifying a transport protocol necessarily.
- Encoding - defines an XML-Schema-based way to serialize data to be transferred in the aforementioned messages
- RPC - defines a way to use both the messaging and the encoding aspects to encapsulate distributed, language-independent method calls
The SOAP specification allows you to use just the messaging aspect, the messaging and encoding, or all three, depending on what your needs are. For example, the project I am currently working on makes use of the full RPC SOAP specification using SOAP::Lite for Perl and Apache SOAP for Java (Over HTTP or HTTPS). But in a different aspect of the same project, we have our own encoding schema and so only use the unidirectional messaging aspects. (Over HTTP or SMTP).
--
Get busy living or get busy dying. Carpe diem.
Re:Warning: The above post is clueless by f00zbll · 2002-01-04 03:58 · Score: 2
You make some good points, with one minor correction. I didn't say:
- SOAP was developed in the context of .NET.
I said in the context of the whitepapers that are public on MSDN and .NET site. The three points you mention are good, I just personally would rather go with XML RPC, because if I don't absolutely need to validate the XML (which is most of the cases), I'd rather not. If I can get away with just using an event based parser like SAX, I will choose that first.
I can see a lot of situations where you would want to use other encoding like unicode 16, which would be an argument to use SOAP. But, so far I haven't found a compelling reason to use a specific encoding other than ascii or UTF8. That doesn't mean there aren't cases, just that I haven't come across a development situation where it was painfully obvious using some other encoding was critical. I don't believe that using SOAP can't be effective or even desireable to others, just from my experience working b2b/e2e applications or with messaging systems like SMS there isn't a compelling reason.
Re:Warning: The above post is clueless by AixGE · 2002-01-04 04:31 · Score: 1

We are definitely in agreement about XML-RPC. I am a firm believer in choosing the technology to fit the requirements and not the other way around. I have found SOAP useful for some situations, but treating it like a panacea and trying to apply it to everything is foolhardy at best. Technological religious wars are just plain dumb. :)

--
Get busy living or get busy dying. Carpe diem.
Re:Warning: The above post is clueless by zulux · 2002-01-04 05:26 · 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.
Re:Warning: The above post is clueless by Anonymous Coward · 2002-01-04 07:23 · Score: 0

For fuck's sake people, just give this guy a break. He's obviously got no clue what he's talking about. He got into XML and SOAP when only implementations available were in pre-alpha (maybe), he's still using them 2 years later, and is now convinced XML and SOAP suck ass. Well, no shit, you're using ancient implementations. Get with the times, this area is advancing rapidly, and faster and more optimized tools become available on a weekly basis. When OO first came out, C++ say, the first compilers sucked big donkey balls, and people were saying OO sucked. But now the object overhead is fairly small, especially compared to other gains. I mean, shit, we're running a nazi OO system inside a virtual machine ON THE SERVER (Java); we're past the OO sucks stage because the tools have improved. Now don't embarass yourself any further and stop defending your stupid position; you're grossly uninformed. XML and SOAP don't automatically suck just because you don't know how to use them.
Re:Warning: The above post is clueless by Anonymous Coward · 2002-01-04 12:57 · Score: 0

There is no official SOAP "standard". The W3 document referred to is a *submission*.

Great, but Microsoft will probably win in the end by bjb · 2002-01-04 01:26 · Score: 2, Insightful

I think its great that the non-Windows world is getting a C# compiler, however, it doesn't guarantee that we'll be fine in the future.

When you compile a C# application, you have a choice of compiling to the CLR bytecode, or to a native EXE. True, many apps from Microsoft will be written in C# in the near future, but they'll all be compiled into native code. Any 3rd party apps that get compiled will probably be built to native simply for the speed. Why would you want to want to build into bytecode when you can build it natively? Why release two separate binaries?

Of course, once Miguel's C# compiler catches up with the still-haven't-seen-it Microsoft C# compiler, 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.

Again, I appreciate the work, but I would be very surprised if it isn't simply "trying to catch our own tail".

--
Never hit your grandmother with a shovel, for it leaves a bad impression on her mind...

Your are making that up by Anonymous Coward · 2002-01-04 01:29 · Score: 0

Execute it on paper? Are you kidding me? I am sure the first compilers were just written in machine code...

C# = JAVA by Anonymous Coward · 2002-01-04 01:35 · Score: 0

I have looked through C# its mostly Java code with the functions renamed...

Re:C# = JAVA by Anonymous Coward · 2002-01-04 17:42 · Score: 0

you should hold a press conference!

SOAP is not .NET by Anonymous Coward · 2002-01-04 01:41 · Score: 1

.NET is a marketing term. It encompasses lots of stuff, and the name was picked to suggest that they're the .NET in the internet, like sun is the . in .com

.NET is comprised of

Common Language Runtime and Type System (a VM based language runtime, like Java, but with support for any language you can write a compiler for)
Base classes for the runtime (some general, some MS specific)
SOAP Web Services - they call them .NET services, but they are just SOAP. You could use XML-RPC or CORBA or, (shudder) COM+
(not yet available) Repackaged versions of existing products like SQL Server, Windows Server OSes, etc. which are ".NET"ed (essentially unchanged except for class wrappers on their CLI or API funcitons instead of COM)
Buzzwords and "open standards" love to make them seem like they're willing to play nice with the other people so the Feds don't come after them again.

not just compilers by Tharsis · 2002-01-04 01:43 · Score: 1

This kind of thing holds for a lot of generators, eg. if you cannot design the UI of a UI designer using itself, you've got a bad UI designer.

Re:not just compilers by dollargonzo · 2002-01-04 06:04 · Score: 1

even if its NOT a generator of any sort.

i think i can generalize this to: if there exists a functionality of a program that the program uses...use it! generators are just a special case of this, because their whole functionality revolves around what they are made of...but many people make the mistake of designing something based on some OTHER library, when what they are making just extends the functionality of the library itself...so the question is: why not use what you have made???? editors are another group of programs that fall into this category.

QED

--
BSD is for people who love UNIX. Linux is for those who hate Microsoft.

A glimpse into Mono's logbook... by The_Messenger · 2002-01-04 01:45 · 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:A glimpse into Mono's logbook... by damiam · 2002-01-04 09:11 · Score: 1

Mono begins installing Windows XP Professional on all pingable boxes.
Time for a good game of XBill. :-)

--
It's hard to be religious when certain people are never incinerated by bolts of lightning.

are they going to....... by the_2nd_coming · 2002-01-04 01:47 · Score: 1

make this available to the windows, Mac, and whatever other platform, or are they going to keep this to Linux/Unix?

I know that it is GPL, but it would be nice if the did the porting so when 1.0 hit, we had all those platforms ready to go.

if it was available, and a good quality, I think that it will beat the pants off MS C# since it is free and all.....hey, next stop, adding it to one of the many multi platform RAD environments!!! like Black Adder!!.

--

I am the Alpha and the Omega-3

Re:are they going to....... by jon_c · 2002-01-04 03:58 · Score: 2

I imagine once they have it compiling under a linux (which apparently they do) it shouldn't be to much effort to port it over to FreeBSD and OSX.

So probably soon.

-Jon

--
this is my sig.
Re:are they going to....... by dzym · 2002-01-04 04:43 · Score: 0

Oh but wait, even if Mono turns out better than Microsoft's C#.NET compiler, they (and us) still win.

In this case, everyone's a winner! (Except, hopefully, Sun and Java)
Re:are they going to....... by the_2nd_coming · 2002-01-04 05:38 · Score: 1

you know, a conspearacy theorist would say that MS is letting Mono go about what it is doing so that C# can Beat Java.....as soon as C# becomes unstopable, MS will kill Mono in a law suit or perhaps drive after Ximian.

--

I am the Alpha and the Omega-3

RE: clarification on semantic web by f00zbll · 2002-01-04 01:58 · Score: 2

Yes, semantic web is a push for richer content on the web, but it has grown since the original idea. A new book just came out last year about semantic web and how web services might work together. There is a new initiative within W3C dealing with RuleML and semantic web. So you might want to check out the latest development in that area. It is no longer as simple as "richer content". In fact, here is a presentation by the people leading RuleML. I don't remember the name of the book, but I suggest you look into it before creaming "Warning.." :). I could blame the lack of coffee and caffiene, but hell I make mistakes. There's more stuff every day we have to learn and sometimes it all seems to bleed together.

The fact there are so many misconceptions about what .NET really means (my own included), means there has been a lack of specifics from microsoft.

Is this progress? by Anonymous Coward · 2002-01-04 02:21 · 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:Is this progress? by kirkb · 2002-01-04 04:41 · Score: 2, Insightful

The linux kernel itself certainly seems governed by Brownian motion. Linus himself suggests that development is random, and that evolution ends up sorting out the good stuff from the bad.

Check out http://kt.zork.net/kernel-traffic/kt20011217_146.h tml#1

--
Slashdot: come for the pedantry, stay for the condescension.
Re:Is this progress? by Anonymous Coward · 2002-01-04 06:42 · Score: 0

If they're not careful, Linux will end up banned in Kansas...
Re:Is this progress? by I_redwolf · 2002-01-04 06:48 · Score: 2

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.)

No it doesn't, it helps Linux simply because that barrier you talk of doesn't exist. If I can run C# and .Net on Linux and not worry about having to PAY for it then I will simply use linux. I mean it just makes alot more economical sense for me to get the same stuff and not have to pay for it.

As for open source not innovating, in the realm of UI type of applications I agree whole-heartedly but everyone seems to forget who did what first. Things like the internet itself, tcp/ip protocols, ftp, multi-tasking, apache, C all these things that allow the internet and desktops to function the way they do today were developed a long time ago on unix platforms. Microsoft innovated none of it and have made their money primarily in the UI app sector (IE: Office). Once we start seeing some innovation in that sector then and only then will people switch. It's not about performance or stability or any of that. It's about easy use with "cool" features.
Re:Is this progress? by doubtme · 2002-01-04 13:04 · Score: 1

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.)
Oh but of course. And that's why Excel wasn't successful until it was both forwards and backwards compatible with Lotus 123?
Read this.
Read Joel's other stuff too.
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?
Yeah? And what proportion of "high profile" closed-source projects really innovate?

--

There's no $$$ in 'team'...
www..--..net - for incisive, w

Re: eat your own dogfood by newton34 · 2002-01-04 02:37 · Score: 0, Offtopic

good point

--
look my sig changes!!! nrrt mf oci jdabi.o!!! z..a ir kot gh-ntbk{{{

Re:Great, but Microsoft will probably win in the e by wadetemp · 2002-01-04 02:47 · Score: 1

When you compile a C# application, you have a choice of compiling to the CLR bytecode, or to a native EXE.

No, that's not true. The MS C# compiler only compiles to bytecode. It's possible to avoid JITing that bytecode at runtime by setting an option for any particular bytecode package (this is called PreJITing, and it caches the native image), but you can do that for any application or library on your system, not just those you compile yourself.

The preJITer can take advantage of your specific hardware when generating a native image. Bytecode is actually better when you have that power... wouldn't you rather compile something for Linux directly from the source to optimize it for your machine rather then just install the 386 binary? That's what preJITing lets you do (except you notably don't get the source. :) )

Get Your Hands Off My Pointers by Anonymous Coward · 2002-01-04 03:00 · Score: 0

Pointers? Where's the pointers? What good is a language if you can't access memory directly?
Christ. Even Microsoft Cassette BASIC had peek and poke.

Re:Get Your Hands Off My Pointers by spacehug · 2002-01-04 05:19 · Score: 2, Insightful

erm ... C# has pointers. Or were you referring to Java? ;)
Re:Get Your Hands Off My Pointers by PixelJuice · 2002-01-04 10:29 · Score: 1

String s = new String ("Hello, nerd!");
char[] a = s.ToCharArray();

unsafe
{
char *p = a;
do
{
*p = '#';
p++;
}
while ('!' != *p);
}

You were saying?

(No, the code above hasn't been compiled or tested. That's left as an exercise for the reader.)

how is this pronounced? by Nick · 2002-01-04 03:03 · Score: 1

Don't stone me or anything, but how do you pronounce C# ?

--
Fuck Ajit Pai

Re:how is this pronounced? by IainHere · 2002-01-04 03:14 · Score: 0

C sharp, like the note.
Re:how is this pronounced? by adadun · 2002-01-04 03:14 · Score: 1

I think Microsoft intended that it should be pronounced "C sharp", just as the musical term.
Re:how is this pronounced? by Anonymous Coward · 2002-01-04 03:15 · Score: 0

see sharp
Re:how is this pronounced? by BlaKnail · 2002-01-04 03:26 · Score: 1

C - sharp

as in musical notation
Re:how is this pronounced? by JLyle · 2002-01-04 04:00 · Score: 1

Dee Flat
Re:how is this pronounced? by Alioth · 2002-01-04 04:12 · Score: 2

Microsoft intended it to be pronounced C-sharp.

But in Britain, the # sign is known as a "hash" (not pound - pound is a cursive L that's used to indicate currency).

So to all non-US English speakers, C# will probably be known as C-Hash.

How ironic :-)

--
Oolite: Elite-like game. For Mac, Linux and Windows
Re:how is this pronounced? by glyph42 · 2002-01-04 04:30 · Score: 1

But on all North-Americal telephone systems, the # sign is called "pound". Funny that. So some people call it "C-Pound", usually half-jokingly :)

You know, pound, as in to fornicate or to drink excessively and irresponsibly :) It's funny.

--
Music speeds up when you yawn, but does not change pitch.
Re:how is this pronounced? by Anonymous Coward · 2002-01-04 08:32 · Score: 0

"Bee Sharp Sharp"
Re:how is this pronounced? by mirabilos · 2002-01-04 08:35 · Score: 0, Offtopic

Zeh Zahlzeichen
Aber bitte _nicht_ "Raute" sagen, same danger
to exchange them where one can't as pound/hash
in English.

--
My Karma isn't excellent, damn it! (And /. still does not get UTF-8 right in 2012. Wow.)
Re:how is this pronounced? by [Marvin] · 2002-01-04 11:06 · Score: 1

heh, in Denmark we call the '#' sign 'havelåge' which means that C# in Danish would translate to 'C gardengate' :)=
Re:how is this pronounced? by Vegeta99 · 2002-01-04 16:01 · Score: 1

If you read music, # is pronounced sharp.

So, C# is also Db :P
Re:how is this pronounced? by mirabilos · 2002-01-05 10:09 · Score: 1

Please, why is this offtopic?
It's as ontopic as the danish comment,
and the question itself.

--
My Karma isn't excellent, damn it! (And /. still does not get UTF-8 right in 2012. Wow.)

DDJ by Anonymous Coward · 2002-01-04 03:13 · Score: 0

Here is a link to this months Dr Dobbs regarding Mono

http://www.ddj.com/documents/s=1818/ddj0201a/020 1a .htm [DDJ]

Busy Miguel by MicroBerto · 2002-01-04 03:16 · Score: 2, Insightful

Does Miguel seem to be overworked? Every single Gnome/Ximian announcement I've seen has his name in it. While I'm sure he's one badass dude, should he stick within just a few projects so that he doesn't go anymore insane than necessary?

--
Berto

Re:Busy Miguel by LunaticLeo · 2002-01-04 05:19 · Score: 1

I have seen Miguel at conferences. He is like a manic-depressive bipolar, but with out the depressive part.

The man was born with a Thyroid gland kicked into high gear (I am not a doctor; just a figure of speach). Add being intelligent, and you've got "Busy Miguel".

He became visible contributing to the Linux Kernel, then he started the Gnome project, and now he is writing a compiler and JITing runtime for a complex system. The guy is not afraid to jump into hard, boardering on impossible, jobs.

May be he is a Mexican Ethan Hunt. :)

--
-- I am not a fanatic, I am a true believer.
Re:Busy Miguel by MAXOMENOS · 2002-01-04 06:54 · Score: 2

If you've ever seen Miguel at a Linux conference, you know that he has more energy than your average hacker. For that matter, he has more energy than your average Slayer concert. It doesn't surprise me that he can be so heavily involved with so many projects. Most of us mere mortals would be lucky to have enough energy to make useful contributions to just *one* such project.

--
Finding God in a Dog

EMCA doesn't mean Sh*t! by bryanbrunton · 2002-01-04 03:30 · 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:EMCA doesn't mean Sh*t! by Anonymous Coward · 2002-01-04 04:12 · Score: 0

You're a loser - go crawl back in your hole. You obviously never accomplished anything of value in your life.
Re:EMCA doesn't mean Sh*t! by Utopia · 2002-01-04 04:47 · Score: 1

The standardization process for Javascript was
actually initiated by Netscape (not Microsoft).

Later Microsoft, Sun, HP and other companies joined in the standardization effort
Re:EMCA doesn't mean Sh*t! by bryanbrunton · 2002-01-04 05:02 · Score: 1

The standardization of Javascript by Netscape is all well and good. It also entirely not relevant.

As I said before, MS submitted _JScript_ to the EMCA as an entirely different implementation of Javascript. Its a variant of Javascript. MS created their own standard. Its a standard that MS never bothered to implement fully in their actual implementation and that is not compatible with Javascript.

JScript and Javascript are two different things.

What's the point? by Cro+Magnon · 2002-01-04 03:39 · Score: 1

.Nyet is just a scheme of make M$ richer. C# (D flat?) is just a Java wanna-be!

--
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.

Sure, but how's the Mono VM? by Anonymous Coward · 2002-01-04 04:14 · Score: 0

Can it run the compiler under Linux natively (i.e., not via Wine)?

Re:Sure, but how's the Mono VM? by programcsharp · 2002-01-05 10:24 · Score: 1

Yes. It's not currently quite there, but the compiler will run natively under Linux. The whole Mono project will.

Miguel by rnd() · 2002-01-04 04:15 · Score: 2

For those who speculate about Miguel's
intentions as they pertain to his work on the
Mono project, simply consider the meaning
of "Mono" in Spanish...

--

Amazing magic tricks

Bytecode or Native compiler? by PRR · 2002-01-04 04:17 · Score: 1

I'm familiar with Java, but haven't really followed C#/.NET stuff, so here's another dumb question: Is this Mono compiler a bytecode compiler like javac (which still requires a JVM for further JIT compilation) or is it a native compiler like GCJ which compiles down to an executable?

Re:Bytecode or Native compiler? by Utopia · 2002-01-04 04:38 · Score: 1

Its a bytecode compiler.

In line with free software idealogy. by Da+VinMan · 2002-01-04 04:18 · Score: 2

I don't speak for RMS, ESR, FSF, or any of the other talking heads in the open source/free software movement, but based on the idealogy as I understand it, this is a good thing.

Why?

Well, if by providing C# on Linux removes the barrier to exit from Linux to Windows, then the converse ought to be largely true as well. That is, having C# on Linux removes the barrier to exit from Windows to Linux.

Is that bad? Doesn't it provide more freedom?

(Keep in mind that this also isn't completely true. C# is only one tiny (yes, TINY) piece of .NET. A port of the most important .NET libraries will also be needed to really crumble that barrier to exit from Windows .NET.)

--
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!

Mono? by Da+VinMan · 2002-01-04 04:21 · Score: 2

OK... not having a Spanish dictionary on hand, I'll bite. What does it mean?

--
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!

Re:Mono? by hetairoi · 2002-01-04 04:55 · Score: 2, Insightful

hmmm, according to the fish it means "monkey". I don't get it, but I'm neither quick of wit nor a speculater. Maybe he is "monkeying" around with Macro$oft? I always thought it was odd that they were trying to infect computers with mononucleosis (see, I told you about my lack of wit).

--
you're all figments of my deranged imagination
Re:Mono? by chetohevia · 2002-01-04 05:45 · Score: 1

You can read the FAQ at http://www.go-mono.com, where it says that Mono means Monkey in Spanish. Miguel and the Ximian crew, in case you hadn't noticed, like monkeys. The logo. Rupert, the plush monkey mascot (store.ximian.com) The name "Evolution" for the email client. The name "bonobo" for the component architecture (heh heh, nudge nudge, wink wink, pluggable, bonobo, get it?).
Re:Mono? by ainsoph · 2002-01-04 06:34 · Score: 1

. Maybe he is "monkeying" around with Macro$oft? '
More like those cultureless monoculturists led by the autistic son of a powerlful banker are probably messing around with *HIM*.
I could be wrong, but you know what happens everytime those idjits up in Redmond play nice with the little guy.
It ain't pretty is it?
Re:Mono? by Anonymous Coward · 2002-01-04 07:34 · Score: 0

And of course the name Ximian itself sounds awefully close to 'simian', just another name for a closely related monkey.

eww by jjeffries · 2002-01-04 04:41 · Score: 2

warning: that kind of thing will make you go blind and grow hair on your palms.

So compiling yourself if a good thing but... by clump · 2002-01-04 04:42 · Score: 1

Ok, am going to celebrate with another steak now ;-)

I will be truly impressed when this thing can compile a steak.

C# is not vapor-ware... by Da+VinMan · 2002-01-04 04:46 · 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:C# is not vapor-ware... by Anonymous Coward · 2002-01-04 05:10 · Score: 0

*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*

*ironic mode on*
Gee, maybe everyone would prefer that Java would just die and go away? That way, the other leading language contender in the market, C#, could just take the market. After all, it's not under the influence of the "evil corporations", like Java is.
*ironic mode off*

It's all a matter of perspective.

Re:Now that C# compiles itself... by Laplace · 2002-01-04 04:49 · Score: 0, Offtopic

Too bad this comment was modded into oblivion. It's one of the funniest that I've read in ages.

--
The middle mind speaks!

Waste of time by Anonymous Coward · 2002-01-04 04:50 · Score: 0

The following link is about the past discussion of GPL coders using MS .SDK toolkits to make GPL software. The link to a legal opinion sums it up: the GPL coders are wasting their time, it is illegal and software produced by such an unholy alliance would quickly be squashed.

Of course, Miguel could be using his time profitable to further true GPL software, but seems bent on wasting his talents to indirectly further the goals of the evil and greedy empire and seduce many other GPL coders to waster their time too. Thus instead of producing GPL software that could weaken M$ they help perpetuate the illegal hegemony.
http://slashdot.org/articles/01/06/21/1810258.sh tm l

Yay! We've really needed this. by seebs · 2002-01-04 04:51 · Score: 0, Flamebait

I think Linux was crippled by the lack of a language totally controlled by a monopolistic power that hates Linux. We should rewrite major applications so they depend on Microsoft's pet language, so that any change in the Microsoft spec can cause untold damage as the compatability problems spread.

This will help us sympathise with people who are stuck using systems based on closed, proprietary, systems. It's the best possible use of developer time there could be.

--
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/

CSL vs. C# by FiskeBoller · 2002-01-04 04:59 · Score: 1

Congrats on the milestone.

In my view C# lacks two critical features: dynamic class loading and anonymous inner classes. C# can dynamically load packages that are spec'd, but NOT classes. Seems like a half-baked idea compared to Java or other Dynamic OOPL concepts. Anonymous inner classes allows something like Smalltalk block or LISP closure type programming. This is especially useful for implementing patterns and templates, and can greatly reduce code.

Can anyone distinguish C# from CSL capabilities here? Will we have these abilities in the Mono CSL?

Re:CSL vs. C# by Anonymous Coward · 2002-01-04 05:50 · Score: 0

Hogwash.

You *can* load classes dynamically at runtime. Check out the Activator class.

There is no concept of "late binding" in c#, except for the cumbersome Reflection/Invoke functionality.

In order to dynamically load a class, you need the following

o The class name
o The assembly name
o The assembly placed in the same directory as the application, or in the GAC.
o The class adhering to a defined interface.

It is very simple to accomplish... once you know the API's.
Re:CSL vs. C# by FiskeBoller · 2002-01-04 06:47 · Score: 1

I stand corrected. My understanding is that C# does not support non-explicit late binding of dynamic loaded classes. That is, I have to know the class to load it.

In Java, only an interface need be known. I can load any implementation and not need "a class adhering to a defined interface".
Re:CSL vs. C# by miguel · 2002-01-04 06:51 · Score: 3, Informative

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:CSL vs. C# by Anonymous Coward · 2002-01-04 08:38 · Score: 0

Anonymous classes were not in Java until 1.1
As a matter of fact, Java 1.0 was very crummy until 1.1 came along...
Re:CSL vs. C# by Anonymous Coward · 2002-01-04 08:59 · Score: 0

> In Java, only an interface need be known. I can load any implementation and not need "a class adhering to a defined interface".

? "A class adhering to a defined interface" IS "any implementation" of that interface. Sounds like C# and Java have the same capability.
Re:CSL vs. C# by PixelJuice · 2002-01-04 10:32 · Score: 1

You don't need to define an interface (and .NET certainly doesn't provide one you have to implement) to use reflection.

IIRC, CLR uses the manifest to verify that you can actually get what you requested from the assembly you specified.

it's been done by hawk · 2002-01-04 05:15 · Score: 2

search through archives of alt.folklore.computers.

It's not done often,and not with modern fortran compilers, because it's generally a dumb idea :)

You can accomplish anything in either C or Fortran. That doesn't make them equally good choices for all situations.

For example, it is possible to hand-optimize C to get speed equivalent to Fortran. But why bother? For fortranny applications, the fortran code is generally shorter and quicker to write, even before the optimization. I found about 3:1 in time a couple of years back. And that only gives you the initial code; now you get to hand-optimize.

On the other hand, part of what makes Fortran faster in the first place are the very things it leaves out, allowing the optimizer to make stronger assumptions. This generally isn't a limitation when smashing matrices into one another, but the OS folks would be horrified not to have these.

Use the right tool for the right job.[1] A high level language such has fortran has no serious need to compile itself. But a language that claims to be appropriate for writing compilers and operating systems had damn-well better be able to compile itself. [and as another post hints, a Cobol compiler that could compile itself just might be scary . . .]

hawk

[1] Two caveats:
I) If force isn't solving your problem, you didn't use enough.
II) If Windows is the answer, you asked the wrong question.

*shudder* by hawk · 2002-01-04 05:23 · Score: 2

>But on all North-Americal telephone systems, the # sign is called "pound".

You're calling the octothorpe a "pound?" *shudder*. Report to a reeducation center at once! They'll also force you to move your punctuation back inside the quotation marks so that the paper doesn't tear when stuck with the printing press . . . :)

hawk

Yup.. by Da+VinMan · 2002-01-04 05:57 · Score: 2

Actually, I agree. I've really come to appreciate what the Java inertia contributed to the market; C# and .NET would probably not have been needed if Java hadn't done as well as it has.

You know, there are those of us who actually love having the choices. I hope the Java market stays strong and keeps Microsoft on their toes. Likewise, I hope Microsoft stays strong and keeps everyone else on their toes.

And as far as the rest of us are concerned, we can only benefit from this.

--
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!

Focus by wabbit2.0 · 2002-01-04 06:01 · Score: 0

C# is yet another example of the total inability
of the gnome project to focus. Yes this is a
flame, but I simply can't see how diversions like
this add any real value or contribute to what I
thought were the goals of the project.

dotGNU got a big boost today. by IsaacW · 2002-01-04 06:04 · Score: 1

Now that there is a non-MS C# compiler, the dotGNU project gets a big boost.

The dotGNU project is a viable way to take on Microsoft in a new market that they don't yet have complete control over. I encourage all developers to pitch in whatever time and code they can to this worthwhile project. Here's a quote from their webpage:

The DotGNU project was originally started in reaction to Microsoft's .NET strategy, for which it will be a complete replacement (and not just a Free Software implementation). The part of .NET strategy about which we are most concerned is Hailstorm (recently renamed ".NET My Services"), which is in fact Microsoft's attempt to gain control of the internet and its users. In contrast, the goal of DotGNU is to give computer users full freedom to use the internet as they want. For example, the DotGNU approach to "web services" will make it possible for end users to run webservice software on their own PC, so that the users are not forced to migrate their data to the webservice servers.

Playing with Fire by Anonymous Coward · 2002-01-04 06:16 · Score: 0

I am not sure about this... But, I do get the feeling Miguel is playing with fire. Somehow I have the feeling Microsft's attorneys are waiting for that particular step in the wrong direction and they will crush the GPL license per se, like THAT.

I hope some mentor is overlooking Miguel's actions. And, I hope he is not blinded by the dollars surrounding his efforts. It's a tough world when we talk money, and Microsoft has shown their attitude towards the GPL as money-destroying.

Old Joke: In what language was 1st C compiler? by Nonesuch · 2002-01-04 06:31 · Score: 2

To 'bootstrap' a compiler by using it to compile it's own source code is a very important milestone in the development of any language.

There's an old geek brain-teaser that goes like this:

Q: In what language was the first C compiler written?
A: The first C compiler was written in.... C.

How is this possible?

The story as I heard it, which I cannot find any verification of from Ritchie's web site, is that a C interpreter was written in B, and the source code for a C compiler was run through the interpreter and used to compile itself.

(The actual history of the evolution of B into C is rather complex, and it is not clear whether this fable is true.)

--

I do not deploy Linux. Ever.

I suppose... by Anonymous Coward · 2002-01-04 06:35 · Score: 0

I suppose the proper thing for a person who doesn't give a crap about C# is to not post any comments at all... and to not grace this slashdot article with the honor of a read.

EMCA even worse than that by Burz · 2002-01-04 06:49 · Score: 0

Correct me if I'm wrong, but this particular MS CLI specification is very bad indeed.

Since ECMA CLI (on Linux) will be a subset of MS CLR (on Windows), a 'ratchet' of sorts encouraging migration away from Linux is setup. MS-oriented developers and others moving to VS .NET will want to use the full range of features available in the IDE; They are not going to split hairs as to what is or isn't CLI/Linux compatible while they are coding. They will say "I want the REAL .net" and that will be the end of it.

I can't imagine that this will do anything but marr Linux's reputation as a server platform.

muddled thinking by markj02 · 2002-01-04 06:57 · Score: 2

It isn't whether Microsoft keeps backwards compatibility that matters, it is whether they add extensions to C# that are difficult to replicate.

We don't have to guess there--we already know it: most of the existing Windows APIs are available from C#. So, the situation you get into is that little C# code for Windows will work on Mono, while most of the open source code will work on Windows. That's just what Microsoft likes, and it is foolish for the open source community to deliver all these programmers and all this marketing to Microsoft. It's also unnecessary, since there is nothing in C# that hasn't been present in a number of programming languages with open source implementations.

But, hey, what can we expect from Miguel? He has said clearly that he thinks Microsoft is doing a great job on software and tLinux software should be constructed more like Windows software. With friends like these, who needs enemies?

Apps that inherently require undocumented stuff by yerricde · 2002-01-04 07:06 · Score: 1

DR-DOS and Samba have had problems because they were relying on things that are not published API's or standards.

Until DirectDraw and DrawSprocket came out, developers on Windows and Mac OS (respectively) had to resort to less-than-fully-documented techniques to get their multimedia applications to display in the full screen.

--
Will I retire or break 10K?

apples and orang by markj02 · 2002-01-04 07:16 · Score: 2

COM and CORBA aren't comparable. COM is an attempt to give C++ a dynamic object system. You have to compare COM to something like Objective-C(++), and in that comparison, COM fails miserably: it's much less flexible and much more complex. DCOM is comparable to CORBA, and it's not as good.

Re:apples and orang by Ayende+Rahien · 2002-01-04 07:44 · Score: 2

When I talk about COM, I'm talking about the whole system, (meaning, COM & DCOM as well)
Why do you think that CROBA is better than DCOM?

--

--
Two witches watched two watches.
Which witch watched which watch?
Re:apples and orang by markj02 · 2002-01-04 09:14 · Score: 2

CORBA is less tied to a particular underlying object model or platform than DCOM, and CORBA is a multi-vendor standard.
(Of course, functionally, you can do almost everything you can do in CORBA in DCOM and vice versa, but to me that's not the issue.)

It's like UNIX's home directory by yerricde · 2002-01-04 07:17 · Score: 1

I regularly test both on Win98,ME,2K, and XP, and have had 0 issues related to saving files.

Do you run as root? Apps running as a normal user under NT or UNIX clones can typically write only to the user's home folder or to the periodically-emptied /tmp, the only places most normal users have write permissions. However, SerpentMage noted that the "get home folder" call did not become documented until just before the release of the OS.

--
Will I retire or break 10K?

Re:It's like UNIX's home directory by ClosedSource · 2002-01-04 09:16 · Score: 1

"Apps running as a normal user under NT or UNIX clones can typically write only to the user's home folder or to the periodically-emptied /tmp, the only places most normal users have write permissions."

Well, in NTFS you can control access to directories with administrator privileges but I doubt that the default behavior would be to break all the legacy applications.
Re:It's like UNIX's home directory by Anonymous Coward · 2002-01-04 10:24 · Score: 0

Do you run as root? Apps running as a normal user under NT or UNIX clones can typically write only to the user's home folder...

That is absolutely false with regards to NT. The default ACL permissions on a local NTFS file system allow full control (read/write/change/delete) to everyone except for a handful of directories (ie: stuff like \WINNT) related to the NT OS itself. The "Program Files" directory has restricted permissions on it for the standard "User" group. "Power Users" have read/write permissions to files in those directories.

If you are developing applications that are to be installed on NT/2000/XP and you don't take the Microsoft guidelines for application behavior into consideration -- then you deserve to have your application fail to work correctly. If you want to be a lazy developer and do an end run around NT's default directory security just install your application outside of the "Program Files" directory.
Re:It's like UNIX's home directory by SerpentMage · 2002-01-04 11:25 · Score: 1

Believe it or not it is...

But most legacy applications have already been updated to worked properly.

--

"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"

It'd be called csharp-mode by yerricde · 2002-01-04 07:22 · Score: 1

hmm...It can't be a real language.

For one thing, Mono is not a language; it's a compiler for the C# language. In future versions of Emacs, you'll probably see a csharp-mode based on the C/C++/Java language modes.

--
Will I retire or break 10K?

Re:here is some C code that does it by Anonymous Coward · 2002-01-04 07:23 · Score: 0

char *s="char *s=%c%s%c;%cmain(){printf(s,34,s,34,10,10);}%c;
main(){printf(s,34,s,34,10,10);}

A different name... (Rhesus?) by Da+VinMan · 2002-01-04 07:58 · Score: 2

Well, I do hope they change the name. 'Mono' just resonates too well with Microsoft's "Linux is a disease" FUD.

If they like primates so much, then they should just stop monkeying around and call it 'rhesus' or something.

--
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!

Waste of Time and Talent by alec314159 · 2002-01-04 08:52 · Score: 1

This has been said before, and I'll say it again: the open-source community would be better off developing its own Free modern language than contributing to the popularity of Microsoft's replacement for Java.

Re:Waste of Time and Talent by be-fan · 2002-01-04 09:52 · Score: 2

There's no point. C# is a good language, and just because Microsoft made it doesn't make it bad. What's wrong with using an already-developed standard to create an open, free implementation?

--
A deep unwavering belief is a sure sign you're missing something...

Re:Compile itself - Li[s th]p by Anonymous Coward · 2002-01-04 10:42 · Score: 0

If I remember correctly, Li[s th]p was originally a pseudolanguage for teaching. McCarthy used to translate programs written in Li[s th]p into assembler by hand, until he realized that he was making a lot of hard work for himself and the computer could probably do it all for him.

So he wrote a compiler for it, and so on and so forth, ...

Not enough C# by GCP · 2002-01-04 12:00 · Score: 2, Insightful

*And* not enough functional language articles.

One thing that disturbs me is how difficult it is for an elegant new language to replace the old hairballs that no longer resemble anything that any sensible person would have designed and are no longer used for what they were originally designed for.

New languages require extraordinary advantages outside the language itself for them to stand a chance at significant popularity. C# is the first since Java to have enough "outside" advantages to make it a realistic candidate to replace C++ for GUI apps.

I'd love to see some of the best functional languages get enough attention that maybe one of them could be in the right place at the right time to also join the exclusive club of Languages That Employers Actually Care About. More attention on Slashdot couldn't hurt.

--
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."

100% right! by GCP · 2002-01-04 12:33 · Score: 1

So true. If C# had started out on Linux, the Slashdotters would have been crowing about it as a magnificent step forward in GUI/application development.

*As a language*, it's an extraordinary improvement over what commercial developers realistically are forced to use for commercial GUI app dev: C/C++ or maybe VB.

--
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."

XPCOM != COM or DCOM by MenTaLguY · 2002-01-04 14:07 · Score: 2

XPCOM is a different beast from Microsoft's COM.

CORBA is more comparable to DCOM, btw.

--

DNA just wants to be free...

Cowboyneal# by Anonymous Coward · 2002-01-04 14:42 · Score: 0

I was always told to be careful when playing with sharp objects.

Close To Home by Anonymous Coward · 2002-01-04 16:15 · Score: 0

The important thing here, as I see it, is that all developers stay close to the developing compiler code and the groups responsible for it - the so-called Mono-Nucleoses.

Mod this one up to +1 Insightful by Bake · 2002-01-04 16:58 · Score: 1

see subject

Don't you get it!! by Anonymous Coward · 2002-01-04 17:08 · Score: 0

C# is people!! C # IS PEOPLE!!

-entro

(m$ is bad for children and other living things).

Thompson's hack by jyasskin · 2002-01-04 19:17 · Score: 1

http://www.acm.org/classics/sep95/

Implement how? by yerricde · 2002-01-05 05:25 · Score: 1

The default ACL permissions on a local NTFS file system allow full control (read/write/change/delete) to everyone except for a handful of directories (ie: stuff like \WINNT) related to the NT OS itself. The "Program Files" directory has restricted permissions on it for the standard "User" group.

Yes, but before NT was released, how were developers supposed to have known about the Win32 API call to retrieve the name of a directory into which the application is supposed to write?

If you are developing applications that are to be installed on NT/2000/XP and you don't take the Microsoft guidelines for application behavior into consideration

I would, but such guidelines (or the means for implementing them) are not available to the general public until two weeks before the release of the OS.

--
Will I retire or break 10K?

Compiler Maturity by ka9dgx · 2002-01-05 10:48 · Score: 2

A compiler is really mature when it can take languages A and B and translate either way. Anything less is nice, but not quite up to par.

--Mike--

Re:Compiler Maturity by mikera · 2002-01-16 09:34 · Score: 2

That is indeed nice. Though I suspect that if one of the two was a lower-level langauge, then the translation to the higher level would either be very difficult or very inefficient, and the whole compiler is less useful if the two were the same level.

I can't think of an example of either type, apart from a pet langauge project I saw that had this as a specific goal - and used langauges that were all pretty much equivalent in data types and functionality.

Re:Yay! We've really needed this. by seebs · 2002-01-05 12:17 · Score: 2

I particularly like the way people use mod points to suppress opinions they disagree with. Go slashdot! Keep the groupthink up.

--
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/

COM vs CORBA by -=Zak=- · 2002-01-05 13:42 · Score: 1

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.

Well, at least the C++ ORB I use (OmniORB - a very nice, highly efficient, open source ORB produced by ATT) is very fast while running in-process. This implies that your comparison only applies to ORBs implemented in such a way as to perform badly under those circumstances.

Re:COM vs CORBA by Ayende+Rahien · 2002-01-09 06:52 · Score: 2

Do you have speed measurements vs. COM components?

--

--
Two witches watched two watches.
Which witch watched which watch?

Fear Uncertainty Doubt by Tony-A · 2002-01-07 07:13 · Score: 1

FUD
I am facing a menu that accepts a single character input. Will the letter be in upper case or in lower case? There is a CapsLock light on my keyboard, but it often lies. Which menu choice will I really be making.
FUD

"Embrace and extend" by malxau · 2002-01-10 18:10 · Score: 1

What makes you think Microsoft would do that? Do they want to take over the entire industry by pretending to support standards while working to undermine them...

With total respect to the Mono team, Linux coders, please don't use C# or .NET...

Slashdot Mirror

Mono C# Compiler Compiles Itself

339 comments