I have to say, for such a long post, you got quite a bit wrong. While I agree with you that current default implementations of Visual Studio would be greatly improved with some refactoring/generation capabilities, there are two important things you left out: 1) there are third-party refactoring tools available for Visual Studio that, frankly, rock, and 2) refactoring support will be available with the new version of Visual Studio due out next month. Written, in fact, by one of those third-party vendors I mentioned.
So what if you don't like the Object Browser? Others find it a very useful tool. If you don't, you don't have to use it, now do you?
Fact: Incremental compilation is already available in Visual Studio.
Now, I'll grant you that Visual Studio only supports VSIP for source control, but there are tons of third-party plugins available for
As for import organization... It's not really that important. Yes, it's a neat feature of Eclipse, one that certainly helps reduce namespace clutter, but it's gravy, not meat.
Separation of concerns (code in your presentation layer) is a design issue, not a language issue. Calling PHP a bad language because you can put code in your presentation layer is like calling water bad because you can drown in it.
Yeah, um... I'm gonna have to go ahead and disagree with you there.
I have pretty much the same story to tell as the grandparent... except I won't post anonymously!;)
Like the grandparent post, I loved java (in my case, AWT) when I first got into GUI programming, but when I finally tried C# and.NET I got hooked, but good. I love to code C# in general, and I love to code GUIs in.NET. (Note: I haven't tried to code in.NET 2.0 or Java 1.5 yet, so no comments on generics or partial classes yet)
And it's not that I happen to have a good drag/drop GUI editor, although that comes in very handy at times; I very often code custom controls and the like by hand, i.e. outside the Designer. No, it's that Windows.Forms frankly kicks Swing's ass, hands down. It's simply a better designed API. And that's not all -- delegates really *are* better than anonymous inner classes. They're easier to use and don't clutter your code like writing an anonymous inner class does. And it's either clutter your code with an AIC or implement ActionListener (for example) clutter your code with a switch statement to figure out which button was pushed. Off a string value, no less. Oh, wait... you can't run a switch on a String in Java can you? I almost forgot that one. I guess C# rots your brain.
Er... got sidetracked. Where was I? Oh, yes. GUI designers and property pages might make development a lot easier, but Swing is still flawed, and.NET's delegates make for a better event model (Sun should have adopted delegates when Microsoft made 'em for Visual J++, rather than play politics).
Anyway, that's C#/.NET vs. Java on a Windows platform. Obvously, Windows.Forms isn't available in Mono. Although it *should* be.
Nobody won, the war just died when most DVD players started supporting both. Which, IMO, is what should happen with the next-gen DVD stuff as well. Manufacturers should support both formats and let the war fizzle.
Well, I've only geocached a few times (I borrowed a friend's GPS, then lost access to it when I moved), but I have to say it's a blast. All you really need is a GPS and some comfortable hiking clothes, but it helps to a wireless internet connection device of some sort with you if you want to do more than one on a trip. Although printing my destinations out before a trip worked for me.
Wait.... you mean Archer doesn't get split into a million pieces at the end of the show, only to have every piece eaten by a gross helium-farting alien and then revived from his vomit in a special mini-series?
The purpose of copyright is artistic preservation, to ensure that the artist who created a work of art is properly credited for his/her creation. Songs (lyrics or music) may be copyrighted. Poems, stories, articles, essays, movies, sculptures, paintings, all these may be copyrighted.
Unfortunately, the purpose of copyright has been twisted by corporate greed to the point where it has become almost like a patent.
Seriously. Comments are important, but don't make the mistake of overcommenting. Comments should, as a rule of thumb, only be used when what you are doing is not particularly clear from the context of the code. Comment functions and methods so that a person reading your code knows what they do. Comment variables and attributes so that a person reading your code knows what they're for or what they represent. Comment key turning points in your code, or perhaps algorithmic sections. Do not comment every damn statement! You don't know how many times I've seen code like
/* Print "Welcome to the main program!" to the console */ printf("Welcome to the main program!");
That's an extremely contrived example, but I *have* seen code where *every* step was commented just like that. That woud be great if it were an explaination of the reasons behind some complex algorithm, but more often it's just a rehash of what's obvious from the statment itself.
The more I think that maybe you should consider offering APIs for *both* languages. Why tie your API to one platform?
You could even consider a multi-tiered approach: create a.dll or.so written in C (or whatever language you use for the driver), and create wrappers in both Java and.NET. You could even create a (shudder) COM wrapper as well, so the VB6 folks could jump in.
Er... I highly doubt they are looking at either Swing or Win.Forms. They're mostly interested in the I/O API. Did you watch the video? They go some cool stuff in there.
Seriously, both offer a very rich IO API, and they're both quite mature, despite C#'s "newness". The syntax of both are roughly similar, keywords and C#'s "property" syntax notwithstanding. What you can do with one language, you can do with the other, no problems.
My personal preference is C#, simply because I enjoy the property syntax and delegates, both of which Java does not offer. Plus I'd rather code in Windows.Forms than Swing any day of the week. But you're not doing desktop GUIs, are you? Anyway, you can do the same stuff in Java using the Bean specification for properties and interfaces rather than delegates, though, so don't get me wrong. If you prefer that platform, go that route. Java also offers cross-platform compatibility, which is a plus if you plan to use *nix over WinXP.
But that whole paragraph was trivial. The bottom line is that what matters is whatever your programmers feel most comfortable programming with.
BTW, I saw the video.... am I the only one thinking about using it for table-top gaming? Add this to my list of things to put in my Ultimate Gaming Room (tm) if/when I get the time/money to create one.
I was gonna mention Dune 2, too, but on second thought I agree with the grandparent post. Dune 2 may have inspired Warcraft, but Warcraft did a helluva lot better than Dune 2 did.
There are two possible reasons you're using XML to transport your data from one database to the other.
The first is that you just heard XML is a great way to transport data, and decided to use it.
The second is that you're using the XML for more than just transporting data from one database to another; you're using it at some point with your application.
In either case, the bottom line is that XML is not good for you. If your data fits in a relational database, you should USE RELATIONAL MEANS TO ACCESS YOUR DATA. Don't use that nifty new XML reader to access your data. It's not nearly as fast or flexible as basic SQL; it's actually much more trouble than it's worth.
If you're just transporting data from one relational database server to another, use a flat file, or better yet raw SQL dumps. If you're accessing the data with an application, use SQL or the underlying API.
The only reason you *ever* need to use an XML database is when your data doesn't fit into a standard relational schema. In fact, if you try to fit standard data into an XML database, you're much more likely to end up with a ton of overhead, both in storage and speed.
Fortunately, non-relational data is extremely rare. So rare, in fact, that I've yet to see a non-contrived-proof-of-concept "real life" example.
You don't need to log changes as they occur, like a journalled fs does
I'd say it depends on the game. Some games, chess for example, might want to keep a history of moves. As such, saving the history might allow you to rebuild state without having to save it.
That said, it's almost always best, IMO, to save state *and* history (when you need to save history). Saving state along with history increases storage usage, but reduces load-time. It's a trade-off.
I can't claim to be the original author of the quote, but I've been tweaking the basic concept over the past few weeks... I think I'll change it to this:
"The problems with Christianity and D&D are essentially the same: too many rules lawyers."
Slashdot Mirror
I have to say, for such a long post, you got quite a bit wrong. While I agree with you that current default implementations of Visual Studio would be greatly improved with some refactoring/generation capabilities, there are two important things you left out: 1) there are third-party refactoring tools available for Visual Studio that, frankly, rock, and 2) refactoring support will be available with the new version of Visual Studio due out next month. Written, in fact, by one of those third-party vendors I mentioned.
So what if you don't like the Object Browser? Others find it a very useful tool. If you don't, you don't have to use it, now do you?
Fact: Incremental compilation is already available in Visual Studio.
Now, I'll grant you that Visual Studio only supports VSIP for source control, but there are tons of third-party plugins available for
As for import organization... It's not really that important. Yes, it's a neat feature of Eclipse, one that certainly helps reduce namespace clutter, but it's gravy, not meat.
Separation of concerns (code in your presentation layer) is a design issue, not a language issue. Calling PHP a bad language because you can put code in your presentation layer is like calling water bad because you can drown in it.
I was surprised to learn that there *was* still a retail market for computers.
Yeah, um... I'm gonna have to go ahead and disagree with you there.
;)
.NET I got hooked, but good. I love to code C# in general, and I love to code GUIs in .NET. (Note: I haven't tried to code in .NET 2.0 or Java 1.5 yet, so no comments on generics or partial classes yet)
.NET's delegates make for a better event model (Sun should have adopted delegates when Microsoft made 'em for Visual J++, rather than play politics).
I have pretty much the same story to tell as the grandparent... except I won't post anonymously!
Like the grandparent post, I loved java (in my case, AWT) when I first got into GUI programming, but when I finally tried C# and
And it's not that I happen to have a good drag/drop GUI editor, although that comes in very handy at times; I very often code custom controls and the like by hand, i.e. outside the Designer. No, it's that Windows.Forms frankly kicks Swing's ass, hands down. It's simply a better designed API. And that's not all -- delegates really *are* better than anonymous inner classes. They're easier to use and don't clutter your code like writing an anonymous inner class does. And it's either clutter your code with an AIC or implement ActionListener (for example) clutter your code with a switch statement to figure out which button was pushed. Off a string value, no less. Oh, wait... you can't run a switch on a String in Java can you? I almost forgot that one. I guess C# rots your brain.
Er... got sidetracked. Where was I? Oh, yes. GUI designers and property pages might make development a lot easier, but Swing is still flawed, and
Anyway, that's C#/.NET vs. Java on a Windows platform. Obvously, Windows.Forms isn't available in Mono. Although it *should* be.
Nobody won, the war just died when most DVD players started supporting both. Which, IMO, is what should happen with the next-gen DVD stuff as well. Manufacturers should support both formats and let the war fizzle.
Hay, come on know, don't loose your temperature!
Well, I've only geocached a few times (I borrowed a friend's GPS, then lost access to it when I moved), but I have to say it's a blast. All you really need is a GPS and some comfortable hiking clothes, but it helps to a wireless internet connection device of some sort with you if you want to do more than one on a trip. Although printing my destinations out before a trip worked for me.
Wait.... you mean Archer doesn't get split into a million pieces at the end of the show, only to have every piece eaten by a gross helium-farting alien and then revived from his vomit in a special mini-series?
Tsk.
The purpose of copyright is artistic preservation, to ensure that the artist who created a work of art is properly credited for his/her creation. Songs (lyrics or music) may be copyrighted. Poems, stories, articles, essays, movies, sculptures, paintings, all these may be copyrighted.
Unfortunately, the purpose of copyright has been twisted by corporate greed to the point where it has become almost like a patent.
That's an extremely contrived example, but I *have* seen code where *every* step was commented just like that. That woud be great if it were an explaination of the reasons behind some complex algorithm, but more often it's just a rehash of what's obvious from the statment itself.
The more I think that maybe you should consider offering APIs for *both* languages. Why tie your API to one platform?
.dll or .so written in C (or whatever language you use for the driver), and create wrappers in both Java and .NET. You could even create a (shudder) COM wrapper as well, so the VB6 folks could jump in.
You could even consider a multi-tiered approach: create a
This is *hardware* UI they're talking about. They're not talking about Swing or Win.Forms. They want to know which platform has the better I/O API.
Er... I highly doubt they are looking at either Swing or Win.Forms. They're mostly interested in the I/O API. Did you watch the video? They go some cool stuff in there.
Seriously, both offer a very rich IO API, and they're both quite mature, despite C#'s "newness". The syntax of both are roughly similar, keywords and C#'s "property" syntax notwithstanding. What you can do with one language, you can do with the other, no problems.
My personal preference is C#, simply because I enjoy the property syntax and delegates, both of which Java does not offer. Plus I'd rather code in Windows.Forms than Swing any day of the week. But you're not doing desktop GUIs, are you? Anyway, you can do the same stuff in Java using the Bean specification for properties and interfaces rather than delegates, though, so don't get me wrong. If you prefer that platform, go that route. Java also offers cross-platform compatibility, which is a plus if you plan to use *nix over WinXP.
But that whole paragraph was trivial. The bottom line is that what matters is whatever your programmers feel most comfortable programming with.
BTW, I saw the video.... am I the only one thinking about using it for table-top gaming? Add this to my list of things to put in my Ultimate Gaming Room (tm) if/when I get the time/money to create one.
I was gonna mention Dune 2, too, but on second thought I agree with the grandparent post. Dune 2 may have inspired Warcraft, but Warcraft did a helluva lot better than Dune 2 did.
:)
I loved 'em both, of course.
Other people might not get it, but I do!
A/S/L?
Hey, now, I never said MIDI sounded bad. *THAT* depends on your sound system and how good a composer you are.
:)
But it *is* a lossless format, so I stayed topical. Not quite good for ripping CDs, though, which is why I ducked.
.MIDI 'nuff said.
*ducks*
There are two possible reasons you're using XML to transport your data from one database to the other.
The first is that you just heard XML is a great way to transport data, and decided to use it.
The second is that you're using the XML for more than just transporting data from one database to another; you're using it at some point with your application.
In either case, the bottom line is that XML is not good for you. If your data fits in a relational database, you should USE RELATIONAL MEANS TO ACCESS YOUR DATA. Don't use that nifty new XML reader to access your data. It's not nearly as fast or flexible as basic SQL; it's actually much more trouble than it's worth.
If you're just transporting data from one relational database server to another, use a flat file, or better yet raw SQL dumps. If you're accessing the data with an application, use SQL or the underlying API.
The only reason you *ever* need to use an XML database is when your data doesn't fit into a standard relational schema. In fact, if you try to fit standard data into an XML database, you're much more likely to end up with a ton of overhead, both in storage and speed.
Fortunately, non-relational data is extremely rare. So rare, in fact, that I've yet to see a non-contrived-proof-of-concept "real life" example.
I can't believe you got modded *Informative* for that. Too funny.
Corporations and new languages don't mix very well. I just started a new job, and I get to wade through tons of fortan77 code.
Fortran77. Where you still *have* to use the GOTO statement to loop.
Sticking with Java because there's a better support base (i.e. because it's older) is perfectly valid.
I personally would rather code with C# any day of the week, and I was a Java-enthusiast for years.
That said, it's almost always best, IMO, to save state *and* history (when you need to save history). Saving state along with history increases storage usage, but reduces load-time. It's a trade-off.
Heh... good ones.
I can't claim to be the original author of the quote, but I've been tweaking the basic concept over the past few weeks... I think I'll change it to this:
"The problems with Christianity and D&D are essentially the same: too many rules lawyers."
Anyone who windows these nutz is joking.
Edit war off -- they've locked the main page and created a Talk:Sollog section.