I love my Microsoft Natural 4000 keyboard except for the truly worthless zoom toggle right in the middle. If they were to replace that with a pointing stick (or even trackball) I would be in heaven. (The back/forward buttons could be left/right click instead.)
Microsoft tools (+ReSharper) are now as nice as tools for Java, ASP.NET is as good as any Java web framework, and WPF totally kills SWING on the client.
I don't do much GUI programming in either, so I'll concede the third point, but I've used both Eclipse and Visual Studio for years, and trialed ReSharper, and Eclipse is still far better. ASP.NET is nice, and easier to get started with, but still not as good as putting together some of the best Java tools, mainly Spring Web. WAR deployments are better than the (non-existent).NET model, and the wealth of free libraries for Java (Jakarta, Codehaus, etc) still beats what's available for.NET.
I think everyone is missing my point. Clearly stupid people can write whatever they want. Obviously unit tests help in this regard, but still don't prevent it. My original point is that, contrary to what Bruce said, duck typing does not help maintainability. You and several others keep harping on this point of moronic implementation, which has nothing to do with my original point. In no way am I saying that just because Java has interfaces can you assume that implementation will be correct or you can change things and it will still work. That's just so idiotic I didn't even think anyone would take my comments that way. Strong, static typing makes it easier to figure out how some (not all) changes will affect other code in a way that Ruby's dynamic typing does not allow. That includes unit test code. This helps a person maintain and change code more easily, especially if the person has not worked on the code before.
I see the point of the incremental programming, which I think can be good short term, but there's problems with it. If you never get around to changing all the other places, then you've left timebombs in your code that could fail, depending on the nature of the change. Also, you say that often a base class would have a default implementation or something, but one of the arguments in your original post was that you aren't forced into extending a specific class. I think those ideas are a bit at odds.
As far as maintenance is concerned, if you are changing Enumerable, then you probably have a good reason, and there may be lots of code using it assuming certain things, and if you want to change it you may need to look at all those things to evaluate those impacts as well as your reasons for making the change to start with. You may decide that change isn't worth it, or maybe you really have a separate interface to create, since maybe it really is separate from Enumerable, or maybe you need a sub-interface of Enumerable, because some but not all things have this new feature. These are the sort of things that, while perhaps Ruby makes it easier, it is not necessarily a good idea, from a maintenance perspective, for these things to be easy.
I'm not trying to knock Ruby, and I really like some of the other features Ruby has to offer. And everyone's brain works differently. But this duck-typing argument shows up so much it's a personal beef of mine. (It has merit but not as much as I see it getting everywhere, I think.)
See my reply to Tamerlin. You're both barking up the wrong tree. Clearly there is no magic language that lets you ensure code does exactly what it says it will. The contract is that you will have certain methods with certain parameter and return types - interface contracts, not design-by-contract or something even more encompassing, which you seem to be describing. Reading any more into it by saying the contract also states that you will have correct implementation is silly. Any language can have bugs, idiot programmers that don't know what they are doing, or malicious hackers. Nothing will prevent that, which is so obvious I'm somewhat surprised you both took my statement the way you did.
Ruby: code takes an object you expect to have a method name quack. Call the code with an object with no quack method, runtime failure.
Java: code takes a Duck. Compiler won't let you call it without that object having a quack method.
Which gets noticed first? Which way would you rather have when you are maintaining the code 6 months from now and have forgotten everything? Maintenance is the topic of the thread.
Yeah, so, you can do that in Ruby, too. In both cases you don't have a duck. The comment is in regards to maintainability. Neither language prevents you from coding like a moron.
However, down the road, let's say you want to change something related to "quack" or being-a-duck. How do you find references in Ruby? Search all text files for a string? With static typing (Java), the compiler knows if changing something affects other code or what code is referenced where. Say you want ducks to be able to "shitOnGround". With Ruby you have to go find all the classes that think they are ducks to make sure they can shitOnGround now. If you add shitOnGround to the duck interface, the compiler will tell you about all the things that no longer properly implement Duck, insofar as method signatures are concerned. Sure, neither language ensures the method implementation isn't bogus, but if someone could find the solution to that then we wouldn't have jobs. But there's a difference between assuming things passed to a method have both quack and shitOnGround methods, and getting a runtime error if they don't, versus knowing at compile-time whether or not that code will run. Which do you think will be noticed more often and earlier?
I don't really view interfaces as design-by-contract. I think your comment about implementing a method correctly or not is besides the point, as implementing something incorrectly can be done in any language.
As it relates to maintainability, the topic of this thread, I argue that Java and interfaces are superior. What if you wanted to add a method to your contract of Enumerable? How, in Ruby, do you go and find every object that used to think it was Enumerable, but now isn't? If you say that a static checking compiler is in the works, then it seems that duck typing really isn't as advantageous as previously asserted. Ruby may be more maintainable if you originally wrote the code, but if you are taking over maintenance of someone else's code, then I think static typing really helps. I'm willing to put in a little more work up front so I can let Eclipse do a whole lot of work for me later.
Java interfaces allow you to declare that something is a Duck, so it must be a duck. However, with Java, I can ensure that anything I think I want to call a duck does indeed fulfill the contract of being a duck. What in Ruby forces you to properly export the collection of methods in Enumerable when you defined is_enumerable to return true? Nothing?
In Ruby, you can write code that assumes a parameter has a method called foo. In the future if I make a new object, I can add a foo method to it and pass it into that code. In Java, all it takes is the oh-so-hard task of creating an interface called, say, CanFoo, that declares a foo method, and typing my parameter to that. For anything I want to pass into that code, I just implement method foo, which I have to do anyway, and add CanFoo to my list of implemented interfaces. Classes don't have to inherit from any particular class, and they can implement as many interfaces as they want. So that was no more work. However, now the compiler helps me to ensure that I properly fulfill the contract of CanFoo. Plus if I want to do anything useful like find things that think they CanFoo, or rename foo to something else, the compiler will know where all of these references are and help me.
I'm not anti-Ruby, but I just plain don't understand arguments like this for the language.
Also, "say it only once" may be somewhat forced by the framework, which is a good principle of a framework, but that transcends languages, so I don't buy that, either.
I'm not arguing that Rails isn't maintainable, just that your reasoning for why it is aren't exclusive to Rails or Ruby.
You are missing the point. Java JIT actually compiles the bytecode to native instructions. Also, since it does this after the code is running, it can optimize the compilation based on usage history and other runtime patterns, something that is not possible at compile time with C. With server apps, which handle a lot of repetive requests, this is very beneficial.
If you are saying C apps are faster because the OS is written is C also, then I don't know if that's a factor, either. Most of the standard Java libraries are written in Java, but the jvm.dll I believe is written in C.
Maybe if you listened to artists with talent then you would find CDs where more than one or two tracks are worthwhile. Nearly everything I like flows well as a whole album and is good throughout - I can't stand radio-like discontinuity of sound.
Slashdot Mirror
Can someone finally put the setting to disallow third-party cookies back?
Don't you mean "loosing"?
I love my Microsoft Natural 4000 keyboard except for the truly worthless zoom toggle right in the middle. If they were to replace that with a pointing stick (or even trackball) I would be in heaven. (The back/forward buttons could be left/right click instead.)
In general I agree, but that's what RTC wake-on-clock is for (combined with idle shutdown or S3 sleep).
I don't do much GUI programming in either, so I'll concede the third point, but I've used both Eclipse and Visual Studio for years, and trialed ReSharper, and Eclipse is still far better. ASP.NET is nice, and easier to get started with, but still not as good as putting together some of the best Java tools, mainly Spring Web. WAR deployments are better than the (non-existent) .NET model, and the wealth of free libraries for Java (Jakarta, Codehaus, etc) still beats what's available for .NET.
With VPDAU, that problem is solved for recent NVidia cards. Myth .22 (should be out soon) supports this.
Too bad Casino's appears so often!
You could also use UnxUtils or GNU win32, which can just be unzipped and put in the path. Cygwin is overkill, I feel.
I think everyone is missing my point. Clearly stupid people can write whatever they want. Obviously unit tests help in this regard, but still don't prevent it. My original point is that, contrary to what Bruce said, duck typing does not help maintainability. You and several others keep harping on this point of moronic implementation, which has nothing to do with my original point. In no way am I saying that just because Java has interfaces can you assume that implementation will be correct or you can change things and it will still work. That's just so idiotic I didn't even think anyone would take my comments that way. Strong, static typing makes it easier to figure out how some (not all) changes will affect other code in a way that Ruby's dynamic typing does not allow. That includes unit test code. This helps a person maintain and change code more easily, especially if the person has not worked on the code before.
I see the point of the incremental programming, which I think can be good short term, but there's problems with it. If you never get around to changing all the other places, then you've left timebombs in your code that could fail, depending on the nature of the change. Also, you say that often a base class would have a default implementation or something, but one of the arguments in your original post was that you aren't forced into extending a specific class. I think those ideas are a bit at odds.
As far as maintenance is concerned, if you are changing Enumerable, then you probably have a good reason, and there may be lots of code using it assuming certain things, and if you want to change it you may need to look at all those things to evaluate those impacts as well as your reasons for making the change to start with. You may decide that change isn't worth it, or maybe you really have a separate interface to create, since maybe it really is separate from Enumerable, or maybe you need a sub-interface of Enumerable, because some but not all things have this new feature. These are the sort of things that, while perhaps Ruby makes it easier, it is not necessarily a good idea, from a maintenance perspective, for these things to be easy.
I'm not trying to knock Ruby, and I really like some of the other features Ruby has to offer. And everyone's brain works differently. But this duck-typing argument shows up so much it's a personal beef of mine. (It has merit but not as much as I see it getting everywhere, I think.)
See my reply to Tamerlin. You're both barking up the wrong tree. Clearly there is no magic language that lets you ensure code does exactly what it says it will. The contract is that you will have certain methods with certain parameter and return types - interface contracts, not design-by-contract or something even more encompassing, which you seem to be describing. Reading any more into it by saying the contract also states that you will have correct implementation is silly. Any language can have bugs, idiot programmers that don't know what they are doing, or malicious hackers. Nothing will prevent that, which is so obvious I'm somewhat surprised you both took my statement the way you did.
Ruby: code takes an object you expect to have a method name quack. Call the code with an object with no quack method, runtime failure.
Java: code takes a Duck. Compiler won't let you call it without that object having a quack method.
Which gets noticed first? Which way would you rather have when you are maintaining the code 6 months from now and have forgotten everything? Maintenance is the topic of the thread.
Yeah, so, you can do that in Ruby, too. In both cases you don't have a duck. The comment is in regards to maintainability. Neither language prevents you from coding like a moron. However, down the road, let's say you want to change something related to "quack" or being-a-duck. How do you find references in Ruby? Search all text files for a string? With static typing (Java), the compiler knows if changing something affects other code or what code is referenced where. Say you want ducks to be able to "shitOnGround". With Ruby you have to go find all the classes that think they are ducks to make sure they can shitOnGround now. If you add shitOnGround to the duck interface, the compiler will tell you about all the things that no longer properly implement Duck, insofar as method signatures are concerned. Sure, neither language ensures the method implementation isn't bogus, but if someone could find the solution to that then we wouldn't have jobs. But there's a difference between assuming things passed to a method have both quack and shitOnGround methods, and getting a runtime error if they don't, versus knowing at compile-time whether or not that code will run. Which do you think will be noticed more often and earlier?
I don't really view interfaces as design-by-contract. I think your comment about implementing a method correctly or not is besides the point, as implementing something incorrectly can be done in any language. As it relates to maintainability, the topic of this thread, I argue that Java and interfaces are superior. What if you wanted to add a method to your contract of Enumerable? How, in Ruby, do you go and find every object that used to think it was Enumerable, but now isn't? If you say that a static checking compiler is in the works, then it seems that duck typing really isn't as advantageous as previously asserted. Ruby may be more maintainable if you originally wrote the code, but if you are taking over maintenance of someone else's code, then I think static typing really helps. I'm willing to put in a little more work up front so I can let Eclipse do a whole lot of work for me later.
Java interfaces allow you to declare that something is a Duck, so it must be a duck. However, with Java, I can ensure that anything I think I want to call a duck does indeed fulfill the contract of being a duck. What in Ruby forces you to properly export the collection of methods in Enumerable when you defined is_enumerable to return true? Nothing?
In Ruby, you can write code that assumes a parameter has a method called foo. In the future if I make a new object, I can add a foo method to it and pass it into that code. In Java, all it takes is the oh-so-hard task of creating an interface called, say, CanFoo, that declares a foo method, and typing my parameter to that. For anything I want to pass into that code, I just implement method foo, which I have to do anyway, and add CanFoo to my list of implemented interfaces. Classes don't have to inherit from any particular class, and they can implement as many interfaces as they want. So that was no more work. However, now the compiler helps me to ensure that I properly fulfill the contract of CanFoo. Plus if I want to do anything useful like find things that think they CanFoo, or rename foo to something else, the compiler will know where all of these references are and help me.
I'm not anti-Ruby, but I just plain don't understand arguments like this for the language.
Also, "say it only once" may be somewhat forced by the framework, which is a good principle of a framework, but that transcends languages, so I don't buy that, either.
I'm not arguing that Rails isn't maintainable, just that your reasoning for why it is aren't exclusive to Rails or Ruby.
You are missing the point. Java JIT actually compiles the bytecode to native instructions. Also, since it does this after the code is running, it can optimize the compilation based on usage history and other runtime patterns, something that is not possible at compile time with C. With server apps, which handle a lot of repetive requests, this is very beneficial.
If you are saying C apps are faster because the OS is written is C also, then I don't know if that's a factor, either. Most of the standard Java libraries are written in Java, but the jvm.dll I believe is written in C.
Maybe if you listened to artists with talent then you would find CDs where more than one or two tracks are worthwhile. Nearly everything I like flows well as a whole album and is good throughout - I can't stand radio-like discontinuity of sound.