4 ms·

I think one of the reasons why new languages are going for compilation again is the death of the multi-architecture ecosystem. Support x64 and ARM and you can p

by mhd 8y ago

I think one of the reasons why new languages are going for compilation again is the death of the multi-architecture ecosystem. Support x64 and ARM and you can play with the big boys. Back then? Intel was barely considered mature, every Unix manufacturer (including sun) had their own processor architecture, and who knew what was coming out for the smaller devices ("thin clients" were all the rage). I still think that for those scenarios Sun should've stuck with PostScript, and we still might have C/C++, but would be spared JS/HTML/CSS. I've got no idea why Microsoft was going apesh* for bytecode all of a sudden. Especially considering that they had the heads of Modula-3 and Delphi...

narag 8y ago
I've got no idea why Microsoft was going apesh· for bytecode all of a sudden. Delphi probably was one of the main reasons. It was a lot better for Windows 32 development than VB and there were projects to port it to Linux. Microsoft then recruited Delphi leads, settled a long running suit with Borland (with the fallout of stopping Delphi for Linux development) and finally created a platform where they keep control, unlike native API that is much more open.
- pjmlp 8y ago
  Java was the reason. COM Runtime was going to be native (Ext-VOS), but then they decided to go VM path and .NET was born. https://blogs.msdn.microsoft.com/dsyme/2012/07/05/more-c-net-generics-research-project-history-the-msr-white-paper-from-mid-1999/ https://blogs.msdn.microsoft.com/dsyme/2012/07/05/more-c-net... If you read Don Syme blog entries about .NET history, you will see a few similarities with WinRT. Just with .NET metadata instead of the old COM type libraries. So the double bet on COM since Vista was a bit like WinDev's revenge. However how things turned out, it appears DevTools is having their way again and even .NET Native might be redone post .NET Core 3.0 release, as per Q&A session at Connect() 2018.
  - narag 8y ago
    I can't find anything in the post you link that supports your conclusion. The author seems to be a person from the research area, in the team for F# maybe? Who do you think had more weight in the decision, this guy or the chief architect for .NET that came from Borland? Of course Java was the model for the VM thing, but that's the what, not the why, the reason they, in the words of the gp, went apesh··· with the bytecode thing. Actually I can neither be in the mind of whoever made the call, just make an educated guess, but at least it has a base on facts that I was paying attention to at that time.
    - pjmlp 8y ago
      Read the Ext-VOS paper linked there, then go read the WinRT implementation MSDN documentation about IInspectable, WinRT type libraries. Don Syme is one of the researchers responsible for .NET and the implementation of .NET generics. F# was a follow up project on his career.
pjmlp 8y ago
We were able to do multi-architecture with compiled languages just fine. What Java had going for it, was being free (beer), more stable across OSes than a mix of K&R/ISO C, pre-ISO C++, batteries included libraries with GUI support and endless amount of money thrown out by Sun, IBM and Oracle driving adoption (yes they were into Java almost since JDK 1.0). As for .NET and bytecode, see my neighbouring comment.
- AnIdiotOnTheNet 8y ago
  > We were able to do multi-architecture with compiled languages just fine. Indeed, we can even distribute them all in the same package on some systems (like NeXT). Here's an idea: have an OS that guarantees support for a certain bytecode VM and format for binaries that supports multi-arch. Now developers can compile to native and the bytecode, so even any unsupported arch will still be able to run the application with just some additional overhead. Now your OS can be distributed for new and experimental archs and still be usable because people's favorite applications will still work.

by mhd 8y ago

narag 8y ago

I've got no idea why Microsoft was going apesh· for bytecode all of a sudden. Delphi probably was one of the main reasons. It was a lot better for Windows 32 development than VB and there were projects to port it to Linux. Microsoft then recruited Delphi leads, settled a long running suit with Borland (with the fallout of stopping Delphi for Linux development) and finally created a platform where they keep control, unlike native API that is much more open.

pjmlp 8y ago
Java was the reason. COM Runtime was going to be native (Ext-VOS), but then they decided to go VM path and .NET was born. https://blogs.msdn.microsoft.com/dsyme/2012/07/05/more-c-net-generics-research-project-history-the-msr-white-paper-from-mid-1999/ https://blogs.msdn.microsoft.com/dsyme/2012/07/05/more-c-net... If you read Don Syme blog entries about .NET history, you will see a few similarities with WinRT. Just with .NET metadata instead of the old COM type libraries. So the double bet on COM since Vista was a bit like WinDev's revenge. However how things turned out, it appears DevTools is having their way again and even .NET Native might be redone post .NET Core 3.0 release, as per Q&A session at Connect() 2018.
- narag 8y ago
  I can't find anything in the post you link that supports your conclusion. The author seems to be a person from the research area, in the team for F# maybe? Who do you think had more weight in the decision, this guy or the chief architect for .NET that came from Borland? Of course Java was the model for the VM thing, but that's the what, not the why, the reason they, in the words of the gp, went apesh··· with the bytecode thing. Actually I can neither be in the mind of whoever made the call, just make an educated guess, but at least it has a base on facts that I was paying attention to at that time.
  - pjmlp 8y ago
    Read the Ext-VOS paper linked there, then go read the WinRT implementation MSDN documentation about IInspectable, WinRT type libraries. Don Syme is one of the researchers responsible for .NET and the implementation of .NET generics. F# was a follow up project on his career.

pjmlp 8y ago

We were able to do multi-architecture with compiled languages just fine. What Java had going for it, was being free (beer), more stable across OSes than a mix of K&R/ISO C, pre-ISO C++, batteries included libraries with GUI support and endless amount of money thrown out by Sun, IBM and Oracle driving adoption (yes they were into Java almost since JDK 1.0). As for .NET and bytecode, see my neighbouring comment.

AnIdiotOnTheNet 8y ago
> We were able to do multi-architecture with compiled languages just fine. Indeed, we can even distribute them all in the same package on some systems (like NeXT). Here's an idea: have an OS that guarantees support for a certain bytecode VM and format for binaries that supports multi-arch. Now developers can compile to native and the bytecode, so even any unsupported arch will still be able to run the application with just some additional overhead. Now your OS can be distributed for new and experimental archs and still be usable because people's favorite applications will still work.