Just because it's different, doesn't mean it's hard.
Correction: just because it is different, it doesn't mean it HAS to be hard. In this case, some things were harder than they needed to be.
Without other background, she had no reason to know what Synaptic is.
You may be right that all she needed to do was use the right program, but that is precisely the author's point: a little extra effort to make things more obvious, would have made each test successful.
I think you managed to both get and miss the point in the same message with remarkable coherence...
I completely agree with you on the first point that software would be better if people still understood the basics better...
But the parent comment is STILL right - the bigger problems for most programmers today have to do with the big, complex systems they need to deal with. Not the algorithm details.
On your second point, you even seem to agree with this.
The big problem in software development today is in understanding the target problem, and dividing it up, so it can be solved in a modular fashion. If this is not done right, and the problem remains too big or nebulous, a number of issues crop up that need to be mitigated.
This is a hard problem, and it is not a computer science problem. Clever algorithmic skills don't help as much on this as domain knowledge, communication, and other skills that have nothing to do with algorithmic analysis.
But if you look at what is broken in most software we use right now, it's not that the algorithms aren't fast or clever - it's the poor design choices, overly complex user interactions, quality control, and in general the things that get broken, and stay broken, even if you have solved all the hard computation problems perfectly.
He's not wrong about unit-tests - he is just trivially (and pointlessly) right.
He says unit-tests are rarely useful to him - and for the type of work and code he does, that is probably correct.
You do not write unit-tests for yourself. You write unit-tests for Other People who deal with your code - even if that "other people" is you 12 months and a few unrelated projects later.
You write them for when someone needs to modify your code, to do something that was not an original requirement, on a real world schedule and without the complete mental picture you (may) have had on your head when you wrote it.
If you can afford to say that your requirements are complete, correct and immutable, and that any change after that can only be to fix a bug - then sure, there are better ways to make that first code bugfree.
But if that is the case, you are either in academia, or your type of work has very specific requirements and needs different (formal) methods from most of the industry anyway.
I think the main reason literate programming doesn't catch on is because a great many (great?) programmers are just not writers - they just do not enjoy writing out their thought processes, and see the code as more concise and literate enough. Writing an essay for every non-trivial piece is no fun in that case.
Knuth enjoys writing, he's an academic, and he already has to work like this (on paper or not) all the time - to teach, write research papers and books, etc.
So I think his system misses the fact that most people don't work the same way he does(nor should they have to), and most code that most people write is not even interesting enough to write about.
I personally like the literate programming concept and think it would be a lot better than the spec->code cycles used in many companies - which at best is 'literate programming without tool support' (but more often is a lot less useful). But many programmers I know find that translation effort a chore that gets in the way, rather than help, the thinking process. They'd be better served and less frustrated spending their time on making their code clear and readable.
The unit-test thing is also related to his academic work - he misses the point of why it is so valuable in the real world.
To be honest, unit-tests do not help that much to get your first version of the code working. If you plan properly and code carefully, they will not help you find many bugs, and you're likely to unit-test only the things that are unlikely to have missed in the code.
But Real Code in the Real World changes over time, by the hands of different people and entirely unexpected purposes. The value of unit-tests is that they allow refactoring and modification of the code, after the fact, with greater confidence.
You do not create unit-tests to "feel out your way in a totally unknown environment". You make them so the OTHER poor bastard who has to feel out their way in YOUR totally unknown environment can use them to have some idea of what works, what doesn't, and an automated set of sanity-check rules that tell him what he missed.
Putting aside the ethical and democratic implications...
The problem is not that your votes aren't counted if you're "too dumb to figure it out". The problem is they can be MIS-counted, affecting the reliability of an election.
Unless you want to make it a reliable intelligence test + analysis + voting machine... in which case I think you'll lose the 'cheap' part.
I'd agree if it were completely up to him, but movies do need money to be made.
It's very different to say "hardcore gamers don't like this director so much" vs "one million viewers signed a petition asking to get him out of the business because his movies were so bad".
The (legitimate) response to the first is 'Who cares?'. The response to the latter would be 'OK, who's the next director on the list? Can I give my money to anyone without a signed 'you suck' declaration by 1 million viewers?'.
Or, if they're clever, 'if I reject this director and make it very public, do I get 1 million viewers for my game-based movie for cheap?'.
As I said - I'm not convinced of their solution either.
Performance issues are an implmentation issue - they may or may not be fixed by the time it is released. But if the idea is good, either AT&T or someone else will take it where it needs to go.
But I do not think lack of this type of visualization is the problem.
"Hmmm... where was the website that look like this?" may be helpful dealing a couple dozen, distinct sites - but that is exactly the scale where bookmarks are just fine.
With more bookmarks, I doubt it will get any better than with text - how many readable screenshots can you show at a time? 3-4? How helpful is it as you iterate through the bunch of links to find what you want?
Worse - what happens when most of your links are from the same site, or similar sites - but with different information?
How many almost-identical snapshots of msdn / sourceforge / javadocs / blogs do I need to go through to find what I want? Yep, being able to see the color scheme will definitely help me to find what I'm looking for!
I'm not sure the problem is already solved with del.icio.us approach - although I'd agree it goes in the right direction.
Moving the links to the cloud does have many advantages - good searchability in particular. I tried it on my own once upon a time (nothing 'social' - just a blog and a datastore and a hacky app to be able to crawl and query my links) - which I left to wither and die out of lazyness and other factors of life - and it was at least more useful than the browser bookmarks. The del.icio.us tools most likely lack the main pain points I had, which were my own clunky hacky fault.
But there's something about their UI, and about storing my links on a common server - and perhaps the web 2.0 pun.c.tua.tion and obsession with 'social' everything - that rubs me the wrong way.
I just want to find the stuff I have already found, easier than the first time around - I can't bring myself to register an account, and download the thing, and tag and deal with a clunky UI and put my links on their server just for that. Might as well do it myself at that point, for the sake of controlling the data store.
It should just happen, in the browser, for both history and explicit bookmarks. Search has gotten good enough that otherwise there is almost no point in keeping track of the data at all.
Back when web directories were actually competitive by hiring people to review websites... and 'search engines' were complementary options for most users, in case what they were looking for had not been added to Yahoo et al (yet).
History and bookmark handling are not scaling well to modern use of the web.
They were designed for a much smaller Internet - back when Yahoo was a comprehensive catalogue of the web, and you could honestly bookmark a short list of all your favorite sites.
Anyone who had to go through the browser history after a long week, to find 'that link that had some information but I cannot find in google again', has experienced this first hand. All the links look the same, all your searches get in the way, etc.
Anyone who has had a few dozen disposable bookmarks by trying to avoid the history search also has experienced this first hand.
Bookmarks lose their value as they accumulate, and reality is that you often cannot know the crucial link will be crucial until after the fact - after you got another piece of data. Specially for technical documentation.
Pogo seems to be addressing two major usability problems that exist today. At this point, I mostly consider those to be non-existent browser features by now. Repeating an Internet search is typically more time-efficient.
Now, I don't really think painting it all in 3D really helps - but what they seem to be trying to fix are real problems.
You're missing the point - the fact that it is unscientific is PRECISELY why you cannot say it is wrong.
If you could say it was wrong, you could make the case it was science - bad science perhaps, but it would at least fit in the truth/falsity discussion.
Since you cannot say whether it is wrong (or right) - the fact that people mix it with theories that can be proven by more than mere matters of opinion (i.e.: science) - is more fundamentally broken than any particular conclusion.
Saying "ID is plain wrong, go away" is not productive to confronting the real problem, because in the big scheme of things it doesn't matter that much if people believe in the theory of evolution in particular or not - bad theories lose over time (that's the point of science). The real problem is that so many people don't understand what science IS, and that can cripple the very process long-term.
That's not a fair comparison. Intelligent design cannot _ever_ hope to partake in a scientific discussion, because there's no science behind it, and that's _it_. No point in debating something that's completely wrong in any way you look at it.
That is an unjust and inaccurate statement.
You can't say ID is wrong just because of your bias - when it is clearly "not even wrong" - it's very wrongness impossible to prove or falsify.
To say it is completely wrong demeans everyone else who is honestly and properly wrong... Or for that matter, those who hold non falsifiable assumptions as matters of faith and philosophy, without misrepresenting them as science (which in the end includes pretty much everyone).
That's a terrible metaphor. The school is not just like your parents, the school is essentially a babysitter.
For a valid comparison, replace that with: "What if your babysitter found you may have done something illegal (when she was not babysitting)? Should they not punish you? Should they instead go straight to the police? ".
The absurdity of the choices is evident - the only sensible choice is "go straight to the parents". Directly punishing you is not within her authority, and escalating to the police should be a measure for extreme circumstances / concerns about the parents.
Schools do have in loco parentis, but only as caretakers for the child during the educational process. At all other purposes / circumstances, the parent is not absent and the interests which have been delegated (educational process) are not at risk. There are good historical reasons to be wary of institutions going overboard with powers of that type - let parents keep the power and the duty to be parents.
It is reasonable that school officials would react and try to put some constructive punishment in place - but this should really have gone through the parents authority.
The school should have gotten together with the relevant parents, expressed their concerns, and make some suggestions as to the plan of action - but the punishment should have been excercised by the parents, who have the full authority for that, and are best able to adapt it to individual circumstances.
When he criticises OSS for a lack of creativity, by implication he is praising closed-source.
Really? Did you read the article, at all? He explicitly favors "closed development" followed by "open source" releases. Read the 2nd page, 8th paragraph, specifically.
OSS is more than a set of licenses these days - it is also a methodology to develop software, which is (or aims to be) very much community-driven. When that community is chronically convinced that "Unix == computer-science", the author's arguments sound quite rational.
Historically, communities and committees are not great sources of radical innovation. Innovation tends to come more easily from individuals and smaller groups with tighter focus over longer periods - there is little reason to say this doesn't apply to software as much as it applies to other arts and sciences.
To abuse another analogy from the article: speciation is good, not 'evil'. It is what drives evolution, and without it our 'Eden' would likely be populated by very robust, stable, but terribly uninteresting bacteria.
Personally, I don't think his "encapsulated development" needs to be closed-source at any point - the informational and normative conformity that would slow down innovation doesn't feed from the source being open, but rather from the communal development. For that matter, any innovative open source (and most successful) projects I can think of used that model anyway, intentionally or not, until the project reaches some maturity, stability becomes more important, and the community takes a greater role.
Everyone raise your hand who didn't play "doctor" or some variant well before the age of 14.
<chirp> <chirp>
Yeah, thought so.
Dude, this is Slashdot.
We get your point, but this may not be the crowd to be making that argument. Most readers have more authority to complain about your chirp tag not passing xml validation than to testify about the practices of medical impersonation among the western youth.
I know you're trying to be funny, but if you replace that with the actual business model it sounds a lot more sensible:
"(Almost) no one's ever going to BOTHER cracking the encryption..."
It will all come down to pricing and convenience - if the price is right, and the restrictions aren't absurd, most people will be more than willing to pay to download yet another TV-show-season pack.
Of course, media companies do not have a history of being very smart about either - but the greatest problem is neither with the basic business model, per se, nor with the "online" extension of that. It's just that they keep doing stupid shit with the parameters (price, forced previews / ads on bought content, etc.) so that they not only make it a bad deal, but actively piss off their consumers.
And I would agree completely... but the argument that Bioshock was a remake/adaptation of SS2 is still valid. That doesn't make it "bad", of anything, it is part of what makes the game as good as it is. But if some people are disappointed by the lack of originality it is understandable and a valid point - how important it is is subjective, but pretending that they're not almost identical reeks of fanboism.
As I said, I'm a big fan of both games - although I do consider SS2 was superior in some ways, Bioshock is still high on my best-games-ever list. I'm also a big fan of "Scotland, Pa", for that matter - which I've found a better movie than most MacBeth renditions.
There is no shame in making an adaptation (even if MacBeth may be a better marketing bet than a video game) - and many adaptations can be far better than the original. There is a bit of shame if all your new original work feels like an adaptation of your first hit - but I never got the impression the expectations of stark originality were driven by the people making the game anyway.
They're not "equivalent" in some high-concept sense - they're practically identical in every meaningful sense.
"Ambition leads man to great betrayal, a rise in power, and ultimate plants the seeds of his own destruction" - that is a common thread to many tragedies in fiction.
But when you have the man and the wife enacting the same scenes, the three witches, the prophecy of power and a promise of invincibility that turns out to prophesize their doom... I'm sorry, but MacBeth is MacBeth, whether it is in 11th century Scotland, or modern Australia, or a Pennsylvania burger joint.
I'm a big fan of both games, but there's no way you can claim the similarities are just common game mechanics. The story in the background was different enough, and well worth playing - but the game in the foreground was, for good or evil, the same game.
I don't think many people say Javascript sucks per se.
But there is serious discussion about whether Javascript sucks for the job.
Still, I'd agree with you completely that the biggest problem is not the language, but the platform (browser compatibilities being a big, but not the only, issue). And then every framework just tries to hide both javascript and the platform - neither of which is designed to do what we're making it do...
It's not hard to understand the motivation, but that doesn't justify it - nor does mean as a method it even works.
Personally, nuclear power doesn't scare me. But your argument does - in any context. I'm not concerned about car drivers who may have a drink or two in their system - but I'm afraid of any driver who consistently lies about their alcohol consumption, because they think 'others might overreact'.
I don't see a better first step to solve the problem, than to embrace transparency as part of the safety process (and the corporate image / PR). A vicious cycle of bad precedents does not help to make the case.
Hysteria and massive liability risks are not unique to nuclear power - drug / health industries have to deal with the same issues, with what are probably higher and more concrete risks of liability. They typically deal with it and with their own 'hippies', and have processes to avoid being tempted to be 'gun-shy' because accusations of a 'cover-up' puts them at unacceptable financial risk.
Not sure the critique to Coldfusion applies - it became irrelevant because it got replaced... by a bunch of frameworks that followed similar, but technically more powerful approaches (e.g.: JSP tags in a dozen dialects).
The general idea is old, tried and true in computer science: "Learn a new straightforward, targeted language, to avoid learning a complex language that was never intended for these needs". And is the way yet another thousand toolkits try to solve the AJAX problem.
The sound-ness of the approach for AJAX, of course, is based on two things: - The subjective suckyness of the javascript language for the job - this is probably a matter of taste and background. - Whether changing the language is enough to solve the complexity / scale problems.
Although I'm no great fan of javascript as a non-small-app development platform, I think the second problem is more important. I think there is only so much you can do by pretending that javascript is assembler, while carrying over all the other baggage of the html+script world.
That may or may not be enough, depending on what people think AJAX should be... for all the ambitious hype of WebOS and office apps on AJAX, I don't think it is enough. The pain is not the syntax, it's the programming and execution model, which is not going to go away by wrapping it into java classes or xml tags.
I think the point is that the ISO stamp doesn't really change that much - it is not what makes it immensely useful, and it was already immensely useful without it being an ISO standard.
This should be funny enough without distorting the facts.
It seems you are establishing an undue connection between two separate statements. From the linked articles, this is the sequence of events as I understand them:
1) LANCOR files a patent infringement suit against OLPC in NIGERIA. 2) Negroponte claims the lawsuit is without merit. 3) LANCOR (obviously) responds it is valid and all your base are belong to us, AND 4) They plan to file a SEPARATE copyright infrimengement lawsuit in a U.S. court.
Presumably, that would be because they do not have a claim to an US-based patent (if their patent was filed only in Nigeria), but they think they have a valid copyright claim, since copyright is both implicit and more broadly supported by international treaties (from what limited data I've read).
Slashdot Mirror
Correction: just because it is different, it doesn't mean it HAS to be hard. In this case, some things were harder than they needed to be.
Without other background, she had no reason to know what Synaptic is.
You may be right that all she needed to do was use the right program, but that is precisely the author's point: a little extra effort to make things more obvious, would have made each test successful.
I think you managed to both get and miss the point in the same message with remarkable coherence...
I completely agree with you on the first point that software would be better if people still understood the basics better...
But the parent comment is STILL right - the bigger problems for most programmers today have to do with the big, complex systems they need to deal with. Not the algorithm details.
On your second point, you even seem to agree with this.
The big problem in software development today is in understanding the target problem, and dividing it up, so it can be solved in a modular fashion. If this is not done right, and the problem remains too big or nebulous, a number of issues crop up that need to be mitigated.
This is a hard problem, and it is not a computer science problem. Clever algorithmic skills don't help as much on this as domain knowledge, communication, and other skills that have nothing to do with algorithmic analysis.
But if you look at what is broken in most software we use right now, it's not that the algorithms aren't fast or clever - it's the poor design choices, overly complex user interactions, quality control, and in general the things that get broken, and stay broken, even if you have solved all the hard computation problems perfectly.
He's not wrong about unit-tests - he is just trivially (and pointlessly) right.
He says unit-tests are rarely useful to him - and for the type of work and code he does, that is probably correct.
You do not write unit-tests for yourself. You write unit-tests for Other People who deal with your code - even if that "other people" is you 12 months and a few unrelated projects later.
You write them for when someone needs to modify your code, to do something that was not an original requirement, on a real world schedule and without the complete mental picture you (may) have had on your head when you wrote it.
If you can afford to say that your requirements are complete, correct and immutable, and that any change after that can only be to fix a bug - then sure, there are better ways to make that first code bugfree.
But if that is the case, you are either in academia, or your type of work has very specific requirements and needs different (formal) methods from most of the industry anyway.
I'd disagree on both points.
I think the main reason literate programming doesn't catch on is because a great many (great?) programmers are just not writers - they just do not enjoy writing out their thought processes, and see the code as more concise and literate enough. Writing an essay for every non-trivial piece is no fun in that case.
Knuth enjoys writing, he's an academic, and he already has to work like this (on paper or not) all the time - to teach, write research papers and books, etc.
So I think his system misses the fact that most people don't work the same way he does(nor should they have to), and most code that most people write is not even interesting enough to write about.
I personally like the literate programming concept and think it would be a lot better than the spec->code cycles used in many companies - which at best is 'literate programming without tool support' (but more often is a lot less useful).
But many programmers I know find that translation effort a chore that gets in the way, rather than help, the thinking process. They'd be better served and less frustrated spending their time on making their code clear and readable.
The unit-test thing is also related to his academic work - he misses the point of why it is so valuable in the real world.
To be honest, unit-tests do not help that much to get your first version of the code working.
If you plan properly and code carefully, they will not help you find many bugs, and you're likely to unit-test only the things that are unlikely to have missed in the code.
But Real Code in the Real World changes over time, by the hands of different people and entirely unexpected purposes. The value of unit-tests is that they allow refactoring and modification of the code, after the fact, with greater confidence.
You do not create unit-tests to "feel out your way in a totally unknown environment". You make them so the OTHER poor bastard who has to feel out their way in YOUR totally unknown environment can use them to have some idea of what works, what doesn't, and an automated set of sanity-check rules that tell him what he missed.
Putting aside the ethical and democratic implications...
The problem is not that your votes aren't counted if you're "too dumb to figure it out". The problem is they can be MIS-counted, affecting the reliability of an election.
Unless you want to make it a reliable intelligence test + analysis + voting machine... in which case I think you'll lose the 'cheap' part.
I'd agree if it were completely up to him, but movies do need money to be made.
It's very different to say "hardcore gamers don't like this director so much" vs "one million viewers signed a petition asking to get him out of the business because his movies were so bad".
The (legitimate) response to the first is 'Who cares?'. The response to the latter would be 'OK, who's the next director on the list? Can I give my money to anyone without a signed 'you suck' declaration by 1 million viewers?'.
Or, if they're clever, 'if I reject this director and make it very public, do I get 1 million viewers for my game-based movie for cheap?'.
Thanks - I'll definitely have to give it a try.
I haven't been following Firefox-3 closely, so I didn't think count on it having must-have features worth the beta-ness and losing add-ons.
But from what I've read on the awesomebar it sounds much like it is worth the install.
As I said - I'm not convinced of their solution either.
Performance issues are an implmentation issue - they may or may not be fixed by the time it is released. But if the idea is good, either AT&T or someone else will take it where it needs to go.
But I do not think lack of this type of visualization is the problem.
"Hmmm... where was the website that look like this?" may be helpful dealing a couple dozen, distinct sites - but that is exactly the scale where bookmarks are just fine.
With more bookmarks, I doubt it will get any better than with text - how many readable screenshots can you show at a time? 3-4? How helpful is it as you iterate through the bunch of links to find what you want?
Worse - what happens when most of your links are from the same site, or similar sites - but with different information?
How many almost-identical snapshots of msdn / sourceforge / javadocs / blogs do I need to go through to find what I want? Yep, being able to see the color scheme will definitely help me to find what I'm looking for!
I'm not sure the problem is already solved with del.icio.us approach - although I'd agree it goes in the right direction.
Moving the links to the cloud does have many advantages - good searchability in particular. I tried it on my own once upon a time (nothing 'social' - just a blog and a datastore and a hacky app to be able to crawl and query my links) - which I left to wither and die out of lazyness and other factors of life - and it was at least more useful than the browser bookmarks. The del.icio.us tools most likely lack the main pain points I had, which were my own clunky hacky fault.
But there's something about their UI, and about storing my links on a common server - and perhaps the web 2.0 pun.c.tua.tion and obsession with 'social' everything - that rubs me the wrong way.
I just want to find the stuff I have already found, easier than the first time around - I can't bring myself to register an account, and download the thing, and tag and deal with a clunky UI and put my links on their server just for that. Might as well do it myself at that point, for the sake of controlling the data store.
It should just happen, in the browser, for both history and explicit bookmarks. Search has gotten good enough that otherwise there is almost no point in keeping track of the data at all.
~1994/1995 - perhaps even early 96.
Back when web directories were actually competitive by hiring people to review websites... and 'search engines' were complementary options for most users, in case what they were looking for had not been added to Yahoo et al (yet).
Usability (through better visualization)?
History and bookmark handling are not scaling well to modern use of the web.
They were designed for a much smaller Internet - back when Yahoo was a comprehensive catalogue of the web, and you could honestly bookmark a short list of all your favorite sites.
Anyone who had to go through the browser history after a long week, to find 'that link that had some information but I cannot find in google again', has experienced this first hand.
All the links look the same, all your searches get in the way, etc.
Anyone who has had a few dozen disposable bookmarks by trying to avoid the history search also has experienced this first hand.
Bookmarks lose their value as they accumulate, and reality is that you often cannot know the crucial link will be crucial until after the fact - after you got another piece of data. Specially for technical documentation.
Pogo seems to be addressing two major usability problems that exist today.
At this point, I mostly consider those to be non-existent browser features by now. Repeating an Internet search is typically more time-efficient.
Now, I don't really think painting it all in 3D really helps - but what they seem to be trying to fix are real problems.
You're missing the point - the fact that it is unscientific is PRECISELY why you cannot say it is wrong.
If you could say it was wrong, you could make the case it was science - bad science perhaps, but it would at least fit in the truth/falsity discussion.
Since you cannot say whether it is wrong (or right) - the fact that people mix it with theories that can be proven by more than mere matters of opinion (i.e.: science) - is more fundamentally broken than any particular conclusion.
Saying "ID is plain wrong, go away" is not productive to confronting the real problem, because in the big scheme of things it doesn't matter that much if people believe in the theory of evolution in particular or not - bad theories lose over time (that's the point of science).
The real problem is that so many people don't understand what science IS, and that can cripple the very process long-term.
That is an unjust and inaccurate statement.
You can't say ID is wrong just because of your bias - when it is clearly "not even wrong" - it's very wrongness impossible to prove or falsify.
To say it is completely wrong demeans everyone else who is honestly and properly wrong...
Or for that matter, those who hold non falsifiable assumptions as matters of faith and philosophy, without misrepresenting them as science (which in the end includes pretty much everyone).
That's a terrible metaphor. The school is not just like your parents, the school is essentially a babysitter.
For a valid comparison, replace that with:
"What if your babysitter found you may have done something illegal (when she was not babysitting)? Should they not punish you? Should they instead go straight to the police? ".
The absurdity of the choices is evident - the only sensible choice is "go straight to the parents". Directly punishing you is not within her authority, and escalating to the police should be a measure for extreme circumstances / concerns about the parents.
Schools do have in loco parentis, but only as caretakers for the child during the educational process. At all other purposes / circumstances, the parent is not absent and the interests which have been delegated (educational process) are not at risk. There are good historical reasons to be wary of institutions going overboard with powers of that type - let parents keep the power and the duty to be parents.
It is reasonable that school officials would react and try to put some constructive punishment in place - but this should really have gone through the parents authority.
The school should have gotten together with the relevant parents, expressed their concerns, and make some suggestions as to the plan of action - but the punishment should have been excercised by the parents, who have the full authority for that, and are best able to adapt it to individual circumstances.
Sounds like their teacher was as much of an elitist asshole as you, and this is the result.
It worked: the students figured it out by themselves: press the "Build" button on the IDE and it works.
Why on earth would they think there is an issue with that, since you let them figure out the details by themselves?
Really? Did you read the article, at all?
He explicitly favors "closed development" followed by "open source" releases. Read the 2nd page, 8th paragraph, specifically.
OSS is more than a set of licenses these days - it is also a methodology to develop software, which is (or aims to be) very much community-driven. When that community is chronically convinced that "Unix == computer-science", the author's arguments sound quite rational.
Historically, communities and committees are not great sources of radical innovation.
Innovation tends to come more easily from individuals and smaller groups with tighter focus over longer periods - there is little reason to say this doesn't apply to software as much as it applies to other arts and sciences.
To abuse another analogy from the article: speciation is good, not 'evil'. It is what drives evolution, and without it our 'Eden' would likely be populated by very robust, stable, but terribly uninteresting bacteria.
Personally, I don't think his "encapsulated development" needs to be closed-source at any point - the informational and normative conformity that would slow down innovation doesn't feed from the source being open, but rather from the communal development.
For that matter, any innovative open source (and most successful) projects I can think of used that model anyway, intentionally or not, until the project reaches some maturity, stability becomes more important, and the community takes a greater role.
Dude, this is Slashdot.
We get your point, but this may not be the crowd to be making that argument.
Most readers have more authority to complain about your chirp tag not passing xml validation than to testify about the practices of medical impersonation among the western youth.
I know you're trying to be funny, but if you replace that with the actual business model it sounds a lot more sensible:
"(Almost) no one's ever going to BOTHER cracking the encryption..."
It will all come down to pricing and convenience - if the price is right, and the restrictions aren't absurd, most people will be more than willing to pay to download yet another TV-show-season pack.
Of course, media companies do not have a history of being very smart about either - but the greatest problem is neither with the basic business model, per se, nor with the "online" extension of that. It's just that they keep doing stupid shit with the parameters (price, forced previews / ads on bought content, etc.) so that they not only make it a bad deal, but actively piss off their consumers.
And I would agree completely... but the argument that Bioshock was a remake/adaptation of SS2 is still valid.
That doesn't make it "bad", of anything, it is part of what makes the game as good as it is.
But if some people are disappointed by the lack of originality it is understandable and a valid point - how important it is is subjective, but pretending that they're not almost identical reeks of fanboism.
As I said, I'm a big fan of both games - although I do consider SS2 was superior in some ways, Bioshock is still high on my best-games-ever list. I'm also a big fan of "Scotland, Pa", for that matter - which I've found a better movie than most MacBeth renditions.
There is no shame in making an adaptation (even if MacBeth may be a better marketing bet than a video game) - and many adaptations can be far better than the original. There is a bit of shame if all your new original work feels like an adaptation of your first hit - but I never got the impression the expectations of stark originality were driven by the people making the game anyway.
Have you played both games?
They're not "equivalent" in some high-concept sense - they're practically identical in every meaningful sense.
"Ambition leads man to great betrayal, a rise in power, and ultimate plants the seeds of his own destruction" - that is a common thread to many tragedies in fiction.
But when you have the man and the wife enacting the same scenes, the three witches, the prophecy of power and a promise of invincibility that turns out to prophesize their doom... I'm sorry, but MacBeth is MacBeth, whether it is in 11th century Scotland, or modern Australia, or a Pennsylvania burger joint.
I'm a big fan of both games, but there's no way you can claim the similarities are just common game mechanics.
The story in the background was different enough, and well worth playing - but the game in the foreground was, for good or evil, the same game.
I don't think many people say Javascript sucks per se.
But there is serious discussion about whether Javascript sucks for the job.
Still, I'd agree with you completely that the biggest problem is not the language, but the platform (browser compatibilities being a big, but not the only, issue). And then every framework just tries to hide both javascript and the platform - neither of which is designed to do what we're making it do...
It's not hard to understand the motivation, but that doesn't justify it - nor does mean as a method it even works.
Personally, nuclear power doesn't scare me. But your argument does - in any context.
I'm not concerned about car drivers who may have a drink or two in their system - but I'm afraid of any driver who consistently lies about their alcohol consumption, because they think 'others might overreact'.
I don't see a better first step to solve the problem, than to embrace transparency as part of the safety process (and the corporate image / PR). A vicious cycle of bad precedents does not help to make the case.
Hysteria and massive liability risks are not unique to nuclear power - drug / health industries have to deal with the same issues, with what are probably higher and more concrete risks of liability. They typically deal with it and with their own 'hippies', and have processes to avoid being tempted to be 'gun-shy' because accusations of a 'cover-up' puts them at unacceptable financial risk.
Not sure the critique to Coldfusion applies - it became irrelevant because it got replaced... by a bunch of frameworks that followed similar, but technically more powerful approaches (e.g.: JSP tags in a dozen dialects).
The general idea is old, tried and true in computer science: "Learn a new straightforward, targeted language, to avoid learning a complex language that was never intended for these needs". And is the way yet another thousand toolkits try to solve the AJAX problem.
The sound-ness of the approach for AJAX, of course, is based on two things:
- The subjective suckyness of the javascript language for the job - this is probably a matter of taste and background.
- Whether changing the language is enough to solve the complexity / scale problems.
Although I'm no great fan of javascript as a non-small-app development platform, I think the second problem is more important. I think there is only so much you can do by pretending that javascript is assembler, while carrying over all the other baggage of the html+script world.
That may or may not be enough, depending on what people think AJAX should be... for all the ambitious hype of WebOS and office apps on AJAX, I don't think it is enough. The pain is not the syntax, it's the programming and execution model, which is not going to go away by wrapping it into java classes or xml tags.
I think the point is that the ISO stamp doesn't really change that much - it is not what makes it immensely useful, and it was already immensely useful without it being an ISO standard.
Huh?
If they're planning to file a copyright infringement lawsuit then, by definition, they (LANCOR) are literally arguing that software was copied.
This should be funny enough without distorting the facts.
It seems you are establishing an undue connection between two separate statements.
From the linked articles, this is the sequence of events as I understand them:
1) LANCOR files a patent infringement suit against OLPC in NIGERIA.
2) Negroponte claims the lawsuit is without merit.
3) LANCOR (obviously) responds it is valid and all your base are belong to us, AND
4) They plan to file a SEPARATE copyright infrimengement lawsuit in a U.S. court.
Presumably, that would be because they do not have a claim to an US-based patent (if their patent was filed only in Nigeria), but they think they have a valid copyright claim, since copyright is both implicit and more broadly supported by international treaties (from what limited data I've read).