You can't sensibly say that some other programmer should have applied (eg) BSD to some code so as not to "restrict" users.
Everything else you say is true. This one doesn't make any sense to me, though. Why can't I? If I can't question the choice of license, then upon what basis can I make my own choice of licences for the code I write? If one isn't supposed to question licenses, then why does the FSF get to recommend the GPL over the LGPL?
The answer seems obvious to me: different licenses have different purposes, and there are some purposes for which the GPL is simply unfit; for which the GPL, in fact, reduces freedom.
The problem in this case would simply be the licence applying to what you release.
And IMO it wouldn't be SCO's problem; if their allegations are true, it would be IBM's and our problem. For an example of this kind of thing, consider RSA's RC4, an encryption algorithm that was secret for a while, then was anonymously posted to Usenet. RSA claimed that it was a stolen trade secret, but because nobody could trace it, they chose to simply threaten to sue anyone who used it in a product that claimed to support RC4. Essentially, you can't make money on a product which you claims supports their algorithm without licensing the algorithm from them.
I don't see much of a chance of anyone buying the "they released it under the GPL!" argument; the problem is that they _did not_ release it, they simply redistributed it. Even if they made changes to that specific part of the code you still can't show that they did anything knowingly. I'm sure an expensive enough lawyer could "convict" them, but I think the result would be to cover over the real problem, which would be IBM releasing non-GPLable code as GPL.
Oh, of course, I have to finish by repeating the technical solution to this problem: rewrite the problematic code. Duh.
Yes, reduced size is a continued goal, and there's still some waste to trim. So you should expect to se the size continue to go down.
Although I honestly don't know whether it'll ever reach the size of Opera without Java; that's elegantly crafted. In theory they could, since they could pull the Java console out of the app and put it into an extension; but I don't know whether that'll ever be a priority.
I don't know how Gore would behave, but I know how he behaved. I'm not ashamed of him or anything (although I'm certainly far from impressed); I don't blame him any more than I blamed Bush; but I don't think it's right to single out Bush as though his conduct during the debacle was any worse than Gore's.
If, as the prior post claimed, Bush's conduct was an indicator of later bad performance, then Gore's conduct would have been as well.
Now, I just happen to believe that it's not really a good measure; the only thing it showed perfectly well is that neither one was willing to give in.
I do believe that there's some blame to be distributed between the candidates, but I can also see that I'll never have enough information to enable me to place it -- so I won't bother. The other parties' guilt seems to be easier to establish.
It seems to me that you're trying to imply that people who vote Democratic are simply stupider (more prone to error) than people who vote Republican. Perhaps you're not, but you're giving that impression.
No, I've seen this before -- he's basing this on a statement of alleged fact, that Gore picked up an enormously higher number of votes in the manual recount than Bush did. I'm not going to bother looking this up right now, you'll have to make your own call on its accuracy, but I suspect that it's valid; there were not that many no-pres-vote ballots compared to the number of ballots with a valid vote on them, so in order to plausibly claim there was a chance of winning the election, Gore would have to have come up with a truly phenominal ratio on the blank ballots.
There are two possible conclusions to reach from this fact (if fact it is): first, that people intending to vote for Gore made mistakes more often than people intending to vote for Bush, or second, the recounting standards were applied inconsistently but in favor of Gore.
I believe that the previous poster would claim the second was more likely; I'm inclined to agree with him, since the counties Gore concentrated most on had political machinery almost entirely controlled by people belonging to the Democratic party. (No conspiracy theory here; it's a simple matter of shared interest. No accusations of fraud are needed, either; interpretation of ambiguity is hard enough anyhow.)
It could equally be true that Republican-controlled districts were simply more lenient toward errors which favored Republican votes. The Republicans certainly claimed that the Democrats were so biased in judging problematical votes.
Correct -- but that wouldn't result in Gore catching up with Bush; instead it would result in a continued tie.
Finally, IIRC Gore offered at one point that all the votes should be recounted; overvotes, undervotes, all votes. He should have done itn much earlier in the process,
Yes, he should have -- ideally before trying to run out the clock his own way, including deliberately appealing to exclude counting certain republican-leaning ballots.
That was SUCH a debacle. The news channels, the vote counters, the candidates, the Florida legislatures, the voters who approved the ballots, the Supremes (both courts)... Nobody looked good.
Honestly, the only people I sympathise with are the candidates; I don't think they did well, but at least they both were straightforwardly looking after their own interests. I would be more impressed if they showed more courtesy, but one has to admit that it was a contest, and letting the other side win when things were so close would seem tragic...
(The voters? Naw -- they voted close, they got a close race. That's the shakes with voting.)
Bush chose not to take that chance, however, showing that he was less interested in the American political process or the will of the American people than in a favorable result for himself - a philosophy he has continued to exhibit since.
This analysis happens to apply to both candidates, doesn't it.
-Billy
Re:employment and advancement
on
Inside SAIC
·
· Score: 1
I see, that makes sense.
Look at the message I'm replying to -- it's claiming that SAIC hires only on the basis of certifications (partially true). I'm trying to explain that although SAIC's customers DO check for certifications and not much else, skill is still meaningful with or without a cert -- at least as much as it is anywhere else.
Your example has simply nothing whatsoever to do with my claim. I'm not saying that there's no cruft at SAIC; I'm just saying that the SAIC policy of requiring certification has both reasons AND workarounds, and that they're (in my experience) commonly applied. Your example simply shows that at least one person can tell a story of an incompetent SAIC employee. (I can tell more stories -- but I won't.)
-Billy
Re:employment and advancement
on
Inside SAIC
·
· Score: 1
This anecdote is so far removed from what I'm talking about... I don't know what to say.
And then there seems to be the implicit expectation that everyone at SAIC be highly competant, motivated, and so on... I guess SAIC should be flattered that your opinion of them is so high, but you need to be warned that no company is so good that you CAN'T find examples of bad apples.
-Billy
Re:SAIC is Employee-Owned - Employee-Ownership Roc
on
Inside SAIC
·
· Score: 1
Read the post you're replying to again. The author is advertising his own employee-owned business, not SAIC.
-Billy
Re:employment and advancement
on
Inside SAIC
·
· Score: 4, Informative
Partially true, but SAIC pays you to get those degrees and certs, since they are required by most of SAIC's customers. They pay for the class and and books in full so long as you make a C or better.
Their policy here makes sense, considering that most of their customers (well, their biggest customer, at least; the US gov't) explicitly check each employee assigned to work on the project, and they don't take the time to verify specific knowledge, only certs, degrees, and experience.
The managers, as far as I've found, are very good at cutting through the BS to find real skill; you will get picked if you've got what it takes, but the manager may have to "sell" you to the customer based on some of your other credentials until you actually get something formal.
You're right in general, whether or not they use flash for this in specific. But you know what? It's a pity. I like flash a LOT more than DHTML. It could have had so many uses for good rather than eeevil.
Oh well -- I use Phoenix and don't have flash installed for it. When I want to see something with flash, I load IE.
There has to be a better way, really.
Oh, I guess it's good that we're getting SVG. That's got a lot of the goodness of flash. Of course, the problem is that with javaScript you can manipulate it just like flash -- and there you go, back to the eeevil. Only without any convenient way to turn it off.
This signature, when enforced by hardware, also becomes part of an overall technological protection measure within the meaning of the DMCA. The DMCA requires the "authority of the copyright holder" to get access to a work protected by a technological protection measure (TPM).
But the GPL explicitly grants unrestricted permission to use (and therefore access) the software, and ALL of the copyright holders have granted licence to their code under the GPL. You missed that when you jumped to the part about copying and modification.
I also don't understand your contention that ALL of the copyright owners would have to grant permission to access the TPM-protected software. I think that ANY of them could grant such permission.
This doesn't relate to the merits of the case, but I thought that was the dumbest PA strip in a long time (and, in spite of the general humor, they drop some real bombs from time to time). Okay, humor's in the eye of the beholder, but that's my opinion.
As for the case, I doubt that PA has a leg to stand on -- it's parody, but it's not parody of SS; it's actually parody of a completely unrelated video game designer. So it's not fair use; it's just trademark dilution and possibly a tiny bit of copyright infringement (a very tiny possibility of that last!).
On to a different question: _should_ it be legal to use copyrighted and trademarked work in a parody of something unrelated to the copyrighted/trademarked materiel? I'd like to see some discussion of that question.
You're quoting the article -- in most contexts that would imply that you read it. Considering what you quoted together with what you said, though, you can't possibly have.
Did you read what her job was at DoubleClick? Yes, DoubleClick is evil, and was much worse -- but she's almost single-handedly responsible for every decent thing they've done.
Who better to protect our privacy than those who know how to completely decimate it?
Nobody else would even possibly have a chance -- it's exactly the same situation as security, for exactly the same reasons. The people who can protect you are in both cases the people who at least KNOW how to destroy you -- the knowledge is the only way to have the ability. Anyone without the knowledge will be wasting their time protecting things that don't need protection while ignoring things that do.
This doesn't prove that she's going to do the right thing, of course. But it should silence the knee-jerk condemnation.
Hmm, my experience is slightly different. The 'fun' part is, of course, rather subjective-- I find dyanmically typed languages more frustrating, which is why I personally wouldn't agree with that, but, of course, YMMV-- but I definitely disagree about the part with "good results being produced faster". They do produce results faster, often even reasonable results. But good results (i.e. stable code) take much longer to achieve, in my experience.
Interesting experience; definitely at odds with mine. In my experience quite stable code is produced quite quickly with either. The key is testing and design (and how they work together), not static or dynamic typing.
As for the other points -- yes, fun is definitely in the eye of the beholder. I've definitely had fun in every language I've worked with (even Fortran); but my experience is that languages like Python are a blast to program in -- the difference is highly noticable, more so every time I switch.
I've rarely had to "work against" strong type systems in the past. Sufficiently expressive type systems are important for this to make sense, I'll admit that; it requires a certain kind of thinking to be able to make use of strong typing effectively. This restriction on "free thought" may be what people find most offensive, but I'm not sure.
I've seen some type systems proposed which would allow almost as much freedom as dynamic typing; the problem is that they uniformly require a LOT of keyboarding. As a result, I haven't seen any of them actually implemented.
[...]the neccessity for implementing a test suite can be considered as a sign of weakness of static checking.
That's fine, and I would agree, but keep in mind that it's a fundamental, natural "weakness" of static checking. You can't get around it. You mention that in your next paragraph, but it needs to be made clear that you can't skip the testing even if you've got arbitrarily strong type correctness.
No test suite writer will ever be able to test for all the things that fall out of a static checker for free.
That's just completely false. A simple test suite can check for almost all the things a strong static typecheck gives; it takes a lot more to test for EVERYTHING, of course, but it's definitely possible.
Good tests are easy to write. I used to think they were hard; but then I started treating tests as part of my design, to be written at the same time as my design; and suddenly what used to be boring work (making my design break) became part of the most interesting work (making my design complete). I can highly recommend "Test Driven Development", known as TDD.
In conclusion, I believe that we need static typechecking, static checking in general, and test suites for everything we cannot formalise (for whichever reason) if we want to ever resolve the "software crisis". Without any of these, we'll just keep inventing more crappy code.
Sounds like the voice of reason and experience to me! I don't give formalism any place there, since in my experience it can't shortcut testing at all; but otherwise I agree with you.
I'm not sure whether I agree with you or not. On the one hand, I really like strong static typing; it's worked well for me. On the other hand, my experience and the experience of others I've seen is that dynamicly typed languages are not only more fun to program in, they produce good results faster.
My theory is that this is just bad implementation on the part of the static languages (this is obvious with C++, less obvious with ML, subtle with Haskell); but I don't know this, it's only a suspicion.
I don't want to spend the rest of my life writing test suites to check for errors which even trivial type systems can detect.
Put that the other way around -- do you want to spend the rest of your life working against strong typing systems which only detect errors that even the simplest test suite would automatically find?
You ARE writing those test suites anyways, right? Because there are errors that NO static type system can ever find but a simple test can.
No, 1.0 doesn't mean enterprise-ready. It means ready for general use.
I'm happily using Phoenix, and I used Mozilla before that; but the fact that I'm using it doesn't mean that I'll close my eyes to its problems.
Of course, the fact that I'm being cynical shouldn't mean that I can't tell a good thing when I see it -- this reorg is _exactly_ the right thing. (Choosing Phoenix is just a minor detail, but it's also IMO a good idea.)
I agree that Mozilla doesn't have the maturity to support a mission-critical enterprise app.
I don't agree that this is anything related to pulling the rug out from under anyone. Your hypothetical tech director deserves to be fired for campaigning to have an unstable, unready application put in a mission-critical enterprise setting: that is precisely the reason why this change _had_ to happen, so that someday Mozilla _can_ be ready.
I don't want to watch a DVD on my current computer. BUT... As soon as I can get a computer that _also_ can do what my DVD player can (including displaying its output on my TV), I'm switching. Why? Because the computer that could do that could also serve as an audio center, PVR (like TiVo), and a number of other things.
Scott gives some perceptive and interesting answers, but his discussion of Test First is incorrect due to a pair of misunderstandings about how it works.
I'm going to use the term "Test Driven Development", or TDD, since that's the current usage.
First, TDD doesn't start by coding a lot of tests. That would indeed be discouraging and counterproductive. It starts by coding _one_ test, and then immediately implementing just enough code to satisfy that one test. The point here is immediate feedback.
Second, TDD isn't about producing tests; it's about designing software. When you write a TDD test, you're actually producing a component of the product's detailed design. Most programmers enjoy design; the reason most give to dislike it is that design usually lacks immediate feedback. With TDD, any reason to dislike design is gone, since the feedback is immediate.
So when Scott says that TDD doesn't take into account the psychology of programmers, he's simply incorrect -- it does.
Of course, the original questioner made the same mistake of identifying TDD with testing. To him: TDD isn't about testing. TDD produces a lot of useful tests, but analysing the effectiveness of the tests isn't something that TDD looks at. A good programmer or team will have to put some effort into a test plan which incorporates the TDD tests together with whatever else is needed to verify and validate the requirements.
Your argument's been used before. Try repeating it, but instead of mentioning "starting a business" try "breaking a window." Yup, breaking a window gives people jobs -- the glazer, policemen, and so on all have something to do thanks to your efforts.
Enough effort has been spent refuting that fallacy; in short, you have to consider not what appears to have been created, but also where the effort to create that came from, and what else the creation effort was being spent on.
Those are perfectly good constraints, but they have one thing in common: they serve ONLY to allow relational (or SQL) databases to imitate business objects. If your program doesn't use a database, those constraints are automatically already being observed. There's no need or possibility of expressing them.
It's very much like putting the constraint of being greater than or equal to zero on an unsigned integer. The constraint is expressible, but it has no meaning. Another example would be requiring a datum to be boolean (0 or 1) when it's stored in a single bit.
The relational format is HUGELY more expressive than any specific object model; thus, it needs constraints when it's used to model any specific object model. But that doesn't mean that the object model has anything to gain from the constraints; they are specific to the relational model, needed only by the relational model.
But let's get really basic here: enforcement of foreign key relationships is an example of a constraint that lives outside of the application.
I have to be honest: my database education is mostly gained in the trenches. I've read the debunking site, as I mentioned, but my knowledge is only light. So you may have a point, and you just chose bad examples; but your examples are definitely bad.
With a REFERENCES constraint on a column, for example, then no client application can add a value in that column unless it exists in the related column of another table.
With a "reference" an object must point to some other actual object. The REFERENCE constraint serves to model a property of an object; it doesn't do anything that isn't already present by nature in a object system.
This is important -- _all_ of the data consistency checks a relational database can uniquely provide (i.e. an object language can't) are there simply to make sure that your data represents an object. If you had been using an object in the first place, those checks are simply extraneous, irrelevant, and impossible.
Most high-end SQL systems allow for many more types of constraints, such as CHECK constraints (don't allow a value in this column unless it meets certain parameters),
Obviously present in object systems.
DOMAIN constraints (these are really cool, essentially letting you have the equivalent of named subtypes, and much more),
Obviously present in object systems.
and of course, the infamous TRIGGER, which makes up for SQL's weakness in declarative logic.
Only by mingling it in a logically inconsistant way with imperative logic!
Thanks for the book recommendation -- I've been looking for a good one.
And, I agree that databases are not necessary for ALL information involved in any application. Often times a system like Prevayler might be a perfect intermediate complement to a back-end database where permanent data is archived, for example.
That sounds like a great arrangement, particularly since older data is more likely to need good ad-hoc queries. And "newer data" can be added to the older data very quickly, thanks to the sort of mirroring you can do with object prevelance.
Point is, where mission-critical or enterprise-critical data is centralized as an organization's primary record of all business doings, I am convinced that the data constraints and integrity should live outside the application.
I agree with everything else you said in this post, but I'm not sure what you mean here. How can data constraints be outside of the application if the application's responsible for the data? If you mean that someone aside from my programmers should be responsible for the data my programmers process, I'm not sure I agree; if you mean that there should be a way to check, repair, and back up your data without depending on how the application sructures the data, I do agree.
Slashdot Mirror
You can't sensibly say that some other programmer should have applied (eg) BSD to some code so as not to "restrict" users.
Everything else you say is true. This one doesn't make any sense to me, though. Why can't I? If I can't question the choice of license, then upon what basis can I make my own choice of licences for the code I write? If one isn't supposed to question licenses, then why does the FSF get to recommend the GPL over the LGPL?
The answer seems obvious to me: different licenses have different purposes, and there are some purposes for which the GPL is simply unfit; for which the GPL, in fact, reduces freedom.
-Billy
The problem in this case would simply be the licence applying to what you release.
And IMO it wouldn't be SCO's problem; if their allegations are true, it would be IBM's and our problem. For an example of this kind of thing, consider RSA's RC4, an encryption algorithm that was secret for a while, then was anonymously posted to Usenet. RSA claimed that it was a stolen trade secret, but because nobody could trace it, they chose to simply threaten to sue anyone who used it in a product that claimed to support RC4. Essentially, you can't make money on a product which you claims supports their algorithm without licensing the algorithm from them.
I don't see much of a chance of anyone buying the "they released it under the GPL!" argument; the problem is that they _did not_ release it, they simply redistributed it. Even if they made changes to that specific part of the code you still can't show that they did anything knowingly. I'm sure an expensive enough lawyer could "convict" them, but I think the result would be to cover over the real problem, which would be IBM releasing non-GPLable code as GPL.
Oh, of course, I have to finish by repeating the technical solution to this problem: rewrite the problematic code. Duh.
-Billy
Yes, reduced size is a continued goal, and there's still some waste to trim. So you should expect to se the size continue to go down.
Although I honestly don't know whether it'll ever reach the size of Opera without Java; that's elegantly crafted. In theory they could, since they could pull the Java console out of the app and put it into an extension; but I don't know whether that'll ever be a priority.
-Billy
2.4GHz isn't a "natural frequency of water" -- that's just a legend.
:-).
Some discussion of, and experiments using, microwave ovens can be found at that link.
And your laptop will cook your leg through direct heat radiation (and conduction), no microwaves needed.
I don't know whether cell phones and such are safe; I just know that that isn't how microwaves work
-Billy
I don't know how Gore would behave, but I know how he behaved. I'm not ashamed of him or anything (although I'm certainly far from impressed); I don't blame him any more than I blamed Bush; but I don't think it's right to single out Bush as though his conduct during the debacle was any worse than Gore's.
If, as the prior post claimed, Bush's conduct was an indicator of later bad performance, then Gore's conduct would have been as well.
Now, I just happen to believe that it's not really a good measure; the only thing it showed perfectly well is that neither one was willing to give in.
I do believe that there's some blame to be distributed between the candidates, but I can also see that I'll never have enough information to enable me to place it -- so I won't bother. The other parties' guilt seems to be easier to establish.
-Billy
It seems to me that you're trying to imply that people who vote Democratic are simply stupider (more prone to error) than people who vote Republican. Perhaps you're not, but you're giving that impression.
No, I've seen this before -- he's basing this on a statement of alleged fact, that Gore picked up an enormously higher number of votes in the manual recount than Bush did. I'm not going to bother looking this up right now, you'll have to make your own call on its accuracy, but I suspect that it's valid; there were not that many no-pres-vote ballots compared to the number of ballots with a valid vote on them, so in order to plausibly claim there was a chance of winning the election, Gore would have to have come up with a truly phenominal ratio on the blank ballots.
There are two possible conclusions to reach from this fact (if fact it is): first, that people intending to vote for Gore made mistakes more often than people intending to vote for Bush, or second, the recounting standards were applied inconsistently but in favor of Gore.
I believe that the previous poster would claim the second was more likely; I'm inclined to agree with him, since the counties Gore concentrated most on had political machinery almost entirely controlled by people belonging to the Democratic party. (No conspiracy theory here; it's a simple matter of shared interest. No accusations of fraud are needed, either; interpretation of ambiguity is hard enough anyhow.)
It could equally be true that Republican-controlled districts were simply more lenient toward errors which favored Republican votes. The Republicans certainly claimed that the Democrats were so biased in judging problematical votes.
Correct -- but that wouldn't result in Gore catching up with Bush; instead it would result in a continued tie.
Finally, IIRC Gore offered at one point that all the votes should be recounted; overvotes, undervotes, all votes. He should have done itn much earlier in the process,
Yes, he should have -- ideally before trying to run out the clock his own way, including deliberately appealing to exclude counting certain republican-leaning ballots.
That was SUCH a debacle. The news channels, the vote counters, the candidates, the Florida legislatures, the voters who approved the ballots, the Supremes (both courts)... Nobody looked good.
Honestly, the only people I sympathise with are the candidates; I don't think they did well, but at least they both were straightforwardly looking after their own interests. I would be more impressed if they showed more courtesy, but one has to admit that it was a contest, and letting the other side win when things were so close would seem tragic...
(The voters? Naw -- they voted close, they got a close race. That's the shakes with voting.)
Bush chose not to take that chance, however, showing that he was less interested in the American political process or the will of the American people than in a favorable result for himself - a philosophy he has continued to exhibit since.
This analysis happens to apply to both candidates, doesn't it.
-Billy
I see, that makes sense.
Look at the message I'm replying to -- it's claiming that SAIC hires only on the basis of certifications (partially true). I'm trying to explain that although SAIC's customers DO check for certifications and not much else, skill is still meaningful with or without a cert -- at least as much as it is anywhere else.
Your example has simply nothing whatsoever to do with my claim. I'm not saying that there's no cruft at SAIC; I'm just saying that the SAIC policy of requiring certification has both reasons AND workarounds, and that they're (in my experience) commonly applied. Your example simply shows that at least one person can tell a story of an incompetent SAIC employee. (I can tell more stories -- but I won't.)
-Billy
This anecdote is so far removed from what I'm talking about... I don't know what to say.
And then there seems to be the implicit expectation that everyone at SAIC be highly competant, motivated, and so on... I guess SAIC should be flattered that your opinion of them is so high, but you need to be warned that no company is so good that you CAN'T find examples of bad apples.
-Billy
Read the post you're replying to again. The author is advertising his own employee-owned business, not SAIC.
-Billy
Partially true, but SAIC pays you to get those degrees and certs, since they are required by most of SAIC's customers. They pay for the class and and books in full so long as you make a C or better.
Their policy here makes sense, considering that most of their customers (well, their biggest customer, at least; the US gov't) explicitly check each employee assigned to work on the project, and they don't take the time to verify specific knowledge, only certs, degrees, and experience.
The managers, as far as I've found, are very good at cutting through the BS to find real skill; you will get picked if you've got what it takes, but the manager may have to "sell" you to the customer based on some of your other credentials until you actually get something formal.
Good place to work.
-Billy
You're right in general, whether or not they use flash for this in specific. But you know what? It's a pity. I like flash a LOT more than DHTML. It could have had so many uses for good rather than eeevil.
Oh well -- I use Phoenix and don't have flash installed for it. When I want to see something with flash, I load IE.
There has to be a better way, really.
Oh, I guess it's good that we're getting SVG. That's got a lot of the goodness of flash. Of course, the problem is that with javaScript you can manipulate it just like flash -- and there you go, back to the eeevil. Only without any convenient way to turn it off.
-Billy
This signature, when enforced by hardware, also becomes part of an overall technological protection measure within the meaning of the DMCA. The DMCA requires the "authority of the copyright holder" to get access to a work protected by a technological protection measure (TPM).
But the GPL explicitly grants unrestricted permission to use (and therefore access) the software, and ALL of the copyright holders have granted licence to their code under the GPL. You missed that when you jumped to the part about copying and modification.
I also don't understand your contention that ALL of the copyright owners would have to grant permission to access the TPM-protected software. I think that ANY of them could grant such permission.
-Billy
This doesn't relate to the merits of the case, but I thought that was the dumbest PA strip in a long time (and, in spite of the general humor, they drop some real bombs from time to time). Okay, humor's in the eye of the beholder, but that's my opinion.
As for the case, I doubt that PA has a leg to stand on -- it's parody, but it's not parody of SS; it's actually parody of a completely unrelated video game designer. So it's not fair use; it's just trademark dilution and possibly a tiny bit of copyright infringement (a very tiny possibility of that last!).
On to a different question: _should_ it be legal to use copyrighted and trademarked work in a parody of something unrelated to the copyrighted/trademarked materiel? I'd like to see some discussion of that question.
-Billy
You're quoting the article -- in most contexts that would imply that you read it. Considering what you quoted together with what you said, though, you can't possibly have.
Did you read what her job was at DoubleClick? Yes, DoubleClick is evil, and was much worse -- but she's almost single-handedly responsible for every decent thing they've done.
Who better to protect our privacy than those who know how to completely decimate it?
Nobody else would even possibly have a chance -- it's exactly the same situation as security, for exactly the same reasons. The people who can protect you are in both cases the people who at least KNOW how to destroy you -- the knowledge is the only way to have the ability. Anyone without the knowledge will be wasting their time protecting things that don't need protection while ignoring things that do.
This doesn't prove that she's going to do the right thing, of course. But it should silence
the knee-jerk condemnation.
-Billy
Hmm, my experience is slightly different. The 'fun' part is, of course, rather subjective-- I find dyanmically typed languages more frustrating, which is why I personally wouldn't agree with that, but, of course, YMMV-- but I definitely disagree about the part with "good results being produced faster".
They do produce results faster, often even reasonable results. But good results (i.e. stable code) take much longer to achieve, in my experience.
Interesting experience; definitely at odds with mine. In my experience quite stable code is produced quite quickly with either. The key is testing and design (and how they work together), not static or dynamic typing.
As for the other points -- yes, fun is definitely in the eye of the beholder. I've definitely had fun in every language I've worked with (even Fortran); but my experience is that languages like Python are a blast to program in -- the difference is highly noticable, more so every time I switch.
I've rarely had to "work against" strong type systems in the past. Sufficiently expressive type systems are important for this to make sense, I'll admit that; it requires a certain kind of thinking to be able to make use of strong typing effectively. This restriction on "free thought" may be what people find most offensive, but I'm not sure.
I've seen some type systems proposed which would allow almost as much freedom as dynamic typing; the problem is that they uniformly require a LOT of keyboarding. As a result, I haven't seen any of them actually implemented.
[...]the neccessity for implementing a test suite can be considered as a sign of weakness of static checking.
That's fine, and I would agree, but keep in mind that it's a fundamental, natural "weakness" of static checking. You can't get around it. You mention that in your next paragraph, but it needs to be made clear that you can't skip the testing even if you've got arbitrarily strong type correctness.
No test suite writer will ever be able to test for all the things that fall out of a static checker for free.
That's just completely false. A simple test suite can check for almost all the things a strong static typecheck gives; it takes a lot more to test for EVERYTHING, of course, but it's definitely possible.
Good tests are easy to write. I used to think they were hard; but then I started treating tests as part of my design, to be written at the same time as my design; and suddenly what used to be boring work (making my design break) became part of the most interesting work (making my design complete). I can highly recommend "Test Driven Development", known as TDD.
In conclusion, I believe that we need static typechecking, static checking in general, and test suites for everything we cannot formalise (for whichever reason) if we want to ever resolve the "software crisis". Without any of these, we'll just keep inventing more crappy code.
Sounds like the voice of reason and experience to me! I don't give formalism any place there, since in my experience it can't shortcut testing at all; but otherwise I agree with you.
-Billy
I'm not sure whether I agree with you or not. On the one hand, I really like strong static typing; it's worked well for me. On the other hand, my experience and the experience of others I've seen is that dynamicly typed languages are not only more fun to program in, they produce good results faster.
My theory is that this is just bad implementation on the part of the static languages (this is obvious with C++, less obvious with ML, subtle with Haskell); but I don't know this, it's only a suspicion.
I don't want to spend the rest of my life writing test suites to check for errors which even trivial type systems can detect.
Put that the other way around -- do you want to spend the rest of your life working against strong typing systems which only detect errors that even the simplest test suite would automatically find?
You ARE writing those test suites anyways, right? Because there are errors that NO static type system can ever find but a simple test can.
-Billy
Latin:
The colloquial translation:
And, although Latin is inflected but English is only partially inflected, all of the words are identical!
So HAH.
This sort of poetry is common in obfuscated C contests, although the visual lack of distinction between 0 and O and I and 1 is also commonly needed.
-Billy
No, 1.0 doesn't mean enterprise-ready. It means ready for general use.
I'm happily using Phoenix, and I used Mozilla before that; but the fact that I'm using it doesn't mean that I'll close my eyes to its problems.
Of course, the fact that I'm being cynical shouldn't mean that I can't tell a good thing when I see it -- this reorg is _exactly_ the right thing. (Choosing Phoenix is just a minor detail, but it's also IMO a good idea.)
-Billy
I agree that Mozilla doesn't have the maturity to support a mission-critical enterprise app.
I don't agree that this is anything related to pulling the rug out from under anyone. Your hypothetical tech director deserves to be fired for campaigning to have an unstable, unready application put in a mission-critical enterprise setting: that is precisely the reason why this change _had_ to happen, so that someday Mozilla _can_ be ready.
-Billy
I don't want to watch a DVD on my current computer. BUT... As soon as I can get a computer that _also_ can do what my DVD player can (including displaying its output on my TV), I'm switching. Why? Because the computer that could do that could also serve as an audio center, PVR (like TiVo), and a number of other things.
-Billy
Scott gives some perceptive and interesting answers, but his discussion of Test First is incorrect due to a pair of misunderstandings about how it works.
I'm going to use the term "Test Driven Development", or TDD, since that's the current usage.
First, TDD doesn't start by coding a lot of tests. That would indeed be discouraging and counterproductive. It starts by coding _one_ test, and then immediately implementing just enough code to satisfy that one test. The point here is immediate feedback.
Second, TDD isn't about producing tests; it's about designing software. When you write a TDD test, you're actually producing a component of the product's detailed design. Most programmers enjoy design; the reason most give to dislike it is that design usually lacks immediate feedback. With TDD, any reason to dislike design is gone, since the feedback is immediate.
So when Scott says that TDD doesn't take into account the psychology of programmers, he's simply incorrect -- it does.
Of course, the original questioner made the same mistake of identifying TDD with testing. To him: TDD isn't about testing. TDD produces a lot of useful tests, but analysing the effectiveness of the tests isn't something that TDD looks at. A good programmer or team will have to put some effort into a test plan which incorporates the TDD tests together with whatever else is needed to verify and validate the requirements.
-Billy
Your argument's been used before. Try repeating it, but instead of mentioning "starting a business" try "breaking a window." Yup, breaking a window gives people jobs -- the glazer, policemen, and so on all have something to do thanks to your efforts.
Enough effort has been spent refuting that fallacy; in short, you have to consider not what appears to have been created, but also where the effort to create that came from, and what else the creation effort was being spent on.
-Billy
It seems to me that you're missing my point.
Those are perfectly good constraints, but they have one thing in common: they serve ONLY to allow relational (or SQL) databases to imitate business objects. If your program doesn't use a database, those constraints are automatically already being observed. There's no need or possibility of expressing them.
It's very much like putting the constraint of being greater than or equal to zero on an unsigned integer. The constraint is expressible, but it has no meaning. Another example would be requiring a datum to be boolean (0 or 1) when it's stored in a single bit.
The relational format is HUGELY more expressive than any specific object model; thus, it needs constraints when it's used to model any specific object model. But that doesn't mean that the object model has anything to gain from the constraints; they are specific to the relational model, needed only by the relational model.
-Billy
But let's get really basic here: enforcement of foreign key relationships is an example of a constraint that lives outside of the application.
I have to be honest: my database education is mostly gained in the trenches. I've read the debunking site, as I mentioned, but my knowledge is only light. So you may have a point, and you just chose bad examples; but your examples are definitely bad.
With a REFERENCES constraint on a column, for example, then no client application can add a value in that column unless it exists in the related column of another table.
With a "reference" an object must point to some other actual object. The REFERENCE constraint serves to model a property of an object; it doesn't do anything that isn't already present by nature in a object system.
This is important -- _all_ of the data consistency checks a relational database can uniquely provide (i.e. an object language can't) are there simply to make sure that your data represents an object. If you had been using an object in the first place, those checks are simply extraneous, irrelevant, and impossible.
Most high-end SQL systems allow for many more types of constraints, such as CHECK constraints (don't allow a value in this column unless it meets certain parameters),
Obviously present in object systems.
DOMAIN constraints (these are really cool, essentially letting you have the equivalent of named subtypes, and much more),
Obviously present in object systems.
and of course, the infamous TRIGGER, which makes up for SQL's weakness in declarative logic.
Only by mingling it in a logically inconsistant way with imperative logic!
Thanks for the book recommendation -- I've been looking for a good one.
-Billy
And, I agree that databases are not necessary for ALL information involved in any application. Often times a system like Prevayler might be a perfect intermediate complement to a back-end database where permanent data is archived, for example.
That sounds like a great arrangement, particularly since older data is more likely to need good ad-hoc queries. And "newer data" can be added to the older data very quickly, thanks to the sort of mirroring you can do with object prevelance.
Point is, where mission-critical or enterprise-critical data is centralized as an organization's primary record of all business doings, I am convinced that the data constraints and integrity should live outside the application.
I agree with everything else you said in this post, but I'm not sure what you mean here. How can data constraints be outside of the application if the application's responsible for the data? If you mean that someone aside from my programmers should be responsible for the data my programmers process, I'm not sure I agree; if you mean that there should be a way to check, repair, and back up your data without depending on how the application sructures the data, I do agree.
-Billy