A History of .NET Runtimes(mattwarren.org)
mattwarren.org
A History of .NET Runtimes
http://mattwarren.org/2018/10/02/A-History-of-.NET-Runtimes/
101 comments
I tried to only focus on runtimes, although the line got a bit blurred at times! But yeah, it would be nice to have included a mention of NGEN. When I get a chance I'll update the post
> And the cloud compiler created for Windows Phone 8.x, based on Bartok from Singularity.
Interesting, I didn't realise that all this came from Bartok, thanks for the info
> And the cloud compiler created for Windows Phone 8.x, based on Bartok from Singularity.
Interesting, I didn't realise that all this came from Bartok, thanks for the info
They are not fully explicit about it, just talking about Bartok and MDIL as if invented for WP 8, but they are scattered all over Singularity documentation and papers, so it is quite obvious where they come from.
The recent Software Engineering Daily podcast on "Unity and WebAssembly" mentions that Unity has a .NET to C++ toolchain. Is that some kind of stock Mono feature, or is that another .NET runtime?
https://www.softwaredaily.com/post/5ba9fdd63e3767000494fe01/...
https://www.softwaredaily.com/post/5ba9fdd63e3767000494fe01/...
That's probably IL2CPP, developed at Unity: https://docs.unity3d.com/Manual/IL2CPP.html
Let's look forward for .NET Core 3.0 and CoreRT: This would make it very competitive to Go not only being both native and self-contained but also going ahead in desktop-based, GUI programming.
Is the .Net environment in SQL Server since version 2005 considered a different runtime?
From memory, I think the runtime is pretty standard, what you got was a more restrictive environment in which the CLR and Framework can run so you had less chance of clobbering data, hanging SQL processes and shooting yourself in the foot.....unless you really, really needed to.
https://docs.microsoft.com/en-us/sql/relational-databases/cl...
https://docs.microsoft.com/en-us/sql/relational-databases/cl...
https://docs.microsoft.com/en-us/sql/relational-databases/cl...
https://docs.microsoft.com/en-us/sql/relational-databases/cl...
No, SQL Server just uses the normal .NET Framework to execute managed code which is also implied by the name of the feature, Common Language Runtime (CLR) Integration. Well, maybe one could also read this as integrating - in the sense of implementing - a CLR into SQL Server.
Yes, SQL Server hosts the .NET framework runtime but with added security configuration. There are also other applications hosting the framework (like IIS), and you can actually host the framework yourself (both the full and core framework). I was actually playing with the idea of hosting .NET addons in Kodi but it turns out it is too much work for a single developer as a hobby project.
What would be the advantage of .NET Kodi addons over Python? They would be faster that's for sure, but if I understand it correct, addons are not the main reason of Kodi suboptimal performance. The downsides are obvious - while you can relatively easy skim over the source code of the Python addons, it wouldn't be easy with .NET binaries - and most of the addons wouldn't provide source code. And the regular user can easily hack the feature, fix or two into Python addon code by himself, that wouldn't be so easy with .NET addons.
Does anyone remember Rotor ? That thing (codeveloped with Corel) was pretty interesting. Too bad about the look but don't touch license model.
Yes...and I also had Ted Neward's book "Shared Source CLI Essentials" to go along with it:
https://www.amazon.co.uk/Shared-Source-Essentials-David-Stut...
The problem with Rotor was that they ripped out of all the good bits and replaced with not so good things, for example they replaced the garbage collector with a naive implementation.
That said I still learned quite a lot from studying and playing around with it way back then.
https://www.amazon.co.uk/Shared-Source-Essentials-David-Stut...
The problem with Rotor was that they ripped out of all the good bits and replaced with not so good things, for example they replaced the garbage collector with a naive implementation.
That said I still learned quite a lot from studying and playing around with it way back then.
I've also read that book, it was excellent!
I think the history of the internal politics at Microsoft in regards to .NET and also the external industry trends is fascinating.
The common thinking is that C# & .NET was a ripoff of Sun Java because of the "write once run anywhere" threat. That's sort of true but missing some nuance.
I'm not a MS insider but here's my understanding of what happened. We have to separate the C# language from the CLR runtime. In the 1990s, Microsoft was already researching how to enhance and extend the COM interoperability model. (Otherwise known as "how do we get multiple programming languages to talk to each other?")
Based on some old interviews with Don Box[1], instead of this work being productized and released as "COM+ version 3" or whatever, it morphed into the CLR. This was a natural evolution that would have happened even without Sun's JVM threat.
C# the language, on the other hand, was a more direct response to Java the language since Microsoft's J++ (Java clone) was abandoned because of Sun's lawsuit.
As for .NET, it's interesting that Microsoft always had this large internal group of programmers (mostly Windows kernel and Office teams) that didn't fully buy into the .NET vision. On the other hand, Bill Gates himself was a big believer in it. My pet theory is that since Bill Gates programmed in BASIC in the 1970s and not in low-level C/C++/assembly, he had a natural affinity for the vision of high-level C# & .NET being pervasive throughout Windows. Even with Bill's support, there was always an ongoing internal tension between the C++ vs the NET framework camps. (On a related note, it seems like Apple's internal programmers are more happily embracing Swift over Objective-C to a greater degree than Microsoft's internal adoption of C# over C++.)
Two major forces outside of Microsoft's control curtailed .NET's planned world dominance: (1) the rise of Javascript in the browser which negated .NET Silverlight, and also Java applets and Flash. (2) the rise of Apple iOS and Android.
.NET is still very popular but it definitely did not fulfill the more ambitious dreams that Bill Gates had for it.
(On a related note, I also wrote an old comment about the decline of .NET's WPF and its limited adoption: https://news.ycombinator.com/item?id=14098832)
[1] Was MS Technical Fellow and author of 1998 COM book: https://www.amazon.com/Essential-COM-Don-Box/dp/0201634465
The common thinking is that C# & .NET was a ripoff of Sun Java because of the "write once run anywhere" threat. That's sort of true but missing some nuance.
I'm not a MS insider but here's my understanding of what happened. We have to separate the C# language from the CLR runtime. In the 1990s, Microsoft was already researching how to enhance and extend the COM interoperability model. (Otherwise known as "how do we get multiple programming languages to talk to each other?")
Based on some old interviews with Don Box[1], instead of this work being productized and released as "COM+ version 3" or whatever, it morphed into the CLR. This was a natural evolution that would have happened even without Sun's JVM threat.
C# the language, on the other hand, was a more direct response to Java the language since Microsoft's J++ (Java clone) was abandoned because of Sun's lawsuit.
As for .NET, it's interesting that Microsoft always had this large internal group of programmers (mostly Windows kernel and Office teams) that didn't fully buy into the .NET vision. On the other hand, Bill Gates himself was a big believer in it. My pet theory is that since Bill Gates programmed in BASIC in the 1970s and not in low-level C/C++/assembly, he had a natural affinity for the vision of high-level C# & .NET being pervasive throughout Windows. Even with Bill's support, there was always an ongoing internal tension between the C++ vs the NET framework camps. (On a related note, it seems like Apple's internal programmers are more happily embracing Swift over Objective-C to a greater degree than Microsoft's internal adoption of C# over C++.)
Two major forces outside of Microsoft's control curtailed .NET's planned world dominance: (1) the rise of Javascript in the browser which negated .NET Silverlight, and also Java applets and Flash. (2) the rise of Apple iOS and Android.
.NET is still very popular but it definitely did not fulfill the more ambitious dreams that Bill Gates had for it.
(On a related note, I also wrote an old comment about the decline of .NET's WPF and its limited adoption: https://news.ycombinator.com/item?id=14098832)
[1] Was MS Technical Fellow and author of 1998 COM book: https://www.amazon.com/Essential-COM-Don-Box/dp/0201634465
It does seem like all these .NET projects are reactions to rival technologies. C# is a Java clone, C# generics are an (arguably improved) Java generics clone, .NET Micro is J2ME, Silverlight is Flash, etc.
What are some examples of where C# / .NET paved the way and others followed? Maybe popularizing async/await?
I’m definitely not claiming MS as a whole is always a follower. It seems like Direct3D led the way for the whole industry, for example.
What are some examples of where C# / .NET paved the way and others followed? Maybe popularizing async/await?
I’m definitely not claiming MS as a whole is always a follower. It seems like Direct3D led the way for the whole industry, for example.
How come C# generics are a copy of Java when they were invented first and the only reason they didn't make it to 1.0 was not to delay the release schedule?
Java annotations are based on .NET atributes, and initially had a clusmy implementation requiring an annotations processing tool until they finally got integrated into javac.
LINQ paved the way to more FP acceptance among enterprise developers. Check "confessions of a language salesman" from Erik Meyer.
Also .NET always had AOT/JIT from the very beginning, whereas AOT was tabu at Sun and only commercial JDKs always had it as option.
Java annotations are based on .NET atributes, and initially had a clusmy implementation requiring an annotations processing tool until they finally got integrated into javac.
LINQ paved the way to more FP acceptance among enterprise developers. Check "confessions of a language salesman" from Erik Meyer.
Also .NET always had AOT/JIT from the very beginning, whereas AOT was tabu at Sun and only commercial JDKs always had it as option.
Hang on, Wikipedia says Generic Java was 1998, generics were adopted in J2SE 5.0 in 2004, and C# 2.0 wasn’t released until 2005. Am I missing something? I’m sure there was cross-fertilization both ways but it seems like Java generics came first.
LINQ is a good one though, that’s definitely a .NET innovation.
LINQ is a good one though, that’s definitely a .NET innovation.
Yes you are missing the remaining part of the sentence "the only reason they didn't make it to 1.0 was not to delay the release schedule".
Don Syme of F# fame was leading generics research since 1999, while they were designing the CLR, but it was clear they would have to delay 1.0 if they wanted to included them, so they just went ahead without them for 1.0 release.
https://blogs.msdn.microsoft.com/dsyme/2011/03/15/netc-gener...
https://blogs.msdn.microsoft.com/dsyme/2012/06/19/some-histo...
https://blogs.msdn.microsoft.com/dsyme/2012/06/26/some-more-...
Additionally C#, like Java, also had CMU, ML, Ada, Eiffel, Sather, BETA, C++ and Modula-3 as possible sources of inspiration for generics.
Don Syme of F# fame was leading generics research since 1999, while they were designing the CLR, but it was clear they would have to delay 1.0 if they wanted to included them, so they just went ahead without them for 1.0 release.
https://blogs.msdn.microsoft.com/dsyme/2011/03/15/netc-gener...
https://blogs.msdn.microsoft.com/dsyme/2012/06/19/some-histo...
https://blogs.msdn.microsoft.com/dsyme/2012/06/26/some-more-...
Additionally C#, like Java, also had CMU, ML, Ada, Eiffel, Sather, BETA, C++ and Modula-3 as possible sources of inspiration for generics.
Just lost out in a photo finish, then (over a span of 5 or 6 years...!)
But Generic Java was started in 1998 (IIRC originally as part of Pizza). It seems reasonable to say that Java covered this ground first.
But Generic Java was started in 1998 (IIRC originally as part of Pizza). It seems reasonable to say that Java covered this ground first.
Faire enough I forgot about Pizza.
Although what Java got wasn't all of Pizza, which had better generics.
Although what Java got wasn't all of Pizza, which had better generics.
If you trust Wikipedia for your answers, I have a bridge to sell you.
Combined with other sources, and when it fits with my own recollection, sure.
I played around with Pizza (AKA Generic Java) in the late 90s, before the launch of C#.
I played around with Pizza (AKA Generic Java) in the late 90s, before the launch of C#.
> C# generics are an (arguably improved) Java generics clone
That one at least is incorrect - C# had generic types long before Java
That one at least is incorrect - C# had generic types long before Java
I didn’t know that, thanks for the correction! (Edit: although now I’m not sure I was wrong after all; see my reply to the other comment)
I had the wrong idea because (if I understand right) C#’s generic collections seem to be a copy of Java’s (which in turn were inspired by C++’s STL). Do I have that one the right way round?
The C# collections use generally poorer name choices (e.g. IEnumerator, which does not actually enumerate the elements) so I assumed they wanted to avoid making it identical to Java.
I had the wrong idea because (if I understand right) C#’s generic collections seem to be a copy of Java’s (which in turn were inspired by C++’s STL). Do I have that one the right way round?
The C# collections use generally poorer name choices (e.g. IEnumerator, which does not actually enumerate the elements) so I assumed they wanted to avoid making it identical to Java.
Java's collections are not much like STL (and pre-date Java generics) and important implementation details of generics in C++, C# and Java differ very substantially.
They are not very similar in implementation due to the nature of the languages. But the idea that it would be useful for the Java standard library to provide flexible, extensible, general-purpose containers (as opposed to ad-hoc stuff like Vector and Hashtable) was inspired by the STL.
I don't think that's accurate or that the general idea comes from STL. STL itself is a very particular kind of design.
What’s a good example of a really flexible, composable containers library that predates STL?
I think STL was the first mainstream one. I guess some of the ideas came from Ada? But I don’t know if Ada had standardized containers.
I think STL was the first mainstream one. I guess some of the ideas came from Ada? But I don’t know if Ada had standardized containers.
Smalltalk and Eiffel collections.
Long before STL was a thing in C++.
Stepanov started STL original design in Ada, before switching to C++. Recent Ada standards have adopted collection classes as well.
Long before STL was a thing in C++.
Stepanov started STL original design in Ada, before switching to C++. Recent Ada standards have adopted collection classes as well.
> C# generics are an (arguably improved) Java generics clone
That depends on who you ask.
My opinion is Java doesn’t have proper generics. In Java they’re just language-level syntactic sugar.
Type system is broken i.e. type information is lost at compile time. This makes it hard to do functional-style programming in Java, that’s why other people made Scala.
Performance is broken too, generic containers box everything into objects causing huge performance penalty for containers with value types.
That depends on who you ask.
My opinion is Java doesn’t have proper generics. In Java they’re just language-level syntactic sugar.
Type system is broken i.e. type information is lost at compile time. This makes it hard to do functional-style programming in Java, that’s why other people made Scala.
Performance is broken too, generic containers box everything into objects causing huge performance penalty for containers with value types.
that’s why other people made Scala
I think you mean “the same people”, at least in the specific case of Martin Odersky. :)
I think you mean “the same people”, at least in the specific case of Martin Odersky. :)
> Generics in the runtime not the compiler (c# 2)
> Functional deeply integrated into a mainstream language (LINQ c# 3)
> Unified graphical application model incorporating all main styles of web, forms, svg, and 3d. (WPF .net 3.5)
> Compiler language services (c# 5)
> Async await (c# 5)
> Functional deeply integrated into a mainstream language (LINQ c# 3)
> Unified graphical application model incorporating all main styles of web, forms, svg, and 3d. (WPF .net 3.5)
> Compiler language services (c# 5)
> Async await (c# 5)
"Two major forces outside of Microsoft's control curtailed .NET's planned world dominance: (1) the rise of Javascript in the browser which negated .NET Silverlight, and also Java applets and Flash. (2) the rise of Apple iOS and Android."
I agree with those 2 forces:
1) the raise of javascript: Now is starting to develop an answer to this in Blazor (https://github.com/aspnet/Blazor)
2) iOS and Android: both are here to stay, so Xamarin is the answer. I have been using Xamarin for iOS and all though still lack of some maturity, in its actual form is very viable.
I agree with those 2 forces:
1) the raise of javascript: Now is starting to develop an answer to this in Blazor (https://github.com/aspnet/Blazor)
2) iOS and Android: both are here to stay, so Xamarin is the answer. I have been using Xamarin for iOS and all though still lack of some maturity, in its actual form is very viable.
Shameless plug - do you want a system built with either Blazor or UNO.
I'm a .NET developer with the perfect experience to leverage this system. I've been doing full stack and front end on various platforms for 20 years, and .NET for 15 years (version 1) and thus can leverage UNO to provide rapid and quality development.
I've already done advanced XAML in Silverlight and WPF with MVVMLight and PRISM application architectures based on TDD/CI/CD, animations, transforms, control templates, control building, designing products.
I'm also good with Blend and do the roundtrip Blend designer to Visual Studio developer workflow, or do both parts myself to design a full front end UX, UI, and code, and well as the rest of the full stack.
I've also done a lot of Razor MVC and modern web front end and I can't wait to get into Blazor as well - it seems about the dream platform for my style of development.
If you're interested to build a system or product built on UNO or Blazor with me, get in touch!
I'm a .NET developer with the perfect experience to leverage this system. I've been doing full stack and front end on various platforms for 20 years, and .NET for 15 years (version 1) and thus can leverage UNO to provide rapid and quality development.
I've already done advanced XAML in Silverlight and WPF with MVVMLight and PRISM application architectures based on TDD/CI/CD, animations, transforms, control templates, control building, designing products.
I'm also good with Blend and do the roundtrip Blend designer to Visual Studio developer workflow, or do both parts myself to design a full front end UX, UI, and code, and well as the rest of the full stack.
I've also done a lot of Razor MVC and modern web front end and I can't wait to get into Blazor as well - it seems about the dream platform for my style of development.
If you're interested to build a system or product built on UNO or Blazor with me, get in touch!
I think the game changer (one way or another) will be webassembly, which will level the playing field in term of portability. Then the popularity of the different languages being ported to wasm will be based on their own merits.
Microsoft developed .NET (internal codename COOL) to get back at Sun for suing them over Java compliance. Microsoft wanted to do embrace-extend-extinguish with the Java runtime and Sun would have none of it, so Microsoft took their ball and were like "Fine! We'll develop our OWN managed runtime and it'll be more better-er than yours is! Neener neener!"
And Bill certainly did program in low level assembly. The last Microsoft code he wrote himself was in the ROM of the Tandy 100 portable computer.
And Bill certainly did program in low level assembly. The last Microsoft code he wrote himself was in the ROM of the Tandy 100 portable computer.
I think it is better-er than Java and the JVM and they have stewarded their language much better than Java, and now Java borrows heavily from C#. I think they will win in the long run if they haven't "won" already.
Considering the language and runtime in themselves, I agree.
But they sort of missed the point of Java, which was that it was cross-platform, and a single Java package could be expected to run on a variety of hardware and OS loadouts with no changes (except maybe in configuration). Microsoft, at the time, wanted .NET to be closely tied to Windows, and though the base libraries were submitted to ECMA, to get anything useful you had to have Windows and Microsoft's Windows-only libraries. (There was Mono, but it was not compatible with Microsoft's stuff and few on the Linux side wanted to touch it.)
Things are changing, obviously, with .NET Core. We'll see if Microsoft or someone else solves for cross-platform GUI and other end-user concerns, where .NET has historically been strongest.
But they sort of missed the point of Java, which was that it was cross-platform, and a single Java package could be expected to run on a variety of hardware and OS loadouts with no changes (except maybe in configuration). Microsoft, at the time, wanted .NET to be closely tied to Windows, and though the base libraries were submitted to ECMA, to get anything useful you had to have Windows and Microsoft's Windows-only libraries. (There was Mono, but it was not compatible with Microsoft's stuff and few on the Linux side wanted to touch it.)
Things are changing, obviously, with .NET Core. We'll see if Microsoft or someone else solves for cross-platform GUI and other end-user concerns, where .NET has historically been strongest.
The Ext-VOS design document as provided by Don Syme, alongside other blog entries, tells another story.
The whole Longhorn/Vista debacle, with .NET components being rewritten in COM for Vista, followed up by the increasing the COM usage in Windows 7 and then bringing up WinRT as .NET replacement under Synofsky's leadership is another example of those political internal wars.
Yeah, I think this was a far bigger contributor to the failure of .NET to achieve dominance. Silverlight was only ever a slightly weird sideline intended to compete with Flash, which became DOA the moment the iPhone launched and Jobs killed Flash overnight by saying the iPhone would never support it.
Microsoft's biggest internal teams turning against .NET during Longhorn created a schism that the company has never resolved. I often wonder what might have happened if they'd had the requisite leadership to force the change through organisation-wide, and MS had spent the last 15 years with a single, rational dev story.
Microsoft's biggest internal teams turning against .NET during Longhorn created a schism that the company has never resolved. I often wonder what might have happened if they'd had the requisite leadership to force the change through organisation-wide, and MS had spent the last 15 years with a single, rational dev story.
>Microsoft's biggest internal teams turning against .NET during Longhorn created a schism that the company has never resolved.
From the fragments of leaks I read about the internal strife, the .NET code had huge performance problems and the C++ team was frustrated that "DevDiv" couldn't solve them. ("DevDiv" is Developer Division that owned NET Framework.) Therefore, they ripped a lot of "managed code" out and redid it in native code.
I hope that one day, an ex-Microsoft programmer or product manager writes a tell-all book of this period. It would be a fascinating case study.
From the fragments of leaks I read about the internal strife, the .NET code had huge performance problems and the C++ team was frustrated that "DevDiv" couldn't solve them. ("DevDiv" is Developer Division that owned NET Framework.) Therefore, they ripped a lot of "managed code" out and redid it in native code.
I hope that one day, an ex-Microsoft programmer or product manager writes a tell-all book of this period. It would be a fascinating case study.
Yeah, that's my understanding as well. But what I wonder is what would have happened if someone at the top had brought the C++ and .NET teams in and made some Jobsian declaration like "this isn't negotiable, the company is switching to .NET. All of your jobs depend on finding a way to make it work." Were those performance problems really insoluble, if all the engineering ability of the company were brought to bear on them? I get the impression that a lot of the C++ old hands were never pleased with .NET to begin with, and were all too happy to chuck it.
Right, it certainly sounded from the outside that a lot of the Longhorn performance issues were various sorts of sandbagging by one side or the other. There's an interesting leadership question there too if some of the worst sandbagging was intentional or just ADHD-style distractions due to a lack of a singular, focused vision for the product. (The biggest example being letting so much of the WinFS team get sucked into the never-ending "semantic web" rabbit hole of trying to "schematize the world"; it's hard to focus on performance when you are busy trying to catalog all the different ways that people store data.)
At RustConf 2017 keynote presented by Joe Duffy regarding Midori at a certain moment, he mentions that even with Midori running in front of them, WinDev guys were still not open to the idea of such kind of system being possible.
"Safe Systems Software and the Future of Computing"
https://www.youtube.com/watch?v=CuD7SCqHB7k
Sorry a bit lazy to track down the exact moment.
"Safe Systems Software and the Future of Computing"
https://www.youtube.com/watch?v=CuD7SCqHB7k
Sorry a bit lazy to track down the exact moment.
The thing is, if they actually collaborated with each other, the outcome would surely look quite different.
> Jobs killed Flash overnight by saying the iPhone would never support it.
I think it was a forced choice. Even if Flash had been supported, most flash sites and games would not have worked well on a phone.
I think it was a forced choice. Even if Flash had been supported, most flash sites and games would not have worked well on a phone.
[deleted]
Yep, they were forced to sort out the mess introduced with WinRT, UAP, UWP, by making UWP .NET Standard 2.0 compliant, and now making Forms, WPF and EF 6 runnable on top of .NET Core 3.0.
However given the last Office related announcements, it appears that the reorganization did little to sort out those political issues.
However given the last Office related announcements, it appears that the reorganization did little to sort out those political issues.
Next stop, making UWP crossplatform :))
Regarding the political issues, the Silverlight/WinRT clusterfuck also helped with WindowsPhone downfall. Release 1.0 and next major update offered a API incompatible with 1.0, what a clusterfuck....
Regarding the political issues, the Silverlight/WinRT clusterfuck also helped with WindowsPhone downfall. Release 1.0 and next major update offered a API incompatible with 1.0, what a clusterfuck....
This exists - UWP code and UI - deployed to iOS, Android, and WebAssembly.
It's called UNO, check out https://platform.uno/ and https://platform.uno/#Comparison
!! By the way to anyone who wants to build a system in UNO - I would like to build one. !!
I'm a .NET developer with the perfect experience to leverage this system. I've been doing full stack and front end on various platforms for 20 years, and .NET for 15 years (version 1) and thus can leverage UNO to provide rapid and quality development.
I've already done advanced XAML in Silverlight and WPF with MVVMLight and PRISM application architectures based on TDD/CI/CD, animations, transforms, control templates, control building, designing products.
I'm also good with Blend and do the roundtrip Blend designer to Visual Studio developer workflow, or do both parts myself to design a full front end UX, UI, and code, and well as the rest of the full stack.
If you're interested to build a system or product built on UNO with me, get in touch!
It's called UNO, check out https://platform.uno/ and https://platform.uno/#Comparison
!! By the way to anyone who wants to build a system in UNO - I would like to build one. !!
I'm a .NET developer with the perfect experience to leverage this system. I've been doing full stack and front end on various platforms for 20 years, and .NET for 15 years (version 1) and thus can leverage UNO to provide rapid and quality development.
I've already done advanced XAML in Silverlight and WPF with MVVMLight and PRISM application architectures based on TDD/CI/CD, animations, transforms, control templates, control building, designing products.
I'm also good with Blend and do the roundtrip Blend designer to Visual Studio developer workflow, or do both parts myself to design a full front end UX, UI, and code, and well as the rest of the full stack.
If you're interested to build a system or product built on UNO with me, get in touch!
> Next stop, making UWP crossplatform :))
they do not need. they have xaml over xamarin.forms, which supports all major platforms (including desktopn and mobile) it still says that its in preview however the only things that did not work well is when you need some kind of file interaction with the os, you need to create native views for all your OSs (i.e. NSFilePicker, OpenFileDialog, etc..) since there is no Xamarin.Forms widget for that. besides that it is already really mature.
they do not need. they have xaml over xamarin.forms, which supports all major platforms (including desktopn and mobile) it still says that its in preview however the only things that did not work well is when you need some kind of file interaction with the os, you need to create native views for all your OSs (i.e. NSFilePicker, OpenFileDialog, etc..) since there is no Xamarin.Forms widget for that. besides that it is already really mature.
Xamarin.Forms has to manage a lot of friction interfacing with the native UI controls. It's both an advantage and a disadvantage to it's approach. It has to conform to the common denominator of the native platforms, but gets to leverage the native look and feel. But this seems much harder to maintain long term.
It would actually make sense if they created a XAML platform (like cross-platform UWP) that used its own rendering stack (similar to Flutter's approach) that wasn't beholden to the design decisions of an externally developed platform and having to reconcile the differences between different platform paradigms.
To further tangent: I don't think the last Office related announcement says anything about UWP that people think it does.
From my understanding, the Office apps that were killed were supposedly forked from the web apps and actually ran as UWP HTML/JS.
Meanwhile, Office has also announced plans to move forward with more UWP XAML Islands to integrate more Fluent Design in the UX starting soon after the Windows October release, and part of why the Office 2019 LTS was shipped where it was and arguably why Office 365 pushed to align to only support latest Windows releases so they could move forward on Fluent Design dogfooding.
They did sunset the non-UWP OneNote with this LTS release, and the UWP XAML app is supposed to be the only Windows version of OneNote moving forward.
From my understanding, the Office apps that were killed were supposedly forked from the web apps and actually ran as UWP HTML/JS.
Meanwhile, Office has also announced plans to move forward with more UWP XAML Islands to integrate more Fluent Design in the UX starting soon after the Windows October release, and part of why the Office 2019 LTS was shipped where it was and arguably why Office 365 pushed to align to only support latest Windows releases so they could move forward on Fluent Design dogfooding.
They did sunset the non-UWP OneNote with this LTS release, and the UWP XAML app is supposed to be the only Windows version of OneNote moving forward.
Lets see, I watched the Office sessions at BUILD, so that was my understanding until the announcement came last week.
Yeah, BUILD's where most of where my impressions come from, especially from how pleasantly happy that the Fluent Design Team was with finally merging in some of Office's design resources and working to align Office towards dogfooding Fluent controls directly.
The implication I take from the UWP "Office Mobile" app shutdowns is that Office is now confident that if UWP returns to mobile it will do so with "real" Office, which was my takeaway from BUILD that that was the strategy they were pursuing.
I think it's another case of Microsoft not being able to properly spin "nuance" in a press release, because they don't want to comment on future plans or publicly commit to things still in flux/prototyping/development.
The implication I take from the UWP "Office Mobile" app shutdowns is that Office is now confident that if UWP returns to mobile it will do so with "real" Office, which was my takeaway from BUILD that that was the strategy they were pursuing.
I think it's another case of Microsoft not being able to properly spin "nuance" in a press release, because they don't want to comment on future plans or publicly commit to things still in flux/prototyping/development.
IMO .NET being closed source until recently was also a big factor in it's lack of world dominance. Why choose a proprietary language when there are several comparable opwn ones to choose from.
My hypotheses is that C# would never have become as popular as it became if Java hadn't had the long stall between 1.6 and 7[1]. That long, long pause provided a window, and under the stewardship of the vampires at Oracle there is not the kind of direction to push things forward that C# has had.
[1] Four and a half years! Nowadays it seems like Angular and React are pushing major versions every four and a half minutes.
[1] Four and a half years! Nowadays it seems like Angular and React are pushing major versions every four and a half minutes.
I'm not sure Java would have changed at all if it wasn't for C#. From the start, Java was never particularly quick to get new features or break any sort of compatibility.
J++ I completely forgot about that! It brings back memories :)
> .NET is still very popular but it definitely did not fulfill the more ambitious dreams that Bill Gates had for it.
Remember when Microsoft was adding '.NET' to practically all of their product names for a time? That was fun...
Remember when Microsoft was adding '.NET' to practically all of their product names for a time? That was fun...
>.NET is still very popular but it definitely did not fulfill the more ambitious dreams that Bill Gates had for it.
There is still time. It just recently got open-sourced, got a compiler written in itself and got a run-time unbundled form all the legacy crap. Those things held C#/.NET back. I feel this is a good time to adopt it for people who want to have reasonable performance, static typing and a mix of OOP/functional paradigms.
My two notes on C#:
1. It is possible to write reasonably "functional" applications in .NET. The only problem I had with that is lack of built-in copy-on-write data types and prevalent nullity.
2. LINQPad is the best damn scripting environment I ever worked with.
There is still time. It just recently got open-sourced, got a compiler written in itself and got a run-time unbundled form all the legacy crap. Those things held C#/.NET back. I feel this is a good time to adopt it for people who want to have reasonable performance, static typing and a mix of OOP/functional paradigms.
My two notes on C#:
1. It is possible to write reasonably "functional" applications in .NET. The only problem I had with that is lack of built-in copy-on-write data types and prevalent nullity.
2. LINQPad is the best damn scripting environment I ever worked with.
> 1. It is possible to write reasonably "functional" applications in .NET. The only problem I had with that is lack of built-in copy-on-write data types and prevalent nullity.
I've tried to minmise that pain over the past few years with my 'functional language extensions' for C# [1].
It's a library with most of the common monadic types (as structs so there's no null issues); Immutable collection types that don't have an unweildy naming scheme like like the System.Immutable.Collections library - which are all structs, so no nulls; A type called 'Record<T>' which when you derive a type from it gives your type value-semantics (equality, ordering, GetHashCode, ToString, serialisation/deserialisation) by default; and tons more.
You still have to do stuff like build your own With method for immutable types. I have written of how these can be achieved _realtively_ easily [2]
C# has made great strides over the past 10 years to make it easier for those of us that want to work functionally to do it. It still has some way to go (discriminated unions, higher-kinds, record types, etc.) but it's already possible to write code functionally - you just need to do some boilerplate every now and then.
[1] https://github.com/louthy/language-ext
[2] https://stackoverflow.com/questions/38575646/general-purpose...
I've tried to minmise that pain over the past few years with my 'functional language extensions' for C# [1].
It's a library with most of the common monadic types (as structs so there's no null issues); Immutable collection types that don't have an unweildy naming scheme like like the System.Immutable.Collections library - which are all structs, so no nulls; A type called 'Record<T>' which when you derive a type from it gives your type value-semantics (equality, ordering, GetHashCode, ToString, serialisation/deserialisation) by default; and tons more.
You still have to do stuff like build your own With method for immutable types. I have written of how these can be achieved _realtively_ easily [2]
C# has made great strides over the past 10 years to make it easier for those of us that want to work functionally to do it. It still has some way to go (discriminated unions, higher-kinds, record types, etc.) but it's already possible to write code functionally - you just need to do some boilerplate every now and then.
[1] https://github.com/louthy/language-ext
[2] https://stackoverflow.com/questions/38575646/general-purpose...
Wow, what a nice project you have there.
I've read that the next C# will have non-nullable reference types, have you thought about how to make your framework fit in with that? It's a "natural" Some/None in a way.
I've read that the next C# will have non-nullable reference types, have you thought about how to make your framework fit in with that? It's a "natural" Some/None in a way.
> Wow, what a nice project you have there.
Thanks :)
> It's a "natural" Some/None in a way.
If we lived in the perfect non-nullable reference world from the start then it's arguable whether Option<A> would ever have been needed - and so going forward it should be needed less, or not at all for some devs. The question comes when you need an optional value, and so you use nullable references instead of Option<A>. With nullable references the `null` still honours the contract of `A` - this is what Option<A> protects against. If the flow-analysis for nullable references is good enough to spot that you're possibly going to use null and then forces you to use a predicate of some sort (if/switch/ternary/...) to validate the referenced value exists then I think we're good. I understand that is what's planned, but it needs to be bulletproof.
There will be devs working in the nullable reference world for a long time (due to difficulties with moving to the new world when it comes) - and so I fully expect Option to be useful for its null protection reasons for a long time.
The story is a bit bigger than just protection against null though. If instead of seeing Option<A> as A|null, you see it as A|B, where B is the single-value type: Unit. Then Option is A|Unit. If you then look at Either<L, R> which is designed to represent one of two alternative values: L|R then it's pretty easy to see that Option is Either<Unit, A>. And then when we look at Try<A> which is designed to return A or capture an exception and return it as a value, then that can be seen as Either<Exception, A>...
All of the types that represent one of two values have lots of additional powerful functionality: Fold, Map, Bind, BiFold, BiMap, BiBind, etc. and have been designed to seamlessly switch between each, which won't exist on the standard nullable reference types. So, there's still a place for Option in the bigger scheme of things.
Personally, I can't wait for non-nullable references to come in. I built language-ext to try and get a handle on a 10,000,000+ line code base that kept falling foul to null reference exceptions (along with other common C# coding world problems). It was 100% to help me and my team build more robust code. Non-nullable references is a feature we will turn on immediately, even if it takes a week to fix up the warnings and errors it spits out, this is going to be one of the most important updates the C# team have done.
Thanks :)
> It's a "natural" Some/None in a way.
If we lived in the perfect non-nullable reference world from the start then it's arguable whether Option<A> would ever have been needed - and so going forward it should be needed less, or not at all for some devs. The question comes when you need an optional value, and so you use nullable references instead of Option<A>. With nullable references the `null` still honours the contract of `A` - this is what Option<A> protects against. If the flow-analysis for nullable references is good enough to spot that you're possibly going to use null and then forces you to use a predicate of some sort (if/switch/ternary/...) to validate the referenced value exists then I think we're good. I understand that is what's planned, but it needs to be bulletproof.
There will be devs working in the nullable reference world for a long time (due to difficulties with moving to the new world when it comes) - and so I fully expect Option to be useful for its null protection reasons for a long time.
The story is a bit bigger than just protection against null though. If instead of seeing Option<A> as A|null, you see it as A|B, where B is the single-value type: Unit. Then Option is A|Unit. If you then look at Either<L, R> which is designed to represent one of two alternative values: L|R then it's pretty easy to see that Option is Either<Unit, A>. And then when we look at Try<A> which is designed to return A or capture an exception and return it as a value, then that can be seen as Either<Exception, A>...
All of the types that represent one of two values have lots of additional powerful functionality: Fold, Map, Bind, BiFold, BiMap, BiBind, etc. and have been designed to seamlessly switch between each, which won't exist on the standard nullable reference types. So, there's still a place for Option in the bigger scheme of things.
Personally, I can't wait for non-nullable references to come in. I built language-ext to try and get a handle on a 10,000,000+ line code base that kept falling foul to null reference exceptions (along with other common C# coding world problems). It was 100% to help me and my team build more robust code. Non-nullable references is a feature we will turn on immediately, even if it takes a week to fix up the warnings and errors it spits out, this is going to be one of the most important updates the C# team have done.
Part of me, though, worries that the ship has sailed. For a while .NET was probably completely fine from Microsoft's perspective, because the platform was (AFAICT) dominant in their target market of enterprise apps.
Then big data became a thing, and basically the entire core ecosystem was written in Java. I think it's becoming a bit of a wedge issue - Java has everything that .NET has, but .NET does not have its own equivalent of, for example, the Hadoop ecosystem.
Then big data became a thing, and basically the entire core ecosystem was written in Java. I think it's becoming a bit of a wedge issue - Java has everything that .NET has, but .NET does not have its own equivalent of, for example, the Hadoop ecosystem.
You can do "big data" entirely in .NET.
You can use Hadoop "Streaming" with .NET easily enough and still take advantage of the "Hadoop ecosystem".
Orleans is not exactly Hadoop, but it's close enough that conversions between are relatively straight-forward, and Orleans is useful for a number of other work distribution patterns beyond map/reduce.
Beyond that, the map/reduce pattern is one of the easiest abstractions to reimplement yourself from scratch if you get the itch. I believe Hadoop is relatively over-rated from that standpoint, and arguably IMO another case of Java developers over-ceremonializing what should be a simple, lovely abstraction/design pattern into a weird spaghetti mess of configuration and ritual.
You can use Hadoop "Streaming" with .NET easily enough and still take advantage of the "Hadoop ecosystem".
Orleans is not exactly Hadoop, but it's close enough that conversions between are relatively straight-forward, and Orleans is useful for a number of other work distribution patterns beyond map/reduce.
Beyond that, the map/reduce pattern is one of the easiest abstractions to reimplement yourself from scratch if you get the itch. I believe Hadoop is relatively over-rated from that standpoint, and arguably IMO another case of Java developers over-ceremonializing what should be a simple, lovely abstraction/design pattern into a weird spaghetti mess of configuration and ritual.
> Java has everything that .NET has
Java offers nothing for game developers, there're multiple game engines written in .NET or using .NET. Java only runs on Android, .NET on all mobiles. Native interop in Java is a joke.
Java offers nothing for game developers, there're multiple game engines written in .NET or using .NET. Java only runs on Android, .NET on all mobiles. Native interop in Java is a joke.
Actually Java had jMonkey and LibGDX before Unity became the engine it is today. Which initially was Mac only and only used Boo and Unity Script as programming languages.
Khronos does have some official OpenGL specs for Java. There are none from them for .NET.
Java runs on iOS via Codename One and Gluon AOT compilers.
Native interop in Java was made hard on purpose, as Sun was pushing for WORA. Oracle is in the process of improving the situation with Project Valhala.
I love both stacks, truth is that .NET still has a bit to catch up outside Windows, while Java lost a bit of its mojo on desktops.
Khronos does have some official OpenGL specs for Java. There are none from them for .NET.
Java runs on iOS via Codename One and Gluon AOT compilers.
Native interop in Java was made hard on purpose, as Sun was pushing for WORA. Oracle is in the process of improving the situation with Project Valhala.
I love both stacks, truth is that .NET still has a bit to catch up outside Windows, while Java lost a bit of its mojo on desktops.
About games, maybe the reason is lack of value types in Java which stresses GC and creates pauses. .NET works OK, Unity is the most obvious (cities skylines, kerbal space program, etc.), but also XNA, MonoGame, SharpDX. This creates an ecosystem with healthy amount of libraries and other resources.
About native interop, I know Java did it on purpose, but as a developer I don’t care much about the rationale. I’ve heard about upcoming Valhala years ago (announced in 2014), still not ready.
Related to both of them, .NET core 2.1 already has SIMD support. Some parts of it is experimental, but it already works more or less OK, esp. on Intel/Amd.
About native interop, I know Java did it on purpose, but as a developer I don’t care much about the rationale. I’ve heard about upcoming Valhala years ago (announced in 2014), still not ready.
Related to both of them, .NET core 2.1 already has SIMD support. Some parts of it is experimental, but it already works more or less OK, esp. on Intel/Amd.
Java had such eco systems first with Java3D, JOGL, Khronos OpenGL bindings, 3D for J2ME, jMonkey, LWJGL
Problem was that Sun never was too serious about their Java Gamming initiative.
Unity only adopted C# after moving out of the Mac into the PC, and it was stuck for ages in 3.5 as they didn't want to pay for the new licenses. Which meant it grew to a kind of C# dialect, which is being fixed now.
ManagedDX and XNA were Quixotic projects not well seen by WinDev. Which replaced XNA with DirectXTK when given the opportunity.
Which took a couple of years effort until Microsoft acknowledged the work done by the MonoGame guys.
Things take ages in Java because there are multiple vendors and everyone has to contribute to the process.
Intel has provided SIMD auto vectorization improvements. There are a couple of talks about it.
Problem was that Sun never was too serious about their Java Gamming initiative.
Unity only adopted C# after moving out of the Mac into the PC, and it was stuck for ages in 3.5 as they didn't want to pay for the new licenses. Which meant it grew to a kind of C# dialect, which is being fixed now.
ManagedDX and XNA were Quixotic projects not well seen by WinDev. Which replaced XNA with DirectXTK when given the opportunity.
Which took a couple of years effort until Microsoft acknowledged the work done by the MonoGame guys.
Things take ages in Java because there are multiple vendors and everyone has to contribute to the process.
Intel has provided SIMD auto vectorization improvements. There are a couple of talks about it.
> Unity only adopted C# after moving out of the Mac into the PC
Not quite true; Unity has always used Mono. The very first Unity 1.0 version in 2005 was already using C#/Mono.
> Which meant it grew to a kind of C# dialect
Unity never had it's own "C# dialect".
Not quite true; Unity has always used Mono. The very first Unity 1.0 version in 2005 was already using C#/Mono.
> Which meant it grew to a kind of C# dialect
Unity never had it's own "C# dialect".
Given that Unity uses different conventions for property names and magical function names with reflection for events, that is a dialect to me, as it is not how C# is used by regular developers.
Actually there are occasional questions on C# forums caused by people learning C# via Unity and then facing issues when using pure .NET.
Then there is the new HPC# for the new ECS and Job systems, which subsets C#.
As for Mono being already in 1.0, OS X only version, I am unsure about it, but the old blog was taken down. So I take your word for it.
Actually there are occasional questions on C# forums caused by people learning C# via Unity and then facing issues when using pure .NET.
Then there is the new HPC# for the new ECS and Job systems, which subsets C#.
As for Mono being already in 1.0, OS X only version, I am unsure about it, but the old blog was taken down. So I take your word for it.
That's just coding style, which by itself is not a new dialect. Yes a bunch of APIs in Unity use different naming conventions from the rest of .NET world, but the language is the same.
The new HPC#/Burst indeed are subsets of C#, but that's a very recent development, and completely unrelated to "Unity had to make their own C# dialect to avoid Novell/Xamarin licensing issues".
> As for Mono being already in 1.0, OS X only version, I am unsure about it, but the old blog was taken down
I have worked at Unity since 2006. Yes Unity was Mac only at that point, but it still used Mono there.
The new HPC#/Burst indeed are subsets of C#, but that's a very recent development, and completely unrelated to "Unity had to make their own C# dialect to avoid Novell/Xamarin licensing issues".
> As for Mono being already in 1.0, OS X only version, I am unsure about it, but the old blog was taken down
I have worked at Unity since 2006. Yes Unity was Mac only at that point, but it still used Mono there.
My remark had to do more with being stuck in a v3.5 world, thus making Unity devs live in an universe quite different than what everyone else is using in terms of APIs and language features, on top of Unity specific behaviors like those magical methods called by the component framework.
> truth is that .NET still has a bit to catch up outside Windows, while Java lost a bit of its mojo on desktops.
I agree, that's quite a nice summary of the 2 ecosystems
I agree, that's quite a nice summary of the 2 ecosystems
> Java has everything that .NET has
C# certainly has many features that Java, the language, does not. It gets better if you consider Kotlin instead, but it's not clear to me if that language has a chance of becoming on par with Java, popularity-wise.
C# certainly has many features that Java, the language, does not. It gets better if you consider Kotlin instead, but it's not clear to me if that language has a chance of becoming on par with Java, popularity-wise.
LINQPad is awesome, and I'm always amazed to still find a lot of .NET developers who've never given it a try.
A cross platform version is high on my wish list.
A cross platform version is high on my wish list.
> Bill Gates programmed in BASIC in the 1970s and not in low-level C/C++/assembly
He didn't program in BASIC, he programmed a BASIC interpreter in 8080 assembly.
He didn't program in BASIC, he programmed a BASIC interpreter in 8080 assembly.
Thank you for the clarification. Yes that makes sense. I'm probably mixing it up with an interview where one of MS ex-employees (Joel Spolsky?) mentioned Bill's affinity for BASIC which is why early MS Word has WordBASIC (not Lisp or Pascal) as its first macro language. It later became VBA Visual Basic for Applications. This philosophy and influence continued all the way into the CLR languages VB.NET and C#. Bill was never a C/C++ guy like his employees who were working on Windows & Office codebases.
Excel BASIC, I believe.
https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
True. But he definitely had a love for BASIC.
Something that makes following Microsoft tech different for engineers, in my opinion, is that naming has historically been driven by marketing/sales, not engineering. There is not a 1-1 mapping between the branded/advertised functionality and the technical components responsible for it. This makes sense when your audience is purchasers at a company. They care about what features/scenarios are supported, not how they are implemented (sorting through that is, at most, the job of someone lower on the totem pole).
Engineers, on the other hand, want to know how the system works. Even when it shouldn’t matter to us, we can’t help but think in terms of the actual mechanisms driving the system’s behavior. We don’t like black boxes, because we experience daily the leakiness of all abstractions. And for an engineer targeting Windows as a platform, the technical details obviously do matter.
I think this difference is especially jarring to developers used to the nix world, where everything is much more developer-oriented. I would bet that the early success of Microsoft products against Unix is partially due to this difference in focus. Ideally, you communicate differently with both groups, but in reality you have to make trade offs. It would just create more confusion if there was one set of names/brands for end-consumers and another totally different set for developers.
(Another difference is that Windows has historically been one big project, so features do in fact span technical components, which due to being under single management, are less regimented to begin with.)
The web has definitely changed things by making operating systems less important. At least the perceived importance of marketing to developers has increased. I think Microsoft has done a good job adapting to this change lately.
Engineers, on the other hand, want to know how the system works. Even when it shouldn’t matter to us, we can’t help but think in terms of the actual mechanisms driving the system’s behavior. We don’t like black boxes, because we experience daily the leakiness of all abstractions. And for an engineer targeting Windows as a platform, the technical details obviously do matter.
I think this difference is especially jarring to developers used to the nix world, where everything is much more developer-oriented. I would bet that the early success of Microsoft products against Unix is partially due to this difference in focus. Ideally, you communicate differently with both groups, but in reality you have to make trade offs. It would just create more confusion if there was one set of names/brands for end-consumers and another totally different set for developers.
(Another difference is that Windows has historically been one big project, so features do in fact span technical components, which due to being under single management, are less regimented to begin with.)
The web has definitely changed things by making operating systems less important. At least the perceived importance of marketing to developers has increased. I think Microsoft has done a good job adapting to this change lately.
You missed two that I can think of:
(1) the runtime written in F# that Frank Krueger’s Continuous uses (and I believe also Xamarin Live player uses in some fashion.)
(2) Goa WinForms was a C# compiler that targeted the Adobe Flash Player, and implemented part of the BCL and WinForms UI. If you include the CrossNet I think this also counts.
Nice! Thanks for the info, I'll check those out, I'd not heard of either of them.
I think that an update to the post is due, turns out that I missed quite a few!
I think that an update to the post is due, turns out that I missed quite a few!
As someone outside the .net world, is there a wasm version? Can I run a .net language in a web browser and have access to the DOM, or render the UI for a .net app as DOM objects on a web page? That would be super useful.
Blazor is coming. It's not GA yet.
https://github.com/aspnet/Blazor
https://github.com/aspnet/Blazor
Yes there's UNO for XAML to phones/wasm, and Blazor for c#/html instead of js/html modern web.
Shameless plug - do you want a system built with either Blazor or UNO.
I'm a .NET developer with the perfect experience to leverage this system. I've been doing full stack and front end on various platforms for 20 years, and .NET for 15 years (version 1) and thus can leverage UNO to provide rapid and quality development.
I've already done advanced XAML in Silverlight and WPF with MVVMLight and PRISM application architectures based on TDD/CI/CD, animations, transforms, control templates, control building, designing products.
I'm also good with Blend and do the roundtrip Blend designer to Visual Studio developer workflow, or do both parts myself to design a full front end UX, UI, and code, and well as the rest of the full stack.
I've also done a lot of Razor MVC and modern web front end and I can't wait to get into Blazor as well - it seems about the dream platform for my style of development. I would favour Blazor because it's in the html and browser world and closer to the rest of the industry and an more open platform.
If you're interested to build a system or product built on UNO or Blazor with me, get in touch!
Shameless plug - do you want a system built with either Blazor or UNO.
I'm a .NET developer with the perfect experience to leverage this system. I've been doing full stack and front end on various platforms for 20 years, and .NET for 15 years (version 1) and thus can leverage UNO to provide rapid and quality development.
I've already done advanced XAML in Silverlight and WPF with MVVMLight and PRISM application architectures based on TDD/CI/CD, animations, transforms, control templates, control building, designing products.
I'm also good with Blend and do the roundtrip Blend designer to Visual Studio developer workflow, or do both parts myself to design a full front end UX, UI, and code, and well as the rest of the full stack.
I've also done a lot of Razor MVC and modern web front end and I can't wait to get into Blazor as well - it seems about the dream platform for my style of development. I would favour Blazor because it's in the html and browser world and closer to the rest of the industry and an more open platform.
If you're interested to build a system or product built on UNO or Blazor with me, get in touch!
Yes, the WASM version is here: https://blazor.net/
It's an early preview
Also Uno if you prefer XAML https://platform.uno/
or if you like functional, http://fable.io/ compiles F# to js to run in the browser
Few more missed include (Device CLR's were in C, Desktop/Server in C++):
(1) CLR for Sony/Ericsson phone OS and (2) Variant running on linux (in 2001/2002).
I worked on the Compact Framework team back in the day so there's a few more things to point out related to the internal politics of Microsoft at the time.
The devices strategy was a mess even back then due to Alchin/Valentine/Ballmers love of Windows desktop 'everywhere'. Windows and Office dominated the company so things like .Net were always going to be secondary to that.
The origins of the CLR can be found in the purchase of Colusa in 1996 which had the Omni VM for running C++ in a sandbox. The original C# language was called cool and came from that project.
(1) CLR for Sony/Ericsson phone OS and (2) Variant running on linux (in 2001/2002).
I worked on the Compact Framework team back in the day so there's a few more things to point out related to the internal politics of Microsoft at the time.
The devices strategy was a mess even back then due to Alchin/Valentine/Ballmers love of Windows desktop 'everywhere'. Windows and Office dominated the company so things like .Net were always going to be secondary to that.
The origins of the CLR can be found in the purchase of Colusa in 1996 which had the Omni VM for running C++ in a sandbox. The original C# language was called cool and came from that project.
> The origins of the CLR can be found in the purchase of Colusa in 1996 which had the Omni VM for running C++ in a sandbox. The original C# language was called cool and came from that project.
Thanks, I'd heard about 'cool', but I didn't know the part about Omni VM, that's interesting to know
Thanks, I'd heard about 'cool', but I didn't know the part about Omni VM, that's interesting to know
Was the framework you mentioned in (1) a Microsoft project, or something else?
As a matter of interest, what did you do on the CF team?
As a matter of interest, what did you do on the CF team?
Worked in the Compact CLR Execution Engine, IL Verifier, and other stuff. On (1) both were done at MS but ended up as proof of concept.
Post Sathya Microsoft has moved to a more open model, hence the full blown CLR on Linux.
Post Sathya Microsoft has moved to a more open model, hence the full blown CLR on Linux.
Back in 2008/9 I was a co-founder at a company (Red Five Labs) that created a .NET Compact Framework runtime for Symbian OS (featured on most Nokia & Samsung smartphones at the time). We got to a .NET CF 2.0 level of compatibility.
It was a venture-backed startup out of Johannesburg, South Africa.
Although we wrote the runtime ourselves, we made extensive use of some of the mono libraries until we were able to rewrite most of these optimized for Symbian.
[1] https://web.archive.org/web/20100112091803/http://www.redfiv...
It was a venture-backed startup out of Johannesburg, South Africa.
Although we wrote the runtime ourselves, we made extensive use of some of the mono libraries until we were able to rewrite most of these optimized for Symbian.
[1] https://web.archive.org/web/20100112091803/http://www.redfiv...
Nice! Thanks for the info. I think that an update to the post is due, turns out that I missed quite a few!
What happens to that code once the company disappears?
Unfortunately it went with it. There were some superficial talks about it winding up in the Symbian Foundation, but those didn’t materialize.
And yes, it probably points to a major problem with a small company developing critical framework or tool components when the codebase isn’t participating in an open source license.
There were many mistakes made along the way, in retrospect.
And yes, it probably points to a major problem with a small company developing critical framework or tool components when the codebase isn’t participating in an open source license.
There were many mistakes made along the way, in retrospect.
I remember this! Good memories
And the cloud compiler created for Windows Phone 8.x, based on Bartok from Singularity.
https://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-an...
https://channel9.msdn.com/Events/Build/2012/3-005
.NET Native is an improvement of this work.