While this has no chance in the world of going anywhere, and even the free software community takes reliance on software copyrights for granted, it's far from obvious that instructions to a computer should be protected in the same way as works composed for humans. In the early days of computers, it was uncertain whether and how copyright would apply. (Maybe someone else can dig up the history.)
It's especially difficult to argue that compiled software is an "expression" worthy of copyright, because it's unintelligible to humans. Society doesn't gain the benefit, part of the quid pro quo of copyright, of reading the expression in its original form. It is like a copyright on a physical tool (rather than its design specifications), which as far as I know doesn't exist.
I would be happy with a world in which copyright could only be claimed when source code is provided. Software companies could still impose their restrictive licenses, but at least we would get to learn from the code, borrow good ideas (assuming they're not patented...), find bugs, perform security audits, etc. I think this would make the industry healthier, if somewhat less profitable (because companies couldn't keep their ideas secret--a good thing for society).
This was a decent book, a precursor to the now more famous "Bringing Down the House", featuring the same brainy, persistent hacker types looking for an exploitable edge. It was a bit of a let down, in that the kids never really made the system pay off on a large scale, despite proving the concept. But the reasons for failing to make the big score are interesting: One, interpersonal issues, which take the story into California hippy culture. And two, the challenge, which slashdot readers will recognize, of pushing immature technology to its limits. These guys were putting a computer into the sole of a shoe and using digital radio communications in the 70s! The night at the table with modest successes interrupted by repeated electrocutions was precious.
To reiterate what the anonymous parent said, this shouldn't break your email, and the reason is a fundamental advantage of DomainKeys over SPF and Sender-ID. The latter require you to send mail through a special host, breaking the end-to-end nature of SMTP, which says that all hosts are equal. DomainKeys just requires you to use a special private key, which can be on any machine or even carried around with you on a keychain. It may require a bit of configuration, but it is far more flexible and egalitarian.
Well, ha ha, but most people I know who use powerful type systems don't actually use type debuggers.
Ok, I was being a little facetious, and I've never used a type debugger either. But I know that some people are pushing Haskell's type system pretty hard (eg, OOHaskell), and I think that some solution must be found for the notorious incomprehensible type errors before normal programmers can take advantage of things like this.
I do agree with the authors that "natural" problem-specific languages are useful for people who are not normally programmers (those people will increase in number dramatically, soon), but I disagree that this is an appropriate condition for the design of general-purpose languages.
The promise of embedded domain-specific languages is that you can create these friendly sub-languages within a sufficiently powerful general-purpose language. The casual programmer can stay within the sub-language, but the "real" language is right there when you need it.
Argh! The slashdot title completely mischaracterizes the article. The authors never use the term "natural language" at all! They call what they're talking about "natural programming", and if you read the article I hope you'll agree that it is something we should all be longing for: the ability to express ourselves in code that is close to the problem domain.
IMO, the best direction for natural programming is embedded domain-specific languages. The best direction for natural debugging is a harder problem. It's well known that many expert programmers still find "printf" debugging the best option, which suggests to me that tracing systems are promising. Of course, powerful type systems eliminate many possible run-time bugs, but then you need a type debugger....
Just from Merkey's lkml posting history (go back to 2000 or before for more juicy stuff), it is clear that he's mentally disturbed, on way too much peyote, or both (as well as an unusually talented engineer, if he could keep his illness out of the way). Take this post, for example. He knows himself, at some level, that he's nuts.
Merkey came recently into the limelight due to more lkml posts, which were again clearly the product of his insanity. He's not an agent of SCO, Canopy, or Microsoft; he's just deranged. He didn't go to the press. If slashdot and (especially) groklaw hadn't picked up on the "story", this would have mercifully died away.
His bizarre reversal should be ample evidence of that.
The best thing for him and for us would be to ignore his unfortunate condition. I can only find the current situation wasteful and tragic.
But that *IS* the point of Agile development, to ensure that every step of the way things are working toghether smoothly.
Although your initial point is good, your "Agile development to the rescue" follow-on falls flat. The components of IE do work together smoothly, beautifully in fact, according to the typical user experience. How secure a program is, and how well it works under normal testing, are almost totally unrelated. The way to secury systems is through careful, security-conscious design of both the components and their interactions, along with programming technologies and techniques that make it hard to screw up. Frequent integration might help security a bit by encouraging communication between component authors, but on the other hand the "make it work" attitude of "agile development" probably works against security.
Before more fully exploring the thesis of software developer as reified smithy, an examination of the role of the bookkeeper would be prudent, for the sake of juxtaposition, comparison, forecasting and nuance.
I'm begging someone to take away this blow-hard's keyboard.
I haven't finished the article--I find this writing style exceedingly tedious. Moreover, his analogy misses by a mile, for the programming analogy to the blacksmith is long dead, and indeed at best existed only in the very earliest days of the art. What does a blacksmith do? He mostly creates objects of a pre-existing design, which he has created hundreds of times before. Who does such repetitive work in the computer industry? Not who, what: compilers, interpreters, and assembly lines. Humans haven't had to perform these tasks for decades, and thank god! We get to work on creative design problems, whose complexity and difficulty far surpasses not only the tasks of the blacksmith, but the design of anything a blacksmith ever built! It never fails to shock me how laughably those who compare programs to tools or bridges underestimate this.
Max Goff is a senior consultant and principal of Decillion, Inc., a boutique M&A and technology consulting firm
Why am I not surprised? Codeless Development Environments? Is it the 80s again? Good grief.
Geesh, links to a press release and trade rag article, and not even the name of the project itself? Go read some real information about Rel, look at the examples, download the source, have fun.
I accept your position, but it sounds like you basically agree with me. You could have chosen to make free Java platforms a priority. If you had, you might have more recognition and support from the free software community. Also, you might have encouraged the wider adoption of those platforms, in which case they might be further along now. The same holds for any number of open source Java projects. (And personally, I think that anyone who cares about the long-term future of Java should support free Java to reduce their dependence on Sun.)
You don't have to tell me about gjc et all not being there yet. I know it. I realize you would have had to do without a lot of useful features and put up with a lot of bugs. But if you made a committment to supporting gcj, I bet they would bend over backwards to help you.
Probably because the Java Open Source community has largely segregated itself from the rest of the free software/open source community by supporting only proprietary Java platforms.
Re:Java checked exceptions suck, but how to fix th
on
Java 1.5 vs C#
·
· Score: 1
I'm talking about cases where you cannot prove that the exception won't happen, so your technique (which I'm sure you are not recommending for those cases) would be reckless. It is actually rare that you can prove a checked exception won't happen, either because it is impossible in principle (eg FileNotFound), or because the specification doesn't guarantee the exact conditions in which it may be thrown.
Java checked exceptions suck, but how to fix them
on
Java 1.5 vs C#
·
· Score: 1
I've written a lot of Java and agree that checked exceptions lose. (Not stating the reasons because it's been discussed to death and I'm lazy.) What I don't understand is why C# didn't adopt the following simple design: Make the cheked-ness of exceptions not a property of the exception class, but of the function throwing it. Then, the FileNotFound exception could be checked in openFile (where it is an expected case) and unchecked in readDataIJustWrote (where it is unexpected). Then, readDataIJustWrote could call openFile without either 1) declaring that it throws FileNotFound (breach of abstraction) or 2) wrapping FileNotFound in an unchecked exception (tedious and obfuscatory). IMO, this solves the biggest problems with mandatory exception checking.
In implementation, there should be some syntax to say, I know that this function I called throws a checked exception, but I want it to be unchecked for me. This could be part of the method declaration, or (even better) part of the expression that trips the exception.
There is some new and very radical stuff in this decision.
This was already sort-of answered, but let me reiterate: No, it's not. IANAL, but to me, this looks like a very conservative statment that copyright code and case law, read narrowly, favor Blizzard. The judge essentially, and IMO conspicuously, declined to consider any new issues in this case. It sounded to me like he was expecting an appeal and just wanted his ruling to establish the laws and precedents, on which a higher court might build new interpretations.
I honestly thing Greg missed his point. Eric is talking about the motivating development philosophies of the two systems. The Solaris philosophy is reliability, serviceability, observability, etc. The Linux philosophy is scratch your itch, and keep it simple. Of course nobody in Linux is against reliability (duh!), but it wasn't designed with reliability as foundational principle. Eric captures the difference in this zinger:
Perhaps you're thinking that because some customer really wants something, we just integrate whatever junk we can come up with in a months time. If this were true, don't you think you'd see Kprobes in Solaris instead of DTrace?
The Solaris guys made tracing a core priority and built a complete system for it. Linux waited until someone came along and contributed a system that is light enough to get past some very conservative objections, and lacks many of the features of DTrace. If observability were a core value of the Linux team, the core developers would have been working on this themselves years ago. (This is not to say that Kprobes won't mature into an excellent system, especially with Solaris's lead to follow.)
The only question is whether "scratch your itch" results, in the long term, in a more reliable (observable, etc) system than "design for reliability (observability, etc)". This is sort of a reprise of the "worse is better" argument, and I think it is by no means resolved.
I agree that "darcs suffers from the math problem", at least in that the implementation has focused on getting the semantics right and not on performance. (And unfortunately, the semantics are still not all right.) David maintains a kernel tree in darcs as a reminder of all the ways it doesn't scale. However, he also thinks most of them are fixable "post 1.0", and given how smart and capable he's proven to be, I give that claim some respect. Alas, I haven't had time to learn the math well enough to really be sure.
Regarding the economics, I don't think SCM is an undervalued field. Or at least, the free software community can find a way to value any field it needs to to make progress. (And for SCM, you're helping!) People said we didn't value desktops, or help, or installers, or web browsers, or couldn't do webdav or other protocols "at the top of the stack". "No fun" is what people have said about all of these. (And we're still not great at all these, but I think we're on a clear path to get there.)
What does this mean for darcs? It already has good semantics, is easy to use, and has a solid theoretical foundation. I think that free software folks will increasingly value distributed SCM and it will get more development man-power (if not as much as bk). These are excellent growth factors, and I suspect darcs will be able to handle 90% of projects out there in a few years. Unless the foundation is found to be weak (which is why I asked about that). Unless David loses interest before someone else steps up. Unless, unless, unless, but I like its chances.
Put it this way: I agree that open source does not solve things that are too hard or no fun. But the second is actually a non issue: when we need something, powerful economic and selective forces will make it fun for someone. So I really care about the first, and I'm trying to gauge whether distributed SCM is too hard for David and others attracted to darcs. I suspect that it's not too hard, at least to get to the 90% mark.
Thanks for taking the time to reply. I do enjoy reading what you have to say.
Ok, I admit I just want to get darcs mentioned here, but I really want to know what Tom (as well as Larry McVoy) thinks about darcs. In particular, whether the theory will stand up to real use and scale to large projects. I have a hunch that David Roundy has discovered much of what Larry McVoy said was a dozen PhD theses worth of research behind BitKeeper.
Check out this page. He says the biggest factor is rolling resistance due to uneven terrain, even on the road. However, the gearing may be part of the answer: a smaller wheel requires a higher gear ration, and higher gear ratios are less efficient.
Slashdot Mirror
It's especially difficult to argue that compiled software is an "expression" worthy of copyright, because it's unintelligible to humans. Society doesn't gain the benefit, part of the quid pro quo of copyright, of reading the expression in its original form. It is like a copyright on a physical tool (rather than its design specifications), which as far as I know doesn't exist.
I would be happy with a world in which copyright could only be claimed when source code is provided. Software companies could still impose their restrictive licenses, but at least we would get to learn from the code, borrow good ideas (assuming they're not patented...), find bugs, perform security audits, etc. I think this would make the industry healthier, if somewhat less profitable (because companies couldn't keep their ideas secret--a good thing for society).
This was a decent book, a precursor to the now more famous "Bringing Down the House", featuring the same brainy, persistent hacker types looking for an exploitable edge. It was a bit of a let down, in that the kids never really made the system pay off on a large scale, despite proving the concept. But the reasons for failing to make the big score are interesting: One, interpersonal issues, which take the story into California hippy culture. And two, the challenge, which slashdot readers will recognize, of pushing immature technology to its limits. These guys were putting a computer into the sole of a shoe and using digital radio communications in the 70s! The night at the table with modest successes interrupted by repeated electrocutions was precious.
Motley Fool Radio Show. (I like the Motley Fool, but those guys have terribly live personalities. Listening to their radio show is painful.)
Not to bang on these guys, but for an open, non-commercial, distributed identity system, with working code, see Identity Commons.
To reiterate what the anonymous parent said, this shouldn't break your email, and the reason is a fundamental advantage of DomainKeys over SPF and Sender-ID. The latter require you to send mail through a special host, breaking the end-to-end nature of SMTP, which says that all hosts are equal. DomainKeys just requires you to use a special private key, which can be on any machine or even carried around with you on a keychain. It may require a bit of configuration, but it is far more flexible and egalitarian.
Ok, I was being a little facetious, and I've never used a type debugger either. But I know that some people are pushing Haskell's type system pretty hard (eg, OOHaskell), and I think that some solution must be found for the notorious incomprehensible type errors before normal programmers can take advantage of things like this.
The promise of embedded domain-specific languages is that you can create these friendly sub-languages within a sufficiently powerful general-purpose language. The casual programmer can stay within the sub-language, but the "real" language is right there when you need it.
IMO, the best direction for natural programming is embedded domain-specific languages. The best direction for natural debugging is a harder problem. It's well known that many expert programmers still find "printf" debugging the best option, which suggests to me that tracing systems are promising. Of course, powerful type systems eliminate many possible run-time bugs, but then you need a type debugger....
Is there some fantasy supercomping league I don't know about?
Merkey came recently into the limelight due to more lkml posts, which were again clearly the product of his insanity. He's not an agent of SCO, Canopy, or Microsoft; he's just deranged. He didn't go to the press. If slashdot and (especially) groklaw hadn't picked up on the "story", this would have mercifully died away. His bizarre reversal should be ample evidence of that.
The best thing for him and for us would be to ignore his unfortunate condition. I can only find the current situation wasteful and tragic.
Although your initial point is good, your "Agile development to the rescue" follow-on falls flat. The components of IE do work together smoothly, beautifully in fact, according to the typical user experience. How secure a program is, and how well it works under normal testing, are almost totally unrelated. The way to secury systems is through careful, security-conscious design of both the components and their interactions, along with programming technologies and techniques that make it hard to screw up. Frequent integration might help security a bit by encouraging communication between component authors, but on the other hand the "make it work" attitude of "agile development" probably works against security.
I'm begging someone to take away this blow-hard's keyboard.
Why am I not surprised? Codeless Development Environments? Is it the 80s again? Good grief.
The article that goes with the poll.
Geesh, links to a press release and trade rag article, and not even the name of the project itself? Go read some real information about Rel, look at the examples, download the source, have fun.
You don't have to tell me about gjc et all not being there yet. I know it. I realize you would have had to do without a lot of useful features and put up with a lot of bugs. But if you made a committment to supporting gcj, I bet they would bend over backwards to help you.
Probably because the Java Open Source community has largely segregated itself from the rest of the free software/open source community by supporting only proprietary Java platforms.
I'm talking about cases where you cannot prove that the exception won't happen, so your technique (which I'm sure you are not recommending for those cases) would be reckless. It is actually rare that you can prove a checked exception won't happen, either because it is impossible in principle (eg FileNotFound), or because the specification doesn't guarantee the exact conditions in which it may be thrown.
In implementation, there should be some syntax to say, I know that this function I called throws a checked exception, but I want it to be unchecked for me. This could be part of the method declaration, or (even better) part of the expression that trips the exception.
This was already sort-of answered, but let me reiterate: No, it's not. IANAL, but to me, this looks like a very conservative statment that copyright code and case law, read narrowly, favor Blizzard. The judge essentially, and IMO conspicuously, declined to consider any new issues in this case. It sounded to me like he was expecting an appeal and just wanted his ruling to establish the laws and precedents, on which a higher court might build new interpretations.
The only question is whether "scratch your itch" results, in the long term, in a more reliable (observable, etc) system than "design for reliability (observability, etc)". This is sort of a reprise of the "worse is better" argument, and I think it is by no means resolved.
Cool! Do you understand the merger algorithms? I really hope you aren't going to do those in shell. ;-)
I agree that "darcs suffers from the math problem", at least in that the implementation has focused on getting the semantics right and not on performance. (And unfortunately, the semantics are still not all right.) David maintains a kernel tree in darcs as a reminder of all the ways it doesn't scale. However, he also thinks most of them are fixable "post 1.0", and given how smart and capable he's proven to be, I give that claim some respect. Alas, I haven't had time to learn the math well enough to really be sure.
Regarding the economics, I don't think SCM is an undervalued field. Or at least, the free software community can find a way to value any field it needs to to make progress. (And for SCM, you're helping!) People said we didn't value desktops, or help, or installers, or web browsers, or couldn't do webdav or other protocols "at the top of the stack". "No fun" is what people have said about all of these. (And we're still not great at all these, but I think we're on a clear path to get there.)
What does this mean for darcs? It already has good semantics, is easy to use, and has a solid theoretical foundation. I think that free software folks will increasingly value distributed SCM and it will get more development man-power (if not as much as bk). These are excellent growth factors, and I suspect darcs will be able to handle 90% of projects out there in a few years. Unless the foundation is found to be weak (which is why I asked about that). Unless David loses interest before someone else steps up. Unless, unless, unless, but I like its chances.
Put it this way: I agree that open source does not solve things that are too hard or no fun. But the second is actually a non issue: when we need something, powerful economic and selective forces will make it fun for someone. So I really care about the first, and I'm trying to gauge whether distributed SCM is too hard for David and others attracted to darcs. I suspect that it's not too hard, at least to get to the 90% mark.
Thanks for taking the time to reply. I do enjoy reading what you have to say.
I dearly hope this company will be called orthotics.
(Get it?)
Ok, I admit I just want to get darcs mentioned here, but I really want to know what Tom (as well as Larry McVoy) thinks about darcs. In particular, whether the theory will stand up to real use and scale to large projects. I have a hunch that David Roundy has discovered much of what Larry McVoy said was a dozen PhD theses worth of research behind BitKeeper.
Check out this page. He says the biggest factor is rolling resistance due to uneven terrain, even on the road. However, the gearing may be part of the answer: a smaller wheel requires a higher gear ration, and higher gear ratios are less efficient.