www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - OT; Will MS kill .NET ?

reply "Nick B" <nick.barbalich gmail.com> writes:
Hi.

I can across this off-topic. It is 2 years old, but it seems well 
written.

http://i-programmer.info/professional-programmer/i-programmer/2591-dumping-net-microsofts-madness.html


Here is a preview book from MS, to back up this point above:

http://blogs.msdn.com/b/microsoft_press/archive/2012/08/20/free-ebook-programming-windows-8-apps-with-html-css-and-javascript-second-preview.aspx

Has anyone heard anything more up to date ?  Will MS just let 
.NET slowly die ?

Nick
Aug 19 2013
next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 19 Aug 2013 18:28:37 -0700, Nick B <nick.barbalich gmail.com>  
wrote:

 Hi.

 I can across this off-topic. It is 2 years old, but it seems well  
 written.

 http://i-programmer.info/professional-programmer/i-programmer/2591-dumping-net-microsofts-madness.html


 Here is a preview book from MS, to back up this point above:

 http://blogs.msdn.com/b/microsoft_press/archive/2012/08/20/free-ebook-programming-windows-8-apps-with-html-css-and-javascript-second-preview.aspx

 Has anyone heard anything more up to date ?  Will MS just let .NET  
 slowly die ?

 Nick

They'd LOVE to, but they can't, it's just to entrenched on the server. They're working on replacing it slowly with node.js and the like, but it'll be a LONG time before server devs are willing to use it for mission critical stuff, if they ever are. More likely, it'll end up like Java, pay VERY close attention to moves that Miguel de Icaza makes very carefully, nobody is better positioned to take up the .NET flag than him and his crew at Xamarin. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Aug 19 2013
parent Gambler <fake feather.org.ru> writes:
On 8/20/2013 3:18 PM, Paulo Pinto wrote:
 On Tuesday, 20 August 2013 at 16:07:00 UTC, Kagamin wrote:
 http://msdn.microsoft.com/en-us/library/system.type.makegenerictype.aspx
 How would you implement this in native code?

Like we use to do in the old days when we were forced to rewrite Assembly on the fly. Allocate a memory buffer with the required sizes and perform the required set of initializations. This is no different than constructing C++ classes during runtime, initializing the required helper structures like vtbl and calling constructors. Nothing that cannot be done with either a set of helper functions on the language runtime, or generating inline code. Yes, I am aware that this requires the ability to execute code from the data segment. -- Paulo

Isn't the approach you're describing *much* more error-prone than the example above?
Aug 21 2013
prev sibling next sibling parent =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
I thought that, if anything, Microsoft was regretting going too 
high-level.

There is a video from Channel 9 with Herb Sutter (perhaps [1], 
not sure) where I recall him saying that the .Net mania had died 
out and Microsoft developers were again focusing on C++.

[1] 
http://channel9.msdn.com/posts/C-and-Beyond-2011-Herb-Sutter-Why-C
Aug 19 2013
prev sibling next sibling parent =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
BTW, I was disappointed to find out (and I had to dig through 
several contradictory articles to clarify that) that WinRT is not 
planned to (eventually) be the new core Windows API (the lowest 
level one, ignoring the NT "native" API) , upon which higher 
level APIs (like .Net) are built.

Things (like WinRT itself) are going to still be built upon 
Win32/64, with all the cruft, and WinRT is just a side 
alternative -- a facade to the old crufty API and all its 
compatibility issues, not something authoritative. For instance, 
windows paths will still have the old Win32 limits, even if the 
NT API (and WinRT) is less restrictive.
Aug 19 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 20 August 2013 at 01:28:38 UTC, Nick B wrote:
 Hi.

 I can across this off-topic. It is 2 years old, but it seems 
 well written.

 http://i-programmer.info/professional-programmer/i-programmer/2591-dumping-net-microsofts-madness.html


 Here is a preview book from MS, to back up this point above:

 http://blogs.msdn.com/b/microsoft_press/archive/2012/08/20/free-ebook-programming-windows-8-apps-with-html-css-and-javascript-second-preview.aspx

 Has anyone heard anything more up to date ?  Will MS just let 
 .NET slowly die ?

 Nick

Usually these articles are written by people without proper Microsoft ecosystem experience. I do consulting both on Java and .NET worlds mainly. .NET is still going strong, Microsoft has done quite a few updates in the form of .NET 4.5 recently and most talks at BUILD 2013 were about .NET. What has happened was shift to the native runtime WinRT (which is basically COM) as the common platform. Althought only for Window Apps, not desktop based. .NET is fully supported and no different than MSVCRT for C(++), or phobos for D. -- Paulo
Aug 20 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 20 August 2013 at 02:20:38 UTC, Luís Marques wrote:
 I thought that, if anything, Microsoft was regretting going too 
 high-level.

 There is a video from Channel 9 with Herb Sutter (perhaps [1], 
 not sure) where I recall him saying that the .Net mania had 
 died out and Microsoft developers were again focusing on C++.

 [1] 
 http://channel9.msdn.com/posts/C-and-Beyond-2011-Herb-Sutter-Why-C

With the failure that Longhorn and Vista were, the .NET political camp inside Microsoft lost power to the native guys. I bet this is what was behind the WinRT decision, because the original .NET design documents for .NET were actually based in COM as well. http://blogs.msdn.com/b/dsyme/archive/2012/07/05/more-c-net-generics-history-the-msr-white-paper-from-mid-1999.aspx Even if Microsoft decides to go fully native, then just have to change the C#/VB.NET/F# compilers to generate fully native binaries instead of MSIL. .NET is just a language runtime. Developers should not confuse languages with implementations. -- Paulo
Aug 20 2013
prev sibling next sibling parent =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
On Tuesday, 20 August 2013 at 07:45:28 UTC, Paulo Pinto wrote:
 With the failure that Longhorn and Vista were, the .NET 
 political camp inside Microsoft lost power to the native guys.

 I bet this is what was behind the WinRT decision, because the 
 original .NET design documents for .NET were actually based in 
 COM as well.

Interesting!
 Even if Microsoft decides to go fully native, then just have to 
 change the C#/VB.NET/F# compilers to generate fully native 
 binaries instead of MSIL.

 .NET is just a language runtime. Developers should not confuse 
 languages with implementations.

I don't quite agree with this. Imagine if I said "they just have to change their Javascript compilers to produce native code". It's clear that the semantics of the JS language do not map well enough to the x86 semantics for us to consider the produced x86 code to be "fully native". It would be x86 code, but you wouldn't be able to do systems programming, like in C++ or D. To a lesser extent the same is true with, say, C#. The design of the language makes it less native to a x86 CPU than C++.
Aug 20 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 20 August 2013 at 12:49:36 UTC, Luís Marques wrote:
 On Tuesday, 20 August 2013 at 07:45:28 UTC, Paulo Pinto wrote:
 ...
 I don't quite agree with this. Imagine if I said "they just 
 have to change their Javascript compilers to produce native 
 code". It's clear that the semantics of the JS language do not 
 map well enough to the x86 semantics for us to consider the 
 produced x86 code to be "fully native". It would be x86 code, 
 but you wouldn't be able to do systems programming, like in C++ 
 or D. To a lesser extent the same is true with, say, C#. The 
 design of the language makes it less native to a x86 CPU than 
 C++.

Native code has nothing to do with systems programming or the mapping of one-to-one from language to microprocessor instructions. Before the Java and .NET craziness, VM everywhere, all mainstream compilers generated native code. Had Sun and Microsoft decided to generate native code instead of their current solution, we wouldn't even be discussing this. This managed vs native is a marketing concept spread by Microsoft when they introduced .NET and wanted to make a distinction when talking to Windows developers. And the main reason why young developers now think that any strong typed language needs to be executed by a VM. Language semantics always matter, regardless how the code is generated. -- Paulo
Aug 20 2013
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
http://msdn.microsoft.com/en-us/library/system.type.makegenerictype.aspx
How would you implement this in native code?
Aug 20 2013
prev sibling next sibling parent =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
On Tuesday, 20 August 2013 at 13:37:00 UTC, Paulo Pinto wrote:
 Native code has nothing to do with systems programming or the 
 mapping of one-to-one from language to microprocessor 
 instructions.

At least in the context of "fully native" and C#, which we were discussing, I disagree. See below.
 Before the Java and .NET craziness, VM everywhere, all 
 mainstream compilers generated native code.

 Had Sun and Microsoft decided to generate native code instead 
 of their current solution, we wouldn't even be discussing this.

If I understand your point, you are defining (fully?) native as simply generating CPU opcodes and executing those directly. But I think this definition can be unhelpful, because there is an equivalence and a continuum between code and data. For instance: 1. Compiler generates x86 code, which is executed directly by the CPU, and nearly all the source program operations (setting a variable, calling a function, etc.) are encoded directly in the produced code. E.g. setting a variable is done directly with a "mov" opcode. 2. Compiler generates x86 code, which is executed directly by the CPU, but some program operations are done indirectly using helper functions/code which was not described in the source code. E.g. setting a variable with memcpy (silly example), creating a closure (actual D example, which uses a D runtime function). 3. The compiler generates x86, which is executed directly by the CPU, but a lot of the source program logic is encoded as data or calls to helper functions. This tends to happen when you try to produce native code for scripting languages: instead of dispatching bytecode operations using a switch(...) as you would do in a typical interpreter, you call/execute helper code directly (so we are still "native" in a certain sense). But the program logic (e.g., "a+b") mostly happens in those helper functions/code the compiler generates, because the semantics of the language (e.g. prevent overflows when multiplying big numbers by converting to arbitrary precision) demand those operations, which don't have direct counterparts in the CPU ISA. 4. You refactor those helper functions in a VM, and generate bytecode which when interpreted will call them, instead of calling them directly. Etc. My point was that when the source language semantics allows you to express constructs which can be directly and efficiently executed by the CPU ISA ("systems programming" would be an extreme of that) then you can probably say that you are being "fully native" (bar assembly language programming). When your Turing complete language can never be efficiently executed by the underlying phyisical machine, even if the compiler produces native CPU opcodes, then I think that is not "fully native". A VM is just a conceptual machine. Although we tend to use the term in a more restricted way, x86 and x64 are also VMs (which a microcoded CPU does not actually implement in "hardware"!)
Aug 20 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 20 Aug 2013 18:34:24 +0200
"Lu=EDs Marques" <luis luismarques.eu> wrote:

 On Tuesday, 20 August 2013 at 13:37:00 UTC, Paulo Pinto wrote:
 Native code has nothing to do with systems programming or the=20
 mapping of one-to-one from language to microprocessor=20
 instructions.

At least in the context of "fully native" and C#, which we were=20 discussing, I disagree. See below. =20
 Before the Java and .NET craziness, VM everywhere, all=20
 mainstream compilers generated native code.

 Had Sun and Microsoft decided to generate native code instead=20
 of their current solution, we wouldn't even be discussing this.

If I understand your point, you are defining (fully?) native as=20 simply generating CPU opcodes and executing those directly. But I=20 think this definition can be unhelpful, because there is an=20 equivalence and a continuum between code and data. For instance: =20

I think what the discussion here (both sides) ultimately amounts to is this: Some "native" languages (ie, generates CPU opcodes) have strong support for low-level control (C/C++/D), and other native languages have weaker support for low-level control (a native compiler for C#/Java). Languages designed to run on a VM like JVM/.NET (but not VMs like LLVM IM, VirtualBox or "macro-assembly" opcodes) tend to have inherently weaker support for low-level control due to the VM. Such languages will likely continue having weaker low-level ability even when using true native compilation.
Aug 20 2013
prev sibling next sibling parent "pjmp" <pjmp progtools.org> writes:
On Tuesday, 20 August 2013 at 16:34:26 UTC, Luís Marques wrote:
 ...

   1. Compiler generates x86 code, which is executed directly by 
 the CPU, and nearly all the source program operations (setting 
 a variable, calling a function, etc.) are encoded directly in 
 the produced code. E.g. setting a variable is done directly 
 with a "mov" opcode.

Agree.
   2. Compiler generates x86 code, which is executed directly by 
 the CPU, but some program operations are done indirectly using 
 helper functions/code which was not described in the source 
 code. E.g. setting a variable with memcpy (silly example), 
 creating a closure (actual D example, which uses a D runtime 
 function).

Agree.
   3. The compiler generates x86, which is executed directly by 
 the CPU, but a lot of the source program logic is encoded as 
 data or calls to helper functions. This tends to happen when 
 you try to produce native code for scripting languages: instead 
 of dispatching bytecode operations using a switch(...) as you 
 would do in a typical interpreter, you call/execute helper code 
 directly (so we are still "native" in a certain sense). But the 
 program logic (e.g., "a+b") mostly happens in those helper 
 functions/code the compiler generates, because the semantics of 
 the language (e.g. prevent overflows when multiplying big 
 numbers by converting to arbitrary precision) demand those 
 operations, which don't have direct counterparts in the CPU ISA.

Your example for overflows means Turbo Pascal and Ada do not compile to native code, right? Because their runtime libraries do have numeric and bounds checking code. In this example you're mixing interpreter with native code.
   4. You refactor those helper functions in a VM, and generate 
 bytecode which when interpreted will call them, instead of 
 calling them directly.

This is not native code.
 Etc. My point was that when the source language semantics 
 allows you to express constructs which can be directly and 
 efficiently executed by the CPU ISA ("systems programming" 
 would be an extreme of that) then you can probably say that you 
 are being "fully native" (bar assembly language programming). 
 When your Turing complete language can never be efficiently 
 executed by the underlying phyisical machine, even if the 
 compiler produces native CPU opcodes, then I think that is not 
 "fully native".

So this means even C is not fully native, because there are CPUs that don't map directly to C instructions and require more help from the C runtime library.
Aug 20 2013
prev sibling next sibling parent "Paulo Pinto" <pjmp progtools.org> writes:
On Tuesday, 20 August 2013 at 16:07:00 UTC, Kagamin wrote:
 http://msdn.microsoft.com/en-us/library/system.type.makegenerictype.aspx
 How would you implement this in native code?

Like we use to do in the old days when we were forced to rewrite Assembly on the fly. Allocate a memory buffer with the required sizes and perform the required set of initializations. This is no different than constructing C++ classes during runtime, initializing the required helper structures like vtbl and calling constructors. Nothing that cannot be done with either a set of helper functions on the language runtime, or generating inline code. Yes, I am aware that this requires the ability to execute code from the data segment. -- Paulo
Aug 20 2013
prev sibling parent "PauloPinto" <pjmlp progtools.org> writes:
On Thursday, 22 August 2013 at 01:40:05 UTC, Gambler wrote:
 On 8/20/2013 3:18 PM, Paulo Pinto wrote:
 On Tuesday, 20 August 2013 at 16:07:00 UTC, Kagamin wrote:
 http://msdn.microsoft.com/en-us/library/system.type.makegenerictype.aspx
 How would you implement this in native code?

Like we use to do in the old days when we were forced to rewrite Assembly on the fly. Allocate a memory buffer with the required sizes and perform the required set of initializations. This is no different than constructing C++ classes during runtime, initializing the required helper structures like vtbl and calling constructors. Nothing that cannot be done with either a set of helper functions on the language runtime, or generating inline code. Yes, I am aware that this requires the ability to execute code from the data segment. -- Paulo

Isn't the approach you're describing *much* more error-prone than the example above?

It is the compiler that generates the code, what is error prone about it? -- Paulo
Aug 21 2013