Does this spell Google moving away just a little bit from Java in the future?
Search for Flutter and Dart. I do not think they will use .Net
That isn't going anywhere, they are just trying to save Dart.
Google joins .NET Foundation as Samsung brings .NET support to Tizen
331–340 of 341 posts
Re: Google joins .NET Foundation as Samsung brings .NET support to Tizen
#332Earlier quoted context omitted.
Please just make C-ABI's first-class citizens (especially on the GUI front), then all other languages can bind to that.
C ABI is very limiting, though, and it's a pain to implement. What's really needed is some standard higher-level ABI (that does things like classes in a sane way), but which is made out of the existing C ABI building blocks in a manner that allows any existing language with C FFI use it. We can then add a new FFI layer that maps higher-level concepts better, but everyone can still play regardless. This is exactly wha…
... so, a C-ABI + per-language wrappers, or perhaps a high-quality cross-platform, multi-language wrapper generator? That effectively accomplishes what you're describing in your second paragraph.
Either way, it'd be great if one could implement efficient GUI's (and full apps more generally) on Android in C/C++/Go/Rust without having to generate JVM bytecode on the fly (or like Xamarin does: at compile time).
Re: Google joins .NET Foundation as Samsung brings .NET support to Tizen
#333Earlier quoted context omitted.
Based on what I know about CIL and C++, the entirety of C and C++ can be compiled to [unverifiable] CIL. The sole exception is setjmp/longjmp - this might be doable on top of CLI exceptions, but I'm not sure. And, indeed, VC++ lets you do just that. There are some bits of the standard library, mostly new stuff like threads and atomic, that had some issues, as I recall. But it's more about the amount of effort that's…
Dynamic languages cannot be easily mapped to CIL, which is why IronPython was the genesis of DLR extensions, later added as standard part of .NET.
Dynamic languages typically aren't compiled, though. So either a language would have some kind of VM of its own (which is typically implemented in C, and hence can be implemented in CIL), or else they have some form of JIT compilation, which can use CIL as a target.
Re: Google joins .NET Foundation as Samsung brings .NET support to Tizen
#334Earlier quoted context omitted.
C ABI is very limiting, though, and it's a pain to implement. What's really needed is some standard higher-level ABI (that does things like classes in a sane way), but which is made out of the existing C ABI building blocks in a manner that allows any existing language with C FFI use it. We can then add a new FFI layer that maps higher-level concepts better, but everyone can still play regardless. This is exactly wha…
... so, a C-ABI + per-language wrappers, or perhaps a high-quality cross-platform, multi-language wrapper generator? That effectively accomplishes what you're describing in your second paragraph. Either way, it'd be great if one could implement efficient GUI's (and full apps more generally) on Android in C/C++/Go/Rust without having to generate JVM bytecode on the fly (or like Xamarin does: at compile time).
A language wrapper generator is about right, although for some languages it makes more sense to wrap things dynamically rather than generate code. .NET does it for WinRT, for example.
The problem with conventional C ABI is that it's just too low-level to produce good wrappers. I mean, all you have are global functions, structs, and data and function pointers. There isn't even a standard string type! (you can say char*, but there's the need to deal with lifetime issues - who deallocates what).
So in practice you need the C ABI, plus all those conventions, like how an "object" looks (i.e. how you do things like method dispatch or type queries), how a callback looks, how strings work etc. And all those conventions are expressed in terms of that basic C ABI - but they also have to be standardized, and they become ABI of their own, like COM and WinRT.
And you also need a convention/standard for metadata, for those wrappers to consume, and for any sort of runtime magic like property bindings - like typelibs for COM and metadata assemblies for WinRT.
Re: Google joins .NET Foundation as Samsung brings .NET support to Tizen
#335Earlier quoted context omitted.
It does them. But it repeats the story with generics, where back-compat (in this case, lack of reified generics) requires hacks for acceptable performance. For example, in Java, you have this: http://docs.oracle.com/javase/8/docs/api/?java/util/function... Note all the permutations. This is necessary, because there's no way to define a generic interface that would have acceptable perf, due to boxing. So you end up de…
> This is necessary, because there's no way to define a generic interface that would have acceptable perf, due to boxing. Actually, that's going away with Java 9 (or 10). Luckily.
This is great to hear, but it also kinda reinforces the point - .NET generics were reified from the get go, back when they were introduced in 2005. Java got generics a few months earlier than .NET, if I remember correctly; but we're still waiting for them to fully catch up. By the time it does, people coming from C# will be asking about things like sequence comprehensions (well, they already do, since those have been around for 8 years) and pattern matching...
Re: Google joins .NET Foundation as Samsung brings .NET support to Tizen
#336Earlier quoted context omitted.
I mean most developers, period , use Windows, on a worldwide basis. Most web developers use Windows. Most C/C++ developers use Windows. Most Android developers use Windows. Almost all .NET developers use Windows--but most developers, period, use Windows. Windows is the de facto standard in most places that aren't chasing the leading edge.
> I mean most developers, period , use Windows, on a worldwide basis. I’m not sure anyone would agree with that. Unless you also count designers, and kids who just learnt how to click together a website in Frontpage 2000 as developers. Especially if you count compsci graduates, it becomes very obvious just how much *nix dominates.
Sure! Unless you have ever, even once, stopped to glance at the overwhelming majority of line-of-business programmers that outnumber your notion of "developers" five to one or more.
But good job with the warrantless and wrong contempt.
Re: Google joins .NET Foundation as Samsung brings .NET support to Tizen
#337Earlier quoted context omitted.
Which is why you would use Scala or Groovy.
Or Kotlin but that's not his argument. He's arguing for Java 8. I don't agree that Java 8 is really an acceptable modern language for development. IMO it's painful and god awful slow develop in compared to a host of better languages (Swift, Scala, Groovy, and C# all included but not limited to).
> develop in compared to a host of better languages (Swift, Scala, Groovy, and C# all included
Swift, Scala, and C# are statically-typed languages, like Java, whereas Apache Groovy is dynamically-typed originally -- though static typing was added in Groovy 2, virtually no-one uses it. Dynamically typed languages like Groovy are good for glue code, build scripts, and testing, not for developing actual systems.
Re: Google joins .NET Foundation as Samsung brings .NET support to Tizen
#338Earlier quoted context omitted.
Dynamic languages cannot be easily mapped to CIL, which is why IronPython was the genesis of DLR extensions, later added as standard part of .NET.
Dynamic languages typically aren't compiled , though. So either a language would have some kind of VM of its own (which is typically implemented in C, and hence can be implemented in CIL), or else they have some form of JIT compilation, which can use CIL as a target.
Those are scripting languages.
If you bothered to read why DLR was created, you will see why CIL wasn't enough.
Or why Java following the same linr of thought had to follow DLR changes to the CLR and introduce invokedynamic byte code and its related infrastructure.
Re: Google joins .NET Foundation as Samsung brings .NET support to Tizen
#339Earlier quoted context omitted.
Dynamic languages typically aren't compiled , though. So either a language would have some kind of VM of its own (which is typically implemented in C, and hence can be implemented in CIL), or else they have some form of JIT compilation, which can use CIL as a target.
Those are scripting languages. If you bothered to read why DLR was created, you will see why CIL wasn't enough. Or why Java following the same linr of thought had to follow DLR changes to the CLR and introduce invokedynamic byte code and its related infrastructure.
I know why DLR was created. I work on a team that has one of the guys who was working on it, and specifically on IronPython.
My point is that they are two different layers in the stack. CIL and JVM are lower level. DLR is a higher level layer. Said higher level can be implemented on any kind of lower level that's powerful enough - for example, you could have a kind of DLR directly on top of native code. All that matters for the lower level is that it's flexible enough to permit something like DLR to be implemented on top of it. CIL is undeniably flexible enough for that.
Re: Google joins .NET Foundation as Samsung brings .NET support to Tizen
#340Earlier quoted context omitted.
Those are scripting languages. If you bothered to read why DLR was created, you will see why CIL wasn't enough. Or why Java following the same linr of thought had to follow DLR changes to the CLR and introduce invokedynamic byte code and its related infrastructure.
I know why DLR was created. I work on a team that has one of the guys who was working on it, and specifically on IronPython. My point is that they are two different layers in the stack. CIL and JVM are lower level. DLR is a higher level layer. Said higher level can be implemented on any kind of lower level that's powerful enough - for example, you could have a kind of DLR directly on top of native code. All that matt…
I remember reading some articles that justified DLR as CIL not having enough semantics that allowed to properly implement optimization algorithms commonly used in dynamic languages, like method lookup and call site caches.
Then again, maybe I understood it wrongly back then and I surely don't have the knowledge of your team.