I think you'd find your first example would be considered "fair use" as long as the slide show was for personal use (and trust me, nobody wants to see wedding photos except the wife).
In the second example, the problem is that youtube.com is a commercial site for one (even if you personally don't stand to gain money from showing the video on there... or even if Google doesn't make a profit overall), and for two you're distributing the work to the public, even if you're not charging for it. The only difference between that and putting an mp3 of the song(s) up on a public download site (btw, for the readership, that's also illegal to do without permission) is that you're violating someone else's copyright with the video too. You're also violating moral rights, although that might not be recognized in US law in such a case. And who knows how many taste laws you'd be breaking.
Nevertheless, in the second example, what you'd be doing would clearly not be covered under "fair use" (unless, I suppose, you could find a way to argue that it's satire). Therefore, it falls outside the scope of comparing the value of fair use to copyright. In that case, you'd be comparing the value of copyright infringement to copyright.
I have yet to play a FPS in which weapons jam (aside from various bugs/lag that might create a similar effect). As for enemy AI that "learns" from tactics... well if they could design an AI that advanced, one would think they could deploy it in their unmanned vehicles, robots, etc.
On the other hand, if the developers/military were interested in allowing the game explore complex and adaptive tactics, they would let players play as either side. No AI (yet) approaches the adaptibility of a human opponent, and even as a recruiting tool it may help some players understand how and why low-tech tactics work in asymmetric warfare. The military might even learn a thing or two.
Whatever you may think of Google's request, you must agree that linking to a website and circumventing proprietary encryption and access control schemes in order to get direct access to data on Google's servers are two entirely different matters.
Instead of people complaining that gold farming detracts from the game, they should be upset that the game designers can't just figure out a way to work around it via game design, rather than trying to put in stopgap measures to ban specific practices.
I find myself watching those "4-5 extra HD channels" more and more. I'm not that much into sports, but INHD2 is great (IMAX movies every Wed. at 8pm;), and I watch HBO series all the time (Rome is unbelievable in HD). With more HD channels in the pipeline and Blu-ray (and/or HD-DVD) on the way, the future is only looking brighter.
You responded to my simple statement that original object oriented languages, like Smalltalk, did, in fact, allow addition of methods outside the class, so this feature isn't some amazing new development.
Followed by your statement "The restrictions in Java and C# are decidedly non-object-oriented, inherited from C++." That's what I took issue with. Later in the thread, you said this:
Alan Kay said about this: "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind."
Implying that C++ is not object-oriented, then you added:
Inabilitiy to add new methods to existing classes is a huge deficit in C++, to this day....and finally:
Misapplying the label "object oriented" to Simula-67/C++...
Moving along...
C++ is great for highly experienced teams developing certain kinds of high performance software, or for academics.
How ironic it is then that C++ enjoys much wider-spread usage than Smalltalk (primarily used by academics) and Obj-C (primarily used by acamedics and MacOS X developers).;)
C++ caught on in the 1980's and 1990's because it was cheap/free, interoperated perfectly with C, and required no retraining; whether the alternatives were fast or slow, better or worse, generally didn't matter.
Those were actually the intentions of its creator; I guess he got them correct. Sometimes the purist's idea of "better" does match the constraints the realists are looking for.
That being said, there's been plenty that has held up C++ progress, such as ABI standardization, lack of high-level standard (de facto or de jure) library, garbage collection, etc. (Just because I prefer C++ for high-level programming in many cases doesn't mean I think the language or its deployment are perfect.)
No, what is "disingenuous" is that Simula/C++ were hyped up using the term "object oriented", popularized by Smalltalk, even though Nygaard and Stroustrup both full well knew that their languages weren't as powerful. Stroustrup overpromised and underdelivered, and the industry fell for it (including myself).
Nothing I've read from Stroustrup has ever billed C++ as anything more than what it is- a systems programming language based on C with object-oriented idioms.
Simula came out before Smalltalk and introduced the concepts of objects. That being said, I've never heard it "hyped" to be anything- in fact it's not really in wide usage.
I'm not experienced with Smalltalk, but from talking with people who are, I've gotten the impression that one of the reasons it hasn't caught on is that it's damned slow (at least, back in the days it had a chance to catch on). Stroustrup designed C++ so that it did not have to be any slower than C (admitting that using certain of its features might sacrifice speed for elegence).
The problem comes up constantly in large software systems developed by multiple groups. There are some patterns you can use as workarounds. But, then, you don't even need any object-oriented features in your language at all in order to do OOP, so why do you even bother with C++ and don't just use straight C?
I assume you've worked on such large software systems, and so have I. You've found a need for it, and I haven't; which is exactly what I argued.
Why not use straight C? I do, for some tasks. I use Perl for others, and Bash for others, Java, C++, whatnot. For most larger programs, I find object-oriented idioms much easier to work with, and so I prefer C++ or Java. If someone finds the idioms of Obj-C useful, they should use it; but I'm not going to start criticizing their choice because it doesn't have some feature of C++.
In what way does our discussions about what features we want to see in languages prevent you from using whatever you want?
What's the point of labelling one language which has objects to be "true" OO and another language which has objects not to be, other than to dissuade people from using it? What's the point of saying that a language "overpromised and underdelivered", other than to dissuage people from using it? The fact is, C++ is used much more than Object-C and Smalltalk, so whatever you think it has underdelivered, there are many people out there who must disagree.
The question I'd rather ask is why people like you feel compelled to try to stop discussion of new languages or new language features.
Smalltalk and Objective-C are not new languages, and according to you, the ability to add methods to existing classes without access to those classes source is "traditional" OO, so I don't know what new features I'm trying to stop discussion of.
You seem to be trying to mischaracterize what I originally was saying in this thread, so I'll repeat it: there's no reason to say that any one feature is required of an "object-oriented" language.
I could make the same case for templates, or generics, or garbage collectors, but it's all nonsense. Different languages are designed for different purposes. I'd rather use a language because it is the right one for the job instead of worrying about purists' definition of abstract language concepts.
(And let's cut the bogus use of emotive language like "any programmer worth his salt".)
This ain't Wikipedia my friend. I think any programmer worth his salt *does* understand these issues, and so I see no reason to refrain from expressing my opinion on here, any more than you should refrain from expressing your *opinion* that "no general purpose language should be without garbage collection."
Alan Kay said about this: "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind."
It's true that Smalltalk was the first language to use the term "object-oriented", but it is disingenuous to say that just because Kay came up with the term, that is can only apply to language features that Kay helped to develop.
Inabilitiy to add new methods to existing classes is a huge deficit in C++, to this day.
That's an opinion. I'm sure you find a use for that feature, but personally I've never found myself wishing I could do it, and I can think of reasons why I wouldn't want to do it (specifically, the ability to know what a class does without having to locate parts of it throughout the sourcecode). You can come up with examples of why its useful, and I could come up with counterexamples of why it would not be required if the design were extensible.
I don't have anything against Objective-C, I'm just tired of all this object-oriented elitism. When I want to get something done with a program, I want to use the right tool for the job. I don't care if someone in the 70s considered some feature essential to be certified "object-oriented". If you feel like you need the feature, use a language that has it, and let others use the language they want to use.
Once again nothing stops you from using a different coding style, you can write classes that do object.value(), where the only difference is choice of punctuation.
Not only that, but in C++ you can use a myriad of operator overloading (such as the * operator), including conversion operators. Using a conversion operator, you may not need to write a method call at all.
While technically legal, this is probably not what you want, because it's a constructor of one object (on the right) and then an assignment to another (on the left).
If you want just an initializer, do this:
NSColor color( 128, 128, 64, 0 );
color = [NSColor colorWithRed:128 Green:128 Blue:64 Alpha:0];
Blecch. You mean I have to re-type all the parameter names just because someone can't figure out how to use a modern IDE or an editor with tags support? I mean if you really must spell that out for people, you could always use *gasp* comments.
I don't understand all this "it's 2005 and programmers still have to worry about memory management?" nonsense.
I primarily write Java these days, and you know what? You still have to worry about memory management, you just don't have to worry about freeing pointers.
When you're writing software, you ought to have to worry about what the software is doing, whether your worries are at the pointer level, or remembering to unregister listeners that are keeping unused observable objects in memory, or whatever else it's doing. You can only 'drag-n-drop program' so much before some knowledge and wisdom about programming come into play.
There are many cases where you need a method to allocate something and either return it or store it in a collection, etc. In that case, it's impossible for the method itself to free it. Any programmer worth his salt would know this.
I guess the library designers thought it was more important to be able to know that the classes in a library would behave the same without having to wonder if somewhere in an application someone added some custom methods to it.
I don't like Java's 'final' classes, but I can see why one wouldn't necessarily want apps being able to modify the functionality of a class by adding new methods.
But if you really really want to do it, you can use aspects, available for at least Java and C++.
Objective C's approach, copied from Smalltalk, is the traditional object-oriented approach. The restrictions in Java and C# are decidedly non-object-oriented, inherited from C++.
Hmm, does Simula have that feature? C++ (or the OO additions to C within it) and Smalltalk are both descendants of Simula, which was arguably the first OO language. Just because Smalltalk added a feature that the C++ line did not does not make it a more object-oriented approach.
The fact is that all of the mentioned languages are "object-oriented" because they revolve around objects (structures with both data and behavior). The things the languages let you do with those objects is just different.
Slashdot Mirror
...is why the terrorists hate us.
It's cool when the NSF does it to monitor terrorists. When the FBI does it to monitor everyone, though, it's considered "fascist". Go figure.
I think you'd find your first example would be considered "fair use" as long as the slide show was for personal use (and trust me, nobody wants to see wedding photos except the wife).
In the second example, the problem is that youtube.com is a commercial site for one (even if you personally don't stand to gain money from showing the video on there... or even if Google doesn't make a profit overall), and for two you're distributing the work to the public, even if you're not charging for it. The only difference between that and putting an mp3 of the song(s) up on a public download site (btw, for the readership, that's also illegal to do without permission) is that you're violating someone else's copyright with the video too. You're also violating moral rights, although that might not be recognized in US law in such a case. And who knows how many taste laws you'd be breaking.
Nevertheless, in the second example, what you'd be doing would clearly not be covered under "fair use" (unless, I suppose, you could find a way to argue that it's satire). Therefore, it falls outside the scope of comparing the value of fair use to copyright. In that case, you'd be comparing the value of copyright infringement to copyright.
...we don't need any more home-brew anime music videos on youtube.
I have yet to play a FPS in which weapons jam (aside from various bugs/lag that might create a similar effect). As for enemy AI that "learns" from tactics... well if they could design an AI that advanced, one would think they could deploy it in their unmanned vehicles, robots, etc.
On the other hand, if the developers/military were interested in allowing the game explore complex and adaptive tactics, they would let players play as either side. No AI (yet) approaches the adaptibility of a human opponent, and even as a recruiting tool it may help some players understand how and why low-tech tactics work in asymmetric warfare. The military might even learn a thing or two.
Whatever you may think of Google's request, you must agree that linking to a website and circumventing proprietary encryption and access control schemes in order to get direct access to data on Google's servers are two entirely different matters.
Of course the real question is: will Sony be able to sell the discs in the first place?
'nuff said
Isn't that the sort of stuff rogues (aka 'thieves') are supposed to do?
Instead of people complaining that gold farming detracts from the game, they should be upset that the game designers can't just figure out a way to work around it via game design, rather than trying to put in stopgap measures to ban specific practices.
I guess if the Guns of Navarone (1961) and For a Few Dollars More (1965) can justify HD, Robocop (1987) can.
I find myself watching those "4-5 extra HD channels" more and more. I'm not that much into sports, but INHD2 is great (IMAX movies every Wed. at 8pm ;), and I watch HBO series all the time (Rome is unbelievable in HD). With more HD channels in the pipeline and Blu-ray (and/or HD-DVD) on the way, the future is only looking brighter.
You responded to my simple statement that original object oriented languages, like Smalltalk, did, in fact, allow addition of methods outside the class, so this feature isn't some amazing new development.
...and finally:
;)
Followed by your statement "The restrictions in Java and C# are decidedly non-object-oriented, inherited from C++." That's what I took issue with. Later in the thread, you said this:
Alan Kay said about this: "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind."
Implying that C++ is not object-oriented, then you added:
Inabilitiy to add new methods to existing classes is a huge deficit in C++, to this day.
Misapplying the label "object oriented" to Simula-67/C++...
Moving along...
C++ is great for highly experienced teams developing certain kinds of high performance software, or for academics.
How ironic it is then that C++ enjoys much wider-spread usage than Smalltalk (primarily used by academics) and Obj-C (primarily used by acamedics and MacOS X developers).
C++ caught on in the 1980's and 1990's because it was cheap/free, interoperated perfectly with C, and required no retraining; whether the alternatives were fast or slow, better or worse, generally didn't matter.
Those were actually the intentions of its creator; I guess he got them correct. Sometimes the purist's idea of "better" does match the constraints the realists are looking for.
That being said, there's been plenty that has held up C++ progress, such as ABI standardization, lack of high-level standard (de facto or de jure) library, garbage collection, etc. (Just because I prefer C++ for high-level programming in many cases doesn't mean I think the language or its deployment are perfect.)
Laugh away, because if you'd read my posts, you'd know I'm not one of those people.
No, what is "disingenuous" is that Simula/C++ were hyped up using the term "object oriented", popularized by Smalltalk, even though Nygaard and Stroustrup both full well knew that their languages weren't as powerful. Stroustrup overpromised and underdelivered, and the industry fell for it (including myself).
Nothing I've read from Stroustrup has ever billed C++ as anything more than what it is- a systems programming language based on C with object-oriented idioms.
Simula came out before Smalltalk and introduced the concepts of objects. That being said, I've never heard it "hyped" to be anything- in fact it's not really in wide usage.
I'm not experienced with Smalltalk, but from talking with people who are, I've gotten the impression that one of the reasons it hasn't caught on is that it's damned slow (at least, back in the days it had a chance to catch on). Stroustrup designed C++ so that it did not have to be any slower than C (admitting that using certain of its features might sacrifice speed for elegence).
The problem comes up constantly in large software systems developed by multiple groups. There are some patterns you can use as workarounds. But, then, you don't even need any object-oriented features in your language at all in order to do OOP, so why do you even bother with C++ and don't just use straight C?
I assume you've worked on such large software systems, and so have I. You've found a need for it, and I haven't; which is exactly what I argued.
Why not use straight C? I do, for some tasks. I use Perl for others, and Bash for others, Java, C++, whatnot. For most larger programs, I find object-oriented idioms much easier to work with, and so I prefer C++ or Java. If someone finds the idioms of Obj-C useful, they should use it; but I'm not going to start criticizing their choice because it doesn't have some feature of C++.
In what way does our discussions about what features we want to see in languages prevent you from using whatever you want?
What's the point of labelling one language which has objects to be "true" OO and another language which has objects not to be, other than to dissuade people from using it? What's the point of saying that a language "overpromised and underdelivered", other than to dissuage people from using it? The fact is, C++ is used much more than Object-C and Smalltalk, so whatever you think it has underdelivered, there are many people out there who must disagree.
The question I'd rather ask is why people like you feel compelled to try to stop discussion of new languages or new language features.
Smalltalk and Objective-C are not new languages, and according to you, the ability to add methods to existing classes without access to those classes source is "traditional" OO, so I don't know what new features I'm trying to stop discussion of.
You seem to be trying to mischaracterize what I originally was saying in this thread, so I'll repeat it: there's no reason to say that any one feature is required of an "object-oriented" language.
I could make the same case for templates, or generics, or garbage collectors, but it's all nonsense. Different languages are designed for different purposes. I'd rather use a language because it is the right one for the job instead of worrying about purists' definition of abstract language concepts.
This ain't Wikipedia my friend. I think any programmer worth his salt *does* understand these issues, and so I see no reason to refrain from expressing my opinion on here, any more than you should refrain from expressing your *opinion* that "no general purpose language should be without garbage collection."
It's true that Smalltalk was the first language to use the term "object-oriented", but it is disingenuous to say that just because Kay came up with the term, that is can only apply to language features that Kay helped to develop.
That's an opinion. I'm sure you find a use for that feature, but personally I've never found myself wishing I could do it, and I can think of reasons why I wouldn't want to do it (specifically, the ability to know what a class does without having to locate parts of it throughout the sourcecode). You can come up with examples of why its useful, and I could come up with counterexamples of why it would not be required if the design were extensible.
I don't have anything against Objective-C, I'm just tired of all this object-oriented elitism. When I want to get something done with a program, I want to use the right tool for the job. I don't care if someone in the 70s considered some feature essential to be certified "object-oriented". If you feel like you need the feature, use a language that has it, and let others use the language they want to use.
Oh yeah, [receiver doSomething:3 magicnumber:2 code:1 msg:"boom"]... that makes a lot more sense.
Not only that, but in C++ you can use a myriad of operator overloading (such as the * operator), including conversion operators. Using a conversion operator, you may not need to write a method call at all.
color = NSColor(128, 128, 64, 0);
While technically legal, this is probably not what you want, because it's a constructor of one object (on the right) and then an assignment to another (on the left).
If you want just an initializer, do this:
NSColor color( 128, 128, 64, 0 );
color = [NSColor colorWithRed:128 Green:128 Blue:64 Alpha:0];
Blecch. You mean I have to re-type all the parameter names just because someone can't figure out how to use a modern IDE or an editor with tags support? I mean if you really must spell that out for people, you could always use *gasp* comments.
I don't understand all this "it's 2005 and programmers still have to worry about memory management?" nonsense.
I primarily write Java these days, and you know what? You still have to worry about memory management, you just don't have to worry about freeing pointers.
When you're writing software, you ought to have to worry about what the software is doing, whether your worries are at the pointer level, or remembering to unregister listeners that are keeping unused observable objects in memory, or whatever else it's doing. You can only 'drag-n-drop program' so much before some knowledge and wisdom about programming come into play.
There are many cases where you need a method to allocate something and either return it or store it in a collection, etc. In that case, it's impossible for the method itself to free it. Any programmer worth his salt would know this.
For anyone who is not sure about the "composition versus inheritence" debate... go code some Eiffel. >:)
I don't like Java's 'final' classes, but I can see why one wouldn't necessarily want apps being able to modify the functionality of a class by adding new methods.
But if you really really want to do it, you can use aspects, available for at least Java and C++.
The fact is that all of the mentioned languages are "object-oriented" because they revolve around objects (structures with both data and behavior). The things the languages let you do with those objects is just different.