How many people do you know would be happy to pay $100 today to buy software (or to buy services to develop software) which will only be available 10 years from now. Not many. Of course, ten years is a ridiculously long time. You'd need a shorter development cycle than that. If your software can't be made on a faster cycle, maybe it wouldn't get made in a post-copyright world... but I'm not convinced that the loss is great enough to keep the restrictions on speech necessary for its development.
I find it a little harsh though that you put all proprietary software in the same basket as the MAFIAA. Do you have a better way to enforce copyright law than what they're doing? I mean, their tactics are harsh and careless, but ISTM that's a basic problem with enforcing copyright at all. You either set your standard of evidence high enough that you ignore a bunch of violations, or low enough that you accuse a bunch of people of violations they only seemed to commit.
You can't just overlook noncommercial copying if you want to use the business model of selling copies. But noncommercial copying is inherently hard to detect or prevent. If you want to have any chance of doing so, I think you'll eventually have to use the same mass lawsuit approach that the RIAA has, and/or push for technical means like the DMCA and Trusted Computing. The only alternative is to put an officer in every home, watching over everyone's shoulder to make sure they don't copy anything.
But how much would you be willing to give up to get software written at all? The GIMP is quite good, but it tries to clone Photoshop. What would it have cloned if Photoshop hadn't been there first? It would've added the features people wanted, and might end up looking a lot like it does today. The designers of Photoshop don't have any special insight that others are incapable of having. You're not really suggesting there'd be no innovation in software if people couldn't develop first and sell copies later, are you?
There are no classes lowercase in Java. Therefore no ambiguity and the programmers never needed to come up with anything. There are no lowercase classes by convention. There's nothing to stop you from creating one, except the shame of violating that convention.
There's a similar convention in.NET to prevent confusion between public fields and properties. The convention is don't make public fields, and it's been followed in the standard library: you might say "there are no fields public in C#". If you insist on violating that convention, then you can come up with your own convention to distinguish them from properties.
Here you go again, completely missing the point. Have you ever used an opensource library or framework? You don't have the code in your workspace to see the comments by passing the mouse over. Yes, I have. In fact, I've used closed-source libraries and frameworks too. You think the.NET Framework comes with source code? It doesn't.
But now you're the one missing the point. You don't need source code because you have compiled metadata. If you have the library in binary form--which you must if you're able to compile your own project against it--then you can use all the IDE's popup help and completion features. You don't need it in your project or workspace, you just need a reference to it from your project, which is exactly what you need to compile your project too.
Of course you can attach the documentation to Eclipse from an arbitrary piece of code, but you won't have it by default. Well, that sounds like a problem with Eclipse, because Visual Studio has no problem extracting metadata from a compiled library. It can even translate the metadata back into a class definition for you (sans method bodies).
I don't think "operator overloading" is a theoretical criticism, in this case overloading the operator "=". You, who don't use C#, say properties are confusing. Thousands of programmers who actually use it every day say they aren't confusing. Either they're just smarter and less easily confused than you, or you're making a fool of yourself with theoretical criticisms about things you don't understand.
BTW, Java has an overloaded operator too. Do you get confused every time you see some code that concatenates strings?
First, classes are uppercase. Therefore "foo" is not a class, it is an instance. Oh, is that a rule of the language? Or is it a convention that programmers came up with to get around an ambiguity?
If you feel the need to make a public field for some reason, you can make its name lowercase. Or you can prefix it with an "F". Problem solved.
It's very important that one thing does one thing only, it would a completely different matter if the syntax for "foo.bar()" could mean something other than a method call. In the case of an attribution with properties you might get a method called as a result, and this might lead to catastrophes. And as I said before, classes are uppercase, so it can't be a static method, and "final" will only matter if you plan extending it. 1. It can mean something else, if "bar" is a property/field containing a method pointer. In that case it means "retrieve this value and then call it", and you won't know exactly what behavior results without knowing what pointer is stored there. (Not much of a problem in Java, I admit.)
2. Final does matter, because it affects the behavior of the method. If you know the static type of foo, then you know exactly which method foo.bar() will call - if it's final. If it isn't final, then foo could be an instance of a derived class with entirely different behavior for that method.
3. See above for my response to the case convention.
You don't have access to their code (or just don't care because the thing should "just work"), you will believe in their documentation. If the syntax is not consistent then the number of times you will need to consult the documentation in order not to destroy anything will increase a lot, therefore decreasing the productivity. Why the hell would I need to consult the documentation to find out whether a certain word refers to a field or a property? It's the 21st century. I'm using an IDE, it has access to the actual metadata and/or source code, and I can find out in one second by hovering my mouse pointer over the word. And I only have to do that if (1) the class was written with such disrespect for convention that it actually exposes public fields and (2) I'm completely unfamiliar with it.
That's why a method is better suited for it. Properties just add confusion. Hate to burst your bubble, but in the real world properties don't confuse anyone, hence the subject of this comment. Try asking someone who actually uses the language instead of making up theoretical criticisms that have no relation to actual practice. What you're saying here makes about as much sense as "Chinese people all look the same to me" - which they might indeed, if you've never met more than one or two.
You can't personally contact 100,000 people. The way to reach them is to put a box on store's shelves and let them buy your software. I don't believe that's the only way. It's not 1985 anymore. Political campaigns are able to raise millions of dollars from individual contributions, without even guaranteeing anyone that their money will produce any useful result, thanks largely to the power of the internet as an organizational tool. Sellaband does it with music, although their model isn't the greatest either. Finding those 100,000 people in advance isn't trivial, but it isn't an insurmountable obstacle either.
I know I'm gonna get modded Troll for this, but the business model of "let's do the R&D right away and let many people pay small amounts of money afterwards" works just as well as "let's try to secure the money first and then do a software with whatever money we got". It works just as well (or better) if your only metric is how much software gets written, or how quickly. But consider the fact that the first model must be propped up by a complicated system of laws that stifle freedom of speech, restrict technical and artistic innovation, and eventually lead to lawsuits against 10-year-old girls and C&D letters for 16-byte hex strings, while the second model is inherently stable. Just how much are you willing to give up to get software written a little faster?
But, it's trivial to write a program that for example:
* Remembers precisely every game that was played, so knows exactly which cards are left in the deck. (good players do this too, more or less anyways) That's not how poker works. The deck is shuffled after each hand.
However, there's still a good reason to track every hand you've played: to collect statistics on everyone you've played with. There's software available right now that does this, analyzing your saved hand histories to tell you how often each person bets or raises, how likely they are to fold at each stage of the game, how many starting hands they play, and so on. You can then use that information during play to decide not to play a marginal hand if you think the guy to your left is likely to raise, or to stay in with a weak made hand if the person betting is likely to be bluffing.
First, it's not a good programming practice to assume anything. The code in order to be considerable readable must expose all the information you need to know. So, are you saying "x = 5" and "foo.bar()" are unreadable because you can't tell whether x is a field or a local variable, whether foo is an instance or a class name, or whether bar is a virtual, sealed, or static method (or a field containing a function pointer) - or, for that matter, what state might be changed by the bar method?
No individual line of code can give you all the information you need to know to make sense of it. In order to be a successful programmer, you have to be able to hold enough context in your head to understand the code you're writing.
Second, what OO says is to hide the internal state of the objects, but there's nowhere saying that "properties are necessary in order to do that" or that "JavaBeans are the only way to do it". It's completely acceptable to have public fields, if the class design requires so.
Properties don't guarantee encapsulation! What properties and get/set methods do is give you the possibility to add validation or reaction behaviors in the future if they become necessary, without breaking source compatibility. If your code is full of lines like "x.Width = 5", what are you going to do when you decide you need to prevent Width from ever becoming negative, or react when it's changed (e.g. adding a log entry or redrawing something on screen)? In a language without properties, you have to go through and manually change all those lines; you could've saved a lot of time by using a setWidth() method in the first place. In a language with properties, you can change Width from a field into a property while maintaining source compatibility.
I spend millions of dollars, you give me $100, and you would like me to let you give it away for free to just about everyone who wants it. Sure the idea is noble, but where's the economic viability in that business model? It's a little late to fix your model here, because you've already made the mistake of spending ten years and millions of dollars producing something for which you can't really expect to recoup your investment.
The viable model would've been to realize from the beginning that you're performing a service, not manufacturing a product, and find enough people who are willing to pay you (or at least sign an agreement to pay) to produce the information in the first place.
Perhaps I didn't read as much into your "etc." as I should have, or read too much into the selective list of freedoms you mentioned. Still, I think it's a mistake to assume that people who download stuff for free don't truly care about the very freedoms they're exercising.
If you take a movie without paying for it, that movie studio has to reduce the "few cents an hour" it pays its employees. Duh. Ditto with the guys in the recording studio. Of course, the same is true if you simply choose not to buy a movie because you didn't like it, or you read a bad review, or you can borrow a copy from your friend. Doesn't mean I'm "guilty" of anything if I don't buy every DVD there is, or if I write a negative review, or lend my discs out.
The studio and its employees don't inherently deserve any more money than they can convince consumers to give them, and if they can't convince anyone to pay for a disc containing data that can be downloaded for free, it's up to them to find a better business model. One that involves selling something that can't be duplicated - like the labor they put into making the movie in the first place.
Sure you can. You can either use reflection to find the accessor method, or you can make an anonymous delegate to access the property. The latter also works with fields.
There are a core group of genuine activists who truly care about individual freedoms: the right to use something you bought in whatever way you want, the removal of restrictive DRM etc. They eloquently advocate consumer rights and fight for the rest of us to have these freedoms. But for the average moron in the street, this has nothing to do with that. It's about being able to copy stuff for free. And then there's the third group you conveniently ignore: the genuine activists who truly care about the freedom to share information, even information you've paid for. The ones who believe that the concept of requiring permission to share a number is inherently unjust and offensive, whether that number is a few bytes (like this key) or a few gigabytes (like a movie).
I don't know a graceful way to say this: stuff your IDE. All IDEs are memory hungry, bloated, and have frustratingly tedious editors. I don't expect the whole world to use vi(m), but I do and I am very very efficient with it. I cannot be nearly as efficient with an IDE. I know some IDEs have vi-like plugin editors but I find them pale imitations. And did I mention the memory usage? Memory usage? Visual Studio uses about as much memory as Firefox. We're talking about.NET and (most likely) Windows here, you know. You have to be a masochist to run those on a machine where memory is tight anyway.
Read: eventually you just learn to decipher the code and know that it is not what the syntax suggests it is. That's true anywhere. If I write "x = 5", is that assigning a field or a local variable? If I write "foo.bar()", am I calling a virtual instance method I can override, a sealed instance method I can't override, or is "foo" a class name and I'm calling a static method? Or maybe "foo.bar" is a field containing a function pointer (C++) or delegate (C#)? You have to know context to make sense of it. If you can't keep enough context in your head to understand the code you're writing, you can't hope to be much of a programmer anyway.
Sure, that's a useful skill, but it's not helpful, it doesn't enhance productivity, and it's not innovative. Oh, and it saves a paltry number of keystrokes at best. Not enough to justify the increased crypticness. It saves you a paltry number of keystrokes. It saves me a ton, because I use an IDE that takes advantage of stuff like this to save me time. I can type "okb.te=ma();" and have it come out "okButton.Text = MakeCaption();"
And finally, properties aren't cryptic in practice, because they can only be confused with public fields, which no one uses - public fields are deprecated, they don't produce the same metadata, and they're no more efficient when the JIT can inline property accessors. Private fields are typically distinguished by prefix or case, much like class names are distinguished from other identifiers (which is why I know "foo.bar()" probably isn't calling a static method).
What if I use a property thinking this is a field, and then the value doesn't get where it should? Even the mere concept of property doesn't solve anything, it saves only a few keystrokes from a proper method. Whenever you see an expression that could be a property or a field, assume it's a property. "Don't expose any public fields" is a guideline of OO design in any language.
That's Foo.getAdapter() you moron. And yes, it's much better. At least you *know* what's happening. With Foo.Adapter, you can't know for sure if it's a freely accessible field or a property mapped to setter and getter functions. The only way to tell is to look at the implementation of Adapter. First, who cares? The whole point of using properties is to make something that's conceptually a field but works a little differently under the hood, or (more commonly) simply to prevent a field from changing or limit the values the field can hold. Unless you screwed up when writing your setter/getter methods, the distinction between field and property should be unimportant to anyone using your class.
Second, if you're using a decent IDE, like the one most C# programmers use, then it'll tell you whether Adapter is a field or a property.
Finally, since public fields are frowned upon (as in most other languages), you can just assume that Adapter is a property, and you'll be right 9 times out of 10. Ask any experienced C# programmer how often they aren't sure whether a certain identifier is a field or a property: it simply isn't an issue in real life.
My company has something similar... it's called a programmable thermostat. The heating system turns off at night, but if someone's working late, they can walk over to the thermostat and turn it back on in temporary mode.
I have to spend $10 in mileage costs to go buy a physical CD. At $3/gallon for gas, you're using more than 3 gallons to drive to the music store and back? Do you live at the center of a giant labyrinth, or do you drive a stretch Hummer?
Forget the ancient red and blue though, as Real D uses "a specially polarized type of eyewear called circular polarized lens, which is very different from traditional 3-D in that it allows you to tip your head without losing the 3-D effect -- something you can't do with typical 3-D systems."
The first-sale doctrine has not been tested at the supreme court level in relation to downloaded music, but this is one case in which a conservative court is more likely to side against the record industry. The law says what it says; you'd have to be one of those so-called "activist" judges to read something into it other than what's on paper and side with the RIAA. Don't be fooled - those judges aren't "conservative" in the sense that they'd prefer not to overrule past decisions. They're just politically conservative. They'll happily read whatever they want into the law if it fits their ideology.
"Advocating a different IP scheme than you" is "a ridiculously insignificant aspect of life"?
I hate to break it to you, but copyright is a free speech issue, and speech is pretty damn important. What he did at the MPAA was no better than advocating any other form of censorship. Should we be sad about the deaths of book-burners too?
No, the problem with Stevens' speech was he obviously didn't have a clue what he was talking about, even if you look past the tubes metaphor. Bandwidth overuse does cause certain problems, but not the problems he mentioned.
Furthermore, if I remember the context correctly, he was trying to make an argument about net neutrality. The problems he mentioned had nothing to do with neutrality, and neither does bandwidth usage, because net neutrality is about discrimination based on who you are rather than how much you use.
I beat Super Paper Mario in a week, playing a couple hours a day. Probably would've taken half that long if there were a button to skip the slow, boring dialogue.
I got mine back in January just by driving around to different stores. Best Buy, Circuit City, and Costco were all sold out and had no clue when they'd be getting more. CompUSA had seven in stock.
Slashdot Mirror
You can't just overlook noncommercial copying if you want to use the business model of selling copies. But noncommercial copying is inherently hard to detect or prevent. If you want to have any chance of doing so, I think you'll eventually have to use the same mass lawsuit approach that the RIAA has, and/or push for technical means like the DMCA and Trusted Computing. The only alternative is to put an officer in every home, watching over everyone's shoulder to make sure they don't copy anything. But how much would you be willing to give up to get software written at all? The GIMP is quite good, but it tries to clone Photoshop. What would it have cloned if Photoshop hadn't been there first? It would've added the features people wanted, and might end up looking a lot like it does today. The designers of Photoshop don't have any special insight that others are incapable of having. You're not really suggesting there'd be no innovation in software if people couldn't develop first and sell copies later, are you?
There's a similar convention in
But now you're the one missing the point. You don't need source code because you have compiled metadata. If you have the library in binary form--which you must if you're able to compile your own project against it--then you can use all the IDE's popup help and completion features. You don't need it in your project or workspace, you just need a reference to it from your project, which is exactly what you need to compile your project too. Of course you can attach the documentation to Eclipse from an arbitrary piece of code, but you won't have it by default. Well, that sounds like a problem with Eclipse, because Visual Studio has no problem extracting metadata from a compiled library. It can even translate the metadata back into a class definition for you (sans method bodies). I don't think "operator overloading" is a theoretical criticism, in this case overloading the operator "=". You, who don't use C#, say properties are confusing. Thousands of programmers who actually use it every day say they aren't confusing. Either they're just smarter and less easily confused than you, or you're making a fool of yourself with theoretical criticisms about things you don't understand.
BTW, Java has an overloaded operator too. Do you get confused every time you see some code that concatenates strings?
If you feel the need to make a public field for some reason, you can make its name lowercase. Or you can prefix it with an "F". Problem solved. It's very important that one thing does one thing only, it would a completely different matter if the syntax for "foo.bar()" could mean something other than a method call. In the case of an attribution with properties you might get a method called as a result, and this might lead to catastrophes. And as I said before, classes are uppercase, so it can't be a static method, and "final" will only matter if you plan extending it. 1. It can mean something else, if "bar" is a property/field containing a method pointer. In that case it means "retrieve this value and then call it", and you won't know exactly what behavior results without knowing what pointer is stored there. (Not much of a problem in Java, I admit.)
2. Final does matter, because it affects the behavior of the method. If you know the static type of foo, then you know exactly which method foo.bar() will call - if it's final. If it isn't final, then foo could be an instance of a derived class with entirely different behavior for that method.
3. See above for my response to the case convention. You don't have access to their code (or just don't care because the thing should "just work"), you will believe in their documentation. If the syntax is not consistent then the number of times you will need to consult the documentation in order not to destroy anything will increase a lot, therefore decreasing the productivity. Why the hell would I need to consult the documentation to find out whether a certain word refers to a field or a property? It's the 21st century. I'm using an IDE, it has access to the actual metadata and/or source code, and I can find out in one second by hovering my mouse pointer over the word. And I only have to do that if (1) the class was written with such disrespect for convention that it actually exposes public fields and (2) I'm completely unfamiliar with it. That's why a method is better suited for it. Properties just add confusion. Hate to burst your bubble, but in the real world properties don't confuse anyone, hence the subject of this comment. Try asking someone who actually uses the language instead of making up theoretical criticisms that have no relation to actual practice. What you're saying here makes about as much sense as "Chinese people all look the same to me" - which they might indeed, if you've never met more than one or two.
* Remembers precisely every game that was played, so knows exactly which cards are left in the deck. (good players do this too, more or less anyways) That's not how poker works. The deck is shuffled after each hand.
However, there's still a good reason to track every hand you've played: to collect statistics on everyone you've played with. There's software available right now that does this, analyzing your saved hand histories to tell you how often each person bets or raises, how likely they are to fold at each stage of the game, how many starting hands they play, and so on. You can then use that information during play to decide not to play a marginal hand if you think the guy to your left is likely to raise, or to stay in with a weak made hand if the person betting is likely to be bluffing.
No individual line of code can give you all the information you need to know to make sense of it. In order to be a successful programmer, you have to be able to hold enough context in your head to understand the code you're writing. Second, what OO says is to hide the internal state of the objects, but there's nowhere saying that "properties are necessary in order to do that" or that "JavaBeans are the only way to do it". It's completely acceptable to have public fields, if the class design requires so.
Properties don't guarantee encapsulation! What properties and get/set methods do is give you the possibility to add validation or reaction behaviors in the future if they become necessary, without breaking source compatibility. If your code is full of lines like "x.Width = 5", what are you going to do when you decide you need to prevent Width from ever becoming negative, or react when it's changed (e.g. adding a log entry or redrawing something on screen)? In a language without properties, you have to go through and manually change all those lines; you could've saved a lot of time by using a setWidth() method in the first place. In a language with properties, you can change Width from a field into a property while maintaining source compatibility.
The viable model would've been to realize from the beginning that you're performing a service, not manufacturing a product, and find enough people who are willing to pay you (or at least sign an agreement to pay) to produce the information in the first place.
Perhaps I didn't read as much into your "etc." as I should have, or read too much into the selective list of freedoms you mentioned. Still, I think it's a mistake to assume that people who download stuff for free don't truly care about the very freedoms they're exercising.
The studio and its employees don't inherently deserve any more money than they can convince consumers to give them, and if they can't convince anyone to pay for a disc containing data that can be downloaded for free, it's up to them to find a better business model. One that involves selling something that can't be duplicated - like the labor they put into making the movie in the first place.
Sure you can. You can either use reflection to find the accessor method, or you can make an anonymous delegate to access the property. The latter also works with fields.
And finally, properties aren't cryptic in practice, because they can only be confused with public fields, which no one uses - public fields are deprecated, they don't produce the same metadata, and they're no more efficient when the JIT can inline property accessors. Private fields are typically distinguished by prefix or case, much like class names are distinguished from other identifiers (which is why I know "foo.bar()" probably isn't calling a static method).
Second, if you're using a decent IDE, like the one most C# programmers use, then it'll tell you whether Adapter is a field or a property.
Finally, since public fields are frowned upon (as in most other languages), you can just assume that Adapter is a property, and you'll be right 9 times out of 10. Ask any experienced C# programmer how often they aren't sure whether a certain identifier is a field or a property: it simply isn't an issue in real life.
My company has something similar... it's called a programmable thermostat. The heating system turns off at night, but if someone's working late, they can walk over to the thermostat and turn it back on in temporary mode.
Microsoft doesn't stop you from installing Windows on a Mac.
e isn't a physical constant, it's a mathematical one, and it can be related back to pi.
"Advocating a different IP scheme than you" is "a ridiculously insignificant aspect of life"?
I hate to break it to you, but copyright is a free speech issue, and speech is pretty damn important. What he did at the MPAA was no better than advocating any other form of censorship. Should we be sad about the deaths of book-burners too?
No, the problem with Stevens' speech was he obviously didn't have a clue what he was talking about, even if you look past the tubes metaphor. Bandwidth overuse does cause certain problems, but not the problems he mentioned.
Furthermore, if I remember the context correctly, he was trying to make an argument about net neutrality. The problems he mentioned had nothing to do with neutrality, and neither does bandwidth usage, because net neutrality is about discrimination based on who you are rather than how much you use.
It's not a "series of tubes". God, what a stupid definition.
It's an array of pipes!
I beat Super Paper Mario in a week, playing a couple hours a day. Probably would've taken half that long if there were a button to skip the slow, boring dialogue.
I got mine back in January just by driving around to different stores. Best Buy, Circuit City, and Costco were all sold out and had no clue when they'd be getting more. CompUSA had seven in stock.