That's not a good argument. These features are not that horrific to implement, and they would improve Java for those that currently use it, not try to make it 'everything to everyone'.
I still disagree, as in a dynamic language, I think you'll find refactoring causes less breakage as stuff will generally continue to work due to the duck typing. Regardless, however you feel about dynamic languages, my point was that Java can be improved by adding in features to do stuff that currently force users to use IDEs to generate boilerplate code, not that Python is a better language than Java.
First of all, yes, it is an issue, because it does hamper productivity. More boilerplate code makes it harder to read, maintain and work with - which is a big deal for any non-trivial project.
As to your later points, why should I have to go to C# or Python to get those language features? Don't get me wrong, I love Python and use it extensively, but Java could implement them, and be a better language for it. That is the point.
How is modifying an attribute a bad thing? That is something that will need to happen in any code.
Actually, you don't need a main function as it's easy enough to execute it without - even if you didn't, it's about boilerplate - in Java, the main class is x lines of code plus a new file.
That is an issue that is solved by documentation and naming properties well, as far as I see it. As to yield being anything to do with this, I don't see it, a quick google seems to show that yield does a similar thing in C# to Python, which is generators - lazy computation of iterables - which is an awesome language feature I love.
The standard library is (mostly) great, I agree on that point, I'm just saying this is a problem I have with it. As to Python throwing too many exceptions, completely disagree, it makes it so much easier to work with - if something doesn't work the way you expect it to, it's going to throw an exception. Knowing that is so much nicer.
Typing bugs just don't really happen. I don't throw objects around my program like a madman into slots they don't fit. Seriously, even in large projects typing just doesn't really become a problem, and I don't know why everyone is so obsessed with it. Typing bugs are generally trivial, easily spotted bugs, that rarely (if ever) happen.
As to refactoring, I really don't see it makes refactoring any easier, if anything, it makes it harder as you can't swap things out as easily, and increases the size of your codebase meaning you have more to deal with.
Ugh, as always happens I poorly phrase the first sentence of my post and everyone jumps on it. I wasn't saying debuggers are bad, or at least wasn't trying to - just that in Java, the standard library has a tendency to return null when something goes wrong rather than throw an exception, which means you don't get told about the cause of the issue, just when it shows up later as a null pointer exception. This can lead to using the debugger a lot or looking through the code to track it down. I hope that clarifies my point.
Then you can swap out 'using a debugger' for 'spending time looking at the code' - neither should be necessary if you get an exception when something fails rather than returning null.
That really isn't true. Typing bugs show up with even the most trivial testing. I have written nontrivial stuff with Python, and it works fine as long as you have sane design.
That's not the point - I'm not saying that needing an IDE is a problem exactly, but it's a sign of a problem - I use an IDE for Python, where I definitely don't need one. The issue is, wherever you are generating boilerplate, that's more code to maintain and making your codebase harder to read, that is a real, big problem.
Properties - you create your getter and setter as you would, but Java layers them onto the attribute so you don't have to actually use getblah/setblah everywhere. C# does it (as do many other languages, but as we are talking Java, C# is the obvious comparison to make).
If you want your interface to remain the same, and may decide in the future to change your class to require functions behind attributes, then you have to use getters and setters in Java, there is nothing like a property in C# or Python that allows you to do this on-the-fly in a more natural way without the boilerplate.
You don't need boilerplate code to keep encapsulation and type-safety, you said it yourself - properties. Getters and setters can be replaced with properties. C# does it, which proves Java could. It's a perfect example of why the IDE is doing stuff the language could do, which is fine, but the language could be improved which would benefit everyone more.
The problem with the null pointer exception is that you get told about the effect of what happened, not what caused it. Say I try and do x, which fails, and then gives me null - when I try and use that x later on, I get the exception, and have to trace back up my code to find the issue. If x threw the exception when the problem happened, I would know why that object isn't there, which is far, far more valuable and easy to work with.
You enjoy pumping out those getters/setters, writing that boilerplate main class rubbish, etc... then? These things simply are not needed, and can be avoided by giving the programmer the right language features.
No, "Java has language flaws that force you to use an IDE to work around them." is the argument. Yes, some other languages do it right and make for an easy way to show the flaws, but that's not the point. The point is that Java could be a better language.
Then why can you catch an exception? Exceptions are the perfect tool for this kind of job - you might not be able to open that file, what will you do if you can't? Catch that exception and deal with it. It means you get the feedback at the right point.
I clarified later that I was talking about needing a debugger often, not at all. Clearly a debugger is a very useful tool, for all the reasons you stated, but in Java you often have to use a debugger to find trivial bugs because of flaws in the way the standard library operates - that is where I was saying there is an issue.
IDEs are great, but you have to admit that Java forces you to use one. Stuff like generating getters and setters and other boilerplate code which Java forces you to write is hell without an IDE. That is a problem with the language. With Java, eclipse is a sign that the IDE has to make up for language flaws, which is an issue - that's what the article is trying to say.
Slashdot Mirror
Of course, by why not talk about it and potentially see those changes happen?
That's not a good argument. These features are not that horrific to implement, and they would improve Java for those that currently use it, not try to make it 'everything to everyone'.
I still disagree, as in a dynamic language, I think you'll find refactoring causes less breakage as stuff will generally continue to work due to the duck typing. Regardless, however you feel about dynamic languages, my point was that Java can be improved by adding in features to do stuff that currently force users to use IDEs to generate boilerplate code, not that Python is a better language than Java.
First of all, yes, it is an issue, because it does hamper productivity. More boilerplate code makes it harder to read, maintain and work with - which is a big deal for any non-trivial project. As to your later points, why should I have to go to C# or Python to get those language features? Don't get me wrong, I love Python and use it extensively, but Java could implement them, and be a better language for it. That is the point.
You are entirely correct, I started with a terribly misleading sentence, I accept that error.
Exactly, that's why it's a language feature that can reduce the boilerplate generation IDEs currently have to do for Java.
How is modifying an attribute a bad thing? That is something that will need to happen in any code.
Actually, you don't need a main function as it's easy enough to execute it without - even if you didn't, it's about boilerplate - in Java, the main class is x lines of code plus a new file.
That is an issue that is solved by documentation and naming properties well, as far as I see it. As to yield being anything to do with this, I don't see it, a quick google seems to show that yield does a similar thing in C# to Python, which is generators - lazy computation of iterables - which is an awesome language feature I love.
The standard library is (mostly) great, I agree on that point, I'm just saying this is a problem I have with it. As to Python throwing too many exceptions, completely disagree, it makes it so much easier to work with - if something doesn't work the way you expect it to, it's going to throw an exception. Knowing that is so much nicer.
Typing bugs just don't really happen. I don't throw objects around my program like a madman into slots they don't fit. Seriously, even in large projects typing just doesn't really become a problem, and I don't know why everyone is so obsessed with it. Typing bugs are generally trivial, easily spotted bugs, that rarely (if ever) happen.
As to refactoring, I really don't see it makes refactoring any easier, if anything, it makes it harder as you can't swap things out as easily, and increases the size of your codebase meaning you have more to deal with.
That's my point, that in Java, nulls do get used to indicate failure, that's when they are a problem.
Ugh, as always happens I poorly phrase the first sentence of my post and everyone jumps on it. I wasn't saying debuggers are bad, or at least wasn't trying to - just that in Java, the standard library has a tendency to return null when something goes wrong rather than throw an exception, which means you don't get told about the cause of the issue, just when it shows up later as a null pointer exception. This can lead to using the debugger a lot or looking through the code to track it down. I hope that clarifies my point.
Then you can swap out 'using a debugger' for 'spending time looking at the code' - neither should be necessary if you get an exception when something fails rather than returning null.
Please clarify those comments, I don't see what you mean at all there.
That really isn't true. Typing bugs show up with even the most trivial testing. I have written nontrivial stuff with Python, and it works fine as long as you have sane design.
That's not the point - I'm not saying that needing an IDE is a problem exactly, but it's a sign of a problem - I use an IDE for Python, where I definitely don't need one. The issue is, wherever you are generating boilerplate, that's more code to maintain and making your codebase harder to read, that is a real, big problem.
Properties - you create your getter and setter as you would, but Java layers them onto the attribute so you don't have to actually use getblah/setblah everywhere. C# does it (as do many other languages, but as we are talking Java, C# is the obvious comparison to make).
If you want your interface to remain the same, and may decide in the future to change your class to require functions behind attributes, then you have to use getters and setters in Java, there is nothing like a property in C# or Python that allows you to do this on-the-fly in a more natural way without the boilerplate.
You don't need boilerplate code to keep encapsulation and type-safety, you said it yourself - properties. Getters and setters can be replaced with properties. C# does it, which proves Java could. It's a perfect example of why the IDE is doing stuff the language could do, which is fine, but the language could be improved which would benefit everyone more.
The problem with the null pointer exception is that you get told about the effect of what happened, not what caused it. Say I try and do x, which fails, and then gives me null - when I try and use that x later on, I get the exception, and have to trace back up my code to find the issue. If x threw the exception when the problem happened, I would know why that object isn't there, which is far, far more valuable and easy to work with.
You enjoy pumping out those getters/setters, writing that boilerplate main class rubbish, etc... then? These things simply are not needed, and can be avoided by giving the programmer the right language features.
No, "Java has language flaws that force you to use an IDE to work around them." is the argument. Yes, some other languages do it right and make for an easy way to show the flaws, but that's not the point. The point is that Java could be a better language.
Then why can you catch an exception? Exceptions are the perfect tool for this kind of job - you might not be able to open that file, what will you do if you can't? Catch that exception and deal with it. It means you get the feedback at the right point.
I clarified later that I was talking about needing a debugger often, not at all. Clearly a debugger is a very useful tool, for all the reasons you stated, but in Java you often have to use a debugger to find trivial bugs because of flaws in the way the standard library operates - that is where I was saying there is an issue.
IDEs are great, but you have to admit that Java forces you to use one. Stuff like generating getters and setters and other boilerplate code which Java forces you to write is hell without an IDE. That is a problem with the language. With Java, eclipse is a sign that the IDE has to make up for language flaws, which is an issue - that's what the article is trying to say.