I'm a "cyber-savvy guy" (software developer, good enough?) and I HATE the fact that I have to accept the design trade-offs of tons of features I don't use. How much smaller would the phone be without a camera, an mp3 player, a web browser, and a bunch of girly jingles and animations to play for every function? How much more battery life would I get if it didn't have a huge, colorful, animated display? The Razr is a huge step in the right direction, except that I have Verizon, and a special LARGER version of the Razr was created for Verizon users, which are evidently all 13-year-old girls.
I'M NOT A 13-YEAR-OLD GIRL! (Though it's an easy mistake to make when I get upset and start screaming.) Motorola created a huge storm of enthusiasm by releasing an unprecedentedly slim phone, and the first thing they did to it was make it fatter. The fact that they did this especially for Verizon sealed my decision to quit Verizon and switch to a company that caters to adults.
Please, produce just a few phones built for people who care about size, battery life, and reception. Don't worry that people won't pay $300 dollars for a phone without features. They will. When I bought my current phone, I looked through the specs of many dozens of phones and ended up paying a couple hundred bucks for a phone I didn't even like, because there were NO phones I liked. People live with their phones their whole waking lives. They'll spend $300 or $500 for a phone that serves them well, even if it doesn't have the latest features.
Give us choices, an array of phones with different features and different design trade-offs, not dozens of phones with the same features and the same design trade-offs.
But the examples are both interoperability problems, and not actual bugs. Looks like an excuse to marginalize the non-windows crowd.
They classify their interoperability problems as defects. I think it's pretty generous for a Windows shop to call a successful Windows product defective because it only works with Windows.
Also blame users! "People who refuse to use SQL Server can't use Vault."
That isn't blaming. It's a description of the defect. By classifying it as a defect, they acknowledge it as a Bad Thing.
Defects in a product are inevitable. However, KNOWN defects are a different thing altogether.
You assume that:
1) You can fix defects as fast as you can find them. This is just a matter of time allocation. If there are ten bugs in the system, I'd rather know about eight and fix one than know about four and fix all four. Our customers prefer it that way, too.
2) You can fix the defects you find. If you're integrating with customer systems, you'll encounter buggy or incomplete documentation and limited access to the specialists who supplement the documentation. Sometimes guys go on vacation at inconvenient times.
3) Every defect you find is important enough to hold up a release. This isn't true for our customers. If the bug has a simple workaround or only manifests itself as a result of user error, they may not want to wait for a fix. Sometimes they need the new features and performance enhancements so badly that they'd lynch us for delaying a week to fix such a bug.
4) The defect isn't the result of a customer changing a requirement that was designed into the system. This is a matter of semantics; you may call them "enhancement requests," but we call them "defects" because it reminds us how the customers see the product. If a customer project is threatened because they can't use our product the way they planned, it doesn't matter to us whose fault it is. We might get blamed for it anyway.
I'm just begging to get modded off-topic here, but so was the parent. Please be merciful.
C++ is not a perfect language, but the examples that you pick on suggest that your distaste for it does not come from experience. chdir has nothing specifically to do with C++, and const is an excellent language feature that has nothing to do with the problems of C++. Even given Java's very conservative approach to language features, I think it would be a worthwhile addition, if it can be implemented.
A design pattern is a repeated pattern of code that must be implemented over and over again because the language isn't expressive enough to factor out the repetition. Java has a ton of design patterns because it's an extremely simple language. So, to point out that a new language feature is redundant with a design pattern is merely to say, "Why add a language feature when I can get the same result with a lot of coding?" The answer: That's what language features are for.
That isn't to say that every language should have as many features as possible. The designers of Java decided to favor simplicity and repetition over expressiveness and conciseness in order to allow inexperienced programmers to work safely and effectively with the language. Java has been extremely conservative in admitting new features, and it has worked out well for them.
However, const is a big win with little downside. Consider passing an object to a library method. If the library interface guarantees (using const) that your object will not be altered, you can freely pass your object. Without const, you have to either make the object immutable, meaning you can no longer modify it yourself, or pass the library a newly created copy, or pass the library an immutable wrapper for your object. The first option restricts your own use of the object, the second option is a performance hit, and the third option requires extra code to implement immutability. The most persuasive evidence of the cost of working around const is that it usually isn't done. The most common solution in practice is for the library's documentation to promise not to modify the object, and for library users to trust the documentation.
There are two problems with const, and they both involve discipline, something that the Java community has embraced wholeheartedly. First, using const can force you to do things The Right Way when you really want a quick fix. I don't think the Java community has any problem with that. Second, using const in a tightly integrated module is an all-or-nothing thing. If you start out ignoring const and decide later to stop being so lazy, you have to work through your entire module adding const in a consistent way. However, if you decide to keep being lazy, your module will just be Java as it is today -- no harm done.
I think the bottom line with const as a language feature is that it isn't very dangerous compared to the great benefit provided. It increases efficiency, helps flag coding errors, and serves as documentation. (Documentation that is checked and enforced by the language is by far the best kind of documentation.) Unfortunately, I have no idea if const can be securely implemented in Java. Perhaps that's the catch.
Boost.Python is well designed, well documented, and has an active mailing list. Getting started can be a real pain, but it's a one-time cost. (If you have any trouble getting it to build or building your first project, you'll find it extremely helpful to read through a basic introduction to Jam, the build tool used to build Boost.Python extensions.) After a very difficult start-up, it's been all roses for me.
Also +1 to scripting language integration in general. I love being able to bring up a command line, load up a C++ module, create instances of my objects, and play with them. It's an enormous help in prototyping, debugging, and getting a new developer started.
That's a great idea. If the attractions of Java are unit testing, error handling, and memory management, maybe it would be just as good to hire a C++ coach who can introduce unit testing, Boost smart pointers (or garbage collection, even), and exceptions and be a good-natured coding standards Nazi to make sure your guys use those wherever they're appropriate. Of course, this doesn't do any good if you're already writing excellent C++.
I think a better question is, are the C++ coders writing the kind of C++ code that was typical ten years ago?
If so, they haven't adapted to new C++ practices, and there's no way they'll adapt to Java. They'll write terrible Java and be miserable.
If not, then they'll adapt to Java pretty quickly. Some of their C++ techniques won't be possible in Java, but they'll figure out the strengths of Java in a few months and start writing good Java code.
Oddly enough, the more modern C++ elements you see in your codebase that don't have direct analogs in Java, such as template metaprogramming and RAII, the more optimistic you should be. Those items show that your programmers have learned and adapted to new paradigms and can be expected to adapt well to Java.
Excellent point. Some people consider smilies informal and unprofessional, but nobody can argue that they're easy and efficient. I write emails much faster when I can use emoticons than when I must rely only on prose.
Using emoticons also promotes relaxed and open conversation among brainy types because it is an acknowledgment that writing without them is a difficult and laborious task. An admission of weakness tends to head off conflict because it signals that one isn't interested in chest-thumping or assigning credit and blame.
On a side note, ambiguity is an excellent way to get inside people's heads and force them to think carefully about what you say. When people can't tell what side you're on or whether you're being sarcastic, they're forced to analyze what you actually said. It may be the only thing they honestly think about all day.
Sorry, when I see the term "free market," I don't automatically research what it means to the person using it. Rest assured that if all self-identified believers in the free market were put on a planet together and asked to implement it, there would be a bloodbath.
I can't imagine why you chose to link the paper you did. It systematically explains why every imaginable effective way of limiting pollution is illegitimate under a libertarian system. The solutions proposed require so much time, money, and attention by so many individual litigants that they would simply never happen, and the paper endorses principles that severely limit legal simplifications such as joining defendants and plaintiffs. Because of this, the system described by the paper is a utopia for polluters in which the unlikelihood of effective litigation grants economic legitimacy to pollution. The main promise is not clean air but the freedom to pollute, and if you don't see it that way, then I believe you're misreading the intent of the paper. (That the authors identify pollution as a Bad Thing -- aggression and injury, in their terminology -- means nothing. It is merely de rigueur.)
Yes, they do, and more efficiently than regulated ones. If regulation solved problems, there would be no pollution, no corruption, no scandals.
Markets only operate efficiently with regards to costs that are visible in the market. Many incredibly harmful things may or may not show up as costs in an unregulated market, depending on the circumstances. Theft, fraud, murder, dumping toxic waste, and slavery can all be profitable in a completely unregulated market. Private property itself is a regulation that is enforced in society by government intervention.
No pollution? Pollution doesn't cost anything in a "free" market, so a free market is completely blind to it. Regulation intervenes in the market to attach costs to pollution so the market can efficiently manage it.
Do you think there's an efficient way to force companies to practice honest accounting, or do we have to choose between these costs and commonplace large-scale fraud? (Please don't flame; it's an honest question.)
You know the annoying kid you knew in college who would repeatedly interrupt every discussion demanding definitions of all the words being used, and who would argue endlessly about flaws in the definitions so that you couldn't really talk about the topic you wanted to? Imagine you're writing a book, and that guy has to personally approve every sentence.
I noticed as a high schooler interested in math that many of the resources for talented math students were Russian in origin. The Russian system systematically encouraged and assisted math students at every level, even the talented ones. They also did a great job of connecting difficult mathematics and physics to very down-to-earth things such as industry, business, and even carpentry. If Yuri the plumber needs to install a drain, you just know he will require basic physics and a really neat mathematical proof.
Education in the US is all about problems. Not math problems, but problem students. If you aren't part of a social pathology then there's little thanks given to teachers for spending time on you.
I know two very smart and busy people who gave up caffeine. They both say that before they gave up caffeine, they were acutely aware (and appreciative) of the intense caffeine-based alertness, but they never realized that they spent most of the day in a fog, getting little done. Without caffeine, they don't reach the highs they used to, but they get more done because they can actually work for six hours out of their eight-hour work day instead of just three or four.
Based on their experience, I'm considering it, but I love the taste of coffee... and, yes, that transitory caffeine high in which I work like a maniac for an hour or so before I vague out and start surfing the web.
It's funny that you mention an 800 MHz PIII. That's what I do my professional software development on. It's the slowest machine in the house, but it's plenty fast, and I wouldn't gain much out of migrating my work environment to the Athlon 64 X2 box I use for web surfing. So your statement is true for my household -- speed is a complete non-issue.
Writing, review, and rewriting helped me most as a writer. I had an excellent teacher in junior high school who made us write constantly, gave us a face-to-face critique of an essay at least once a week, and forced us to go through several revisions on many of our papers. The students critiqued each others' papers as well, which wasn't as helpful as the teacher's critiques but at least taught us that bad writing is unpleasant and unedifying to read. (It also convinced the skeptics that the teacher wasn't exaggerating how many passages were unclear or incoherent.)
The most common failing I see in myself and my colleagues is leaving out important bits of context. I think the best cure for this is reading and critiquing other students' writing.
The most important thing is to force them to write as often as possible. Have them write one-off essays in class, and have them go through three or more rounds of peer review on several papers. At least one paper should go through three rounds of review personally with you. That way they'll get decent advice from at least one person. Frankly, I think everything else should be subordinated. Whatever amount of theorizing and speechifying you manage to fit in between writing and review will be plenty.
First, the compiler may reorder things.... The compiler may choose.... Compilers take care.... Even if the compiler doesn't reorder like that, though, the processor might.... the memory management unit *also* reorders writes.... I think it's the concept that's hard.
None of these things are given; there's no such thing as "the concept." The designer of the language decides what guarantees to give the programmer and what latitude to give to the compiler, as well as what structures are provided to manage concurrency. Essentially, the language designer decides what concepts the users of the language must understand and employ. C and C++ expose the programmer to the full complexity of machine behavior because efficiency has always been their overriding concern, and in any case, those decisions were made at a time when threading was a niche concern. Newer languages typically strike a different balance between efficiency and support for concurrency.
In short, C++ (combined with a decent underlying O/S and development environment) is just as much a "technology designed for multithreaded programming". There's nothing about support for multithreading which is particularly compelling about Java vs. C++ (that I'm aware of).
I would +1 the rest of your comment but must take exception here. The Java language standard makes useful sequencing and atomicity guarantees that make it clear exactly when a mutex is needed. C++ does not. A dumbed-down version (because I don't know the precise version, nor know any C++ programmers who do) of what C++ guarantees is that externally observable operations occur in object code in the same order that they occur in the source code. So if the source code says
write A to file F;
write B to file F;
then A will indeed be written to the file before B. However, writes to memory are not deemed to be externally observable. If your code says
a = fooA;
b = fooB;
then other threads may see the value of b change before the value of a changes. So the sequence of operations can only be ensured by using explicit synchronization.
Likewise, atomicity of operations is not guaranteed by the C++ standard. The atomicity of an operation in C++ can only be depended on if you know the compiler will compile the operation to a machine word that you know will execute atomically on the target platform(s).
Because of this lack of guarantees, some synchronization techniques that rely on sequencing or atomicity must be accomplished using mutexes or platform-specific directives. You must explicitly protect pretty much all shared data in C++, and for portability, that means mutexes. In Java, you can safely perform unsynchronized reads and writes to an int member variable without worrying that on some platform, somewhere, a thread might read garbage from that variable because of concurrency. (This statement dates to 2001; now I hear strange terms like "64-bit Java," so this might no longer be true.) Java really acts like a single very well documented platform in that respect. In C++, you might have some degree of confidence that an assignment to an int will be atomic on your target platform, but you probably wouldn't depend on it unless you had a lot of confidence in your knowledge of the compiler, the platform, and the fact that your program would NEVER need to be ported by anyone less expert than you.
Also, most people assume that C++ makes stronger guarantees than it really does, so they write crappy code. Java has always been designed for average programmers, and C++ was designed for experts, but in the case of concurrency, C++ really overshot the mark. C++ dates from a time when only gurus did concurrency, and it shows, especially in the lack of documentation and the failure of most popular C++ programming books to include BIG FLASHING WARNINGS about all the surprising gotchas like reordering of writes to memory, or indeed the failure of most C++ learning resources to address concurrency in any way.
C and C++ are slowly losing their status as common first languages. Programmers raised on modern languages chafe at the lack of consideration for concurrency in the C++ language. This will hurt C++ (and the Lisps), as there are many people who categorize all such languages as being essentially from another time period and not worth learning. Right now, people have to abandon that attitude when they leave school, but what if they didn't have to?
Signed, a proud and happy C++ programmer. I'll repeat, +1 to most of your post, but -1 to the idea that C++'s concurrency support is on par with Java.
Nope. The first computer I built was an old and popular SFF barebones unit from the largest SFF manufacturer, with a Celeron processor. Fedora installed fine right out of the box. I managed to get Windows running on it but had to switch back to Linux several times to figure things out, despite having Windows drivers from the manufacturer. The second computer I built used mainstream everything -- a motherboard from a major manufacturer, an Athlon processor, and a popular mid-range Nvidia graphics card. Once again, Fedora ran fine straight out of the box, but Windows required downloading drivers from manufacturers' web sites and burning them onto CDs. In both cases Windows was unusable on its first install and gave no clue as to how to continue, which is exactly what people used to complain about with Linux.
At least with Linux you can go to Fry's and grab a box off the shelf that probably contains everything you'll need to get up and running in a decent way. Try that with Windows. Windows only works that way if you buy a complete system with Windows installed, in which case you get a set of CDs containing Windows drivers and utilities for your system -- essentially a custom OS distribution for your hardware configuration. Old, super high volume hardware often works right out of the box with Windows, so if you have an old Dell, you're probably in luck. Otherwise, you can look forward to a driver hunt. (So many hardware manufacturers' web sites suck....)
Some companies, such as HP, provide CDs of drivers and extras with their Linux workstations, and they'll even install it for you. Sure, installing an OEM's custom Windows distribution on the OEM's hardware is often easier than installing an off-the-shelf Linux distribution on random hardware. But if you compare apples to apples -- off-the-shelf Windows vs. Linux on random hardware, or Windows vs. Linux from an OEM -- Linux wins. (This is probably due to years of hard work from people trying to win the unfair comparison, so maybe we should let the unfair comparison stick.)
A full feature set and a simple interface can be combined, thanks to the ability of users to ignore what they don't need to understand. The trick in software is to provide advanced controls but make them optional -- preferably in a granular way, so that a browser user can be an advanced user of the tab options interface without needing to understand cookies or the security controls. Actually, a web browser is a great example. Practically anyone can use Firefox, even though an advanced user can:
Disable SSL 2.0 (leaving 3.0 enabled) with four clicks Disable Javascript with five clicks Disable a subset of Javascript functionality with fewer than a dozen clicks Create an original parameterized keyword bookmark by typing in a url format string
And so on.
A surprising number of programs screw this up in one way or another, by shoving tons of options in front of a user with an incoherent set of defaults (if they don't learn all the options they'll never appreciate how leet I am!!!111!!1!) or not including basic controls (I have to hide this from the stupid grandmas or they'll stroke out and die lol!)
Too many ease-of-use oriented designers never figure out how easy it is to hide advanced controls from newbies or basics-only users. As long as non-optional controls are conspicuous and easily understood, optional controls can be hidden in relatively plain sight. Non-advanced users are not on a divine mission to find the advanced controls -- you don't have to make it an ordeal to access them! Usually it's safe to put them exactly where the advanced users expect to find them.
A debugger won't help you if you're trying to ensure correctness at too low a level of abstraction. Most languages give you a couple of low-level building blocks equivalent to the pthreads basics: threads, mutexes, and condition variables. These should not be used directly except in the simplest of circumstances. Rather, they should be used to create a set of higher-level tools that can be applied in a simple and straightforward way to your task.
The most popular way is to create a workflow model with task queues, worker threads, and job dependencies, plus a few application-specific rules to ensure that resource limitations don't cause deadlock.
The high-level model can typically be lifted right out of your proof of deadlock avoidance. Don't have one of those? It's a good idea. The proof gives you a minimal solution and confidence to implement it. Without the proof, you're going to overkill the problem out of nervousness, and you still might miss something crucial.
Fixing Firefox's memory problems might be an unglorious task, but many commercial projects are plagued with the same problems. An ambitious developer could turn Firefox's problems into the beginning of a lucrative career as a performance analyst and bug hunter, if he managed to make a significant difference and get credit for his work.
stating what someone might want (for whatever reasons) as if it has already happened
That's called "vision." I hate it when someone invests a bunch of time and resources in something without being sure of its moral superiority and inevitable triumph and then expects more credit than the noble and enlightened people who really believed. I mean, jeez, without my ostentatious certainty, your efforts would have been totally wasted. Wake up and smell the self-actualization.
Slashdot Mirror
I'M NOT A 13-YEAR-OLD GIRL! (Though it's an easy mistake to make when I get upset and start screaming.) Motorola created a huge storm of enthusiasm by releasing an unprecedentedly slim phone, and the first thing they did to it was make it fatter. The fact that they did this especially for Verizon sealed my decision to quit Verizon and switch to a company that caters to adults.
Please, produce just a few phones built for people who care about size, battery life, and reception. Don't worry that people won't pay $300 dollars for a phone without features. They will. When I bought my current phone, I looked through the specs of many dozens of phones and ended up paying a couple hundred bucks for a phone I didn't even like, because there were NO phones I liked. People live with their phones their whole waking lives. They'll spend $300 or $500 for a phone that serves them well, even if it doesn't have the latest features.
Give us choices, an array of phones with different features and different design trade-offs, not dozens of phones with the same features and the same design trade-offs.
They classify their interoperability problems as defects. I think it's pretty generous for a Windows shop to call a successful Windows product defective because it only works with Windows.
Also blame users! "People who refuse to use SQL Server can't use Vault."
That isn't blaming. It's a description of the defect. By classifying it as a defect, they acknowledge it as a Bad Thing.
You're right about SQL, though.
You assume that:
1) You can fix defects as fast as you can find them. This is just a matter of time allocation. If there are ten bugs in the system, I'd rather know about eight and fix one than know about four and fix all four. Our customers prefer it that way, too.
2) You can fix the defects you find. If you're integrating with customer systems, you'll encounter buggy or incomplete documentation and limited access to the specialists who supplement the documentation. Sometimes guys go on vacation at inconvenient times.
3) Every defect you find is important enough to hold up a release. This isn't true for our customers. If the bug has a simple workaround or only manifests itself as a result of user error, they may not want to wait for a fix. Sometimes they need the new features and performance enhancements so badly that they'd lynch us for delaying a week to fix such a bug.
4) The defect isn't the result of a customer changing a requirement that was designed into the system. This is a matter of semantics; you may call them "enhancement requests," but we call them "defects" because it reminds us how the customers see the product. If a customer project is threatened because they can't use our product the way they planned, it doesn't matter to us whose fault it is. We might get blamed for it anyway.
I'm just begging to get modded off-topic here, but so was the parent. Please be merciful.
C++ is not a perfect language, but the examples that you pick on suggest that your distaste for it does not come from experience. chdir has nothing specifically to do with C++, and const is an excellent language feature that has nothing to do with the problems of C++. Even given Java's very conservative approach to language features, I think it would be a worthwhile addition, if it can be implemented.
A design pattern is a repeated pattern of code that must be implemented over and over again because the language isn't expressive enough to factor out the repetition. Java has a ton of design patterns because it's an extremely simple language. So, to point out that a new language feature is redundant with a design pattern is merely to say, "Why add a language feature when I can get the same result with a lot of coding?" The answer: That's what language features are for.
That isn't to say that every language should have as many features as possible. The designers of Java decided to favor simplicity and repetition over expressiveness and conciseness in order to allow inexperienced programmers to work safely and effectively with the language. Java has been extremely conservative in admitting new features, and it has worked out well for them.
However, const is a big win with little downside. Consider passing an object to a library method. If the library interface guarantees (using const) that your object will not be altered, you can freely pass your object. Without const, you have to either make the object immutable, meaning you can no longer modify it yourself, or pass the library a newly created copy, or pass the library an immutable wrapper for your object. The first option restricts your own use of the object, the second option is a performance hit, and the third option requires extra code to implement immutability. The most persuasive evidence of the cost of working around const is that it usually isn't done. The most common solution in practice is for the library's documentation to promise not to modify the object, and for library users to trust the documentation.
There are two problems with const, and they both involve discipline, something that the Java community has embraced wholeheartedly. First, using const can force you to do things The Right Way when you really want a quick fix. I don't think the Java community has any problem with that. Second, using const in a tightly integrated module is an all-or-nothing thing. If you start out ignoring const and decide later to stop being so lazy, you have to work through your entire module adding const in a consistent way. However, if you decide to keep being lazy, your module will just be Java as it is today -- no harm done.
I think the bottom line with const as a language feature is that it isn't very dangerous compared to the great benefit provided. It increases efficiency, helps flag coding errors, and serves as documentation. (Documentation that is checked and enforced by the language is by far the best kind of documentation.) Unfortunately, I have no idea if const can be securely implemented in Java. Perhaps that's the catch.
+1
Boost.Python is well designed, well documented, and has an active mailing list. Getting started can be a real pain, but it's a one-time cost. (If you have any trouble getting it to build or building your first project, you'll find it extremely helpful to read through a basic introduction to Jam, the build tool used to build Boost.Python extensions.) After a very difficult start-up, it's been all roses for me.
Also +1 to scripting language integration in general. I love being able to bring up a command line, load up a C++ module, create instances of my objects, and play with them. It's an enormous help in prototyping, debugging, and getting a new developer started.
That's a great idea. If the attractions of Java are unit testing, error handling, and memory management, maybe it would be just as good to hire a C++ coach who can introduce unit testing, Boost smart pointers (or garbage collection, even), and exceptions and be a good-natured coding standards Nazi to make sure your guys use those wherever they're appropriate. Of course, this doesn't do any good if you're already writing excellent C++.
I think a better question is, are the C++ coders writing the kind of C++ code that was typical ten years ago?
If so, they haven't adapted to new C++ practices, and there's no way they'll adapt to Java. They'll write terrible Java and be miserable.
If not, then they'll adapt to Java pretty quickly. Some of their C++ techniques won't be possible in Java, but they'll figure out the strengths of Java in a few months and start writing good Java code.
Oddly enough, the more modern C++ elements you see in your codebase that don't have direct analogs in Java, such as template metaprogramming and RAII, the more optimistic you should be. Those items show that your programmers have learned and adapted to new paradigms and can be expected to adapt well to Java.
Excellent point. Some people consider smilies informal and unprofessional, but nobody can argue that they're easy and efficient. I write emails much faster when I can use emoticons than when I must rely only on prose.
Using emoticons also promotes relaxed and open conversation among brainy types because it is an acknowledgment that writing without them is a difficult and laborious task. An admission of weakness tends to head off conflict because it signals that one isn't interested in chest-thumping or assigning credit and blame.
On a side note, ambiguity is an excellent way to get inside people's heads and force them to think carefully about what you say. When people can't tell what side you're on or whether you're being sarcastic, they're forced to analyze what you actually said. It may be the only thing they honestly think about all day.
Sorry, when I see the term "free market," I don't automatically research what it means to the person using it. Rest assured that if all self-identified believers in the free market were put on a planet together and asked to implement it, there would be a bloodbath.
I can't imagine why you chose to link the paper you did. It systematically explains why every imaginable effective way of limiting pollution is illegitimate under a libertarian system. The solutions proposed require so much time, money, and attention by so many individual litigants that they would simply never happen, and the paper endorses principles that severely limit legal simplifications such as joining defendants and plaintiffs. Because of this, the system described by the paper is a utopia for polluters in which the unlikelihood of effective litigation grants economic legitimacy to pollution. The main promise is not clean air but the freedom to pollute, and if you don't see it that way, then I believe you're misreading the intent of the paper. (That the authors identify pollution as a Bad Thing -- aggression and injury, in their terminology -- means nothing. It is merely de rigueur.)
Markets only operate efficiently with regards to costs that are visible in the market. Many incredibly harmful things may or may not show up as costs in an unregulated market, depending on the circumstances. Theft, fraud, murder, dumping toxic waste, and slavery can all be profitable in a completely unregulated market. Private property itself is a regulation that is enforced in society by government intervention.
No pollution? Pollution doesn't cost anything in a "free" market, so a free market is completely blind to it. Regulation intervenes in the market to attach costs to pollution so the market can efficiently manage it.
A fidgety guy on a street corner reports that police patrols are a waste of taxpayer money.
Do you think there's an efficient way to force companies to practice honest accounting, or do we have to choose between these costs and commonplace large-scale fraud? (Please don't flame; it's an honest question.)
You know the annoying kid you knew in college who would repeatedly interrupt every discussion demanding definitions of all the words being used, and who would argue endlessly about flaws in the definitions so that you couldn't really talk about the topic you wanted to? Imagine you're writing a book, and that guy has to personally approve every sentence.
I noticed as a high schooler interested in math that many of the resources for talented math students were Russian in origin. The Russian system systematically encouraged and assisted math students at every level, even the talented ones. They also did a great job of connecting difficult mathematics and physics to very down-to-earth things such as industry, business, and even carpentry. If Yuri the plumber needs to install a drain, you just know he will require basic physics and a really neat mathematical proof.
Education in the US is all about problems. Not math problems, but problem students. If you aren't part of a social pathology then there's little thanks given to teachers for spending time on you.
Based on their experience, I'm considering it, but I love the taste of coffee... and, yes, that transitory caffeine high in which I work like a maniac for an hour or so before I vague out and start surfing the web.
Silk makes unsweetened soy milk. I can even buy it at HEB, the most common grocery store chain in my part of the US.
It's funny that you mention an 800 MHz PIII. That's what I do my professional software development on. It's the slowest machine in the house, but it's plenty fast, and I wouldn't gain much out of migrating my work environment to the Athlon 64 X2 box I use for web surfing. So your statement is true for my household -- speed is a complete non-issue.
Writing, review, and rewriting helped me most as a writer. I had an excellent teacher in junior high school who made us write constantly, gave us a face-to-face critique of an essay at least once a week, and forced us to go through several revisions on many of our papers. The students critiqued each others' papers as well, which wasn't as helpful as the teacher's critiques but at least taught us that bad writing is unpleasant and unedifying to read. (It also convinced the skeptics that the teacher wasn't exaggerating how many passages were unclear or incoherent.)
The most common failing I see in myself and my colleagues is leaving out important bits of context. I think the best cure for this is reading and critiquing other students' writing.
The most important thing is to force them to write as often as possible. Have them write one-off essays in class, and have them go through three or more rounds of peer review on several papers. At least one paper should go through three rounds of review personally with you. That way they'll get decent advice from at least one person. Frankly, I think everything else should be subordinated. Whatever amount of theorizing and speechifying you manage to fit in between writing and review will be plenty.
None of these things are given; there's no such thing as "the concept." The designer of the language decides what guarantees to give the programmer and what latitude to give to the compiler, as well as what structures are provided to manage concurrency. Essentially, the language designer decides what concepts the users of the language must understand and employ. C and C++ expose the programmer to the full complexity of machine behavior because efficiency has always been their overriding concern, and in any case, those decisions were made at a time when threading was a niche concern. Newer languages typically strike a different balance between efficiency and support for concurrency.
I would +1 the rest of your comment but must take exception here. The Java language standard makes useful sequencing and atomicity guarantees that make it clear exactly when a mutex is needed. C++ does not. A dumbed-down version (because I don't know the precise version, nor know any C++ programmers who do) of what C++ guarantees is that externally observable operations occur in object code in the same order that they occur in the source code. So if the source code says
write A to file F;
write B to file F;
then A will indeed be written to the file before B. However, writes to memory are not deemed to be externally observable. If your code says
a = fooA;
b = fooB;
then other threads may see the value of b change before the value of a changes. So the sequence of operations can only be ensured by using explicit synchronization.
Likewise, atomicity of operations is not guaranteed by the C++ standard. The atomicity of an operation in C++ can only be depended on if you know the compiler will compile the operation to a machine word that you know will execute atomically on the target platform(s).
Because of this lack of guarantees, some synchronization techniques that rely on sequencing or atomicity must be accomplished using mutexes or platform-specific directives. You must explicitly protect pretty much all shared data in C++, and for portability, that means mutexes. In Java, you can safely perform unsynchronized reads and writes to an int member variable without worrying that on some platform, somewhere, a thread might read garbage from that variable because of concurrency. (This statement dates to 2001; now I hear strange terms like "64-bit Java," so this might no longer be true.) Java really acts like a single very well documented platform in that respect. In C++, you might have some degree of confidence that an assignment to an int will be atomic on your target platform, but you probably wouldn't depend on it unless you had a lot of confidence in your knowledge of the compiler, the platform, and the fact that your program would NEVER need to be ported by anyone less expert than you.
Also, most people assume that C++ makes stronger guarantees than it really does, so they write crappy code. Java has always been designed for average programmers, and C++ was designed for experts, but in the case of concurrency, C++ really overshot the mark. C++ dates from a time when only gurus did concurrency, and it shows, especially in the lack of documentation and the failure of most popular C++ programming books to include BIG FLASHING WARNINGS about all the surprising gotchas like reordering of writes to memory, or indeed the failure of most C++ learning resources to address concurrency in any way.
C and C++ are slowly losing their status as common first languages. Programmers raised on modern languages chafe at the lack of consideration for concurrency in the C++ language. This will hurt C++ (and the Lisps), as there are many people who categorize all such languages as being essentially from another time period and not worth learning. Right now, people have to abandon that attitude when they leave school, but what if they didn't have to?
Signed, a proud and happy C++ programmer. I'll repeat, +1 to most of your post, but -1 to the idea that C++'s concurrency support is on par with Java.
Nope. The first computer I built was an old and popular SFF barebones unit from the largest SFF manufacturer, with a Celeron processor. Fedora installed fine right out of the box. I managed to get Windows running on it but had to switch back to Linux several times to figure things out, despite having Windows drivers from the manufacturer. The second computer I built used mainstream everything -- a motherboard from a major manufacturer, an Athlon processor, and a popular mid-range Nvidia graphics card. Once again, Fedora ran fine straight out of the box, but Windows required downloading drivers from manufacturers' web sites and burning them onto CDs. In both cases Windows was unusable on its first install and gave no clue as to how to continue, which is exactly what people used to complain about with Linux.
At least with Linux you can go to Fry's and grab a box off the shelf that probably contains everything you'll need to get up and running in a decent way. Try that with Windows. Windows only works that way if you buy a complete system with Windows installed, in which case you get a set of CDs containing Windows drivers and utilities for your system -- essentially a custom OS distribution for your hardware configuration. Old, super high volume hardware often works right out of the box with Windows, so if you have an old Dell, you're probably in luck. Otherwise, you can look forward to a driver hunt. (So many hardware manufacturers' web sites suck....)
Some companies, such as HP, provide CDs of drivers and extras with their Linux workstations, and they'll even install it for you. Sure, installing an OEM's custom Windows distribution on the OEM's hardware is often easier than installing an off-the-shelf Linux distribution on random hardware. But if you compare apples to apples -- off-the-shelf Windows vs. Linux on random hardware, or Windows vs. Linux from an OEM -- Linux wins. (This is probably due to years of hard work from people trying to win the unfair comparison, so maybe we should let the unfair comparison stick.)
A full feature set and a simple interface can be combined, thanks to the ability of users to ignore what they don't need to understand. The trick in software is to provide advanced controls but make them optional -- preferably in a granular way, so that a browser user can be an advanced user of the tab options interface without needing to understand cookies or the security controls. Actually, a web browser is a great example. Practically anyone can use Firefox, even though an advanced user can:
Disable SSL 2.0 (leaving 3.0 enabled) with four clicks
Disable Javascript with five clicks
Disable a subset of Javascript functionality with fewer than a dozen clicks
Create an original parameterized keyword bookmark by typing in a url format string
And so on.
A surprising number of programs screw this up in one way or another, by shoving tons of options in front of a user with an incoherent set of defaults (if they don't learn all the options they'll never appreciate how leet I am!!!111!!1!) or not including basic controls (I have to hide this from the stupid grandmas or they'll stroke out and die lol!)
Too many ease-of-use oriented designers never figure out how easy it is to hide advanced controls from newbies or basics-only users. As long as non-optional controls are conspicuous and easily understood, optional controls can be hidden in relatively plain sight. Non-advanced users are not on a divine mission to find the advanced controls -- you don't have to make it an ordeal to access them! Usually it's safe to put them exactly where the advanced users expect to find them.
A debugger won't help you if you're trying to ensure correctness at too low a level of abstraction. Most languages give you a couple of low-level building blocks equivalent to the pthreads basics: threads, mutexes, and condition variables. These should not be used directly except in the simplest of circumstances. Rather, they should be used to create a set of higher-level tools that can be applied in a simple and straightforward way to your task.
The most popular way is to create a workflow model with task queues, worker threads, and job dependencies, plus a few application-specific rules to ensure that resource limitations don't cause deadlock.
The high-level model can typically be lifted right out of your proof of deadlock avoidance. Don't have one of those? It's a good idea. The proof gives you a minimal solution and confidence to implement it. Without the proof, you're going to overkill the problem out of nervousness, and you still might miss something crucial.
Fixing Firefox's memory problems might be an unglorious task, but many commercial projects are plagued with the same problems. An ambitious developer could turn Firefox's problems into the beginning of a lucrative career as a performance analyst and bug hunter, if he managed to make a significant difference and get credit for his work.
That's called "vision." I hate it when someone invests a bunch of time and resources in something without being sure of its moral superiority and inevitable triumph and then expects more credit than the noble and enlightened people who really believed. I mean, jeez, without my ostentatious certainty, your efforts would have been totally wasted. Wake up and smell the self-actualization.