Would be storing/usr/portage in a huge.zip file. There are 121537 files in portage on my system and that constitutes a massive overhead on the filesystem and degrades the performance. And when updating it tends to scatter lots of little tiny files all over the disk, making performance even worse. With Reiser 4 is literally takes 6+ seconds to rebalance the filesystem tree, which happens ever so often.
It should be simple in python to just replace file.open to first look in/usr/portage for an actual file and then in/usr/portage.zip for the official sync version. So you would still get the benefits of being able to tweak individual files without the drawbacks of 100k+ files. It should use zip instead of tar since zip files are random access. Even uncompressed the zip file is a massive improvement.
I had to do this recently, but to print a 20-page document as 12 pages by removing page breaks. I found that kword using the html export filter and setting it to "HTMl 4.01 + Light (strict xhtml)" was the best mode. This doesn't use the style sheets and just converts to basic html.... no fancy positioning or fonts, just some headers and basic styles. This was using kwork 1.4.1 / kde 3.4.2 btw.
Everything else I tried sucked, including OO.o's export.
Typically the CPU performance penalty from running vmware 4 is about 5%. With vmware 5 it seems to be even less. If you look at the performance comparison on Xen's site you'll see essentially no difference on CPU time. The vmware they tested had problems with network and file IO, but that's two major versions ago (because of draconian vmware license against publishing benchmarks). Now vmware machines run in kernel mode (at least on linux) and have much faster IO and network, comparable to native and xen.
And with vmware 5 you can make clones of the machines that are basically live diff's. So you can test 100 different variations of different patch levels and whatnot and use 100 mb of space instead of 100 gb. I mean sure there are reasons to use Xen over vmware, but vmware is still an awesome software. It's like photoshop, where if you have a need for what it does it's basically the only choice and well worth the high price.
So while separation seems like the 'correct' choice, it doesn't buy you much in the end and adds lots of complexity to the OS... vmware is complex but it is basically a black box. It's like the difference between O(os*jails) vs O(os+vmware).
Even with the native machine code plug-in, QEMU runs code something like 1/5th the speed of normal. In short it does not compete at all. I suppose qemu and bochs would be pretty nice for capturing audio from those DRM stores though =P
Hey, as long as you feel good about putting newspaper into the recycle bin, who cares that it produces more pollution to turn it back into quality paper than it would to plant a tree and harvest it? It's all about feeling good, isn't it?
No, it's all about not being a phracking moron.
Never do any research and find out that the #1 pollution from paper is from bleaching the pulp, which you have to do far less of with recycled. Never mind that each aluminum can recycled saves about the equivalent of 6 oz of gasoline in energy cost. Never mind us researching fuel cells for 40 years then ceding the market to Japan, Germany, and Canada because we are too stupid to even continue funding at existing levels.
You seem to think that unbridled capitalism will produce the most efficient result. That's mostly true, yet capitalism doesn't care if it uses all the resources in the world and then what's left of us after a crash lives in a few underground bunkers or habitats. That's called a market correction. We can pay more for food and energy now to lessen it or we can get snapped back to ensign so fast our heads will still be spinning in our mass graves.
That's basic Global Econ 101. Some people are just too stupid or short-sighted to understand the consequences of rampant capitalism.
IMO a better solution is to just delay changes for a while. Have the main page shown for each article be one that is 1+ hours out of date from the current page (when you go to edit it takes you to the most up-to-date page).
So in order to vandalize, the changes would have to survive a 'burn in' period where those people watching the article have a chance to cancel it before everybody sees it on the main page. This takes away the primary motivation for vandalism since nobody sees the change except to revert it. Currently people make rapid changes and keep hacking the articles day after day because they think somebody sees it, even for the several minutes or less before it is reverted. This incentive would be gone with a time-delayed scheme.
When you get to the point in your life where your time is more valuable than the entertainment/social value you get from the game, you stop playing. That's why young people play games and old people do not: the older you get the less time you have to waste.
Doxygen and javadoc provide a consistent way to document the code inside the source. Sure, you get comments that include no-brainers like "@param size, the size" but even these add some value by reinforcing the comment structure. So when I see code commented with doxygen or javadoc I can skip the step of parsing the documentation format and go straight to what it says. It doesn't sound like much, but when you look at the Java API for instance, all of it follows the same basic format: summary sentence, description, parameters, return value, and those people who have experienced it know it really helps having that consistency.
Some other posters have diss'd doxygen comments because they say what but now how, or something like that... what does woggle do and when do I need to use it? Is the returned wobble a new one or an old one with ref++. But that's not a problem with doxygen or javadoc, but with the language you are commenting (ie C): there's no good place to comment on these things in-line. In Java the class comment tells you when you would use it and what the basic function the whole thing does. The method comments tell you if it's some shared reference and what algorithm is used (if appropriate). But in C you just have functions... there's no cohesive whole to explain the higher-level ideas you might want to document, so the result is you get comments on individual functions that don't tell you what you want to know and are either too low-level or too high-level.
But both doxygen and javadoc are the single best way you can document code. Documentation outside the code is for chumps... seriously. If your code is not organized well enough that you can write meaningful comments -- high and low level -- within it then you design sucks. And what's the use of writing great external documentation for a piece of poo?
Then what's to stop the poaching company from just buying the information off the guy while he is working for the competition?. Oh yeah... that's why they also put in the contract that you can't give out that kind of non-public information, to protect against that.
Really the non-compete has nothing to do with protecting the company's information, but is entirely directed instead at harming the competition by taking away a potential resource and lowering wages by effectively limiting the demand for your work.
This is a good reason why NOT to support *BSD and other non-gpl open-source software. Don't use it and don't contribute to it, because any company could take a BSD and add the so-called trusted computing code to it and close that part. We could be left with companies using our software when we can't even use it on our own computers if we use the BSD license! With GPLed software if they add a private key to make it boot/run with a bios then they have to publish the private key and then anybody can recompile the OS to do whatever they want.
I think this is a very bad sign for Sun, because it sound to me like IBM hedging its bets for what might happen if Sun is bought out or sells Java. IBM's java virtual machine is based on Sun code, so if Sun sells the rights to Java then IBM is beholden to somebody else (maybe even Microsoft, who would buy Sun just to finally kill Java). As sad as it is to say, I think IBM sees the writing on the wall that Sun just doesn't seem like the reliable bet these days.
A lot of research has gone into mitigating these issues (with Sun producing some very impressive results!), but it doesn't change the fact that the machine and software are mismatched.
This was talking about Java/.NET, but it's not the machine and safe, object-oriented languages that are mismatches... it's a mismatch between the operating system and these environments. The machine is well suited to these languages like Java or C#.
For example, a properly-matched OS can use page faults to speed up the garbage collector: all allocations are in a 'new' area and when that fills up only pages written to need to be searched for references to the new objects. So allocations are literally a pointer increment, and de-allocations are a factor of how much memory was changed... so "while (true) { new Point(0,0); }" woudl run an order of magnitude faster than any C++ based version. Allocations on the stack become irrelevant for performance.
Also imagine if in all the idle time your applications were being primed for responsiveness. All the live objects can be compacted in memory to free up holes from fragmentation. This can happen during IO so that there is less latency since while waiting the application can be primed so any allocations it has to do are instant (for example when parsing xml into objects).
You can have non-copying IO without the massive complexity of mmap. You can have nanosecond task switches. System calls as normal method calls instead of 1000-cycle-long interrupts.
The problem with Java, C#, etc is not the hardware, it's the operating system. And the problem is they are all built to run C and assembly programs, which nobody in their right mind would touch for the vast majority of programs these days.
The problem with that is that if the massive companies want this DRM badly enough they will subsidize monitors that support it. So you can get a DRM monitor for 1/2 the price of a 'free' monitor who is going to buy the more expensive one?
$20 billion can subsidize a lot of DRM monitors and other hardware, especially when augmented with exclusive Microsoft Music Store licensing and other kickbacks.
Ultimately hardware options are not a solution pirates can use, since watermarking could easily identify which person freed some content from DRM. The number of people capable of freeing content is directly proportional to the ease in identifying them (and thus shutting them down).
The big problem in terms of maintaining freedom over your own computer is the BIOS. Nowadays it is compressed and encrypted, so if one day it started refusing to load non-authorised operating systems you could easily have a situation where only longhoard would load, it wouldn't let you load drivers or even read the decoding software instructions to simulate it, etc. So that's the key piece, since if that goes DRM-only then the only options are to a) hack the os or b) emulate the entire computer. But to do (b) you'll have to read keys, etc from hardware which can be made extremely difficult.
Of course hacking longhoard will be easy, for now, but ultimately that's a losing proposition. So people with the skill and that care should contribute to the open bios project.
Microsoft will be creating MORE opportunities for services and products that can't really exist without their technology.
Well really Microsoft will be creating an market for some services by artificially limiting what people can do with their computers. And if you really believe that is a good thing, what other artificially created markets have ultimately been beneficial to the people?
Basically, the premise behind DRM is that some content can't exist on its own so they are going to force conditions on us where it can. What if some company created mechanical legs that were expensive and were awkward, so they went around and hobbled everybody so they would have to buy them to get around? That's what we're talking about here. Sure it creates MORE opportunities... for crap.
But I wouldn't fault C++ for it's complexity; it's design goal is to be as powerful as possible, within that, it should be as simple as possible. Many fault it's complexity, but I've yet to see anything simpler that retains all the power.
Are C++ backers intentionally trying to miss the point? The post was about human factors.
You really have no clue that "::" is a horrible choice of name separator, especially since "." was already used for that purpose? Or that requiring a space in nested templates because writing the BNF for the compiler would be too hard otherwise is a crappy excuse from a human interface POV? Or that requiring google searches for add-on hacks just to get basic functionality from over three decades ago is not 'power to the people'?
"cin >> s, shift right or method call?" Method call....(e.g. if 'cin' in your example isn't a stream.)
Doesn't that just say it all? First you accuse me of being ignorant of C++ but then you assume "cin" must be an io stream because no competent developer would use that name otherwise. So you made an assumption, and based on data you think is wrong to begin with. You did that to mask the fact that in C++ simple statements like "a + b" require a lot of context to know what is really happening.
And this is what I'm talking about: human factors. Bjarne says that "a * b" for matrix multiply and "a <something besides.> b" for dot product is better because it looks like what it does, semantically (except for dot product...). But ultimately that is just saying the code for matrices should look quite pretty. Never mind that b is a string and is converted into a 1xN matrix using an automatic implicit conversion. Oops.
Of course you can nest templates. You just need a space between the ">" charachters. Bjarne is annoyed by this, because he's enough of a purist that he doesn't like having whitespace next to an operator be significant in this one case only. In principle, I agree, in practice, it's no big deal.
Enough of a purist?! You can nest templates like this: "outer<inner<type> >" but not like this: "outer<inner<type>>". That's not an annoyance, it's absolutely moronic from a human design POV. I mean I hate to harp on this since it is just one of many instances of the same poor design, but this what really irritates me about C++... there's just so much bullshit nonsense in it.
Surely separate interface and inplementation files are a good thing?! Isn't it good OO design practise to keep a definition away from the grubby internals. I mean, that's why you actually have interface types in Java that cannot contain code, or enjoy implemetation inheritance.
Way to miss the point, dude. Dot-h files are an anachronism. They don't provide anything useful except a kludge so other source files will compile against a type without re-compiling everything for each file. Java doesn't need dot-h files; the api is viewable in JavaDoc and other ways.
I once worked with someone who was tasked with adding a new entry to something, and each entry was masked with a bitmask.. so we had #define A 1, #define B 2, #define C 4... and he quite rightly tagged a new one on the end.. #define D 5. A little knowledge of how computers work would have saved us some trouble there
Nice, you defined a bitset in DECIMAL?! N00b. Quick, what's bit 22 in decimal? Define them (1<<bit) or in hex. But you choose C++ because you are such a competent programmer huh? More likely you choose it so you can blame things on co-workers or that "programming is hard"
and besides, what is the difference between add() and operator+() except how the programmer types it?
What does "i + j" do? In Java there are fewer possiblities than C even. In C++ you have no way to know without looking at the implementation of both types, and looking for global type conversions. So basically you have to know the entire codebase to be certain; the "magic" factor of scripting languages combined with the exactness required for C.
First of all, there is no MethodNotSupported... it's either NoSuchMethod (linking to different class version than compiled against) or UnsupportedOperation, mostly used in the Collections hierarchy.
In any case, for Collections the reasons why they didn't have separate type are clearly documented by Sun, and it makes sense. Basically, you get a massive class hierarchy of collections that are immutable, unmodifiable, synchronized, and modifiable. Not to mention collections that can be added to but not removed from and vice versa, or lists that are a fixed size (only support set/get).
The fact is that the Liskov Substitution Principle is a good guideline, but it's not a Law of good OO design. And if you think Java is bad, just consider value types. When you assign a subclass instance to a variable of a parent class, any extra state is lost. A simple assignment changes an object's type! That should pretty well destroy any regard you might have for C++ or Eiffel (or probably C# as well) if you think UnsupportedOperation is such a huge problem for java. Of course, it turns out to be fairly practical even though it is about the most anti-OO concept there is.
Java does not remove a few warts from C++, it forces you to use a Garbage collector, OO design, type introspection, etc, etc. Those are pretty fundamental changes.
What, like it can't do both? The problem with C++ is that is was built with focus purely on technology and seemingly without any effort to human factors at all. I mean come on, "::" to separate class from method name, pure virtual destructors, separate interface and implementation files, can't nest templates because >> is a token, references *and* pointers, no garbage collector (even optional)? If there had been any thought into human factors whoever came up with these would be burned at the stake.
Java does enforce using a GC, and encourages OO design, and makes C into a safe language (no pointer math and no invalid casts), but that is not why it has been so successful.
The #1 thing it does is make the code do what is says... you can look at Java code and see exactly what is going on with no ambiguity at all. You might not know what some method does, but you know when it's called; with operator overloading it is impossible to know what a C++ code is doing (ie, cin >> s, shift right or method call?).
The #2 thing Java does is have a large, consistent library. People can glance at pretty much any Java code and know a lot about the methods being called do since they are to the standard library.
The #3 thing it does is to remove all of the syntax crap of C++. The syntax in C is somewhat functional and makes some sense (except function pointers). It's clearly something people can stand, and Java adds nothing to this and even removes the -> vs . ambiguity.
Those are the reasons why Java is so successful, not because it forces OO, GC, safety, etc on the programmer. In fact in a lot of areas those are the things slowing its growth.
You may view such things as shortcomings. I view them as power. Power that can be used for good or for ill.
That's true, but sometimes less is more. Java took away a lot of features from C++, like multiple inheritance, templates, structures, etc and the result is a better language. It's the same way in real life a person isn't allowed to do anything they physically could do according to the rules of the Earth Simulator that we run in because it would be chaos that ultimately leads to some byzantine order, like some huge C project gone bad.
People that seem to require strongly-typed languages, to prevent their errors of inattention while they write code. But all these features are unknown to the CPU -- they've all been stripped away in the compiler, and reduced back to the purity of sequential code.
No that's not it at all, it's because they have no use for the power they are missing. The benefits far outweight the costs. If you look at "Frontier House" you see people spending all day doing things that take us seconds, like buying a stick of butter instead of churning it for hours. It's the same with assembly, sure you *could* have it automatically relocate live objects in memory like Java does, but all your code would have to live with a lot of the same restrictions (not xor'ing the next/previous addresses into one to save space, not using non-stack space as a stack, etc). So you often end up with the same thing, but just doing it the *really* hard, slow way.
maintainability and enhanceability, at least, are entirely dependent on the quality of the programmer
Change a constant in Java and if it is going to break something more often than not you get an error telling you exactly where the problem was and what the call stack was. In C it's not so unusual that you can't even get the call stack (with gdb) because it has been trashed, leading to a long process of stepping through various functions one line at a time.
In Java when you know a lot more for certain. If you have a reference to an object you know what types it could be, that it has been initialized by a constructor, that it isn't simultaneously co-located with other objects, etc. In C/C++ you don't, so when things go bad (because of a lame developer or code rot or whatever) they can go much worse. Somebody casts a char *buf returned from gets into a Config object with the comment 'read config from stdin'. And it works, kinda...
The reason why there is a obfuscated C contest is because C code doesn't even have to look like what it does. Obfuscated Java looks like what it does, so you just have to follow the steps not figure out what those steps are. Java is like a tide that raises all boats for maintainability and enhanceability, even the crappy ones, where C is like an anchor always trying to drag the project down into the depths.
If you care about startup time, use gcj and get the startup time of C code.
And I don't get it how people can say they "care about memory usage" so Java is out. Memory allocation in Java is one pointer increment. Big-Oh of one instruction. In almost all cases C is worse for heap allocation, in performance and space efficiency (since it cannot move allocations that are in use to compact them). C wins on stack-based variables and large arrays. Which one has better memory usage depends on the software you are writing.
When I watch one of those crime shows on tv and the officer says "anything you say can be held against you in a court of law" I used to think then meant starting from now. I guess it's really more of just a fyi kinda thing.
Slashdot Mirror
Would be storing /usr/portage in a huge .zip file. There are 121537 files in portage on my system and that constitutes a massive overhead on the filesystem and degrades the performance. And when updating it tends to scatter lots of little tiny files all over the disk, making performance even worse. With Reiser 4 is literally takes 6+ seconds to rebalance the filesystem tree, which happens ever so often.
/usr/portage for an actual file and then in /usr/portage.zip for the official sync version. So you would still get the benefits of being able to tweak individual files without the drawbacks of 100k+ files. It should use zip instead of tar since zip files are random access. Even uncompressed the zip file is a massive improvement.
It should be simple in python to just replace file.open to first look in
So basically:
.doc into html ...
1. Hire intern to transcribe work
2. Outsource html transcription job to india
4. Profit!!
I had to do this recently, but to print a 20-page document as 12 pages by removing page breaks. I found that kword using the html export filter and setting it to "HTMl 4.01 + Light (strict xhtml)" was the best mode. This doesn't use the style sheets and just converts to basic html.... no fancy positioning or fonts, just some headers and basic styles. This was using kwork 1.4.1 / kde 3.4.2 btw.
Everything else I tried sucked, including OO.o's export.
Typically the CPU performance penalty from running vmware 4 is about 5%. With vmware 5 it seems to be even less. If you look at the performance comparison on Xen's site you'll see essentially no difference on CPU time. The vmware they tested had problems with network and file IO, but that's two major versions ago (because of draconian vmware license against publishing benchmarks). Now vmware machines run in kernel mode (at least on linux) and have much faster IO and network, comparable to native and xen.
And with vmware 5 you can make clones of the machines that are basically live diff's. So you can test 100 different variations of different patch levels and whatnot and use 100 mb of space instead of 100 gb. I mean sure there are reasons to use Xen over vmware, but vmware is still an awesome software. It's like photoshop, where if you have a need for what it does it's basically the only choice and well worth the high price.
So while separation seems like the 'correct' choice, it doesn't buy you much in the end and adds lots of complexity to the OS... vmware is complex but it is basically a black box. It's like the difference between O(os*jails) vs O(os+vmware).
Even with the native machine code plug-in, QEMU runs code something like 1/5th the speed of normal. In short it does not compete at all. I suppose qemu and bochs would be pretty nice for capturing audio from those DRM stores though =P
No, it's all about not being a phracking moron.
Never do any research and find out that the #1 pollution from paper is from bleaching the pulp, which you have to do far less of with recycled. Never mind that each aluminum can recycled saves about the equivalent of 6 oz of gasoline in energy cost. Never mind us researching fuel cells for 40 years then ceding the market to Japan, Germany, and Canada because we are too stupid to even continue funding at existing levels.
You seem to think that unbridled capitalism will produce the most efficient result. That's mostly true, yet capitalism doesn't care if it uses all the resources in the world and then what's left of us after a crash lives in a few underground bunkers or habitats. That's called a market correction. We can pay more for food and energy now to lessen it or we can get snapped back to ensign so fast our heads will still be spinning in our mass graves.
That's basic Global Econ 101. Some people are just too stupid or short-sighted to understand the consequences of rampant capitalism.
IMO a better solution is to just delay changes for a while. Have the main page shown for each article be one that is 1+ hours out of date from the current page (when you go to edit it takes you to the most up-to-date page).
So in order to vandalize, the changes would have to survive a 'burn in' period where those people watching the article have a chance to cancel it before everybody sees it on the main page. This takes away the primary motivation for vandalism since nobody sees the change except to revert it. Currently people make rapid changes and keep hacking the articles day after day because they think somebody sees it, even for the several minutes or less before it is reverted. This incentive would be gone with a time-delayed scheme.
Games waste time. Games are fun.
When you get to the point in your life where your time is more valuable than the entertainment/social value you get from the game, you stop playing. That's why young people play games and old people do not: the older you get the less time you have to waste.
Doxygen and javadoc provide a consistent way to document the code inside the source. Sure, you get comments that include no-brainers like "@param size, the size" but even these add some value by reinforcing the comment structure. So when I see code commented with doxygen or javadoc I can skip the step of parsing the documentation format and go straight to what it says. It doesn't sound like much, but when you look at the Java API for instance, all of it follows the same basic format: summary sentence, description, parameters, return value, and those people who have experienced it know it really helps having that consistency.
Some other posters have diss'd doxygen comments because they say what but now how, or something like that... what does woggle do and when do I need to use it? Is the returned wobble a new one or an old one with ref++. But that's not a problem with doxygen or javadoc, but with the language you are commenting (ie C): there's no good place to comment on these things in-line. In Java the class comment tells you when you would use it and what the basic function the whole thing does. The method comments tell you if it's some shared reference and what algorithm is used (if appropriate). But in C you just have functions... there's no cohesive whole to explain the higher-level ideas you might want to document, so the result is you get comments on individual functions that don't tell you what you want to know and are either too low-level or too high-level.
But both doxygen and javadoc are the single best way you can document code. Documentation outside the code is for chumps... seriously. If your code is not organized well enough that you can write meaningful comments -- high and low level -- within it then you design sucks. And what's the use of writing great external documentation for a piece of poo?
Then what's to stop the poaching company from just buying the information off the guy while he is working for the competition?. Oh yeah... that's why they also put in the contract that you can't give out that kind of non-public information, to protect against that.
Really the non-compete has nothing to do with protecting the company's information, but is entirely directed instead at harming the competition by taking away a potential resource and lowering wages by effectively limiting the demand for your work.
This is a good reason why NOT to support *BSD and other non-gpl open-source software. Don't use it and don't contribute to it, because any company could take a BSD and add the so-called trusted computing code to it and close that part. We could be left with companies using our software when we can't even use it on our own computers if we use the BSD license! With GPLed software if they add a private key to make it boot/run with a bios then they have to publish the private key and then anybody can recompile the OS to do whatever they want.
Well if there was any truth in advertising they would call their OS:
WinMac X
And the boot screen would be the 'pissing dude' on top of an Apple logo.
I think this is a very bad sign for Sun, because it sound to me like IBM hedging its bets for what might happen if Sun is bought out or sells Java. IBM's java virtual machine is based on Sun code, so if Sun sells the rights to Java then IBM is beholden to somebody else (maybe even Microsoft, who would buy Sun just to finally kill Java). As sad as it is to say, I think IBM sees the writing on the wall that Sun just doesn't seem like the reliable bet these days.
A lot of research has gone into mitigating these issues (with Sun producing some very impressive results!), but it doesn't change the fact that the machine and software are mismatched.
This was talking about Java/.NET, but it's not the machine and safe, object-oriented languages that are mismatches... it's a mismatch between the operating system and these environments. The machine is well suited to these languages like Java or C#.
For example, a properly-matched OS can use page faults to speed up the garbage collector: all allocations are in a 'new' area and when that fills up only pages written to need to be searched for references to the new objects. So allocations are literally a pointer increment, and de-allocations are a factor of how much memory was changed... so "while (true) { new Point(0,0); }" woudl run an order of magnitude faster than any C++ based version. Allocations on the stack become irrelevant for performance.
Also imagine if in all the idle time your applications were being primed for responsiveness. All the live objects can be compacted in memory to free up holes from fragmentation. This can happen during IO so that there is less latency since while waiting the application can be primed so any allocations it has to do are instant (for example when parsing xml into objects).
You can have non-copying IO without the massive complexity of mmap. You can have nanosecond task switches. System calls as normal method calls instead of 1000-cycle-long interrupts.
The problem with Java, C#, etc is not the hardware, it's the operating system. And the problem is they are all built to run C and assembly programs, which nobody in their right mind would touch for the vast majority of programs these days.
The problem with that is that if the massive companies want this DRM badly enough they will subsidize monitors that support it. So you can get a DRM monitor for 1/2 the price of a 'free' monitor who is going to buy the more expensive one?
$20 billion can subsidize a lot of DRM monitors and other hardware, especially when augmented with exclusive Microsoft Music Store licensing and other kickbacks.
Ultimately hardware options are not a solution pirates can use, since watermarking could easily identify which person freed some content from DRM. The number of people capable of freeing content is directly proportional to the ease in identifying them (and thus shutting them down).
The big problem in terms of maintaining freedom over your own computer is the BIOS. Nowadays it is compressed and encrypted, so if one day it started refusing to load non-authorised operating systems you could easily have a situation where only longhoard would load, it wouldn't let you load drivers or even read the decoding software instructions to simulate it, etc. So that's the key piece, since if that goes DRM-only then the only options are to a) hack the os or b) emulate the entire computer. But to do (b) you'll have to read keys, etc from hardware which can be made extremely difficult.
Of course hacking longhoard will be easy, for now, but ultimately that's a losing proposition. So people with the skill and that care should contribute to the open bios project.
Microsoft will be creating MORE opportunities for services and products that can't really exist without their technology.
Well really Microsoft will be creating an market for some services by artificially limiting what people can do with their computers. And if you really believe that is a good thing, what other artificially created markets have ultimately been beneficial to the people?
Basically, the premise behind DRM is that some content can't exist on its own so they are going to force conditions on us where it can. What if some company created mechanical legs that were expensive and were awkward, so they went around and hobbled everybody so they would have to buy them to get around? That's what we're talking about here. Sure it creates MORE opportunities... for crap.
But I wouldn't fault C++ for it's complexity; it's design goal is to be as powerful as possible, within that, it should be as simple as possible. Many fault it's complexity, but I've yet to see anything simpler that retains all the power.
...(e.g. if 'cin' in your example isn't a stream.)
.> b" for dot product is better because it looks like what it does, semantically (except for dot product...). But ultimately that is just saying the code for matrices should look quite pretty. Never mind that b is a string and is converted into a 1xN matrix using an automatic implicit conversion. Oops.
Are C++ backers intentionally trying to miss the point? The post was about human factors.
You really have no clue that "::" is a horrible choice of name separator, especially since "." was already used for that purpose? Or that requiring a space in nested templates because writing the BNF for the compiler would be too hard otherwise is a crappy excuse from a human interface POV? Or that requiring google searches for add-on hacks just to get basic functionality from over three decades ago is not 'power to the people'?
"cin >> s, shift right or method call?"
Method call.
Doesn't that just say it all? First you accuse me of being ignorant of C++ but then you assume "cin" must be an io stream because no competent developer would use that name otherwise. So you made an assumption, and based on data you think is wrong to begin with. You did that to mask the fact that in C++ simple statements like "a + b" require a lot of context to know what is really happening.
And this is what I'm talking about: human factors. Bjarne says that "a * b" for matrix multiply and "a <something besides
Of course you can nest templates. You just need a space between the ">" charachters. Bjarne is annoyed by this, because he's enough of a purist that he doesn't like having whitespace next to an operator be significant in this one case only. In principle, I agree, in practice, it's no big deal.
Enough of a purist?! You can nest templates like this: "outer<inner<type> >" but not like this: "outer<inner<type>>". That's not an annoyance, it's absolutely moronic from a human design POV. I mean I hate to harp on this since it is just one of many instances of the same poor design, but this what really irritates me about C++... there's just so much bullshit nonsense in it.
Surely separate interface and inplementation files are a good thing?! Isn't it good OO design practise to keep a definition away from the grubby internals. I mean, that's why you actually have interface types in Java that cannot contain code, or enjoy implemetation inheritance.
Way to miss the point, dude. Dot-h files are an anachronism. They don't provide anything useful except a kludge so other source files will compile against a type without re-compiling everything for each file. Java doesn't need dot-h files; the api is viewable in JavaDoc and other ways.
I once worked with someone who was tasked with adding a new entry to something, and each entry was masked with a bitmask.. so we had #define A 1, #define B 2, #define C 4... and he quite rightly tagged a new one on the end.. #define D 5. A little knowledge of how computers work would have saved us some trouble there
Nice, you defined a bitset in DECIMAL?! N00b. Quick, what's bit 22 in decimal? Define them (1<<bit) or in hex. But you choose C++ because you are such a competent programmer huh? More likely you choose it so you can blame things on co-workers or that "programming is hard"
and besides, what is the difference between add() and operator+() except how the programmer types it?
What does "i + j" do? In Java there are fewer possiblities than C even. In C++ you have no way to know without looking at the implementation of both types, and looking for global type conversions. So basically you have to know the entire codebase to be certain; the "magic" factor of scripting languages combined with the exactness required for C.
First of all, there is no MethodNotSupported... it's either NoSuchMethod (linking to different class version than compiled against) or UnsupportedOperation, mostly used in the Collections hierarchy.
In any case, for Collections the reasons why they didn't have separate type are clearly documented by Sun, and it makes sense. Basically, you get a massive class hierarchy of collections that are immutable, unmodifiable, synchronized, and modifiable. Not to mention collections that can be added to but not removed from and vice versa, or lists that are a fixed size (only support set/get).
The fact is that the Liskov Substitution Principle is a good guideline, but it's not a Law of good OO design. And if you think Java is bad, just consider value types. When you assign a subclass instance to a variable of a parent class, any extra state is lost. A simple assignment changes an object's type! That should pretty well destroy any regard you might have for C++ or Eiffel (or probably C# as well) if you think UnsupportedOperation is such a huge problem for java. Of course, it turns out to be fairly practical even though it is about the most anti-OO concept there is.
Java does not remove a few warts from C++, it forces you to use a Garbage collector, OO design, type introspection, etc, etc. Those are pretty fundamental changes.
What, like it can't do both? The problem with C++ is that is was built with focus purely on technology and seemingly without any effort to human factors at all. I mean come on, "::" to separate class from method name, pure virtual destructors, separate interface and implementation files, can't nest templates because >> is a token, references *and* pointers, no garbage collector (even optional)? If there had been any thought into human factors whoever came up with these would be burned at the stake.
Java does enforce using a GC, and encourages OO design, and makes C into a safe language (no pointer math and no invalid casts), but that is not why it has been so successful.
The #1 thing it does is make the code do what is says... you can look at Java code and see exactly what is going on with no ambiguity at all. You might not know what some method does, but you know when it's called; with operator overloading it is impossible to know what a C++ code is doing (ie, cin >> s, shift right or method call?).
The #2 thing Java does is have a large, consistent library. People can glance at pretty much any Java code and know a lot about the methods being called do since they are to the standard library.
The #3 thing it does is to remove all of the syntax crap of C++. The syntax in C is somewhat functional and makes some sense (except function pointers). It's clearly something people can stand, and Java adds nothing to this and even removes the -> vs . ambiguity.
Those are the reasons why Java is so successful, not because it forces OO, GC, safety, etc on the programmer. In fact in a lot of areas those are the things slowing its growth.
You may view such things as shortcomings. I view them as power. Power that can be used for good or for ill.
That's true, but sometimes less is more. Java took away a lot of features from C++, like multiple inheritance, templates, structures, etc and the result is a better language. It's the same way in real life a person isn't allowed to do anything they physically could do according to the rules of the Earth Simulator that we run in because it would be chaos that ultimately leads to some byzantine order, like some huge C project gone bad.
People that seem to require strongly-typed languages, to prevent their errors of inattention while they write code. But all these features are unknown to the CPU -- they've all been stripped away in the compiler, and reduced back to the purity of sequential code.
No that's not it at all, it's because they have no use for the power they are missing. The benefits far outweight the costs. If you look at "Frontier House" you see people spending all day doing things that take us seconds, like buying a stick of butter instead of churning it for hours. It's the same with assembly, sure you *could* have it automatically relocate live objects in memory like Java does, but all your code would have to live with a lot of the same restrictions (not xor'ing the next/previous addresses into one to save space, not using non-stack space as a stack, etc). So you often end up with the same thing, but just doing it the *really* hard, slow way.
maintainability and enhanceability, at least, are entirely dependent on the quality of the programmer
Change a constant in Java and if it is going to break something more often than not you get an error telling you exactly where the problem was and what the call stack was. In C it's not so unusual that you can't even get the call stack (with gdb) because it has been trashed, leading to a long process of stepping through various functions one line at a time.
In Java when you know a lot more for certain. If you have a reference to an object you know what types it could be, that it has been initialized by a constructor, that it isn't simultaneously co-located with other objects, etc. In C/C++ you don't, so when things go bad (because of a lame developer or code rot or whatever) they can go much worse. Somebody casts a char *buf returned from gets into a Config object with the comment 'read config from stdin'. And it works, kinda...
The reason why there is a obfuscated C contest is because C code doesn't even have to look like what it does. Obfuscated Java looks like what it does, so you just have to follow the steps not figure out what those steps are. Java is like a tide that raises all boats for maintainability and enhanceability, even the crappy ones, where C is like an anchor always trying to drag the project down into the depths.
If you care about startup time, use gcj and get the startup time of C code.
And I don't get it how people can say they "care about memory usage" so Java is out. Memory allocation in Java is one pointer increment. Big-Oh of one instruction. In almost all cases C is worse for heap allocation, in performance and space efficiency (since it cannot move allocations that are in use to compact them). C wins on stack-based variables and large arrays. Which one has better memory usage depends on the software you are writing.
Jenn #2
When I watch one of those crime shows on tv and the officer says "anything you say can be held against you in a court of law" I used to think then meant starting from now. I guess it's really more of just a fyi kinda thing.