Despite all of the anticipation felt by die-hard Star Wars fans in the buildup to the new movies, he disappointed them all by pandering to 10 year-old children with his movie and its slushy plot, cardboard characters and fucking annoying CGI aliens.
Um...Yeah. That's the whole point!
What we're all forgetting is that (for the most part) we were the 10-year-olds when the first trilogy came out. Star Wars has always been first and foremost a children's serial. If you expect gritty, hard-core science fiction, forget it. It will never happen.
And if you don't think Lucas was playing to the children in the original series, let provide a few reminders:
Actually, Moore's Law refers to the density of transistors on a chip, not speed. It happens that speed follows transistor density because smaller transistors switch more quickly.
Since a vote for a minor party will have basically no chance of being reflected in the overall representation in Congress or elsewhere, my only way of influencing politics at all is to vote for the "lesser of two evils" from the major parties.
Not to pick on you personally, but I'm really tired of hearing this. Comments like this strike me as being from someone who is just looking for an excuse to complain.
Does anyone here remember where the (current) Republican party came from?
Yes, it's true the Reps and Dems have more money, etc. to blow on a campaign, but a vote for a third party is not wasted. Ask Abe Lincoln.
And for those complaining about how politics today is all about mudslinging and character assasination, please review the history of presidential elections in the United States. This has been going on almost since the country was founded. US News had a good article on this a few issues back.
I was specifically responding to Bruce's assertion that KDE should not have responded at all. In any event:
RMS's position is absurd. As the KDE folks point out, many projects which have violated the GPL in far worse ways in the past have had no such treatment by RMS. It doesn't matter whether "forgiveness" implies legal or moral issues. The fact that he asks for special action on the part of the KDE developers when no such action has been required of, for example, Be, Corel or anyone that used older versions of bison smacks of the worst kind of double standard elitism.
The KDE folks were quite restrained. I'd have said much worse things.
I disagree. If the KDE developers had kept silent, we would now be speculating on why the KDE project is ignoring this latest difficulty brought up by RMS. How many times have we heard questions about why KDE ignored the GPL/Qt conflict and didn't take a public stance?
However I really wish that Debian would come out with a simple yet complete default install with all other packages as add-ons.
Ahh, I grok you now. I think what you're looking for will be available when debconf is adopted by all the packages. It allows the user to choose a configuration threshold so that questions deemed below the threshold (i.e. they have sane defaults) will not be asked. Debian is working on a completely automatic install process based on debconf. I'm not sure if it'll be ready for woody, though.
I've not tried a potato install from scratch, but when I installed slink, I simply skipped the dselect step. It installed the base system and that's it. It was then just a matter of apt'ing just the things I wanted.
Of course I left out FP. Everyone knows x86 has a horrible FP implementation. It's not even worth comparing because it's so crippled.
This does not invalidate what I stated. CISC does not require a braindead FP stack implementation.
If it's just Intel's brute force keeping IA32 on top, then may I humbly suggest the other manufacturers hire away some of that brute?
I'm not sure what other units you're referring to. Memory, perhaps? A lot of that has more to do with the PC platform than anything else -- consumer-level machines don't require huge levels of memory bandwidth and scaling.
Keep in mind that SpecINT measures the entire processor performance runnning (mostly) integer applications. This includes memory and control flow.
Could x86 run faster if it weren't burdened with a huge decoder? Probably. Branch mispredicts are a big problem.
My point is that you can't judge a processor by its packaging (marketing). It's the guts and the bottom line that count. Speculations based on anecdotes and (in this case) dogma are next to useless.
We all know that RISC processors (i.e. Alpha) are faster and better than CISC processors (i.e. x86)
Not true, not true. The x86 processor family provides the highest SpecINT rating and has for some time now. We can argue about benchmarks all day, but Spec is the industry standard.
Just because something is RISC doesn't automatically make it the Holy Grail. There are a lot of factors that go into processor design.
Which brings me to another point about the P4: unless there's been some grand breakthrough in branch prediction of which I am unaware, I don't buy the trace cache as being anything more than a predecode cache (which, granted, on an x86 could be a big deal).
That's too bad. The unique thing about the KTMA era is that there was no writing whatsoever. It was all improvised. All that, and fan letters, too. *sniff*
Actually, forking can be extremely useful in some cases. Probably the best example is the gcc/egcs split that happened some years ago.
At the time, the gcc maintainer was sitting on an enormous number of patches, mostly contributed by Cygnus. These patches fixed critical problems with g++. Things were so bad at one point that the Cygnus version of g++ was the only version of gcc that could compile my code.
Several people brought this up on USENET. Some time later, the EGCS project was announced. The Cygnus compiler was quickly released more visibly (it had of course always been availble on their FTP site). Development was changed to a bazaar style and improvements quickly rolled in.
About two years later, the FSF finally caught up and decided to roll in the EGCS changes, creating gcc 2.95. Both projects happily merged and all is well in compiler-land.
Forking is probably the most powerful tool we have in the Free Software community. It's akin to booting our elected officials out of office. If handled in a civil manner, it is a useful tool to spur development on a stagnant project.
I think what they means is that woody does not yet have all the packages necessary to completely install and run the system from scratch.
When people say unstable is more stable than other distributions, they usually mean that upgrading to unstable doesn't cause many problems. One has to start with a released version of the OS. For example, I recently installed Slink on a couple of machines and upgraded to Woody with apt.
And unstable is very stable. Any problems I have had were fixed within a couple of days, though they did involved some workarounds. For example modutils was broken a few days ago, which was kind of a pain to fix (had to compile a static kernel). It's still not completely correct, last I checked (couple of days ago).
I've rarely ever found magazine articles to be much helpful in things.
Well, to each his own, of course. However, just as C has its well-known idioms (the on-line copy loop being an example), so does C++. It's just that the C++ idioms tend to be more abstract (things like design patterns and such). These are usually well-explained in articles, because a book on the subject would either be too short or contain too many disparate ideas to be of any use.
I recently read a couple articles about traits that helped me solve a problem I'd been struggling with for a week. Through the judicious use of templates and traits, I was able to greatly reduce both the size and complexity of the system I was designing.
That I can write C in C++ is probably one of the big negatives for C++ for me.
I would be so tempted to just do what I know.
While I understand your concern, I think it is unfounded. It's how I started out, and while I don't consider myself a guru, I certainly have learned enough on large-scale projects to consider myself more than competent in C++. C++ was designed to be like C to ease the transition for C programmers, and I think it's one of its greatest strengths. One can slowly add language features to the designer's toolkit without upsetting things too much. That fact that you can make use of all the existing C libraries is a godsend.
Why do
I need to "get" encapsulation when I already have it in the abstract sense of the design? C is just the vehicle I use to bridge the
abstraction-to-reality gap. Don't assume that because I code in C, that I didn't do anything object oriented in the design (I do to
varying degrees in many projects).
I hear this one a lot, and frankly (please don't take this the wrong way), I think it reveals a fundamental misunderstanding of the purpose of a high-level language. The language exists to help the programmer. It is a tool and nothing more. There is nothing "magical" about encapsulation or inheritance. As you said, one can write OO programs in any language. It's just that some languages make it easier than others.
C++ is designed to catch errors at compile-time. Strong typing and templates make the use of void pointers almost completely unnecessary (they are useful in the implementations of templates in some cases). Compiler-enforced encapsulation makes it impossible to get at data that shouldn't be got at. I had to chuckle at the comment (in another thread) about const being a horrible component of the language. I know it has saved me countless times from obscure bugs that otherwise would have to be tracked down in the debugger.
Why write a big, clunky switch statement when a couple of virtual functions will do the job just as well and better separate various components of the design? Another thread contains a good analogy: in C, a loop is an abstraction of a backward goto. In the same way inheritance and virtual functions are an abstraction of unions and switches.
Most of the documentation out there for so much stuff is written with the idea of sequential reading in mind. I don't have the time
to do that in most cases, so documentation that gives an introductory concept explanation (without the usual sales talk that most
use as introductions), and has all the rest as a well indexed reference, would do better for me (and a lot of people I know).
This past weekend I picked up The C++ Standard Library by Josuttis. I've found this to be a wonderful reference, with sections not only covering the STL, but also strings, numerics, iostreams, i18n and allocators. It has a good TOC and index. I've not read it straight through (or even made an attempt), but it is very easy to find what I need. Explanations are clear and concise. Reading one page of the iostreams chapter halped me successfully derive a new stream buffer and class in five minutes. All previous documents were either too esoteric or verbose -- I couldn't get my head around the problem.
In a previous post, you suggested:
If you still want to convert C programmers to use C++ then I suggest writing a book... a short one, that explains every concept in
C++... not just language syntax, but practical concepts... clearly and concisely. Don't drag it out for newbies; focus on experienced
C programmers. Explain how it is that C++ takes basic OO design concepts and puts them into a programming language. Explain
how C++ behaves with each concept at higher abstract as well as lower real levels. Include a full reference section. And make sure
there are examples of whole programs, not just snippets everywhere. Maybe then you might see more converts. But until someone
does this, I doubt you will see very many.
Perhaps you'd be interested in the following books:
I've only read D&E. This is probably where you should start. It is very small. It's whole purpose is to explain why things are they way they are (i.e. you don't pay for what you don't use).
In addition, journals like DDJ and the (now-defunct) C++ Report have good articles about practical software development. I hear many of the C++ Report folk are heading over to the C++ User's Journal.
The most important thing to remember about C++ is that it is complicated. But only as complicated as you make it. For all intents and purposes, you can write C in C++. A good place to start is using it as "C with classes" to get encapsulation, then move on to polymorphism. It's also important to understand when to use language features (i.e. templates and specialization vs. inheritance) and books like Effective C++ help in that regard.
I've been shopping for a good, free C++ toolkit for some time now. I've come to the conclusion that no such beast exists.
The toolkits generally suffer from one of several problems:
Poor documentation (Inti, Gtk--, FOX)
Pool integration with std C++ (Qt, FLTK, FOX, wxWindows)
Poor font support (Gtk--, FLTK)
I'm writing an app that requires good support for drawing items to a blank canvas. It has to support things like lines and curves as well as arbitrarily placed text of arbitrary font and size. It sould also support scaling of the view. It's incredibly difficult to find a toolkit that does this well. GnomeCanvas is about the best I've found. From what I tell, most of the existing tookits are built to allow "cookie-cutter" application building. Really custom stuff is not well supported. I'm not saying it should be braindead. But it should be reasonably possible.
Granted, I haven't investigated every toolkit thoroughly. I simply don't have the time. But from the available documentation, I have yet to find the toolkit that's right for me. Maybe Inti will be. Given the complete lack of documentation, there's no way to tell.
If someone can help me find a toolkit that addresses all of the above problems, I would greatly appreciate it.
Let me say because of MP3s, I've spent more money on CDs than I ever had. I also buy the stuff that I want to listen to. I listen to a lot of Progressive Rock, which wouldn't otherwise be played on the radio.
So you buy the CD's, which is great. Why again is Napster necessary for this? I agree that Napster is a great way to check out new bands. Perhaps the model that should be adopted is one where Napster provides:
Sample tracks under permission of the performer/RIAA
Snippets of tracks a la Amazon (fair use)
This issure is bigger than Napster. It sets a bad precident for the way I discover music. Music under the big corporations is becoming more and more of a product than art anymore.
Music under the "big corporations" has always been more of a product than art. Witness the large amounts of tin-pan-alley dross foisted upon bands in the 20's and 30's. We only remember it as art because the truly great songs are the ones that survived the test of time.
But that's not the "official" Gnutella. It seems odd to me that RMS get up in arms about GNU/Linux but doesn't care about a project that is usurping the name GNU.
And here's more food for thought: MP3 proponents have always claimed that it allows indie musicians more exposure. But Chris' post contradicts this. He really is competing against the big labels. With all the copying of the big mainstream groups, it's getting much more difficult for the indie musician to be heard.
Sure, services like MP3.com help, but if everyone is trading music (illegally) on Napster and Gnutella, does it matter?
To get off-track a bit, I'm curious as to why RMS has not waged a campaign against Gnutella. It's not GNU is any sense whatsoever. What is Gnutella's license, anyway. It better not be GPL.
Actually, I was coding with Qt about a year ago and had some of the same questions.
Recently, I checked out the latest version of Gtk--. While I haven't started using it yet, it looks like gold. It fully integrates with the STL and libsigc++ is signals/slots done correctly (using the full power of templates rather than a preprocessor).
Now, before Qt fans get up in arms, it is clear that Qt was developed before the STL and templates were well supported. For me, it looks like Gtk-- has exactly what I need.
A nice comparison of the Qt and libsigc++ callback methods is presented here.
Slashdot Mirror
--
Um...Yeah. That's the whole point!
What we're all forgetting is that (for the most part) we were the 10-year-olds when the first trilogy came out. Star Wars has always been first and foremost a children's serial. If you expect gritty, hard-core science fiction, forget it. It will never happen.
And if you don't think Lucas was playing to the children in the original series, let provide a few reminders:
--
--
Not to pick on you personally, but I'm really tired of hearing this. Comments like this strike me as being from someone who is just looking for an excuse to complain.
Does anyone here remember where the (current) Republican party came from?
Yes, it's true the Reps and Dems have more money, etc. to blow on a campaign, but a vote for a third party is not wasted. Ask Abe Lincoln.
And for those complaining about how politics today is all about mudslinging and character assasination, please review the history of presidential elections in the United States. This has been going on almost since the country was founded. US News had a good article on this a few issues back.
--
RMS's position is absurd. As the KDE folks point out, many projects which have violated the GPL in far worse ways in the past have had no such treatment by RMS. It doesn't matter whether "forgiveness" implies legal or moral issues. The fact that he asks for special action on the part of the KDE developers when no such action has been required of, for example, Be, Corel or anyone that used older versions of bison smacks of the worst kind of double standard elitism.
The KDE folks were quite restrained. I'd have said much worse things.
--
I disagree. If the KDE developers had kept silent, we would now be speculating on why the KDE project is ignoring this latest difficulty brought up by RMS. How many times have we heard questions about why KDE ignored the GPL/Qt conflict and didn't take a public stance?
--
Ahh, I grok you now. I think what you're looking for will be available when debconf is adopted by all the packages. It allows the user to choose a configuration threshold so that questions deemed below the threshold (i.e. they have sane defaults) will not be asked. Debian is working on a completely automatic install process based on debconf. I'm not sure if it'll be ready for woody, though.
--
For a more pessimistic view, check out this journal paper.
--
--
This does not invalidate what I stated. CISC does not require a braindead FP stack implementation.
If it's just Intel's brute force keeping IA32 on top, then may I humbly suggest the other manufacturers hire away some of that brute?
I'm not sure what other units you're referring to. Memory, perhaps? A lot of that has more to do with the PC platform than anything else -- consumer-level machines don't require huge levels of memory bandwidth and scaling.
Keep in mind that SpecINT measures the entire processor performance runnning (mostly) integer applications. This includes memory and control flow.
Could x86 run faster if it weren't burdened with a huge decoder? Probably. Branch mispredicts are a big problem.
My point is that you can't judge a processor by its packaging (marketing). It's the guts and the bottom line that count. Speculations based on anecdotes and (in this case) dogma are next to useless.
--
P6, anyone? I would think O-O-O execution would be a pretty major overhaul.
--
Not true, not true. The x86 processor family provides the highest SpecINT rating and has for some time now. We can argue about benchmarks all day, but Spec is the industry standard.
Just because something is RISC doesn't automatically make it the Holy Grail. There are a lot of factors that go into processor design.
Which brings me to another point about the P4: unless there's been some grand breakthrough in branch prediction of which I am unaware, I don't buy the trace cache as being anything more than a predecode cache (which, granted, on an x86 could be a big deal).
--
--
At the time, the gcc maintainer was sitting on an enormous number of patches, mostly contributed by Cygnus. These patches fixed critical problems with g++. Things were so bad at one point that the Cygnus version of g++ was the only version of gcc that could compile my code.
Several people brought this up on USENET. Some time later, the EGCS project was announced. The Cygnus compiler was quickly released more visibly (it had of course always been availble on their FTP site). Development was changed to a bazaar style and improvements quickly rolled in.
About two years later, the FSF finally caught up and decided to roll in the EGCS changes, creating gcc 2.95. Both projects happily merged and all is well in compiler-land.
Forking is probably the most powerful tool we have in the Free Software community. It's akin to booting our elected officials out of office. If handled in a civil manner, it is a useful tool to spur development on a stagnant project.
--
When people say unstable is more stable than other distributions, they usually mean that upgrading to unstable doesn't cause many problems. One has to start with a released version of the OS. For example, I recently installed Slink on a couple of machines and upgraded to Woody with apt.
And unstable is very stable. Any problems I have had were fixed within a couple of days, though they did involved some workarounds. For example modutils was broken a few days ago, which was kind of a pain to fix (had to compile a static kernel). It's still not completely correct, last I checked (couple of days ago).
--
Well, to each his own, of course. However, just as C has its well-known idioms (the on-line copy loop being an example), so does C++. It's just that the C++ idioms tend to be more abstract (things like design patterns and such). These are usually well-explained in articles, because a book on the subject would either be too short or contain too many disparate ideas to be of any use.
I recently read a couple articles about traits that helped me solve a problem I'd been struggling with for a week. Through the judicious use of templates and traits, I was able to greatly reduce both the size and complexity of the system I was designing.
While I understand your concern, I think it is unfounded. It's how I started out, and while I don't consider myself a guru, I certainly have learned enough on large-scale projects to consider myself more than competent in C++. C++ was designed to be like C to ease the transition for C programmers, and I think it's one of its greatest strengths. One can slowly add language features to the designer's toolkit without upsetting things too much. That fact that you can make use of all the existing C libraries is a godsend.
I hear this one a lot, and frankly (please don't take this the wrong way), I think it reveals a fundamental misunderstanding of the purpose of a high-level language. The language exists to help the programmer. It is a tool and nothing more. There is nothing "magical" about encapsulation or inheritance. As you said, one can write OO programs in any language. It's just that some languages make it easier than others.
C++ is designed to catch errors at compile-time. Strong typing and templates make the use of void pointers almost completely unnecessary (they are useful in the implementations of templates in some cases). Compiler-enforced encapsulation makes it impossible to get at data that shouldn't be got at. I had to chuckle at the comment (in another thread) about const being a horrible component of the language. I know it has saved me countless times from obscure bugs that otherwise would have to be tracked down in the debugger.
Why write a big, clunky switch statement when a couple of virtual functions will do the job just as well and better separate various components of the design? Another thread contains a good analogy: in C, a loop is an abstraction of a backward goto. In the same way inheritance and virtual functions are an abstraction of unions and switches.
--
And I did specify free (as in beer).
MFC (last I checked) also falls under the "Poor integration with std C++" clause. As does VC++, BTW.
And, ironically, so does std::fstream, among others in std...argh!
--
This past weekend I picked up The C++ Standard Library by Josuttis. I've found this to be a wonderful reference, with sections not only covering the STL, but also strings, numerics, iostreams, i18n and allocators. It has a good TOC and index. I've not read it straight through (or even made an attempt), but it is very easy to find what I need. Explanations are clear and concise. Reading one page of the iostreams chapter halped me successfully derive a new stream buffer and class in five minutes. All previous documents were either too esoteric or verbose -- I couldn't get my head around the problem.
In a previous post, you suggested:
Perhaps you'd be interested in the following books:
I've only read D&E. This is probably where you should start. It is very small. It's whole purpose is to explain why things are they way they are (i.e. you don't pay for what you don't use).
In addition, journals like DDJ and the (now-defunct) C++ Report have good articles about practical software development. I hear many of the C++ Report folk are heading over to the C++ User's Journal .
The most important thing to remember about C++ is that it is complicated. But only as complicated as you make it. For all intents and purposes, you can write C in C++. A good place to start is using it as "C with classes" to get encapsulation, then move on to polymorphism. It's also important to understand when to use language features (i.e. templates and specialization vs. inheritance) and books like Effective C++ help in that regard.
Hope this helps!
--
The toolkits generally suffer from one of several problems:
I'm writing an app that requires good support for drawing items to a blank canvas. It has to support things like lines and curves as well as arbitrarily placed text of arbitrary font and size. It sould also support scaling of the view. It's incredibly difficult to find a toolkit that does this well. GnomeCanvas is about the best I've found. From what I tell, most of the existing tookits are built to allow "cookie-cutter" application building. Really custom stuff is not well supported. I'm not saying it should be braindead. But it should be reasonably possible.
Granted, I haven't investigated every toolkit thoroughly. I simply don't have the time. But from the available documentation, I have yet to find the toolkit that's right for me. Maybe Inti will be. Given the complete lack of documentation, there's no way to tell.
If someone can help me find a toolkit that addresses all of the above problems, I would greatly appreciate it.
--
So you buy the CD's, which is great. Why again is Napster necessary for this? I agree that Napster is a great way to check out new bands. Perhaps the model that should be adopted is one where Napster provides:
Music under the "big corporations" has always been more of a product than art. Witness the large amounts of tin-pan-alley dross foisted upon bands in the 20's and 30's. We only remember it as art because the truly great songs are the ones that survived the test of time.
--
Nice, eh?
--
--
Sure, services like MP3.com help, but if everyone is trading music (illegally) on Napster and Gnutella, does it matter?
To get off-track a bit, I'm curious as to why RMS has not waged a campaign against Gnutella. It's not GNU is any sense whatsoever. What is Gnutella's license, anyway. It better not be GPL.
--
I was just about to say the same. :)
Thanks for a good discussion!
--
Recently, I checked out the latest version of Gtk--. While I haven't started using it yet, it looks like gold. It fully integrates with the STL and libsigc++ is signals/slots done correctly (using the full power of templates rather than a preprocessor).
Now, before Qt fans get up in arms, it is clear that Qt was developed before the STL and templates were well supported. For me, it looks like Gtk-- has exactly what I need.
A nice comparison of the Qt and libsigc++ callback methods is presented here.
--