Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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

No no, you're thinking C#. Which is not in any way to be confused with C3. Which is not at all a typo that completely slipped through... Nothing to see here. Move along./s
VB6 is dead, but VB.NET is still alive and kicking (sadly) both as a transitional language from VB6 and as a language for new projects, but IIRC Microsoft suggested C# and avoiding VB.NET where possible.

There are some who claim that its somewhat verbose syntax ('dim varname as vartype' instead of 'vartype varname;' for example) and Basic-like loop and code structure make it an inherently worse language. It looks kind of ugly to an experienced developer in C-style languages, but I honestly don't see much basis for disliking it beyond a degree of elitism that drives one to scorn a highly readable "easy to learn" language.

Under the covers, aside from a few assemblies specificlaly to aid compatibility with leg

...I honestly don't see much basis for disliking it beyond a degree of elitism that drives one to scorn a highly readable "easy to learn" language.

I know someone, a Perl programmer who thinks Python is too "childish" - IIRC is how he put it.

I think it's a bit ironic that many programmers and other CS types have this elitism towards easy to learn language when the whole point of computer languages was to make it easier for the programmer. No one seems to remember their CS history and how human readable languages were developed because assembly and machine code was just too cumbersome.

The problem is that producing a programming language with verbose keywords and so on doesn't actually make it any easier to work with, at least once you get beyond trivial levels. The easiness is superficial. Once you get beyond the surface level (which most people can do in a matter of just a few weeks working with a language) the verbosity just gets in the way of seeing the truly important things. And the consistency of c-like syntax means there's actually less stuff to remember. How do you end the bl

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 rig

This is done all the time with object oriented programming. Perhaps what you meant to say is that you can't do this with object oriented languages that hide pointer arithmetic. That would be true. It would also be true that you can't do it with procedural languages that hide pointer arithmetic.

Perhaps what you meant to say is that you can't do this with object oriented languages that hide pointer arithmetic

Yes, that was what I meant. You could do it with objects in C++.

Problem is C++ has so many quirks that what I often do is to think in objects but implement in plain C. Object orientation is a principle that you can apply even if your programming language doesn't support objects.

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 avoid

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.

There will be a market for VB6 programmers for a while. I'd be willing to bet there will be a nice market niche for individuals or small firms that do nothing but VB6 to <insert new language> conversions for years to come.

I've finally convinced one of my clients to port their code over from VB6 to *something else* (I've been trying to get them to switch since 2006). Their VB6 programmer/Access person is retiring next July and they've finally seen the light that their VB6/Access solution needs to be

There's so much VB6 software out there, that it's the COBOL of the future

Most COBOL software is extremely complex stuff running on mainframes of banks and insurance companies.

Most VB6 software is something that was coded in 15 minutes to fill a need in a lab computer, or a frontend to some command-line program that isn't written in VB. This is not me looking down upon VB6, that's just what VB6 was designed to do: it's easy to learn and you could get something running on it fast, so that's what people did when they just needed something quick. The result of it is that if someb

I've been following your threads on this topic - an I felt I have to chime in, because I think you have an honest misunderstanding of the technology.
I have written rather large projects in both VB.NET and C#. I currently work on a MSIL decompiler. The language syntax is very different, and VB. NET is similiar to vb6 in syntax.
I believe your misunderstanding comes from the behavior of the languages, which the people arguing with you are pointing out.
You can take _any_ program written in C# or VB.NET, a

That's a brilliant article and should be required reading. It's good enough reason to not use Microsoft's present compilers.

Just for the record, though, the article doesn't seem to suggest anything about actual compilers as a service; it still seems to discuss a normal compiler that runs on your local machine. Very confusingly titled.

It is left as a exercise to the reader to see the point I'm trying to make.

I don't think that's any more relevant now than it has been for decades when using proprietary, binary-only development tools from MS and others. Thompson's point was that even having source, which was always assumed on Unix systems, is not sufficient to prevent trojans for being inserted into code.

The description "Compiler-as-a-Service" is misleading. It doesn't mean that people will ship their source to MS and get back object code. It simply means that the compiler exposes an API for introspecting code. T

I thought I was already using System.CodeDom.Compiler to dynamically create assemblies?

Also, converting code from one language to another isn't new in the slightest. Redgate's Reflector has been disassembling IL and displaying it in C#, and VB for ages. I'm sure there are open source equivalents too.

I fail to see what all the excitement is... Unless they're able to give me an AST to mess with? Even then I might not be terribly interested.

The Compiler as a Service system should give us some form of AST. This should be exactly the same AST as Microsoft uses for Intellisense, since one of the goals of this project internally was to allow Intelisense and the compiler share as much code as possible, since they previously had separate implementations of some analysis passes, and other complicated code, with the Intellisense version not full matching the version in the compiler.

I suspect we may also have the capability of manipulating the AST, and

Pentium Processor Optimization Tools by Michael L. Schmit comes with a floppy that contains an "Optimizing Assembler". It doesn't actually optimize your code, but produces a formatted listing that gives the timing of each instruction, as well as pipeline stalls and the like. One can then use the listing to refactor the assembly source to be more efficient.

The book is long out of print but can easily be had used. It's also a good book for learning x86 assembly in general.

The title on the article is misleading. The author is confusing the "Software as a Service [wikipedia.org]" distribution model with the "Just In Time [wikipedia.org]" (JIT) compilation model. The article subject is about how Microsoft, through the Roslyn architecture, is allowing SDK level access to the JIT compiler that runs the.NET applications on the host computer.

Whereas you are confusing "compiler" and "JIT compiler" here. Roslyn has nothing whatsoever to do with JIT-compilation of CIL bytecode to native code. It is about compilation of C# and VB source code to CIL bytecode - but more than that, since it also exposes intermediate steps (such as AST).

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.

IIRC Apple's compiler is or was gcc, I seem to recall them moving to another (also open source?) compiler a while back. Regardless, Apple compilers are more or less standard C/C++/ObjC. The trick with iDevices is getting the compiled code onto the device. You can write, compile, and test IPhone apps all day with free tools on any Mac, or even a (questionably legal) Mac VM. Getting your code onto an iPhone requires either a license or cracking the device.

I think Apple developed Clang [wikipedia.org] as the frontend with LLVM as the backend instead of GCC. It is mostly GCC compatible but the main reason probably had to do with the licensing. Clang and LLVM are BSD style while GCC is GPL.

I agree 100%. I'm a huge distcc fanboi, but outsourcing compiling of code scares the shit out of me. I'd expect to see a security vulnerability where faulty code was somehow delivered to you. It's a backdoor that you run yourself, as you expect the compiler to return, you know, a compiled version of what you gave it. Nasty things in 3... 2... 1...

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.

I don't think you read the (already classic?) Ken Thompson's Reflections on Trusting Trust [bell-labs.com]
"You can't trust code that you did not totally create yourself." - if your binary compiler injects a backdoor in the object code, then even recompiling the compiler from source may not get you out of the woods.

Otherwise, let point to you the (in my opinion) relevant phrases in TFA:

Today's commercial compilers are black boxes, Hejlsberg said.

While Hejlsberg is probably right, fortunately in this world there are such things as non-blackbox-compilers.

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 no

You're assuming that two different compilers would output identical binary images, but why would they? Different authors would implement different instructions in different ways. I'd expect that behavior only from a simple assembler.

From there maybe you could go on to compile a fairly simple reference compiler to compile your higher level languages, as you were discussing. But I doubt you could do a meaningful binary diff of the output of the Intel C compiler and gcc.

You're assuming that two different compilers would output identical binary images, but why would they?

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 compi

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.

I challenge that this is as hard as it sounds. The bootstrapping homebrew compiler doesn't have to be fast or efficient, and doesn't have to produce fast or efficient code, it only has to be *correct* the one time you use it. You'd then use it to compile gcc, which to my understanding is implemented using only C (not c++) features.

So time to bootstrap a correct C-compliant compiler? In my arrogance, I bet it could be done in 6 months by a few dudes in a garage. Which if you're in a field that needs bull

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. If you applied that mantra to any other area of your life you'd have to live in a sealed commune, by yourself or maybe with with a single (well vetted and not allowed to leave) life partner. Of course you can't trust any software you didn't create yourself... Like anything e

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?

There's at least two points of failure in your counter here. First, what Microsoft is proposing here isn't a "software as a service" compiler, the title of the article is simply wrong. It's simply a compiler that provides a lot more access to the internals than current compilers (at least current MS compilers). Anything that a hacker could do to this compiler, he could do to a normal MS compiler. He'd have to have the same level of access to your box to modify this as he would to insert new code into yo

There's at least two points of failure in your counter here. First, what Microsoft is proposing here isn't a "software as a service" compiler, the title of the article is simply wrong.

Nope, this one is not: I didn't assume this service in the SaaS meaning (not this time anyway).

Anything that a hacker could do to this compiler, he could do to a normal MS compiler.

Not quite... lately it became easier to attack a running process than to "infect a file" (signed executables and whatnot), especially if that process is a server accepting request from other processes running under user privileges.

Second, that's not what you said. What you said was that any compiler that you haven't coded and built yourself is untrustworthy.

I didn't intend to say this, but to point the extra weakness: not only a file (the compiler executable image) but now an always running process as well (even if I admit, my intention was

"You can't trust code that you did not totally create yourself." - if your binary compiler injects a backdoor in the object code, then even recompiling the compiler from source may not get you out of the woods.

Otherwise, let point to you the (in my opinion) relevant phrases in TFA:

Have you read all the code of your OS? Your compiler? Have your read the code of each compiler that was used in the chain, back to the very first one written in assembly/hex?

If not, then you are really not in much of a better position than you would be using a closed source compiler.

If not, then you are really not in much of a better position than you would be using a closed source compiler.

Well, even if I didn't, I'd argue I'm in a better position when using open source compilers... granted, not 100%.And certainly more secure if using a compiler as a tool than a compiler as a service always running... on a Windows box.

Doesn't mean this is a bad idea, it just means, like every other piece of computer tech, use with caution. On a Linux or BSD box, it's pretty damn easy to mimic a service if you don't need access to ports below 1024, and screen is installed, for example. With just those two caveats, there's a lot you can do that is really unpleasant. You don't even need a "service" to patch into.

I think Microsoft understands the risks involved with allowing self-concealing malware to be released in its compiler - corporate death to the tune of >$230B. Nothing could possibly drive developers and customers from their platform faster than if such a thing were to happen. Indeed, it's in their vested interested to ensure that such a thing doesn't happen.

Does GCC have such a risk? Even if the project were to die because of such a thing what would anyone lose beyond a littl

Have you read all the code of your OS? Your compiler? Have your read the code of each compiler that was used in the chain, back to the very first one written in assembly/hex?

You act as if limiting the number of vulnerabilities is a bad thing. Are we ever 100% secure? No. But that doesn't mean we should allow more vulnerabilities if we can help it. Will installing a good lock on my house protect it against all thieves? No. But if my current lock has a defect that allows it to be easily bypassed, I can replace it if I want.

I don't see the alternatives as a reduction of vulnerabilities in this case, unless you actually bother to look at and parse the code of the entire chain, or at some point hand recompile the binaries. I will never do this, and therefore, I gain no advantage.

What part of adding another point of vulnerability isn't clear? Do you have to trust MS if you have Windows? Yes. But any code you write yourself is assumed not to have backdoors if you compiled it yourself. Having another party compile it for you adds a another layer of checks. Does the benefits outweigh the risks? Not in my book.

I don't trust MS any more or less than I trust the developers of Linux and it's associated tools. So, swapping one for another doesn't really bother me. The question is - is the benefit from the tool worth the extra layer.

And assuming code you write/compile yourself has no back doors is idiotic. People doing that, and then selling it, is how many security issues come about..

And the compiler would still run on your machine, not a remote machine, so... You'd still be compiling it on your machine. Yes, it's a closed source compiler, but I don't want to waste years trying to comprehend the code clusterfuck that is GCC, so GCC is just as closed source for my purposes - I don't see an added risk.

And assuming code you write/compile yourself has no back doors is idiotic. People doing that, and then selling it, is how many security issues come about..

What? I am assuming that unless I have some sort of split personality like in Fight Club, I am not going to program a backdoor without my knowledge. Now I may not know the existence of every conceivable vulnerability but if you don't know the difference between the two, you should brush up on basic computer literacy.

And the compiler would still run on your machine, not a remote machine, so... You'd still be compiling it on your machine. Yes, it's a closed source compiler, but I don't want to waste years trying to comprehend the code clusterfuck that is GCC, so GCC is just as closed source for my purposes - I don't see an added risk.

Again, brush up on computers and read the article. Running compiler as a service may allow for execution of code that you do not intend. As an example, take the simple door lock which can b

If you took the care to let your mouse hover on the link you'd see that the article's title was "Microsoft previews Compiler-as-a-Service software". The article's author used a very bad analogy-of-an-analogy and that's what's causing this confusion.

I heard Compiler as a Service and thought at first, "Oh great, Microsoft feels the big threat by Google App Engine, and that Python is going to take all of their business, so they've created a Python killer."

It will play into the Azure platform if it's a pure service. You can run an application on Azure with a SQL backend, and have this new compiler service build it for you.

Although from the article, I didn't even get a sense of that being the purpose. From what i was seeing, it's just a service you can run while developing that will give you more insight into the compiler's workings. You access it via VS2010 like you normally do.

I'm curious how this would play into TFS as well, if you could get more informatio

it means nothing like this (and i hate the name of it because of it). it means you have much more ways to use the compiler. it still is on your desktop, still 100% in your control. but it's not a blackbox anymore, it's now something you can plug in own stuff, extend, reuse, etc.

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.

Of course it's about software-as-a-service compilers. The only way MSFT can give you this ability to look what the compiler does is by keeping the compiler binary from you (compiling as a service by MSFT) or giving you much more insight on how the compiler works, basically open sourcing it. The latter is obviously anathema, so they provide it as a service. And if it catches on, it's another awesome lock-in capability by MSFT. Awesome!

I'm not saying this isn't good, it clearly is, but it highlights a difference between open source tooling and closed tooling: Both gcc and Microsoft's compilers need to be able to show their own developers the internals in order for them to write good compilers. Because gcc was open source, though, they could build this in a way that made it available to their user base, whereas Microsoft had to hide or remove theirs before shipping.

There is something about this concept that I find very threatening. Service Orientated Architecture is no doubt a good thing and Software as a Service can save costs. However with something as simple as a compiler being outsourced to the platform vendor, this returns control over software creation that can be produced squarely with the vendor.

Imagine a vendor that could suppress the compilation of software that it deems unfavourable. A company would never refuse to provide a compiling contract to a business that makes products that compete with the vendor, would they? They would not create a terms of service that deems what software is appropriate to be compiled?

Have you ever heard of Apple's App Store? It's this crazy store which is the only place you can get applications for your phone or tablet, and Apple controls every piece of software published on it. Apple also imposes arbitrary bans on applications whenever Apple sees fit. Apple is also trying to push this model to their laptops and personal computers. Furthermore if you want to make your own applications run on your iDevice you have to pay apple $100, or violate the TOS to unlock your phone. That's r

What is preventing anyone from doing just that with local compilers? I mean, its not like you can't switch from one compiler to another if one provider decides to be a douchebag and ban specific use. That will be their problem, and that's what competition is for. But I don't really see why that should be worse for 'services', at least in practice.

Cross compiling is currently a bit of a bitch though. I would like a cloud compiler helping with building for different platforms at once. Provided you could freely download the compilers yourself of course.

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

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

Although I dont think such a thing exists yet, C3 could indicate another stage. Compiler research has been an ongoing thing at Microsoft, and the in-development Phoenix Framework [wikipedia.org] continues to use a stage-2 compiler (still named c2.exe)

Are you a troll, or just dim? If you don't understand anything the article speaks about, it might be a good idea to just not comment.

If I'd follow your advice:
1. I'd lose the chance to stand corrected - I'm not afraid to be in such a position, I'd suggest you to try sometime.
2. life may become a bit boring for you. I mean, you wouldn't have too many occasions to call someone a "troll or dim-witted". How would you like "good manner and menuet dancing" all the day everyday?

I'm sorry. The title of this article is bad. SaaS has an established meaning and it does not necessary mean the services running in the background (as a service) on your PC, it means using remote services.

The article makes no mention where the actual compiler runs. If it runs remotely, are our fears are not unqualified.

The compilers do not run remotely. They will continue to be local applications installed with every copy of the.NET framework.

The Compiler as a Service concept mostly just exposing the the compiler's AST to the calling program. It has no relation to SaaS.

This is of great benefit to authors of tools that read and manipulate source code, since they no longer need to implement their own AST and parser, and can instead use the one of the compiler, which ensures that they never reject code that the compiler wil