What's more, a fair licencing deal would have kept Sun going which would have been easier for Google to deal with going forward than Oracle, and not have allowed Java to get into Oracle's hands, which a large number of developers would have preferred.
I generally like Google, but they really did shaft Sun.
That was the least fact filled review ever. "There are lots of good things about the Galaxy but none of them are important, and besides, it's not an iPad."
..and you get modded 'troll'? Serious moderation abuse
Re:What are they trying to prove at this point?
on
Sony Compromised, Again
·
· Score: 3, Insightful
When they expose the personal details of millions of innocent customers? Jesus, use your fucking brain
Re:What are they trying to prove at this point?
on
Sony Compromised, Again
·
· Score: 5, Interesting
Case in point - I've been pro open source, anti IP laws, anti harsh pirating / copying fines for a very long time. I'm pretty liberal and I don't like big corporations. But this shit just pisses me off. They don't like Sony so they fuck over the services that millions of paying customers are using and expose all their personal details? What a pack of pricks. That ain't cool, that's fucked up and selfish.
In New Zealand, Subway still has 'foot long' sandwiches. Just because you don't use feet for measuring things in general usage, doesn't mean that everyone suddenly forgets what the word means.
I prefer NB to VS, but it's hardly apples to oranges. NB does do C/C++, but it's not its strong point - Java is its strong point. I used to think that Visual Studio was the best IDE ever at about release 5, but since then I think all the main Java IDEs: Netbeans, Eclipse and IdeaJ have, well, eclipsed VS.
I'd say that parenthesis matching is necessary for programming LISP, but whatever.
Let's say that an IDE *is* necessary for programming Java (I'd agree it is) so what? Java & and IDE is how people code java - get over it. You think that's "impure" or "improper" in some way. So. Fucking. What. I don't share your sense of the moral significance of that fact. There is no software engineering benefit or hinderance flowing from that fact. You like languages that don't need IDEs, I like girls with red hair. Those facts have as much software engineering significance as each other.
I didn't mean to imply that I thought refactoring was in and of itself useless, rather that with the Java style getters/setters you either have to use those exclusively, just in case you need to change the semantics of accessing a particular property, or use refactoring tools to automate changing what had previously been a simple attribute access, e.g. blah == foo.bar, to blah = foo.getBar() when the situation dictates.
I merely wished to point out the typical Java solution of "Getters and Setters For Everything" is wrong headed and leads to the exact kind of code bloat and extraneous verbosity that Java is undeniably famous for. The kind of pointless verbosity which requires complex IDE's and toolsets to keep developers from going insane. "Oh joy, my new class is going to have 20 publicly visible attributes, time to write 20 more getter methods. I love my job!"
As I said before, no-one writes all those getters and setters, so you're railing at a problem that no-one ever has. If there was some rule that you had to code using notepad, you'd have a point. But there isn't and the fact is that everyone codes Java using an IDE (you have to mainly for documentation and completion on the standard libraries since they're so numerous).
In practice, writing a class in Java with 20 publicly visible attributes in Java is EXACTLY the same as doing so in Ruby. You can only make your strawman argument work if you insist that IDE's are not allowed. In the real world, people use IDEs. And so what if they're "complicated". They're not, but even if they were, so what? I use Emacs a whole lot - you can certainly argue that Emacs is complicated but that doesn't make C code bad because I use Emacs to write C in. I'd never write LISP without an editor that does parentheses matching - is LISP suddenly a bad language? I don't think so.
It's ideal if you never type errors, but I suspect with equality checking vs assignment, there's always going to be some mistakes since "A equals B" is how we talk about both equality and assignment. If you have ":=" or ".equals()", people will still mistakenly write "=" from time to time. I've used dozens of different languages with different equality tests and assignments and invariably I get them wrong from time to time.
I personally don't dislike any of them (except Javascript - don't like ===) the only thing I can't stand is the compiler silently accepting stuff it should warn you about "if(a=b)" in Algol based languages being the classic example.
So, I agree with what you're saying - in theory - I just don't think there IS any language that does a significantly better job than any other in making assignment and equality testing impossible to screw up.
What are you talking about? You have one returning an int and the other returning a void. That is why I asked. Guesing you meant to return an int in the second one as well, so not as excited as I was when I first saw it.
No, I did NOT mean to return an int. That is perfectly valid Java code. You DID notice that one method takes an int and the other has no parameters, right? That's why this is just normal parametric overloading, as I said.
I agree with you that code is read more than it's written, which is why I think that being explicit in code is better than being clever. It's also why I don't think a few extra characters here or there make a big difference.
I do agree with you that having lots of accessor / mutators makes the code harder to read, but I still don't think its the biggest problem in the world. Most people just browse their classes via an IDE anyway. This seems like one of the more trivial reasons to dislike Java. I'd much rather see closures, type inference, object literals, type inference in the language than agonise over accessor functions.
...And don't even start on "Refactoring tools" as a solution to this problem. The necessity for "refactoring" when you simply need to change something so simple is merely an indication of design flaws in in the language itself.
The Java method is to access public attributes strictly with the kludgey getter/setter functions. Although I've never worked on a "huge enterprisey project," the Ruby/Python method of public except where absolutely necessary is easiest to work with. If some stupid bastard is changing things in an object which shouldn't be changed from the outside, the problem is due to PERSONNEL, not design.
Huh! That huge 'Refactoring Ruby' book I've got at work must be completely in error, then. You must drop them a line and let them know they've got it all wrong.
You are so wrong-headed about refactoring that I can't even be bothered to correct you. Use Google to educate yourself about why software engineers refactor code. HINT: It's not related to language choice.
I don't really agree. I think you need both a supportive language and good developer culture to make developing in a team successful. They're both necessary but not individually sufficient conditions for a good dev. team.
I have worked with teams of smart, well intentioned C++ programmers who despite conventions and reviews to the contrary, end up developing code in stylistic cul-de-sacs that none of their fellows shared.
Specifically regarding operator overloading - really, I don't mind EXTREMELY limited use of operator overloading, but someone ALWAYs ends up abusing the feature. And in real life, you don't control all the code you use. In the real life, you use third party code, over which you have no control and your style guides and procedures are worth precisely NOTHING in that case.
Also, regarding overloading, my other major objection is that it's not actually possible to do it properly:
* You can't use all the appropriate operators - Vector maths uses cross and dot product operators. I can do cross product in the conventional way - using the multiply operator, but I can't overload the dot operator at all.
* In most cases, you're stuck with the language's built in operator precedence, which is often wrong (e.g.: in Vector maths, dot product conventionally has lower precedence than cross product)
* I'm aware of no implementation that will give you the other important notation in vector mathematics - the length and normal operators: |v| ||v||
So, you can't actually write code to look like a simple, common mathematical domain like Vector mathematics. And most of the time, mathematicians aren't writing code, coders are writing code. So following the principles of least astonishment and the principal of code orthogonality, we should have code that looks like normal code, not code that wants to look like mathematical notation but can't even get halfway there.
Operator overloading is a neat idea but an imperfect, ill-fitting reality.
I've coded in C++ since the early drafts of the language. I know how multiple inheritance or operator overloading work in C++ perfectly well, thank you. In fact, I'd be pretty damn sure that I have more C++ experience than you do - unless you were actually on the development team with Stroustrup?
I explained why multiple inheritance is bad (the diamond problem - other people have pointed this out and I notice you haven't answered any of them, you just keep ranting the same stuff). I also explained how to solve those issues in a way that's better than either MI or SI with interfaces - namely mixins / traits. You've ignored that even though that's clearly a better solution than either MI or SI+I.
You don't seem to take off your C++ blinkers and see that there are other ways to do things, and contrary to your apparent point of view, C++ did not get everything right. The answer to every language design issue is not "make it C++"
Slashdot Mirror
What's more, a fair licencing deal would have kept Sun going which would have been easier for Google to deal with going forward than Oracle, and not have allowed Java to get into Oracle's hands, which a large number of developers would have preferred.
I generally like Google, but they really did shaft Sun.
Nice rant, but finding apple 'enthusiasts' a little tiring does not automatically make one a linux apologist.
That was the least fact filled review ever. "There are lots of good things about the Galaxy but none of them are important, and besides, it's not an iPad."
Why the fuck is this shit even on /.?
..and you get modded 'troll'? Serious moderation abuse
When they expose the personal details of millions of innocent customers? Jesus, use your fucking brain
Case in point - I've been pro open source, anti IP laws, anti harsh pirating / copying fines for a very long time. I'm pretty liberal and I don't like big corporations. But this shit just pisses me off. They don't like Sony so they fuck over the services that millions of paying customers are using and expose all their personal details? What a pack of pricks. That ain't cool, that's fucked up and selfish.
You can get it under the GPL licence?
6.9 is rock solid for me - perhaps it's just your install?
Hmmm, yeah, I'll agree with that. The file dialogs aren't so great.
Just as it was for EVERY OTHER nation on the planet. They all coped.
In New Zealand, Subway still has 'foot long' sandwiches. Just because you don't use feet for measuring things in general usage, doesn't mean that everyone suddenly forgets what the word means.
Buggy? I use NB all day every day and I can't remember the last time I saw a bug in NB
I prefer Swing by a long shot. SWT was prettier and slightly faster than Swing when it was initially released. Neither of those are true any more.
So do I and I think the exact opposite.
I prefer NB to VS, but it's hardly apples to oranges. NB does do C/C++, but it's not its strong point - Java is its strong point. I used to think that Visual Studio was the best IDE ever at about release 5, but since then I think all the main Java IDEs: Netbeans, Eclipse and IdeaJ have, well, eclipsed VS.
I'd say that parenthesis matching is necessary for programming LISP, but whatever.
Let's say that an IDE *is* necessary for programming Java (I'd agree it is) so what? Java & and IDE is how people code java - get over it. You think that's "impure" or "improper" in some way. So. Fucking. What. I don't share your sense of the moral significance of that fact. There is no software engineering benefit or hinderance flowing from that fact. You like languages that don't need IDEs, I like girls with red hair. Those facts have as much software engineering significance as each other.
I didn't mean to imply that I thought refactoring was in and of itself useless, rather that with the Java style getters/setters you either have to use those exclusively, just in case you need to change the semantics of accessing a particular property, or use refactoring tools to automate changing what had previously been a simple attribute access, e.g. blah == foo.bar, to blah = foo.getBar() when the situation dictates.
I merely wished to point out the typical Java solution of "Getters and Setters For Everything" is wrong headed and leads to the exact kind of code bloat and extraneous verbosity that Java is undeniably famous for. The kind of pointless verbosity which requires complex IDE's and toolsets to keep developers from going insane. "Oh joy, my new class is going to have 20 publicly visible attributes, time to write 20 more getter methods. I love my job!"
As I said before, no-one writes all those getters and setters, so you're railing at a problem that no-one ever has. If there was some rule that you had to code using notepad, you'd have a point. But there isn't and the fact is that everyone codes Java using an IDE (you have to mainly for documentation and completion on the standard libraries since they're so numerous).
In practice, writing a class in Java with 20 publicly visible attributes in Java is EXACTLY the same as doing so in Ruby. You can only make your strawman argument work if you insist that IDE's are not allowed. In the real world, people use IDEs. And so what if they're "complicated". They're not, but even if they were, so what? I use Emacs a whole lot - you can certainly argue that Emacs is complicated but that doesn't make C code bad because I use Emacs to write C in. I'd never write LISP without an editor that does parentheses matching - is LISP suddenly a bad language? I don't think so.
It's ideal if you never type errors, but I suspect with equality checking vs assignment, there's always going to be some mistakes since "A equals B" is how we talk about both equality and assignment. If you have ":=" or ".equals()", people will still mistakenly write "=" from time to time. I've used dozens of different languages with different equality tests and assignments and invariably I get them wrong from time to time.
I personally don't dislike any of them (except Javascript - don't like ===) the only thing I can't stand is the compiler silently accepting stuff it should warn you about "if(a=b)" in Algol based languages being the classic example.
So, I agree with what you're saying - in theory - I just don't think there IS any language that does a significantly better job than any other in making assignment and equality testing impossible to screw up.
int myProperty(){ return mp; }
void myProperty(int i){ mp = i; }
What are you talking about? You have one returning an int and the other returning a void. That is why I asked. Guesing you meant to return an int in the second one as well, so not as excited as I was when I first saw it.
No, I did NOT mean to return an int. That is perfectly valid Java code. You DID notice that one method takes an int and the other has no parameters, right? That's why this is just normal parametric overloading, as I said.
I agree with you that code is read more than it's written, which is why I think that being explicit in code is better than being clever. It's also why I don't think a few extra characters here or there make a big difference.
I do agree with you that having lots of accessor / mutators makes the code harder to read, but I still don't think its the biggest problem in the world. Most people just browse their classes via an IDE anyway. This seems like one of the more trivial reasons to dislike Java. I'd much rather see closures, type inference, object literals, type inference in the language than agonise over accessor functions.
... diatribe snipped ...
The Java method is to access public attributes strictly with the kludgey getter/setter functions. Although I've never worked on a "huge enterprisey project," the Ruby/Python method of public except where absolutely necessary is easiest to work with. If some stupid bastard is changing things in an object which shouldn't be changed from the outside, the problem is due to PERSONNEL, not design.
Huh! That huge 'Refactoring Ruby' book I've got at work must be completely in error, then. You must drop them a line and let them know they've got it all wrong.
You are so wrong-headed about refactoring that I can't even be bothered to correct you. Use Google to educate yourself about why software engineers refactor code. HINT: It's not related to language choice.
where did *I* say that Java got everything right?
I don't really agree. I think you need both a supportive language and good developer culture to make developing in a team successful. They're both necessary but not individually sufficient conditions for a good dev. team.
I have worked with teams of smart, well intentioned C++ programmers who despite conventions and reviews to the contrary, end up developing code in stylistic cul-de-sacs that none of their fellows shared.
Specifically regarding operator overloading - really, I don't mind EXTREMELY limited use of operator overloading, but someone ALWAYs ends up abusing the feature. And in real life, you don't control all the code you use. In the real life, you use third party code, over which you have no control and your style guides and procedures are worth precisely NOTHING in that case.
Also, regarding overloading, my other major objection is that it's not actually possible to do it properly:
* You can't use all the appropriate operators - Vector maths uses cross and dot product operators. I can do cross product in the conventional way - using the multiply operator, but I can't overload the dot operator at all.
* In most cases, you're stuck with the language's built in operator precedence, which is often wrong (e.g.: in Vector maths, dot product conventionally has lower precedence than cross product)
* I'm aware of no implementation that will give you the other important notation in vector mathematics - the length and normal operators: |v| ||v||
So, you can't actually write code to look like a simple, common mathematical domain like Vector mathematics. And most of the time, mathematicians aren't writing code, coders are writing code. So following the principles of least astonishment and the principal of code orthogonality, we should have code that looks like normal code, not code that wants to look like mathematical notation but can't even get halfway there.
Operator overloading is a neat idea but an imperfect, ill-fitting reality.
Since when can Java do method return overloading?
Um.... It can't. Re-read the code I wrote - that's bog standard parametric overloading.
I've coded in C++ since the early drafts of the language. I know how multiple inheritance or operator overloading work in C++ perfectly well, thank you. In fact, I'd be pretty damn sure that I have more C++ experience than you do - unless you were actually on the development team with Stroustrup?
I explained why multiple inheritance is bad (the diamond problem - other people have pointed this out and I notice you haven't answered any of them, you just keep ranting the same stuff). I also explained how to solve those issues in a way that's better than either MI or SI with interfaces - namely mixins / traits. You've ignored that even though that's clearly a better solution than either MI or SI+I.
You don't seem to take off your C++ blinkers and see that there are other ways to do things, and contrary to your apparent point of view, C++ did not get everything right. The answer to every language design issue is not "make it C++"