Announcement

Collapse
No announcement yet.

Mono Developers Renew Their Love For Microsoft

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    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.

    Comment


    • #47
      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.

      Comment


      • #48
        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.

        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.
        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).

        Comment


        • #49
          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.

          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.

          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.

          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.

          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.

          Comment


          • #50
            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

            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.

            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.

            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

            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.

            Comment


            • #51
              Originally posted by ciplogic View Post
              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.
              This is just false. It was end developer source code migration compatibility, not VM or byte code issues. Directly from Neal Gafter who was a principal author on the JDK at that time

              http://gafter.blogspot.com/2006/11/r...for-java.html:

              Generics are implemented using erasure as a response to the design requirement that they support migration compatibility: it should be possible to add generic type parameters to existing classes without breaking source or binary compatibility with existing clients. I wrote about this two years ago. Migration compatibility is exploited widely in JDK5; all of the collection classes and interfaces use generics, yet existing code using collections continues to work. Without migration compatibility, the collection APIs could not be retrofitted use generics; we would probably have added a separate, new set of collection APIs that use generics. That was the approach used by C# when generics were introduced, but Java did not take this approach because of the huge amount of pre-existing Java code using collections.
              I prefer the C# solution and I believe most other devs do as well.

              Originally posted by ciplogic View Post
              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!?
              "name something from a non decentralized source"? Non decentralized is centralized, so Oracle? I don't think that's what you meant. Obviously, almost everything in the Java world comes from outside of Oracle: the popular languages (Scala, Clojure, Groovy), the two major IDEs (Eclipse and IntelliJ), the popular build tools (Ant, Maven, Groovy, SBT), plus the popular web frameworks, logging frameworks, testing frameworks, mocking frameworks, etc.

              A non de-facto implementation? Like RoboVM or IcedTea or JRockit (was acquired and merged into mainline JDK) or the ones from here: http://en.wikipedia.org/wiki/List_of...rtual_machines

              Java is a trademark protected word. You can't name your own tech Java, just like you can't name your own tech company Microsoft or Google either. That's not an unreasonable restriction.

              You can also freely fork Java, as long as you keep it under GPL terms, which Google didn't want to do with Android.

              I completely acknowledge there is uglier legal or political issues invovling the JCP and the disputes with Apache Harmony and even Android.

              Originally posted by ciplogic View Post
              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 where we agree to disagree. You point out all these open source .NET projects and activity which I'm generally aware of and point out that C# has official ECMA standardization which I already know, but then you say that MS technologies are so good, that .NET doesn't need the same type of open source choices. That last part is where we can agree do disagree. I've worked in C# companies for years, and often there's various Microsoft standards, which to others are fine, but to me are awful, and there's just a widespread hostility to non-Microsoft alternatives. I find that stifling. Clearly, you are happy with .NET as a more heavily curated ecosystem, and so are a lot of other perfectly intelligent developers.

              Originally posted by ciplogic View Post
              First of all I never suggested that Xamarin is neutral, but I didn't see any point where Oracle is technology neutral.
              The one big difference is that when Oracle does something arguably wrong, the community is more willing to adopt non-Oracle solutions.

              Originally posted by ciplogic View Post
              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.
              Miguel is the founder and CTO and spokesperson for Xamarin. That is silly to claim that he doesn't represent the team when he's talking about work relevant issues. Did Steve Jobs not represent Apple? Sure, there is some difference between the leaders and the official company.

              Before Xamarin split from Novell and chose its current name, that team did support and promote Silverlight for many years before eventually cancelling it.

              Originally posted by ciplogic View Post
              At last, why you use Scala as the best example, why don't *you* support it for .Net?
              It's not my job to promote Scala and I don't want to put more effort into promoting it than making casual recommendations. Scala tried to support both JVM/CLR in the past, but I presume the cost of supporting different ecosystems, and a lack of interest from the .NET side didn't justify it. The typesafe guys make lots of effort to cater to both Java and C# developers.

              Comment


              • #52
                Originally posted by DanLamb View Post
                This is just false. It was end developer source code migration compatibility, not VM or byte code issues. Directly from Neal Gafter who was a principal author on the JDK at that time

                http://gafter.blogspot.com/2006/11/r...for-java.html:
                Did I read the same text as well? Yes, maybe I misread but the Java did care (maybe too much) on backward compatibility so it wasn't able to make a (fairly trivial from bytecode standpoint) change to support "full" generics. If you look from CIL instruction set, there is no (visible) bytecode change (there are some extra parameters the class Type has to have to make things working) to support generics explicitly. This is in stark contrast with the idea of adding support for unsigned int, in which JVM (if it follows the previous bytecode philosophy) doesn't have bytecodes to spare (and imagine the previous code will be 100% compatible, so is out of the talk of Generics that can break code).
                Originally posted by DanLamb View Post
                "name something from a non decentralized source"? Non decentralized is centralized, so Oracle? I don't think that's what you meant. Obviously, almost everything in the Java world comes from outside of Oracle: the popular languages (Scala, Clojure, Groovy), the two major IDEs (Eclipse and IntelliJ), the popular build tools (Ant, Maven, Groovy, SBT), plus the popular web frameworks, logging frameworks, testing frameworks, mocking frameworks, etc.

                A non de-facto implementation? Like RoboVM or IcedTea or JRockit (was acquired and merged into mainline JDK) or the ones from here: http://en.wikipedia.org/wiki/List_of...rtual_machines
                Yes, this is in fact what exists also in the .Net world, some parts were replaced by upstream implementations (like Nant was and is still popular, but people use today MSBuild because is well integrated with both VS or Xamarin or SharpDevelop). Some items are not yet replaced by far like: NUnit is far more popular than MSTest, and in my work for years I have not seen any MSTest "shop" to say so. NUGet makes so hard to make another replacement usable (they were, like Mono.Addins), because it is integrated vertically (from the command line to IDEs) and also horizontally: it supports C#, VB.Net, C++, etc. NHibernate was really very popular before Entity come about, and the success of Entity was based on many folds of reasons again: it was opensource, well packaged, well documented, supported by MS, as it was MVC3 or MVC4, the "new" MS way to implement web frontends. There are in fact a lot of opensource/free packages in the C# world, maybe a half of what you have in Java (with Maven), but is a non-trivial number (Stable packages: "There are 16768 packages" ).

                But what I meant by Java contributions in a descentalized source (you're right, I've mistyped) is that major contributions from outside that went back to Oracle. Like let's say an Hibernate to become the reference JPA implementation, or OSGi to be a standard way accepted by Oracle to modularize (at leas the high level components). What about MS/Xamarin. As was told earlier DLR started as an opensource project and is still opensource (even it "runs" the dynamic C# part), Ikvm.Reflect is the reflection API of the Mono's C# compiler.

                Originally posted by DanLamb View Post
                Java is a trademark protected word. You can't name your own tech Java, just like you can't name your own tech company Microsoft or Google either. That's not an unreasonable restriction.

                You can also freely fork Java, as long as you keep it under GPL terms, which Google didn't want to do with Android.

                I completely acknowledge there is uglier legal or political issues invovling the JCP and the disputes with Apache Harmony and even Android.

                This is where we agree to disagree. You point out all these open source .NET projects and activity which I'm generally aware of and point out that C# has official ECMA standardization which I already know, but then you say that MS technologies are so good, that .NET doesn't need the same type of open source choices. That last part is where we can agree do disagree. I've worked in C# companies for years, and often there's various Microsoft standards, which to others are fine, but to me are awful, and there's just a widespread hostility to non-Microsoft alternatives. I find that stifling. Clearly, you are happy with .NET as a more heavily curated ecosystem, and so are a lot of other perfectly intelligent developers.
                The one big difference is that when Oracle does something arguably wrong, the community is more willing to adopt non-Oracle solutions.
                As I've told you, NUnit is far more popular, even MSTest is integrated with Visual Studio. NAnt was more popular than .bat files, and I've seen it working in big C++ companies before MSBuild was in place. I used NRefactory and I see no replacement for controls like AvalonDock or AvalonEdit.

                [QUOTE=DanLamb;373771]
                Miguel is the founder and CTO and spokesperson for Xamarin. That is silly to claim that he doesn't represent the team when he's talking about work relevant issues. Did Steve Jobs not represent Apple? Sure, there is some difference between the leaders and the official company.

                Before Xamarin split from Novell and chose its current name, that team did support and promote Silverlight for many years before eventually cancelling it.
                It is not silly to claim that he doesn't represent the team. Because for example Miguel has political views, and clearly not everyone share his views. Steve Jobs did refrain to state politics on Twitter for example. Similarly, Novell had a politics (albeit criticized from Linux folks) of interoperability, so it was normal that if Miguel (or Novell) believed that they want to interoperate with MS, they have to make Mono compatible and to promote their stuff.

                Why I say that Miguel is different from let's say Xamarin or Novell, is at another level: certainly he was bashing C++ or Java on his blogs, but also people from other communities do it also. Rob Pike (Go creator) does it, Herb Shutter (is from Microsoft btw) the C++ committee head in his presentations is a collection of logical fallacies, and I think for Miguel to answer to him was at least appropriate. Is it also true from other members (I don't know all the outspoken Java folks, but Cliff Chick did comment that Java can beat C++ handily and he retracted some claims).

                Taking of the face value, Miguel was (and I think he still is) an enthusiast, a dreamer (at least technology wise, as politics he looks down to earth to me) and he made many claims promoting MS technologies (which he obviously like). Anyway, he did it many times with fairly good reasons. For example his promotion of MS OpenXml, and the support in Gnumeric is common sense for me: he stated that Gnumeric internals were matching really well the MS format, so it was much easier to support than ODF and for small projects is overkill; his promotion of Silverlight was that he didn't want that Linux to be the "second or third class citizen" in the case that Silverlight is successful. I think that these are good views in themselves (even are made from a partisan standpoint).

                Originally posted by DanLamb View Post
                It's not my job to promote Scala and I don't want to put more effort into promoting it than making casual recommendations. Scala tried to support both JVM/CLR in the past, but I presume the cost of supporting different ecosystems, and a lack of interest from the .NET side didn't justify it. The typesafe guys make lots of effort to cater to both Java and C# developers.
                Yes, I fully know what you mean, and I see that most of the differences between Mono (which is an open environment, as Java is) and Java is mostly about the perceived culture. As for me I'm not so interested in Scala(the same about Closure), but not because I have something against Java, but because sometimes the combination of IDE, tools (paid ones) that are given from my company and opensource/free ones do successfully fill my needs. If I need a fancy toolkit, there is XWT, which is developed in the open and is the base of a major IDE in the Mono world (so is "half supported"), it is a vibrant and kicking. Is it anything than Swing (which is to be deprecated) and JavaFX around in the Java world?

                Comment


                • #53
                  Originally posted by ciplogic View Post
                  Did I read the same text as well? Yes, maybe I misread but the Java did care (maybe too much) on backward compatibility so it wasn't able to make a (fairly trivial from bytecode standpoint) change to support "full" generics. If you look from CIL instruction set, there is no (visible) bytecode change
                  If you did read the same text, you completely skimmed over the main points. He's talking about source code compatibility and you are talking about byte code issues. I believe you that the CIL instruction set didn't change, but C# rewrote their collections classes so C# 1.0/1.1 and C#2.0 used different collections classes and that posed a source code migration issue with existing C# 1.0/1.1 client code. The C# people may have made the better choice in hindsight, but I don't see any evidence that the Java implementation was hung up on legacy byte code restrictions.

                  Originally posted by DanLamb View Post
                  As I've told you, NUnit is far more popular, even MSTest is integrated with Visual Studio. NAnt was more popular than .bat files, and I've seen it working in big C++ companies before MSBuild was in place. I used NRefactory and I see no replacement for controls like AvalonDock or AvalonEdit.
                  But I have told you, I am completely aware and in agreement that high quality open source technology exists in the .NET space. I'm not denying that exists or challenging you to list examples.

                  My perception is that the .NET culture is still much more Microsoft centric and curated and there is less tolerance or interest in technologies that are not endorsed and promoted by Microsoft/Xamarin.

                  Isn't MSBuild a Microsoft created and owned tech? The NAnt/MSBuild story you cite seems to confirm my belief: the official Microsoft/Oracle had a weak build solution so open source fills the role... With Java, the third party tool achieves predominance because it's just that good. With .NET, the Microsoft tool achieves predominance because it's Microsoft.

                  Originally posted by ciplogic View Post
                  It is not silly to claim that he doesn't represent the team. Because for example Miguel has political views, and clearly not everyone share his views. Steve Jobs did refrain to state politics on Twitter for example.
                  Sure, when Miguel expresses extreme political views or when Steve Jobs talked about his LSD experiences, clearly those have little to do with the function of the teams and the leadership role of those people. Those views aren't representative of the team or its members.

                  When Steve Jobs expresses negativity towards Flash or Blu-Ray, I'm sure there is plenty of disagreement within the members of the team, but it is reasonable that that viewpoint is representative of the team as a whole and the direction they are going in.

                  Originally posted by ciplogic View Post
                  Yes, I fully know what you mean, and I see that most of the differences between Mono (which is an open environment, as Java is) and Java is mostly about the perceived culture.
                  This is correct. The perceived culture and also the perceived level of choice and quality that result from that culture.

                  Originally posted by ciplogic View Post
                  If I need a fancy toolkit, there is XWT, which is developed in the open and is the base of a major IDE in the Mono world (so is "half supported"), it is a vibrant and kicking. Is it anything than Swing (which is to be deprecated) and JavaFX around in the Java world?
                  Swing is already deprecated by JavaFX for new projects, but Swing will continue to be fully supported for quite a while because it is used so heavily. I had never heard of XWT. Well, that's definitely a contender for a workstation platform agnostic GUI toolkit. In the past, the Mono fans heavily advocated native toolkits over platform agnostic toolkits.

                  Comment


                  • #54
                    Originally posted by DanLamb View Post
                    If you did read the same text, you completely skimmed over the main points. He's talking about source code compatibility and you are talking about byte code issues. I believe you that the CIL instruction set didn't change, but C# rewrote their collections classes so C# 1.0/1.1 and C#2.0 used different collections classes and that posed a source code migration issue with existing C# 1.0/1.1 client code. The C# people may have made the better choice in hindsight, but I don't see any evidence that the Java implementation was hung up on legacy byte code restrictions.
                    So let me clarify the original point and topic: Java historically was much more conservative because there are historical issues (like a lot of code written in a specific version of JVM) but also technological issues. My understanding of the "Java guy" is simply that even it would be possible the new collections to be "fully" generic there is a cost of source migrations that is too big. Even so, the technicalities of generics (look on the next paragraph) are a much smaller issue on the bytecode level, compared with support of bytecode instructions. It is because JVM has only 256 (theoretical) bytecodes and the semantics of the bytecodes contain the type of the operations, so adding a new primitive type adds in itself a lot of "unwanted" bloat in bytecodes usages.

                    As for CIL, you get two levels of information (the same is true for JVM): the "reflection"/"class metadata" kind of informations and the bytecode operations (CIL instruction set). To support Generics as far as I'm aware is no change (maybe there is one change) from the CIL instruction set. Anyway, the original point was that to add support for unsigned integers (for example) require much more semantic instructions on the JVM level from one side, and there are less "empty" slots than in the .Net case. Going back to generics, I said that the fact that the generics code generated by Java 1.5 would run on Java 1.4, even it would require very little machinery from the JVM side (none!?), this is not the case when you have to spare some of the 16 opcodes left for 5 math operations to support unsigned. Even more when this new code would require if you want to support all unsigned int types (like from Uint8 to Uint64, all supported by .Net), you may likely not have enough bytecodes, and even you have, you don't know the future, so is a bad decision to define them with no chance to go back.

                    Java can create tomorrow with very little work on their side of the bytecode level (the JVM will have a huge task ahead, as many methods should be cloned and specialized) a new set of collections (as for Java 10!?) and reified generics. The biggest work should be on "metadata" and on "hot-spot" level, which both of them may face non-trivial migration issues, but are no technical limitations. As I've told you earlier: JVM is limited on 255 arguments per method. You can change this limitation on the Hotspot level, but you can't change this on the bytecode level (as "load argument" instruction has a 1 byte after this, so you cannot write "load argument" and after that the parameter to be 320). To be clear, these can be circumvented if the .class format will have a "version 2.0" which is incompatible with "old .class files", but as for now, there are big technical limitations (which were fully adequate for 1995 year when Java was launched), but as of today, they are not so much.
                    Originally posted by DanLamb View Post
                    (...) Swing is already deprecated by JavaFX for new projects, but Swing will continue to be fully supported for quite a while because it is used so heavily. I had never heard of XWT. Well, that's definitely a contender for a workstation platform agnostic GUI toolkit. In the past, the Mono fans heavily advocated native toolkits over platform agnostic toolkits.
                    XWT is both agnostic and "gnostic" because it is implemented over native controls and you can also access the underlying native controls. So it matches the Mono "perspective" about UI toolkits.

                    Comment


                    • #55
                      Originally posted by ciplogic View Post
                      To be clear, these can be circumvented if the .class format will have a "version 2.0" which is incompatible with "old .class files"
                      The .class file format has frequently changed so that older JDKs can't use them. This type of incompatibility is the norm and is very common. Same with .NET and most similar systems.

                      Originally posted by ciplogic View Post
                      but as for now, there are big technical limitations
                      I believe your technical comments on the current structure of the JDK/CLR byte code.

                      I don't trust this personal judgement of yours as to the scale and complexity of JDK team changes to the VM byte code. I believe you are exaggerating this.

                      You are dismissing Neal Gafter as some "Java guy" (your quotes), who was directly involved with the implementation of JDK generics, who quite clearly says that they designed JDK generics with erasure to avoid the source code migration issue that C# faced, not because of underlying technical reasons. You could question his honesty or motivation, but that's clearly what he is claiming. Also, this "Java guy" has been a full time employee at Microsoft working on .NET for the past several years.saying

                      Comment


                      • #56
                        Originally posted by DanLamb View Post
                        The .class file format has frequently changed so that older JDKs can't use them. This type of incompatibility is the norm and is very common. Same with .NET and most similar systems.
                        I believe your technical comments on the current structure of the JDK/CLR byte code.

                        I don't trust this personal judgement of yours as to the scale and complexity of JDK team changes to the VM byte code. I believe you are exaggerating this.
                        Of course I'm not exagerating this, because simply I know both bytecode formats. And as I've told you, there are let's say 32 positions out of 256 remaining. The reason I'm knowing this is simply because both formats are public and clearly described. Of course, these free slots can be extended like to be an "escape bytecode" and they will describe another codes on the 2nd byte. This will change that all bytecodes of JVM use 1 byte per bytecode (and this is why I've been clearly saying: keeping the same philosophy). Of course, JVM is free to break the bytecodes and to use another convention to make eventually support of bytecodes. Or maybe it will use a trick to push as a previous instruction the word size and it will have 1 "unsigned int" and the previous "push int" instruction will say the length of this int as being: uint8, uint16, uint32, ... uint128. All these "tricks" would make handily into 256 byte codes, but... they break the way the other bytecodes are done as of today in JVM.
                        You are dismissing Neal Gafter as some "Java guy" (your quotes), who was directly involved with the implementation of JDK generics, who quite clearly says that they designed JDK generics with erasure to avoid the source code migration issue that C# faced, not because of underlying technical reasons. You could question his honesty or motivation, but that's clearly what he is claiming. Also, this "Java guy" has been a full time employee at Microsoft working on .NET for the past several years.saying
                        I'm not dismissing Neal , I am more than sure that he is more skilled in the JVM than I am in .Net, but still this doesn't make the points stated false: bytecode instructions are limited and they don't use type inference (as .Net does) as the bytecode level. I certainly also know much less than Herb Sutter, or Miguel de Icaza or Steve Jobs (when he was alive). There are a lot of people around, but claims can be checked.

                        Type erasure takes a lot of work to get it right, and given the Java state I am sure it was a difficult decision, but yet if Java 1.5 would have full generics would break many things (not only source wise, as you can still you can write C# 1.0 ArrayList in .Net 4.5 with no breakage), I would understand the inertia in Java world.

                        Java class format is fairly fixed too, and the changes in between releases are fairly trivial. (in fact is the same in .Net 1.x, 2.x-3.5x, 4.x)

                        Please read an instruction in the Java world (look to any instruction from this link). Look that the instruction.

                        Let's look for example to SHL (shift left, << in C languages):

                        Instruction:

                        http://docs.oracle.com/javase/specs/...ml/jvms-6.html

                        ishl
                        Operation

                        Shift left int
                        Format


                        ishl
                        Forms

                        ishl = 120 (0x78)
                        Operand Stack

                        ..., value1, value2 →

                        ..., result
                        Description

                        Both value1 and value2 must be of type int. The values are popped from the operand stack. An int result is calculated by shifting value1 left by s bit positions, where s is the value of the low 5 bits of value2. The result is pushed onto the operand stack.
                        http://msdn.microsoft.com/en-us/libr...vs.110%29.aspx

                        A value is pushed onto the stack.

                        The amount of bits to be shifted is pushed onto the stack.

                        The number of bits to be shifted and the value are popped from the stack; the value is shifted left by the specified number of bits.

                        The result is pushed onto the stack.

                        The shl instruction shifts the value (type int32, int64 or native int) left by the specified number of bits. The number of bits is a value of type int32 or native int. The return value is unspecified if the number of bits to be shifted is greater than or equal to the width (in bits) of the supplied value.
                        This is why you have for example iadd, fadd, dadd (int add, float add, double add) in the JVM instruction set, when in CLR there is just one instruction: add (that works over all types: int*, uint*, float, double).

                        Comment


                        • #57
                          Originally posted by ciplogic View Post
                          Of course I'm not exagerating this, because simply I know both bytecode formats. And as I've told you, there are let's say 32 positions out of 256 remaining. The reason I'm knowing this is simply because both formats are public and clearly described.
                          My assertion is that you are exaggerating the technical effort of implementing reified generics in Java and the effort of changing the Java byte code. I did not and do not challenge the details your knowledge of the current state of the VM or the details that you cite.

                          Originally posted by ciplogic View Post
                          you can still you can write C# 1.0 ArrayList in .Net 4.5 with no breakage
                          I know that and so does Neal Gafter. That's not what we are talking about.

                          If there is a C# 1.0 library written with ArrayList, and has many clients using it, you can't remove ArrayList and change to List<Int> without breaking source code compatibility and requiring client code to change.

                          Comment


                          • #58
                            Originally posted by DanLamb View Post
                            My assertion is that you are exaggerating the technical effort of implementing reified generics in Java and the effort of changing the Java byte code. I did not and do not challenge the details your knowledge of the current state of the VM or the details that you cite.(...)
                            If there is a C# 1.0 library written with ArrayList, and has many clients using it, you can't remove ArrayList and change to List<Int> without breaking source code compatibility and requiring client code to change.
                            Let's clarify once again, and I rephrase the argument, even it will state the all facts the same.
                            I started the topic line with the idea that JVM will not support unsigned int and you replied:
                            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.
                            The parts that you say: there is no reason, but you ignore the fact that I give to you the reason: the JVM bytecode policy doesn't allow to add bytecodes as you have limited free slots. I give to you the specification so is it really in your power to check this. Reified generics could remain debatable, as about "how easy" or "how hard" it is, but let's state for the sake of argument, that is possible. I think that is likely possible. Anyway, this is because the way in .Net the generics are implemented, can be mapped even with today's limited capabilities to some extend to Java .class support (or by having name mangling and copies in a higher level language).

                            But this doesn't change the part of the "easy" and "difficulty" of a component to invalidate my first point. The bytecode remains limited. I even went to the extent to give to you the sources so you can analyze the statement and see the faults. Either in my logic or in the links. who knows, maybe for you is as easy as to say how can be defined "Unsigned int" by providing a model of how this can be done, and this to be easy to retrofit into the JVM bytecode.

                            If not, to me the talk doesn't seem equal, isn't it? I can say a lot of baseless statements about Java:
                            - it is easy to retrofit Oracle's Java SE on mobile phones, Oracle don't do it just for political reasons (to limit Java access on a high quality reference JVM)
                            - it is easy to JVM to work with pointers directly, but Java wants to be a simple C, otherwise will be a just over-the-weekend work for them
                            - Oracle added a bytecode in 12 years (from Java 1.4, that changed how trigonometric function works, there is no major another instruction addition than invokedynamic), so if it is that hard, so it will take for them 100 years to add 10 other bytecodes
                            - Jigsaw is the easiest solution to take, they just copied GAC design, it was decided just because Oracle didn't like OSGi
                            - etc.

                            But all this statements would be false, isn't it?

                            I can make as many statements with easy/hard, but for me, based on how the things are publicly documented, there is a disconnect with no source.

                            Comment


                            • #59
                              Originally posted by ciplogic View Post
                              The parts that you say: there is no reason, but you ignore the fact that I give to you the reason: the JVM bytecode policy doesn't allow to add bytecodes as you have limited free slots. I give to you the specification so is it really in your power to check this.
                              The spec shows how it is now, but it generally doesn't show you what future versions can or can not contain. JDK 9 can ignore that entire spec and use a completely different standard with a different spec.

                              Originally posted by ciplogic View Post
                              I can make as many statements with easy/hard, but for me, based on how the things are publicly documented, there is a disconnect with no source.
                              I don't think I have proved or even could prove my point that making VM changes is easier than you are suggesting it is. You disagree, and assert it would be a larger effort to change VM byte code, but you also can't prove that. I think we just have to accept an unresolved disagreement on this issue.

                              Comment


                              • #60
                                Originally posted by ciplogic View Post
                                the JVM bytecode policy doesn't allow to add bytecodes as you have limited free slots. I give to you the specification so is it really in your power to check this.
                                Let me try once more. This point shouldn't be debateable:

                                Let's say the JDK9 or JDK10 devs take the spec with the byte code limits and flush it down the toilet and write a new system with a new spec that doesn't have those limits. As the old spec is working its way through the sewer system, how does it prevent the new system from working?

                                Comment

                                Working...
                                X