To me, it's a general problem of redundancy. Filetype should be defined once and only once. If type X has magic prefix Y, then the server should identify the data as of type X using MIME and leave out magic prefix Y. The client can then stuff magic prefix Y onto the file when saving it.
Once-and-only-once is the first and last rule of good programming. The moment any information appears in more than one place, things start to hit the fan.
Yes, but my point is that C++ allows you to produce typesafe code if you limit yourself to a subset of the language while still maintaining most of the functionality. If you constructed more tools for yourself in C++ outside of the typesafe environment, you could improve this toolset to an impressive level. Meanwhile, you would be hard pressed to find a useful subset of pre-1.5 Java that is typesafe.
Haven't coded in C++ in a while - my complaint about the syntax was for streams in general, not just the stringstream. And the stringstream is a painful approach to string manipulation compared to other languages - dispite the advantages of having a unified syntax of having strings treated just like i/o streams. A true string library was an annoying omission.
As for my auto_ptr complatint, what I meant was that there was no mechanism in standard C++ to transfer ownership of an object to a container without copying the object. This copy was an unnecessary overhead. auto_ptr didn't work, and if you stuck a conventional pointer into a container, you'd have to delete the object manually.
My attitude: if you produce code that uses any of the obscure (and bizarre) features of C that do not cross over into C++, then you're already a bizarre four star coder and anything you produce will be of no value anyways.
And you can tell the compiler "I know" by casting properly. You can write "no warning" C++, which will protect you the one time that you _didn't_ realise that you floored your floats.
Hmmph. You hear about the successes, like C++'s spectacularly awsome template system, but people simply don't talk about the failures. Exception specifications anyone? Run-time handling of thrown exception specifications is worse than useless.
Amen. two-thousand-frickin'-9 is their _earliest_ estimate for a standard? I want this shit yesterday.
The apalling pace of development and some brain-dead holes in the standard libs are it's big flaws. The language itself is wonderful, but the standard library has some massive problems. For example, the string stream system in C++ was just dumb, and the fact that there was no mechanism to use STL containers to hold any auto_ptr-like mechanism was just ludicrous. I didn't expect the modern idea of strings-as-immutables-for-fast-hashing to hit them, but a the string stream approach was ridiculously cumbersome and didn't even have efficiency as an excuse. Plus, it provided the prototypical example of operator overloading abuse that became the hallmark embarassment of the language.
And as for the "using" keyword for currying templates - make it typedef, and don't give me any excuses for why typedef doesn't work for such things.
You could re-implement the primitives in such a way that would not allow implicit typecasting for example. Because of the lack of operator overloading in Java, you are stuck with the true primitives as is unless you want the headache of boxing/unboxing.
Also, you can avoid the NULL case (which is a giant hole in preventing runtime errors) by passing by value or reference only.
Yes, but many people just don't have time on their hands and just want to game online socially with their group of friends. Such people often have the money - these are where goldfarmers get their cash. And if Blizzard themselves (or whatever company runs your game of choice) offered the premium-priced top-end-characters, they could allow you to design and outfit the character yourself.
There are two ways to think about C++ - C++ is a superset of C, and C++ is a new language that is backwards compatible with C. Both are true, but they produce completely different programming styles.
Well, there's the extreme programming approach, the fundamental tenet of which is "the program is the design". After all, is writing "foo" with a square around it and an arrow pointing to "bar" in a box any easier than
class foo : bar {}
?
The idea of XP is that the design document should be a quick thumbnail sketch. The rest should be thrashed out in the real world of code and computers with a minimum of gold plating, with a massive set of tests set up to make sure that the process of thrashing things around doesn't break anything you already finished.
Let players buy their characters. Simple. For $120 upfront, start at level 50 with a greater mount and the inventory of your choice. That would let you compete in the CTF, be on-par with your guild, etc. Simple way for latecomers to catch up with their friends. It would avoid the "my char got nerfed, I want to make a new one, but I gotta play through 40 hours of gameplay to get to the good multiplayer parts of the game" problem.
Which makes more sense than tacking on extra tasks that need to be done just so rogues can be useful. To me, the whole idea of adding on complexities to a game to justify the existence of a class seems rather stupid.
The idea is that you can do both in C++. If you restrict all your operations to a subset of the standard, C++ is safe. If you allow yourself usage of the unsafe objects, then C++ is unsafe. If you make wrappers for all the the core primitives, you can even have a more oop, typesafe language than Java.
The problem is that (a) too many C++ coders treat C++ as a superset of C, instead of a new language that is backwards compatible with C, (b) the standard library is weak, and (c), standard compliant compilers (and the '90s standard) came out too late in the game.
Agreed. The first step to coding C++ is to forget all the C you ever knew. Arrays are used for optimizing and nothing else. Combine that with the type safety of the language, and using references instead of pointers, and you basically get Java without all the flaws of Java/C# - it's faster, more typesafe, backwards-compatible, better hardware access, and more expressive than it's newer offspring. If only the 9x standard had come out (and been supported by mainstream compilers) earlier and there were some solid GUI libraries, we could've dodged the whole Java/C# thing altogether... well, if there were some way to put pointers in a collection and have them be deleted on removal in standard C++ (either support for auto_ptrs or inclusion of smart_ptrs in C++).
Because real enterprise apps aren't run on webhosting companies. THey're run on company-owned servers - colos at a bare minimum. And in that case, they don't use MySQL.
I've worked in a Java shop and I'm working in a.NET shop, and I call it like I see it. The historical lack of generics in those languages combined with the lack of multiple inheritence means that doing normal tasks become tons and tons of work.
Java was invented so that coders could look busy by producing huge, megalithic programs without getting too much done. It's the "look busy" school of architecture design - it maximizes the number of annoying intermediary classes and functions the coder must make.
While I've never used Maya, I don't think anybody sane characterises Max as easy to pick up sans manual. That app is just mindboggly (justifiably so - it's very powerful).
AiW linux support is even worse than normal ATI linux support - the AIWs use some completely orthogonal approach that means they don't work at all like a normal capture board - as such, nobody supports their capture abilities at all.
I have the 9600 A-I-W, bought with the intent of making a hybrid PVR and desktop - hooked the TV-out and the on-chip sound to the TV, and used the monitor out with my PC sound.
Needless to say it didn't work out well. ATI's apalling software couldn't be told to use the secondary sound output device. That's an understandable failure, but pales in comparison to how bad the rest of the platform is - the remote is barely useful and sucks the batteries (and is a headache to find patches for), the TV schedule app is just apalling. The mouse pointer vanishes whenever there is no signal (like if you're selecting future programming) and the resolution is too high for TV.
The mainstream TV/DVD apps are passable, but the TV app is flawed by the fact that it doesn't make enough use of the program info - it will tell you the name of the program you're viewing, but not of any others, meaning it leaves you channel surfing. The recording system works well though.
The playback app is likewise terrible - it integrates well with the ATI recorder, but it's nigh-impossible to load a movie file from fullscreen mode. Basically, you can't pop in a CD with an xvid on it and watch it without switching apps to some 3rd party app that won't work well with the remote.
ATI hardware = teh roxxor. ATI software = teh suxxor.
Re:This doesn't mean they want to "control" Python
on
Guido Goes Google
·
· Score: 1
The generic containers are a new invention, and imho the language was disastrously incomplete before then. And the Java API is similar to the.NET API in that it's bulkiness comes from the massive amount of database, serialization etc. libraries thrown in, not because of having a perfectly complete set of containers.
Having worked with TkInter, I have to say that I actually enjoyed the layout of it. I found it pleasant and lightweight to code with. The problem was that the widgets themselves were just awful.
Slashdot Mirror
To me, it's a general problem of redundancy. Filetype should be defined once and only once. If type X has magic prefix Y, then the server should identify the data as of type X using MIME and leave out magic prefix Y. The client can then stuff magic prefix Y onto the file when saving it.
Once-and-only-once is the first and last rule of good programming. The moment any information appears in more than one place, things start to hit the fan.
Yes, but my point is that C++ allows you to produce typesafe code if you limit yourself to a subset of the language while still maintaining most of the functionality. If you constructed more tools for yourself in C++ outside of the typesafe environment, you could improve this toolset to an impressive level. Meanwhile, you would be hard pressed to find a useful subset of pre-1.5 Java that is typesafe.
Haven't coded in C++ in a while - my complaint about the syntax was for streams in general, not just the stringstream. And the stringstream is a painful approach to string manipulation compared to other languages - dispite the advantages of having a unified syntax of having strings treated just like i/o streams. A true string library was an annoying omission.
As for my auto_ptr complatint, what I meant was that there was no mechanism in standard C++ to transfer ownership of an object to a container without copying the object. This copy was an unnecessary overhead. auto_ptr didn't work, and if you stuck a conventional pointer into a container, you'd have to delete the object manually.
My attitude: if you produce code that uses any of the obscure (and bizarre) features of C that do not cross over into C++, then you're already a bizarre four star coder and anything you produce will be of no value anyways.
And you can tell the compiler "I know" by casting properly. You can write "no warning" C++, which will protect you the one time that you _didn't_ realise that you floored your floats.
Hmmph. You hear about the successes, like C++'s spectacularly awsome template system, but people simply don't talk about the failures. Exception specifications anyone? Run-time handling of thrown exception specifications is worse than useless.
Amen. two-thousand-frickin'-9 is their _earliest_ estimate for a standard? I want this shit yesterday.
The apalling pace of development and some brain-dead holes in the standard libs are it's big flaws. The language itself is wonderful, but the standard library has some massive problems. For example, the string stream system in C++ was just dumb, and the fact that there was no mechanism to use STL containers to hold any auto_ptr-like mechanism was just ludicrous. I didn't expect the modern idea of strings-as-immutables-for-fast-hashing to hit them, but a the string stream approach was ridiculously cumbersome and didn't even have efficiency as an excuse. Plus, it provided the prototypical example of operator overloading abuse that became the hallmark embarassment of the language.
And as for the "using" keyword for currying templates - make it typedef, and don't give me any excuses for why typedef doesn't work for such things.
You could re-implement the primitives in such a way that would not allow implicit typecasting for example. Because of the lack of operator overloading in Java, you are stuck with the true primitives as is unless you want the headache of boxing/unboxing.
Also, you can avoid the NULL case (which is a giant hole in preventing runtime errors) by passing by value or reference only.
Yes, but many people just don't have time on their hands and just want to game online socially with their group of friends. Such people often have the money - these are where goldfarmers get their cash. And if Blizzard themselves (or whatever company runs your game of choice) offered the premium-priced top-end-characters, they could allow you to design and outfit the character yourself.
There are two ways to think about C++ - C++ is a superset of C, and C++ is a new language that is backwards compatible with C. Both are true, but they produce completely different programming styles.
Well, there's the extreme programming approach, the fundamental tenet of which is "the program is the design". After all, is writing "foo" with a square around it and an arrow pointing to "bar" in a box any easier than
class foo : bar {}
?
The idea of XP is that the design document should be a quick thumbnail sketch. The rest should be thrashed out in the real world of code and computers with a minimum of gold plating, with a massive set of tests set up to make sure that the process of thrashing things around doesn't break anything you already finished.
The designers could take the alternate approach:
Let players buy their characters. Simple. For $120 upfront, start at level 50 with a greater mount and the inventory of your choice. That would let you compete in the CTF, be on-par with your guild, etc. Simple way for latecomers to catch up with their friends. It would avoid the "my char got nerfed, I want to make a new one, but I gotta play through 40 hours of gameplay to get to the good multiplayer parts of the game" problem.
Which makes more sense than tacking on extra tasks that need to be done just so rogues can be useful. To me, the whole idea of adding on complexities to a game to justify the existence of a class seems rather stupid.
The idea is that you can do both in C++. If you restrict all your operations to a subset of the standard, C++ is safe. If you allow yourself usage of the unsafe objects, then C++ is unsafe. If you make wrappers for all the the core primitives, you can even have a more oop, typesafe language than Java.
The problem is that (a) too many C++ coders treat C++ as a superset of C, instead of a new language that is backwards compatible with C, (b) the standard library is weak, and (c), standard compliant compilers (and the '90s standard) came out too late in the game.
Agreed. The first step to coding C++ is to forget all the C you ever knew. Arrays are used for optimizing and nothing else. Combine that with the type safety of the language, and using references instead of pointers, and you basically get Java without all the flaws of Java/C# - it's faster, more typesafe, backwards-compatible, better hardware access, and more expressive than it's newer offspring. If only the 9x standard had come out (and been supported by mainstream compilers) earlier and there were some solid GUI libraries, we could've dodged the whole Java/C# thing altogether... well, if there were some way to put pointers in a collection and have them be deleted on removal in standard C++ (either support for auto_ptrs or inclusion of smart_ptrs in C++).
Agreed. C# vs Java is Coke vs. Pepsi right now.
Because real enterprise apps aren't run on webhosting companies. THey're run on company-owned servers - colos at a bare minimum. And in that case, they don't use MySQL.
Whoa - just looked into Media Portal - it looks incredisexy, and perfect for my purposes.
I've worked in a Java shop and I'm working in a .NET shop, and I call it like I see it. The historical lack of generics in those languages combined with the lack of multiple inheritence means that doing normal tasks become tons and tons of work.
Java was invented so that coders could look busy by producing huge, megalithic programs without getting too much done. It's the "look busy" school of architecture design - it maximizes the number of annoying intermediary classes and functions the coder must make.
While I've never used Maya, I don't think anybody sane characterises Max as easy to pick up sans manual. That app is just mindboggly (justifiably so - it's very powerful).
AiW linux support is even worse than normal ATI linux support - the AIWs use some completely orthogonal approach that means they don't work at all like a normal capture board - as such, nobody supports their capture abilities at all.
I have the 9600 A-I-W, bought with the intent of making a hybrid PVR and desktop - hooked the TV-out and the on-chip sound to the TV, and used the monitor out with my PC sound.
Needless to say it didn't work out well. ATI's apalling software couldn't be told to use the secondary sound output device. That's an understandable failure, but pales in comparison to how bad the rest of the platform is - the remote is barely useful and sucks the batteries (and is a headache to find patches for), the TV schedule app is just apalling. The mouse pointer vanishes whenever there is no signal (like if you're selecting future programming) and the resolution is too high for TV.
The mainstream TV/DVD apps are passable, but the TV app is flawed by the fact that it doesn't make enough use of the program info - it will tell you the name of the program you're viewing, but not of any others, meaning it leaves you channel surfing. The recording system works well though.
The playback app is likewise terrible - it integrates well with the ATI recorder, but it's nigh-impossible to load a movie file from fullscreen mode. Basically, you can't pop in a CD with an xvid on it and watch it without switching apps to some 3rd party app that won't work well with the remote.
ATI hardware = teh roxxor. ATI software = teh suxxor.
but what of us losers that like Python tabbing?
The generic containers are a new invention, and imho the language was disastrously incomplete before then. And the Java API is similar to the .NET API in that it's bulkiness comes from the massive amount of database, serialization etc. libraries thrown in, not because of having a perfectly complete set of containers.
Having worked with TkInter, I have to say that I actually enjoyed the layout of it. I found it pleasant and lightweight to code with. The problem was that the widgets themselves were just awful.