Oh, no, sir. You've misunderstood me completely. I'm all for changing the language when it makes it more concise, more expressive, more descriptive...better. I'm against changing it in ways that make it more ambiguous and less clear. I'm not against evolution, because evolution is change that makes things better (on the whole—it's not against trying things out). And people like me ensure that evolution is what we get...not degradation.
Let's take my attitude to the extreme. Language gets better a lot faster. Let's take the attitude of the poster to whom I was responding to the extreme. We end up with two words that can mean anything at all. (Probably the f-word and dude.)
I don't mean most of my post aimed at you personally. I'm only trying to make the point that, today, most of the time people spend using computers is moving things from one place to another that should be automatic. If we demanded better from our machines, we'd get better results. If someone, somewhere in the world types in their address, that ought to be it. If I know that person and that person wants me to have their address, I should have it. And when they update it, I should get the new one automatically. That's the promise Internet. So where's my Internet?
I want an address book that lets me specify the OpenID URL of the person I'm interested in, and then the profile info that person has chosen to share with me is what I see. When they update and want me to see the new info, I see it. No typing, no pretending I'm using some paper address book from the 1960s. I'm using a computer, and I want it to serve me.
I just don't see how this future is ever going to happen if people think Excel is a reasonable solution for keeping addresses. Ooh look! It sorts!!! Big flaming donkey pile, I say.
You need your management to support you. The notion that they can drop a big codebase in someone's lap with the implicit expectation that it will be grok'd in a short period of time is poor management—knowledge and change management are not technical issues, they're business issues, and it sounds like management dropped the ball at your place.
There are two options here: (1) go above and beyond, and demand recognition for doing so, or (2) make it a management problem to get you trained and get the proper knowledge transferred. It is not your job to start cold, and management's expectation to the contrary is just bad management. If they didn't require the previous guy to write good documentation, then that's their chosen process and they have to deal with the consequences of such a management decision, which is that knowledge is now lost and can never reasonably be regained.
The most helpful thing you can do is make sure they fix their broken approach. If you do undertake the Herculean task of papering over prior poor management decisions, you just make it harder for the rest of us.
If we follow your way of doing things, then we end up with tragic situations like scan and bimonthly.
Scan used to mean examine carefully. With the advent of supermarket scanners—so named because they examined bar codes with far more accuracy than their human counterparts—people mistakenly associated "scanning" with the increase in speed, not accuracy. Due to this misconception, scan now has two opposite meanings: the original one, and the newer, stupider one, skim. Now when I say scan, it doesn't matter what I mean, I've used it correctly. Unfortunately, it doesn't communicate anything to my listener. I suppose that's an inconsequential detail in your way of thinking?
The same is true for bimonthly (biannually, biweekly, etc). One might initially wonder if this word means twice per month or every two months. That is, until one stops to consider other bi- words, such as bicycle (two wheels) and bisexual (interest in two sexes). Clearly, the prefix bi- has to do with two-ness, not half-ness. And yet, because of pea-brained common usage, we are now forced to accept two conflicting definitions, because the dictionary now incorrectly claims it may mean either. (No, I don't accept it just because it's in a heavy book.)
As an intelligent person, I used to have the choice of two different terms to mean two different things. If I wanted to communicate to you that something happens regularly six times per year, I could say it occurs bimonthly, and if it happens regularly 24 times per year, I could say semimonthly. Unfortunately, given the overwhelmingly popular and dimwitted usage, whatever I'm talking about had better be occurring 24 times per year so I can say semimonthly, as that is the only word we have left that requires no further explanation. If I'm in the unfortunate situation of having to explain something that happens every two months, I can try and use bimonthly, but it will immediately be followed by the question: Which definition of 'bimonthly' are you using? The smart one, or the one introduced into the language by idiots?
Or we may look at the history of the list-terminating comma. Correct: I have apples, pears, and limes. Incorrect (or at least, used to be): I have apples, pears and limes. Let us presume that I wish to convey various groupings using commas: bushels and baskets, packages and boxes, and bags. If I leave off the list-terminating comma, instead I end up grouping bags with packages and boxes, which I intended to be in its own group. This may not convince you if you're someone that likes to leave out the list-terminating comma. If that's so, and you choose to respond to this post, please do not dedicate your post to your parents, Ayn Rand, and god. Lest it come out: I dedicate this post to my parents, Ayn Rand and god. (No, I don't capitalize "god" just because I was told to in some other heavy book.)
And let us also consider the popular treatment of the word data as a plural, as in the ghastly These data are interesting. Now I know I'm going to raise the ire of many reading this post that think they're being clever by pretending data is a proper plural, but let me repeat: it is not. Data is an aggregative singular form, like sugar, hair, and information. You would not say, My hair are brown, or These sugar are sweet, any more than you ought to say, These data are interesting. All of these words imply a measure word which is singular. One infers the measure word, and that is why these terms agree with singular verb forms. Making the measure words explicit: My (head of) hair is brown, This (pinch of) sugar is sweet, and This (set of) data is interesting. I can go on at length on this topic and embarra
Unfortunately, this kind of software isn't going to achieve widespread penetration unless someone can build a schema simply and intuitively without having to know how databases work. I don't see why this shouldn't be possible either. If I'm creating an address list there's no reason why I couldn't put in a sample, drag over the text and say, "This is a person. It's the central thing of my entry. Here's the first name, last name, title, relationship to me. Here's the address. There could be many of these for each person. Here's the street number, street name, unit, city, state, zip, country. Here's a phone number. There could be many of these for each person. Here's the area code, exchange, suffix, and extension..."
In this way, using a single example and highlighting the various parts of the data and relationships, the software could build a schema that could store the information. Later, if I encounter a new type of address that I hadn't anticipated, the software could either change the schema and map the old data into the new schema, or just create another schema to the side for those exceptional cases. The point is that all of this could happen under the covers, the data would be as structured as I desire it, and any app could hook up to the same data source if only I'm willing to provide the mapping. (This mapping could be easy too—a new app unfamiliar with my particular schema could just display a sample entry and ask me to match up the terms that app uses with the parts of that sample entry.)
An address book isn't even the best use case for what I'm talking about, as there are plenty of apps already out there that provide this functionality. But it ought to be easy for me to quickly create a way of storing data in a structured way that I define that I can import/export in any way I wish, sort, select subsets, do simple visualizations, run quick calculations, keep securely, and use as a long-term storage solution if I so choose.
I use it to prototype and double-check formulas in software code.
I use a debugger and unit tests for that.
I use it to demonstrate changes graphically to people.
I agree that this is a good use for a spreadsheet, provided you don't keep the data driving the graphs in the spreadsheet itself. Unstructured data bad. And this is temporary. I know of at least a few companies that are working on good, intuitive visualization software for business and home users in which one can quickly create graphs over generic data. Most of the time, though, if you're using a proper application to keep your source data and there is a strong visualization requirement, the app itself will provide it. Financial packages like Quicken that provide pie charts of your personal finances come to mind.
I use it to create CSV files.
Why would anyone want a CSV file? This is purely an interchange format like XML—these were never intended to be persisted to disk for long-term storage, it's merely an intermediate format to be used between two other, useful formats. (Yes, I know that XML is also persisted to disk and now considered a permanent data format. And it's one of the things holding back the world.)
I certainly won't fault someone for sticking an address into it and hitting the "Sort" button once in a while.
I would. Use your gmail contact list. Or -shudder- use Outlook's address book. Then you don't even have to hit "Sort".
Lots of people just keep a flat text file. My mom still has an actual book from the 70s.
Lots of people make lots of mistakes. That's no reason to adopt mistake-making as a lifestyle.
I happen to use a Mac, which has an excellent address book and password storage utility built-in, so I don't need Excel for those tasks:) Firefox also keeps most passwords in a file somewhere.
Here you're agreeing with me. Excel sucks for that stuff, so you're using applications that don't suck. If you really think hard about it, I'll bet you'll be hard-pressed to come up with a use for Excel that there isn't some better app available.
My wife's biotech company recently asked one of the scientists to take over the database. When I asked why the company would want a scientist to own a database when they have a perfectly capable IT staff, my wife's coworker (our friend) replied: Oh, because the IT staff doesn't understand the data. You have to understand the experiments and how the data is collected in order to properly load it into the database.
Wha?!, I wondered. Why on earth would someone loading data into a database have to understand that data in order to load it properly? In fact, why is one loading data into a database manually to begin with? And what form is the data in prior to being loaded? The answer to all these questions became clear when our friend explained that the scientists are the company tabulate all their data in Excel spreadsheets, from which the columns must be mapped into the database. For each experiment, the scientist creates a new spreadsheet and more or less randomly orders the columns, so without an understanding of experimental procedures one could not make sense of the data and know how to load it properly.
Um, I wonder, Why are they paying a scientist's salary to screw around with spreadsheets and learn IT functions when you could be doing science? Why don't they just hire a programmer to write a simple app that allows scientists to input data (or import data directly, in the case of a scientific apparatus that can output the data in a known format) to the database? This would certainly be cheaper than this on-going, error-prone process of doing things in which each scientist maintains their own spreadsheet templates and tweaks them for each and every experiment.
Well, she replied, this is how all of the big biotech firms do it. And she's right. I've talked to people since that have worked at Genentech, AmGen, Novo Nordist, etc, and they all do the same stupid thing. And they all keep the data in the database in a fixed schema (it differs from company to company, but all experimental results are eventually pushed into the same DB schema across the company as a whole).
This is my problem with spreadsheets. They're not very good at doing calculations (unless you like looking for typos). Mathematica/Maple for computations and Minitab for statistical analysis are far better apps for doing everything from quick'n'dirty calculations to extensive mathematical work. Spreadsheets are not very good for most of the things they're used for—expense tracking, project scheduling, budgeting, address book, the list goes on. The ubiquity of the spreadsheet has inhibited the spread of proper solutions more than any single other piece of software I can think of.
This proves my point precisely. The spreadsheet has somehow become the application that stands in as a kind of generic app when people don't stop to think about using something more appropriate. By suggesting a better application than Excel to store passwords, you've shown one example in a never-ending stream. What I mean to say is: no matter what scenario one comes up with for using a spreadsheet, I can come up with a different, better application.
Let us recall the original purpose of the spreadsheet, and here I do not refer to the whiz-bang computer application, but the actual paper spreadsheet. It is an accounting tool. Even most accountants no longer use spreadsheets. It is one of the strange additions to the "standard" suite of office applications that at some point a few people in some companies somewhere decided everyone should have access to, and they gave us that hammer, and now my personal data must be a nail because I happen to have a hammer.
No, we need personal database software. The terabytes of data that homes will soon be accumulating require a better storage solution than a spreadsheet. Example: I have memberships on a lot of sites, like here. I can't remember all my passwords. I could keep them cleartext in a spreadsheet, or someone could allow me a means of storing them in my personal DB that a keyring app could hook up to (or me directly, from the mysql prompt, if I have the knowledge to do so and so choose).
Unless a design defect is discovered in a line of locks, picking one (or creating a specialized pick) does not grant all would-be attackers instant access. The best it can do is lower the barrier to entry, it can make the task easier. Physical access, time, and a certain level of skill are still required of the attacker.
You've never played with a lock-pick set, have you? You can get past most knob-locks and deadbolts with a torsion wrench and a rake in under 10 seconds. The time investment required to achieve this level of expertise? About 15 minutes of playing around. The time investment to make your own lock pick set? Maybe a couple of hours if you go really high-end, but probably could be done in around a half hour if you know what you're doing.
Unless you're dealing with a tubular lock. Those things are, like, impossible to pick (unless you happen to have a highly specialized device called a ballpoint pen).
I remember one summer in college, rooming with a guy that went to CalTech during the school year. When I learned this, I waited for summer to begin with great anticipation, as I knew that every freshman is required to develop good lock pick skills at CalTech, and I would find a way to make myself the beneficiary of that knowledge. So it was almost a letdown when he showed me how to pick locks and within the half hour I was able to breeze through most locks I encounter in daily life as if they weren't even there. So much for a highly specialized skill.
There could be no flaw more basic than what is proposed in TFA.
Person 1 pays Company A for some product. Company A wants to send product to Person 1 so that Person 1 can enjoy product. But they want to do it in such a way that Person 1 cannot be trusted not to publish product for Persons 2, 3, etc. No amount of filtering, encryption, copyright protection, etc, in the world is going to help Company A achieve this goal.
Now let's look at untrusted Person 1. Person 1 has content that they want to transmit to Persons 2, 3, etc. In this communication, both Person 1 and Person 2 are "trusted". The information holder, Person 1, doesn't really care what Person 2 does with the information, so it's a very low bar Person 2 must clear to fit the trust criteria. Basic encryption allows two trusted parties to communicate information such that no other entity, whether Company A, ISP K, or Person 3, can eavesdrop. Period.
These are the fundamentals. They cannot be changed. As long as Company A can't trust the paying recipient to not redistribute the information, there is no technology that can help them.
The only model that will work is for Company A to transmit information to some trusted endpoint, say Provider Omega, and then require Person 1 to contact Provider Omega for some derivative of the product. The derivative has to be something Company A doesn't care about. Example: I, the copyright holder, post a photo on shutterfly gallery and send a link to untrusted Mom. Mom goes to link, sees photo thumbnail (derivative of photo no one cares about untrusted Mom stealing), orders print (another derivative no one cares about—if untrusted Mom gives photo to third party, that's fine with everyone).
Of course, the problem our Company A faces is quite different. Person 1 isn't buying a derivative of product, like untrusted Mom is happy to do. Person 1 wants the thing itself. No matter how many trusted third parties Company A contracts to stick DRM-enabled DVD drives in Person 1's computer, or ISPs that monitor Person 1's network traffic, or jack-booted thugs that break into Person 1's house, at the end of the day the technology serves only communications with trusted endpoints and no other kind. The only way Company A can keep Person 1 from distributing product is to not give product to Person 1 and instead substitute some derivative they don't care about. But if they don't care about it, neither will Person 1, and Person 1 will not buy it.
Forget it. You are powerless to combat the constant marketing machine that has brainwashed the vast majority of women. Regardless of what you say now, you are less than 10% likely to not buy a diamond at some point in your life if you enter a serious relationship. I've known many guys that sing the same tune. Not one has placed their principles over their honey when push comes to shove. (And that is why De Beers is rich.)
"Google's" "PageRank algorithm" is actually an implementation of a very powerful, general mathematical principle. Math applies to more than just the web.
Well, if you consider the goal at $1M, they accomplished that goal and added $1 extra for every $10 of the goal. That's kinda like killing every tenth dollar in line. I admit, it's a stretch, but seems like an somewhat appropriate (though unintentional) usage to me.:-)
The fact that people paid DOES NOT mean people are paying for music due to quality or ease of use. They are paying out of CHARITY.
Clearly, the music, the quality of the music, and ease of use have something to do with the fact that people paid. Without those elements in place, I doubt that many of the people sending money would've still sent their money to Radiohead. I'm not arguing here that $2.40 per album is the definitive golden amount that albums are worth...I'm saying, in general, that in a world full of piracy there's money to be made by bands making music. The jury's still out on exactly how much and exactly what form it will take. The main point is that the band is more motivated to get their music into the hands of others than anyone else in the world. The extra work they're willing to do to make that happen is a valuable service that customers will pay for. I don't claim to know how much and the mechanism whereby the money will be transacted, but clearly there is something there.
At the same time, regardless of whatever technology you're talking about, there will always be those that are committed to getting that music for free. And they will succeed. They will succeed because there is no fundamental way to stop these people. It is a well-known cryptographic principle that if person A (Radiohead) is trying to communicate information (music) to person B (Joe Average) while preventing person C (a pirate—ARRRRR!!!), it is absolutely essential that the two communicating parties be trusted. Specifically, that neither A nor B will share that information with C. In this case, Radiohead can't possibly trust Joe Average in every case to keep their music from a pirate. Hence, there is no way in principle to sell music to B in a way that C always ends up either without the music or paying for the music.
As a practical matter, however, it is good business to recognize the inflection point at which C becomes so dedicated to theft that it is no longer worthwhile to prevent it.
As to CD sales at a concert, if I have been told correctly, when you are signed to a label those are not part of concert revenues but rather, CD revenues which go into the same machine as sales at wal-mart. This is why I lump that into cd sales rather than concert revenues.
Let us presume you are right. If that is so, then the amount of money passed through to the band from CD sales at concerts is the same as that passed through from CD sales at Wal-Mart—for most bands, this is effectively no money until their 100,000th sale, as it takes that many CDs to pay off their debt to the label (I don't know if it's 100,000 or 20,000 or 1 million, but you get the point). After that magic number, the band starts making money from each sale...but it's a tiny amount for the vast majority of bands. So even for fairly well-known bands, if they're not in the A-list upper echelon, the vast majority of their income comes from concert tickets, promotions, endorsements, and other activities not covered by the contract with the label.
If I was right in my last post, and CDs sold at concerts are considered concert revenue, the band gets to keep all the proceeds from this vanishingly small percentage of overall CD sales, so that's even better for them. Notice, though, that in either case, whichever way it goes, if the band's not playing concerts then these CDs sold at the concert venues don't exist at all. There's no option that allows even those sales if the band isn't playing concerts.
As to windows, all I can say is I know a grand total of 4 people that have ever paid 300$ for windows. The other 400 or so paid about 25 dollars(or got it free depending on how you look at it) and it was legal.
This is untrue. You've met dozens if not hundreds of people that have paid more than $25 for Windows. I'll bet you've even met a few people that have paid for a legal copy of Windows without actually gettin
...demand at a price of 0...doesn't help a company in any way shape or form figure out what is the correct way to do business.
You're right about this...it doesn't help them figure out a correct way to do business. This is as it should be—as a customer I don't feel I ought to be compelled to help companies. As a business man I wouldn't expect it of my customers, either. Because, as you correctly point out, it doesn't work.
...2.40$ is a legitimate amount [Radiohead] could demand from any record company for their cd's
Well, they could demand it before, but they certainly wouldn't get it. Now they can realistically demand it because they have another avenue. As a point of contrast, Metallica doesn't get nearly that much per CD through their super-sweet deal with their label.
I only personally know 2 artists(successfully making a career in music) and I can say both turn most of their money by sales of cd's after small scale concerts.
Umm...those CD sales actually count as concert revenue, along with tickets and t-shirts and all the other trinkets they sell at concert venues. So basically, you're unwittingly saying now what I said in the last post—bands don't earn anything from their contracts with their labels, it's all concert sales.
that a popular band finds fans loyal enough to pay them is equivalent of me bringing up metallica as a band against piracy : NEITHER are in any way average.
I wasn't using Radiohead (or Metallica, for that matter) in my argument in any way that requires them to represent the average. So my point still stands. I did use them to refute your assertion that, if music is free, people won't pay for it. So what I did was find a specific, relevant example where the music is free, and people still paid for it. Furthermore, my point was that they paid for it happily because service does matter, and getting it from Radiohead's site was easier and less risky than from Pirate Bay. And people are willing to pay for music that's easily obtained, even when not being required to do so. (I'm not really big on rehashing my arguments several times over, but it seemed like you really missed what I said on this one.)
the market is simple: any way buyers and sellers come together and can communicate through actions the prices they are willing to deal at. piracy is NOT the market because it lacks 1/2 the equation: the seller.
Well, you're free to believe that piracy is separate from "the market" and it doesn't communicate anything important, but if you want to run a successful business it pays to take account of reality with all its warts. Or you can stick your head in the sand and say, This isn't the way it should be, so I'm going to operate as though it isn't. Good luck with that.
I have choices between paying 0 and x$ after deciding I would like to consume, even if I value the object at 10*x, I will still pay 0$.
That's you. Not to offend, but frankly, no one's interested in you. I'm talking about Joe Average. Radiohead posted their album for free, and 60-some % of the downloaded were unpaid. Of the 40% or so that paid something, the average payment was $6. If you run the numbers like I did, you too will find that Joe Average paid $2.40 per download. Joe Average is who we're interested in, and Joe Average isn't doing what you do. So what have you got to do with this discussion?
but the fact that the downloading scene is so massive and vibrant(probably rivaling record sales in a given year) leads me to believe that overall music consumption is UP, not down in the last few years.
You were led correctly. Music consumption is up, and as more music is pirated through file-sharing, record companies are making more money. They're not advertising that, but it
I've never once seen a 14 year old tithe any real amount of money to any war chest of a corporation.
What's the biggest demographic that buys what the large music labels are selling?
It's amazing what a financial incentive can do.
True—but why is it different this time? The same argument has been rolled out after every new technology advance. The first time someone could tape a song off the radio and play it any time they wanted, for instance.
...you will never have to pay for music again... and it's better quality than any online store even comes close to offering.
So...explain to me why it's reasonable for music companies to expect me to get in my car, go down to the mall, pay $20 for a CD that contains 13 songs I don't want and one that I do when I can download the one song that I want right now..."and it's better quality than any online store even comes close to offering." You're making my point for me. The music companies aren't making it convenient for people to give them money.
[Rod Serling's voice] Picture if you will, a man who knows nothing about BitTorrent pays $1 for a top-quality recording of a new song that begins playing within seconds. Doo-doo-doo-doo, doo-doo-doo-doo.
If I download the entire garth brooks, michael jackson, beatles, alan jackson, and 3 more artists COMPLETE works in 1 night, it's a different story. It's hard to compare the losses between the two.
This is a common argument made against piracy. The first time I visited the Microsoft museum in Redmond, they had erected a giant LED board that constantly ticked up the total loss incurred by MS due to software piracy. However, I would point out that just because you download the complete catalogues of these artists does not mean they have incurred losses equal to the retail price associated with the CDs containing those songs. This is the logical fallacy of the false dilemma—it presents a choice between two and only two options—buy the complete works of 7 musicians or download it for free—when there is really a third, and far more likely option: do nothing at all.
If I download a cracked copy of Adobe FooBar and install it, this only costs Adobe money in the case that I would've gone out and bought a copy of Adobe FooBar had the cracked version not been available. In the case of Adobe FooBar, however, I can tell you without a doubt that it's so expensive, if I don't get it pirated, I won't be getting Adobe FooBar at all. I'm pretty sure there's not a marketing executive alive that would tell you they'd rather have someone not using their product than using it without paying. The illegal user promotes marketshare, brand recognition, mindshare, and a list of other minor benefits that a non-user doesn't.
Why do you think Microsoft didn't secure early versions of all their software so that it was uncrackable? Are you under the misapprehension that the necessary technology and methods don't exist?
Concerts are not an equivalent form of paid work for an artist and it's ignorant to think it is.
Do you know how many albums a band must sell under the standard record label contract before they break even with their label? And then, once they break even, do you know how much of that $20 CD retail price actually ends up in the average musician's pocket for each subsequent CD? It's fashionable these days to think that Metallica, one of the biggest crabs about all this P2P filesharing movement, represents the average band. They do not. Metallica cares so passionately about filesharing because they are one of the very few bands in existence that has negotiated very favorable terms with their label, and so they actually do make money off of album sales. Most bands do not. Most bands yield all or most of their album profits to
The OP is framing this discussion improperly. This shouldn't be a discussion about morality or ethics; this should be a discussion about what is and what will continue to happen.
The fact of the matter is that companies want the right to sell whatever product or service they like, without being compelled to package those products and services in any way by the government. In this particular case, they're lobbying government to correct the slight of omission against the industry—that is, they feel victimized as no one is really helping them stop so-called "illegal" downloads from occurring and it's law enforcement's duty to step in.
Well I personally believe that any business should have the right to sell whatever they want, packaged any way they want (a broad and untrue generalization if ever there was one, to be sure—certainly we don't want to go back to the early 20th Century robber barons, so there have to be some controls in place to deal with monopolies and such). And I don't support any action that would compel me, were I to start a business, to package my products or services in any particular way. What I sell and how I sell it is a problem for the free market to solve, not government. What companies further want, and will never have, is the right to sell whatever they want packaged any way they want free of restrictions from the customer. This, quite simply, will never happen in any business. At the end of the day, in a capitalist democratic republic, the people can and always will vote with their dollars, and I don't believe that's going to change any time soon, nor should it. We can argue ethics until we're blue in the face, but it won't change reality...specifically, if people don't want to pay for what you're selling and there's an easier, more convenient way to get it, then that's what's happening. Forget about asking Is it right? Is it fair? Instead, try: Is it moot?
Businesses ought to be smart enough to sell customers the products and services they want in the way the customers want them packaged...this isn't rocket science, it's just good business. Music companies used to sell us music, and if you had the tools, you could legally make as many reel-to-reel or cassette tape copies as you wanted, provided they were for your personal consumption (turns out that it's considered "personal consumption" if you take your music over to a friend's house and play it there). Practically, the music companies may not have liked the idea of the time-honored tradition of guys making their sweeties mix tapes from copyrighted CDs...but they were smart enough, after some initial friction I'm sure, to lay off and let things unfold naturally. Sure, they included toothless legalese and mostly kept up a facade of controlling things, but everyone—and I do mean everyone, including those in the biz—regarded such restrictions as quaint. So how did this work out for business? Why didn't the mix tape deep-six their profits? Because mix tapes signal emotional investment to the sweetie-in-question for one big reason: they take time and effort. Music companies that provided music to customers in a way that they found convenient and enjoyable could still generate a good buck.
This time, however, it's completely different (much like it was completely different all the other times, too: cassette deck, reel-to-reel, VCR, CD-R, etc). The fact of the matter is, music companies want to sell people rights nowadays, not music—the right to play this song on this device, the right to transfer this song from device 1 to device 2. But people don't want to pay for these rights...customers want to pay for music. Dealing with companies to buy a legal abstraction is too troublesome when all people want is music, same as they've always had. Since the companies aren't selling music, though, the only way to get it is to steal it. These companies are all too willing to dig into their war chests to pro
This is clearly an intractable problem that cannot be solved any other way. Blame the technology!
Seriously, no piece of technology can be blamed for poor time management. Neither can one blame one's manager for allowing that person to manage your time poorly for you.
This is an issue of ownership. Own your job, own your time, and take responsibility for yourself. If everyone's doing what they should be doing, then this discussion is moot. If everyone's not doing what they should be doing, then how about having that discussion instead of some hypothetical potential abuse you fear by those above you?
My attitude toward my managers is this: if you're a good manager, then you're going to remove the obstacles I tell you are blocking me from doing my job. If you're not going to behave that way, then you're irrelevant to my core duties, and I'm going to invert our relationship. In other words, now I'm your manager, in the sense that I have to manage you as yet one more obstacle in my path to completing my tasks. If I do my job as your manager correctly, you'll trundle along happily and never know that I think of you as essentially a child out of your depth. If you become too much of a problem, I'll take me and my record of success somewhere else where I can work with adults.
"A unit of data is not necessarily the same as knowledge"
"Knowledge is a vague term"
"There is no unit of knowledge; that is to say: knowledge cannot be quantified"
These are all of the atoms of knowledge contained in your post. Because I was able to identify them, perhaps they are not so vague after all (at least not to humans...machines are a different story, but by that standard faces were vague until recently as well). This leads me to another question: does a knol have to be correct to be a knol, or is there such a thing as an incorrect knowledge (as I, apparently, am arguing would apply to 3 and 4 above)?
If these are knols, then what would we call compositions of knowledge atoms (knowledge molecules, if you will)? And how many knolecules are there in your post?
(Yes, that was a long way to go just to be able to say knolecules.)
Though I'm sure you can design a particular application in which a square is behaviorally a rectangle, and therefore it would be ok to have square extend rectangle, it is not universally the case.
One of the best things I ever did was head over to Object Mentor's published articles page and click on the Design Principles category. There you will find a paper on the Liskov Substitution Principle which defines exactly when it is appropriate for one class to extend another. (You won't go wrong reading all the papers in that Design Principles category—I found them riveting for hours on end.)
In this particular case, behaviorally speaking a rectangle has two degrees of configuration freedom whereas a square has one. So, if you think about the actual practice of defining a Rectangle API with get/setWidth() and get/setHeight() methods, you could then write a unit test against those methods to fix the proper behavior of a rectangle. One of those unit tests might go something like: {1} set width to 1, (2) set height to 2, (3) assert that getArea() returns 2. I challenge you to now implement the subclass of rectangle called square that will pass this unit test which behaviorally (and correctly) verifies rectangle-type behavior.
Your suggestion of making squareness an attribute of rectangle is interesting and one I have not yet heard in any of the instances I've presented this example. I imagine it would take the form of something like the method boolean Rectangle.isSquare(), and would return getHeight()==getWidth(). This would work, as long as clients to the rectangle API understood that its square-ness is temporally defined and could change in the next moment. This is, however, an important consideration, though. In making this a requirement of what it means to be a square, nearly all definition of the square is itself lost...the concept of a square becomes a temporal thing itself. The old mathematical standby of an object that forever and always has equal sides is no longer relevant to this implementation.
"A square is-a immutable rectangle..." Your point is well-taken, and this addition of immutability goes a long way to aligning OO with mathematics. Even this is not universally true, though it is obviously true in almost all cases. Theoretically, I can think of an application in which it would not be appropriate to make an immutable square extend an immutable rectangle.
Say I'm writing an application that applies mathematical transforms to 2D geometrical objects and creates a new object based on the result. Let us further presume that all such transforms must be defined such that they are operations that exhibit mathematical closure. In other words, if the transform operates on circles, the result of such operations must also be circles.
I define a transform that operates on immutable rectangles as arguments. Specifically, it is a unary operation that takes a rectangle and produces a result that is 2x in width and the same in height. If I pass in an immutable rectangle with dimensions [4,1] I get back a new rectangle with dimensions [8,1]. In this scenario, for closure to hold, both the input and the output must be from the same set (rectangles). If I now mistakenly let square extend rectangle, this transform is no longer meeting the requirement that it demonstrate closure. The compiler will allow me to pass a square to this method as a rectangle argument, but instead of producing a result from the set of squares, it will most certainly produce something from the set of rectangles as a result. If I'm creating this new type square as I did rectangle—in order to treat it as a new kind of set on which a set of transforms can operate with closure—then allowing it to extend rectangle is most definitely a mistake.
I wish to avoid a detailed discussion of the subtleties of this particular example (as I believe that I would quickly find myself out of my depth) and trust that my point has landed...which is: we can say that a square should not extend rectangle, and regardless of the application under consideration, it is universally true that such a design allows us to respect all OO principles. On the other hand, it is only true for a subset of these applications that we can respect OO principles if square does extend rectangle (square and rectangle must be immutable in certain ways, etc).
When you define an API, it should always be in service to what clients may want. So, if the physics app you are trying to write would be concerned with the gravitational aspects of a relatively tiny ball, then I agree, by all means add your method. On the other hand, if clients would never be interested in calculating the gravitational force of two balls out in deep space (or some similar application), then adding such a method unnecessarily complicates things.
One thing to keep in mind is that OO code is not math or physics. Consider the following classic example: I'm writing a geometry library and I have a Shape interface. I implement that interface with Rectangle, Circle, Triangle, etc. Then I get to Square. Should Square extend Rectangle? After all, a square is a kind of rectangle, as every schoolboy knows...right?
Except in this case, it's not. A square may be a type of rectangle in geometry, but in an OO system it would be improper to represent a square as a subclass of rectangle because behaviorally speaking a square and a rectangle are different, and OO regards classes as behavioral objects, whereas geometry regards shapes as characteristic objects. In other words, in geometry, if you have 4 sides and 4 90 degree angles (in Euclidean space) you're a rectangle. A square has those things, so it's a rectangle. In OO, since a rectangle and a square behave differently with respect to pretty much every sensible API you could assign to each, Square is not a subtype of Rectangle.
Of course, that's a great example because it's pretty much true across the board. Very few examples are true in that way—in nearly all cases, f you're arguing with a colleague about whether this should extend that or aggregate this other thing, context matters. I've often discussed possible designs with colleagues where they correctly argue that, for some particular application, their approach is correct. What I always try to get them to focus on (if we have a disagreement) is forget about some general, archetypal application. In our application, in this context, does it make sense?
Example: should Automobile aggregate Engine or should Automobile associate an Engine? (The difference is: aggregation implies a "part-of" relationship in which the containing object partially derives its identity from the contained object, implying the two have similar lifetimes. For instance, a building aggregates a room because it doesn't make sense to have a building with no rooms or a room without a building, when you new up a building the constructor ought to new up one or more rooms, they're born together and they die together. A surgeon and a scalpel, however, are a different story. A surgeon may never use a scalpel for a particular surgery because only other tools are called for, so that would merely be an association...a surgeon is still a surgeon, scalpel or no, but what would you call a building with no rooms?) In this case, it's impossible to say whether Automobile should associate or aggregate an Engine. If the clients of the Automobile API are owners that will only be interested in driving it, then it should probably aggregate Engine. If the client using the Automobile API is an auto manufacturing plant, then perhaps it makes sense to merely associate the two.
This is the problem with your answer above. It takes no account of the actual application the end user has in mind for the Ball class...you simply state that you would do it X way. If clients desire that behavior, great...but if none of the use cases would ever need that kind of functionality, you might be adding complexity with no pay-off.
Slashdot Mirror
Oh, no, sir. You've misunderstood me completely. I'm all for changing the language when it makes it more concise, more expressive, more descriptive...better. I'm against changing it in ways that make it more ambiguous and less clear. I'm not against evolution, because evolution is change that makes things better (on the whole—it's not against trying things out). And people like me ensure that evolution is what we get...not degradation.
Let's take my attitude to the extreme. Language gets better a lot faster. Let's take the attitude of the poster to whom I was responding to the extreme. We end up with two words that can mean anything at all. (Probably the f-word and dude.)
Duuuude. That's totally f'd up.
I don't mean most of my post aimed at you personally. I'm only trying to make the point that, today, most of the time people spend using computers is moving things from one place to another that should be automatic. If we demanded better from our machines, we'd get better results. If someone, somewhere in the world types in their address, that ought to be it. If I know that person and that person wants me to have their address, I should have it. And when they update it, I should get the new one automatically. That's the promise Internet. So where's my Internet?
I want an address book that lets me specify the OpenID URL of the person I'm interested in, and then the profile info that person has chosen to share with me is what I see. When they update and want me to see the new info, I see it. No typing, no pretending I'm using some paper address book from the 1960s. I'm using a computer, and I want it to serve me.
I just don't see how this future is ever going to happen if people think Excel is a reasonable solution for keeping addresses. Ooh look! It sorts!!! Big flaming donkey pile, I say.
You need your management to support you. The notion that they can drop a big codebase in someone's lap with the implicit expectation that it will be grok'd in a short period of time is poor management—knowledge and change management are not technical issues, they're business issues, and it sounds like management dropped the ball at your place.
There are two options here: (1) go above and beyond, and demand recognition for doing so, or (2) make it a management problem to get you trained and get the proper knowledge transferred. It is not your job to start cold, and management's expectation to the contrary is just bad management. If they didn't require the previous guy to write good documentation, then that's their chosen process and they have to deal with the consequences of such a management decision, which is that knowledge is now lost and can never reasonably be regained.
The most helpful thing you can do is make sure they fix their broken approach. If you do undertake the Herculean task of papering over prior poor management decisions, you just make it harder for the rest of us.
If we follow your way of doing things, then we end up with tragic situations like scan and bimonthly.
Scan used to mean examine carefully. With the advent of supermarket scanners—so named because they examined bar codes with far more accuracy than their human counterparts—people mistakenly associated "scanning" with the increase in speed, not accuracy. Due to this misconception, scan now has two opposite meanings: the original one, and the newer, stupider one, skim. Now when I say scan, it doesn't matter what I mean, I've used it correctly. Unfortunately, it doesn't communicate anything to my listener. I suppose that's an inconsequential detail in your way of thinking?
The same is true for bimonthly (biannually, biweekly, etc). One might initially wonder if this word means twice per month or every two months. That is, until one stops to consider other bi- words, such as bicycle (two wheels) and bisexual (interest in two sexes). Clearly, the prefix bi- has to do with two-ness, not half-ness. And yet, because of pea-brained common usage, we are now forced to accept two conflicting definitions, because the dictionary now incorrectly claims it may mean either. (No, I don't accept it just because it's in a heavy book.)
As an intelligent person, I used to have the choice of two different terms to mean two different things. If I wanted to communicate to you that something happens regularly six times per year, I could say it occurs bimonthly, and if it happens regularly 24 times per year, I could say semimonthly. Unfortunately, given the overwhelmingly popular and dimwitted usage, whatever I'm talking about had better be occurring 24 times per year so I can say semimonthly, as that is the only word we have left that requires no further explanation. If I'm in the unfortunate situation of having to explain something that happens every two months, I can try and use bimonthly, but it will immediately be followed by the question: Which definition of 'bimonthly' are you using? The smart one, or the one introduced into the language by idiots?
Or we may look at the history of the list-terminating comma. Correct: I have apples, pears, and limes. Incorrect (or at least, used to be): I have apples, pears and limes. Let us presume that I wish to convey various groupings using commas: bushels and baskets, packages and boxes, and bags. If I leave off the list-terminating comma, instead I end up grouping bags with packages and boxes, which I intended to be in its own group. This may not convince you if you're someone that likes to leave out the list-terminating comma. If that's so, and you choose to respond to this post, please do not dedicate your post to your parents, Ayn Rand, and god. Lest it come out: I dedicate this post to my parents, Ayn Rand and god. (No, I don't capitalize "god" just because I was told to in some other heavy book.)
And let us also consider the popular treatment of the word data as a plural, as in the ghastly These data are interesting. Now I know I'm going to raise the ire of many reading this post that think they're being clever by pretending data is a proper plural, but let me repeat: it is not. Data is an aggregative singular form, like sugar, hair, and information. You would not say, My hair are brown, or These sugar are sweet, any more than you ought to say, These data are interesting. All of these words imply a measure word which is singular. One infers the measure word, and that is why these terms agree with singular verb forms. Making the measure words explicit: My (head of) hair is brown, This (pinch of) sugar is sweet, and This (set of) data is interesting. I can go on at length on this topic and embarra
Unfortunately, this kind of software isn't going to achieve widespread penetration unless someone can build a schema simply and intuitively without having to know how databases work. I don't see why this shouldn't be possible either. If I'm creating an address list there's no reason why I couldn't put in a sample, drag over the text and say, "This is a person. It's the central thing of my entry. Here's the first name, last name, title, relationship to me. Here's the address. There could be many of these for each person. Here's the street number, street name, unit, city, state, zip, country. Here's a phone number. There could be many of these for each person. Here's the area code, exchange, suffix, and extension..."
In this way, using a single example and highlighting the various parts of the data and relationships, the software could build a schema that could store the information. Later, if I encounter a new type of address that I hadn't anticipated, the software could either change the schema and map the old data into the new schema, or just create another schema to the side for those exceptional cases. The point is that all of this could happen under the covers, the data would be as structured as I desire it, and any app could hook up to the same data source if only I'm willing to provide the mapping. (This mapping could be easy too—a new app unfamiliar with my particular schema could just display a sample entry and ask me to match up the terms that app uses with the parts of that sample entry.)
An address book isn't even the best use case for what I'm talking about, as there are plenty of apps already out there that provide this functionality. But it ought to be easy for me to quickly create a way of storing data in a structured way that I define that I can import/export in any way I wish, sort, select subsets, do simple visualizations, run quick calculations, keep securely, and use as a long-term storage solution if I so choose.
I use a debugger and unit tests for that.
I agree that this is a good use for a spreadsheet, provided you don't keep the data driving the graphs in the spreadsheet itself. Unstructured data bad. And this is temporary. I know of at least a few companies that are working on good, intuitive visualization software for business and home users in which one can quickly create graphs over generic data. Most of the time, though, if you're using a proper application to keep your source data and there is a strong visualization requirement, the app itself will provide it. Financial packages like Quicken that provide pie charts of your personal finances come to mind.
Why would anyone want a CSV file? This is purely an interchange format like XML—these were never intended to be persisted to disk for long-term storage, it's merely an intermediate format to be used between two other, useful formats. (Yes, I know that XML is also persisted to disk and now considered a permanent data format. And it's one of the things holding back the world.)
I would. Use your gmail contact list. Or -shudder- use Outlook's address book. Then you don't even have to hit "Sort".
Lots of people make lots of mistakes. That's no reason to adopt mistake-making as a lifestyle.
Here you're agreeing with me. Excel sucks for that stuff, so you're using applications that don't suck. If you really think hard about it, I'll bet you'll be hard-pressed to come up with a use for Excel that there isn't some better app available.
Augh! No!!!
My wife's biotech company recently asked one of the scientists to take over the database. When I asked why the company would want a scientist to own a database when they have a perfectly capable IT staff, my wife's coworker (our friend) replied: Oh, because the IT staff doesn't understand the data. You have to understand the experiments and how the data is collected in order to properly load it into the database.
Wha?!, I wondered. Why on earth would someone loading data into a database have to understand that data in order to load it properly? In fact, why is one loading data into a database manually to begin with? And what form is the data in prior to being loaded? The answer to all these questions became clear when our friend explained that the scientists are the company tabulate all their data in Excel spreadsheets, from which the columns must be mapped into the database. For each experiment, the scientist creates a new spreadsheet and more or less randomly orders the columns, so without an understanding of experimental procedures one could not make sense of the data and know how to load it properly.
Um, I wonder, Why are they paying a scientist's salary to screw around with spreadsheets and learn IT functions when you could be doing science? Why don't they just hire a programmer to write a simple app that allows scientists to input data (or import data directly, in the case of a scientific apparatus that can output the data in a known format) to the database? This would certainly be cheaper than this on-going, error-prone process of doing things in which each scientist maintains their own spreadsheet templates and tweaks them for each and every experiment.
Well, she replied, this is how all of the big biotech firms do it. And she's right. I've talked to people since that have worked at Genentech, AmGen, Novo Nordist, etc, and they all do the same stupid thing. And they all keep the data in the database in a fixed schema (it differs from company to company, but all experimental results are eventually pushed into the same DB schema across the company as a whole).
This is my problem with spreadsheets. They're not very good at doing calculations (unless you like looking for typos). Mathematica/Maple for computations and Minitab for statistical analysis are far better apps for doing everything from quick'n'dirty calculations to extensive mathematical work. Spreadsheets are not very good for most of the things they're used for—expense tracking, project scheduling, budgeting, address book, the list goes on. The ubiquity of the spreadsheet has inhibited the spread of proper solutions more than any single other piece of software I can think of.
I was waiting for this reply. :-)
This proves my point precisely. The spreadsheet has somehow become the application that stands in as a kind of generic app when people don't stop to think about using something more appropriate. By suggesting a better application than Excel to store passwords, you've shown one example in a never-ending stream. What I mean to say is: no matter what scenario one comes up with for using a spreadsheet, I can come up with a different, better application.
Are you kidding? Spreadsheets suck.
Let us recall the original purpose of the spreadsheet, and here I do not refer to the whiz-bang computer application, but the actual paper spreadsheet. It is an accounting tool. Even most accountants no longer use spreadsheets. It is one of the strange additions to the "standard" suite of office applications that at some point a few people in some companies somewhere decided everyone should have access to, and they gave us that hammer, and now my personal data must be a nail because I happen to have a hammer.
No, we need personal database software. The terabytes of data that homes will soon be accumulating require a better storage solution than a spreadsheet. Example: I have memberships on a lot of sites, like here. I can't remember all my passwords. I could keep them cleartext in a spreadsheet, or someone could allow me a means of storing them in my personal DB that a keyring app could hook up to (or me directly, from the mysql prompt, if I have the knowledge to do so and so choose).
You've never played with a lock-pick set, have you? You can get past most knob-locks and deadbolts with a torsion wrench and a rake in under 10 seconds. The time investment required to achieve this level of expertise? About 15 minutes of playing around. The time investment to make your own lock pick set? Maybe a couple of hours if you go really high-end, but probably could be done in around a half hour if you know what you're doing.
Unless you're dealing with a tubular lock. Those things are, like, impossible to pick (unless you happen to have a highly specialized device called a ballpoint pen).
I remember one summer in college, rooming with a guy that went to CalTech during the school year. When I learned this, I waited for summer to begin with great anticipation, as I knew that every freshman is required to develop good lock pick skills at CalTech, and I would find a way to make myself the beneficiary of that knowledge. So it was almost a letdown when he showed me how to pick locks and within the half hour I was able to breeze through most locks I encounter in daily life as if they weren't even there. So much for a highly specialized skill.
If you're ever in need of a Java guy to work on a side project, ping me. I'll work with guys like you any day.
There could be no flaw more basic than what is proposed in TFA.
Person 1 pays Company A for some product. Company A wants to send product to Person 1 so that Person 1 can enjoy product. But they want to do it in such a way that Person 1 cannot be trusted not to publish product for Persons 2, 3, etc. No amount of filtering, encryption, copyright protection, etc, in the world is going to help Company A achieve this goal.
Now let's look at untrusted Person 1. Person 1 has content that they want to transmit to Persons 2, 3, etc. In this communication, both Person 1 and Person 2 are "trusted". The information holder, Person 1, doesn't really care what Person 2 does with the information, so it's a very low bar Person 2 must clear to fit the trust criteria. Basic encryption allows two trusted parties to communicate information such that no other entity, whether Company A, ISP K, or Person 3, can eavesdrop. Period.
These are the fundamentals. They cannot be changed. As long as Company A can't trust the paying recipient to not redistribute the information, there is no technology that can help them.
The only model that will work is for Company A to transmit information to some trusted endpoint, say Provider Omega, and then require Person 1 to contact Provider Omega for some derivative of the product. The derivative has to be something Company A doesn't care about. Example: I, the copyright holder, post a photo on shutterfly gallery and send a link to untrusted Mom. Mom goes to link, sees photo thumbnail (derivative of photo no one cares about untrusted Mom stealing), orders print (another derivative no one cares about—if untrusted Mom gives photo to third party, that's fine with everyone).
Of course, the problem our Company A faces is quite different. Person 1 isn't buying a derivative of product, like untrusted Mom is happy to do. Person 1 wants the thing itself. No matter how many trusted third parties Company A contracts to stick DRM-enabled DVD drives in Person 1's computer, or ISPs that monitor Person 1's network traffic, or jack-booted thugs that break into Person 1's house, at the end of the day the technology serves only communications with trusted endpoints and no other kind. The only way Company A can keep Person 1 from distributing product is to not give product to Person 1 and instead substitute some derivative they don't care about. But if they don't care about it, neither will Person 1, and Person 1 will not buy it.
Spoken like a true bachelor!
Forget it. You are powerless to combat the constant marketing machine that has brainwashed the vast majority of women. Regardless of what you say now, you are less than 10% likely to not buy a diamond at some point in your life if you enter a serious relationship. I've known many guys that sing the same tune. Not one has placed their principles over their honey when push comes to shove. (And that is why De Beers is rich.)
"Google's" "PageRank algorithm" is actually an implementation of a very powerful, general mathematical principle. Math applies to more than just the web.
Well, if you consider the goal at $1M, they accomplished that goal and added $1 extra for every $10 of the goal. That's kinda like killing every tenth dollar in line. I admit, it's a stretch, but seems like an somewhat appropriate (though unintentional) usage to me. :-)
Clearly, the music, the quality of the music, and ease of use have something to do with the fact that people paid. Without those elements in place, I doubt that many of the people sending money would've still sent their money to Radiohead. I'm not arguing here that $2.40 per album is the definitive golden amount that albums are worth...I'm saying, in general, that in a world full of piracy there's money to be made by bands making music. The jury's still out on exactly how much and exactly what form it will take. The main point is that the band is more motivated to get their music into the hands of others than anyone else in the world. The extra work they're willing to do to make that happen is a valuable service that customers will pay for. I don't claim to know how much and the mechanism whereby the money will be transacted, but clearly there is something there.
At the same time, regardless of whatever technology you're talking about, there will always be those that are committed to getting that music for free. And they will succeed. They will succeed because there is no fundamental way to stop these people. It is a well-known cryptographic principle that if person A (Radiohead) is trying to communicate information (music) to person B (Joe Average) while preventing person C (a pirate—ARRRRR!!!), it is absolutely essential that the two communicating parties be trusted. Specifically, that neither A nor B will share that information with C. In this case, Radiohead can't possibly trust Joe Average in every case to keep their music from a pirate. Hence, there is no way in principle to sell music to B in a way that C always ends up either without the music or paying for the music.
As a practical matter, however, it is good business to recognize the inflection point at which C becomes so dedicated to theft that it is no longer worthwhile to prevent it.
Let us presume you are right. If that is so, then the amount of money passed through to the band from CD sales at concerts is the same as that passed through from CD sales at Wal-Mart—for most bands, this is effectively no money until their 100,000th sale, as it takes that many CDs to pay off their debt to the label (I don't know if it's 100,000 or 20,000 or 1 million, but you get the point). After that magic number, the band starts making money from each sale...but it's a tiny amount for the vast majority of bands. So even for fairly well-known bands, if they're not in the A-list upper echelon, the vast majority of their income comes from concert tickets, promotions, endorsements, and other activities not covered by the contract with the label.
If I was right in my last post, and CDs sold at concerts are considered concert revenue, the band gets to keep all the proceeds from this vanishingly small percentage of overall CD sales, so that's even better for them. Notice, though, that in either case, whichever way it goes, if the band's not playing concerts then these CDs sold at the concert venues don't exist at all. There's no option that allows even those sales if the band isn't playing concerts.
This is untrue. You've met dozens if not hundreds of people that have paid more than $25 for Windows. I'll bet you've even met a few people that have paid for a legal copy of Windows without actually gettin
You're right about this...it doesn't help them figure out a correct way to do business. This is as it should be—as a customer I don't feel I ought to be compelled to help companies. As a business man I wouldn't expect it of my customers, either. Because, as you correctly point out, it doesn't work.
Well, they could demand it before, but they certainly wouldn't get it. Now they can realistically demand it because they have another avenue. As a point of contrast, Metallica doesn't get nearly that much per CD through their super-sweet deal with their label.
Umm...those CD sales actually count as concert revenue, along with tickets and t-shirts and all the other trinkets they sell at concert venues. So basically, you're unwittingly saying now what I said in the last post—bands don't earn anything from their contracts with their labels, it's all concert sales.
I wasn't using Radiohead (or Metallica, for that matter) in my argument in any way that requires them to represent the average. So my point still stands. I did use them to refute your assertion that, if music is free, people won't pay for it. So what I did was find a specific, relevant example where the music is free, and people still paid for it. Furthermore, my point was that they paid for it happily because service does matter, and getting it from Radiohead's site was easier and less risky than from Pirate Bay. And people are willing to pay for music that's easily obtained, even when not being required to do so. (I'm not really big on rehashing my arguments several times over, but it seemed like you really missed what I said on this one.)
Well, you're free to believe that piracy is separate from "the market" and it doesn't communicate anything important, but if you want to run a successful business it pays to take account of reality with all its warts. Or you can stick your head in the sand and say, This isn't the way it should be, so I'm going to operate as though it isn't. Good luck with that.
That's you. Not to offend, but frankly, no one's interested in you. I'm talking about Joe Average. Radiohead posted their album for free, and 60-some % of the downloaded were unpaid. Of the 40% or so that paid something, the average payment was $6. If you run the numbers like I did, you too will find that Joe Average paid $2.40 per download. Joe Average is who we're interested in, and Joe Average isn't doing what you do. So what have you got to do with this discussion?
You were led correctly. Music consumption is up, and as more music is pirated through file-sharing, record companies are making more money. They're not advertising that, but it
What's the biggest demographic that buys what the large music labels are selling?
True—but why is it different this time? The same argument has been rolled out after every new technology advance. The first time someone could tape a song off the radio and play it any time they wanted, for instance.
So...explain to me why it's reasonable for music companies to expect me to get in my car, go down to the mall, pay $20 for a CD that contains 13 songs I don't want and one that I do when I can download the one song that I want right now..."and it's better quality than any online store even comes close to offering." You're making my point for me. The music companies aren't making it convenient for people to give them money.
[Rod Serling's voice] Picture if you will, a man who knows nothing about BitTorrent pays $1 for a top-quality recording of a new song that begins playing within seconds. Doo-doo-doo-doo, doo-doo-doo-doo.
This is a common argument made against piracy. The first time I visited the Microsoft museum in Redmond, they had erected a giant LED board that constantly ticked up the total loss incurred by MS due to software piracy. However, I would point out that just because you download the complete catalogues of these artists does not mean they have incurred losses equal to the retail price associated with the CDs containing those songs. This is the logical fallacy of the false dilemma—it presents a choice between two and only two options—buy the complete works of 7 musicians or download it for free—when there is really a third, and far more likely option: do nothing at all.
If I download a cracked copy of Adobe FooBar and install it, this only costs Adobe money in the case that I would've gone out and bought a copy of Adobe FooBar had the cracked version not been available. In the case of Adobe FooBar, however, I can tell you without a doubt that it's so expensive, if I don't get it pirated, I won't be getting Adobe FooBar at all. I'm pretty sure there's not a marketing executive alive that would tell you they'd rather have someone not using their product than using it without paying. The illegal user promotes marketshare, brand recognition, mindshare, and a list of other minor benefits that a non-user doesn't.
Why do you think Microsoft didn't secure early versions of all their software so that it was uncrackable? Are you under the misapprehension that the necessary technology and methods don't exist?
Do you know how many albums a band must sell under the standard record label contract before they break even with their label? And then, once they break even, do you know how much of that $20 CD retail price actually ends up in the average musician's pocket for each subsequent CD? It's fashionable these days to think that Metallica, one of the biggest crabs about all this P2P filesharing movement, represents the average band. They do not. Metallica cares so passionately about filesharing because they are one of the very few bands in existence that has negotiated very favorable terms with their label, and so they actually do make money off of album sales. Most bands do not. Most bands yield all or most of their album profits to
The OP is framing this discussion improperly. This shouldn't be a discussion about morality or ethics; this should be a discussion about what is and what will continue to happen.
The fact of the matter is that companies want the right to sell whatever product or service they like, without being compelled to package those products and services in any way by the government. In this particular case, they're lobbying government to correct the slight of omission against the industry—that is, they feel victimized as no one is really helping them stop so-called "illegal" downloads from occurring and it's law enforcement's duty to step in.
Well I personally believe that any business should have the right to sell whatever they want, packaged any way they want (a broad and untrue generalization if ever there was one, to be sure—certainly we don't want to go back to the early 20th Century robber barons, so there have to be some controls in place to deal with monopolies and such). And I don't support any action that would compel me, were I to start a business, to package my products or services in any particular way. What I sell and how I sell it is a problem for the free market to solve, not government. What companies further want, and will never have, is the right to sell whatever they want packaged any way they want free of restrictions from the customer. This, quite simply, will never happen in any business. At the end of the day, in a capitalist democratic republic, the people can and always will vote with their dollars, and I don't believe that's going to change any time soon, nor should it. We can argue ethics until we're blue in the face, but it won't change reality...specifically, if people don't want to pay for what you're selling and there's an easier, more convenient way to get it, then that's what's happening. Forget about asking Is it right? Is it fair? Instead, try: Is it moot?
Businesses ought to be smart enough to sell customers the products and services they want in the way the customers want them packaged...this isn't rocket science, it's just good business. Music companies used to sell us music, and if you had the tools, you could legally make as many reel-to-reel or cassette tape copies as you wanted, provided they were for your personal consumption (turns out that it's considered "personal consumption" if you take your music over to a friend's house and play it there). Practically, the music companies may not have liked the idea of the time-honored tradition of guys making their sweeties mix tapes from copyrighted CDs...but they were smart enough, after some initial friction I'm sure, to lay off and let things unfold naturally. Sure, they included toothless legalese and mostly kept up a facade of controlling things, but everyone—and I do mean everyone, including those in the biz—regarded such restrictions as quaint. So how did this work out for business? Why didn't the mix tape deep-six their profits? Because mix tapes signal emotional investment to the sweetie-in-question for one big reason: they take time and effort. Music companies that provided music to customers in a way that they found convenient and enjoyable could still generate a good buck.
This time, however, it's completely different (much like it was completely different all the other times, too: cassette deck, reel-to-reel, VCR, CD-R, etc). The fact of the matter is, music companies want to sell people rights nowadays, not music—the right to play this song on this device, the right to transfer this song from device 1 to device 2. But people don't want to pay for these rights...customers want to pay for music. Dealing with companies to buy a legal abstraction is too troublesome when all people want is music, same as they've always had. Since the companies aren't selling music, though, the only way to get it is to steal it. These companies are all too willing to dig into their war chests to pro
This is clearly an intractable problem that cannot be solved any other way. Blame the technology!
Seriously, no piece of technology can be blamed for poor time management. Neither can one blame one's manager for allowing that person to manage your time poorly for you.
This is an issue of ownership. Own your job, own your time, and take responsibility for yourself. If everyone's doing what they should be doing, then this discussion is moot. If everyone's not doing what they should be doing, then how about having that discussion instead of some hypothetical potential abuse you fear by those above you?
My attitude toward my managers is this: if you're a good manager, then you're going to remove the obstacles I tell you are blocking me from doing my job. If you're not going to behave that way, then you're irrelevant to my core duties, and I'm going to invert our relationship. In other words, now I'm your manager, in the sense that I have to manage you as yet one more obstacle in my path to completing my tasks. If I do my job as your manager correctly, you'll trundle along happily and never know that I think of you as essentially a child out of your depth. If you become too much of a problem, I'll take me and my record of success somewhere else where I can work with adults.
Wasn't there a Futurama about this? Yes, there was! The Lucy Liu bot...and the movie reel about little Billy!
These are all of the atoms of knowledge contained in your post. Because I was able to identify them, perhaps they are not so vague after all (at least not to humans...machines are a different story, but by that standard faces were vague until recently as well). This leads me to another question: does a knol have to be correct to be a knol, or is there such a thing as an incorrect knowledge (as I, apparently, am arguing would apply to 3 and 4 above)?
If these are knols, then what would we call compositions of knowledge atoms (knowledge molecules, if you will)? And how many knolecules are there in your post?
(Yes, that was a long way to go just to be able to say knolecules.)
Though I'm sure you can design a particular application in which a square is behaviorally a rectangle, and therefore it would be ok to have square extend rectangle, it is not universally the case.
One of the best things I ever did was head over to Object Mentor's published articles page and click on the Design Principles category. There you will find a paper on the Liskov Substitution Principle which defines exactly when it is appropriate for one class to extend another. (You won't go wrong reading all the papers in that Design Principles category—I found them riveting for hours on end.)
In this particular case, behaviorally speaking a rectangle has two degrees of configuration freedom whereas a square has one. So, if you think about the actual practice of defining a Rectangle API with get/setWidth() and get/setHeight() methods, you could then write a unit test against those methods to fix the proper behavior of a rectangle. One of those unit tests might go something like: {1} set width to 1, (2) set height to 2, (3) assert that getArea() returns 2. I challenge you to now implement the subclass of rectangle called square that will pass this unit test which behaviorally (and correctly) verifies rectangle-type behavior.
Your suggestion of making squareness an attribute of rectangle is interesting and one I have not yet heard in any of the instances I've presented this example. I imagine it would take the form of something like the method boolean Rectangle.isSquare(), and would return getHeight()==getWidth(). This would work, as long as clients to the rectangle API understood that its square-ness is temporally defined and could change in the next moment. This is, however, an important consideration, though. In making this a requirement of what it means to be a square, nearly all definition of the square is itself lost...the concept of a square becomes a temporal thing itself. The old mathematical standby of an object that forever and always has equal sides is no longer relevant to this implementation.
"A square is-a immutable rectangle..." Your point is well-taken, and this addition of immutability goes a long way to aligning OO with mathematics. Even this is not universally true, though it is obviously true in almost all cases. Theoretically, I can think of an application in which it would not be appropriate to make an immutable square extend an immutable rectangle.
Say I'm writing an application that applies mathematical transforms to 2D geometrical objects and creates a new object based on the result. Let us further presume that all such transforms must be defined such that they are operations that exhibit mathematical closure. In other words, if the transform operates on circles, the result of such operations must also be circles.
I define a transform that operates on immutable rectangles as arguments. Specifically, it is a unary operation that takes a rectangle and produces a result that is 2x in width and the same in height. If I pass in an immutable rectangle with dimensions [4,1] I get back a new rectangle with dimensions [8,1]. In this scenario, for closure to hold, both the input and the output must be from the same set (rectangles). If I now mistakenly let square extend rectangle, this transform is no longer meeting the requirement that it demonstrate closure. The compiler will allow me to pass a square to this method as a rectangle argument, but instead of producing a result from the set of squares, it will most certainly produce something from the set of rectangles as a result. If I'm creating this new type square as I did rectangle—in order to treat it as a new kind of set on which a set of transforms can operate with closure—then allowing it to extend rectangle is most definitely a mistake.
I wish to avoid a detailed discussion of the subtleties of this particular example (as I believe that I would quickly find myself out of my depth) and trust that my point has landed...which is: we can say that a square should not extend rectangle, and regardless of the application under consideration, it is universally true that such a design allows us to respect all OO principles. On the other hand, it is only true for a subset of these applications that we can respect OO principles if square does extend rectangle (square and rectangle must be immutable in certain ways, etc).
When you define an API, it should always be in service to what clients may want. So, if the physics app you are trying to write would be concerned with the gravitational aspects of a relatively tiny ball, then I agree, by all means add your method. On the other hand, if clients would never be interested in calculating the gravitational force of two balls out in deep space (or some similar application), then adding such a method unnecessarily complicates things.
One thing to keep in mind is that OO code is not math or physics. Consider the following classic example: I'm writing a geometry library and I have a Shape interface. I implement that interface with Rectangle, Circle, Triangle, etc. Then I get to Square. Should Square extend Rectangle? After all, a square is a kind of rectangle, as every schoolboy knows...right?
Except in this case, it's not. A square may be a type of rectangle in geometry, but in an OO system it would be improper to represent a square as a subclass of rectangle because behaviorally speaking a square and a rectangle are different, and OO regards classes as behavioral objects, whereas geometry regards shapes as characteristic objects. In other words, in geometry, if you have 4 sides and 4 90 degree angles (in Euclidean space) you're a rectangle. A square has those things, so it's a rectangle. In OO, since a rectangle and a square behave differently with respect to pretty much every sensible API you could assign to each, Square is not a subtype of Rectangle.
Of course, that's a great example because it's pretty much true across the board. Very few examples are true in that way—in nearly all cases, f you're arguing with a colleague about whether this should extend that or aggregate this other thing, context matters. I've often discussed possible designs with colleagues where they correctly argue that, for some particular application, their approach is correct. What I always try to get them to focus on (if we have a disagreement) is forget about some general, archetypal application. In our application, in this context, does it make sense?
Example: should Automobile aggregate Engine or should Automobile associate an Engine? (The difference is: aggregation implies a "part-of" relationship in which the containing object partially derives its identity from the contained object, implying the two have similar lifetimes. For instance, a building aggregates a room because it doesn't make sense to have a building with no rooms or a room without a building, when you new up a building the constructor ought to new up one or more rooms, they're born together and they die together. A surgeon and a scalpel, however, are a different story. A surgeon may never use a scalpel for a particular surgery because only other tools are called for, so that would merely be an association...a surgeon is still a surgeon, scalpel or no, but what would you call a building with no rooms?) In this case, it's impossible to say whether Automobile should associate or aggregate an Engine. If the clients of the Automobile API are owners that will only be interested in driving it, then it should probably aggregate Engine. If the client using the Automobile API is an auto manufacturing plant, then perhaps it makes sense to merely associate the two.
This is the problem with your answer above. It takes no account of the actual application the end user has in mind for the Ball class...you simply state that you would do it X way. If clients desire that behavior, great...but if none of the use cases would ever need that kind of functionality, you might be adding complexity with no pay-off.