This was just a play on the title of another post... But its the honest truth. M$ needs to target the #2 desktop if they want to defeat Java.
No because than developers could easily write software for the Mac. Why would Microsoft want to do this when they can keep .NET on Windows and have millions of developers continue to code for the Windows platform?
When you control Microsoft's share of the market, you can ignore the (distant) #2 platform completely if you'd rather.
The whole reason MS destroyed Netscape, and has tried to destroy Java, is precisely because they offered cross-platform application deployment that mooted the operating system. MS doesn't want Windows to be mooted. So .NET is designed to be a "better Java," and it runs on 90% of the machines out there, which is close enough. Most importantly, it affirms the importance of Windows, and gives Microsoft absolute control. That is the whole point of the exercise.
The point certainly isn't pushing the envelope of language development... :P
The *only* nice new thing I've seen about C# is the delegate keyword. Nice approach to making an implicit ubiquitous construct explicit. Improves comprehension and readability.
Other than that though, .NET is just warmed over tech from other companies and research groups. *shrug*
The point certainly isn't pushing the envelope of language development... :P
The *only* nice new thing I've seen about C# is the delegate keyword. Nice approach to making an implicit ubiquitous construct explicit. Improves comprehension and readability.
Other than that though, .NET is just warmed over tech from other companies and research groups. *shrug*
You mean you're not totally floored by VB.NET?
C# is actually really nice. We're converting all of our old VB apps to C# at work and it is a big improvement. I haven't worked with C++ or C since College so I can't really compare C# to those. But it stacks up pretty well against Java too.
Basically if you're developing apps for Windows, there's no reason not to swith to .NET/C# it is a much better toolset to work with.
Microsoft can kill this at anytime. They have patents on much of the .NET technology and all they have to do is call their lawyers. OR change a great deal of the .NET framework to break MONO from working. \
The point certainly isn't pushing the envelope of language development... :P
The *only* nice new thing I've seen about C# is the delegate keyword. Nice approach to making an implicit ubiquitous construct explicit. Improves comprehension and readability.
Other than that though, .NET is just warmed over tech from other companies and research groups. *shrug*
The other nice feature of C# is that you cannot accidentally override a method. To make a method overridable (is that a word?) you have to declare it virtual. This solves lots of issues.
Its hard to argue with .net for GUI development. I just ordered a book on SWT (for Java), so hopefully it will be decent. Supposedly they improved Swing in 1.4.2 as well.
Edit: before I get flamed, I agree whole-heartedly that the Apple GUI is better. But I really cant see myself switching to C++ for general purpose business application development. Theres just too many issues with it.
The other nice feature of C# is that you cannot accidentally override a method. To make a method overridable (is that a word?) you have to declare it virtual. This solves lots of issues.
*twitch*
*twitch*
You realize, of course, that that's exactly *BACKWARDS* of every accepted model of OO on the planet, right?
(Yeah, so is C++.)
Everything is overridable at any time in 'pure' OO... that's what gives it its power and flexibility. Having a library developer say "Oh, oops, sorry, we forgot about that one, you'll have to wait until the next release in six months" because you don't have access to the source code and can't pose a class in its place to work around their screw up is *annoying*. Not a problem in dynamic languages. :P
Just as a curious aside... what issues do you see this solving??
The other nice feature of C# is that you cannot accidentally override a method.
How do you accidentally override a method, and why isn't the solution to change or delete the offending method?
Quote:
To make a method overridable (is that a word?) you have to declare it virtual. This solves lots of issues.
In other words, you "override" it by punting the definition to subclasses. What does this solve exactly? It sounds like Microsoft has given up on polymorphism, which is one of the bedrock features of object-oriented design.
So C# is an OO language for people who learned block-structured code (or BASIC!) and are confused by all this "object" stuff. Right.
It infuriates me that so many people think that you can design a language by putting lipstick on C++.
Quote:
Its hard to argue with .net for GUI development. I just ordered a book on SWT (for Java), so hopefully it will be decent. Supposedly they improved Swing in 1.4.2 as well.
GUI development has as much to do with the available toolset as anything else. Apple has Interface Builder; Borland did a good job of wrangling good UI tools out of MFC, etc.
Quote:
Edit: before I get flamed, I agree whole-heartedly that the Apple GUI is better. But I really cant see myself switching to C++ for general purpose business application development. Theres just too many issues with it.
I won't disagree, but what are the issues with an OO language that cripples polymorphism?!
Microsoft can kill this at anytime. They have patents on much of the .NET technology and all they have to do is call their lawyers. OR change a great deal of the .NET framework to break MONO from working. \
From what I've heard, they don't own a few of the major patents for .net
Sounds like MS is doing to application developers with C# what they did to web designers wit IE. Allow bad coding practices and everyone will praise them.
You make a good point... I don't see how that would solve any problems at all. If you don't want it to override the method, why the hell are you declaring it again!? In fact... to me it seems like that would cause more problems than it would solve.
I'll have to think of a good example.... If you compile this code, you will quickly find that pure OO is not all its cracked up to be. Without knowing it, a developer can override important functionality that the base class needs to properly function. In C#, the compiler will not allow you to override the method without calling it virtual. It will compile, but the base constructor will call the appropriate method, rather than inadvertantly inheriting from the new class.
Code:
package test;
public class MyBase
{
public MyBase()
{
printMessage();
}
public void printMessage()
{
System.out.println("Base Message");
//critical constructor work being done here
}
}
Now lets say you extend this class as follows:
//--------------------------------------------
package test2;
import test.MyBase;
public class MyExtended extends MyBase
{
public MyExtended()
{
super();
}
public void printMessage()
{
System.out.println("Exteneded Method");
//critical base class constructor work being inadvertantly
//overwritten here with no compiler warnings...
}
public static void main(String args[])
{
MyExtended mi=new MyExtended();
}
}
[edit by Amorph: The code tag is your friend ]
[edit by Jukebox Hero: Tx Amorph. Also, even though it has nothing to do with the point I'm making, I moved MyExtended into another package just so nobody can come back and say, "Why would anybody do that?"]
The essential tasks you need to perform when creating a Java Client application are listed below:
1) Create a model using EOModeler.
2) Create a project using Project Builder.
3) Write source code for enterprise-object classes (if your enterprise objects require custom business logic).
4) Create your application?s user interface with Interface Builder (Java Client approach).
5) Customize your application?s user interface (Direct to Java Client approach).
6) Write source code for any application-level logic.
//----------------
back to my take:
The problem with this approach is that alot of business application developers have beened burned by C++ application frameworks. C++ adds an entire class of bugs that don't exist in languages such as Java (or as MS calls it; managed languages). For example, I spent about 600 hours on a project that got eventually got canceled because of all the bugs in Borlands Visual Component Library (Sorry for the negative press, Borland. Its been a few years and maybe you've fixed your problems). Sure, tools have gotten better at finding the types of memory bugs that create these hard-to-find, company-destroying bugs. But these same bugs simply do not exist in Java.
So I rephrase my claim to be more specific; I would highly value a framework that was developed on a managed language.
May I ask why the critical constructor work isn't being done in the constructor, but in a public method?
This example seems a bit too contrived to be relevant. First of all, since the whole point of polymorphism is to override base class behavior, I don't understand why the compiler should warn you. Second, there's a one-line fix to that issue, if you do want the base class' PrintMessage() to be called: Call it.
This "fix" is for people who don't understand basic OO principles. If I want a sensible default behavior, but different or additional behavior in a few cases, what do I do? Either I paste the default behavior code into every instance of the method, or I stuff it in a helper method and invoke it with a call - but if I'm going to invoke a method, why not super.PrintMessage()?
May I ask why the critical constructor work isn't being done in the constructor, but in a public method?
This example seems a bit too contrived to be relevant. First of all, since the whole point of polymorphism is to override base class behavior, I don't understand why the compiler should warn you. Second, there's a one-line fix to that issue, if you do want the base class' PrintMessage() to be called: Call it.
This "fix" is for people who don't understand basic OO principles. If I want a sensible default behavior, but different or additional behavior in a few cases, what do I do? Either I paste the default behavior code into every instance of the method, or I stuff it in a helper method and invoke it with a call - but if I'm going to invoke a method, why not super.PrintMessage()?
Of course this example is contrived... but now imagine the reverse happening. A developer purchases "Super Duper Framework V1.0" and builds an application on it. Later, "Super Duper Framework V2.0" becomes available. Unfortunately, the application built on SDF1.0 no longer runs on SDF2.0 and nobody knows why. Sorry about your luck. C# fixes a major problem that I have seen happen numerous times in corporate environment.
Thanks for the tip, but no thanks for the snotty, greater than thou attitude (Way to bring Windows developers into the fold!!).
Your point about doing interface design in C++ was bizarre, though. You can, if you really want to, but it's not like Apple doesn't offer options with slick tools backed up by rich and mature frameworks.
Quote:
I browsed around and found the following link, which describes Apples recommended approach:
The essential tasks you need to perform when creating a Java Client application are listed below:
1) Create a model using EOModeler.
2) Create a project using Project Builder.
3) Write source code for enterprise-object classes (if your enterprise objects require custom business logic).
4) Create your application?s user interface with Interface Builder (Java Client approach).
5) Customize your application?s user interface (Direct to Java Client approach).
6) Write source code for any application-level logic.
The problem with this approach is that alot of business application developers have beened burned by C++ application frameworks.
Where are the C++ application frameworks here? You're looking at WebObjects, which is a client-server application design and deployment suite built 100% in Java. Its frameworks have been stable and mature for years now (dating back to when it was implemented 100% in Objective-C - it's never had anything to do with C++).
The only C++ application frameworks for the Mac that I'm aware of are third party solutions like MetroWerks' PowerPlant.
Quote:
C++ adds an entire class of bugs that don't exist in languages such as Java (or as MS calls it; managed languages).
Huh? I remember Java back in the 1.x days, and it was so buggy that our class once fixed a bug by changing the name of a local variable. In other words, there was a bug in the symbol table implementation! I've never even heard of that in a C++ compiler.
If anything, managed languages (or, if you prefer, 4GLs) are more vulnerable to quality of implementation issues. Another such thing cropped up with a "managed language" we were using at work, called Forte. They'd implemented arrays as hashes, and in one update they borked the hashing algorithm so that every eighth member of an array vanished into the ether. This, in a $50,000 toolset. At least in a 3GL like C++ if some library has a bug I can drop down and roll my own replacement, and expect it to run well. (In Objective-C, I can pose the replacement as the buggy original, and write all my code as if I were using the original framework! Then when the vendor fixes the bug, I can yank out my workaround without changing a single line of code.)
I have to wonder why you're so fixated on C++ on Apple's OS? It's there. It's available if and when you need it. But none of Apple's frameworks use C++, or even target it as a primary development language; nearly all of Apple's frameworks are mature and battle-tested at this point (there are, and will always be, bugs, but the same is true of Java and .NET). You can use Objective-C, Python, Ruby, Java... and C++ when and if it makes sense to. Most people who use C++ on the Mac use the pure language, without any framework dependencies, for cross-platform code, and at that point you're very unlikely to run into bugs in the language implementation (unfortunate caveat: Microsoft's C++ compiler).
Quote:
For example, I spent about 600 hours on a project that got eventually got canceled because of all the bugs in Borlands Visual Component Library (Sorry for the negative press, Borland. Its been a few years and maybe you've fixed your problems). Sure, tools have gotten better at finding the types of memory bugs that create these hard-to-find, company-destroying bugs. But these same bugs simply do not exist in Java.
I'll be the last person on Earth to defend Borland, as their C++ Builder has given us a world of pain over the last year and a half. But that has nothing to do with C++ (Borland's actual language implementation is quite good, it's just their IDE and frameworks and makefiles that suck...) and everything to do with the crap you're linking it to.
Quote:
So I rephrase my claim to be more specific; I would highly value a framework that was developed on a managed language.
I'm content to know that the frameworks actually work, and that if they don't, the language will allow me to efficiently route around them - because I will have to do that at some point on any non-trivial project. And if a particular library or framework sucks (*cough*AWT*cough*) I'd like to have the option of not using it.
Comments
Originally posted by Jukebox Hero
This was just a play on the title of another post... But its the honest truth. M$ needs to target the #2 desktop if they want to defeat Java.
No because than developers could easily write software for the Mac. Why would Microsoft want to do this when they can keep .NET on Windows and have millions of developers continue to code for the Windows platform?
The whole reason MS destroyed Netscape, and has tried to destroy Java, is precisely because they offered cross-platform application deployment that mooted the operating system. MS doesn't want Windows to be mooted. So .NET is designed to be a "better Java," and it runs on 90% of the machines out there, which is close enough. Most importantly, it affirms the importance of Windows, and gives Microsoft absolute control. That is the whole point of the exercise.
The *only* nice new thing I've seen about C# is the delegate keyword. Nice approach to making an implicit ubiquitous construct explicit. Improves comprehension and readability.
Other than that though, .NET is just warmed over tech from other companies and research groups. *shrug*
Originally posted by Kickaha
The point certainly isn't pushing the envelope of language development... :P
The *only* nice new thing I've seen about C# is the delegate keyword. Nice approach to making an implicit ubiquitous construct explicit. Improves comprehension and readability.
Other than that though, .NET is just warmed over tech from other companies and research groups. *shrug*
You mean you're not totally floored by VB.NET?
C# is actually really nice. We're converting all of our old VB apps to C# at work and it is a big improvement. I haven't worked with C++ or C since College so I can't really compare C# to those. But it stacks up pretty well against Java too.
Basically if you're developing apps for Windows, there's no reason not to swith to .NET/C# it is a much better toolset to work with.
http://www.theregister.co.uk/content/4/32735.html
Originally posted by cowerd
Already done--well almost.
http://www.theregister.co.uk/content/4/32735.html
Microsoft can kill this at anytime. They have patents on much of the .NET technology and all they have to do is call their lawyers. OR change a great deal of the .NET framework to break MONO from working.
Originally posted by Kickaha
The point certainly isn't pushing the envelope of language development... :P
The *only* nice new thing I've seen about C# is the delegate keyword. Nice approach to making an implicit ubiquitous construct explicit. Improves comprehension and readability.
Other than that though, .NET is just warmed over tech from other companies and research groups. *shrug*
The other nice feature of C# is that you cannot accidentally override a method. To make a method overridable (is that a word?) you have to declare it virtual. This solves lots of issues.
Its hard to argue with .net for GUI development. I just ordered a book on SWT (for Java), so hopefully it will be decent. Supposedly they improved Swing in 1.4.2 as well.
Edit: before I get flamed, I agree whole-heartedly that the Apple GUI is better. But I really cant see myself switching to C++ for general purpose business application development. Theres just too many issues with it.
Originally posted by kim kap sol
I'm not sure I want a MS framework in OS X. It might bring more inconsistencies between apps than there is now with carbon and cocoa.
It most certainly would. MS will always want to do it their way. So how does one put together a GUI on OSX without resorting to C++?
Originally posted by Jukebox Hero
So how does one put together a GUI on OSX without resorting to C++?
Perhaps I missed a joke here, but just in case:
Originally posted by Jukebox Hero
The other nice feature of C# is that you cannot accidentally override a method. To make a method overridable (is that a word?) you have to declare it virtual. This solves lots of issues.
*twitch*
*twitch*
You realize, of course, that that's exactly *BACKWARDS* of every accepted model of OO on the planet, right?
(Yeah, so is C++.)
Everything is overridable at any time in 'pure' OO... that's what gives it its power and flexibility. Having a library developer say "Oh, oops, sorry, we forgot about that one, you'll have to wait until the next release in six months" because you don't have access to the source code and can't pose a class in its place to work around their screw up is *annoying*. Not a problem in dynamic languages. :P
Just as a curious aside... what issues do you see this solving??
Originally posted by Jukebox Hero
The other nice feature of C# is that you cannot accidentally override a method.
How do you accidentally override a method, and why isn't the solution to change or delete the offending method?
To make a method overridable (is that a word?) you have to declare it virtual. This solves lots of issues.
In other words, you "override" it by punting the definition to subclasses. What does this solve exactly? It sounds like Microsoft has given up on polymorphism, which is one of the bedrock features of object-oriented design.
So C# is an OO language for people who learned block-structured code (or BASIC!) and are confused by all this "object" stuff. Right.
It infuriates me that so many people think that you can design a language by putting lipstick on C++.
Its hard to argue with .net for GUI development. I just ordered a book on SWT (for Java), so hopefully it will be decent. Supposedly they improved Swing in 1.4.2 as well.
GUI development has as much to do with the available toolset as anything else. Apple has Interface Builder; Borland did a good job of wrangling good UI tools out of MFC, etc.
Edit: before I get flamed, I agree whole-heartedly that the Apple GUI is better. But I really cant see myself switching to C++ for general purpose business application development. Theres just too many issues with it.
I won't disagree, but what are the issues with an OO language that cripples polymorphism?!
Originally posted by Willoughby
Microsoft can kill this at anytime. They have patents on much of the .NET technology and all they have to do is call their lawyers. OR change a great deal of the .NET framework to break MONO from working.
From what I've heard, they don't own a few of the major patents for .net
Originally posted by Kickaha
*twitch*
*twitch*
Sounds like MS is doing to application developers with C# what they did to web designers wit IE. Allow bad coding practices and everyone will praise them.
You make a good point... I don't see how that would solve any problems at all. If you don't want it to override the method, why the hell are you declaring it again!? In fact... to me it seems like that would cause more problems than it would solve.
package test;
public class MyBase
{
public MyBase()
{
printMessage();
}
public void printMessage()
{
System.out.println("Base Message");
//critical constructor work being done here
}
}
Now lets say you extend this class as follows:
//--------------------------------------------
package test2;
import test.MyBase;
public class MyExtended extends MyBase
{
public MyExtended()
{
super();
}
public void printMessage()
{
System.out.println("Exteneded Method");
//critical base class constructor work being inadvertantly
//overwritten here with no compiler warnings...
}
public static void main(String args[])
{
MyExtended mi=new MyExtended();
}
}
[edit by Amorph: The code tag is your friend
[edit by Jukebox Hero: Tx Amorph. Also, even though it has nothing to do with the point I'm making, I moved MyExtended into another package just so nobody can come back and say, "Why would anybody do that?"]
Originally posted by Brad
Perhaps I missed a joke here, but just in case:
Thanks for the tip, but no thanks for the snotty, greater than thou attitude (Way to bring Windows developers into the fold!!).
I browsed around and found the following link, which describes Apples recommended approach:
http://developer.apple.com/documenta...section_7.html
Heres the exerpt:
Developing a Java Client Application
The essential tasks you need to perform when creating a Java Client application are listed below:
1) Create a model using EOModeler.
2) Create a project using Project Builder.
3) Write source code for enterprise-object classes (if your enterprise objects require custom business logic).
4) Create your application?s user interface with Interface Builder (Java Client approach).
5) Customize your application?s user interface (Direct to Java Client approach).
6) Write source code for any application-level logic.
//----------------
back to my take:
The problem with this approach is that alot of business application developers have beened burned by C++ application frameworks. C++ adds an entire class of bugs that don't exist in languages such as Java (or as MS calls it; managed languages). For example, I spent about 600 hours on a project that got eventually got canceled because of all the bugs in Borlands Visual Component Library (Sorry for the negative press, Borland. Its been a few years and maybe you've fixed your problems). Sure, tools have gotten better at finding the types of memory bugs that create these hard-to-find, company-destroying bugs. But these same bugs simply do not exist in Java.
So I rephrase my claim to be more specific; I would highly value a framework that was developed on a managed language.
This example seems a bit too contrived to be relevant. First of all, since the whole point of polymorphism is to override base class behavior, I don't understand why the compiler should warn you. Second, there's a one-line fix to that issue, if you do want the base class' PrintMessage() to be called: Call it.
This "fix" is for people who don't understand basic OO principles. If I want a sensible default behavior, but different or additional behavior in a few cases, what do I do? Either I paste the default behavior code into every instance of the method, or I stuff it in a helper method and invoke it with a call - but if I'm going to invoke a method, why not super.PrintMessage()?
Originally posted by Amorph
May I ask why the critical constructor work isn't being done in the constructor, but in a public method?
This example seems a bit too contrived to be relevant. First of all, since the whole point of polymorphism is to override base class behavior, I don't understand why the compiler should warn you. Second, there's a one-line fix to that issue, if you do want the base class' PrintMessage() to be called: Call it.
This "fix" is for people who don't understand basic OO principles. If I want a sensible default behavior, but different or additional behavior in a few cases, what do I do? Either I paste the default behavior code into every instance of the method, or I stuff it in a helper method and invoke it with a call - but if I'm going to invoke a method, why not super.PrintMessage()?
Of course this example is contrived... but now imagine the reverse happening. A developer purchases "Super Duper Framework V1.0" and builds an application on it. Later, "Super Duper Framework V2.0" becomes available. Unfortunately, the application built on SDF1.0 no longer runs on SDF2.0 and nobody knows why. Sorry about your luck. C# fixes a major problem that I have seen happen numerous times in corporate environment.
Originally posted by Jukebox Hero
Thanks for the tip, but no thanks for the snotty, greater than thou attitude (Way to bring Windows developers into the fold!!).
Your point about doing interface design in C++ was bizarre, though. You can, if you really want to, but it's not like Apple doesn't offer options with slick tools backed up by rich and mature frameworks.
I browsed around and found the following link, which describes Apples recommended approach:
http://developer.apple.com/documenta...section_7.html
Heres the exerpt:
Developing a Java Client Application
The essential tasks you need to perform when creating a Java Client application are listed below:
1) Create a model using EOModeler.
2) Create a project using Project Builder.
3) Write source code for enterprise-object classes (if your enterprise objects require custom business logic).
4) Create your application?s user interface with Interface Builder (Java Client approach).
5) Customize your application?s user interface (Direct to Java Client approach).
6) Write source code for any application-level logic.
The problem with this approach is that alot of business application developers have beened burned by C++ application frameworks.
Where are the C++ application frameworks here? You're looking at WebObjects, which is a client-server application design and deployment suite built 100% in Java. Its frameworks have been stable and mature for years now (dating back to when it was implemented 100% in Objective-C - it's never had anything to do with C++).
The only C++ application frameworks for the Mac that I'm aware of are third party solutions like MetroWerks' PowerPlant.
C++ adds an entire class of bugs that don't exist in languages such as Java (or as MS calls it; managed languages).
Huh? I remember Java back in the 1.x days, and it was so buggy that our class once fixed a bug by changing the name of a local variable. In other words, there was a bug in the symbol table implementation! I've never even heard of that in a C++ compiler.
If anything, managed languages (or, if you prefer, 4GLs) are more vulnerable to quality of implementation issues. Another such thing cropped up with a "managed language" we were using at work, called Forte. They'd implemented arrays as hashes, and in one update they borked the hashing algorithm so that every eighth member of an array vanished into the ether. This, in a $50,000 toolset. At least in a 3GL like C++ if some library has a bug I can drop down and roll my own replacement, and expect it to run well. (In Objective-C, I can pose the replacement as the buggy original, and write all my code as if I were using the original framework! Then when the vendor fixes the bug, I can yank out my workaround without changing a single line of code.)
I have to wonder why you're so fixated on C++ on Apple's OS? It's there. It's available if and when you need it. But none of Apple's frameworks use C++, or even target it as a primary development language; nearly all of Apple's frameworks are mature and battle-tested at this point (there are, and will always be, bugs, but the same is true of Java and .NET). You can use Objective-C, Python, Ruby, Java... and C++ when and if it makes sense to. Most people who use C++ on the Mac use the pure language, without any framework dependencies, for cross-platform code, and at that point you're very unlikely to run into bugs in the language implementation (unfortunate caveat: Microsoft's C++ compiler).
For example, I spent about 600 hours on a project that got eventually got canceled because of all the bugs in Borlands Visual Component Library (Sorry for the negative press, Borland. Its been a few years and maybe you've fixed your problems). Sure, tools have gotten better at finding the types of memory bugs that create these hard-to-find, company-destroying bugs. But these same bugs simply do not exist in Java.
I'll be the last person on Earth to defend Borland, as their C++ Builder has given us a world of pain over the last year and a half. But that has nothing to do with C++ (Borland's actual language implementation is quite good, it's just their IDE and frameworks and makefiles that suck...) and everything to do with the crap you're linking it to.
So I rephrase my claim to be more specific; I would highly value a framework that was developed on a managed language.
I'm content to know that the frameworks actually work, and that if they don't, the language will allow me to efficiently route around them - because I will have to do that at some point on any non-trivial project. And if a particular library or framework sucks (*cough*AWT*cough*) I'd like to have the option of not using it.