I've been saying this for weeks now. Actually, ever since the first time I said, "Wow, I love g-mail, I wish I could use it for work."
If Google has calendaring and mail, with interfaces that are both simple and intuitive (obviously a strength of Google) then they can bundle that with their Enterprise search functionality and have a heck of a package.
They can sell it service-based like Microsoft dreams about, or they can ship it out on the little yellow boxes. Users are freed from installation hassles, and in the subscription package, IT departments from management hassles.
So... is your saying that "XML sucks as a data storage language" kind of like Winston Churchill saying, "Democracy is the worst form of government except for all those others that have been tried."?
Which I read to mean, "It works, but there's room for improvement"?
Why not? Because those two documents (lisp s expressions and documentation thereof) are only in synch once, at creation. From there forward, never again.
Everyone here at/. whines about the readability of XML. I have yet to see an example of an improvement.
As for performance, for 99% of your applications, it just doesn't matter. Software analysis and development time is much more expensive than clock cycles.
Would I use XML for a database? Probably not without a lot of convincing. Do I use it for data exchanges? Absolutely, and I don't know of a better tool.
Just to be clear, those 20K signatures get your new initiative on the ballot, not actually made into law. I'm sure the OP is aware of this, I just didn't want other readers to get confused.
Congratulations on your long, though apparently shallow, experience with Java. Perhaps you'd like to quantify your complaints other than what boils down to "I've heard of the language since the beginning, used it in the late 90's, and still think it's terrible"
You've pointed out that you know what SWT is. Can explain why you use its Linux shortcomings as a reason to dismiss the entire platform, even though you know that it's an unrelated third party library? Especially as regards to performance?
And as for the Visual Studio comment, if you're going to compare IDEs (or any application, really), and use it to bash the language, I think you have to compare them platform by platform. Eclipse runs as "snappily" on windows as Visual Studio does. Eclipse also runs quite a bit better on Linux than Visual Studio does.
If you're going to discuss the parent topic (Linux Java dev environments), then I think you have to leave out your outdated "java sux" trollery.
If my replies seem rather harsh, I have to apologize. This is one of those Java Myths that drives me nuts./. pundits have fallen so behind when they complain "java gui's are slow! java gui's are slow". Java's gui interactions were increased dramatically with 1.4, and with 1.5 there's no reason at all to even perpetuate this myth.
If there's a legitimate complaint to be heard here, it's that Sun wants to push a Java-branded look and feel. That interaction is "different", and since they don't pay their designers as well as Apple or Microsoft (or at least I hope they don't--Metal is ugly), it ends up looking boxy instead of modern. Looks and performance are two different things, and there are certainly well-known and well-supported (just not default) approaches to having a more native look-and-feel.
Ultimately, though, as a "consultant working on all sorts of operating systems and development environments", you should be able to tell the difference between appearance and performance. In this case, I think you're misleading yourself.
Whoop, you're on Linux. SWT does have issues on Linux. However, SWT (the GUI library that Eclipse is written in)... and listen to this closely... SWT is not Java. You're decrying an entire language based on a third-party tool that was neither developed nor supported by the makers of the platform.
In case you're unaware, SWT is a bizarre partly-native abomination. If you have problems on your platform (and there are some on Linux), it's a problem on your platform with the platform-specific half of said abomination.
Well, yeah. Eclipse can't really magically solve one of CVS' major defects. FWIW, it does handle it as gracefully as possible, there's an "add file" and "delete file" action when you go to commit.
First, I was unaware of the other definition of "incremental" compilation.
What Eclipse does is attempt to compile the code as I type, even before I save the file. If I need to add a cast, I can see that immediately. Perhaps it ought to be called immediate compilation, but that sounds a lot more intrusive than it is.
Since I'm on the topic, the other thing that Eclipse provides is a "quick fix" functionality that actually works. I never type the cast block in my 1.4 code, I type the Collection accessor and press control-1 for quickfix. The compiler has already complained, and the IDE says "Add cast to String?". Which I never read because it's always right, and I've pressed enter and continued on.
Similarly for undeclared variables. I assign it to something, hit control-1 and select whether I wanted a local variable or a field. It fills in the type, and I carry on.
The "predictive" stuff (that isn't compilation) is more like when I call a method that takes an Integer field called "size" and a String field called "message". If I happen to have an Integer and a String with those names, it fills them in for me. It also leaves them highlighted so I can type over them if I want, with no extra keystrokes.
However, it still has that funky slow-ass feeling that all applications written in Java have. [...] Java still sucks. I'll be frank here:
I think this is in your head. Unless you're running it on a p90, Eclipse and SWT is really quite snappy. Especially Eclipse 3.0. If you felt slowness in 2.0, it's because of the immense amount of work it attempts to do in the background. Parsing, compiling, interpreting your codebase is not a small task, unless you've got a small project.
As for Java's general performance, I can tell you that at my company, it's sufficient for the $10,000/hr server platform that must have sub-3ms response times.
In vi (and most shell apps) control-z returns you to the shell, and suspends the application you were running. This leaves you free to run other applications, like perhaps:
ant devbuild
watching them complete, then returning to your suspended ap with:
I find that incremental compilation and code completion are now essential to my own development flow. I type part of the classname and hit control-space. I pick the option I wanted (often faster than typing it) and it is automatically added to the import statements.
I call a method on that class (like the constructor), hitting control-space again to see the options. Often, if the names and types in the current context match what I want, it's filled in. I hit enter and carry on.
Wait, I missed an exception apparently, because it's telling me that. I'll either deal with it now (when I know what I'm doing) or save it for later.
It's just another tool to use. If you're writing code 8 hours a day, why not let the computer do stuff it's good at, and free yourself up to do the hard part of actually figuring out the problem domain?
Eclipse 3.0 is responsive on my box, but then it's a 2.8ghz with 1GB of ram. Not that those are the minimum specs, just what I happen to have.
You're overstating the use of the tool, I think. Nothing's changed "willy nilly because I like to show off my new Eclipse toy". They're changed so that they say what they do.
We do this often enough to like it, but not so often it bothers us, on my team of three. Perhaps your codebase has rather a lot of poorly named classes?
What preprocessor are you talking about? If you're talking about JSPs, there are plug-ins. If you're rolled your own, you'll need to roll your own preprocessor worker (called a 'builder' in Eclipse) as well.
The only thing you get from a graphical IDE is the ability to step through the instructions.
You *really* need to have a look at Eclipse. Debugging is nice, but it's not the whole crop.
What's at the top? It understands your code. The first thing you'll notice is the incremental compilation. You don't have to ctrl-z (or alt-tab or whatever) and run the compiler and wait. It compiles it as you're typing, and tells you where you've screwed up. That improves your efficiency right there.
Next on the list is lint-checking. This starts with needless imports, and continues with warnings for unused private methods, empty and undocumented catch blocks, and a host of things that are easily missed. It's a real eye-opener to load up your vi-edited code into Eclipse and see the cruft.
Last, and most powerful of all, is refactoring. I can, with that dreaded mouse, move a class between packages far faster than you can even if you're a regexp wizard. I can rename variables and methods without fear. In short, I can do everything I need in order to make sure that the codebase makes sense. No more comments like, "This method doesn't do this anymore, but it's too much hassle to change its name"
Knowing that classnames and packages aren't set in stone, you are much more free to get to writing the code, and change what you need to change, as you discover the need to change it.
If I had to guess, I'd guess that you tried JBuilder, didn't care for it, and haven't looked back. Eclipse is so radically different from that environment that its almost miscategorization to call it 'an IDE'.
-Zipwow
Re:Lacking Accountability and Ownership
on
Time Sharing Cars
·
· Score: 2, Informative
Another poster points out that that's why Flexcar has staff. They change the oil more regularly than you do, they rotate the tires more often than you do, they have the car tuned more often than you do.
And, should you like to make yourself $5, Flexcar will also *pay you* to wash the car. It's a nice touch, when you've got extra time and have to put gas in it anyway.
Which, by the way they pay for. AND they pay you $2 when you put their gas in it when it's under half a tank.
-Zipwow
Do NOT be late with the flexcar.
on
Time Sharing Cars
·
· Score: 2, Informative
The first rule of Flexcar is: You can depend on the flexcar.
The second rule of Flexcar is: You can depend on the flexcar.
The third rule of Flexcar is: DO NOT BE LATE WITH THE FLEXCAR.
Their policy is that if you have a reservation, and the car isn't there, you call their toll-free 24-hour support number. They either get you a car nearby (if that works), or they send you a taxi. You take that taxi on your task, for up to some amount ($200 I think it is). The bottom line: if you have a reservation, you can count on getting where you're going.
Why can they afford to do this? If you're the one late with the flexcar, and you didn't call and let them know, YOU PAY FOR THE TAXI.
Do NOT be late with the Flexcar.
On the upside, if you *know* you're going to be late, then you can call in and let them know. Then they can warn the next member, or send a taxi to take them to another car. Much cheaper than sending a taxi to take them on their whole trip.
Of course, if it totally isn't your fault (accident, car breakdown, etc) Flexcar takes pretty good care of you. I was late with a car once because I had taken my wife to the hospital in it (a deep cut -- needed to be examined, but not ambulance worthy). They worked with the next person, and got it taken care of.
I've been a Flexcar member and car-free (in Seattle) for four years. It's great. I've only paid taxi fees a couple of times, they were about $40 or so. Ultimately, not a big deal. And even with the fees, waaay cheaper than owning a car.
Or rained-on, or frozen, or snowed-on. And can shower/warm up/treat frostbite at work.
Bikes are nice, but they're not an ultimate solution in most of the country. Think Minneapolis. Think Denver. Hell, it's cold enough in Seattle that only the hard-core greens bike year round. Even then it only works if you have shower facilities at work.
First, it's scaling pretty well already. Second, if you find that Comic Book Guy did God Knows What in the back seat, you call the 24-hour number. They fine Comic Book Guy $200, pay you $20 for your inconvenience. Then they get you a taxi to another car, or you use the taxi itself for your trip. Which Comic Book Guy also pays for.
Go read the site at flexcar, it's pretty well thought-out.
I agree that we need some other style of voting, but IRV doesn't seem to be it. From wikipedia:
"Instant-runoff voting is unusual in that it does not satisfy the monotonicity criterion--in some situations, if a voter or group of voters decides to rank a preferred candidate lower, it can result in that candidate winning the election, whereas if they had ranked the candidate higher, according to their sincere preference, that candidate would not have won."
Condorcet doesn't have this problem. It seems to make a lot of sense, but I haven't looked into all the tie-resolution methods.
First, there is more than one car on the system. If you have more than three, take extra cars.
But why three, and not four, or five? The reason I've read in the past is this:
Three is the smallest number of occupants that guarantees that no members of a group need to ride alone.
If the cars held two, and your group of three arrived, then someone would have to ride by themselves. Not fun, and socially difficult.
It's true that if the cars held four, the same system would work (five people go in three and two). There is, however, significant expense to adding another passenger space. You'd either have to make them wider. This would increase the space between the railings, and the overall construction cost in addition to the car cost. You could add another row of seats, but that would increase the complexity and cost of the car.
Slashdot Mirror
I've been saying this for weeks now. Actually, ever since the first time I said, "Wow, I love g-mail, I wish I could use it for work."
If Google has calendaring and mail, with interfaces that are both simple and intuitive (obviously a strength of Google) then they can bundle that with their Enterprise search functionality and have a heck of a package.
They can sell it service-based like Microsoft dreams about, or they can ship it out on the little yellow boxes. Users are freed from installation hassles, and in the subscription package, IT departments from management hassles.
It seems like the next logical step to me.
-Zipwow
So... is your saying that "XML sucks as a data storage language" kind of like Winston Churchill saying, "Democracy is the worst form of government except for all those others that have been tried."?
Which I read to mean, "It works, but there's room for improvement"?
-Zipwow
What's your beef with the file format? And what's your proposal or suggestion for an improvement?
Why not? Because those two documents (lisp s expressions and documentation thereof) are only in synch once, at creation. From there forward, never again.
/. whines about the readability of XML. I have yet to see an example of an improvement.
Everyone here at
As for performance, for 99% of your applications, it just doesn't matter. Software analysis and development time is much more expensive than clock cycles.
Would I use XML for a database? Probably not without a lot of convincing. Do I use it for data exchanges? Absolutely, and I don't know of a better tool.
-Zipwow
What a story -- do you have a city, or a news story link?
Just to be clear, those 20K signatures get your new initiative on the ballot, not actually made into law. I'm sure the OP is aware of this, I just didn't want other readers to get confused.
-Zipwow
It's only a joke in 2005 to those who haven't paid attention since 1998.
I write Java applications that are moderate in terms of memory consumption, and are high-speed components at the core of our business.
My friends manage a bunch of servers that run C++ applications, and they regularly get their memory resources swamped.
-Zipwow
Hopefuly they have the memory hogging under control; somehow it seems a waste to have 4G of ram in an embedded device just to run java
1998 called, they want their joke back.
-Zipwow
Congratulations on your long, though apparently shallow, experience with Java. Perhaps you'd like to quantify your complaints other than what boils down to "I've heard of the language since the beginning, used it in the late 90's, and still think it's terrible"
/. pundits have fallen so behind when they complain "java gui's are slow! java gui's are slow". Java's gui interactions were increased dramatically with 1.4, and with 1.5 there's no reason at all to even perpetuate this myth.
You've pointed out that you know what SWT is. Can explain why you use its Linux shortcomings as a reason to dismiss the entire platform, even though you know that it's an unrelated third party library? Especially as regards to performance?
And as for the Visual Studio comment, if you're going to compare IDEs (or any application, really), and use it to bash the language, I think you have to compare them platform by platform. Eclipse runs as "snappily" on windows as Visual Studio does. Eclipse also runs quite a bit better on Linux than Visual Studio does.
If you're going to discuss the parent topic (Linux Java dev environments), then I think you have to leave out your outdated "java sux" trollery.
If my replies seem rather harsh, I have to apologize. This is one of those Java Myths that drives me nuts.
If there's a legitimate complaint to be heard here, it's that Sun wants to push a Java-branded look and feel. That interaction is "different", and since they don't pay their designers as well as Apple or Microsoft (or at least I hope they don't--Metal is ugly), it ends up looking boxy instead of modern. Looks and performance are two different things, and there are certainly well-known and well-supported (just not default) approaches to having a more native look-and-feel.
Ultimately, though, as a "consultant working on all sorts of operating systems and development environments", you should be able to tell the difference between appearance and performance. In this case, I think you're misleading yourself.
-Zipwow
Whoop, you're on Linux. SWT does have issues on Linux. However, SWT (the GUI library that Eclipse is written in) ... and listen to this closely... SWT is not Java. You're decrying an entire language based on a third-party tool that was neither developed nor supported by the makers of the platform.
In case you're unaware, SWT is a bizarre partly-native abomination. If you have problems on your platform (and there are some on Linux), it's a problem on your platform with the platform-specific half of said abomination.
How well does Visual Studio run on Linux, anyway?
-Zipwow
Well, yeah. Eclipse can't really magically solve one of CVS' major defects. FWIW, it does handle it as gracefully as possible, there's an "add file" and "delete file" action when you go to commit.
First, I was unaware of the other definition of "incremental" compilation.
What Eclipse does is attempt to compile the code as I type, even before I save the file. If I need to add a cast, I can see that immediately. Perhaps it ought to be called immediate compilation, but that sounds a lot more intrusive than it is.
Since I'm on the topic, the other thing that Eclipse provides is a "quick fix" functionality that actually works. I never type the cast block in my 1.4 code, I type the Collection accessor and press control-1 for quickfix. The compiler has already complained, and the IDE says "Add cast to String?". Which I never read because it's always right, and I've pressed enter and continued on.
Similarly for undeclared variables. I assign it to something, hit control-1 and select whether I wanted a local variable or a field. It fills in the type, and I carry on.
The "predictive" stuff (that isn't compilation) is more like when I call a method that takes an Integer field called "size" and a String field called "message". If I happen to have an Integer and a String with those names, it fills them in for me. It also leaves them highlighted so I can type over them if I want, with no extra keystrokes.
-Zipwow
However, it still has that funky slow-ass feeling that all applications written in Java have. [...] Java still sucks.
I'll be frank here:
I think this is in your head. Unless you're running it on a p90, Eclipse and SWT is really quite snappy. Especially Eclipse 3.0. If you felt slowness in 2.0, it's because of the immense amount of work it attempts to do in the background. Parsing, compiling, interpreting your codebase is not a small task, unless you've got a small project.
As for Java's general performance, I can tell you that at my company, it's sufficient for the $10,000/hr server platform that must have sub-3ms response times.
Have you actually tried it since 1998?
-Zipwow
In vi (and most shell apps) control-z returns you to the shell, and suspends the application you were running. This leaves you free to run other applications, like perhaps:
ant devbuild
watching them complete, then returning to your suspended ap with:
fg 1
-Zipwow
Since you mention flow...
I find that incremental compilation and code completion are now essential to my own development flow. I type part of the classname and hit control-space. I pick the option I wanted (often faster than typing it) and it is automatically added to the import statements.
I call a method on that class (like the constructor), hitting control-space again to see the options. Often, if the names and types in the current context match what I want, it's filled in. I hit enter and carry on.
Wait, I missed an exception apparently, because it's telling me that. I'll either deal with it now (when I know what I'm doing) or save it for later.
It's just another tool to use. If you're writing code 8 hours a day, why not let the computer do stuff it's good at, and free yourself up to do the hard part of actually figuring out the problem domain?
Eclipse 3.0 is responsive on my box, but then it's a 2.8ghz with 1GB of ram. Not that those are the minimum specs, just what I happen to have.
-Zipwow
You're overstating the use of the tool, I think. Nothing's changed "willy nilly because I like to show off my new Eclipse toy". They're changed so that they say what they do.
We do this often enough to like it, but not so often it bothers us, on my team of three. Perhaps your codebase has rather a lot of poorly named classes?
-Zipwow
What preprocessor are you talking about? If you're talking about JSPs, there are plug-ins. If you're rolled your own, you'll need to roll your own preprocessor worker (called a 'builder' in Eclipse) as well.
-Zipwow
You *really* need to have a look at Eclipse. Debugging is nice, but it's not the whole crop.
What's at the top? It understands your code. The first thing you'll notice is the incremental compilation. You don't have to ctrl-z (or alt-tab or whatever) and run the compiler and wait. It compiles it as you're typing, and tells you where you've screwed up. That improves your efficiency right there.
Next on the list is lint-checking. This starts with needless imports, and continues with warnings for unused private methods, empty and undocumented catch blocks, and a host of things that are easily missed. It's a real eye-opener to load up your vi-edited code into Eclipse and see the cruft.
Last, and most powerful of all, is refactoring. I can, with that dreaded mouse, move a class between packages far faster than you can even if you're a regexp wizard. I can rename variables and methods without fear. In short, I can do everything I need in order to make sure that the codebase makes sense. No more comments like, "This method doesn't do this anymore, but it's too much hassle to change its name"
Knowing that classnames and packages aren't set in stone, you are much more free to get to writing the code, and change what you need to change, as you discover the need to change it.
If I had to guess, I'd guess that you tried JBuilder, didn't care for it, and haven't looked back. Eclipse is so radically different from that environment that its almost miscategorization to call it 'an IDE'.
-Zipwow
Another poster points out that that's why Flexcar has staff. They change the oil more regularly than you do, they rotate the tires more often than you do, they have the car tuned more often than you do.
And, should you like to make yourself $5, Flexcar will also *pay you* to wash the car. It's a nice touch, when you've got extra time and have to put gas in it anyway.
Which, by the way they pay for. AND they pay you $2 when you put their gas in it when it's under half a tank.
-Zipwow
The first rule of Flexcar is: You can depend on the flexcar.
The second rule of Flexcar is: You can depend on the flexcar.
The third rule of Flexcar is: DO NOT BE LATE WITH THE FLEXCAR.
Their policy is that if you have a reservation, and the car isn't there, you call their toll-free 24-hour support number. They either get you a car nearby (if that works), or they send you a taxi. You take that taxi on your task, for up to some amount ($200 I think it is). The bottom line: if you have a reservation, you can count on getting where you're going.
Why can they afford to do this? If you're the one late with the flexcar, and you didn't call and let them know, YOU PAY FOR THE TAXI.
Do NOT be late with the Flexcar.
On the upside, if you *know* you're going to be late, then you can call in and let them know. Then they can warn the next member, or send a taxi to take them to another car. Much cheaper than sending a taxi to take them on their whole trip.
Of course, if it totally isn't your fault (accident, car breakdown, etc) Flexcar takes pretty good care of you. I was late with a car once because I had taken my wife to the hospital in it (a deep cut -- needed to be examined, but not ambulance worthy). They worked with the next person, and got it taken care of.
I've been a Flexcar member and car-free (in Seattle) for four years. It's great. I've only paid taxi fees a couple of times, they were about $40 or so. Ultimately, not a big deal. And even with the fees, waaay cheaper than owning a car.
Or rained-on, or frozen, or snowed-on. And can shower/warm up/treat frostbite at work.
Bikes are nice, but they're not an ultimate solution in most of the country. Think Minneapolis. Think Denver. Hell, it's cold enough in Seattle that only the hard-core greens bike year round. Even then it only works if you have shower facilities at work.
-Zipwow
First, it's scaling pretty well already. Second, if you find that Comic Book Guy did God Knows What in the back seat, you call the 24-hour number. They fine Comic Book Guy $200, pay you $20 for your inconvenience. Then they get you a taxi to another car, or you use the taxi itself for your trip. Which Comic Book Guy also pays for.
Go read the site at flexcar, it's pretty well thought-out.
-Zipwow
Perhaps you missed the part in your basic geography classes where they call those flat middle states the "high plains"?
Kansas (where I'm from) has an average elevation of 2000 feet (cite). As you may know, it's not a state well known for wide variances in elevation.
Not too likely to be disappearing. Tell us about your PhD again?
-Zipwow
Condorcet doesn't have this problem. It seems to make a lot of sense, but I haven't looked into all the tie-resolution methods.
-Zipwow
First, there is more than one car on the system. If you have more than three, take extra cars.
But why three, and not four, or five? The reason I've read in the past is this:
Three is the smallest number of occupants that guarantees that no members of a group need to ride alone.
If the cars held two, and your group of three arrived, then someone would have to ride by themselves. Not fun, and socially difficult.
It's true that if the cars held four, the same system would work (five people go in three and two). There is, however, significant expense to adding another passenger space. You'd either have to make them wider. This would increase the space between the railings, and the overall construction cost in addition to the car cost. You could add another row of seats, but that would increase the complexity and cost of the car.
Three is the right number.
-Zipwow