While I agree in general that MS puts out lots of good software and does excellent research, I couldn't let this go:
Now, I'm not much of a MS fan, however, it must be pointed out that their office software does work very well, and works well with itself.
This is completely untrue for any serious technical documentation. Figures and bulleted/numbered lists top my worst experiences in Word. Excel's data point limit has more than once forced me over to gnuplot.
Office is great for the vast majority of users: business types, one-off letters, etc. It is completely insufficient for anything of substantial size or complexity. LaTeX or Frame wins hands down.
The important thing to "get" about OO (at least
in the C++ sense) is that you invoke an interface
on an object and it does different things depending on the true type of the object. This
is nice because you can write code that doesn't
really care about the type of thing it's operating on:
void drawAll(const shapeList &shapes)
{
for(shapeList::const_iterator i = shapes.begin();
i != shapes.end();
++i) {
(*i)->draw();
}
}
All we have here is a list of pointers to Shape. Each object could be a Circle, Rectangle, etc. The drawAll code doesn't care. All it knows is that it has to draw everything. This nicely separates the high-level "draw everything" interface from the individual details of how to draw each shape. A good way to look at it is that the C++ virtual function mechanism has replaced the traditional C tagged union and switch construct. That's a lot of code to save.:)
Projects like Linux would really benefit from this. Every time a C++ programmer sees and if-else tree or a switch, she instantly thinks virtual functions and wonders why anyone would go to all the trouble.:)
The UNIX file system is OO in this sense. The user redirects from or to device nodes (i.e. to do audio recording or playback). He doesn't care what type of device it is or even that it is a device. All he knows is that this file causes neet things to happen. Too bad it's not implemented in an OO language in Linux:(
As for minimalist, C++ can do that too. Not only does it generate "as good as C" code for equivalent functionality, it reduces source code size as well. Getting this benefit sometimes requires a bit more overhead than C (i.e. declaring classes, etc.) but in the long run it is a real win. Not to mention the outstanding standard library which saves hours of drudgery.
Of course OO is not needed in every project or even many of them. That is why C++ is so nice to use. We pick the tool that appropriate to the task out of the many provided by the language. Once can write perfectly good advanced C++ code without using inheritence or polymorphism. In fact the cutting edge today seems to involve heavy use of generic programming and metprogramming -- inheritence is only used when necessary.
There are many new features over C, which radically increases the complexity of the language.
This is certainly true. C++ compilers are hard to write. So are C compilers.
C++ maps poorly onto the actual assembly language of the processor
Please back up this statement. It maps no worse than C does, given code with the same functionality.
the code produced in C++ for any program with more than one object will ALWAYS be slower than equivalent C code.
Careful with those absolutes. I don't know what you mean by "more than one object," but I can show you C++ code using standard library constructs that runs much faster than functionally-equivalent C code, even when the C code uses custom implementations tuned to particular data types.
C++ is not, not, not slow.
Finally, it's not possible to write C++ code to maximise code-space or RAM-space efficiency,
This is just plain wrong. As with any language there are multiple entries in the solution space for a given problem. Choose the one to use the least amount of X. In the end you can always resort to "C with classes" if you must (which you shouldn't).
since you are entirely at the mercy of the compiler writer - the best you can do is select from a coarse menu and hope the compiler does it properly.
OO is not needed to do magnificient things. Look at the Linux and other kernels.. Look at the many other applications that are not C++. Granted you can do OO programming In plain C.
You're right that OO is not needed to do magnificent things, but you're wrong that Linux is not OO. It's not explicitly OO in the sense of the language or programming style used in its implementation, but the whole concept of UNIX itself is based on OO principles. The "everything is a file" idea sounds suspiciously like the OO "isa" relationship (A isa B).
Just today I was reading the LWN kernel page, where 64-bit DMA interfaces are discussed. To support 64-bit DMA a new datatype will be declared along with a bunch of new interfaces probably looking very similar to the current 32-bit interfaces. In addition, various devices will require different kinds of DMA transactions based on the type of device and/or the host system configuration. Sounds OO to me.
I have always viewed OO programming as a style not as something very important. Everything you can do with your OO styles I am sure can be done without it.
Well of course, since in the end it's all machine code anyway.:)
I am concerned about the statement that OO is not important. It's not magic pixie dust, but it helps solve real world problems very well. It's an important tool in the programmer's belt. Yes, it's "merely" a style but style is what makes art art. And make no mistake, program design and implementation is an art as much as it is a science.
If Slack works for you, great. It may not in the future and it certainly doesn't for many Linux users.
Wow. You've left a bit of FUD on your chin. Would you like a napkin?
Where's the FUD? Many Linux users don't use Slack. That's not in debate. It's obviously not right for them. Or are you objecting to the colloquial use of "works?"
If some time in the future you become tired of manually configuring and building packages[...]
This shows a deep misunderstanding of how Slack and Slack packages work.
I know how Slack packages work. Used 'em for many years. I was responding directly to a comment that having to manually configure packages (X in this case) is good and indirectly to a (common, IME) belief among Slackware users that compiling from source is a necessary task for good system maintenance. You're right, I was a little sloppy with my wording.
[acknowledge] that changes come through time how open-minded and forward-thinking you are.
Hmmmm. If hiding information from the administrator is open-minded and forward-thinking, give me unreceptive and reactionary any day.
Well, I was being a bit facetious there, but only a little. It takes some insight and courage to realize that sometimes the easy way is not a cop-out. It's the same reason that NIH is so looked down upon.
How, presently, do package managers hide information? I agree they can, but I can't think of a single instance where they do. Note that I'm coming from a Debian perspective and YMMV for other distributions or operating systems.
The concept that Linux must be easy to use for any clueless git on the planet is seriously flawed.
First off, no one is a "clueless git." They may not be interested or may not have the background you and I do, but they almost certainly have a clue in areas where you and I will be
lost. Sorry, this sort of talk really grates on me.
The requirement of study and attention to detail to run a *nix system is a Good Thing. I'd prefer that people who aren't willing to put in the time and effort stay out of the pool rather than pissing in it.
Now how could someone new to Linux/UNIX possibly ruin it for you? At worst a nice hacker writes a useful interface for that person. No reason you have to use it. Yes, you could argue about open relays or some such thing, but that sort of thing has been going forever, even before UNIX became less macho. Either it happens in closed/unfixable Windows or it happens in Linux. I'd rather it happened in Linux, and making Linux friendly is the only way to accomplish that.
--
Re:The Neverending wave of criticism of slackware.
on
Slackware 8.0 Released
·
· Score: 1
Ok, that's a good point. However, with Debian (don't know about others) it is trivial to grab the source of a package, tweak it, automatically build a new package and have it play nice with the packaging system.
For kernels, this is pretty much the standard practice in Debian. In fact there's a nice make-kpkg tool that converts a generic kernel source tree into a Debian package, configured to your liking and ready to install. It even runs LILO for you so you don't forget.:)
--
Re:The Neverending wave of criticism of slackware.
on
Slackware 8.0 Released
·
· Score: 2
The problem is a packaging system that enforces the maintainers idea of dependencies. Yes, the maintainer may have built his RPM on a system with libfoo-1.1, but I have libfoo-1.0.8, because I've found libfoo-1.0.9 to be broken for me. And after I rip open the RPM and hand install the thing, I find it works perfectly fine with libfoo-1.0.8...
True, this is a maintainer problem. The package in this case is buggy and needs to be fixed. Packages should only specify the bare minumum of dependecies. That's why we have dependencies like "glibc >= 2.0."
Making every administrator specify dependencies is not the answer, though. Perhaps some way of incrementally modifying the dependecy structure of a package would be useful. Think "free software" for packages, but in a more automated fashion. As people learn what additional versions of things the package works with, they can be added to the specification.
--
Re:The Neverending wave of criticism of slackware.
on
Slackware 8.0 Released
·
· Score: 1
It's actually a namespace problem with packaging schemes per se.
There should be a way for the Netscape package to say "I optionally need an icon package associated with Netscape, doesn't matter what it's called" without the whole thing blowing up.
You are absolutely correct. Debian supports this in a primitive way with the "provides" field.
--
Re:The Neverending wave of criticism of slackware.
on
Slackware 8.0 Released
·
· Score: 1
For example, both Ximian Gnome and the Red Hat Netscape RPM's provide a Netscape Icon, thus producing a conflict and breaking up2date.
The problem there is mixing packages from two independent, non-cooperating vendors, not packaging per se.
The underlying problem with Windows (and MacOS) is that it is condecending to the user. "There there, poor, stupid user, don't worry, we'll just install this crap and you don't have to think..."
No, the problem is that these systems hide what is going on and make it impossible to fix when problems occur. I don't want to think when doing something as mundane as upgrading software. Gads, I have too many other thing to think about!
One of the major goodneses of Free software and Linux is that it does not condecend. The user has the right to be responsible for their own computer!
Packaging systems in no way prevent that.
My friends with Red Hat call me saying they updated an RPM and now the config's different and they can't find the config file and the dependancies won't resolve and so on... It's the same calls they made to me years ago about Windows.
They're making the call because it's not convenient to RTFM. One of the really nice things about Debian is/usr[/share]/doc. Nothing in Slackware would prevent these sorts of call. You'll just get them about configuring X or running./configure && make && make install.
USE THE SOURCE, People! This is not a black box... It's good to know and care what's happening on your hard drive.
Of course its good to know this. It's even better if it can be automated and the knowledge kept in a nicely-organized system.
No, _I_ dont think the cli is hard or unfriendly to use at all. Though this seems to be the opinion of all my friends who arent big fans of linux / BSDs (one of my friends beleives EVERYTHING should be done on OS9 macs).
Note that I mentioned vendors leaving the CLI as the sole user experience. I do not underestimate the power and user-friendliness of the CLI. It's an absolutely crucial element of a user interface.
My response was more to the point of some UNIX advocates thinking that to be a real UNIX Guru one has to work solely at the CLI, or configure Sendmail by hand or some other ridiculous notion. The hostility toward graphical mailers/editors/wizards is a perfect example. Not all of these things are right for me because I am more familiar with other tools. But that doesn't mean the ideas are wrong.
I agree that it's fun to rummage around a system, find out how things work, etc. It's part of the learning process. Forcing this process on people who aren't interested is a bad idea.
If Slack works for you, great. It may not in the future and it certainly doesn't for many Linux users. If some time in the future you become tired of manually configuring and building packages, you won't be "giving up" or "sacrificing your UNIX-ness" by moving to another distribution. You'll just be ackowledging that changes come through time how open-minded and forward-thinking you are.:)
--
Re:The Neverending wave of criticism of slackware.
on
Slackware 8.0 Released
·
· Score: 1
Living in the past is certainly fun and educational but it also has a tendency to close our minds to new ideas.
As a postscript, realize that the reverse is also true: ignoring the past leads us to reinvention and downright hostility to those keeping it alive. Witness the "30 year old technology" rants of Bill and Steve and the blackballing of those not on "the cutting edge" in most fields.
--
Re:The Neverending wave of criticism of slackware.
on
Slackware 8.0 Released
·
· Score: 2
Dependencies should be up to the administrator, not up to the maintainers, because the maintainers will eventually get something wrong.
Eh? This makes no sense at all. Why reproduce very hard work millions of times. Let one person intimately familiar with the software do it and validate the results. Yes, there will be bugs. That's why we do testing. With your strategy those bugs will be repeated millions of times and will be more frequent because there's no way an administration team can keep track of the dependecies of an entire system.
I tried both Debian 2.0 and Debian 2.2 and the complexity level and rigidness level are on part with that of RPM-based distributions, only not as polished.
What did you find rigid about Debian?
Maybe it's better said like this: Slackware is the old-school sysadmin's distro!
Ah, now I understand your viewpoint. I vigorously disagree with it, but I understand it.:)
Living in the past is certainly fun and educational but it also has a tendency to close our minds to new ideas. This is not a personal criticism. I've heard this view expressed too many times in too many different contexts to be able to ignore it. Hell, I'm guilty of it myself (check the.sig).
I then went to slackware, which i LOVE, because it is pure unix and not afraid of saying it.
There's nothing "UNIX" about "hard to use!" Does no one remember why UNIX came about? It was a simplification of MULTICS, both in the kernel and in user space. The "everything is a file" paradigm was developed for the user. UNIX != unfriendly and there is no reason something has to be held back in the Dark Ages of the CLI to be UNIX. UNIX system vedors left the CLI as the sole interface years ago.
UNIX == user friendly. Unfortunately, most of us still haven't realized it and cling to some overblown nostalgic view of the "good old days."
As for your unfortunate Red Hat experience, it was my experience around Red Hat 5.0 that the packages just weren't well-maintained. I switched to Debian and never looked back. Don't judge a concept by its implementation.
Also its good because its default setup of X never works properly (in my experience), so it almost FORCES the new user to figure out the command line before getting lazy with X.
You can't be serious. The only thing worse would be a non-working sendmail.
I agree that Slack is a great way to get under the hood and learn a few things. I'd encourage anyone interested in Linux beyond day-to-day use to install Slack and have a go at maintaining it. But to get work done, go with a package-managed distribution.
Before everyone comes down on me, I do think Slackware has one very important role. It is an excellent teaching tool. I'd encourage everyone new to Linux to try out Slackware in some way, either on a space machine, partition or before installing a more advanced distribution. Maintaining a Slack system really helps one to understand the UNIX Way and why things are they way they are. You'll also appreciate all the hard work packagers do to make your life simple.
Don't underestimate the importance of Slackware in this role. I view it as critical.
--
Re:The Neverending wave of criticism of slackware.
on
Slackware 8.0 Released
·
· Score: 1
Slackware was originally created because Patrick Volkerding couldn't get 386BSD working on his computer. So he took the time and created the basis of a truely UNIX based linux distrobution. It's a damn shame no one else seems to have followed his lead.
I don't follow you. What's not UNIX-like about Red Hat, Debian or any other server/workstation distribution of Linux? Perhaps you meant "BSD based?"
Slackware tarballs are still cross platform compatable to other unixes, or windows. Or at least far more than RPMs or DEBs.
One can examine and unpack.debs with standard tools. Please see here. Yes,.deb is missing some functionality. But it does more and is more "cross platform" than most people realize.
Slackware is a sourcefriendly distrobution that is rock solid from the bottom up.
I'd argue that Debian is more source-friendly than Slackware because source packages are an integrated part of the distribution. That's a big part of what makes Debian Debian. Source is available for anything and it is trivial to download, build and install any package from source. The "build depends" field in.deb means that there shouldn't ever be a problem getting all the tools necessary to build it. Those complaining that Debian releases too slowly (they do, but it's for a good reason) can always build unstable source packages for their stable distribution. I don't think it's guaranteed to always work due to build-depends (tools from unstable may be needed), but it should work most of the time.
With alien, I've had no trouble installing RPMs. I've never tried a.tgz, but I can't imagine it would be all that much different.
It is not a wonder that it doesn't die, It is only a wonder that people don't take the time to think about seriously using it.
No it isn't a wonder that more people don't use it. I'll agree with you that it's not a wonder it hasn't died. It will be around as long as it's useful to someone and with millions of people using Linux, the odds are pretty high that this will be the case for some time.
Many people don't use it because they've realized that Debian provides everything Slackware does plus a lot more. I consider it the modern version of the great Slackware that saved us from SLS back in its heyday.
Other people don't use it because they just don't care about building from source and use Red Hat or some other binary-focused distribution. Honestly, what's the difference between downloading source, compiling and installing and installing a binary package? It certainly isn't any more secure. It's only more work and takes time people could use to actually get something useful done.
anymore than cp and tar are 'package management tools'.
Exactly right.
of course, deb doesn't really have alternate distros, so i assume it would have a similar drift problem were it in the same circumstance.
Corel and Progeny are both based on Debian, use the.deb package format and have no problems interacting with "official" Debian packages. I think this is a testament to the design of the distribution. I'm not sure how cross-polination between Progeny and Corel works. I doubt they include dependecies or conflicts between each other.
The iPAQ Familiar distribution uses the.ipkg format which is.deb repackaged using tar instead of ar so that ar doesn't have to be installed. So Debian-proper packages are out.
The Intimate iPAQ distribution is Familiar using full-blown.debs. Adding Debian-proper packages is no problem.
Finally, there's emdebian, another ARM-based handheld distribution. It's not too far along, though.
So Debian does indeed have several derivatives, most using the original package format and having no problem mixing Debian packages and its own repackaged software.
--
Re:Why does GCC require so much memory?
on
GCC 3.0 Released
·
· Score: 1
Where I work, we're developing software that has a medium to long lifespan. I've got to write code with the expectation that it will be modified and maintained by other people who aren't likely to be exposed to these techniques. Clarity, simplicity, and adherence to standards are generally more important in our code than cleverness, and there has to be a compelling reason to do something unorthodox.
I figured as much. Recently there was a discussion on comp.std.c++ on the STL's map interface. While not directly related to your concerns, I did get into an argument with Bjarne over the amount of time/money spent in trying to understand the standard library when a few simple changes could make life much easier for the average programmer. His viewpoint is that one must keep up with the latest techniques. I agree to a point, but understand the realistic situation you've outlined above, where not all members of the team can afford to live on the bleeding edge.
IMHO one of the larger problems is the lack of adequate tools to analyze and debug C++ code. Using gdb is a nightmare with g++ and as you indicated, it is incredibly difficult to debug template metaprograms. At least some people (e.g. Jeremy Siek) are working on techiques to improve compiler error messages (concept checks)!
--
Re:Why does GCC require so much memory?
on
GCC 3.0 Released
·
· Score: 1
But for template instances that are required but don't have definitions visible, it will store some extra information in the object file to be used by the linker to re-invoke the compiler. This is one reason for the ABI change.
That is very nice. It will allow better separation of interface and implementation.
So am I. I've read some of his stuff, including Modern C++. Fascinating stuff, although it's difficult to justify using many of his techniques in production code.
I'm curious as to why you say this. Is it the amount of inlined code or the fact that it's something akin to magic?:)
That may be true. The projects I'm working on don't use a lot of that due to their age. One could compile Blitz++ or Andrei Alexandrescu's Loki to find out.:)
I did try my hand at some metaprogramming which used a bit of partial specialization. I was using (I think) 2.90.blah and it failed miserably. But that compiler was so old and buggy I'm sure it would work much better now.
--
Re:Why does GCC require so much memory?
on
GCC 3.0 Released
·
· Score: 1
Anyway, most of the C++ compilers I've used follow the original Cfront method for handling templates:
Information about which template instances are required by which program unit are stored by the compiler in "instantiation request" files
Right. This is the "control file" method I mentioned. IIRC, Cfront didn't implement this in a completely automatic way, though compilers that use this model have cleaned it up.
I would think that explicit template instantiation would be faster than this method only because the compiler and prelinker aren't doing all of this bookeeping. The same amount of code should be compiled either way. That's why I don't really understand what makes the MSVC template instantiation method so fast.
The overhead is not only in the bookeeping. The overhead is also in generating the instantiations. To do this the compiler has to re-parse the source and generate code (either by recompiling the entire object file all over again or placing just the generated template code in a separate object). Some implementations could avoid this by generating some sort of targeted template code (a la DyC or other runtime compilers), but I don't know of any implementation that does this. It's tough to know which dominates. It probably depends on how "integrated" the prelinker is (i.e. does it rely on external programs to analyze object files?).
In contrast, the current gcc model (gcc 2.95 + GNU ld 2.8) is to let the compiler create all template instances required by a given unit during the compilation of that unit. Of course, this creates a lot of duplicate symbols. It is the purpose of the collect2 program to throw away the duplicates.
Whoops! Yes, of course you are correct. This is a different model from the prelinker method. It does have the drawback of generating the same code over and over again, though it only has to parse each source file once.
I seem to recall that collect2 is only used on ELF systems. How does instantiation work for other object types? I do recall, in the early days of EGCS, a repository (.rpo) notion that never quite worked for me. Has this been implemented correctly now? I didn't see much about how this all works in the 2.95.2 info files.
Ironically, I don't find gcc to be any slower at compiling template code than most other UNIX compilers. In many cases, it's faster.
It could be parsing speed, but that seems unlikely. It probably depends on how the other compilers implement "recompilation." There's a large design space trading off complexity and speed. Then again, maybe the prelinker bookkeeping really is expensive. I haven't seen any good numbers.
However, I do know that most implementations in UNIX land are derived from the SGI implementation, which was derived from earlier HP work. In the version of the SGI implementation that the GCC team based their work on, all class template member functions and member templates were defined inline. I have never understood the justification for writing it that way. Perhaps the MS implementation of the STL makes considerably less use of inlining.
This is an excellent point. The SGI STL is pretty braindead in terms of implementation. I'm very interested to see the fruits of Andrei Alexandrescu's YASTLI (Yet Another STL Implementation) project. His plan (documented on comp.lang.c++.moderated) is to implement the STL (hopefully all of the standard library eventually) using all of the modern design techniques (policies, traits, metaprogramming, typelists, etc.) to create a super-efficient version of the library. No compromises will be made for non-standard compilers, so it will be a good conformance test. g++ should do well in that regard.
For those interested, his book Modern C++ Design gives some clues on what he's thinking. It's an excellent read and I highly recommend it for anyone interested in some of the latest C++ design techniques, especially concerning templates.
Which features do you need? The export keyword is not supported, but automatic instantiation works very well.
I'm greatly anticipating the new C++ library. Finally we will have stringstream! For me the C++ library was the largest hole in the C++ implementation. The compiler itself has been quite good for some time, feature-wise.
--
Re:Why does GCC require so much memory?
on
GCC 3.0 Released
·
· Score: 5
For one thing, the MS compiler & linker don't support automatic template instantiation. You may not have noticed this because the IDE does the bookeeping for you and generates the template declarations needed by the compiler.
This is not a bad thing. In fact, it is a very valid (I'd say good!) design decision. Explanation below.
For some reason, most compilers are faster when you turn of automatic instantiation and explicitly list the template instances you need.
The reason explicit instantiation is so much faster is that the compiler doesn't have to compile your code twice. Automatic template instantiation requires some sort of support outside the compiler proper. For all the gory details, I recommend Stan Lippman's Inside the C++ Object Model. It's a little out of date and inaccurate (or more properly, misleading) at times, but for anyone interested in why C++ works the way it does and what sort of decisions the compiler makes when generating code, it's a great book. It dispels many of the common myths about C++'s performance and makes an honest evaluation of the cases where performance is negatively affected.
But I digress. One of the most popular strategies for automatic template instantiation involves some sort of "collector" program. The basic idea is to collect all the object files that go into the final link and look for undefined symbols that refer to template code. The GNU collect2 program does this for g++. Once the symbols have been identified, the compiler needs some way of knowing how to recompile the source files that contain the template elements. Strategies include using control files generated by the compiler and collector, entries in the object files themselves (strings or symbols are common) or a combination of the two. Other strategies are possible as well. The driver script (the IDE in VC++) gathers this information and reinvokes the compiler to recompile the source files containing the needed template code, passing flags to tell the compiler to instantiate particular templates.
After having implemented some of this, I have to tell you that it is all a tremendous pain in the neck. It's also quite, quite convenient and necessary for the user.:)
As for the MS IDE, that's just another strategy for handling the problem. No compiler that I know of fully handles automatic template instantiation by itself. The closest that a compiler could come to this would be to aggregate the collector actions into the compiler as a separate phase. This is really no different that running a separate program and the "compiler" becomes the driver script (think g++), with the compiler proper (i.e. translation and transformation) being but one (usually, more than one) phase of compilation.
Every C++ compiler I've used on UNIX systems is painfully slow at optimizing template code.
Is this not true under Windows? I'm curious, as they should have many of the same problems. Optimizing template code is expensive because there is a lot of it and most of it is inlined. Inlining is not as trivial one might initially expect and it has large implications for transformation (optimization). Inlining usually greatly expands the size and scope of functions that are transformed. There are more nodes, more symbols and more analysis bookkeeping to handle. Many compiler algorithms have complexity of N^2 or worse (lots are NP-complete!) so things get dicey as code size expands. Strangely enough, this is also why transformation can speed up compilation -- it often removes nodes and symbols from the program!
But the RIAA isn't moving to a new business model. That's part of my point. We only remember the good/long lasting/important musicians because for some reason what they did affected a large part of the population (at the time) in some way. There are countless musicians who were widely promoted for a short time and then dropped into the abyss. There is nothing new here.
How many of us can honestly say we understand the importance of 1920's jazz musicians? How about the ragtimers and shout pianists of the 1910's? Certainly these were very popular people who defined music for a generation. Who here knows the names of the composer and lyricist for Charleston? I do, but only because one of my hobbies is studying music from that era. This tune in particular was promoted with great abandon, to the point where the composer lamented his reputation as a pop tunesmith. The song has a certain meaning to folks of that generation, though most from this one could care less, just as most a generation from now won't really care who the Eagles were. One could argue that's already the case.
Of course things have changed a bit with Napster and digital music, but not that much, really. Recoding devices have been around for a long time and the RIAA seems to be doing fine. One could argue that it is more difficult to share physical media than bits, but only a little more. Used record stores have been around forever, as has radio.
Absolutely. I think any sort of scoring system is hopelessly inadequate. Music by its nature is abstract -- impossible to quantify. Which bands are "important" depends more on a particular persons tastes than it does on number of albums sold, etc. Some of the most musically influential artists have quite small discographies with modest sales numbers. Some of the multi-platinum artists listed in the study will be considered irrelevant by some listeners.
It might be more interesting to look at the history of music promotion as a whole -- find the top promoted acts/albums/songs each year and look at how long they stick around in terms of sales/radio time, etc. Longevity and sales will be biased toward early publishers but perhaps radio time tends toward newer releases.
We might also be able to reasonably agree on truly monumental artists or albums -- those that the general population agrees are significant. This will be a quite small group, I think, but I wonder how these acts were promoted. I'll bet they're some of the top-promoted artists of all time. Such a result would take away from the study's conclusion that the industry's heavy promotion of a limited number of acts means that none of those acts will have any staying power. I just don't buy it.
As an interesting twist, we can look at the same sorts of numbers from the perspective of the artists -- the acts they think are the most important. I think we'd get some wide differences from the general population.
To be truly accurate we ought to look at this over the entire history of recording and perhaps even back to the sheet music publishing business.
My own taste is predjudiced toward classic jazz. It is interesting that in the jazz community, it's been generally true that commercially successful artists are considered inferior musicians. I've never quite been able to figure out why, but the trend goes back almost to the roots of the music. It seems the same is happening in the rock/pop world. I see a sharp parallel between the break from swing to beebop (where jazz lost its general popularity and the vilification of classic/popular artists by "real" jazz elites became more apparent) and the break from rock (classic/metal/alternative) to pop (Britney, 'N Sync, etc.) where the pop artists are equally vilified by the l33t death metalers.
Perhaps this latest break occurred much earlier, as indeed it seems to occur at every generation (I used pop as a label deliberately). It's not unlike the raging debates between Windows/Linux and Linux/BSD. There's always a crowd deriding the popular group of the day.
Promotion has become more important than quality. OK, well the study does tell us (me anyway) that this has been a long term trend, rather than my previous (unsupported ) feeling that it has only ocurred over the past decade, it appears to have extended over the past two deades, and perhaps a bit further back.
Hell, the recording industry's need to push mediocre music on a mass audience has existed almost since the inception of the technology! Even before that, sheet music was big business and the same strategies ruled.
Listen to some of the old jazz (for example) recordings. Not the famous Louis Armstrong and Duke Ellington sides, but the non-famous ones. Many highly-respected artists were forced to record the trite "song-of-the-day" for the studios.
This "promote-at-all-costs" attitude was a major contributing factor in the death of Fats Waller and probably many other artists with whom I am less familiar. Certainly it contributed to the depression and retreat to drugs of many a rock-'n'-roller. If anything, the study doesn't go far enough back into history to trace the trends.
Slashdot Mirror
While I agree in general that MS puts out lots of good software and does excellent research, I couldn't let this go:
This is completely untrue for any serious technical documentation. Figures and bulleted/numbered lists top my worst experiences in Word. Excel's data point limit has more than once forced me over to gnuplot.
Office is great for the vast majority of users: business types, one-off letters, etc. It is completely insufficient for anything of substantial size or complexity. LaTeX or Frame wins hands down.
--
void drawAll(const shapeList &shapes)
{
for(shapeList::const_iterator i = shapes.begin();
i != shapes.end();
++i) {
(*i)->draw();
}
}
All we have here is a list of pointers to Shape. Each object could be a Circle, Rectangle, etc. The drawAll code doesn't care. All it knows is that it has to draw everything. This nicely separates the high-level "draw everything" interface from the individual details of how to draw each shape. A good way to look at it is that the C++ virtual function mechanism has replaced the traditional C tagged union and switch construct. That's a lot of code to save. :)
Projects like Linux would really benefit from this. Every time a C++ programmer sees and if-else tree or a switch, she instantly thinks virtual functions and wonders why anyone would go to all the trouble. :)
The UNIX file system is OO in this sense. The user redirects from or to device nodes (i.e. to do audio recording or playback). He doesn't care what type of device it is or even that it is a device. All he knows is that this file causes neet things to happen. Too bad it's not implemented in an OO language in Linux :(
As for minimalist, C++ can do that too. Not only does it generate "as good as C" code for equivalent functionality, it reduces source code size as well. Getting this benefit sometimes requires a bit more overhead than C (i.e. declaring classes, etc.) but in the long run it is a real win. Not to mention the outstanding standard library which saves hours of drudgery.
Of course OO is not needed in every project or even many of them. That is why C++ is so nice to use. We pick the tool that appropriate to the task out of the many provided by the language. Once can write perfectly good advanced C++ code without using inheritence or polymorphism. In fact the cutting edge today seems to involve heavy use of generic programming and metprogramming -- inheritence is only used when necessary.
--
Hoo boy...
This is certainly true. C++ compilers are hard to write. So are C compilers.
Please back up this statement. It maps no worse than C does, given code with the same functionality.
Careful with those absolutes. I don't know what you mean by "more than one object," but I can show you C++ code using standard library constructs that runs much faster than functionally-equivalent C code, even when the C code uses custom implementations tuned to particular data types.
C++ is not, not, not slow.
This is just plain wrong. As with any language there are multiple entries in the solution space for a given problem. Choose the one to use the least amount of X. In the end you can always resort to "C with classes" if you must (which you shouldn't).
As is the case with any language.
--
You're right that OO is not needed to do magnificent things, but you're wrong that Linux is not OO. It's not explicitly OO in the sense of the language or programming style used in its implementation, but the whole concept of UNIX itself is based on OO principles. The "everything is a file" idea sounds suspiciously like the OO "isa" relationship (A isa B).
Just today I was reading the LWN kernel page, where 64-bit DMA interfaces are discussed. To support 64-bit DMA a new datatype will be declared along with a bunch of new interfaces probably looking very similar to the current 32-bit interfaces. In addition, various devices will require different kinds of DMA transactions based on the type of device and/or the host system configuration. Sounds OO to me.
Well of course, since in the end it's all machine code anyway. :)
I am concerned about the statement that OO is not important. It's not magic pixie dust, but it helps solve real world problems very well. It's an important tool in the programmer's belt. Yes, it's "merely" a style but style is what makes art art. And make no mistake, program design and implementation is an art as much as it is a science.
--
Where's the FUD? Many Linux users don't use Slack. That's not in debate. It's obviously not right for them. Or are you objecting to the colloquial use of "works?"
I know how Slack packages work. Used 'em for many years. I was responding directly to a comment that having to manually configure packages (X in this case) is good and indirectly to a (common, IME) belief among Slackware users that compiling from source is a necessary task for good system maintenance. You're right, I was a little sloppy with my wording.
Well, I was being a bit facetious there, but only a little. It takes some insight and courage to realize that sometimes the easy way is not a cop-out. It's the same reason that NIH is so looked down upon.
How, presently, do package managers hide information? I agree they can, but I can't think of a single instance where they do. Note that I'm coming from a Debian perspective and YMMV for other distributions or operating systems.
First off, no one is a "clueless git." They may not be interested or may not have the background you and I do, but they almost certainly have a clue in areas where you and I will be lost. Sorry, this sort of talk really grates on me.
Now how could someone new to Linux/UNIX possibly ruin it for you? At worst a nice hacker writes a useful interface for that person. No reason you have to use it. Yes, you could argue about open relays or some such thing, but that sort of thing has been going forever, even before UNIX became less macho. Either it happens in closed/unfixable Windows or it happens in Linux. I'd rather it happened in Linux, and making Linux friendly is the only way to accomplish that.
--
For kernels, this is pretty much the standard practice in Debian. In fact there's a nice make-kpkg tool that converts a generic kernel source tree into a Debian package, configured to your liking and ready to install. It even runs LILO for you so you don't forget. :)
--
True, this is a maintainer problem. The package in this case is buggy and needs to be fixed. Packages should only specify the bare minumum of dependecies. That's why we have dependencies like "glibc >= 2.0."
Making every administrator specify dependencies is not the answer, though. Perhaps some way of incrementally modifying the dependecy structure of a package would be useful. Think "free software" for packages, but in a more automated fashion. As people learn what additional versions of things the package works with, they can be added to the specification.
--
You are absolutely correct. Debian supports this in a primitive way with the "provides" field.
--
The problem there is mixing packages from two independent, non-cooperating vendors, not packaging per se.
No, the problem is that these systems hide what is going on and make it impossible to fix when problems occur. I don't want to think when doing something as mundane as upgrading software. Gads, I have too many other thing to think about!
Packaging systems in no way prevent that.
They're making the call because it's not convenient to RTFM. One of the really nice things about Debian is /usr[/share]/doc. Nothing in Slackware would prevent these sorts of call. You'll just get them about configuring X or running ./configure && make && make install.
Of course its good to know this. It's even better if it can be automated and the knowledge kept in a nicely-organized system.
--
Note that I mentioned vendors leaving the CLI as the sole user experience. I do not underestimate the power and user-friendliness of the CLI. It's an absolutely crucial element of a user interface.
My response was more to the point of some UNIX advocates thinking that to be a real UNIX Guru one has to work solely at the CLI, or configure Sendmail by hand or some other ridiculous notion. The hostility toward graphical mailers/editors/wizards is a perfect example. Not all of these things are right for me because I am more familiar with other tools. But that doesn't mean the ideas are wrong.
I agree that it's fun to rummage around a system, find out how things work, etc. It's part of the learning process. Forcing this process on people who aren't interested is a bad idea.
If Slack works for you, great. It may not in the future and it certainly doesn't for many Linux users. If some time in the future you become tired of manually configuring and building packages, you won't be "giving up" or "sacrificing your UNIX-ness" by moving to another distribution. You'll just be ackowledging that changes come through time how open-minded and forward-thinking you are. :)
--
--
Eh? This makes no sense at all. Why reproduce very hard work millions of times. Let one person intimately familiar with the software do it and validate the results. Yes, there will be bugs. That's why we do testing. With your strategy those bugs will be repeated millions of times and will be more frequent because there's no way an administration team can keep track of the dependecies of an entire system.
What did you find rigid about Debian?
Ah, now I understand your viewpoint. I vigorously disagree with it, but I understand it. :)
Living in the past is certainly fun and educational but it also has a tendency to close our minds to new ideas. This is not a personal criticism. I've heard this view expressed too many times in too many different contexts to be able to ignore it. Hell, I'm guilty of it myself (check the .sig).
--
There's nothing "UNIX" about "hard to use!" Does no one remember why UNIX came about? It was a simplification of MULTICS, both in the kernel and in user space. The "everything is a file" paradigm was developed for the user. UNIX != unfriendly and there is no reason something has to be held back in the Dark Ages of the CLI to be UNIX. UNIX system vedors left the CLI as the sole interface years ago.
UNIX == user friendly. Unfortunately, most of us still haven't realized it and cling to some overblown nostalgic view of the "good old days."
As for your unfortunate Red Hat experience, it was my experience around Red Hat 5.0 that the packages just weren't well-maintained. I switched to Debian and never looked back. Don't judge a concept by its implementation.
You can't be serious. The only thing worse would be a non-working sendmail.
I agree that Slack is a great way to get under the hood and learn a few things. I'd encourage anyone interested in Linux beyond day-to-day use to install Slack and have a go at maintaining it. But to get work done, go with a package-managed distribution.
--
Don't underestimate the importance of Slackware in this role. I view it as critical.
--
I don't follow you. What's not UNIX-like about Red Hat, Debian or any other server/workstation distribution of Linux? Perhaps you meant "BSD based?"
One can examine and unpack .debs with standard tools. Please see here. Yes, .deb is missing some functionality. But it does more and is more "cross platform" than most people realize.
I'd argue that Debian is more source-friendly than Slackware because source packages are an integrated part of the distribution. That's a big part of what makes Debian Debian. Source is available for anything and it is trivial to download, build and install any package from source. The "build depends" field in .deb means that there shouldn't ever be a problem getting all the tools necessary to build it. Those complaining that Debian releases too slowly (they do, but it's for a good reason) can always build unstable source packages for their stable distribution. I don't think it's guaranteed to always work due to build-depends (tools from unstable may be needed), but it should work most of the time.
With alien, I've had no trouble installing RPMs. I've never tried a .tgz, but I can't imagine it would be all that much different.
No it isn't a wonder that more people don't use it. I'll agree with you that it's not a wonder it hasn't died. It will be around as long as it's useful to someone and with millions of people using Linux, the odds are pretty high that this will be the case for some time.
Many people don't use it because they've realized that Debian provides everything Slackware does plus a lot more. I consider it the modern version of the great Slackware that saved us from SLS back in its heyday.
Other people don't use it because they just don't care about building from source and use Red Hat or some other binary-focused distribution. Honestly, what's the difference between downloading source, compiling and installing and installing a binary package? It certainly isn't any more secure. It's only more work and takes time people could use to actually get something useful done.
--
Exactly right.
Corel and Progeny are both based on Debian, use the .deb package format and have no problems interacting with "official" Debian packages. I think this is a testament to the design of the distribution. I'm not sure how cross-polination between Progeny and Corel works. I doubt they include dependecies or conflicts between each other.
The iPAQ Familiar distribution uses the .ipkg format which is .deb repackaged using tar instead of ar so that ar doesn't have to be installed. So Debian-proper packages are out.
The Intimate iPAQ distribution is Familiar using full-blown .debs. Adding Debian-proper packages is no problem.
Finally, there's emdebian, another ARM-based handheld distribution. It's not too far along, though.
So Debian does indeed have several derivatives, most using the original package format and having no problem mixing Debian packages and its own repackaged software.
--
I figured as much. Recently there was a discussion on comp.std.c++ on the STL's map interface. While not directly related to your concerns, I did get into an argument with Bjarne over the amount of time/money spent in trying to understand the standard library when a few simple changes could make life much easier for the average programmer. His viewpoint is that one must keep up with the latest techniques. I agree to a point, but understand the realistic situation you've outlined above, where not all members of the team can afford to live on the bleeding edge.
IMHO one of the larger problems is the lack of adequate tools to analyze and debug C++ code. Using gdb is a nightmare with g++ and as you indicated, it is incredibly difficult to debug template metaprograms. At least some people (e.g. Jeremy Siek) are working on techiques to improve compiler error messages (concept checks)!
--
That is very nice. It will allow better separation of interface and implementation.
I'm curious as to why you say this. Is it the amount of inlined code or the fact that it's something akin to magic? :)
--
I did try my hand at some metaprogramming which used a bit of partial specialization. I was using (I think) 2.90.blah and it failed miserably. But that compiler was so old and buggy I'm sure it would work much better now.
--
Right. This is the "control file" method I mentioned. IIRC, Cfront didn't implement this in a completely automatic way, though compilers that use this model have cleaned it up.
The overhead is not only in the bookeeping. The overhead is also in generating the instantiations. To do this the compiler has to re-parse the source and generate code (either by recompiling the entire object file all over again or placing just the generated template code in a separate object). Some implementations could avoid this by generating some sort of targeted template code (a la DyC or other runtime compilers), but I don't know of any implementation that does this. It's tough to know which dominates. It probably depends on how "integrated" the prelinker is (i.e. does it rely on external programs to analyze object files?).
Whoops! Yes, of course you are correct. This is a different model from the prelinker method. It does have the drawback of generating the same code over and over again, though it only has to parse each source file once.
I seem to recall that collect2 is only used on ELF systems. How does instantiation work for other object types? I do recall, in the early days of EGCS, a repository (.rpo) notion that never quite worked for me. Has this been implemented correctly now? I didn't see much about how this all works in the 2.95.2 info files.
It could be parsing speed, but that seems unlikely. It probably depends on how the other compilers implement "recompilation." There's a large design space trading off complexity and speed. Then again, maybe the prelinker bookkeeping really is expensive. I haven't seen any good numbers.
This is an excellent point. The SGI STL is pretty braindead in terms of implementation. I'm very interested to see the fruits of Andrei Alexandrescu's YASTLI (Yet Another STL Implementation) project. His plan (documented on comp.lang.c++.moderated) is to implement the STL (hopefully all of the standard library eventually) using all of the modern design techniques (policies, traits, metaprogramming, typelists, etc.) to create a super-efficient version of the library. No compromises will be made for non-standard compilers, so it will be a good conformance test. g++ should do well in that regard.
For those interested, his book Modern C++ Design gives some clues on what he's thinking. It's an excellent read and I highly recommend it for anyone interested in some of the latest C++ design techniques, especially concerning templates.
--
I'm greatly anticipating the new C++ library. Finally we will have stringstream! For me the C++ library was the largest hole in the C++ implementation. The compiler itself has been quite good for some time, feature-wise.
--
This is not a bad thing. In fact, it is a very valid (I'd say good!) design decision. Explanation below.
The reason explicit instantiation is so much faster is that the compiler doesn't have to compile your code twice. Automatic template instantiation requires some sort of support outside the compiler proper. For all the gory details, I recommend Stan Lippman's Inside the C++ Object Model. It's a little out of date and inaccurate (or more properly, misleading) at times, but for anyone interested in why C++ works the way it does and what sort of decisions the compiler makes when generating code, it's a great book. It dispels many of the common myths about C++'s performance and makes an honest evaluation of the cases where performance is negatively affected.
But I digress. One of the most popular strategies for automatic template instantiation involves some sort of "collector" program. The basic idea is to collect all the object files that go into the final link and look for undefined symbols that refer to template code. The GNU collect2 program does this for g++. Once the symbols have been identified, the compiler needs some way of knowing how to recompile the source files that contain the template elements. Strategies include using control files generated by the compiler and collector, entries in the object files themselves (strings or symbols are common) or a combination of the two. Other strategies are possible as well. The driver script (the IDE in VC++) gathers this information and reinvokes the compiler to recompile the source files containing the needed template code, passing flags to tell the compiler to instantiate particular templates.
After having implemented some of this, I have to tell you that it is all a tremendous pain in the neck. It's also quite, quite convenient and necessary for the user. :)
As for the MS IDE, that's just another strategy for handling the problem. No compiler that I know of fully handles automatic template instantiation by itself. The closest that a compiler could come to this would be to aggregate the collector actions into the compiler as a separate phase. This is really no different that running a separate program and the "compiler" becomes the driver script (think g++), with the compiler proper (i.e. translation and transformation) being but one (usually, more than one) phase of compilation.
Is this not true under Windows? I'm curious, as they should have many of the same problems. Optimizing template code is expensive because there is a lot of it and most of it is inlined. Inlining is not as trivial one might initially expect and it has large implications for transformation (optimization). Inlining usually greatly expands the size and scope of functions that are transformed. There are more nodes, more symbols and more analysis bookkeeping to handle. Many compiler algorithms have complexity of N^2 or worse (lots are NP-complete!) so things get dicey as code size expands. Strangely enough, this is also why transformation can speed up compilation -- it often removes nodes and symbols from the program!
--
How many of us can honestly say we understand the importance of 1920's jazz musicians? How about the ragtimers and shout pianists of the 1910's? Certainly these were very popular people who defined music for a generation. Who here knows the names of the composer and lyricist for Charleston? I do, but only because one of my hobbies is studying music from that era. This tune in particular was promoted with great abandon, to the point where the composer lamented his reputation as a pop tunesmith. The song has a certain meaning to folks of that generation, though most from this one could care less, just as most a generation from now won't really care who the Eagles were. One could argue that's already the case.
Of course things have changed a bit with Napster and digital music, but not that much, really. Recoding devices have been around for a long time and the RIAA seems to be doing fine. One could argue that it is more difficult to share physical media than bits, but only a little more. Used record stores have been around forever, as has radio.
--
It might be more interesting to look at the history of music promotion as a whole -- find the top promoted acts/albums/songs each year and look at how long they stick around in terms of sales/radio time, etc. Longevity and sales will be biased toward early publishers but perhaps radio time tends toward newer releases.
We might also be able to reasonably agree on truly monumental artists or albums -- those that the general population agrees are significant. This will be a quite small group, I think, but I wonder how these acts were promoted. I'll bet they're some of the top-promoted artists of all time. Such a result would take away from the study's conclusion that the industry's heavy promotion of a limited number of acts means that none of those acts will have any staying power. I just don't buy it.
As an interesting twist, we can look at the same sorts of numbers from the perspective of the artists -- the acts they think are the most important. I think we'd get some wide differences from the general population.
To be truly accurate we ought to look at this over the entire history of recording and perhaps even back to the sheet music publishing business.
My own taste is predjudiced toward classic jazz. It is interesting that in the jazz community, it's been generally true that commercially successful artists are considered inferior musicians. I've never quite been able to figure out why, but the trend goes back almost to the roots of the music. It seems the same is happening in the rock/pop world. I see a sharp parallel between the break from swing to beebop (where jazz lost its general popularity and the vilification of classic/popular artists by "real" jazz elites became more apparent) and the break from rock (classic/metal/alternative) to pop (Britney, 'N Sync, etc.) where the pop artists are equally vilified by the l33t death metalers.
Perhaps this latest break occurred much earlier, as indeed it seems to occur at every generation (I used pop as a label deliberately). It's not unlike the raging debates between Windows/Linux and Linux/BSD. There's always a crowd deriding the popular group of the day.
--
Listen to some of the old jazz (for example) recordings. Not the famous Louis Armstrong and Duke Ellington sides, but the non-famous ones. Many highly-respected artists were forced to record the trite "song-of-the-day" for the studios.
This "promote-at-all-costs" attitude was a major contributing factor in the death of Fats Waller and probably many other artists with whom I am less familiar. Certainly it contributed to the depression and retreat to drugs of many a rock-'n'-roller. If anything, the study doesn't go far enough back into history to trace the trends.
--