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.
SUN needs to loosen control of Java. Fast. (Score:1, Troll)
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.
Re:SUN needs to loosen control of Java. Fast. (Score:1)
Re:SUN needs to loosen control of Java. Fast. (Score:4, Informative)
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.
Re:SUN needs to loosen control of Java. Fast. (Score:4, Informative)
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 ...)
Should be (-1 Astrotufer) (Score:4, Interesting)
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).
Flamebait? (Score:2, Insightful)
Quite simply
Once Microsoft have got the market share, they can work on the reliability and security.
my $0.02 (Score:3, Insightful)
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.
fundamental distinction (Score:2)
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].
Re:fundamental distinction (Score:1)
It's encapsulation mechanism is broken, all members are essentially public
That's news to me. Can you provide details?
-- Brian
C(Hash) Encapsulation mechanism is broken (Score:2, Informative)
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
Re:C(Hash) Encapsulation mechanism is broken (Score:1)
Thanks anyway.
-- Brian
You're wrong (Score:2)
Missing Point. (Score:2)
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.
No (Score:2)
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.
Re: (Score:2)
Informative? (Score:1)
-- Brian
Fact based argument. (Score:2)
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.
You've misunderstood (Score:2)
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++.
Re:Fact based argument. (Score:2, Informative)
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?
When compiled, this program produces the following error on line 12:
Any questions?
-- Brian
More fundamental distinctions (Score:2)
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.
Re:More fundamental distinctions (Score:2)
public class AClass
{
private int privateMember;
}
public class AnotherClass
{
public void BreakAClass()
{
AClass anObject = new AClass();
int localMember = anObject.privateMember;
anObject.privateMember ++ ;
}
}
Here's what the compiler told me:
Build started: Project: testproj, Configuration: Debug
Preparing resources...
Updating references...
Performing main compilation...
c:\testproj\class1.cs(18,22): error CS0122: 'testproj.AClass.privateMember' is inaccessible due to its protection level
c:\testproj\class1.cs(19,4): error CS0122: 'testproj.AClass.privateMember' is inaccessible due to its protection level
Build complete -- 2 errors, 0 warnings
Building satellite assemblies...
Satellite assemblies could not be built because the main project output is missing.
Done
Build: 0 succeeded, 1 failed, 0 skipped
Re:More fundamental distinctions (Score:2)
Accessors are basically methods in disguise. These are functionally identical:
public int GetFoo()
{
return privateFoo;
}
public int Foo
{
get { return privateFoo; }
}
also, these are functionally identical:
public void SetFoo(int foo)
{
privateFoo = foo;
}
public void Foo
{
set { privateFoo = value; }
}
combine them and you get:
public void Foo
{
get { return privateFoo;}
set { privateFoo = value; }
}
Now, the advantage of accessors, of course, is that you get to do this in your calling code:
anObject.Foo = 7;
instead of:
anObject.SetFoo(7);
Now, something a little more nontrivial. What if you want to do something when Foo is set? Like this:
public int Foo
{
set
{
privateFoo = value;
onFooChanged(this, new EventArgs());
}
}
Or maybe the accessor isn't just mapping to a private member:
Public DateTime CurrentTime
{
// if you don't implement a setter or getter, the accessor becomes read or write only
get
{
DateTime dt = new DateTime();
dt = SomeWackyMethodForDeterminingDateTime();
return dt;
}
}
So, that is what an Accessor is. Another cool feature is indexers, where you can use array notation for accessing elements in your own collection classes.
Disclaimer: I didn't compile this code. It's basic enough that I shouldn't have screwed anything up, but don't cut-and-paste it into space shuttle software or something.
OK, Well done. (Score:2)
Ok, I accept that i was mistaken over 'broken encapsulation'.
Er, No... (Score:5, Insightful)
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...
Re:Er, No... (Score:1)
>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?
Re:Er, No... (Score:1)
Of course, argument against would be that you can pick your "application server" on Java platform but not the
JRun is only a servlet engine (Score:2)
Curious (Score:2)
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.
Re:Er, No... (Score:1)
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.
Re:Er, No... (Score:1)
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#?
So - Gosling invented Emacs huh? (Score:1)
He wrote the original EMACS, huh? Whatta guy! (Score:3, Insightful)
Re:He wrote the original EMACS, huh? Whatta guy! (Score:4, Informative)
http://www.free-soft.org/gpl_history/ [free-soft.org]
Re:He wrote the original EMACS, huh? Whatta guy! (Score:2)
From the UniPress site (ca. 1995):
UniPress Emacs is priced from $395 per workstation
C/C++macs and FortranEmacs are priced at $695 per workstation
AdaEmacs is priced at $995 per workstation
Source code is available for an additional $600
Site licenses, special university pricing and discounts are available
;-)
Just wondering (Score:1)
Emacs, 23 years ago"?
I think I have been flaming the wrong hairy guy
all this time
:wq
C# and .NET will NEVER be cross-platform (Score:2, Interesting)
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.
Re: (Score:2)
you dont get it (its about speed + XML) (Score:2)
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