Note that this package does not implement Python as a first-class CLR language - it does not produce managed code (IL) from Python code. Rather, it is an integration of the CPython engine with the .NET or Mono runtime. This approach allows you to use use CLR services and continue to use existing Python code and C-based extensions while maintaining native execution speeds for Python code. If you are interested in a pure managed-code implementation of the Python language, you should check out the IronPython project, which is in active development.
C# and Python are my two favorite languages, but what would be cool is using .NET without C#, but using C# without .NET.
The main reason I don't write C# much of the time is because of the .NET dependency. There has always been Mono and nowadays there even is some Microsoft official version of .NET for Linux-based systems if I remember correctly, but really I'd just like C# to be completely independent of an operating system and independent of $someBigCorp.
Some (many?) Gnome apps are written in Vala. It takes a language that is basically a subset of C# and compiles it to C with GObjects. If I were going to write a non-trivial Gnome app right now, I'd probably use Vala.
Nowadays there is a .NET Core, which is platform independent. And I think Microsoft is one of the main reasons why C# and tooling around it is as good as it is. So it is reasonable to say that $someBigCorp can be really good thing.
DotNet core is both cross platform and is in the custody of the DotNet Foundation.
Of course Microsoft has the majority of the Foundation members, as they are paying most of the DotNet bills, in the end, but most of DotNet is open these days.
There are many standard C library implementations that target various microprocessors and platforms, that enable us to use C instead of assembler. Bringing more high level languages like C# on these platforms would benefit security and development speed.
How does removing .NET change anything ? You still need a runtime (GC, reflection/type information for casting, etc.)
You could probably strip down .NET core runtime if size is your concern and have an AoT compiled binary that links to that if you're concerned about JIT. I think there was a MS project a while back that compiled .NET IL to static code trough LLVM (https://github.com/dotnet/llilc - it seems dead now unfortunately)
There's also Mono AoT which is used by Xamarin for iOS. But it would have been nice to have an official .NET Core project that targets LLVM, hope they revive it at some point - the project got abandoned without any announcements from what I can tell.
Hmm, does that also mean LILLC (the LLVM based IL AoT) is also suspended ? I hope it's not abandoned - with the upcoming WASM it could be a big deal for .NET to get all the platforms LLVM supports that don't support JIT.
I love using C without libc or POSIX! (You can do it on Windows if you rely on the Rtl/NT libraries provided by the OS -- i.e. basically develop userland programs as if you were developing a device driver.)
So a drag and drop UI designer, followed by a simple binding to a model code behind with literally the words 'Text={Binding Name}' is apparently making 'easy things hard'?
I have to do funky validations on textfields. If the validation fails, make the field blink, or show an icon. Never allow a field to have input that fails validation (if you paste an invalid value, don't change the value of the field). I can do this several different ways in HTML and JS, or Java and one of it's UI frameworks (or my pivot framework, Qt). This apparently is hard to do with WPF. I solved it but the solution left me with a bad taste in my mouth. I shudder to think about other 'simple things' that I will have to torture a solution for given my experience. I would entertain the idea that I am a bad coder if I didn't have some experience delivering. I've spoken with a veteran WPF developer to see if I was misunderstanding something but apparently my solution was fine.
That's what I thought. Maybe my "senior dev" connection is not competent. It doesn't really matter thou, I have other reasons to avoid .NET. I have to link against unmanaged C++ and apparently there are inherent memory leaks (memory assigned by UC++ then handed to .NET process can not be freed by .NET).
memory assigned by UC++ then handed to .NET process can not be freed by .NET
Pretty sure that can be solved by implementing IDisposable and having Dispose call back into C++ to free resources. Probably if you add a managed C++ layer in between this is sort of built-in.
Oh and like skc says: the validation you're after does work as well, though I admit it takes some time to figure out exactly how to do it.
