Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Java Programming

Java Creator James Gosling on C# And More 52

DreamTheater writes: "Java inventor James Gosling says he isn't losing much sleep over Microsoft these days, despite the software giant's effort to stem Java's popularity with its own Java-like language." Gosling talks about other things in this interview, too, like his current project of developing a good IDE.
This discussion has been archived. No new comments can be posted.

Java Creator James Gosling on C# And More

Comments Filter:
  • C# has already geared itself up for a dominant position in tomorrow's enterprise development environment due to its ECMA standardisation and Microsoft's atypical encouragement of competing implementations (hence Mono, Portable.NET and other such projects). Microsoft's not stupid -- they know from history that open, standard systems almost always outcompete even the most entrenched closed systems eventually.

    Sun has scared off a large potential userbase for their Java platform with their obsessively protective and litigious treatment of their intellectual property. Only Apple is more ferocious in their protection of trademarks and copyrights, and we've all seen the marginalising effect Apple's insular attitude has had. Unless Sun has a rapid change of heart, .NET, C# and the CLR is going to vapourise Sun's marketshare in server applications and enterprise programming userbase due to sheer openness. And you can rest assured that, once Microsoft's asserted their dominance in the field, .NET won't remain an open standard for long.

    • If Sun was so "worried" about MS "taking-over" Java, they probably should look at J#, http://msdn.microsoft.com/visualj/jsharp/beta.asp. Given the fact that nothing about it is mentioned is a bit surprising.
    • by TurboRoot ( 249163 ) on Friday January 18, 2002 @12:56AM (#2860383)
      This is the common FUD spread by Microsoft regarding the Java standard, but you forgot one important thing... the truth.

      The truth is.. Sun can't protect an open standard. If Java was a totally open standard then Microsoft could "embrace and extend" Java into the ground and destroy it. Sun isn't stupid.

      The truth is, Sun makes every step possible to keep Java as standard as possible and documents it VERY VERY VERY well. Go to http://java.sun.com/docs/books [sun.com] and see for yourself. Scroll down, look at the bottom. THAT is the standard.

      Sun also goes to great pains to receive feedback from the community and industry. In fact a lot of the EJB and J2EE standards were dictated by application server companies.
    • by MarkMac ( 13774 ) on Friday January 18, 2002 @09:50AM (#2861954)
      Microsoft's not stupid -- they know from history that open, standard systems almost always outcompete even the most entrenched closed systems eventually.

      What a BIZZARE statement regarding Microsoft. Never mind that Visual Basic - the most widely used programming language - is completely proprietary and Microsoft windows specific. Never mind that Microsoft has perverted every "open" standard they use to add their own extensions (often undocumented) effectively turning them into proprietary protocols. The C# language specification may have been passed off to an obscure standards group (that normally doesn't deal with computer languages) but it hardly opens up all of the APIs which really define .NET and the use of C#. "Embrace and extend" is a standard Microsoft policy - has been for a long time and will continue to be. It is not at all clear that CLR and .NET are open standards as it is given the possibility of hidden patents etc.

      Microsoft was caught doing the same thing to Java once they had licensed its use (SUN was pretty naive to have permitted this - maybe they didn't have good enough lawyers ...). As soon as the court found Microsoft guilty, Microsoft announced it would dump Java for their own language which turned out to be C# (that looks and works a lot like Java).

      Unless Sun has a rapid change of heart, .NET, C# and the CLR is going to vapourise Sun's marketshare in server applications and enterprise programming userbase due to sheer openness.

      While SUN has not given up the trademark "Java", this language is hardly as restricted in use as Microsoft would like to imply. Given the incredible number of licensees of various forms of Java would hardly imply that the user base is scared off by SUN's intellectual property. Indeed, Microsoft's past insidious behavior will haunt their promotion of .NET as the new "open" standard. (Who hasn't gotten over the years burned by Microsoft's business practices ...)

    • by Martin S. ( 98249 ) on Friday January 18, 2002 @10:23AM (#2862193) Journal
      C# has already geared itself up for a dominant position in tomorrow's enterprise development environment

      This reads like Marketing hype worthy of the FUD-Master General himself.

      ... its ECMA standardisation

      ECMA standardisation is a red herring when it comes to openness. ECMA is a closed organisation. As an individual expert Software Enginner I cannot join and influence language development at ECMA. However I can (and have) joined the JDC and bring my ideas to bear on the development of Java at (http://developer.java.sun.com/). This is open to anybody, including Microsoft.

      Furthermore you only have to consider the death of the ECMA standardisation of JavaScript which has been an abysmal failure to seem that, ECMA is not a guarantee of a successful standardisation.

      and Microsoft's atypical encouragement of competing implementations

      You've obviously not been keeping up on current affairs. Microsoft have been found guilty of anti-competative behaviour in the US and are about to get another nailed in the EU too.

      http://news.bbc.co.uk/hi/english/business/newsid _1 635000/1635317.stm
      http://news.bbc.co.uk/hi/english/business/newsid _1 697000/1697766.stm

      .NET, C# and the CLR is going to vapourise Sun's marketshare in server applications and enterprise programming userbase due to sheer openness.

      Hardly likely; Microsoft have minimal existing presence (or mindshare) in the heavy weight enterprise sector. As long as they stick to the attitude of stick security, robustness and quality, they never will.

      once Microsoft's asserted their dominance in the field, .NET won't remain an open standard for long.

      The only truth, in your entire post, Embrace and Extend.

      Perhaps we need another Moderation option (-1 Astrotufer).
  • Flamebait? (Score:2, Insightful)

    'You guys (at Microsoft) still don't get it,' because it's sort of Java with reliability, productivity and security deleted."

    Quite simply ... this attitude worked for Windows 95, so why should MS be rattled by these remarks?

    Once Microsoft have got the market share, they can work on the reliability and security.
  • my $0.02 (Score:3, Insightful)

    by Adrian Voinea ( 216087 ) <adrian.gds@ro> on Thursday January 17, 2002 @05:28PM (#2858227) Homepage Journal
    I think from the level of people who make decisions about what programming languages to use on commercial projects (this includes me), the technical distinctions between Java and C# are of little concern: the languages are so similar that they are basically interchangeable. What matters is who supports it, what libraries are available, how mature are the implementations, whether it's a single-vendor or mult-vendor solution, how well it integrates with the platform, and how many programmers are available.

    For pure Windows programmers, C# wins there and will probably be picked up by lots of VB and VisualC++ programmers. But people who live in that world are already not using Java. For everybody else, Java seems to win hands down. I think C# will neither be a complete failure nor will it do much harm to Java.
    • the technical distinctions between Java and C# are of little concern

      You have fallen for the M$ FUD; IMHO these distinction(s) are pretty fundamental.

      1) Java is platform agnostic, C(hash) is WOSA only; couple this with fact that WinTel platform is dying at the hands of a raft of alternative platforms(http://news.bbc.co.uk/hi/english/busines s/newsid_1767000/1767695.stm)
      2) Java is an industry wide product, C(hash) is from only one supplier.
      2) Java is OO, C(hash) is not. [It's encapsulation mechanism is broken, all members are essentially public].
      • It's encapsulation mechanism is broken, all members are essentially public

        That's news to me. Can you provide details?

        -- Brian

        • It's encapsulation mechanism is broken, all members are essentially public

          That's news to me. Can you provide details?

          Yes, A private member may be accessed directly, just as if it is a public member, this breaks encapsulation, for example:


          localMember = anObject.privateMember ;
          anObject.privateCounter ++;


          http://searchnetworking.techtarget.com/sDefiniti on /0,,sid7_gci212060,00.html

          http://genamics.com/developer/csharp_comparative .h tm#2
          • Sorry, but I think you're wrong -- or at least confused about the difference between fields and properties in C#. AFAIK, C# does not allow direct access to private members.

            Thanks anyway.

            -- Brian
          • C# has properties - a mechanism also seen in Delphi. The same chap designed both languages, but the features is not new. It was also in common lisp. A property looks like a public field to the outside world, but under the covers overridable accessor methods get called, so you can override the behaviour or make them read-only.
            • C# has properties ...

              In OOP; a field, a property, a member, or what ever you care to call it are all the same thing. The terminology is different languages for different languages.

              They are ALL a variable encapusulated within an object.
              • by SimonK ( 7722 )
                In C# and Delphi "property" has a special meaning distinct from "field". A field is a bit of storage set aside for storing a value. These, of course, should not be public because they are an implementation detail.

                It is common, however, in OO languages to expose getX and/or setX methods for a value X which may or may not be stored in a field. Thats OK, provided it is done for a good reason, and not abused to violate class invariants, because the implementations can be changed. So if getX starts off returning the value of a field X, I can later change it to return Y * 42, or whatever else I please. In the jargon, exposing setter and getter methods decouples the implementation from the interface exposed, whereas exposing the field X directly would not. It is this, and not slavishly hiding data values, that matters, because it makes software easier to maintain.

                The only problem is that writing a.setX(3) or p = a.getX() is clumsy compared with writing a.x = 3 or p = a.x. Thus a series of languages, starting with Common Lisp, and the most recent example being C#, have provided mechansisms by which the standard = notation can be used to call a setter method, and standard expression notation can be used to call a getter. Its only a syntactic convenience, though. The actual implementation - whether there is a field or not - is still hidden.

                To anyone who has developed a big application in language - like Java or C++ - without this feature, the attraction should be obvious.
            • Comment removed based on user account deletion
          • Who the heck modded this up as informative? It's just wrong. The bottom link goes to a page that describes the differences between "fields" and "properties" in C#. The top link simply defines the OO term "encapsulation". In neither instance is there any evidence that C# is not OO.

            -- Brian
            • It's just wrong.

              Care to back that up with a fact based argument rather than a blanket assertion ?

              The bottom link goes to a page that describes the differences between "fields" and "properties" in C#.

              Perhaps I should have beem more specific about what the links represented.

              The first link goes to a C# Advocacy site that admits the pertinent facts (though it attempts to dress them up as an ease of use advantage). Anybody with even remotest familiar with the concepts of encapsulation or OO, SHOULD understand the ramifications of this (summary below) and can draw their own conclusions.

              This mechanism allows members to be accessed directly outside the Object in the following fashion.

              anObject.aMember = anOther.aMember ;

              Since this can be done even when aMember is private, this is a blatant violation of encapsulation.

              The top link simply defines the OO term "encapsulation".

              Yes; since few slashdot readers are actually OO Software Engineers, this was an attempt inform those unfamiliar with the expression, of what it actually means.

              In neither instance is there any evidence that C# is not OO.

              The first explains what encapsulation is the second is how C# violates it, my post is the conclusion; that since C# violates encapsulation it is not an OO language. The links are most certainly the only evidence you need to draw that conclusion.
              • The point of encapsulation is not to slavishly conceal all the data possessed by an instance of a class. In many cases its quite legitimate to expose functions to get and set data values - although I can provide you with much abuse of programmers who do so thoughtlessly. Properties (as in C#) just provide a formalised mechanism for doing this.

                If this isn't clear to you, we need to examine what exactly encapsulation is, and what it is intended to accomplish. To do that, we need to do right back to the roots of modular programming, and the concept of coupling. Modules - including classes for these purposes - are meant to be decoupled from one another. Thats just a smart way of saying that a module should only depend on the interface of any any other module, and that interface should support all the possible alternative implementations. Decoupling matters because it allows the implementation of each module to vary independently of the rest.

                Encapsulation is just part of the OO way of allowing for decoupling. The implementation varies between OO languages, but the common theme is that they place what functions and data are exposed by a class under the control of the developer of that class, rather than its user. So, for instance, while in C if my struct foo has a field bar, anyone who imports the definition of foo can access bar, OO languages provide mechanisms by which the person responsible for foo can prevent this. The point is not "data hiding" as people often naively say, objects very frequently expose data (although not actual fields) but hiding of the details of how foo is implemented.

                Now, you're claiming that C#'s property mechanism removes this useful property of OO languages. That is not true, and won't become so regardless of how often you repeat the assertion. Much though I dislike the language and the politics behind it, I'll stop short of endorsing false statements about it.

                Developers of C# classes do not have to expose their fields as properties, nor are they committed, by exposing a property, to keeping the corresponding field in place. Thus, when I write code that makes use of a property, I am not preventing the developer of the class from varying its implementation. Both encapsulation, and the real reason for having it - decoupling - are still there.

                Reread the admirable definition of encapsulation you posted: objects publish their interfaces, and contain all the code and data needed to implement those interfaces. That is just as true in C# as it is in Java or C++.
              • by Shimmer ( 3036 )

                Care to back that up with a fact based argument rather than a blanket assertion ?

                Sure. I happen to have Visual Studio.NET right here. Let's give it a try, shall we?

                class B
                {
                public B() {}
                private int privateMember;
                }

                class A
                {
                static void Main(string[] args)
                {
                B b = new B();
                b.privateMember = 5;
                }
                }

                When compiled, this program produces the following error on line 12:

                error CS0122: 'B.privateMember' is inaccessible due to its protection level

                Any questions?

                -- Brian

  • Er, No... (Score:5, Insightful)

    by barnsleyBigUn ( 84793 ) on Thursday January 17, 2002 @05:34PM (#2858286)
    "You guys (at Microsoft) still don't get it,' because it's sort of Java with reliability, productivity and security deleted"

    Er, no, Sun really don't get it. C# on top of .NET is a significantly more "productive" language than Java as it is based on a much higher level of abstraction. You can concentrate on immediately doing things your application (Web, Client, etc.) is supposed to DO than the plumbing to get to that stage. Visual Studio.NET is easily the most productive environment I have ever seen, but the article concentrated on C# so...

    Microsoft haven't forced people to use the highest abstraction, you can choose to do much lower level things ("unsafe code" for instance). I assume this is what Mr. Gosling is referring to with "reliability, ...security deleted". The .NET approach puts the onus on the developer (you know, the one with the brain) to decide what they want to do, and how they want to do it. In order words don't penalise all developers to script kiddie level, realise there are different problem spaces and different levels of developers and let them figure it out themselves.

    Yes I program in .NET, have done since Beta 1, and find it a joy to use. Stability even from the earliest builds simply was amazing (especially considering its an MS product) and brings a lot of the "fun" back to programming (doing stuff instead of writing or finding/using support libraries). But I do have a background in Java, having programmed in it for the past 4 years...put simply, I'll choose which language/environment to use depending upon the project.

    ...fire extinguisher ready and waiting...
    • >NET is a significantly more "productive" language than Java as it is based on a much higher level of abstraction. You can concentrate on immediately doing things your application (Web, Client, etc.) is supposed to DO than the plumbing to get to that stage

      >But I do have a background in Java, having programmed in it for the past 4 years

      So umm.. you programmed in Java for 4 years and never used an application server to do the "plumbing" for you?
      • JRun and a little "play" with JBoss, but only in the past 14months or so. JRun does help immensely but you still end up writing significant plumbing which .NET and C# (using Metadata and lots of syntactic sugar) do automatically for you. I'd say my classes in Java are 3-4x size of the ones in C#.

        Of course, argument against would be that you can pick your "application server" on Java platform but not the .NET platform.
        • A full application server environment also contains an EJB container, JMS, etc. EJB in particular is tremendously useful for applications that require persistence, and it also does a certain amount to help with session management. If you write centralised web applications, the whole thing helps tremendously in the same way you describe for .NET.
    • Can you give more detail, or a references (preferably a non-marketing-bullshit reference) on how .NET is more productive than Java ? I find Java - with the appropriate supporting tools - substantially more productive than most of the alternatives.

      As to the "unsafe" features in C#, I see what you are saying, but they still worry me. Aside from very deeply embedded stuff - and there's very little of that these days - there is no need for pointer arithmetic, or manual control over memory allocation.

      To say "if you don't like it, don't use it", is only one half of the story. The second part is, we live in an industry full over people with an over-confident view of their own abilities and an obsession with efficiency. Keeping dangerous features out of the language helps keep those people under control.
    • Yes, thank you! It's about time someone actually judged the language on its *merits*, and not who produced it!

      Every time I see a language advocacy debate, it amazes me how quickly it goes from "language X has this feature, while language Y does not", et. al., into "corporation X, who produces language X, is pure evil, so language X sucks" or whatever. It kinda reminds me of a local movie critic who uses his film "reviews" as a bully pulpit to whine and bitch about every aspect of life that he doesn't like. It really gets annoying to read through his drivel when really, all you want to know is how good the movie is. Same deal here.

      As far as the "unsafe" code that C# allows one to write, call me a cynic, but if this were allowed in Java (or any other non-M$ product for that matter), I wonder how many of the same people that are badmouthing it now would be calling it a "cool feature" that "allows great flexibility", yadda yadda yadda....

      Politics as usual, I guess.
    • Is there any task for which you would choose Java over C#?

      More to the point -- I'm a newbie when it comes to OO languages, and I'm wondering which I should study first, Java or C#?
  • by Linux_ho ( 205887 ) on Thursday January 17, 2002 @08:48PM (#2859499) Homepage
    I was kind of the guy responsible for the original Emacs, 23 years ago.
    I think his brain is starting to go. If I remember correctly, he wrote a version of it in C, using a bastardized LISP for extensions, in the early eighties. Stallman wrote the original in... umm... 1976?
  • How was Gossling "responsible for the original
    Emacs, 23 years ago"?

    I think I have been flaming the wrong hairy guy
    all this time ;-)
    :wq
  • Hmmmm....I originally submitted this story this morning, about 6 hours before this story was posted on Slashdot, and it was promptly rejected.....

    Anyway, if you talk to just about any serious Java developer, they will tell you the same thing I'm about to tell you now. Noone will buy M$'s assertion that C# will be cross-platform for the simple reason that it's Microsoft. Microsoft depends upon a Windows monopoly, and for that reason, it will do nothing to support other platforms. If they did, they would have made Linux versions of Office, Internet Explorer, Media Player, etc. Noone trusts them to make *ANY* product cross-platform. Their history clearly demonstrates this pattern.

    The reason why most developers use Java is because they KNOW they can compile it on one platform, and then run it on another. I know it's not perfectly platform-independent, but it comes pretty close. Switching from Java makes no sense if this cross-platform utility is compromised, or even made uncertain.

    Besides, Java has a proven track record and is *EXTREMELY* well documented. If I need info on any class, package or utility, it's just a few clicks away in the HTML javadocs. Also, I can document my all of my OWN code with only a single text command: javadoc. Thus everyone will be able to read my own documentation in the same format and with the same easy of use as the Sun Java documentation. Every product Microsoft has attempted to document, especially Visual Basic, has been very difficult to get pertinent information on.

    I can run, compile and deploy a Java application using nothing but the free JDK and J2EE from the Sun site, a simple text editor, a command prompt (whether Windows or Linux), a text-line compiler (like Jakarta Ant), and a free application server (like Tomcat). I don't even need a GUI, save for the browser to test my web application. I don't have to shell out $1,000 for Visual Studio to learn, use, program and deploy a Java application. The web application I'm developing for my company has thus far cost us $0 in development costs (aside from my salary and maintaining the hardware it will run on).

    I'm sorry, but I don't believe that Microsoft will make any of their prodocols and/or products truly open, documented or free. The openness, documentation and free cost of Java, as well as its cross-platform capabilities make Java and excellent development platform, and these three advantages, by their intrinsic nature, conflict with Microsoft's intrinsic nature and will never be successfully duplicated by that company.
  • Comment removed based on user account deletion
  • sun thank you for java I personally like it and use it where I can

    BUT
    the CLR is well designed + engineered
    for speed and interoperability

    Perl.NET VB.NET TCL.NET and even C++.NET will all work and thats what we have around today think interoperability or in Microsoft terms BACKWARDS COMPATIBILITY

    it matters

    and with a transport stream that is XML what matters is tools and those tools will be on windows

    java's nice but until I see a tool that can debug C and java
    forget about it MS wins the services of the "net"
    (there are alot more fields that java wins in like phones and TV which is nice for java and means that it does not go away any time soon)

    regards

    john jones

I THINK THEY SHOULD CONTINUE the policy of not giving a Nobel Prize for paneling. -- Jack Handley, The New Mexican, 1988.

Working...