It is so bad that it took a decade just to get compilers that worked properly
The C++ Standard wasn't finalized until 1998. We're seven years out from the Standard, and we've had good compilers for more than a couple of years now. GCC 3.0 is where I draw the line for "good C++ compilers", but Intel and other firms had good C++ compilers for a similarly long time.
But C++ is an abomination--
Most C++ enthusiasts, myself included, will agree with you. In some ways, C++ is a lot like Perl. Larry Wall said about Perl, "The language is such a mess because the problem space is such a mess." The same applies to C++.
I can't imagine why it survives at all.
If you can't imagine why it survives at all, that strongly suggests you've never bothered to learn why it's survived.
no consistency of design
You've clearly never read the C++ standard, where one design goal guides all of the C++ specification: "you don't pay for what you don't use".
You've also clearly never done serious programming with the Standard Template Library, where the algorithms are written so generically--and so consistently across different data types--that they can be plugged together in an almost limitless number of configurations.
No: what I'm saying to you is it's only a cogent, coherent engineering process--of which documentation is a large part--which allows 30% of software projects to succeed.
The 70% failure rate is unacceptable, yes. That's not an excuse to ignore the processes which let us have a 30% success rate.
This is not an insult. I want to make that very clear, right up front. That said:
Go take a software engineering course. There's a lot of wisdom that's been accumulated about how to write reliable software, and while (IMO) about two-thirds of it is utter rubbish, one-third is really good advice. Learning software engineering is like eating pufferfish: really cool, but be careful what you swallow. You'll learn about requirements analysis, drafting a coherent requirements document, architectural analysis, drafting a coherent design document, interpersonal skills needed to get people to sign off on your ideas, time management, resource allocation... computer programming isn't the same as software engineering. Very little software engineering is concerned with computer programming--less than a quarter, in my experience.
It's a fun subject. It teaches you how to tackle big projects, and have a reasonable chance of success at them. 70% of all software projects fail, but the 30% which succeed include some of the most fun projects you'll ever see. Take a software engineering course. It's fun, and you'll be hunting much bigger game once you're through.:)
Now, that said... you ask reasonable questions, you get reasonable answers. Design documents aren't exercises in futility. In fact, they're essential. For any nontrivial software project, at least 75% of the codebase is trivial--and since it's trivial, that means there are a few thousand ways to do it. A design document lets the entire team know precisely how the trivial parts are going to get solved, so that the team can all be on the same page when it comes time to tackling the big stuff.
In a good design document, the hard parts are underspecified for exactly the reason you mention; you go through a lot of bad ideas on the way towards finding the Right Thing.
Design documents come in two varieties: the kind which is written by one person who has final authority, and the kind which is written by committee. If it's the former, the design document will have in big boldface letters at the header and footer of every page, SUBJECT TO CHANGE. If you've got one of these and your copy of the design document is more than 24 hours old, go check another one out of CVS. These design documents change very quickly as the development teams try different approaches. Unfortunately, the latter is more common--in which case just getting everyone to agree on the design document is a labor of Hercules, so usually the middle is left underspecified so that the programmers can do whatever the hell they need to do without needing to go back to the committee.
After the project's done, one day should be set aside to document "okay, now this is how it really works...". That document stays inside the engineering pit. When people need to learn how the package works, they read the requirements (to learn what it does), the design (to learn how the trivial parts work), and the How It Really Works (to learn how it really works).
Hope this sheds some light on the documentation issue.:)
One valid reason for MUST NOTs is to allow implementors to experiment. Many of the "implementation-defined" parts of the ANSI/ISO C++ spec, for instance, are left that way to encourage vendors to come up with new solutions to the problem. Then the next draft of the standard looks at the existing body of software and decides which is the best solution, and that gets turned into the new MUST.
Talk to the various stakeholders. Hold meetings. Get everyone's input on what's the Right Thing To Do.
To the degree these ideas are not the Wrong Thing, do them, even if they're less efficient than you'd like, or are less fun to code. You're going to be giving them a prostate exam with a cheese grater in a couple of steps, so soothe their egos proactively by letting their ideas make it into the final product.
Take the draft to your dev team. Circulate copies, have everyone read it, then have a short meeting--one hour, tops--not to discuss how to do things, but which parts of the design will require a lot of experimentation and fiddling.
If your dev team doesn't already have someone fluent in Corporate Weaselspeak, then get one.
Give your translator this sentence: "We will use our magic powers to accomplish this part of the design document." Have him turn it into a five-page monstrosity that lets every stakeholder think these difficult parts are going to be done their way, without really committing your dev team to anything.
Take the weaselized design doc back to the stakeholders. Your Corporate Weasel's job is to make the stakeholders sign off on it.
The easy and routine parts of the job get done the way the stakeholders want, assuming their way isn't completely braindamaged. The hard parts of the job will be solved by your development team's magic powers. It's right there in the design document.
Bring the project to completion. As you're doing the hard part, write This Is How It Really Works documentation for engineers who are coming after you.
When your project is ready for handoff, make sure to praise the (easy, routine) parts for which you used Marketing's ideas of how the software ought to be written.
Gloss over the fact that you did the hard part via magic powers. The other stakeholders probably don't care. You're giving them a beautiful bullet point for their end-of-year performance eval. That's what they care about at this point.
Move on to the next project.
... Is all this weasel office politics? Damn straight. On the other hand, it's weasel office politics meant to shield your development team from unnecessary weasel office politics. As much as we hate weasel office politics, sometimes it's necessary.
RFCs are requirements documents, not design documents.
An RFC specifies what behavior MUST, MUST NOT, SHOULD, SHOULD NOT, MAY, MAY NOT exist. It doesn't say jack about how that behavior is supposed to come into being. I could write an OpenPGP application that did all of its work by hiring Bruce Schneier to manually do the RSA computations, and it'd pass the RFC.
RFCs aren't design documents. RFCs specify behavior; design documents specify how that behavior is achieved.
... the "this is how it really works" document. That's what you're really interested in. There's nothing wrong with the design documents you've seen.
No, I'm not kidding.
The design documents which have driven you mad probably weren't incomplete. They were probably quite complete design documents. But a complete design document isn't supposed to cover everything. If you had a design document that was fully specified in every significant detail, you could run the design document through a compiler and generate your code. (This isn't as far-fetched as it sounds; there are tools to automatically generate large amounts of code just from simple UML diagrams. That's an example of design documents being translated directly into running code.)
A design document can best be viewed as the development team's prejudices regarding the best way to solve the problem. There will be holes in the design document, mostly in those areas where the programming team doesn't really have a good grasp on what the best thing to do is.
A good design document is a like a good steak; they're best when served a little bit rare. You want to give the guy who comes after you a game plan, but you don't want to commit yourself to doing things in one particular way when you don't know if that one particular way is going to work. After all, once the design document has had every stakeholder sign off on it, going back to the drawing board and saying "uh, this isn't going to work, let's try something else" means all the stakeholders get back on board again. But if the design document has some room to move--what you think are "holes"--then that gives the programmers freedom to get the job done without having to go through the entire design approval bureaucracy again.
Most serious software engineering shops worship at the altar of requirements and architecture documents. Hackers in the trenches add the "this is how it really works" document to that list. There's nothing quite as valuable as stumbling across some prior hacker's notes when you're trying to grok the system.
Stop looking at the design document for the 'missing' stuff. It might very well have been deliberately omitted. Start asking around for the "this is how it really works" documentation, instead.
They're using AES. That means it has (potentially) a 256-bit keyspace. You have neither the time, nor the energy, nor the computing power, to exhaust that keyspace. You can't even make a dent in that keyspace. A really monstrously huge distributed.net effort that runs for a decade might be able to create 2^80 bad keys. Okay, fine, great, that's a lot.
Now take 2^256 and subtract 2^80. What do you get?
Why, roughly 2^256. 2^80 is so insignificant in comparison to 2^256 that you're basically subtracting zero from the total keyspace.
People who do not understand just how large a keyspace is should not talk about how easy it is to exhaust a keyspace.
Yeah, I know. My objection isn't that "everything's a file" is a bad idea. My objection is that other, better ideas have come along, which UNIX by and large hasn't adopted. Plan9's evolution of the metaphor is just one example.
In what way is Unix stuck in the past? What defect, exactly speaking, threatens to kill it?
Here's my short list:
The UNIX security model is abysmal. The traditional UNIX model--user, group, world--is about as brain-damaged as you can get while still being able to legitimately call yourself an ACL. I'd much rather see a capability-based filesystem. (A cap filesystem can be thought of as at right angles to an ACL filesystem; rather than each file having a list of attributes saying who can do what, a cap filesystem attaches to each user a list of capabilities saying what they can do where and how. Caps generalize a lot better than ACLs.)
UNIX is written in an insecure language. Why is UNIX written in C? Why's the kernel written in a language in which it's gratuitously difficult to write code safely, and amazingly easy to write dangerous code? Other languages such as Ada95 give just as efficient code, but the language reduces the frequency of silly C errors and also allows for much easier formal verification (e.g., running the code through SPARK).
The 'everything's a file' idea has come and gone. (Obvious rejoinder: "Yeah! Nowadays, everything's a URL!") The everything's-a-file idea is a good one, but we've also had better ideas come along in the last 30 years. So why are we still using this idea? Plan 9 has several interesting ideas in this vein; why hasn't UNIX adopted them?
Your basis of criticism of 'modern cynicism' appears to be that it's reality-based
Not in the least. Again, you're reading what you want me to have written--not what I wrote. I'm a cynic in the manner of Diogenes, who was a big believer in realism. However, modern cynicism has gone far astray from Diogenes; it has become shallow and puerile.
Your post appears to be based on ninth-grade civics classes with an implicit plea "have patience, it's very hard to do this sort of thing right"
Again, you're reading what you want to have read, not what I wrote. I never said we should have patience. In fact, I think rather the opposite. I think we should keep a steady drumbeat in the ears of our legislators, that we want a streamlined system, and we're willing to vote them out of office if they don't provide it.
It is, however, very difficult to do this sort of thing right. Or do you dispute that?
What are you producing besides hot air?
More than that. I won't bore you, because on the Internet anyone can claim to be doing anything. There is one thing I'm producing, though, which I think you would be well-served to consider:
You're telling us... that laws are created by public servants whose only interest is the public good...
Please read what I wrote, not what you want me to have written. Nowhere did I claim laws are created by public servants whose only interest is the public good. Humanity, as a rule, is fallible. We screw up. Legislators as much as the next guy.
I only claimed that it was unnecessary to posit bad motives on the part of lawmakers, an assumption which requires us to assess things we cannot see (namely, their hearts and minds), when a perfectly sufficient explanation exists in the form of something we can see. That's Occam's Razor for you.
I'm a classical cynic. That means, among other things, I have little patience for modern cynicism, which is as ersatz as it is shallow. You're a modern cynic. If you wish to be that way, fine.
But those of us who have not sold our souls to a belief in humanity's worst are quietly working to achieve humanity's best. Why don't you join us?
Occam's razor is a more reliable guide than cynicism. Do you need to assume bad motives on the part of politicians to explain why we have such trouble getting government under control?
No, absolutely not. The problem domain is large enough to explain it by itself.
So why are we assuming bad motives on the part of politicians to explain why we have such trouble getting government under control?
Occam's Razor says we shouldn't.
There are a lot of things I for which I think we can surmise bad motives on the part of politicians--but the legal system of this country isn't one of them, I don't think. Not without running afoul of Occam, at least.
"The shoddy state of software today will last for as long as we have programmers. Because, after all, it's not in their interest for this state of affairs to end. If software becomes reliable, they're out of a job."
If someone were to come on Slashdot and say this, a few people would loudly agree with them and quickly get modded -1 Troll. A lot more people would accuse them of being arrogant, closedminded and just generally stupid. Of course many--most!--programmers want reliable software. The benefits to us of reliable software are myriad and manifold. No more calls at 2am on a Sunday because the server crashed. No more scouring BUGTRAQ looking for the next exploit we have to defend against. No more wondering whether the software flying the airplane we're riding on was written by lowest-bidders working in Bangalore.
The benefits to programmers from reliable software are so clear, so obvious, that we would laugh at anyone who seriously proposed that we deliberately kept software unreliable.
And yet, the instant you say lawyers are deliberately keeping the legal system difficult, people nod their heads understandingly and compliment you on your wisdom.
The benefits to a clean, efficient system of law are so huge and so obvious that, without exception, every single lawyer I know--and I know quite a lot of them--is an advocate for streamlining the legal system.
The problem is that society is huge. The machinery of government is truly gargantuan. These enormous edifices of government were put in place for a reason: because as obnoxious as they are, they're a lot better than what came before. (Take the Voting Rights Act as an example. It's a colossal piece of legislation and is a constant pain in the ass during election years. But it's a lot better than Jim Crow.)
So the problem Congress faces is, how do they pare government down and streamline it without returning us to the Bad Old Days we're trying so hard to avoid?
This is a tough, tough problem--all the moreso since the law is, almost by definition, a safety-critical system.
Imagine that you're given 100 million lines of source code. You're told, "Here. A lot of people are unhappy with it and they want major change right now. Oh, and while you're trying to strip out a few million lines and reduce bugcount, our coders are going to continue to write code to adjust to the ever-changing needs of our clients. Finally, remember that any bug you introduce has the potential to affect billions of people worldwide. Have a nice day!"
Please, try looking at the problem as a pragmatist and a realist, not with the simple and sophomoric eyes of a cheap cynic. The world is more complex, and a far richer place, than can ever be sufficiently explained with cheap cynicism.
What do you think the law is except a large series of references?
You want an argument, but you're not getting one. You haven't met the prima facie requirements for argument. If you want to argue that the word "fork" really means "apple", then yes, you can be dismissed with nothing more than a "look it up in Webster's, and if you don't like it, take it up with them".
Likewise, if you want to argue that the definitions in Black's are not authoritative, are not definitive, are inaccurate, then you're going to have to present strong evidence that Black's is either lacking in authority, in definitiveness, or accuracy. Until you're ready to do that, you're just a troll.
Incidentally, I'm not the one who has to make an argument. You want to overturn two centuries of American jurisprudence in how a word is used? Great: the burden of proof is on you to show that it's wrong, not on me to show it's correct.
No, no, not later. Not in a couple of days. Close your browser window right now and go talk to a lawyer before you wind up spending five-to-ten in Federal pound-me-in-the-ass prison.
What are you, mental?
Do you have any idea how few eavesdropping devices are planted each year? Do you have any idea how much legal rigamarole law-enforcement has to do to actually do a B&E and plant bugs? We already know law-enforcement cares enough about the situation to do God knows how much paperwork: do you think they'll just say "oh, good catch, you got us, don't worry, you can go free"?
And then, to make matters worse, you post on Slashdot where you acknowledge that you know the material is evidence in an ongoing investigation and ask for help in tampering with it?
Let me say this one more time: you are not 1337. You are not too cool for school. You are not immune to prosecution.
At some point they're going to want that information. They're going to discover that it's been removed from the car. At that point, they know they don't need to be subtle--someone already knows they were bugging. So they're going to haul in your friend and point out just how long five years in a Federal penitentiary is, and they're going to ask her--probably her, directly, since if she's anything like you she's dumb enough not to want a lawyer present--what she did with it. If she cooperates, they'll play nice. If she doesn't, well... hey. One more conviction in the old win-loss book is always a good thing.
And then they're going to come after you. And when they get to you, you're not going to have anyone you can rat out on. You're going to be left holding the Fuck-Me-Harder bag.
Get a lawyer right now. Not later. Not in an hour. RIGHT. NOW.
All the spin in the world won't erase the fact that they broke the law and were convicted.
Fact: Microsoft was never convicted of anything.
Fact: Microsoft could never be convicted of anything. No criminal charges were filed, after all.
Microsoft has been found by a court of law to be an abusive monopolist, that's true. They are not convicted monopolists.
Using the word "convicted" is, itself, a kind of spin. It makes Microsoft out to sound even more slimy and unpleasant than they are. If you want to be spin-free, then avoid using the word "convicted" in connection with the Microsoft antitrust lawsuit.
Feel free to substitute "stops the cheap licensing of your current software and gives you a choice between abandoning your software or upgrading" for "stops supporting", as you like.
It's exactly the sort of technique abusive monopolies in the software industry have been known to do.
What happens three years down the road when Management decides not to renew the Rational Rose license? What happens when IntelliJ stops supporting your version of IDEA and you have to upgrade with money you don't have? Etc.
Use only open tools. Open-source is best, of course, but anything that uses completely documented file formats and has tools for exporting to other formats is acceptable.
Don't let yourself get nailed with vendor lock-in. That's a bad, bad place to be. Better to use slightly inferior tools which are open than to lock yourself to a vendor.
That said, here are the tools I find myself using again and again:
C++
jEdit is a Java programmer's editor with excellent C++ support. I do development on Linux, Win32 and MacOS X, so it's very nice for me to have one editor I use on every platform. jEdit's not as featureful as, say, Emacs, but it's considerably more friendly to use.
Boost. If you're writing C++ and you're not using Boost, you're committing a crime against yourself.
Python. With Boost's Python library, it's easy to make your C++ applications scriptable. Write the heavy lifting parts in C++, then make those parts callable from Python. Do the rest of your development in a far safer, more sane language. You get almost all of the speed of C++, and far fewer headaches.
SWIG is another tool that's excellent for creating scriptable C++ applications.
Subversion for your version-control needs. Nothing else will do.
Doxygen for all your documentation needs. Learn it, love it. Your code's not done until every public part of the API has been doxygenated.
The GNU Autotools are really, really awful. They're also far better supported than Scons or pick-your-Autotools-replacement. Get ready to feel the pain of m4 macros. Sorry.:(
The GNU Compiler Collection started getting a good C++ compiler around version 3.0. I've been quite favorably impressed with 3.3, and I'm looking forward to 4.0. I don't recommend it for Windows, but for Solaris and x86 Linux it's beautiful.
I haven't found a good C++ unit testing framework yet. If you find one, please let me know.
Java
Eclipse is an excellent Java IDE. jEdit also fits the bill nicely, if all you want is an editor. I use both frequently, and am quite pleased with both.
jUnit for unit tests. Your code's incomplete unless you've written unit tests for it.
Javadoc for documentation. I would recommend Doxygen, but it's quite possible you'll be deploying your applications on machines that don't have it installed.
In the days of the Eastern Roman Empire, the laws were required to be publically posted before they were deemed enforceable. This didn't bother Emperor Justinian, though, who hired scribes to write the laws in the smallest font possible--and then had those laws posted high up on the walls, such that they couldn't be read from the ground.
You need to check with better cryptographers; a massive speedup does apply to symmetric ciphers, in the form of Grover's Algorithm. It reduces the keyspace you have to search by an exponential factor of 0.5, meaning breaking 128-bit symmetric crypto by brute force is within the realm of well-funded private citizens.
it stops being OO once you compile it since it is in machine code?
Clearly, yes. Machine code is not C++. Machine code is its own language, with its own grammar, syntax and rules. A many-to-many correspondence exists between C++ source and machine code representations. There are many ways to write C++ source which will compile down to the same machine code, and there are many different pieces of machine code which can be derived from the same piece of C++ depending on compiler optimizations and the like.
A correspondence exists, but once you make the translation you can no longer be said to be using idiosyncratic features of the original language. If I take English text and translate it into Japanese, I'm not going to have prepositional grammar anymore. Likewise, if I take C++ and compile it into machine code, I'm not going to have OO code anymore. (Or I might; it depends on whether I'm targeting silicon directly or an intermediate layer like the CLR.)
OO is not about design. OO is a feature of a language. It can be supported strongly and by design (Smalltalk) or weakly and by accident (C) or not at all (PROLOG).
It's not about design. If it was about design, I'd be able to design OO applications in PROLOG and backwards-chaining declarative logic applications in C.
Slashdot Mirror
You've also clearly never done serious programming with the Standard Template Library, where the algorithms are written so generically--and so consistently across different data types--that they can be plugged together in an almost limitless number of configurations.
No: what I'm saying to you is it's only a cogent, coherent engineering process--of which documentation is a large part--which allows 30% of software projects to succeed.
The 70% failure rate is unacceptable, yes. That's not an excuse to ignore the processes which let us have a 30% success rate.
This is not an insult. I want to make that very clear, right up front. That said:
:)
:)
Go take a software engineering course. There's a lot of wisdom that's been accumulated about how to write reliable software, and while (IMO) about two-thirds of it is utter rubbish, one-third is really good advice. Learning software engineering is like eating pufferfish: really cool, but be careful what you swallow. You'll learn about requirements analysis, drafting a coherent requirements document, architectural analysis, drafting a coherent design document, interpersonal skills needed to get people to sign off on your ideas, time management, resource allocation... computer programming isn't the same as software engineering. Very little software engineering is concerned with computer programming--less than a quarter, in my experience.
It's a fun subject. It teaches you how to tackle big projects, and have a reasonable chance of success at them. 70% of all software projects fail, but the 30% which succeed include some of the most fun projects you'll ever see. Take a software engineering course. It's fun, and you'll be hunting much bigger game once you're through.
Now, that said... you ask reasonable questions, you get reasonable answers. Design documents aren't exercises in futility. In fact, they're essential. For any nontrivial software project, at least 75% of the codebase is trivial--and since it's trivial, that means there are a few thousand ways to do it. A design document lets the entire team know precisely how the trivial parts are going to get solved, so that the team can all be on the same page when it comes time to tackling the big stuff.
In a good design document, the hard parts are underspecified for exactly the reason you mention; you go through a lot of bad ideas on the way towards finding the Right Thing.
Design documents come in two varieties: the kind which is written by one person who has final authority, and the kind which is written by committee. If it's the former, the design document will have in big boldface letters at the header and footer of every page, SUBJECT TO CHANGE. If you've got one of these and your copy of the design document is more than 24 hours old, go check another one out of CVS. These design documents change very quickly as the development teams try different approaches. Unfortunately, the latter is more common--in which case just getting everyone to agree on the design document is a labor of Hercules, so usually the middle is left underspecified so that the programmers can do whatever the hell they need to do without needing to go back to the committee.
After the project's done, one day should be set aside to document "okay, now this is how it really works...". That document stays inside the engineering pit. When people need to learn how the package works, they read the requirements (to learn what it does), the design (to learn how the trivial parts work), and the How It Really Works (to learn how it really works).
Hope this sheds some light on the documentation issue.
One valid reason for MUST NOTs is to allow implementors to experiment. Many of the "implementation-defined" parts of the ANSI/ISO C++ spec, for instance, are left that way to encourage vendors to come up with new solutions to the problem. Then the next draft of the standard looks at the existing body of software and decides which is the best solution, and that gets turned into the new MUST.
- Talk to the various stakeholders. Hold meetings. Get everyone's input on what's the Right Thing To Do.
- To the degree these ideas are not the Wrong Thing, do them, even if they're less efficient than you'd like, or are less fun to code. You're going to be giving them a prostate exam with a cheese grater in a couple of steps, so soothe their egos proactively by letting their ideas make it into the final product.
- Take the draft to your dev team. Circulate copies, have everyone read it, then have a short meeting--one hour, tops--not to discuss how to do things, but which parts of the design will require a lot of experimentation and fiddling.
- If your dev team doesn't already have someone fluent in Corporate Weaselspeak, then get one.
- Give your translator this sentence: "We will use our magic powers to accomplish this part of the design document." Have him turn it into a five-page monstrosity that lets every stakeholder think these difficult parts are going to be done their way, without really committing your dev team to anything.
- Take the weaselized design doc back to the stakeholders. Your Corporate Weasel's job is to make the stakeholders sign off on it.
- The easy and routine parts of the job get done the way the stakeholders want, assuming their way isn't completely braindamaged. The hard parts of the job will be solved by your development team's magic powers. It's right there in the design document.
- Bring the project to completion. As you're doing the hard part, write This Is How It Really Works documentation for engineers who are coming after you.
- When your project is ready for handoff, make sure to praise the (easy, routine) parts for which you used Marketing's ideas of how the software ought to be written.
- Gloss over the fact that you did the hard part via magic powers. The other stakeholders probably don't care. You're giving them a beautiful bullet point for their end-of-year performance eval. That's what they care about at this point.
- Move on to the next project.
... Is all this weasel office politics? Damn straight. On the other hand, it's weasel office politics meant to shield your development team from unnecessary weasel office politics. As much as we hate weasel office politics, sometimes it's necessary.RFCs are requirements documents, not design documents.
An RFC specifies what behavior MUST, MUST NOT, SHOULD, SHOULD NOT, MAY, MAY NOT exist. It doesn't say jack about how that behavior is supposed to come into being. I could write an OpenPGP application that did all of its work by hiring Bruce Schneier to manually do the RSA computations, and it'd pass the RFC.
RFCs aren't design documents. RFCs specify behavior; design documents specify how that behavior is achieved.
... the "this is how it really works" document. That's what you're really interested in. There's nothing wrong with the design documents you've seen.
No, I'm not kidding.
The design documents which have driven you mad probably weren't incomplete. They were probably quite complete design documents. But a complete design document isn't supposed to cover everything. If you had a design document that was fully specified in every significant detail, you could run the design document through a compiler and generate your code. (This isn't as far-fetched as it sounds; there are tools to automatically generate large amounts of code just from simple UML diagrams. That's an example of design documents being translated directly into running code.)
A design document can best be viewed as the development team's prejudices regarding the best way to solve the problem. There will be holes in the design document, mostly in those areas where the programming team doesn't really have a good grasp on what the best thing to do is.
A good design document is a like a good steak; they're best when served a little bit rare. You want to give the guy who comes after you a game plan, but you don't want to commit yourself to doing things in one particular way when you don't know if that one particular way is going to work. After all, once the design document has had every stakeholder sign off on it, going back to the drawing board and saying "uh, this isn't going to work, let's try something else" means all the stakeholders get back on board again. But if the design document has some room to move--what you think are "holes"--then that gives the programmers freedom to get the job done without having to go through the entire design approval bureaucracy again.
Most serious software engineering shops worship at the altar of requirements and architecture documents. Hackers in the trenches add the "this is how it really works" document to that list. There's nothing quite as valuable as stumbling across some prior hacker's notes when you're trying to grok the system.
Stop looking at the design document for the 'missing' stuff. It might very well have been deliberately omitted. Start asking around for the "this is how it really works" documentation, instead.
No, you can't DoS the keyspace.
They're using AES. That means it has (potentially) a 256-bit keyspace. You have neither the time, nor the energy, nor the computing power, to exhaust that keyspace. You can't even make a dent in that keyspace. A really monstrously huge distributed.net effort that runs for a decade might be able to create 2^80 bad keys. Okay, fine, great, that's a lot.
Now take 2^256 and subtract 2^80. What do you get?
Why, roughly 2^256. 2^80 is so insignificant in comparison to 2^256 that you're basically subtracting zero from the total keyspace.
People who do not understand just how large a keyspace is should not talk about how easy it is to exhaust a keyspace.
Yeah, I know. My objection isn't that "everything's a file" is a bad idea. My objection is that other, better ideas have come along, which UNIX by and large hasn't adopted. Plan9's evolution of the metaphor is just one example.
It is, however, very difficult to do this sort of thing right. Or do you dispute that?More than that. I won't bore you, because on the Internet anyone can claim to be doing anything. There is one thing I'm producing, though, which I think you would be well-served to consider:
Civility.
I only claimed that it was unnecessary to posit bad motives on the part of lawmakers, an assumption which requires us to assess things we cannot see (namely, their hearts and minds), when a perfectly sufficient explanation exists in the form of something we can see. That's Occam's Razor for you.
I'm a classical cynic. That means, among other things, I have little patience for modern cynicism, which is as ersatz as it is shallow. You're a modern cynic. If you wish to be that way, fine.
But those of us who have not sold our souls to a belief in humanity's worst are quietly working to achieve humanity's best. Why don't you join us?
Occam's razor is a more reliable guide than cynicism. Do you need to assume bad motives on the part of politicians to explain why we have such trouble getting government under control?
No, absolutely not. The problem domain is large enough to explain it by itself.
So why are we assuming bad motives on the part of politicians to explain why we have such trouble getting government under control?
Occam's Razor says we shouldn't.
There are a lot of things I for which I think we can surmise bad motives on the part of politicians--but the legal system of this country isn't one of them, I don't think. Not without running afoul of Occam, at least.
Let's put this in terms we can understand:
"The shoddy state of software today will last for as long as we have programmers. Because, after all, it's not in their interest for this state of affairs to end. If software becomes reliable, they're out of a job."
If someone were to come on Slashdot and say this, a few people would loudly agree with them and quickly get modded -1 Troll. A lot more people would accuse them of being arrogant, closedminded and just generally stupid. Of course many--most!--programmers want reliable software. The benefits to us of reliable software are myriad and manifold. No more calls at 2am on a Sunday because the server crashed. No more scouring BUGTRAQ looking for the next exploit we have to defend against. No more wondering whether the software flying the airplane we're riding on was written by lowest-bidders working in Bangalore.
The benefits to programmers from reliable software are so clear, so obvious, that we would laugh at anyone who seriously proposed that we deliberately kept software unreliable.
And yet, the instant you say lawyers are deliberately keeping the legal system difficult, people nod their heads understandingly and compliment you on your wisdom.
The benefits to a clean, efficient system of law are so huge and so obvious that, without exception, every single lawyer I know--and I know quite a lot of them--is an advocate for streamlining the legal system.
The problem is that society is huge. The machinery of government is truly gargantuan. These enormous edifices of government were put in place for a reason: because as obnoxious as they are, they're a lot better than what came before. (Take the Voting Rights Act as an example. It's a colossal piece of legislation and is a constant pain in the ass during election years. But it's a lot better than Jim Crow.)
So the problem Congress faces is, how do they pare government down and streamline it without returning us to the Bad Old Days we're trying so hard to avoid?
This is a tough, tough problem--all the moreso since the law is, almost by definition, a safety-critical system.
Imagine that you're given 100 million lines of source code. You're told, "Here. A lot of people are unhappy with it and they want major change right now. Oh, and while you're trying to strip out a few million lines and reduce bugcount, our coders are going to continue to write code to adjust to the ever-changing needs of our clients. Finally, remember that any bug you introduce has the potential to affect billions of people worldwide. Have a nice day!"
Please, try looking at the problem as a pragmatist and a realist, not with the simple and sophomoric eyes of a cheap cynic. The world is more complex, and a far richer place, than can ever be sufficiently explained with cheap cynicism.
What do you think the law is except a large series of references?
You want an argument, but you're not getting one. You haven't met the prima facie requirements for argument. If you want to argue that the word "fork" really means "apple", then yes, you can be dismissed with nothing more than a "look it up in Webster's, and if you don't like it, take it up with them".
Likewise, if you want to argue that the definitions in Black's are not authoritative, are not definitive, are inaccurate, then you're going to have to present strong evidence that Black's is either lacking in authority, in definitiveness, or accuracy. Until you're ready to do that, you're just a troll.
Incidentally, I'm not the one who has to make an argument. You want to overturn two centuries of American jurisprudence in how a word is used? Great: the burden of proof is on you to show that it's wrong, not on me to show it's correct.
Look it up in Black's, please; then tell me whether the term 'convicted' is appropriate in a civil context.
Correct, the definition of convicted is "proven guilty of a crime".
But look at the complaint against Microsoft. It wasn't a criminal complaint. It was a civil pleading.
Get a lawyer.
No, no, not later. Not in a couple of days. Close your browser window right now and go talk to a lawyer before you wind up spending five-to-ten in Federal pound-me-in-the-ass prison.
What are you, mental?
Do you have any idea how few eavesdropping devices are planted each year? Do you have any idea how much legal rigamarole law-enforcement has to do to actually do a B&E and plant bugs? We already know law-enforcement cares enough about the situation to do God knows how much paperwork: do you think they'll just say "oh, good catch, you got us, don't worry, you can go free"?
And then, to make matters worse, you post on Slashdot where you acknowledge that you know the material is evidence in an ongoing investigation and ask for help in tampering with it?
Let me say this one more time: you are not 1337. You are not too cool for school. You are not immune to prosecution.
At some point they're going to want that information. They're going to discover that it's been removed from the car. At that point, they know they don't need to be subtle--someone already knows they were bugging. So they're going to haul in your friend and point out just how long five years in a Federal penitentiary is, and they're going to ask her--probably her, directly, since if she's anything like you she's dumb enough not to want a lawyer present--what she did with it. If she cooperates, they'll play nice. If she doesn't, well... hey. One more conviction in the old win-loss book is always a good thing.
And then they're going to come after you. And when they get to you, you're not going to have anyone you can rat out on. You're going to be left holding the Fuck-Me-Harder bag.
Get a lawyer right now. Not later. Not in an hour. RIGHT. NOW.
And grow up, while you're at it.
Fact: Microsoft could never be convicted of anything. No criminal charges were filed, after all.
Microsoft has been found by a court of law to be an abusive monopolist, that's true. They are not convicted monopolists.
Using the word "convicted" is, itself, a kind of spin. It makes Microsoft out to sound even more slimy and unpleasant than they are. If you want to be spin-free, then avoid using the word "convicted" in connection with the Microsoft antitrust lawsuit.
Feel free to substitute "stops the cheap licensing of your current software and gives you a choice between abandoning your software or upgrading" for "stops supporting", as you like.
It's exactly the sort of technique abusive monopolies in the software industry have been known to do.
What happens three years down the road when Management decides not to renew the Rational Rose license? What happens when IntelliJ stops supporting your version of IDEA and you have to upgrade with money you don't have? Etc.
Use only open tools. Open-source is best, of course, but anything that uses completely documented file formats and has tools for exporting to other formats is acceptable.
Don't let yourself get nailed with vendor lock-in. That's a bad, bad place to be. Better to use slightly inferior tools which are open than to lock yourself to a vendor.
That said, here are the tools I find myself using again and again:
- C++
- jEdit is a Java programmer's editor with excellent C++ support. I do development on Linux, Win32 and MacOS X, so it's very nice for me to have one editor I use on every platform. jEdit's not as featureful as, say, Emacs, but it's considerably more friendly to use.
- Boost. If you're writing C++ and you're not using Boost, you're committing a crime against yourself.
- Python. With Boost's Python library, it's easy to make your C++ applications scriptable. Write the heavy lifting parts in C++, then make those parts callable from Python. Do the rest of your development in a far safer, more sane language. You get almost all of the speed of C++, and far fewer headaches.
- SWIG is another tool that's excellent for creating scriptable C++ applications.
- Subversion for your version-control needs. Nothing else will do.
- Doxygen for all your documentation needs. Learn it, love it. Your code's not done until every public part of the API has been doxygenated.
- The GNU Autotools are really, really awful. They're also far better supported than Scons or pick-your-Autotools-replacement. Get ready to feel the pain of m4 macros. Sorry.
:( - The GNU Compiler Collection started getting a good C++ compiler around version 3.0. I've been quite favorably impressed with 3.3, and I'm looking forward to 4.0. I don't recommend it for Windows, but for Solaris and x86 Linux it's beautiful.
- I haven't found a good C++ unit testing framework yet. If you find one, please let me know.
- Java
- Eclipse is an excellent Java IDE. jEdit also fits the bill nicely, if all you want is an editor. I use both frequently, and am quite pleased with both.
- Subversion again for your version-control needs.
- jUnit for unit tests. Your code's incomplete unless you've written unit tests for it.
- Javadoc for documentation. I would recommend Doxygen, but it's quite possible you'll be deploying your applications on machines that don't have it installed.
- Ant for all your build needs.
Hope all this helps.In the days of the Eastern Roman Empire, the laws were required to be publically posted before they were deemed enforceable. This didn't bother Emperor Justinian, though, who hired scribes to write the laws in the smallest font possible--and then had those laws posted high up on the walls, such that they couldn't be read from the ground.
You need to check with better cryptographers; a massive speedup does apply to symmetric ciphers, in the form of Grover's Algorithm. It reduces the keyspace you have to search by an exponential factor of 0.5, meaning breaking 128-bit symmetric crypto by brute force is within the realm of well-funded private citizens.
A correspondence exists, but once you make the translation you can no longer be said to be using idiosyncratic features of the original language. If I take English text and translate it into Japanese, I'm not going to have prepositional grammar anymore. Likewise, if I take C++ and compile it into machine code, I'm not going to have OO code anymore. (Or I might; it depends on whether I'm targeting silicon directly or an intermediate layer like the CLR.)
OO is not about design. OO is a feature of a language. It can be supported strongly and by design (Smalltalk) or weakly and by accident (C) or not at all (PROLOG).
It's not about design. If it was about design, I'd be able to design OO applications in PROLOG and backwards-chaining declarative logic applications in C.
Have you ever seen an OO design in PROLOG?
It usually starts with this: "First, implement LISP..."
Have you ever seen backwards-chaining declarative logic designs in Scheme?
It usually starts with "First, implement PROLOG..."
I wish I was kidding.