What in the heck happened to my HTML tags? They were there in the preview... oh well, here goes again:
Always use the right tool for the job... in other words, learn every language you can.
Rgularly program in C++ (mainstream applications), Fortran 90/95 (scientific number curnching and high-performance cluster apps), Python (scripting and prototypes), Java (portability and network systems), and various other languages as the need arises.
Programming is a matter of algorithm, process, and design; syntax is a detail.
BTW, your opinion of Fortran 90 is incorrect; indeed, Fortran 90 (and 95) is widely used, especially in the high performance computing (cluster) community. There is an active Fortran 95 project for the GNU compiler collection, and Intel has a "non-commercial" version of the Fortran 95 for Linux. Fortran 200x is in development right now.
Always use the right tool for the job... in other words, learn every language you can.
I regularly program in C++ (mainstream applications), Fortran 90/95 (scientific number curnching and high-performance cluster apps), Python (scripting and prototypes), Java (portability and network systems), and various other languages as the need arises.
Programming is a matter of algorithm, process, and design; syntax is a detail.
BTW, your opinion of Fortran 90 is incorrect; indeed, Fortran 90 (and 95) is widely used, especially in the high performance computing (cluster) community. There is an active Fortran 95 project for the GNU compiler collection, and Intel has a "non-commercial" version of the Fortran 95 for Linux.
Fortran 200x is in development right now.
In addition to the blindness shown by regulators in approving a dangerous Yucca Mountain site, another issue is at stake: the United States doesn't legally pown Nevada:
No conspiracy theories, just good old-fashion adherence to what is supposed to be the law of the land.
And for those who don't care about the long-standing problems of Indians: Where do you think the U.S. government learned how to steal people's rights? If you want to defend your rights, defend those of others.
...can be summarized in the oft-repeated phrase, uttered by people who work on projects like KDE: "I don't get paid to do this."
There are many good reasons to write free software: education, personal need, exposure, generosity, and altruism. But idealism will only carry you so far, and at some point, you need to feed and clothe yourself.
Money is more than a way of buying "stuff" -- it is a social contract between individuals, a symbolic binder that defines relationships and responsibilities. For "free" software, the lack of any "binder" between developer and user is a problem that must be addressed.
The answer is clear and conclusions plain: a product will be only as good as the market demands. When the market demands better software, the software will get better.
I'll grant that consumers get what they expect -- but do we have to give it to them?
Free software, in theory, is not driven by the consumers you deride -- yet free software projects seem to have an awful lot of bugs, and poor documentation, and many of the other flaws found in commercial works. Using your logic, free software should be bug-free and perfect, given that it is not influenced by commercial concerns -- and it just ain't so. Programmers are a lazy lot, from my experiences; they'll spen all night fine tuning a lovely obscrue hack, but won't spend any time thoroughly designing a project before they begin typing code.
You say people get what they deserve; I say programmers and management are lazy, and use "customers" as an excuse for writing lousy software.
The article misses a few points, but otherwise gives a good explanation of why software has devolved from engineering to hacking. The primary cause for this state of affairs is a lack of design and testing, and every programmer needs to seriously consider what they do and how it's done.
Blaming it all on "management", however, is naive at best. Yes, managers want everything now and have no patience for planning beyond the end of their budget or product cycle -- but programmers themselves have a real responsibility for the quality of their work. In too many cases, the professional discipline that was computer programming has devolved into amateur hacking. We take more pride in cute little tricks than we do in writing solid, maintainable code; a pretty user interface may be unusable, but it looks so nice that managers and consumers ignore or tolerate underlying flaws.
Free software suffers from such problems as well; read the daily mailing lists for the Linux kernel, or the GNU compiler collection, or any large "open" product, and you'll see that many eyes do not necessarily mean better software. Someone finds a "bug" or wants an enhancement, so they dive in, create a patch, and submit it, without any real concept of how the new code fits into the overall product. Ever wonder why so many "free" software projects lack documentation? It's because the programmers are more enamoured of coding than they are of design and writing.
Not to say that I haven't made my mistakes over the years, or that my software is perfect. In many cases, "mistakes were made" because I was programming as a job, where my paycheck wasn't determined by the perfection of my code. Writing books is no different from writing code for an employer; time pressures and the need "to get to market" supercede any requirements for reliable code. Until we change priorities as an industry, I don't see the quality of software improving. Programmers (like all people) are only as good as their environment and ethics allow them to be.
Jon, might I suggest that you write about real issues instead of inventing them?
The reality is: Star Wars Episode II and Spiderman are both doing well. Why create a conflicts and a social even when there isn't one? Most people I know saw both; they're great escapist eye candy. I can spout statistics that show how Star Wars beat Spidey at the box office (per screen revenues, for example)... but it's not worth the trouble.
I just took my two oldest dughters, ages 13 and 11 to see Star Wars. There is something magical about taking my kids to see a movie mythos that I've loved since the first film amazed me at age 15. The same thing happened with The Lord of the Rings last December -- I shared with my kids something special from my own life.
I'll be impressed when Spiderman 5 comes out in twenty-fix years and still pulls down blockbuster numbers.
Okay, perhaps I was a bit harsh; I had just spent an hour reading shallow review after shallow review of Wolfram's work, and I dumped on you. Please accept my apology for the tone; I could have made my point more politely.
Slashdot tends to be a "me first, me first" forum, where erroneous articles get published with the expectation of "fixing" mistakes in a Slashback.
I come from the world of professional journalism, where people actually pay to read the words I write. A slower realm, to be sure, and not always more accurate -- but dead-tree journalism receives more respect than Internet writing, for the simple reason that web articles get published as quickly as possible with minimal depth, while print articles at least have a number of people looking them over, fixing typos and grammar and giving some sense of fact-checking.
Can we look forward to an in-depth review once you've read the book?
Oh, give me a freaking break. "Look through the chapters" is not reading, especially when it comes to a book of this depth and complexity. The reviewer can't possible grasp a work that took decades to write, simply by "looking through it."
Bah. I'd rather be thought a troll by shallow people than lauded for an incomplete review of a book I haven't read.
"Skimming" is not reading, and the reviewer's opinion is meaningless if he hasn't had time to digest the book. The reviewer BEGINS by declaring his or her ignorance and lack of effort -- that's just plain irresponsible.
This is a book, not a TV show or a movie; it will still be available a month (and probably ten years) from now, giving a reviewer plenty of time to actually READ the book before commenting on it. Then the review might have some credibility.
The review begins with a a grand statement about how the author hasn't even read the book -- the first inidcation that the reviewer is reviewing reactions and interviews, and not Wolfram's actual words.
An algorithm is a pure expression of process; it has no meaning with execution and data contexts. Thus, I think Wolfram has gone beyond science into faith and religion... he may answer "how", but that is only part of an entire description of the universe that also asks "why" and "what."
Be that as it may, I am fond of heretics who shake the foundations of science with unorthodoxy. Wolfram is brilliant, if erratic, and I'll read his book simply to have my viewpoints challenged.
...where you will learn that the vast majority of humanity is not interested in "causes" or "revolutions". Even when most people recognize that they are being harmed or exploited, they lack the confidence and courage to do something about it. They rationalize that it isn't their problem, or that nothing can be done, or that it's really someone else's responsibility. They close their ears so they don't hear about something they can't cope with.
Any revolution is lead by a few who are willing to sacrifice anything for what is right. How many of the "privacy" advocates are willing to give up their job, risk harassment, and alienate friends in the quest to do what is "right?"
Of course I'm cynical -- I've studied history, and I've worked the frontlines of various causes. Complaining that other people won't "fight the good fight" is a waste of effort. If the fight is worth fighting, then you must be willing to take the responsibility on your back to "do the right thing."
At the least the site stayed running with the spike in hits...
I'm putting together some "large" benchmarks for the "rematch" when gcc 3.1 hits reality next week. The problem with most "real world" programs is that they're interactive or I/O bound, masking the code generator's abilities.
I need to be clear about one thing: Anyone who tosses out gcc over this review is a fool. Intel C++ is a good product for very specific applications, but it does not replace gcc. All the benchmarks show is that Intel C++ can provide a performance boost for certain classes of computationally-bound programs. For some of my scientific work, Intel kicks ass in comparison to gcc... for some other projects, gcc comes out on top. What's important is choice and competition, which fuel evolution...
I urge people to read the entire article before making any assumptions about my goals or the results.
Modifying an article after publication is acceptable -- and it's a Good Thing if the revision fixes errors or omissions.
Modifying an article and not telling anyone is a Bad Thing called a "lie."
A case in point: Yesterday, I posted a benchmark comparison of Intel's "non-commercial" C++ compiler and gcc. Several people gave me suggestions for improving gcc's performance, and I updated the article today -- with clearly marked additions and explanations of what changed and why. That's journalism on the web.
Good reply; I'll respond to just a couple of your points:
In terms of refinement, I'm all in favor of avoiding changes that break existing code. Of course, the original C++ Standard broke some code when it was approved, as do almost all new standards. It's a cost-benefit choice; I prefer maximum benefit for minimal cost, without hamstringing the language's ability to grow.
In its original form, C++ derived from C, with a goal of "as close to C, but no closer" as iterated by Stroustrup and Koenig. The C99 Standard contains design decisions incompatible with C++; thus, in the future, C++ will no longer be upwardly compatible with C. The whole episode is raft with human politics, but the end result is that what was once true is now false.
While it might be a good idea to implement set/map/vector in certain ways, the reality is that the standard provides no guidance on implementation (which is good), leaving vendors to make bad choices. An excellent example is the performance of vector, which varies by a factor of three between various Linux compilers. The code may be portable, but the performance may not. I pick a fast part of STL under Linux, and it runs like a dog under Windows... ugh. I don't want the Standard to specify implementation (see the horrors of rand()!), but I'd also like to see strong guidelines that keep the language consistent.
I stand on my "20%, 80% of the time" statement. Most of the time, I create vectors, push things into them, get the begin and end iterators, and destroy them. About 20% of the time, I use other methods. And on high-performance code, I dump vendors in favor of good, old-fashion C-style arrays.
One last note: I didn't say smart pointers were equivalent to garbage collection -- however, there should have been a paragraph break there somewhere.
In 2001, Bjarne Stroustrup
started a dialogue about the future of
C++. As primary inventor of C++, Bjarne is giving interviews, visiting user's
groups, and posting in forums, all with the intent of stimulating discussion
about where C++ should "go." It's an important topic for software
engineers, and everyone has a laundry list of features they'd like to see added in the next
revision of C++.
I'll buck the laundry-list trend and suggest some things I don't want to put in
the next C++.
In my experience, C++ iterators, algorithms, and containers are inefficient and unnecessarily
complex. The actual source code doesn't look terribly confusing — it's the
underlying mechanisms that obscure function with too much form. We heap
template upon template, giving the compiler nightmares while obscuring what is
really happening "under the hood."
Is container abstraction akin to the hiding a car's pistons from its
driver? No, because I'm not driving the car, I'm building it. And as any
good engineer can tell you, hidden complexity and obfuscated parts have been
the bane of many software (and hardware) projects. I have no problem with containers being part
of the language — what bothers me is that the current set of containers is
complicated and inconsistent. We need to refine the current standard before we
begin adding new material; otherwise, we build new code on uncertain
foundations.
An official template library also leads to another question: Just what is
a "standard" container? Some people argue that, for the sake of completeness,
we should add hash-based containers to the standard library. But "completeness"
means different things to different people; someone might want balanced binary tree
containers, while others would prefer B-Tree or r-tree implementations.
And then we get into the whole issue of graphical development — and you end
up with Java, that tries to be everything to everyone but does few things
particularly
well.
The current template library is much too heavy, prone to the "feature
creep" inherent in a committee-based standards process. And when the
standard includes an inconsistency, (list<>.sort() comes to mind),
we're stuck with it. Should a list be sorted via its member method or the
sort algorithm? And what constitutes a "required" container
feature? I use about 20% of the vector<> template 80% of the time; it
seems to me that C++ needs a functional hierarchy that stems from a set of
concise "base" containers.
We also have the entire realm of garbage collection and
"smart" pointers, which is a nasty tangle of divergent opinions.
The auto_ptr<> type has numerous logical and practical problems,
as does the Boost smart_ptr<>. I don't believe one type of smart
pointer makes sense for all applications — and C++'s experience with
auto_ptr<> should teach us to avoid providing specific solutions
to general problems. I'm still not convinced that automatic garbage collection
is a good idea in most applications; it tends to make programmers lazy about
controlling their resources.
I've always preached that code should be no more complicated than necessary —
and that includes the code I obtain from language libraries. The
C++ container types are heavy and detailed, when what we need is a simple
set of light, fast containers, with hooks for adding algorithms that fit
individual application needs.
Consider, for a moment, that Slashdot and other pro-Linux sites trumpeted the introduction of Linux in Mexico. Did anyone think Microsoft wouldn't notice?
Sometimes, it's best to tread softly and carry a big stick; if you yell too much about a potential success, some bigger fish might come along and eat your lunch. Microsoft perceived the Linux-Mexico initiatives as a threat, and reacted with their drug-dealer attitude: "The first one is free." It sounds *so* good, until you find your country trapped by a monopoly...
Perhaps Linux needs to work harder and quiter, instead of bringing undue attention upon itself with artless boasting.
Sheesh, I wish these politicians and spooks would grow up. The Yellow Menace went out with poodle skirts and tailfins. These poor blokes, with George "how do you spell W?" Bush at their head, need an enemy to pad their profit lines.
Yeah, some Chinese twits might do something annoying -- just like our own twits. Why are *their* twits worse? I can hazard a guess...
Most of my early books are out of print, and I always have people e-mailing me asking for copies. I don't have any to sell, but I can direct them to a used bookstore. I already received my pittance (a couple bucks on a $40 retail computer book) for the book, so why should I insist on getting paid again?
If someone doesn't need one of my books any longer, I encourage them to sell it through a used store. I want some of my old books to be available to new readers!
On the other hand, there are a couple books I wrote (at publisher's insistence) that I wouldn't mind seeing vanish from the planet!;)
My main monitor is a 17" HP F70 LCD; it is sharp, brilliant, fast, and clear at 1280x1024. I play StartFleet Command, Wizardry 8, Heroes of Might & Magic IV, Destroyer Command, and Combat Flight Simulator with no problems at all.
Of course, I could have bought three nice 19" CRTs for the same price, but the CRTs would have continued to give me a headache, I suspect. My eyes don't twitch after 12 hours of coding on the LCD... and that's worth something.
My advice -- stay away from cheap LCDs and the bargain 15-inchers. You get what you pay for...
Well, I'm not so sure about the EFF myself... maybe I'll just take my $50 and buy a competitor's game, or donate it to a home for penguins -- anything but give it to Blizzard.
It isn't so much that Blizzard doesn't have a point about bnetd -- it's how they made their point that bugs me. The DMCA is a bad law that is misapplied in this case; it is a bad precedent at best.
As has been reported recently in many places (including Slashdot), Scientology is using the DMCA to edit Google and other sources of imformation about their cult. In a similar fashion, Blizzard is using the DMCA and the threat of lawsuit to stop people from the legitimate fair and reverse engineering of Battle.net. Both companies are using the DMCA for "bad" purpose, which makes the comparison valid.
As for my "breed cults of ill-mannered folk" comment -- spend some time on Battle.net, and you'll see what I mean. I play lots of games, and Blizzard attracts the most childish fans of any company. Living in Clearwater, Florida, the "spiritual home" of Scientology has taught me much about the poor behavior of Scientology.
Slashdot Mirror
Always use the right tool for the job... in other words, learn every language you can.
Rgularly program in C++ (mainstream applications), Fortran 90/95 (scientific number curnching and high-performance cluster apps), Python (scripting and prototypes), Java (portability and network systems), and various other languages as the need arises.
Programming is a matter of algorithm, process, and design; syntax is a detail.
BTW, your opinion of Fortran 90 is incorrect; indeed, Fortran 90 (and 95) is widely used, especially in the high performance computing (cluster) community. There is an active Fortran 95 project for the GNU compiler collection, and Intel has a "non-commercial" version of the Fortran 95 for Linux. Fortran 200x is in development right now.
Always use the right tool for the job... in other words, learn every language you can. I regularly program in C++ (mainstream applications), Fortran 90/95 (scientific number curnching and high-performance cluster apps), Python (scripting and prototypes), Java (portability and network systems), and various other languages as the need arises. Programming is a matter of algorithm, process, and design; syntax is a detail. BTW, your opinion of Fortran 90 is incorrect; indeed, Fortran 90 (and 95) is widely used, especially in the high performance computing (cluster) community. There is an active Fortran 95 project for the GNU compiler collection, and Intel has a "non-commercial" version of the Fortran 95 for Linux. Fortran 200x is in development right now.
What goes around, comes around. DO something about it, or get over it.
In addition to the blindness shown by regulators in approving a dangerous Yucca Mountain site, another issue is at stake: the United States doesn't legally pown Nevada:
Stealing Nevada
No conspiracy theories, just good old-fashion adherence to what is supposed to be the law of the land.
And for those who don't care about the long-standing problems of Indians: Where do you think the U.S. government learned how to steal people's rights? If you want to defend your rights, defend those of others.
There are many good reasons to write free software: education, personal need, exposure, generosity, and altruism. But idealism will only carry you so far, and at some point, you need to feed and clothe yourself.
Money is more than a way of buying "stuff" -- it is a social contract between individuals, a symbolic binder that defines relationships and responsibilities. For "free" software, the lack of any "binder" between developer and user is a problem that must be addressed.
I'll grant that consumers get what they expect -- but do we have to give it to them?
Free software, in theory, is not driven by the consumers you deride -- yet free software projects seem to have an awful lot of bugs, and poor documentation, and many of the other flaws found in commercial works. Using your logic, free software should be bug-free and perfect, given that it is not influenced by commercial concerns -- and it just ain't so. Programmers are a lazy lot, from my experiences; they'll spen all night fine tuning a lovely obscrue hack, but won't spend any time thoroughly designing a project before they begin typing code.
You say people get what they deserve; I say programmers and management are lazy, and use "customers" as an excuse for writing lousy software.
The article misses a few points, but otherwise gives a good explanation of why software has devolved from engineering to hacking. The primary cause for this state of affairs is a lack of design and testing, and every programmer needs to seriously consider what they do and how it's done.
Blaming it all on "management", however, is naive at best. Yes, managers want everything now and have no patience for planning beyond the end of their budget or product cycle -- but programmers themselves have a real responsibility for the quality of their work. In too many cases, the professional discipline that was computer programming has devolved into amateur hacking. We take more pride in cute little tricks than we do in writing solid, maintainable code; a pretty user interface may be unusable, but it looks so nice that managers and consumers ignore or tolerate underlying flaws.
Free software suffers from such problems as well; read the daily mailing lists for the Linux kernel, or the GNU compiler collection, or any large "open" product, and you'll see that many eyes do not necessarily mean better software. Someone finds a "bug" or wants an enhancement, so they dive in, create a patch, and submit it, without any real concept of how the new code fits into the overall product. Ever wonder why so many "free" software projects lack documentation? It's because the programmers are more enamoured of coding than they are of design and writing.
Not to say that I haven't made my mistakes over the years, or that my software is perfect. In many cases, "mistakes were made" because I was programming as a job, where my paycheck wasn't determined by the perfection of my code. Writing books is no different from writing code for an employer; time pressures and the need "to get to market" supercede any requirements for reliable code. Until we change priorities as an industry, I don't see the quality of software improving. Programmers (like all people) are only as good as their environment and ethics allow them to be.
Jon, might I suggest that you write about real issues instead of inventing them?
The reality is: Star Wars Episode II and Spiderman are both doing well. Why create a conflicts and a social even when there isn't one? Most people I know saw both; they're great escapist eye candy. I can spout statistics that show how Star Wars beat Spidey at the box office (per screen revenues, for example)... but it's not worth the trouble.
I just took my two oldest dughters, ages 13 and 11 to see Star Wars. There is something magical about taking my kids to see a movie mythos that I've loved since the first film amazed me at age 15. The same thing happened with The Lord of the Rings last December -- I shared with my kids something special from my own life.
I'll be impressed when Spiderman 5 comes out in twenty-fix years and still pulls down blockbuster numbers.
Okay, perhaps I was a bit harsh; I had just spent an hour reading shallow review after shallow review of Wolfram's work, and I dumped on you. Please accept my apology for the tone; I could have made my point more politely.
Slashdot tends to be a "me first, me first" forum, where erroneous articles get published with the expectation of "fixing" mistakes in a Slashback.
I come from the world of professional journalism, where people actually pay to read the words I write. A slower realm, to be sure, and not always more accurate -- but dead-tree journalism receives more respect than Internet writing, for the simple reason that web articles get published as quickly as possible with minimal depth, while print articles at least have a number of people looking them over, fixing typos and grammar and giving some sense of fact-checking.
Can we look forward to an in-depth review once you've read the book?
Oh, give me a freaking break. "Look through the chapters" is not reading, especially when it comes to a book of this depth and complexity. The reviewer can't possible grasp a work that took decades to write, simply by "looking through it."
Bah. I'd rather be thought a troll by shallow people than lauded for an incomplete review of a book I haven't read.
"Skimming" is not reading, and the reviewer's opinion is meaningless if he hasn't had time to digest the book. The reviewer BEGINS by declaring his or her ignorance and lack of effort -- that's just plain irresponsible.
This is a book, not a TV show or a movie; it will still be available a month (and probably ten years) from now, giving a reviewer plenty of time to actually READ the book before commenting on it. Then the review might have some credibility.
The review begins with a a grand statement about how the author hasn't even read the book -- the first inidcation that the reviewer is reviewing reactions and interviews, and not Wolfram's actual words.
But then again, this is Slashdot... ;)
An algorithm is a pure expression of process; it has no meaning with execution and data contexts. Thus, I think Wolfram has gone beyond science into faith and religion... he may answer "how", but that is only part of an entire description of the universe that also asks "why" and "what."
Be that as it may, I am fond of heretics who shake the foundations of science with unorthodoxy. Wolfram is brilliant, if erratic, and I'll read his book simply to have my viewpoints challenged.
Any revolution is lead by a few who are willing to sacrifice anything for what is right. How many of the "privacy" advocates are willing to give up their job, risk harassment, and alienate friends in the quest to do what is "right?"
Of course I'm cynical -- I've studied history, and I've worked the frontlines of various causes. Complaining that other people won't "fight the good fight" is a waste of effort. If the fight is worth fighting, then you must be willing to take the responsibility on your back to "do the right thing."
At the least the site stayed running with the spike in hits...
I'm putting together some "large" benchmarks for the "rematch" when gcc 3.1 hits reality next week. The problem with most "real world" programs is that they're interactive or I/O bound, masking the code generator's abilities.
I need to be clear about one thing: Anyone who tosses out gcc over this review is a fool. Intel C++ is a good product for very specific applications, but it does not replace gcc. All the benchmarks show is that Intel C++ can provide a performance boost for certain classes of computationally-bound programs. For some of my scientific work, Intel kicks ass in comparison to gcc... for some other projects, gcc comes out on top. What's important is choice and competition, which fuel evolution...
I urge people to read the entire article before making any assumptions about my goals or the results.
Modifying an article after publication is acceptable -- and it's a Good Thing if the revision fixes errors or omissions.
Modifying an article and not telling anyone is a Bad Thing called a "lie."
A case in point: Yesterday, I posted a benchmark comparison of Intel's "non-commercial" C++ compiler and gcc. Several people gave me suggestions for improving gcc's performance, and I updated the article today -- with clearly marked additions and explanations of what changed and why. That's journalism on the web.
What CNET is doing is called lying.
Good reply; I'll respond to just a couple of your points:
In terms of refinement, I'm all in favor of avoiding changes that break existing code. Of course, the original C++ Standard broke some code when it was approved, as do almost all new standards. It's a cost-benefit choice; I prefer maximum benefit for minimal cost, without hamstringing the language's ability to grow.
In its original form, C++ derived from C, with a goal of "as close to C, but no closer" as iterated by Stroustrup and Koenig. The C99 Standard contains design decisions incompatible with C++; thus, in the future, C++ will no longer be upwardly compatible with C. The whole episode is raft with human politics, but the end result is that what was once true is now false.
While it might be a good idea to implement set/map/vector in certain ways, the reality is that the standard provides no guidance on implementation (which is good), leaving vendors to make bad choices. An excellent example is the performance of vector, which varies by a factor of three between various Linux compilers. The code may be portable, but the performance may not. I pick a fast part of STL under Linux, and it runs like a dog under Windows... ugh. I don't want the Standard to specify implementation (see the horrors of rand()!), but I'd also like to see strong guidelines that keep the language consistent.
I stand on my "20%, 80% of the time" statement. Most of the time, I create vectors, push things into them, get the begin and end iterators, and destroy them. About 20% of the time, I use other methods. And on high-performance code, I dump vendors in favor of good, old-fashion C-style arrays.
One last note: I didn't say smart pointers were equivalent to garbage collection -- however, there should have been a paragraph break there somewhere.
In 2001, Bjarne Stroustrup started a dialogue about the future of C++. As primary inventor of C++, Bjarne is giving interviews, visiting user's groups, and posting in forums, all with the intent of stimulating discussion about where C++ should "go." It's an important topic for software engineers, and everyone has a laundry list of features they'd like to see added in the next revision of C++.
I'll buck the laundry-list trend and suggest some things I don't want to put in the next C++.
In my experience, C++ iterators, algorithms, and containers are inefficient and unnecessarily complex. The actual source code doesn't look terribly confusing — it's the underlying mechanisms that obscure function with too much form. We heap template upon template, giving the compiler nightmares while obscuring what is really happening "under the hood."
Is container abstraction akin to the hiding a car's pistons from its driver? No, because I'm not driving the car, I'm building it. And as any good engineer can tell you, hidden complexity and obfuscated parts have been the bane of many software (and hardware) projects. I have no problem with containers being part of the language — what bothers me is that the current set of containers is complicated and inconsistent. We need to refine the current standard before we begin adding new material; otherwise, we build new code on uncertain foundations.
An official template library also leads to another question: Just what is a "standard" container? Some people argue that, for the sake of completeness, we should add hash-based containers to the standard library. But "completeness" means different things to different people; someone might want balanced binary tree containers, while others would prefer B-Tree or r-tree implementations. And then we get into the whole issue of graphical development — and you end up with Java, that tries to be everything to everyone but does few things particularly well.
The current template library is much too heavy, prone to the "feature creep" inherent in a committee-based standards process. And when the standard includes an inconsistency, (list<>.sort() comes to mind), we're stuck with it. Should a list be sorted via its member method or the sort algorithm? And what constitutes a "required" container feature? I use about 20% of the vector<> template 80% of the time; it seems to me that C++ needs a functional hierarchy that stems from a set of concise "base" containers.
We also have the entire realm of garbage collection and "smart" pointers, which is a nasty tangle of divergent opinions. The auto_ptr<> type has numerous logical and practical problems, as does the Boost smart_ptr<>. I don't believe one type of smart pointer makes sense for all applications — and C++'s experience with auto_ptr<> should teach us to avoid providing specific solutions to general problems. I'm still not convinced that automatic garbage collection is a good idea in most applications; it tends to make programmers lazy about controlling their resources.
I've always preached that code should be no more complicated than necessary — and that includes the code I obtain from language libraries. The C++ container types are heavy and detailed, when what we need is a simple set of light, fast containers, with hooks for adding algorithms that fit individual application needs.
Anything else is trying to be Java. ;)
Consider, for a moment, that Slashdot and other pro-Linux sites trumpeted the introduction of Linux in Mexico. Did anyone think Microsoft wouldn't notice?
Sometimes, it's best to tread softly and carry a big stick; if you yell too much about a potential success, some bigger fish might come along and eat your lunch. Microsoft perceived the Linux-Mexico initiatives as a threat, and reacted with their drug-dealer attitude: "The first one is free." It sounds *so* good, until you find your country trapped by a monopoly...
Perhaps Linux needs to work harder and quiter, instead of bringing undue attention upon itself with artless boasting.
Sheesh, I wish these politicians and spooks would grow up. The Yellow Menace went out with poodle skirts and tailfins. These poor blokes, with George "how do you spell W?" Bush at their head, need an enemy to pad their profit lines.
Yeah, some Chinese twits might do something annoying -- just like our own twits. Why are *their* twits worse? I can hazard a guess...
...because Orcs would never stoop so low.
Most of my early books are out of print, and I always have people e-mailing me asking for copies. I don't have any to sell, but I can direct them to a used bookstore. I already received my pittance (a couple bucks on a $40 retail computer book) for the book, so why should I insist on getting paid again?
If someone doesn't need one of my books any longer, I encourage them to sell it through a used store. I want some of my old books to be available to new readers!
On the other hand, there are a couple books I wrote (at publisher's insistence) that I wouldn't mind seeing vanish from the planet! ;)
My main monitor is a 17" HP F70 LCD; it is sharp, brilliant, fast, and clear at 1280x1024. I play StartFleet Command, Wizardry 8, Heroes of Might & Magic IV, Destroyer Command, and Combat Flight Simulator with no problems at all.
Of course, I could have bought three nice 19" CRTs for the same price, but the CRTs would have continued to give me a headache, I suspect. My eyes don't twitch after 12 hours of coding on the LCD... and that's worth something.
My advice -- stay away from cheap LCDs and the bargain 15-inchers. You get what you pay for...
Well, I'm not so sure about the EFF myself... maybe I'll just take my $50 and buy a competitor's game, or donate it to a home for penguins -- anything but give it to Blizzard.
It isn't so much that Blizzard doesn't have a point about bnetd -- it's how they made their point that bugs me. The DMCA is a bad law that is misapplied in this case; it is a bad precedent at best.
As has been reported recently in many places (including Slashdot), Scientology is using the DMCA to edit Google and other sources of imformation about their cult. In a similar fashion, Blizzard is using the DMCA and the threat of lawsuit to stop people from the legitimate fair and reverse engineering of Battle.net. Both companies are using the DMCA for "bad" purpose, which makes the comparison valid.
As for my "breed cults of ill-mannered folk" comment -- spend some time on Battle.net, and you'll see what I mean. I play lots of games, and Blizzard attracts the most childish fans of any company. Living in Clearwater, Florida, the "spiritual home" of Scientology has taught me much about the poor behavior of Scientology.