Slashdot Mirror
Microsoft Previews Compiler-as-a-Service Software
angry tapir writes "Microsoft will release a Community Technology Preview of a new type of compiler its researchers have been building — code-named Project Roslyn — a company executive announced Thursday. Roslyn is a compiler for C# and Visual Basic with a set of APIs that developers can use to fine-tune their code. It resembles a model developed by the Mono Project, in which the information the compiler generates about a program can be reused as a library."
I don't think you even really read the summary... it essentially comes down to offering more compile abilities into an application. This can work for extensible plugins, and scripting. It is not the compiler offered via a SaaS (Software as a Service) model.
Michael J. Ryan - tracker1.info
http://cm.bell-labs.com/who/ken/trust.html
It is left as a exercise to the reader to see the point I'm trying to make.
It's not about software-as-a-service compilers, it's about exposing the internal data structures and information a compiler produces to the programmer. This lets you go a level beyond introspection and into some interesting possibilities.
I do not fail; I succeed at finding out what does not work.
No, you're not getting it right, this is a service as in a process always running on your computer, not as in a cloud based compiler. The point is your program can dynamically call the compiler with additional source code to be compiled so your program can modify itself even though it's in a relatively static language like C#.
not 'service' as in 'zuckerberg/NSA world domination'
However, even if you get a free compiler like gcc, you either get the source (which you then have to compile yourself, shifting the problem to the compiler you use to compile it) or you get a precompiled version where you have to trust that whoever compiled it did not insert a backdoor.
Actually the only way to be completely sure without trusting anyone is to actually study the generated machine code (that's assuming you can trust your computer to faithfully execute that, of course). Of course in practice nobody would go that far (and few would even have the resources to do so), but instead there's one point where you put trust in (possibly the compiler+linker), and from there on you just go on.
Of course, another way would be to bootstrap by writing yourself an assembler in machine code, then a compiler for the source language of that compiler in assembly (using your self-written assembler), and then use that to compile the compiler you got in source (and to get an optimized compiler, compile the compiler with that compiler again). But again, few people have the resources to do so.
Well, one way to increase trust would be to build the source-provided compiler with two different compilers, then use both of these generated compilers to re-compile the compiler, and then compare the generated executables. If only one starting compiler has been compromised, or if both have been compromised independently, then the compiler executables thus generated will differ. Thus if the compiler executables generated that way are the same, they are very likely not compromised, or else there's a conspiracy and both original compilers contain the same malicious modification. The more separate compilers you add to the mix, the less likely a conspiracy becomes (and moreover if some compiler is really compromised, you'll also learn which one -- although you cannot exclude the possibility that the difference is just due to a "self-propagating bug" instead of due to malicious code, but then, neither is desired).
The Tao of math: The numbers you can count are not the real numbers.
My main reason for disliking VB.NET is I don't want to wreck my VB6 skills.
While I wouldn't voluntarily want to go back to VB6 development ... well, it's something to fall back on. There's so much VB6 software out there, that it's the COBOL of the future - people are likely to be wanting skilled VB6 developers and they are probably going to have to pay through the nose for them. A nice little pension plan.
VB.NET is close enough to VB6 in syntax, but different enough to ruin my memory of VB6. So I have avoided it as much as possible. As another poster points out, it's essentially C# with some different syntax sugar.
the whole point of computer languages was to make it easier for the programmer
That's very true and that's why I use Python a lot, despite having learned to write software in the 1970s, in FORTRAN in an IBM/370.
However, there's a moment when ease of use limits the programmer if he needs to go to the limits of performance. We are used to think that we have CPU enough, so it's not necessary to optimize for performance anymore.
That might be true for business software, under some circumstances. Scientific and engineering software, OTOH, could still use a lot more CPU than what we have right now. This means you may need to reorganize your data structures in some non-obvious way.
When you need to invert a matrix, for instance, which is one of the most common operations you do in number crunching, you have to keep your data carefully aligned, you need to take advantage of what vector operations your hardware does and consider how the cache is handled. You cannot do this with object oriented programming, you need to define memory allocation and use pointers to manipulate data. Object oriented programming will not work in this case.
I may use Python to develop algorithms, but for doing real jobs only C or Fortran will do.
You "new" it was better? I believe the word you are looking for is "knew".
Also, Mono is an implementation/compiler for .NET, not a replacement. So, if mono is better than (Visual Studios, and the MS .NET run time, I'm guessing you are referring to?) Then I'm guessing you don't want to kill .NET because that would also kill Mono, which is .NET.
To emphasize this point, I compile programs on both Mono and Visual Studios 2010/MS Runtime. I then run programs compiled on either system to run on the other.
Both are AMAZING pieces of work.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
You also can't trust food you didn't grow yourself. Doors and locks you didn't build yourself. People whom you haven't given birth to and watched from infancy. The level of paranoia represented by that quote is borderline hysteria. [a.s.o.]
If you'd stop to think a moment instead of rambling...
Speaking hypothetically, say I'd be a hacker... wouldn't it be nice to successfully attack "an always running compiler service", inject a little DLL there, and make all the applications you'd build and deploy in your organisation spy for me? Still think is hysterical paranoid? Or do you trust Microsoft to make this "compiler service" impervious?
Questions raise, answers kill. Raise questions to stay alive.
From TFA: "It also adds dynamic typing to the statically typed C# and Visual Basic, allowing developers to add objects and new variables to a program on the fly."
So it turns VB/C# into...Obj-C!
*ducks*
I chose to end my comments, not with a rim shot, but a long decaying F#7sus4
No, I'm not. I only assumed that two correctly working compilers would output functionally equivalent code (what I tacitly did assume was that the source-provided compiler doesn't invoke undefined behaviour, though). Note that I did not propose to compare the output of the two different compilers, but to compare the output of the one source provided compiler compiled with two different binary-provided compilers.
So say you have the source of gcc, and binary versions of Microsoft C and Borland C.
Step 1: You compile the gcc source code with Microsoft C (let's call the resulting binary vgcc).
Step 2: You compile the gcc source code with vgcc (let's call the resulting binaty gvgcc).
Step 3: You compile the gcc source code with Borland C (resulting in bgcc).
Step 4: You compile the gcc source code with bgcc (resulting in gbgcc).
Step 5: You compare gvgcc with gbgcc.
If both Microsoft C and Borland C correctly translate the gcc source code (and the gcc source code contains no undefined behaviour), then vgcc and bgcc, while not the same, have equivalent behaviour. Especially they both translate the gcc source code into the same executable. In other words, gvgcc and gbgcc must be binary identical.
The Tao of math: The numbers you can count are not the real numbers.