Page 5 of 7 FirstFirst ... 34567 LastLast
Results 41 to 50 of 62

Thread: Mono Developers Renew Their Love For Microsoft

  1. #41
    Join Date
    Feb 2013
    Posts
    233

    Default

    Quote Originally Posted by ciplogic View Post
    you can get that C++ to perform faster than .Net, but even so, you cannot get more than 20-30%. (you can get for specific cases, "happy cases").
    This sounds reasonable.

    Quote Originally Posted by ciplogic View Post
    I agree and I know what you mean. First of all let's clarify: this doesn't make a person writing bad code to not have a more code usage. The "round of 8 bytes" of every data set and boxing make Java to consume much more than the dataset you want to represent. C# doesn't need this and this is a good thing.
    ...
    But in the same time [C#] is not 10x more memory wasteful (like Java)
    Claiming Java is 10x more memory wasteful is ridiculous. Even you don't believe that. The Mono guys purposefully design benchmarks like that, but that is deceptive in that you won't see anything so dramatic in more normal world scenarios. JVM has larger fixed memory overhead so you see a large percentage difference on a "hello world" program. But when you start loading actual data into memory, you won't see a dramatic memory difference like that.

    If you load a byte[] in Java or a Array[Byte] in Scala, there is very close to zero overhead. I already agreed that it is a good thing that C# generics works with value types without a boxing overhead. You are just blowing that minor benefit out of proportion. Scala basically gives you the same benefit, where you don't have boxing overhead on somethign like Array[Byte].

    Quote Originally Posted by ciplogic View Post
    C# and Linq/database features are not related. Linq can be used from Boo, VB.Net, or any .Net language with a decent support of lambdas. It could be written in C# (which it is) but it doesn't relate with the fact that Linq (as technology) to be Windows centric. I use Linq day by day, and I don't target Windows or Sql server. Even I do programming on Windows (let's say), Linq can be used against Xmls, collections (arrays, List<T>), etc. which have no relation with the support of C#.
    Sure, the in-memory LINQ functionality isn't permanently bound to C# or Microsoft and it could be potentially adopted by other non-Microsoft ecosystems. And if it makes sense to do so, it should adopted, regardless of passed history and politics.

    However, LINQ isn't an originator and isn't unique in it's functionality. Scala natively provdes the functionality of in-memory LINQ, long before LINQ ever existed, and does it more seamlessly than LINQ where it's not this disjoint syntax separate from the rest of the language. Scala has arguably better technology, it's lacking the trademarked brand name, and Microsoft marketing, and all that, which isn't important to many people.

    Quote Originally Posted by ciplogic View Post
    C++ was probably made for describing business logic, and metaprogramming and was targetted for Unix development. This doesn't make C++ to not be very good for other environments (including Windows).
    Same argument. If C# is technologically beneficial in other platforms, it can and should be adopted for technical reasons, regardless of whatever political issues have plagued that past.

    I agree with this sentiment, but C# isn't even good technology. It has minor advantages over Java like reified generics and lack of generics related boxing (which Scala fixes) and native unsigned primitives (which isn't hard to work around). But C# is _far_ behind a more modern language like Scala. To quote myself in response to someone asking "Can you provide examples of legacy hacks and how Scala, Haskell and F# are actually better than languages like C# or Java?":

    Quote Originally Posted by DanLamb View Post
    Java has this horrific convention of writing getters/setters everywhere because you can't change a variable to a function without breaking source + binary compatability.

    C# automates this with properties, but in some ways it's even worse. There is no reason C# should have both mostly redundant language constructs of variables/fields and properties. You can have a local variable, but not a local property. You can have an instance variable, but generally you can always replace it with an instance property. "readonly" works on instance/class fields, but not properties and not local variables, and it's different from const. If you want a read only property, that uses a completely separate syntax. Props can be overridden, variables can not. The "var" type inference mechanism works with local variables, but not instance variables or class variables or properties or function return values. What a complete chaotic mess!!

    Scala has var (read/write) and val (read only) and that's it. Whether you use them as local var/vals, instance var/vals, or singleton var/vals, they work the same and use the same syntax and don't need a myriad of weird rules and legacy syntaxes and keywords. Type inference works in all cases and also works similarly with function return types.

    null. Scala/F# support null for Java/C# interop, but native Scala/F# otherwise doesn't use null at all. Option is a much better solution than null. C#'s nullable types are a much weaker partial solution, which is why Microsoft's newer F# uses Option.

    Arrays. C#/Java both started with arrays and added generics as a separate system later. Arrays should use the generics syntax. And they should use the same casting rules. Scala does, Java/C# do not. Java/C# have arrays that can downcast (covariance) which is a mistake that they can't fix for legacy reasons as you can write code that compiles but fails at runtime.

    I mentioned LINQ. Scala does all the in-memory stuff that LINQ does in the core language where C# has this separate disjoint syntax bolted on.

    Ternary operator. C/Java/C#/JavaScript use the ternary operator, because they don't have "if" expressions that return a value like Ruby, Scala, or most other modern languages. The ternary operator also doesn't extend cleanly to multiple else if conditions or multi-line expressions like an "if" expression.

    Partial functions. C had switch/case statements which was carried over into JavaScript/C#/Java. This is similar to a mathematical partial function (a function defined for only some range of inputs like a logarithm function). Scala basically replaces the C-era switch/case with native partial function support.

    Native support for tuples is extremely useful.

    Native support for pattern matching is huge. This dove tails with Option btw.

    Native support for currying. You can approximate it with C#/Java, but it's nice to have native support.

    Look at Scala's parser combinator library for an example of some useful, practical code that really showcases the conciseness and elegance of Scala in a way that would be far more bulky in Java/C#.
    Quote Originally Posted by ciplogic View Post
    Java 7 was announced less than a week ago as supported by Dalvik when async/await support (VS 2012 feature, VS launched in October 2012) was ready as for start of 2013 in the master branch in Mono.
    It's much worse than that. Dalvik doesn't support the major Java 7 enhancements, specificially the NIO.2 library which Google helped write, and Invoke Dynamic byte code. The Android toolset just supports soms superficial petty Java 7 syntax improvements, which is barely better than nothing.

    The dated Java support is almost surely due to the legal battles with Oracle. I presume Google has been working to phase out Java and replace with something else, and that just hasn't been ready to announce.

    IMO, there are much better languages than Java: Scala, Haskell, Ocaml, Rust, etc. But worse than Java, is using a completely out of date, legacy version of the language that is incompatabile with much of the more recent developments.

    I am not downplaying this disaster, but are you just gloating? I never claimed Mono had this problem.

    The async issue seems to be a tangent. Scala has super nice syntax for dealing with async programming, and I believe that can compile to Dalvik binaries.

  2. #42
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    398

    Default

    Quote Originally Posted by DanLamb View Post
    Claiming Java is 10x more memory wasteful is ridiculous. Even you don't believe that. The Mono guys purposefully design benchmarks like that, but that is deceptive in that you won't see anything so dramatic in more normal world scenarios. JVM has larger fixed memory overhead so you see a large percentage difference on a "hello world" program. But when you start loading actual data into memory, you won't see a dramatic memory difference like that.
    (...)
    Same argument. If C# is technologically beneficial in other platforms, it can and should be adopted for technical reasons, regardless of whatever political issues have plagued that past.

    I agree with this sentiment, but C# isn't even good technology. It has minor advantages over Java like reified generics and lack of generics related boxing (which Scala fixes) and native unsigned primitives (which isn't hard to work around). But C# is _far_ behind a more modern language like Scala. To quote myself in response to someone asking "Can you provide examples of legacy hacks and how Scala, Haskell and F# are actually better than languages like C# or Java?":
    (...)
    I am not downplaying this disaster, but are you just gloating? I never claimed Mono had this problem.
    You claimed two things here:
    Quote Originally Posted by DanLamb View Post
    (...)
    C# has a zillion technical problems, major ugly technical problems, but beyond those, it's not a platform-agnostic, general purpose language. It's an integration langauge for Microsoft tech stacks. If you don't want a Microosft centric tech stack, C# and .NET usually doesn't make sense.
    Given this "impartial view", I think is appropriate to give this kind of responses. And the numbers are not given by a Mono enthusiast (like myself), but by Java guys like an expert working on Twitter claims that JVM is huge on memory. Taking it from his slides:
    - smallest object: 16 bytes
    - (empty) array of bytes: 24 bytes
    - class A {
    byte x;
    }
    class B extends A {
    byte y;
    }
    new A(): 24 bytes, new B(): 32 bytes
    -
    class C {
    Object obj = new Object();
    }
    new C() = 40 bytes
    - Guava MapMaker.makeMap() takes 2272 bytes!
    MapMaker.concurrencyLevel(1).makeMap() - 352 bytes

    - Corba like Thrift can also be heavy (Thrift is a Twitter project): "It adds between 52 and 72 bytes of overhead per object."

    So, what remained for me to "prove" are the following:
    - Mono is not just a poor's man CLR (or .Net). Because performance wise (as was quoted) gives the same optimizations (given you pick LLVM which is not default) as a C++ runtime
    - C# is not MS centric (it runs just well on Mono and with not impaired functionality)
    - C# it makes sense on some platforms which are not Windows (like Linux, or iOS or Android) maybe even more than Java. The reason: at the end is created a native binary that is executed so it can run faster than let's say... Java on some devices (like Android and/or iOS). I know about RoboVM which is pre-alpha (like my tool too) and it can compile some Java apps on iOS

    What about C# vs Scala. I don't know. I cannot comment (too much), because as much as you say, it looks to me that Scala has some ups and downs. Scala looks to me a more OOP that tries to describe as much as possible functional features, when C# added them later (via Linq). Maybe is not a clean syntax, but feature wise on practical side it looks that in some parts C# is clearly superior:
    - PInvoke and native platform integration working with any OS (also to falsify your statement that C# is not platform agnostic)
    - dynamic object: you can do dynamic programming. The syntax is worse than Mirah, or IronRuby or IronPython, of course, but you can do it fairly natural and the generated code is fast too.
    - async/await is more than an actors or task based programming, and is supported on Mono (which is the topic of this article), not because it offers something more (which it does), but because the whole states are written by the compiler. This is why is so good experience running Windows Phones or modern WPF applications

  3. #43
    Join Date
    Feb 2013
    Posts
    233

    Default

    ciplogic,

    You clearly know your material. Your points are backed with evidence. But:

    - You are passionate about Mono/Xamarin/.NET/C#, which is great, but many of your statements seem highly slanted as a result. I'm biased as well, but I'm trying to be reasonable about it, acknowledge some C#/Mono advantages etc.
    - Mono's strength is runtime flexibility and integration with non-Windows OSs. The core VM isn't quite as optimized as the official Microsoft one, it runs a little slower. You don't use it to win benchmarks, you use it because you want to use C# on a non-Windows OS. That's not necessarily a "poor man's" tool, but it is what it is. RoboVM occupies a similar spot in the JVM space: people don't use it because it runs server apps faster, they use it to target OSs like iOS that the official Oracle runtime doesn't support.
    - You may have some points on Java memory. The Java VM, and probably the Microsoft VM, have undergone too many iterations by different super serious team to just waste large amounts of memory for no reason. I can believe JVM made a different set of trade offs. For example, memory alignment generally trades memory efficiency for runtime efficiency and different VM teams optimize for different targets. But when you claim that Java wastes 10x as much memory as .NET, that just is too far outside of reason. Even when you cite Guava memory wastefulness, I have never directly used that particular Guava API, but I suspect that the Guava guys just made different trade offs and optimizations rather than just wrote a horrible product.
    - You quote Xamarin benchmarks. Those guys are known for making completely deceptive skewed benchmark tests. They aren't a neutral party at all. Almost anyone can cook up some benchmarks and cherry pick results. They are notorious for that.
    - I believe you are downplaying the major defficiencies of C# as a language. You are too gung ho about the related technologies to see its flaws. I think even many Microsoft people are completely aware that C# is quite dated, which is why they are priming F# for prime time when the mass audience is ready.
    - Some of the reverse is probably true, I'm not familiar with PInvoke, but I suspect you are right that .NET has advantages in that area. Even I will give the Mono team credit for integrating their toolset into other ecosystems like PlayStation Vita much better than most other toolsets.

  4. #44
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    398

    Default

    Quote Originally Posted by DanLamb View Post
    ciplogic,

    You clearly know your material. Your points are backed with evidence. But:

    - You are passionate about Mono/Xamarin/.NET/C#, which is great, but many of your statements seem highly slanted as a result. I'm biased as well, but I'm trying to be reasonable about it, acknowledge some C#/Mono advantages etc.
    - Mono's strength is runtime flexibility and integration with non-Windows OSs. The core VM isn't quite as optimized as the official Microsoft one, it runs a little slower. You don't use it to win benchmarks, you use it because you want to use C# on a non-Windows OS. That's not necessarily a "poor man's" tool, but it is what it is. RoboVM occupies a similar spot in the JVM space: people don't use it because it runs server apps faster, they use it to target OSs like iOS that the official Oracle runtime doesn't support.
    - You may have some points on Java memory. The Java VM, and probably the Microsoft VM, have undergone too many iterations by different super serious team to just waste large amounts of memory for no reason. I can believe JVM made a different set of trade offs. For example, memory alignment generally trades memory efficiency for runtime efficiency and different VM teams optimize for different targets. But when you claim that Java wastes 10x as much memory as .NET, that just is too far outside of reason. Even when you cite Guava memory wastefulness, I have never directly used that particular Guava API, but I suspect that the Guava guys just made different trade offs and optimizations rather than just wrote a horrible product.
    - You quote Xamarin benchmarks. Those guys are known for making completely deceptive skewed benchmark tests. They aren't a neutral party at all. Almost anyone can cook up some benchmarks and cherry pick results. They are notorious for that.
    - I believe you are downplaying the major defficiencies of C# as a language. You are too gung ho about the related technologies to see its flaws. I think even many Microsoft people are completely aware that C# is quite dated, which is why they are priming F# for prime time when the mass audience is ready.
    - Some of the reverse is probably true, I'm not familiar with PInvoke, but I suspect you are right that .NET has advantages in that area. Even I will give the Mono team credit for integrating their toolset into other ecosystems like PlayStation Vita much better than most other toolsets.
    I have to start with an apology: certainly Java doesn't use 10x memory, and it was an exageration from my side. Though, I can still say that it uses more memory than a typical other VM implementations. Given this, this quote were intentionally exagerated based on the claims were provided (maybe with no intent to misinform) by you. If they were slanderous, it was not by far any intent but to give just "tit for tat".

    Also, I want to disclaim some things about myself and the "Xamarin benchmarks". I did contribute to Xamarin products, and in fact just to only one (Xamarin Studio) some patches in code quality (and once I had also reported a bug that MonoDevelop did not open my project, but I didn't contribute anything to fix it), but all benchmarks are written by myself and they are also documented how I did the testing, etc. as my intent of writing CR is an academic endevour and my interst into compilers (too long and too personal to expand it here). The project is simply the tentative (for now successful) to translate CIL (the MSIL / .Net bytecodes) to C++. This is the reason why I know .Net internals (and Java too) as when I did convert for first time I've got more than 8x slowdown in any C++ application and I had to look in various ways to improve it.

    At last, Java does offer tangible performance speedup in most cases, and in my view: .Net CLR is lightweight (as it maps C/C++ fairly well as semantics, just with a GC in the back) but with GCC -O1 optimizations, Java is an alien runtime (alien != slanderous, simply, it is like Self or SmallTalk or Objective Pascal on that manner, where the wrapping is not done naturally to C/C++) but with optimizations comparing with GCC -O2 (as it uses HotSpot, CHA and partially interpretrs the code). I agree for this reason with you 100%: 8 bytes alignment is for performance and less misaligned cache lines (which is really important to some extend into modern CPUs).

    C# is not that modern? Probably, I never did a detailed testing. I tried Kotlin (which I heard that is like Scala) and I use JetBrain tools (R#), and I liked more than C#. I would love that Kotlin to work in .Net (it doesn't... )

    But also to all fairness, the JVM bytecodes are not so well defined as CIL ones: generics are defined at the IL level in CLR world (I think if you said that Scala has "full" reified generics, they have either to make copies in implementation of bytecodes), structs too, and is not just that you make them "generic" but you can define them as parameters, Java is limited as types (and will not be able to add unsigned int in my understanding) because there are no enough bytecode numbers, and even the instructions that do math are for me a bit silly: you push two integers, and after that you have to call instruction "iadd", because you cannot add them anyway with "fadd" (addition of two floats). Java has also limitations that CLR extends them: like a function in Java can have no more than 256 parameters, but in .Net the limit is of 64K (if I recall right), so even you use code generators, you have to look sometimes of the Java generated limits.

    So maybe the pretiest language is Scala, the fastest (in the runtime performace) is Java, but as for me are not by much. InvokeDynamic and Jigsaw are the single things I've heard in a while that are fascinating in Java world, but these two things are features made in the last 5 years of development. Maybe I wasn't impressed with the "WPF clone" (Java FX) or with their public record (with Oracle suing Google and things of this sort)

  5. #45
    Join Date
    Apr 2008
    Location
    Saskatchewan, Canada
    Posts
    460

    Default

    Quote Originally Posted by DanLamb View Post
    Sure, Java lets you write inefficient code. No language is idiot proof. If you use a totally inappropriate data structure you can get terrible results.
    I'm not convinced that using objects to store data in an 'object-oriented' language is 'a totally inappropriate data structure'.

    C++, for example, would likely use no more RAM to store the values as Byte objects that just wrapped a byte value than it would for a byte array (assuming you didn't run into any stupid packing restrictions). Java can't, because of the silly 'every object is a reference' design that requires you to store pointers everywhere.

  6. #46
    Join Date
    Sep 2012
    Posts
    270

    Default

    Quote Originally Posted by movieman View Post
    I'm not convinced that using objects to store data in an 'object-oriented' language is 'a totally inappropriate data structure'.

    C++, for example, would likely use no more RAM to store the values as Byte objects that just wrapped a byte value than it would for a byte array (assuming you didn't run into any stupid packing restrictions). Java can't, because of the silly 'every object is a reference' design that requires you to store pointers everywhere.
    Pleas learn a language before bashing on it.
    Java does have primitive types and you do use the a lot.
    C# however doesn't, they are just keywords to the Classes.

  7. #47
    Join Date
    Feb 2013
    Posts
    233

    Default

    I completely believe you or agree with every point in your last post with some minor exceptions.

    - "[Java] will not be able to add unsigned int": Why? Even if this would require major JVM bytecode changes, that's completely feasible. A new Java VM must continue to support older legacy byte code, but newer byte code does not need to run on older VMs. Java changes byte code standards with every version of Java. They could do a ground-up rewrite if there was justification.
    - Scala runs as fast as Java. It actually benchmarks slightly faster, which I didn't expect, but that's not generally a reason to use it over Java.
    - Scala isn't just "pretty" in terms of aesthetics: it's elegant, concise, and easier to express and maintain logic. Many argue that Haskell is better in this regard (my experience with Haskell is far too shallow).
    - Kotlin: It seems like a half way step between Java and Scala. I don't see a justification for the existence of this. There is no novel paradigm or use case or feature or audience for this.
    - I'm curious, if you are fond of Mono and .NET, why not use F#?
    - WPF + JavaFX: The demand for classic desktop GUI toolkits has mostly vanished as almost everything has gone web or mobile. One big advantage of JavaFX is that it runs natively on Win/Linux/Mac and has alpha support for iOS. I know the Mono guys were big advocates of using native GUI toolkits rather than foreign platform agnostic toolkits, but often, for IDE-like tools, a platform agnostic GUI toolkit is what you want. Even if you love WPF from a developer perspective, it really is a strictly Windows only toolkit.

    Here is my one contentious point:

    Technologies like Clojure/Scala are focused on language level enhancements regarding elegance/conciseness/logic. They want to bring their innovations to the widest audience possible and be politically neutral, so Clojure supports both JVM and CLR (and JavaScript). Scala used to support both, but deprecated it's CLR runtime, presumably due to a combination of complexity and lack of interest.

    You've made many points about the technical benefits of the CLR bytecode and the VM technology of Mono. If these are legitimate, politically neutral technology enhancements, why don't they bring their VM innovations to other compatible language/library technologies like Java, the Java system library, Clojure, and Scala, and reach a larger number of developers and focus less on restricting their choices at other points in their development stacks?

    My hypothesis is that Xamarin isn't focused on improving VMs in a politically neutral fashion. Their primary charter is spreading the adoption of Microsoft technologies, eliminating competing technologies, and the technical innovations that they deliver are just a means to an end.

  8. #48
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    398

    Default

    Quote Originally Posted by DanLamb View Post
    I completely believe you or agree with every point in your last post with some minor exceptions.

    - "[Java] will not be able to add unsigned int": Why? Even if this would require major JVM bytecode changes, that's completely feasible. A new Java VM must continue to support older legacy byte code, but newer byte code does not need to run on older VMs. Java changes byte code standards with every version of Java. They could do a ground-up rewrite if there was justification.
    In fact is not feasible. JVM bytecodes are limited in count, by a wide margin: they are limited to 256 opcodes, and most of them are taken. In comparison CIL (CLR bytecode) is 2bytes long (meaning more options to play with, some of the most common instructions are 1 byte though). Excluding this, as I've told you earlier, the JVM bytecodes are type encoded, when from CIL standpoint they depend on type inference. So adding support for the basic 4 operations in JVM for an UInt32 you have to add at least the following opcodes: convert_to_uint32, add_ui32, sub_ui32, mul_ui32, rem_ui32. In comparison, in .Net you have to add two instructions: convert_to_uin32 and convert_overflow_uint32. So at least without changing the semantics drastically, you will not see too soon, or ever this support.

    Quote Originally Posted by DanLamb View Post
    - Scala runs as fast as Java. It actually benchmarks slightly faster, which I didn't expect, but that's not generally a reason to use it over Java.
    - Scala isn't just "pretty" in terms of aesthetics: it's elegant, concise, and easier to express and maintain logic. Many argue that Haskell is better in this regard (my experience with Haskell is far too shallow).
    - Kotlin: It seems like a half way step between Java and Scala. I don't see a justification for the existence of this. There is no novel paradigm or use case or feature or audience for this.
    - I'm curious, if you are fond of Mono and .NET, why not use F#?
    (...)
    I use at home F#, for very tutorial like coding, but... when I need functional, Linq fulfills my needs for now. At work, I cannot use F# at all, I asked this and there is no support (from my colleagues). How do we check for code safety? We use R# (static analysis components) and Code Contracts.

    As for Kotlin which I can comment (but not for Scala, as I never used it), I can say that are some specific features (mostly in static code analysis) which are guaranteed by the language. Maybe this feature alone makes the language useful for Jetbrains folks.
    Quote Originally Posted by DanLamb View Post
    Here is my one contentious point:

    Technologies like Clojure/Scala are focused on language level enhancements regarding elegance/conciseness/logic. They want to bring their innovations to the widest audience possible and be politically neutral, so Clojure supports both JVM and CLR (and JavaScript). Scala used to support both, but deprecated it's CLR runtime, presumably due to a combination of complexity and lack of interest.

    You've made many points about the technical benefits of the CLR bytecode and the VM technology of Mono. If these are legitimate, politically neutral technology enhancements, why don't they bring their VM innovations to other compatible language/library technologies like Java, the Java system library, Clojure, and Scala, and reach a larger number of developers and focus less on restricting their choices at other points in their development stacks?

    My hypothesis is that Xamarin isn't focused on improving VMs in a politically neutral fashion. Their primary charter is spreading the adoption of Microsoft technologies, eliminating competing technologies, and the technical innovations that they deliver are just a means to an end.
    Let's start with Xamarin, and my understanding of Xamarin: Xamarin is a company, and by default no company is moral. Replace Xamarin with Google, RedHat, Microsoft, Oracle, IBM, ... anything and you will see that no company is interested of contributing to other project excluding there is a case of money, politics or brand involved to support other products. "Do not evil" was the Google motto, and I don't see you bashing Google. What can be defined are: opensource (they don't talk with 'free' anymore) friendly companies and opensouce not so friendly companies.

    Sun was opensource friendly, when MS was not, but as of today Xamarin is opensource friendly, MS is also in the .Net C# world (F#, Iron* languages, MVC3 and 4, Entity Framework, etc.) were opensourced and paid (at least in part by MS full time developers). Did they have an interest to do it? Yes, as people start to be interested in another platforms (like iOS and ObjC or Java and Android), MS prefers that people to look for C# tools instead of looking in other places. With this perspective, Oracle is more of a bully (and Google is following close in my view) in the free software. They used to own some major opensource projects and some of them departed (MariaDB and LibreOffice). OpenJDK is great, given it was made by Sun public, and MS I can agree it doesn't have a similar "openess" whatever it means.

    Going back to Xamarin or MS and why they are not contributing into Java... in my view Java has two issues: is a dinosaur project (as of OpenJDK, the Hotspot are overly complex, maybe Jigsaw will simplify things a little) driven tight by Oracle, so there is little benefit for other companies to add contributions; even on the surface they look alike, internally are fairly different: bytecodes have different semantics (albeit similar as both are stack VMs), the places where there is a gap between Java and .Net can be solved fairly easy with this opensource project, or using Google's protocol buffers (which has a .Net implementation too).

  9. #49
    Join Date
    Feb 2013
    Posts
    233

    Default

    Quote Originally Posted by ciplogic View Post
    In fact is not feasible. JVM bytecodes are limited in count, by a wide margin:
    The current bytecodes are limited in count, but there is no reason they can't completely redesign that. That wouldn't even be that big a deal. The new VMs need to support old byte code of course, but that wouldn't conflict.

    Quote Originally Posted by ciplogic View Post
    As for Kotlin which I can comment (but not for Scala, as I never used it), I can say that are some specific features (mostly in static code analysis) which are guaranteed by the language. Maybe this feature alone makes the language useful for Jetbrains folks.
    I used to prefer the Kotlin approach. It's simpler for most mainstream programmers who are used to null to understand. However, after using it more, I believe that the Maybe/Option solution to avoid null entirely is better, even if it involves a small learning adoption curve.

    Quote Originally Posted by ciplogic View Post
    Sun was opensource friendly, when MS was not, but as of today Xamarin is opensource friendly, MS is also in the .Net C# world
    They are "open source" in the literal sense that they release source code to their products and allow project forks in many situations. That's a real benefit.

    However, JVM has more a culture of decentralized independence where there is maximum choice and the best technologies rise to the top regardless of vendor, where .NET is more of a curated walled garden ecosystem.

    If you look at independent technologies like Clojure that operate on both the JVM and .NET, it is far more adopted and embraced in the JVM community. Microsoft and Xamarin ignore it in their evangelism efforts and keynote speaches, and the .NET community follows suit.

    There is a huge ecosystem around .NET, and there is amazing, super high quality independent technologies, like Clojure. But the community is much more heavily vendor centric around Microsoft/Xamarin, and technologies that don't receive official endorsement from Microsoft/Xamarin are second class outsiders.

    Quote Originally Posted by ciplogic View Post
    by default no company is moral.
    You can say the same about people. No one is truely moral and almost everyone could be corrupted by unchecked power.

    There are still tangible differences between people, and groups of people, and organizations. Some companies make better products than others, and some ecosystems have a more open nature than others.

    Quote Originally Posted by ciplogic View Post
    Going back to Xamarin or MS and why they are not contributing into Java... in my view Java has two issues: is a dinosaur project
    You have some completely legitimate points where Java has technical deficiencies. Almost every technology does.

    It is silly to suggest that Xamarin are these neutral technology people who contentious decisions on a primarily technical basis that just coincidentally happen to unversally align perfectly with their big sponsor. This is all transparently political. Xamarin's history is evangelizing all Microsoft technologies and only Microsoft technologies. They've been heavy evangelists/supporters of .NET, C#, Silverlight, ASP.NET, LINQ, and F# and Microsoft's TypeScript. They ignore technologies like Clojure and extensively bash competing technologies like Java which is consistent with Microsoft evangelism. Xamarin has even been extensively involved with advocating for Microsoft's Office Open XML office document standards which doesn't even seem to have any technical significance to their products.

  10. #50
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    398

    Default

    Quote Originally Posted by DanLamb View Post
    The current bytecodes are limited in count, but there is no reason they can't completely redesign that. That wouldn't even be that big a deal. The new VMs need to support old byte code of course, but that wouldn't conflict.
    Let me clarify: when Java faced the option to have reified generics and change the VM, they decided to not change the VM because it was a big deal. You imply that is possible just because at the end, they can make a separate VM (like Dalvik) and pack it with the main VM and anything that is old runs the "classic JVM" and everything new runs the "Java3x" or whatever will be named with a different bytecode and meta-capable. Excluding we talk SF, in reality it will not be the case

    Quote Originally Posted by DanLamb View Post
    They are "open source" in the literal sense that they release source code to their products and allow project forks in many situations. That's a real benefit.

    However, JVM has more a culture of decentralized independence where there is maximum choice and the best technologies rise to the top regardless of vendor, where .NET is more of a curated walled garden ecosystem.
    JVM may have a descentralized culture, but can you name something that come from a non descentralized source? Like a non de-facto implementation. If you make your own Java, can you name it Java? Or do you need to pass JCK suite and to pay Oracle for this certification!?

    If you looked in the CLR world, the CIL/MSIL part was developed "in the open", it was developed by MS with feedback from HP and IBM. CIL (MSIL) and C# are ECMA specified (so are similar with JavaScript in this regard). Is the same with Xaml.

    Quote Originally Posted by DanLamb View Post
    If you look at independent technologies like Clojure that operate on both the JVM and .NET, it is far more adopted and embraced in the JVM community. Microsoft and Xamarin ignore it in their evangelism efforts and keynote speaches, and the .NET community follows suit.

    There is a huge ecosystem around .NET, and there is amazing, super high quality independent technologies, like Clojure. But the community is much more heavily vendor centric around Microsoft/Xamarin, and technologies that don't receive official endorsement from Microsoft/Xamarin are second class outsiders.
    In fact there are first class citizens in the .Net world: Boo is one, DLR is another (which was imported into C# 4.0 dynamic features), Iron* languages (as much as there was developed by MS was a bit faster than their native Ruby and Python implementations. Many of "second class citizens" as you name them are much more with your perspective about a "iron-fist" driven projects. The fact that MS offers many infrastructure projects like NuGet, good Xml parsers, good libraries for almost anything made much useless to create libraries for various aspects where Java created them. There is no need for Maven or OSGi in .Net's world, or a very little reason to exist a project like Jigsaw or InvokeDynamic.

    This is why most of development happened upstream, and Mono if you will look in what is it, is mostly made upstream. OpenTK (the OpenGL wrapper is higher quality than any Java OpenGL wrapper I know) was imported into Xamarin. Similarly MonoGame.

    Also there are stand alone projects in .Net world, I recommend to check OpenRA, is really a great game.

    Quote Originally Posted by DanLamb View Post
    You have some completely legitimate points where Java has technical deficiencies. Almost every technology does.
    You miss the point of all the cases I've told you. Is not to say that Java has deficiencies, was to say that your point that an "open flow of ideas" is not trivially possible as even the principles are the same the languages in fact are fairly different. Given this, you cannot make a reference parameter to Java (to make a swapReference function) for example. Is not to bash Java or the JVM, but simply to see that .Net has a different semantics so it cannot (trivially) make the flow of ideas flowing. Also, Java had a head-start of 5 years in many places, and right now is still important in some fields. .Net/Mono though got it to be significant in places

    Quote Originally Posted by DanLamb View Post
    It is silly to suggest that Xamarin are these neutral technology people who contentious decisions on a primarily technical basis that just coincidentally happen to unversally align perfectly with their big sponsor. This is all transparently political. Xamarin's history is evangelizing all Microsoft technologies and only Microsoft technologies. They've been heavy evangelists/supporters of .NET, C#, Silverlight, ASP.NET, LINQ, and F# and Microsoft's TypeScript. They ignore technologies like Clojure and extensively bash competing technologies like Java which is consistent with Microsoft evangelism. Xamarin has even been extensively involved with advocating for Microsoft's Office Open XML office document standards which doesn't even seem to have any technical significance to their products.
    First of all I never suggested that Xamarin is neutral, but I didn't see any point where Oracle is technology neutral. Does it support Android as of today? Is it Dalvik developped in the open?

    Another mistake is that you seem to have a bias against Xamarin as a MS supporter, but Xamarin is different from Miguel de Icaza. On his blog he writes that he doesn't present the position of his employer. So he supported Silverlight, Linq, Typescript and MS's Office Xml format, but Xamarin did not support all (some were supported like: C#, .Net, F#) but Xamarin is neutral on MS Office, Silverlight, TypeScript. Is it good to make this distinction for many reasons.

    Also, I think that depends how you count it Google is a Java supporter, but also is backstabbing many opensource projects in Java world. This kind of behavior is not so often found in the .Net world. Case and point: Android Studio is based today on IntelliJ IDEA Community edition, not on Eclipse, but Google did not submit patches or report bugs for none of the projects. Dalvik was implemented behind the closed doors (and still is, as ART runtime proves), and is a non-standard Java VM.

    Independent Java projects were not supported by big companies like Looking Glass.

    At last, why you use Scala as the best example, why don't *you* support it for .Net? In fact I found many .Net languages supported by Xamarin, at least if you report bugs that work in .Net you should get fixes to work inside Mono. In fact I remember I reported a bug in XSP (Asp.Net implemented in C# by Xamarin) and they fixed it, even is not their main thing they sell today.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •