Slashdot Mirror
Microsoft Starts Working On an LLVM-Based Compiler For .NET
An anonymous reader writes Are the days of Microsoft's proprietary compiler over? Microsoft has announced they've started work on a new .NET compiler using LLVM and targets their CoreCLR — any C# program written for the .NET core class libraries can now run on any OS where CoreCLR and LLVM are supported. Right now the compiler only supports JIT compilation but AOT is being worked on along with other features. The new Microsoft LLVM compiler is called LLILC and is MIT-licensed.
How did Ballmer push developers aside? Under the latter part of his reign, Microsoft started open sourcing a lot of their developer frameworks etc (ASP.Net MVC in 2012, Entity Framework in 2013 etc) and we saw fairly large shifts in developer conferences and support.
Well I can say these announcements have brought me back to developing in .Net. C# has been my favorite language by far ever since v3.5 (and was my favorite by a little since v2.0) but its vendor lock was becoming too much of a liability.
The moment I can go back to C# and easily have my code run on *nix servers I will drop Java in a heartbeat. Just being able to use LINQ again in my professional life will be a blessing. And going back to Visual Studio over Eclipse / Netbeans / and even IntelliJ is also something I have been longing for.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
How did Ballmer push developers aside?
He pushed them aside by killing development systems (VB6,FoxPro), introducing new technologies with the promise of how critical they were to the future (Silverlight), and allowing the crown jewels of Windows development, the Win32 API, to slowly become more irrelevant with endless layers of cruft built on top (eg. .net, although a wonderful system, becomes more and more incompatible with the underlying OS; eg. GDI+).
Microsoft started open sourcing a lot of their developer frameworks etc (ASP.Net MVC in 2012, Entity Framework in 2013 etc) and we saw fairly large shifts in developer conferences and support
By your own words, we can infer that Ballmer's middle-empire period required large shifting from where it was to what it became.
Ballmer wasn't bad; his jumping around on stage shouting "Developers!" showed that he knew what the true value of Windows was: the external developers who wrote Win32 code for retail products or company-internal developers. However, his middle-empire stage was a shift to focusing on selling to enterprise customers. This isn't a bad things by itself, but by taking his eye off the "Developer!" ball and focusing elsewhere, he guaranteed that plenty of developers went elsewhere. For example, with the death of VB plenty of developers shifted to Java rather than .net. The fact that it needed a large shift in support shoes just how far developers had slipped in Microsoft's priority.
It's interesting to see how Nadella is shifting the focus again and broadening it (Windows 10 on Raspberry Pi, for example). Time will tell if Nadella is simply being an anti-Ballmer or if this glasnost is signs of a more fundamental shift in the way Microsoft does business. I hope it's the latter.
With LLVM using an intermediate representation of code (LLVM IR) and CLR another : MSIL, now called CIL, does that mean it goes C# -> LLVM bytecode -> .NET bytecode?, does the JIT does both steps at once, why doesn't that mean every single language with a LLVM target can now run on the CoreCLR?, was LLVM modified, was what's in my first question horribly wrong?
VB6 and FoxPro served their purpose and needed to end. They were prototypes for various parts of what became .Net.
VB6 was discontinued right away when Microsoft combined VBRUNxxx.DLL with their Java implementation that got shitcanned by the anti-trust courts. Then they refined it into a common language runtime for a VB variant, a Java variant, and a heavily modified variant of C and all of the object oriented stuff that has cropped up around it. Later, they dropped the Java variant. Later still, they added a functional programming language.
FoxPro was discontinued when they released LINQ, which basically mimics the one thing FoxPro had going for it that nothing else did.
Win32 has not become "irrelevant", since all of the newer technologies still rely on those older ones. (.Net "winforms" simply packages up the old Win32 WNDCLASSEX and window class registration and instantiation into a handy Form object, so instead of 80+ lines of boiler-plate code, you use a simple new Form() and be done with it. I fail to see how this is anything but progress.)
And .Net uses GDI and GDI+ directly, and has done so since day 1. More recently, it also uses Direct3D and Windows Media Framework directly.
It's actually rather amazing that otherwise well-informed people on tech sites keep parroting this panicky crap that naysayers said years ago without doing any research into whether it's correct or not. It seems that the one thing Microsoft hasn't been able to change is the level of trust people place in them. A good portion of that was earned, but it's also about time that some people at least brush a few of the chips off of their shoulders.
I completely agree with everything you've written... if you're a .net programmer, you're fine. But if you're a C programmer sitting directly on top of Win32, you're screwed
Lots of cutting-edge applications are still written in C or C++ and directly use the Windows API (it's not called Win32 anymore). In fact, I'd go so far as to say the majority of large commercial applications you can think of are native apps: Photoshop, Microsoft Office, most videogames, web browsers, media players, etc, etc. Nearly all the new APIs released with new versions of Windows are available to native applications. There's no reason a company has to abandon their legacy C codebase if they don't want to. BTW, the "way forward" for C developers is called C++, and it's conveniently backwards compatible with your C codebase.
The major reason one would consider switching to .NET from native code is productivity, not new functionality. The .NET APIs are much easier to use than the much older Windows APIs, and the languages .NET supports like C# are far easier to use as well. You don't even have to completely abandon your C or C++ code either. It's pretty simple to write interop layers to communicate between C# and C, and have done so many times at work.
Irony: Agile development has too much intertia to be abandoned now.