Something tells me Oracle's recommended practice is to have it running on it's own box (the same is true of MS SQL, BTW... it'll also chew up all physical memory in its default configuration).
Again, it's all about the expected operating environment. To you expect to have to play with others, or do you expect to have the box all to yourself? If the latter, then by all means, chew up all the memory if it'll allow you to perform tasks more quickly. A web browser, OTOH, obviously must be a little more careful.
So IMHO the only way we are going to get real competition is to go eminent domain on them. They have used our public right of way to run their cables, we paid them billions of dollars in tax breaks for nationwide high speed and got nothing but the finger, it is time to take it back.
Uhoh... yeah, that ain't gonna work. That's pinko hippy communist talk, and as we all know, that way leads Stalinistic purges. And honestly, given the choice between shitty broadband and Stalinistic purges, which would you prefer? Huh?? Yeah, I thought so... now bend over.
That's no different than saying "spam isn't a problem, my spam filters get almost all of it".
Actually, it's very different. When a jerk sends spam, they suck up resources within the network, where it must be transmitted, and on the servers and clients, where it must be stored and filtered.
Annoying popups and rollovers, on the other hand, may never be downloaded at all (thanks to NoScript), meaning no waste, other than the extra bit of javascript that's downloaded but never executed. And even if the content is downloaded but just not shown (as is sometimes the case with AdBlock and similar tools), it's a fairly small amount of extra crap, so it's not a lot of extra expense... and the lions share of that expense is actually paid by the provider of the content (who must serve all those page views), rather than the user viewing said content.
There is so much nonsense on the internet about Scientology, all of which was written by anti-religion extremists in the employ of the Psychiatric-Pharmaceutical industry. Many are also being paid by certain depraved, degenerate factions within the German government. You can't believe any of it. If these scumbags had their way, all children would be psych-drugged into oblivion, most eventually becoming high school gunmen; vicious de-programmers would constantly be leaping out from shadowy corners; there would be all-night electroshock parlors on the high street of every village, town and city; and anyone who tried to live an ethical life would quickly receive an icepick lobotomy.
Wow... way to make your case, there. Nope... not crazy at all. Now, where'd I put that icepick...
Make developers target a slow and memory constrained platform. Then you get stellar performance when it runs on the big machines.
Hardly. Have you never heard of space-time tradeoffs? ie, the most common compromise one has to make when selecting an algorithm for solving a problem? If you assume you have a highly constrained system, then you'll select an algorithm which will work within those constraints. That probably means selecting for space over time. Conversely, if you know you're working on a machine with multiple gigabytes of memory, you'll do the exact opposite.
In short: there's *nothing wrong with using resources at your disposal*. If your machine has lots of memory, and you can get better performance by building a large, in-memory cache, then by all means, do it! This is *not* the same as "bloat". It's selecting the right algorithm given your target execution environment.
I would be very disappointed with a 1.9.x version that was a beta of a 2.0 major break rather than an elegant expression of the 1.xx series.
And in the *real* world, no one actually does that. Hell, I never even implied that.
In the real world, KDE would've released a 4.0alpha, then a 4.0beta, then 4.0rc1, etc, etc, until 4.0 final was ready for release. You know, like the way the Linux kernel developers handle every single release they issue.
But I do expect to have to read the release notes on an x.0 release carefully.
And I never suggested otherwise, did I? No. What I said was that one *should* be able to expect a.0 release to be a) feature complete, and b) ready for general consumption. No other major software project that I can think of has released an x.0 while not intending it for general consumption. KDE broke the rules, no matter how much you may try to justify it.
KOffice makes it very clear that this is an early beta
Then *call it an early beta*! Jebus, how hard is it to label it "2.0 alpha", or "2.0rc1"? Honestly, how you can defend this is truly baffling to me.
How many projects use even numbers for unstable releases and odd numbers for end-user oriented releases? I think a fair number do that.
Umm... so? KDE isn't versioned that way. They have a two digit system. What KDE did is equivalent to a project like the one you describe releasing a 1.4.0, when it was really a 1.3.99... a feature-incomplete 1.3.99, no less.
What... you'd rather the US government got out of the business of border security? Wow. Even the craziest right-wing loonies admit that the government's job is to protect the borders...
It did until KDE decided to change the definition. But yeah, you're right, I'm sure all the users who bitched about KDE4 were just confused about what "4.0" actually meant (ie, "it's not really done but we're gonna pretend it's done so that we can finally say we got KDE4 out the door, and then when people complain we'll tell them it's a.0 release, and it's their own fault for not realizing that we really meant it was a preview release of an incomplete product").
The issue isn't stability. KDE 4 was quite stable in my experience. The issue is feature completeness.
That's splitting hairs. KDE 4 was incomplete. Period. It could not serve as a sufficient replacement for KDE 3, and the damn well knew it when they released it. It was *not* ready for prime time. But the version number said, to all sane, normal people out there, that it was, and that was a gross error on their part.
A "beta" or "RC" product indicates instability, not feature incompleteness.
Bullshit. a.0 release says "This thing is ready for general consumption". A "beta" or "RC" says "this thing is *not* ready for the masses". Period. *Why* the product isn't ready is entirely tangential to the issue.
Hell, I would tend that, if the product isn't even feature complete, it doesn't even deserve the monicker "beta". A "beta" is typically near feature complete, but still undergoing polish and stabilization work. What KDE4 did was release an early preview, at best. How they could call that a.0 is completely baffling, as there we *major* features as yet unimplemented.
So... Tools that make it even easier to strip the content from people who've spent their free time running websites that are expensive, using their bandwidth to do so? How is this democratic? A democracy is about having a say in how a country (the web) is run, not having your say over individuals (websites).
So PVRs that skip commercials are undemocratic because the viewer is altering the content before they view it?
Not that KDE are the only one to do that... I remember when I used to use RedHat (around versions 5 to 7) and as a rule of thumb you would have to wait to.1 or.2 to actually have a not so broken, usable version.
Yes, *but*... RedHat didn't put their.0 version out there with the caveat that, oh, by the way, this thing will be unstable, so normal users probably shouldn't actually use it.
Again, should you expect a few bugs in.0 releases? Yes, of course. But a.0 release says to the world that the product is ready for the masses. If that ain't true (as was the case with KDE4), *don't stick a fucking.0 release out there*. Call it what it is, a beta, or a release candidate.
I appreciate your opinion, and I even understand your point of view. Do you understand that releasing software may be something that is not just for your benefit? There are integrators, developers and others that need this release.
What the hell do you think alpha and beta releases are for, exactly?
Not sure where you got the impression that a.0 version is a final "please use this for your mission critical work". That has never been true and nobody every claimed it to be the case.
Huh. Sorry, that's complete bullshit. While everyone knows that a.0 version may have bugs, it's also expected that a.0 version *will* be ready for prime time. If it's not, it should have an alpha or beta moniker.
It's simple: KDE fucked up. Big time. And KOffice seems to be doing the exact same god damned thing. Thanks a lot KDE. Thank you very much. Way to ensure that no user will be able to tell if a given version of a product is actually a version they can trust.
That's not really usability though but merely productivity. I don't disagree that keyboard shortcuts and applications based on them (and in fact command line OS' vs. GUI OS' even) can allow you to be far more productive, but they are certainly less usable as usability is really defined as how easily you can use something without such prior knowledge.
Sure, but you should ask yourself something: should power tools, such as code editors, etc, focus on being usable, or being productive? Personally, I would argue that, because these tools are directed at professionals whose ultimate goal is to be productive, it's better to create a powerful tool with a steep learning curve than an easy-to-use tool that gets in the way.
Or, to put it another way: IMHO, when evaluating any development tool, "usability" should *not* be the first item on the list.
'course, I'm also a huge fan of Git, which is the SCM equivalent of vi or emacs.:)
One might argue then that they're extreme examples of productivity over usability, but I'm not convinced this is the case, I believe it's possible for an application to be both usable and be great in terms of productivity. Vi and Emacs are the way they are because it's the way they've always been, not because they've undergone studies in usability and been rehashed based on that. They just offer improvements in productivity on the classic design.
I disagree. Vi and Emacs are the way they are because developers decided that that's how they wanted to work, and could work most productively. I mean, those tools have been around for 30 or more years, now... and they've stood the test of time. I think that says something for their underlying design.
Now, can a tool be both usable and productive? Honestly... I'm not convinced. The best applications in their fields, be it FrameMaker or Photoshop or AutoCAD or <insert favorite product here> have one thing in common: they take a long time to become productive in. Similarly, Emacs, for example, can easily be used without knowing anything about it's more powerful features. But to *truly* use it, you've gotta take the time to learn it.
'course, in the case of Vim, you probably have a point... it's, to say the least, esoteric. It just happens to be esoteric in a way I like.:)
In short, is it possible to have a tool be both usable and powerful/productive? Perhaps. But I certainly can't think of an example off the top of my head. Can you?
As for the rest, personally, I've never viewed the free software "movement" as any kind of mission, and, frankly, I find those who do... amusing. Personally, rather than wasting time worrying about world dominance I'd rather spend my time doing what I do best: writing code.
I agree, that's a serious moderation injustice. Coming from Canada (Edmonton Alberta, the northernmost North American city with a population >1M... woo!), I completely agree... in the dead of winter, a good blanket of snow on the roof is a very good thing. But the summers... jebus, I'd give anything for a nice, highly reflective roof.
Maybe we like having black roofs and roads to melt the snow faster if there's a little opening?
Speaking as someone who lives around the 53rd parallel, dibs out. Snow melting prematurely on my roof means the danger of ice jams, which means water backing up under the shingles and causing all sorts of havoc. Hell, we go out of our way, around here, to ensure our roofs are properly vented so that warm air escapes the attic and doesn't melt snow cover from beneath.
As for roads, a combination of plowing, sheer traffic volume, and in some areas, salting, will do far more to keep roads clear than a little blacktop. Once again, speaking from experience, around here, the roads that are clear during the winter are ones that are cleared off, and frequently driven on. After all, once the snow is down, unless something removes, it, no sunlight will hit the blacktop to heat it up in the first place.
Hell, a road surface that discourages partial melting might even be a good thing... or have you never hit a patch of black ice?
Well, I gotta tell ya, that approach to development is, to say the least, strange to me. Personally, when developing new code, most of the time I already know what functions I need thanks to my up-front design work (whether that be on paper or simply in my head), so I stub them out right away. The rest of the time, I just write the stubs as I need them.
Frankly, the approach you describe sounds... ad hoc. I can certainly see writing code that way in limited cases, but generally speaking, it strikes me as a bad approach to problem solving, as it would seem to encourage a design-as-you're-coding mentality. And the last thing I'd want is an IDE which encourages such behaviour.
Thanks for the response! Sounds like what I expected... it ties a lot of tools together in a nice package, and adds a lot of convenience features (like code completion)... nothing that can't be done with Vim/Emacs and related tools, of course, but probably better tied up in a single package (which matches pretty well my experiences with VS).
On this particular point, though:
By large my favorite feature is the snapshot. No need to commit to my repository until I ready. If I want to try a major risky change I can just snapshot with a single click and roll back if it really gets screwed up.
Now, obviously if you're in a corporate setting, your toolset is more or less dictated for you, but if you're working on person projects, or if your company is uses SVN and you have the flexibility to use your own tools, I'd strongly suggest you check out git (assuming you haven't already done so). Forget snapshotting, imagine being able to arbitrarily, at will, create new temporary branches for experimenting with new work. Bug comes along that you need to fix? No biggie, commit to your working tree, switch back to the primary, fix the bug, commit, then go back to what you're doing. It puts the full power of branching and merging right at your fingertips, and makes those operations *cheap*.
If your company uses SVN, you can even use Git as a front-end to SVN (this is how I work... VS2k5 + Git for Windows development). You can do all your work in your local repo, and when you're ready to publish your work to the corporate SCM, you just push your changes upstream. It really is a revelation after working with SVN/CVS for years.
Of course, you do sacrifice SCM integration with your IDE. But, IMHO, it's a worthwhile tradeoff.
Don't be silly. If I've already written the return type, the method name and the types and names of the arguments elsewhere, why would I type them again to implement the method when I can get all that plus an impossible-to-miss note reminding me that the method is a stub with a single button press?
Wait, what? Assuming I'm reading you right (and I might not be... I've never used this code clippy thinger before), who the hell writes code that calls a method before stubbing it out first?
.I make use of those all the time. Necessary? No, but then hardly anything is. Convenient, definitely, but more than that, essential to proving that a modification to code has been done correctly.
Not usually, actually. 99% of the time, a rename done improperly will result in a broken compile. Which is probably why I've never gotten around to using the refactoring tools... I just end up doing the rename, fire up a quick test compile of the file/sub-project/project I'm working on, and then fix the few remaining errors the compiler caught.
And unlike Clippy, quick fixes are shown when you request them and poignant,
Because you can't figure out those things on your own?
You know, normally, I don't bemoan people's use of IDEs. Use the tool that suits you. But if you really need your IDE to tell you to "create this method/class", honestly, you're using your IDE as a crutch, and that's a very bad sign, IMHO.
A lot. When you work on projects that are less than perfectly coupled, this moves from handy to necessary.
I guess I've just been lucky, then.:)
This will find all structural links to that method in all open project that reference my editing project. Each and every reference to the method will get the name change, and life moves on. Through the command line, you could be spending days search/replacing every possible reference to the method in 100 files.
Or you rename the method, let the compiler catch the errors, and then fix them (of course I'd start with a search/replace first, and let the compiler catch the remaining cases).
Again, for the number of times I actually have to do this, it hardly seems like a killer feature for "real" IDEs. And, if push came to shove, you could always use a standalone refactoring tool (which will likely be as good or better than similar tools integrated into your average IDE).
Personally I just think the layout and UI is better with XCode. I am not a frequent coder and I was able to get up and moving MUCH faster with XCode than I was able to with VS2k5. That isn't to say that VS is bad.
I'm actually more interested in what XCode offers over, say, a Vim or Emacs-type environment. The GP said that, after years working with Vim, XCode "blew" his mind... but my experience with IDEs is that, while they provide some handy features, there's nothing in them that I truly couldn't live without. So either I'm missing something in these IDEs, or the GP was missing something in Vim (or he/she's easily impressed:) ).
If someone just wants to build Windows apps then Visual Studio is far and away the quickest and easiest way to do that.
It's certainly hard to deny that. After all, the Mono folks are basically building a clone of VS as MonoDevelop... they wouldn't be doing that if they didn't realize VS was doing *something* right.
Really, it comes down to the right tool for the job. If I'm working on a Unix application, I prefer good ol' GNU Screen, Vim, Git, and a plethora of command-line tools (grep and sed, gdb, etc). But if I'm working in the Windows world, it's hard to argue that VS isn't the best tool for the job (though I like to marry it with a Cygwin environment so I can still use Git and grep, sed, perl, etc).
Asking people to give up usability and productivity for some moral stance is going to be about as easy as getting blood out of stone.
Here I have to argue a bit, though. Vim and Emacs aren't "usable", in the sense that a neophyte can come to them and immediately become productive. Rather, they're "usable" in the sense that, like driving stick, it requires time and practices to become used to them, but once you've crested the steep learning curve, they become extremely productive power tools.
That said, on Windows, where you need to build GUIs using the *horrible* Windows layout model, and need to build out installers and so forth the Windows way, the integrated tools in VS just make it that much more useful. But I think that's as much a function of the Windows ecosystem itself, rather than the inherent superiority of VS as a development environment.
Meh, all handy little features, none of them necessary.
Does it refactor methods signatures?
How often do you do that, really? Hell, I have that in VS and I still never use it.
Update import statements when copy-pasting code from an other class?
Again, never needed it.
Generate hashCode() and equals()?
Emacs and Vim can both be set up to support templates, so it can be done. Besides, this is just boilerplate... again, convenient, but by no means necessary.
Extract a method from a block of code?
Vim: da{, type in method signature, p
No idea about Emacs. Again, convenient? Yes. Necessary? Hardly.
Rename methods, classes, fields or local variables?
Again, how often do you really do this that a simple search/replace in the current file won't be sufficient? Once again, I have this feature in VS... I never use it.
Inline methods?
Uh, that's the compiler/VM's job.
Suggest quick fixes?
Good Christ, I'll be damned if I want Clippy in my VM. Thanks but no thanks.:)
Slashdot Mirror
Something tells me Oracle's recommended practice is to have it running on it's own box (the same is true of MS SQL, BTW... it'll also chew up all physical memory in its default configuration).
Again, it's all about the expected operating environment. To you expect to have to play with others, or do you expect to have the box all to yourself? If the latter, then by all means, chew up all the memory if it'll allow you to perform tasks more quickly. A web browser, OTOH, obviously must be a little more careful.
So IMHO the only way we are going to get real competition is to go eminent domain on them. They have used our public right of way to run their cables, we paid them billions of dollars in tax breaks for nationwide high speed and got nothing but the finger, it is time to take it back.
Uhoh... yeah, that ain't gonna work. That's pinko hippy communist talk, and as we all know, that way leads Stalinistic purges. And honestly, given the choice between shitty broadband and Stalinistic purges, which would you prefer? Huh?? Yeah, I thought so... now bend over.
That's no different than saying "spam isn't a problem, my spam filters get almost all of it".
Actually, it's very different. When a jerk sends spam, they suck up resources within the network, where it must be transmitted, and on the servers and clients, where it must be stored and filtered.
Annoying popups and rollovers, on the other hand, may never be downloaded at all (thanks to NoScript), meaning no waste, other than the extra bit of javascript that's downloaded but never executed. And even if the content is downloaded but just not shown (as is sometimes the case with AdBlock and similar tools), it's a fairly small amount of extra crap, so it's not a lot of extra expense... and the lions share of that expense is actually paid by the provider of the content (who must serve all those page views), rather than the user viewing said content.
Wow... way to make your case, there. Nope... not crazy at all. Now, where'd I put that icepick...
Make developers target a slow and memory constrained platform. Then you get stellar performance when it runs on the big machines.
Hardly. Have you never heard of space-time tradeoffs? ie, the most common compromise one has to make when selecting an algorithm for solving a problem? If you assume you have a highly constrained system, then you'll select an algorithm which will work within those constraints. That probably means selecting for space over time. Conversely, if you know you're working on a machine with multiple gigabytes of memory, you'll do the exact opposite.
In short: there's *nothing wrong with using resources at your disposal*. If your machine has lots of memory, and you can get better performance by building a large, in-memory cache, then by all means, do it! This is *not* the same as "bloat". It's selecting the right algorithm given your target execution environment.
I would be very disappointed with a 1.9.x version that was a beta of a 2.0 major break rather than an elegant expression of the 1.xx series.
And in the *real* world, no one actually does that. Hell, I never even implied that.
In the real world, KDE would've released a 4.0alpha, then a 4.0beta, then 4.0rc1, etc, etc, until 4.0 final was ready for release. You know, like the way the Linux kernel developers handle every single release they issue.
But I do expect to have to read the release notes on an x.0 release carefully.
And I never suggested otherwise, did I? No. What I said was that one *should* be able to expect a .0 release to be a) feature complete, and b) ready for general consumption. No other major software project that I can think of has released an x.0 while not intending it for general consumption. KDE broke the rules, no matter how much you may try to justify it.
KOffice makes it very clear that this is an early beta
Then *call it an early beta*! Jebus, how hard is it to label it "2.0 alpha", or "2.0rc1"? Honestly, how you can defend this is truly baffling to me.
How many projects use even numbers for unstable releases and odd numbers for end-user oriented releases? I think a fair number do that.
Umm... so? KDE isn't versioned that way. They have a two digit system. What KDE did is equivalent to a project like the one you describe releasing a 1.4.0, when it was really a 1.3.99... a feature-incomplete 1.3.99, no less.
What... you'd rather the US government got out of the business of border security? Wow. Even the craziest right-wing loonies admit that the government's job is to protect the borders...
I think a lot of things in those days were built without a really good understanding of engineering, so things were typically over-engineered.
Two words: Survivorship Bias
It did until KDE decided to change the definition. But yeah, you're right, I'm sure all the users who bitched about KDE4 were just confused about what "4.0" actually meant (ie, "it's not really done but we're gonna pretend it's done so that we can finally say we got KDE4 out the door, and then when people complain we'll tell them it's a .0 release, and it's their own fault for not realizing that we really meant it was a preview release of an incomplete product").
The issue isn't stability. KDE 4 was quite stable in my experience. The issue is feature completeness.
That's splitting hairs. KDE 4 was incomplete. Period. It could not serve as a sufficient replacement for KDE 3, and the damn well knew it when they released it. It was *not* ready for prime time. But the version number said, to all sane, normal people out there, that it was, and that was a gross error on their part.
A "beta" or "RC" product indicates instability, not feature incompleteness.
Bullshit. a .0 release says "This thing is ready for general consumption". A "beta" or "RC" says "this thing is *not* ready for the masses". Period. *Why* the product isn't ready is entirely tangential to the issue.
Hell, I would tend that, if the product isn't even feature complete, it doesn't even deserve the monicker "beta". A "beta" is typically near feature complete, but still undergoing polish and stabilization work. What KDE4 did was release an early preview, at best. How they could call that a .0 is completely baffling, as there we *major* features as yet unimplemented.
So... Tools that make it even easier to strip the content from people who've spent their free time running websites that are expensive, using their bandwidth to do so? How is this democratic? A democracy is about having a say in how a country (the web) is run, not having your say over individuals (websites).
So PVRs that skip commercials are undemocratic because the viewer is altering the content before they view it?
Interesting...
Not that KDE are the only one to do that... I remember when I used to use RedHat (around versions 5 to 7) and as a rule of thumb you would have to wait to .1 or .2 to actually have a not so broken, usable version.
Yes, *but*... RedHat didn't put their .0 version out there with the caveat that, oh, by the way, this thing will be unstable, so normal users probably shouldn't actually use it.
Again, should you expect a few bugs in .0 releases? Yes, of course. But a .0 release says to the world that the product is ready for the masses. If that ain't true (as was the case with KDE4), *don't stick a fucking .0 release out there*. Call it what it is, a beta, or a release candidate.
I appreciate your opinion, and I even understand your point of view. Do you understand that releasing software may be something that is not just for your benefit? There are integrators, developers and others that need this release.
What the hell do you think alpha and beta releases are for, exactly?
Not sure where you got the impression that a .0 version is a final "please use this for your mission critical work". That has never been true and nobody every claimed it to be the case.
Huh. Sorry, that's complete bullshit. While everyone knows that a .0 version may have bugs, it's also expected that a .0 version *will* be ready for prime time. If it's not, it should have an alpha or beta moniker.
It's simple: KDE fucked up. Big time. And KOffice seems to be doing the exact same god damned thing. Thanks a lot KDE. Thank you very much. Way to ensure that no user will be able to tell if a given version of a product is actually a version they can trust.
That's not really usability though but merely productivity. I don't disagree that keyboard shortcuts and applications based on them (and in fact command line OS' vs. GUI OS' even) can allow you to be far more productive, but they are certainly less usable as usability is really defined as how easily you can use something without such prior knowledge.
Sure, but you should ask yourself something: should power tools, such as code editors, etc, focus on being usable, or being productive? Personally, I would argue that, because these tools are directed at professionals whose ultimate goal is to be productive, it's better to create a powerful tool with a steep learning curve than an easy-to-use tool that gets in the way.
Or, to put it another way: IMHO, when evaluating any development tool, "usability" should *not* be the first item on the list.
'course, I'm also a huge fan of Git, which is the SCM equivalent of vi or emacs. :)
One might argue then that they're extreme examples of productivity over usability, but I'm not convinced this is the case, I believe it's possible for an application to be both usable and be great in terms of productivity. Vi and Emacs are the way they are because it's the way they've always been, not because they've undergone studies in usability and been rehashed based on that. They just offer improvements in productivity on the classic design.
I disagree. Vi and Emacs are the way they are because developers decided that that's how they wanted to work, and could work most productively. I mean, those tools have been around for 30 or more years, now... and they've stood the test of time. I think that says something for their underlying design.
Now, can a tool be both usable and productive? Honestly... I'm not convinced. The best applications in their fields, be it FrameMaker or Photoshop or AutoCAD or <insert favorite product here> have one thing in common: they take a long time to become productive in. Similarly, Emacs, for example, can easily be used without knowing anything about it's more powerful features. But to *truly* use it, you've gotta take the time to learn it.
'course, in the case of Vim, you probably have a point... it's, to say the least, esoteric. It just happens to be esoteric in a way I like. :)
In short, is it possible to have a tool be both usable and powerful/productive? Perhaps. But I certainly can't think of an example off the top of my head. Can you?
As for the rest, personally, I've never viewed the free software "movement" as any kind of mission, and, frankly, I find those who do... amusing. Personally, rather than wasting time worrying about world dominance I'd rather spend my time doing what I do best: writing code.
I agree, that's a serious moderation injustice. Coming from Canada (Edmonton Alberta, the northernmost North American city with a population >1M... woo!), I completely agree... in the dead of winter, a good blanket of snow on the roof is a very good thing. But the summers... jebus, I'd give anything for a nice, highly reflective roof.
Maybe we like having black roofs and roads to melt the snow faster if there's a little opening?
Speaking as someone who lives around the 53rd parallel, dibs out. Snow melting prematurely on my roof means the danger of ice jams, which means water backing up under the shingles and causing all sorts of havoc. Hell, we go out of our way, around here, to ensure our roofs are properly vented so that warm air escapes the attic and doesn't melt snow cover from beneath.
As for roads, a combination of plowing, sheer traffic volume, and in some areas, salting, will do far more to keep roads clear than a little blacktop. Once again, speaking from experience, around here, the roads that are clear during the winter are ones that are cleared off, and frequently driven on. After all, once the snow is down, unless something removes, it, no sunlight will hit the blacktop to heat it up in the first place.
Hell, a road surface that discourages partial melting might even be a good thing... or have you never hit a patch of black ice?
Well, I gotta tell ya, that approach to development is, to say the least, strange to me. Personally, when developing new code, most of the time I already know what functions I need thanks to my up-front design work (whether that be on paper or simply in my head), so I stub them out right away. The rest of the time, I just write the stubs as I need them.
Frankly, the approach you describe sounds... ad hoc. I can certainly see writing code that way in limited cases, but generally speaking, it strikes me as a bad approach to problem solving, as it would seem to encourage a design-as-you're-coding mentality. And the last thing I'd want is an IDE which encourages such behaviour.
Thanks for the response! Sounds like what I expected... it ties a lot of tools together in a nice package, and adds a lot of convenience features (like code completion)... nothing that can't be done with Vim/Emacs and related tools, of course, but probably better tied up in a single package (which matches pretty well my experiences with VS).
On this particular point, though:
By large my favorite feature is the snapshot. No need to commit to my repository until I ready. If I want to try a major risky change I can just snapshot with a single click and roll back if it really gets screwed up.
Now, obviously if you're in a corporate setting, your toolset is more or less dictated for you, but if you're working on person projects, or if your company is uses SVN and you have the flexibility to use your own tools, I'd strongly suggest you check out git (assuming you haven't already done so). Forget snapshotting, imagine being able to arbitrarily, at will, create new temporary branches for experimenting with new work. Bug comes along that you need to fix? No biggie, commit to your working tree, switch back to the primary, fix the bug, commit, then go back to what you're doing. It puts the full power of branching and merging right at your fingertips, and makes those operations *cheap*.
If your company uses SVN, you can even use Git as a front-end to SVN (this is how I work... VS2k5 + Git for Windows development). You can do all your work in your local repo, and when you're ready to publish your work to the corporate SCM, you just push your changes upstream. It really is a revelation after working with SVN/CVS for years.
Of course, you do sacrifice SCM integration with your IDE. But, IMHO, it's a worthwhile tradeoff.
Don't be silly. If I've already written the return type, the method name and the types and names of the arguments elsewhere, why would I type them again to implement the method when I can get all that plus an impossible-to-miss note reminding me that the method is a stub with a single button press?
Wait, what? Assuming I'm reading you right (and I might not be... I've never used this code clippy thinger before), who the hell writes code that calls a method before stubbing it out first?
.I make use of those all the time. Necessary? No, but then hardly anything is. Convenient, definitely, but more than that, essential to proving that a modification to code has been done correctly.
Not usually, actually. 99% of the time, a rename done improperly will result in a broken compile. Which is probably why I've never gotten around to using the refactoring tools... I just end up doing the rename, fire up a quick test compile of the file/sub-project/project I'm working on, and then fix the few remaining errors the compiler caught.
And unlike Clippy, quick fixes are shown when you request them and poignant,
Because you can't figure out those things on your own?
You know, normally, I don't bemoan people's use of IDEs. Use the tool that suits you. But if you really need your IDE to tell you to "create this method/class", honestly, you're using your IDE as a crutch, and that's a very bad sign, IMHO.
A lot. When you work on projects that are less than perfectly coupled, this moves from handy to necessary.
I guess I've just been lucky, then. :)
This will find all structural links to that method in all open project that reference my editing project. Each and every reference to the method will get the name change, and life moves on. Through the command line, you could be spending days search/replacing every possible reference to the method in 100 files.
Or you rename the method, let the compiler catch the errors, and then fix them (of course I'd start with a search/replace first, and let the compiler catch the remaining cases).
Again, for the number of times I actually have to do this, it hardly seems like a killer feature for "real" IDEs. And, if push came to shove, you could always use a standalone refactoring tool (which will likely be as good or better than similar tools integrated into your average IDE).
Personally I just think the layout and UI is better with XCode. I am not a frequent coder and I was able to get up and moving MUCH faster with XCode than I was able to with VS2k5. That isn't to say that VS is bad.
I'm actually more interested in what XCode offers over, say, a Vim or Emacs-type environment. The GP said that, after years working with Vim, XCode "blew" his mind... but my experience with IDEs is that, while they provide some handy features, there's nothing in them that I truly couldn't live without. So either I'm missing something in these IDEs, or the GP was missing something in Vim (or he/she's easily impressed :) ).
If someone just wants to build Windows apps then Visual Studio is far and away the quickest and easiest way to do that.
It's certainly hard to deny that. After all, the Mono folks are basically building a clone of VS as MonoDevelop... they wouldn't be doing that if they didn't realize VS was doing *something* right.
Really, it comes down to the right tool for the job. If I'm working on a Unix application, I prefer good ol' GNU Screen, Vim, Git, and a plethora of command-line tools (grep and sed, gdb, etc). But if I'm working in the Windows world, it's hard to argue that VS isn't the best tool for the job (though I like to marry it with a Cygwin environment so I can still use Git and grep, sed, perl, etc).
Asking people to give up usability and productivity for some moral stance is going to be about as easy as getting blood out of stone.
Here I have to argue a bit, though. Vim and Emacs aren't "usable", in the sense that a neophyte can come to them and immediately become productive. Rather, they're "usable" in the sense that, like driving stick, it requires time and practices to become used to them, but once you've crested the steep learning curve, they become extremely productive power tools.
That said, on Windows, where you need to build GUIs using the *horrible* Windows layout model, and need to build out installers and so forth the Windows way, the integrated tools in VS just make it that much more useful. But I think that's as much a function of the Windows ecosystem itself, rather than the inherent superiority of VS as a development environment.
Meh, all handy little features, none of them necessary.
Does it refactor methods signatures?
How often do you do that, really? Hell, I have that in VS and I still never use it.
Update import statements when copy-pasting code from an other class?
Again, never needed it.
Generate hashCode() and equals()?
Emacs and Vim can both be set up to support templates, so it can be done. Besides, this is just boilerplate... again, convenient, but by no means necessary.
Extract a method from a block of code?
Vim: da{, type in method signature, p
No idea about Emacs. Again, convenient? Yes. Necessary? Hardly.
Rename methods, classes, fields or local variables?
Again, how often do you really do this that a simple search/replace in the current file won't be sufficient? Once again, I have this feature in VS... I never use it.
Inline methods?
Uh, that's the compiler/VM's job.
Suggest quick fixes?
Good Christ, I'll be damned if I want Clippy in my VM. Thanks but no thanks. :)