I'd just like to note that I'm not arguing against subclasses, rather I'm arguing for other things which I think are also valuable by pretending we don't have some of the things we do (like subclasses).
Subclassing allows an object of an old class to call an object of a new, revised class, using the same API, getting the current functionality.
Ok, that's fine, but in this case the parent class doesn't have to contain any code, i.e. it can just be an interface. I think that meshes with what I said earlier.
Subclassing with multi-inheritance allows new classes with combined behavior of old ones, without necessarily writing any new code.
Is this necessarily a good thing, considering that interfacing two separately-designed objects, especially those which use the same resource, i.e. a particular window on the screen, almost always requires some consideratin? And in that case, how is multiple inheritance any better than creating an object containing the two other objects? In my experience, multiple inheritance is most used to patch over a lacking type system.
Subclassing reflects disciplined versioning, and is all too often disregarded, at the peril of the application's fate.
That is certainly a valid point, and versioning systems would do well to take into accoutn semantic information.
(1) Only allowing copyright on the source code, but not the compiled binaries, and (2) striking down and in fact outlawing the ability to give up certain rights through click-through/shrink-wrap "licenses" might have a similar effect. Is there any kind of restriction on processed works in other areas similar to (1)? How about (2)?
That's an interesting point. The only problem I see is that correctness is application-specific, so we need a compact way to define correct application behavior. For GCC, this isn't so much of a problem, because C is a widely-accepted standard; but joebob's Ogg organizing GUI is not. So I guess what you'd end up having is a standard set of requirements on the interactions between different types of widgets, along with parameterized test cases for those requirements. Then you could specify which widgets plug into which requirement-positions, e.g. "such and such custom editing widget (like for equations or something) should follow the standards for text editing" and "such and such is the editing window and that other thing is the Edit->Copy menu option". I suppose requirements could be bundled together into mega-requirements like "typical single-dialog application". You'd also probably want to be able to specify algebraic properties of operations you can perform on the application, like so the tool can derive sequences of events which should result in the same state modulo a particular feature. To do this, perhaps the user interface could be specified as a simplified state machine regarding windows/widgets which are displayed and options which are available. This would allow us to perform a large number of random interactions along a guided path for stress-testing.
Derived objects, on the other hand, don't seem too useful for GUIs so long as you have interfaces or a good implementation of generic functions and type inference.
Uhh...right...because C has all of those things...
You're 100% right, it doesn't. But the current crop of popular programming languages is almost equally lacking in these regards -- C++'s templates are basically textual substitution, you can't type-constrain template arguments, you just have to see if it works; Java's generics are still in development, but other than that Java's libraries are already a total mess. Since the least common denominator isn't much worse than the best of what's popular, might as well keep the flexibility of C so that we're not tied to a incompatible halfway solution when the right thing finally comes out and is accepted.
Many people are probably going to say that GUIs are inherently object-oriented, as they attempt to reconcile programmatic constructs with tangible objects. But the fact that GTK+ isn't implemented in, say, C++ isn't necessarily as bad as it sounds -- I don't think extending classes is particularly useful for GUI programming -- by deriving, you're either essentially encapsulating the parent class's functionality along with other functionality, or doing weird stuff to the internals of the parent to extend it.
What's really important is that GUIs are concurrent and event-based, and hence the primitives which are reused all over the place need to be as well. Contrast a push-button, which generates an event for the containing program to handle whenever the user decides to click on it, with a square-root function, which only when instructed by the containing program takes a value, performs a finite amount of computation, returns another value, and stops. This is why Qt has its signals and slots. This is why TCL/Tk has been used so much for GUI programming despite its terribly lacking language features. This is why Java uses threads in its GUI frameworks. This is why the failed BeOS focused on highly efficient multi-threading.
Although I agree that object-oriented encapsulation is essential for organizing the code of widgets, asynchronous lightweight concurrency is at least as important to make GUIs work. Derived objects, on the other hand, don't seem too useful for GUIs so long as you have interfaces or a good implementation of generic functions and type inference. Unfortunately, popular object oriented languages like C++ and Java don't really add this over C -- C++ is still totally sequential at heart, and Java's threads aren't particularly lightweight, nor is its huge library.
Support for DirectX vs. OpenGL extensions... that's another good point.
I think the original poster was arguing that the GPL is more political than the BSD license. But that's irrelevant here, because GTK+ is LGPLed, while Qt is GPLed/other license available. Since most application developers won't be modifying either toolkit's libraries, GTK+ is actually more lenient (at least for cheapskates).
I agree with your assertion that GUIs are inherently object-oriented, as they attempt to reconcile programmatic constructs with tangible objects. However, MFC is a bad example of an easy-to-program GUI library. Furthermore, I don't think extending classes is particularly useful for GUI programming -- by deriving, you're either essentially encapsulating the parent class's functionality along with other functionality, or doing weird stuff to the internals of the parent to extend it.
What's really important is that GUIs are concurrent and event-based, and hence the primitives which are reused all over the place need to be as well. Contrast a push-button, which generates an event for the containing program to handle whenever the user decides to click on it, with a square-root function, which only when instructed by the containing program takes a value, performs a finite amount of computation, returns another value, and stops. This is why Qt has its signals and slots. This is why TCL/Tk has been used so much for GUI programming despite its terribly lacking language features. This is why Java uses threads in its GUI frameworks. This is why the failed BeOS focused on highly efficient multi-threading.
Although I 100% agree that object-oriented encapsulation is essential for organizing the code of widgets, asynchronous lightweight concurrency is at least as important to make GUIs work. Derived objects, on the other hand, don't seem too useful for GUIs so long as you have interfaces or a good implementation of generic functions and type inference.
Regarding OpenGL vs. DirectX, in my experience OpenGL is very easy and intuitive to program, and is structured very naturally. You have to remember that drawing to the screen is essentially procedural. Even in toolkits like DirectX designed in so-called object-oriented languages, your drawing code looks essentially the same. The only real difference is that when you create objects like buffers or textures, they're "real objects" in your language rather than quasi-opaque handle numbers. I do think that is a good incremental improvement, but I also think OpenGL object handles can be easily wrapped into objects in, say, C++, without sacrificing performance. The real arguments for DirectX, in my opinion, are (1) it's more than just graphics -- DirectSound, DirectInput, etc., and (2) it's heavily supported by Microsoft -- this means that game developers can be more confident that their product will work well on their customers' systems, and hence not be returned or gain a reputation for unreliability. Indeed, as Microsoft has demonstrated with the XBox, DirectX is an attempt to make PCs more uniform, predictable, and console-like, appealing to developers without as high up-front costs of development kits and lingering threat of not "making the cut" when the console proprietor decides whether or not to license your game.
Was becoming a billionare businessman an option for Saddam Hussein? If yes, then why not go that route?
No, not really. Not at all. He was unfortunately outcast since he was a child, especially by his uncle. After getting out of jail, he joined the Ba'ath party as a hired hitman to take out the then-president of Iraq, and took it from there, reveling in and hyping up his brutality. His own military plans have generally been crude and unsuccessful, what has kept him in power is his eager willingness to kill any subordinate who doesn't follow his orders and tow his line.
I think it actually functions as some sort of apology in this bizarre little subculture to keep the Slashdot-groupthink moderators at bay, and hence increase the chance of the moderators who might mod it up to see it and do so. I'll have to agree with you that it's not a direct cause-effect correlation of whinewhinewhine => +5 Insightful.
Here's another one, season-appropriate (for the northern hemisphere):
Jack Frost paper art. This cute little guy is a demon in the Persona video games, and probably some others. He also seems to be a mascot for Atlus software.
Most CompactFlash cards have built-in write conditioning in their controls, which is why it's not much of a problem to write whatever filesystem, including FAT, to them. SmartMedia (really StupidMedia), on the other hand, requires the host to do it.
Slashdot Mirror
I'd just like to note that I'm not arguing against subclasses, rather I'm arguing for other things which I think are also valuable by pretending we don't have some of the things we do (like subclasses).
Ok, that's fine, but in this case the parent class doesn't have to contain any code, i.e. it can just be an interface. I think that meshes with what I said earlier.
Subclassing with multi-inheritance allows new classes with combined behavior of old ones, without necessarily writing any new code.
Is this necessarily a good thing, considering that interfacing two separately-designed objects, especially those which use the same resource, i.e. a particular window on the screen, almost always requires some consideratin? And in that case, how is multiple inheritance any better than creating an object containing the two other objects? In my experience, multiple inheritance is most used to patch over a lacking type system.
Subclassing reflects disciplined versioning, and is all too often disregarded, at the peril of the application's fate.
That is certainly a valid point, and versioning systems would do well to take into accoutn semantic information.
(1) Only allowing copyright on the source code, but not the compiled binaries, and (2) striking down and in fact outlawing the ability to give up certain rights through click-through/shrink-wrap "licenses" might have a similar effect. Is there any kind of restriction on processed works in other areas similar to (1)? How about (2)?
That's an interesting point. The only problem I see is that correctness is application-specific, so we need a compact way to define correct application behavior. For GCC, this isn't so much of a problem, because C is a widely-accepted standard; but joebob's Ogg organizing GUI is not. So I guess what you'd end up having is a standard set of requirements on the interactions between different types of widgets, along with parameterized test cases for those requirements. Then you could specify which widgets plug into which requirement-positions, e.g. "such and such custom editing widget (like for equations or something) should follow the standards for text editing" and "such and such is the editing window and that other thing is the Edit->Copy menu option". I suppose requirements could be bundled together into mega-requirements like "typical single-dialog application". You'd also probably want to be able to specify algebraic properties of operations you can perform on the application, like so the tool can derive sequences of events which should result in the same state modulo a particular feature. To do this, perhaps the user interface could be specified as a simplified state machine regarding windows/widgets which are displayed and options which are available. This would allow us to perform a large number of random interactions along a guided path for stress-testing.
Uhh...right...because C has all of those things...
You're 100% right, it doesn't. But the current crop of popular programming languages is almost equally lacking in these regards -- C++'s templates are basically textual substitution, you can't type-constrain template arguments, you just have to see if it works; Java's generics are still in development, but other than that Java's libraries are already a total mess. Since the least common denominator isn't much worse than the best of what's popular, might as well keep the flexibility of C so that we're not tied to a incompatible halfway solution when the right thing finally comes out and is accepted.
Many people are probably going to say that GUIs are inherently object-oriented, as they attempt to reconcile programmatic constructs with tangible objects. But the fact that GTK+ isn't implemented in, say, C++ isn't necessarily as bad as it sounds -- I don't think extending classes is particularly useful for GUI programming -- by deriving, you're either essentially encapsulating the parent class's functionality along with other functionality, or doing weird stuff to the internals of the parent to extend it. What's really important is that GUIs are concurrent and event-based, and hence the primitives which are reused all over the place need to be as well. Contrast a push-button, which generates an event for the containing program to handle whenever the user decides to click on it, with a square-root function, which only when instructed by the containing program takes a value, performs a finite amount of computation, returns another value, and stops. This is why Qt has its signals and slots. This is why TCL/Tk has been used so much for GUI programming despite its terribly lacking language features. This is why Java uses threads in its GUI frameworks. This is why the failed BeOS focused on highly efficient multi-threading. Although I agree that object-oriented encapsulation is essential for organizing the code of widgets, asynchronous lightweight concurrency is at least as important to make GUIs work. Derived objects, on the other hand, don't seem too useful for GUIs so long as you have interfaces or a good implementation of generic functions and type inference. Unfortunately, popular object oriented languages like C++ and Java don't really add this over C -- C++ is still totally sequential at heart, and Java's threads aren't particularly lightweight, nor is its huge library.
I think the original poster was arguing that the GPL is more political than the BSD license. But that's irrelevant here, because GTK+ is LGPLed, while Qt is GPLed/other license available. Since most application developers won't be modifying either toolkit's libraries, GTK+ is actually more lenient (at least for cheapskates).
What's really important is that GUIs are concurrent and event-based, and hence the primitives which are reused all over the place need to be as well. Contrast a push-button, which generates an event for the containing program to handle whenever the user decides to click on it, with a square-root function, which only when instructed by the containing program takes a value, performs a finite amount of computation, returns another value, and stops. This is why Qt has its signals and slots. This is why TCL/Tk has been used so much for GUI programming despite its terribly lacking language features. This is why Java uses threads in its GUI frameworks. This is why the failed BeOS focused on highly efficient multi-threading.
Although I 100% agree that object-oriented encapsulation is essential for organizing the code of widgets, asynchronous lightweight concurrency is at least as important to make GUIs work. Derived objects, on the other hand, don't seem too useful for GUIs so long as you have interfaces or a good implementation of generic functions and type inference.
Regarding OpenGL vs. DirectX, in my experience OpenGL is very easy and intuitive to program, and is structured very naturally. You have to remember that drawing to the screen is essentially procedural. Even in toolkits like DirectX designed in so-called object-oriented languages, your drawing code looks essentially the same. The only real difference is that when you create objects like buffers or textures, they're "real objects" in your language rather than quasi-opaque handle numbers. I do think that is a good incremental improvement, but I also think OpenGL object handles can be easily wrapped into objects in, say, C++, without sacrificing performance. The real arguments for DirectX, in my opinion, are (1) it's more than just graphics -- DirectSound, DirectInput, etc., and (2) it's heavily supported by Microsoft -- this means that game developers can be more confident that their product will work well on their customers' systems, and hence not be returned or gain a reputation for unreliability. Indeed, as Microsoft has demonstrated with the XBox, DirectX is an attempt to make PCs more uniform, predictable, and console-like, appealing to developers without as high up-front costs of development kits and lingering threat of not "making the cut" when the console proprietor decides whether or not to license your game.
No, not really. Not at all. He was unfortunately outcast since he was a child, especially by his uncle. After getting out of jail, he joined the Ba'ath party as a hired hitman to take out the then-president of Iraq, and took it from there, reveling in and hyping up his brutality. His own military plans have generally been crude and unsuccessful, what has kept him in power is his eager willingness to kill any subordinate who doesn't follow his orders and tow his line.
I think it actually functions as some sort of apology in this bizarre little subculture to keep the Slashdot-groupthink moderators at bay, and hence increase the chance of the moderators who might mod it up to see it and do so. I'll have to agree with you that it's not a direct cause-effect correlation of whinewhinewhine => +5 Insightful.
So you're saying Europeans are murderous fiends?
Here's another one, season-appropriate (for the northern hemisphere): Jack Frost paper art. This cute little guy is a demon in the Persona video games, and probably some others. He also seems to be a mascot for Atlus software.
For all its faults, Pine does. It says "sent mail and copied to sent-mail folder," or something like that.
The Marines have a Marine Doom level for download on one of their websites...
Most CompactFlash cards have built-in write conditioning in their controls, which is why it's not much of a problem to write whatever filesystem, including FAT, to them. SmartMedia (really StupidMedia), on the other hand, requires the host to do it.
The Rio Karma plays MP3, WMA, Ogg and FLAC, but it includes a 20GB hard drive. It also has an ethernet port in its docking station.
Probably similar volume
That doesn't make any sense, you could just have a separate process which gets started and finishes updating MSIE after the browser has closed.
No, they do reencode the images with higher compression, consequently making them look like shit.