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 reply =?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
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 parent reply "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 

binaries instead of MSIL.

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

--
Paulo
Aug 20 2013
parent reply =?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 

 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 

makes it less native to a x86 CPU than C++.
Aug 20 2013
parent reply "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++ 

 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
next sibling parent reply "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
parent reply "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
parent reply 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
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
prev sibling parent reply =?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.



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


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


=20
 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

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