Slashdot Mirror
Java Creator James Gosling on C# And More
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.
'You guys (at Microsoft) still don't get it,' because it's sort of Java with reliability, productivity and security deleted."
... this attitude worked for Windows 95, so why should MS be rattled by these remarks?
Quite simply
Once Microsoft have got the market share, they can work on the reliability and security.
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.
"You guys (at Microsoft) still don't get it,' because it's sort of Java with reliability, productivity and security deleted"
.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...
...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.
.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.
Er, no, Sun really don't get it. C# on top of
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,
Yes I program in
...fire extinguisher ready and waiting...
include $sig;
1;
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 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.
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 ...)
the technical distinctions between Java and C# are of little concern
s s/newsid_1767000/1767695.stm)
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/busine
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].
C# has already geared itself up for a dominant position in tomorrow's enterprise development environment
... its ECMA standardisation
d _1 635000/1635317.stm
d _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.
.NET won't remain an open standard for long.
This reads like Marketing hype worthy of the FUD-Master General himself.
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/newsi
http://news.bbc.co.uk/hi/english/business/newsi
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,
The only truth, in your entire post, Embrace and Extend.
Perhaps we need another Moderation option (-1 Astrotufer).
It's encapsulation mechanism is broken, all members are essentially public
i on /0,,sid7_gci212060,00.html
e .h tm#2
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/sDefinit
http://genamics.com/developer/csharp_comparativ
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.
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.
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.
This space left intentionally blank.
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.
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.
I'm going to assume your post is based on ignorance and is not a troll. Time will reveal the wisdom of this decision.
/ Ja va/Server-Side/Application_Servers/
/ Ja va/Development_Tools/
...
Firstly the primary assertion of my first post was that C(hash) and Java are the essentially the same thing. Your post despite the errors, actually illustrates more differences.
C# is a ECMA standard.
So What? ECMA is not 'open'; and ECMAScript is a standard, but hardly anybody uses it, most Web Developers use propriety non-standard implementions of JavaScript/JScript/Flash etc.
Java is a single supplier system.
Not true! This is a list of ~26 supplies of Java Application Servers. This is about 25 more than the number of alternative implementation of C#.
http://dmoz.org/Computers/Programming/Languages
This is a list of ~258 Suppliers of Java Development tools.
http://dmoz.org/Computers/Programming/Languages
I suspect this one was just a typo on your part, transposing C(hash) [sic] and Java.
No it was not a typo. Java IS platform agnostic, implementations are available on dozens of platforms from dozens of suppliers including all the biggest IT suppliers, IBM, HP, Netscape(IPlanet), Oracle, Fujitsu it's available open source, and last but not least Sun.
Java has primitive types
Java's primative should have been wrapped in an object, however wrapping anything in an Object is well within the capabilities of even the most junior programmer; and that deficiency is hardly a criticism in the league of a broken encapsulation mechanism. Encapsulation is Essential to OO, that all variables must be objects is not.
Your whining about encapsulation shows a profound ignorance of what you speak of.
Then best insult is to prove I am wrong not just assert it.
C#'s private fields and methods are fully protected, you're thinking of properties.
So you will be able to me the error message generated, when you try to access a private member of anObject with the following code:
localMember = anObject.privateMember ;
anObject.privateMember ++ ;
In the future, I suggest actually knowing what you're talking about before accusing people of FUDing.
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.
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++.
.NET (+ C# & CLR), dead on arrival with CIOs, my consulting customers and smart developers everywhere. Besides, Borland beat them out the gate with web services, which is a good implementation to boot (as always with Borland development tools). And Java's slant on web services is ramping fast with the help of IBM and other players.
Steve Magruder, Metro Foodist
Borland Delphi. I'll stick with the best Windows *and* Linux tool on the market. My small business and non-profit customers don't give a whit about what tools I use in my work.
Steve Magruder, Metro Foodist
Ok, I accept that i was mistaken over 'broken encapsulation'.
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