For an excellent account of the German successes (and failures) at breaking the Allied naval codes during WW-II, see "German Naval Code Breakers" by J.P. Mallman Showell.
The 16000 meters claim does not say that he did that, it only says that the software can. Like in: "This is the physics involved, this is what we can get on terms of picture quality, and based on all that the maximum we can do would be 16000. And it turns out we're lucky that the ocean ain't that deep anywhere."
The next killer app does not have to come out of the current killer. But it is a very well documented and repeating pattern that many of these "next killer apps" are developed within the then dominant organisation - because that's where the money is - but ignored or not understood by management. The inventors then quit and build the new killer organisation, leaving their previous employer wonder what happened. The most important observation, however, is that the very same people that went through all this later fall in the exact same trap themselves.
Remember Ken Olsen. IBM didn't believe in his ideas for smaller better and more ubiquitous computers, so he built DEC. But 20 years later he didn't believe in the PC ("there is no reason for any individual to have a computer in his home") and DEC ended up being bought by Compaq.
There are plenty more examples of this pattern in the computer industry.
You're right, the second and third level backups are done manually. But it's not a lot of work, as each just involves a single file copy operation. My off-site disk is stored in a location that I need to pass by very frequently anyway. I just pick up the disk when I'm there and bring it back the next day or the day after.
Regarding lazyness, it's all a matter of trade-off. Are you willing to loose your digital history or not? I sure as hell am not, so I make sure to have my backups under control. OTOH, wether or not I'd consider an e-mail worth replying to is a completely different matter: it seems perfectly possible to me to be "lazy" on that front while not being so on the backup one. One can always tell one's sister that the mail got misfilled or burried in work related e-mail, but it's impossible to restore a backup that never got made.
This is why I don't leave any mail on my ISP's server. Everything gets downloaded to my home desktop as soon as possible. This machine is automatically backed-up to a separate partition on the same disk on a daily basis. Once a week the latest of these daily backups is copied to a normally powered down external disk attached to my laptop. Finally, that disk is backed up regularly to another one that normally is not even on-site. The day that all of these things fail at the same time, I more than likely am not around to care anymore.
The other reason why I download everything is that I do not want some random ISP admin to be able to read all my mail (current and past) or some random ad agency in disguise (need I still name them?) to scan it for profiling purposes.
a ship abandoned or sunk in international waters has no owners anyway
Unless it is a war grave. In that case, the ship is forever owned by the government of the country that it sailed for, or its internationally recognised sucessor, no matter whose waters the wreck is located in. HMS Hood is property of the UK government, despite her position in international waters. KM Bismarck is property of the German government (I don't know which Germany would have been considered owner between 1945 and 1990, but it doesn't matter: either one would have been "done the trick").
For me, reason no. 1 is the hassle. I wouldn't want to keep track of which of multiple IDs I'd be logged in as. So I'm always logged in as "myself" and I sure will remember on a case by case basis if I want a certain post to go out as AC.
Of course one might say that my "/. self" can not be traced to "the real me" anyhow, as long as I don't display my real name or e-mail adres. But for quite a few people, my/. account name is enough to know who I am. And even if it isn't, if you use a non-AC account to post stuff about topics that you know about, you slowly build a public profile that eventually allows people who know you in real life to guess who you are. There you have my reason number 2, which is actually more fundamental than no. 1.
Microsoft does not need to have US law applicable in Germany, except for locking the German market as well.
One reason is that Microsoft may already have an equivalent European patent. (No, please don't tell me that software patents are impossible in the EU: I've seen some approved first hand. It's all a matter of how you package the thing when you write up the description.)
The second and more fundamental reason is that even if the infringing software is perfectly legal in the EU it cannot be sold or distributed in the US without violating US patent law. Patent law applies not to the location of product development or production, but to the location of the market in which you operate. From a strictly legal point of view that is the real killer, because if you can't legally market your software in the US, US companies or individuals will likely develop a competing program and squeeze you out of the market by sheer volume. Fortunately, at least the individuals will just find ways to get hold of the EU software they want, no matter what.
I mean objects to mean instatiations of classes and, yes, I mean "hundreds of thousands" of objects.
Actually, 100,000 objects is not a lot at all. Imagine parsing a 10 KLoC piece of C++ code, ignoring comments and whitespace. (Our biggest standard test case was about 50 KLoC IIRC, some of our customers did even bigger things). These 10 KLoC are spread out over about 50 files. Furthermore, imagine having to retain that program's abstract syntax tree in memory, including how each of the files references others via #includes, because later on you will be required to regenerate modified code that looks as much like the original one as possible. Let's also say that an average line of code requires about five "source level" objects (declarations, variables, statements, variable references, operators, constants, for-loops, conditions, function definitions or calls, argument lists,...) to be represented. (Actually, I think that that five estimate is low, but I no longer have access to the program in question, so I can't check.) That's about 10000 * 5 + 50 * 10 or 50500 objects right there (and I'm on purpose skipping important concepts such as "compilation units" to keep things simple).
Then remember that above ignores all temporary objects created and destroyed along the way while building this tree. Then remember that, since we're parsing C++, since we need to keep track of the original file structure, and since we need to keep track of the #includes, we also need en embedded C preprocessor, not just a file-flattening one in an up-front separate process. Yet more objects. All this also ignores all the hidden auxiliary objects that are needed behind the scenes to implement the one-to-many or many-to-many relationships between the main objects (sets, hash tables, hash table entries,...). And it does not take into account that when using proper encapsulation every string is an object. Before you know it, you need more than 100000 objects just to get from process initiation to the internal representation of that 10 KLoC program. Multiply by 5 to get an estimate for our 50 KLoC test case and it's way over 500000.
And so far you have not yet done anything valuable with this data structure! I will spare you a description of the kind of thing we did with it, esp. as it required a lot more additional data structures and several hours of calculations creating and deleting temporary objects almost all the time. It will be clear that on bigger applications we were talking not hundreds of thousands, but many millions of objects. This also explains why in one of my posts in this discussion I mentioned a custom memory allocator: having that thing really helped a lot (often both in terms of speed and size, but on each platform that we supported at least in terms of one of these without compromising the other).
Before I forget: We had a complete embedded Python interpreter sitting in our program as well in order to provide scriptability. There's a ton more objects sitting right there. And did you notice that so far I didn't even touch upon the implementation of the GUI? We did have one, though...
I remember counting the number of memory allocations needed to process our biggest test case once. The number was absolutely mind boggling. Of course, not every allocation corresponds to an object instantiation, especially not when you're frequently dynamically reallocating auxiliary buffers, but even so...
(Note: This paragraph is besides my original point, but what the heck...)
Sadly, asking for a customer dataset is not always feasible. Our software read C(++) code, performed complex analysis and ditto optimisations on it, and then spit out optimised C(++) code next to many other things (statistics, power usage estimations, specifications for hardware in embedded systems, you name it). Our typical customer would not in a million years share the dataset (i.e. his program) with us, because those programs were their key IP and because they knew we were working with their competitors as well. Even worse, we regularly had people from those competing customers on-site and even then we would not get to see the code, precisely because the competition was also around.
As I already indicated, debug builds are nice, but not very useful in case they, for instance through some side effect such as a modified memory allocation pattern, affect the behaviour of the bug.
As for knowing where the bug should be: of course we had an idea where it should be and where it shouldn't be. Because of all the checks we had built-in, we actually had a pretty good track record as far as bugfix turnaround time was concerned. But having that idea of where the bug can and can't be can be misleading as well. It are mainly those cases that I'm talking about here. See also my other posts for a non-exhaustive set of examples why ideas about which module owner has been naughty might be proven wrong.
It's silly to reply to my own post, but just to prevent this somewhat off-topic discussion from escalating: we even went as far as to write our own C++ code generator that translated complex IMs into complete C++ class implementations (much beyond what commercial code generators could do at the time). Eventually, 70% of the C++ code (millions of lines in total) was generated automatically according to rigourous pattern templates. Most classes even were generated 100% automatically. We did that exactly because it allowed us to automatically implement a metric ton of consistency checks amd to always be sure to register the correct event handlers for all relevant events etc. But even so: bugs happen. There still is the 30% manual code. There still is the base layer (to name just one example: think efficient dynamic memory allocation customised to the dominant allocation patterns in our tool set). There still are compilers. There still are third party libraries that can create havoc (we never found an ILP library that was both affordable and fully reliable, for instance)....
I knew someone would say this.:-) Actually, it helps to make my point. Our code was stuffed with pre- and post condition consistency checks, so debug versions of the software sometimes ran an order of magnitude slower tham production ones. Hence one more reason for the emergence of Heisenbugs: enable the checks and the problem goes away. In complex event driven extensible architectures not everything can be checked during every operation. Trust me, I've spent countless days trying to ensure absolute logical consistency of my classes, no matter what happens. But when event callback mechanisms enter into the picture it becomes incredibly hard and eventually infeasible.
But yes, in theory, you are right: there were encapsulation problems, as well as others, in our code. Guess what, those are called bugs and they are some of the very bugs we're looking for. In real life, you cannot reason them away by saying "naughty you, these bugs should not be there" or "if only everybody who ever worked on this project would have been a perfect software engineer, things would be easier". In real life you have to find and fix the bugs first and ponder how much nicer life could be if only you'd be able to redesign and reimplement everything from scratch later.
In systems with several million lines of code, bugs are not unheard of, no matter how well you try to stick to the rules. Especially if some of the code has a 12 year history. Especially if it is written in C++, a language that supports something weird and badly controllable called "pointers". Especially if you're sometimes dealing with compiler bugs. E.g.: We've found numerous virtual multiple inheritance bugs in several compilers over the years, including g++. You read your code and know with 100% certainty that it is OK, and you're absolutely sure all the encapsulation is done right, and even that you verify it all at run time, and yet...
Your example is way to simplistic. I've seen core dump cases in which it was perfectly clear why it was crashing: the data structure got into a logically inconsistent state that it should never be in. The question is how and when. In case of big data structures (in some of the cases I've had to deal with: hundreds of thousands of objects, built gradually and modified heavily during several hours) finding the exact sequence that causes the inconsistency can be a nightmare. Plus, it might have been sitting around in this state for a long time before the program actually enters a path that leads to a crash.
Also, the worst type of bug is the Heisenbug: those that go away as soon as you enable debugging, or add even just a single line of extra code to monitor something while the stuff is running. I've seen my share of those as well. Sometimes persistance pays off and you find the root cause within hours or days, but sometimes reality forces you to give up. It's no use spending five weeks fruitlessly looking for a rare intermittent bug triggered by a convoluted internal unit test case if at the same time easily tracable bugs are being reported by paying users that need a solution within a week.
Well, let's say that that might depend on the definition of "to advance". In my book, a publication is not an "advance". Its content might be, but the publication itself isn't...
I'm basing my opinion on 17 years spent in research, supporting and guiding many PhDs. At least where I worked, a minimum number of publications (at least two of which had to be so-called journal papers) was required for a PhD. But I have seen some cases in which one could doubt whether the work advanced the body of knowledge in any meaningful way. One of these people went on to become a full professor nonetheless. And that was in a high-tech engineering discipline, a field that still evolves very rapidly. I would expect the average PhD in some of the elder sciences to advance its field less (note: on average!).
It's obvious that my reply contained a message between the lines that you did not see. If you can't bother to think about what you reply to, please don't reply.
You could not possibly be more wrong on this one. I can only hope you're not a (candidate) manager (let alone CIO or CEO) yourself.
The IT architecture has to be perfectly aligned with the company's mission and strategy. If it's not, it's a just problem waiting to happen! If the misalignment is major, it's a disaster waiting to happen.
Besides, everyone in the company must know the mission!
Last week I had a chat with the former managing director of one of the big four labels in my country (and in a few others as well). His personal opinion is that DRM has to go. When asked directly, he stated that in the music industry boardrooms, about 50% of the people are by now convinced that it has to go, whereas 50% have not yet reached that point. One of the things that's holding them back, is that the movie and especially the games industries are putting pressure on the music one not to drop DRM because they fear the domino effect.
It would indeed. But the original question was: would it work for making money. That's a study I'd like to see as well.
In the end, if you're not orchestrating these things yourself but observing what's going on and making good choices based on that, all you are doing is exploiting publicly available information better than the next guy. And that, after all is the core of the entire stockmarket idea. So while the SEC may decde to have a close look at you, as long as you're not involved in the scam itself, nobody can convict you of anything. That is: until somebody proves that the idea actually works and an appropriate law is passed, making it illegal to strategically base your investment decisons on what you know to be obvious scams. Until then, the SEC's investigations may have some undesired side effects, but as long as the rewards are higher...
Re:I've been using vi for so long...
on
The Birth of vi
·
· Score: 1
Vi is the ultimate editor, for one main reason. It's a modal editor
How true! But for me, the absolute beauty of vi is that the modality allows you to cut and paste not only text input but also commands without having to deal with that pesky Ctrl key and that you don't need the arrow keys to move around. The only special key you really need in vi is Esc and that little nuissance is easily solved by predefining a key mapping of an input sequence like ESCAPE - or whatever you prefer - to Esc.
The number of times I have performed a set of editing commands on a group of files just by preparing them once, observing the effect "live", and then cutting and pasting them into every file in quick succession cannot be represented in 32 bits.:-) This technique saved my a ton of time, and is much simpler and safer than to write a shell (or heaven forbid) a perl script for it. This also is why my source code always looked consistent and easily readable: sticking to my layout rules made it very easy to write such vi commands, even complex ones, and the ease of applying them in vi made me actually care to consistently make any required global changes whereas others typically scared away from the effort.
Once upon a time (+-1989), we had a set of some 50 Apollo workstations linked up via a Token Ring network. Not only did that ring have a habit of being physically broken every so often, the worst part was that there was no file server. Everybody stored his own files on his own machine. Project accounts were housed on the machine of the project owner. Nice and orderly, huh?
Well... except for the fact that there were people who didn't have a personal machine. Their data was initially housed on the machine of someone they cooperated most with. When disks filled up, new people without a machine would end up on whatever disk happened to have spare capacity. Then we (or rather "they", as I was there but not part of the IT gang) found that the amount of data people store over time outgrows the size of their disks, especially if you have shared project accounts. So ever so often, accounts had to be moved around. And sure enough, before you knew it the owner of the machine to which some high profile project had just been moved would complain that his box was overloaded doing other people's I/O. And just when that had been sorted out, there typically would be a reorganisation involving people switching offices or desks. Sometimes the machine followed its owner (not all were equally fast and some of them had black&white displays that nobody wanted to inherit), but most often IT would object to moving the boxes. By now the physical link between the data and its owner is totally gone. In the end, most people didn't have a clue what machines their files were stored on.
And now the fun really starts. We relied a lot on students and interns. In those days, if a student had seen a computer before, either it was a Commodore 68 or an early standalone PC. They didn't have a clue what the network was used for, so whenever they were done and went home, they'd physically switch off the machine they had been using. To make matters worse, even just keeping employee data storage away from the student machines was not an option, because there were not nearly enough student machines around. Typically, students would use the machine of an employee who happened to be out of the office on that day or during that night. Oh, what sweet memories... Not!
Not to mention the backup problems... Nor the fact that we also had a parallel experimental ethernet network with non-Apollo machines, of couse also without a proper file server. After a while, some data was being stored there instead. Now where the... did I save that f... file last week???
In my experience, the 2 weakest links are the disk and the hinges of the screen. Personally, I've only had disk problems, but looking back at the company laptop problems I've seen, the hinges (that is: including the electrical connections inside) probably come close in second place.
In terms of "what can you do about it that the customer is willing to pay for", the disk is by far at the top of the list. Apart from the complete newbies, customers do understand that there are major risks involved in disk failure. They also feel the heat and hear the noise. So they're willing to fork over a few extra greenbacks to get a no-heat, no-noise, no-mechanical breakage replacement solution. There's no way you're going to convince them to pay more for better designed more robust hinges, however. Besides, no vendor will want to admit to having done a bad job on those in the past.
The ads on slashdot, for instance, are relatively unobtrusive,
Ahem. They used to be. Nowadays in about 50% of my visits to the main page I get a big square ad in the top right corner that overlays part of the text in the center column, simply making it impossible to RTFI (I=Intro). Talk about (un)obtrusive...
Actually, the whole situation was a lot more complex. There were hardware exceptions (not enough bits to represent data after conversion from floating point to integer), combined with deadly so-called efficieny optimisations (the trap for these hardware exceptions had been disabled), combined with a cascade of other problems in which code mis-interpreted the bits encoding the unexpected hardware exception as normal data.
On top of all that, the original conversion error occured in a piece of code that had no function once lift-off had occured and that therefore should no longer have been used/active. This actually is another place where the reuse caused problems: the timer that was supposed to switch off the stuff in question was not modified for Ariane 5. After the fact, it also was argued that even for Ariane 4 this switch off was done way too late anyway: as soon as lift-off occured, the sensors in questions were producing nonsense (and as already mentioned: unsued) data anyway. But for Ariane 4 the delay actually was an intended feature that had on one earlier occasion been used to stop and restart the pre-launch countdown in a time-saving way. Note that this indicates yet another mistake: even if the delay feature is intentional and useful as long as the rocket is still on the ground, the software should be written such that it is disabled immediately after lift-off, not X seconds after some pre-launch event. Worst of all, for Ariane 5 the entire setup made no sense at all anyway, not even as a pre-launch time saver.
And then there was the design (actually specification) mistake that any exception had to result in stopping the processor.
Slashdot Mirror
For an excellent account of the German successes (and failures) at breaking the Allied naval codes during WW-II, see "German Naval Code Breakers" by J.P. Mallman Showell.
The 16000 meters claim does not say that he did that, it only says that the software can. Like in: "This is the physics involved, this is what we can get on terms of picture quality, and based on all that the maximum we can do would be 16000. And it turns out we're lucky that the ocean ain't that deep anywhere."
Having said that, I still don't believe it.
The next killer app does not have to come out of the current killer. But it is a very well documented and repeating pattern that many of these "next killer apps" are developed within the then dominant organisation - because that's where the money is - but ignored or not understood by management. The inventors then quit and build the new killer organisation, leaving their previous employer wonder what happened. The most important observation, however, is that the very same people that went through all this later fall in the exact same trap themselves.
Remember Ken Olsen. IBM didn't believe in his ideas for smaller better and more ubiquitous computers, so he built DEC. But 20 years later he didn't believe in the PC ("there is no reason for any individual to have a computer in his home") and DEC ended up being bought by Compaq.
There are plenty more examples of this pattern in the computer industry.You're right, the second and third level backups are done manually. But it's not a lot of work, as each just involves a single file copy operation. My off-site disk is stored in a location that I need to pass by very frequently anyway. I just pick up the disk when I'm there and bring it back the next day or the day after.
Regarding lazyness, it's all a matter of trade-off. Are you willing to loose your digital history or not? I sure as hell am not, so I make sure to have my backups under control. OTOH, wether or not I'd consider an e-mail worth replying to is a completely different matter: it seems perfectly possible to me to be "lazy" on that front while not being so on the backup one. One can always tell one's sister that the mail got misfilled or burried in work related e-mail, but it's impossible to restore a backup that never got made.
This is why I don't leave any mail on my ISP's server. Everything gets downloaded to my home desktop as soon as possible. This machine is automatically backed-up to a separate partition on the same disk on a daily basis. Once a week the latest of these daily backups is copied to a normally powered down external disk attached to my laptop. Finally, that disk is backed up regularly to another one that normally is not even on-site. The day that all of these things fail at the same time, I more than likely am not around to care anymore.
The other reason why I download everything is that I do not want some random ISP admin to be able to read all my mail (current and past) or some random ad agency in disguise (need I still name them?) to scan it for profiling purposes.
a ship abandoned or sunk in international waters has no owners anyway
Unless it is a war grave. In that case, the ship is forever owned by the government of the country that it sailed for, or its internationally recognised sucessor, no matter whose waters the wreck is located in. HMS Hood is property of the UK government, despite her position in international waters. KM Bismarck is property of the German government (I don't know which Germany would have been considered owner between 1945 and 1990, but it doesn't matter: either one would have been "done the trick").
For me, reason no. 1 is the hassle. I wouldn't want to keep track of which of multiple IDs I'd be logged in as. So I'm always logged in as "myself" and I sure will remember on a case by case basis if I want a certain post to go out as AC.
Of course one might say that my "/. self" can not be traced to "the real me" anyhow, as long as I don't display my real name or e-mail adres. But for quite a few people, my /. account name is enough to know who I am. And even if it isn't, if you use a non-AC account to post stuff about topics that you know about, you slowly build a public profile that eventually allows people who know you in real life to guess who you are. There you have my reason number 2, which is actually more fundamental than no. 1.
Microsoft does not need to have US law applicable in Germany, except for locking the German market as well.
One reason is that Microsoft may already have an equivalent European patent. (No, please don't tell me that software patents are impossible in the EU: I've seen some approved first hand. It's all a matter of how you package the thing when you write up the description.)
The second and more fundamental reason is that even if the infringing software is perfectly legal in the EU it cannot be sold or distributed in the US without violating US patent law. Patent law applies not to the location of product development or production, but to the location of the market in which you operate. From a strictly legal point of view that is the real killer, because if you can't legally market your software in the US, US companies or individuals will likely develop a competing program and squeeze you out of the market by sheer volume. Fortunately, at least the individuals will just find ways to get hold of the EU software they want, no matter what.
I mean objects to mean instatiations of classes and, yes, I mean "hundreds of thousands" of objects.
Actually, 100,000 objects is not a lot at all. Imagine parsing a 10 KLoC piece of C++ code, ignoring comments and whitespace. (Our biggest standard test case was about 50 KLoC IIRC, some of our customers did even bigger things). These 10 KLoC are spread out over about 50 files. Furthermore, imagine having to retain that program's abstract syntax tree in memory, including how each of the files references others via #includes, because later on you will be required to regenerate modified code that looks as much like the original one as possible. Let's also say that an average line of code requires about five "source level" objects (declarations, variables, statements, variable references, operators, constants, for-loops, conditions, function definitions or calls, argument lists, ...) to be represented. (Actually, I think that that five estimate is low, but I no longer have access to the program in question, so I can't check.) That's about 10000 * 5 + 50 * 10 or 50500 objects right there (and I'm on purpose skipping important concepts such as "compilation units" to keep things simple).
Then remember that above ignores all temporary objects created and destroyed along the way while building this tree. Then remember that, since we're parsing C++, since we need to keep track of the original file structure, and since we need to keep track of the #includes, we also need en embedded C preprocessor, not just a file-flattening one in an up-front separate process. Yet more objects. All this also ignores all the hidden auxiliary objects that are needed behind the scenes to implement the one-to-many or many-to-many relationships between the main objects (sets, hash tables, hash table entries, ...). And it does not take into account that when using proper encapsulation every string is an object. Before you know it, you need more than 100000 objects just to get from process initiation to the internal representation of that 10 KLoC program. Multiply by 5 to get an estimate for our 50 KLoC test case and it's way over 500000.
And so far you have not yet done anything valuable with this data structure! I will spare you a description of the kind of thing we did with it, esp. as it required a lot more additional data structures and several hours of calculations creating and deleting temporary objects almost all the time. It will be clear that on bigger applications we were talking not hundreds of thousands, but many millions of objects. This also explains why in one of my posts in this discussion I mentioned a custom memory allocator: having that thing really helped a lot (often both in terms of speed and size, but on each platform that we supported at least in terms of one of these without compromising the other).
Before I forget: We had a complete embedded Python interpreter sitting in our program as well in order to provide scriptability. There's a ton more objects sitting right there. And did you notice that so far I didn't even touch upon the implementation of the GUI? We did have one, though...
I remember counting the number of memory allocations needed to process our biggest test case once. The number was absolutely mind boggling. Of course, not every allocation corresponds to an object instantiation, especially not when you're frequently dynamically reallocating auxiliary buffers, but even so...
(Note: This paragraph is besides my original point, but what the heck...)
Sadly, asking for a customer dataset is not always feasible. Our software read C(++) code, performed complex analysis and ditto optimisations on it, and then spit out optimised C(++) code next to many other things (statistics, power usage estimations, specifications for hardware in embedded systems, you name it). Our typical customer would not in a million years share the dataset (i.e. his program) with us, because those programs were their key IP and because they knew we were working with their competitors as well. Even worse, we regularly had people from those competing customers on-site and even then we would not get to see the code, precisely because the competition was also around.
As I already indicated, debug builds are nice, but not very useful in case they, for instance through some side effect such as a modified memory allocation pattern, affect the behaviour of the bug.
As for knowing where the bug should be: of course we had an idea where it should be and where it shouldn't be. Because of all the checks we had built-in, we actually had a pretty good track record as far as bugfix turnaround time was concerned. But having that idea of where the bug can and can't be can be misleading as well. It are mainly those cases that I'm talking about here. See also my other posts for a non-exhaustive set of examples why ideas about which module owner has been naughty might be proven wrong.
It's silly to reply to my own post, but just to prevent this somewhat off-topic discussion from escalating: we even went as far as to write our own C++ code generator that translated complex IMs into complete C++ class implementations (much beyond what commercial code generators could do at the time). Eventually, 70% of the C++ code (millions of lines in total) was generated automatically according to rigourous pattern templates. Most classes even were generated 100% automatically. We did that exactly because it allowed us to automatically implement a metric ton of consistency checks amd to always be sure to register the correct event handlers for all relevant events etc. But even so: bugs happen. There still is the 30% manual code. There still is the base layer (to name just one example: think efficient dynamic memory allocation customised to the dominant allocation patterns in our tool set). There still are compilers. There still are third party libraries that can create havoc (we never found an ILP library that was both affordable and fully reliable, for instance). ...
I knew someone would say this. :-) Actually, it helps to make my point. Our code was stuffed with pre- and post condition consistency checks, so debug versions of the software sometimes ran an order of magnitude slower tham production ones. Hence one more reason for the emergence of Heisenbugs: enable the checks and the problem goes away. In complex event driven extensible architectures not everything can be checked during every operation. Trust me, I've spent countless days trying to ensure absolute logical consistency of my classes, no matter what happens. But when event callback mechanisms enter into the picture it becomes incredibly hard and eventually infeasible.
But yes, in theory, you are right: there were encapsulation problems, as well as others, in our code. Guess what, those are called bugs and they are some of the very bugs we're looking for. In real life, you cannot reason them away by saying "naughty you, these bugs should not be there" or "if only everybody who ever worked on this project would have been a perfect software engineer, things would be easier". In real life you have to find and fix the bugs first and ponder how much nicer life could be if only you'd be able to redesign and reimplement everything from scratch later.
In systems with several million lines of code, bugs are not unheard of, no matter how well you try to stick to the rules. Especially if some of the code has a 12 year history. Especially if it is written in C++, a language that supports something weird and badly controllable called "pointers". Especially if you're sometimes dealing with compiler bugs. E.g.: We've found numerous virtual multiple inheritance bugs in several compilers over the years, including g++. You read your code and know with 100% certainty that it is OK, and you're absolutely sure all the encapsulation is done right, and even that you verify it all at run time, and yet...
Your example is way to simplistic. I've seen core dump cases in which it was perfectly clear why it was crashing: the data structure got into a logically inconsistent state that it should never be in. The question is how and when. In case of big data structures (in some of the cases I've had to deal with: hundreds of thousands of objects, built gradually and modified heavily during several hours) finding the exact sequence that causes the inconsistency can be a nightmare. Plus, it might have been sitting around in this state for a long time before the program actually enters a path that leads to a crash.
Also, the worst type of bug is the Heisenbug: those that go away as soon as you enable debugging, or add even just a single line of extra code to monitor something while the stuff is running. I've seen my share of those as well. Sometimes persistance pays off and you find the root cause within hours or days, but sometimes reality forces you to give up. It's no use spending five weeks fruitlessly looking for a rare intermittent bug triggered by a convoluted internal unit test case if at the same time easily tracable bugs are being reported by paying users that need a solution within a week.
Well, let's say that that might depend on the definition of "to advance". In my book, a publication is not an "advance". Its content might be, but the publication itself isn't...
I'm basing my opinion on 17 years spent in research, supporting and guiding many PhDs. At least where I worked, a minimum number of publications (at least two of which had to be so-called journal papers) was required for a PhD. But I have seen some cases in which one could doubt whether the work advanced the body of knowledge in any meaningful way. One of these people went on to become a full professor nonetheless. And that was in a high-tech engineering discipline, a field that still evolves very rapidly. I would expect the average PhD in some of the elder sciences to advance its field less (note: on average!).
One does not require a PhD to understand things, one obtains a PhD by understanding and (ideally but bot necessarily) advancing them.
Any PhD worth his or her salt will admit that the PhD itself is just a piece of paper.
It's obvious that my reply contained a message between the lines that you did not see. If you can't bother to think about what you reply to, please don't reply.
People don't want configurability
In that case, please enlighten me what kind of animal I must be, for I clearly can't be human.
Hmmm, actually, you might be right after all because I'm not "people". I'm me, an individual with a brain and a mind of his own.
Guess what, I use Linux without Gnome.
They don't even have to know the mission.
You could not possibly be more wrong on this one. I can only hope you're not a (candidate) manager (let alone CIO or CEO) yourself.
The IT architecture has to be perfectly aligned with the company's mission and strategy. If it's not, it's a just problem waiting to happen! If the misalignment is major, it's a disaster waiting to happen.
Besides, everyone in the company must know the mission!
Last week I had a chat with the former managing director of one of the big four labels in my country (and in a few others as well). His personal opinion is that DRM has to go. When asked directly, he stated that in the music industry boardrooms, about 50% of the people are by now convinced that it has to go, whereas 50% have not yet reached that point. One of the things that's holding them back, is that the movie and especially the games industries are putting pressure on the music one not to drop DRM because they fear the domino effect.
It would indeed. But the original question was: would it work for making money. That's a study I'd like to see as well.
In the end, if you're not orchestrating these things yourself but observing what's going on and making good choices based on that, all you are doing is exploiting publicly available information better than the next guy. And that, after all is the core of the entire stockmarket idea. So while the SEC may decde to have a close look at you, as long as you're not involved in the scam itself, nobody can convict you of anything. That is: until somebody proves that the idea actually works and an appropriate law is passed, making it illegal to strategically base your investment decisons on what you know to be obvious scams. Until then, the SEC's investigations may have some undesired side effects, but as long as the rewards are higher...
Vi is the ultimate editor, for one main reason. It's a modal editor
How true! But for me, the absolute beauty of vi is that the modality allows you to cut and paste not only text input but also commands without having to deal with that pesky Ctrl key and that you don't need the arrow keys to move around. The only special key you really need in vi is Esc and that little nuissance is easily solved by predefining a key mapping of an input sequence like ESCAPE - or whatever you prefer - to Esc.
The number of times I have performed a set of editing commands on a group of files just by preparing them once, observing the effect "live", and then cutting and pasting them into every file in quick succession cannot be represented in 32 bits. :-) This technique saved my a ton of time, and is much simpler and safer than to write a shell (or heaven forbid) a perl script for it. This also is why my source code always looked consistent and easily readable: sticking to my layout rules made it very easy to write such vi commands, even complex ones, and the ease of applying them in vi made me actually care to consistently make any required global changes whereas others typically scared away from the effort.
Once upon a time (+-1989), we had a set of some 50 Apollo workstations linked up via a Token Ring network. Not only did that ring have a habit of being physically broken every so often, the worst part was that there was no file server. Everybody stored his own files on his own machine. Project accounts were housed on the machine of the project owner. Nice and orderly, huh?
Well... except for the fact that there were people who didn't have a personal machine. Their data was initially housed on the machine of someone they cooperated most with. When disks filled up, new people without a machine would end up on whatever disk happened to have spare capacity. Then we (or rather "they", as I was there but not part of the IT gang) found that the amount of data people store over time outgrows the size of their disks, especially if you have shared project accounts. So ever so often, accounts had to be moved around. And sure enough, before you knew it the owner of the machine to which some high profile project had just been moved would complain that his box was overloaded doing other people's I/O. And just when that had been sorted out, there typically would be a reorganisation involving people switching offices or desks. Sometimes the machine followed its owner (not all were equally fast and some of them had black&white displays that nobody wanted to inherit), but most often IT would object to moving the boxes. By now the physical link between the data and its owner is totally gone. In the end, most people didn't have a clue what machines their files were stored on.
And now the fun really starts. We relied a lot on students and interns. In those days, if a student had seen a computer before, either it was a Commodore 68 or an early standalone PC. They didn't have a clue what the network was used for, so whenever they were done and went home, they'd physically switch off the machine they had been using. To make matters worse, even just keeping employee data storage away from the student machines was not an option, because there were not nearly enough student machines around. Typically, students would use the machine of an employee who happened to be out of the office on that day or during that night. Oh, what sweet memories... Not!
Not to mention the backup problems... Nor the fact that we also had a parallel experimental ethernet network with non-Apollo machines, of couse also without a proper file server. After a while, some data was being stored there instead. Now where the ... did I save that f... file last week???
In my experience, the 2 weakest links are the disk and the hinges of the screen. Personally, I've only had disk problems, but looking back at the company laptop problems I've seen, the hinges (that is: including the electrical connections inside) probably come close in second place.
In terms of "what can you do about it that the customer is willing to pay for", the disk is by far at the top of the list. Apart from the complete newbies, customers do understand that there are major risks involved in disk failure. They also feel the heat and hear the noise. So they're willing to fork over a few extra greenbacks to get a no-heat, no-noise, no-mechanical breakage replacement solution. There's no way you're going to convince them to pay more for better designed more robust hinges, however. Besides, no vendor will want to admit to having done a bad job on those in the past.
Ahem. They used to be. Nowadays in about 50% of my visits to the main page I get a big square ad in the top right corner that overlays part of the text in the center column, simply making it impossible to RTFI (I=Intro). Talk about (un)obtrusive...
Actually, the whole situation was a lot more complex. There were hardware exceptions (not enough bits to represent data after conversion from floating point to integer), combined with deadly so-called efficieny optimisations (the trap for these hardware exceptions had been disabled), combined with a cascade of other problems in which code mis-interpreted the bits encoding the unexpected hardware exception as normal data.
On top of all that, the original conversion error occured in a piece of code that had no function once lift-off had occured and that therefore should no longer have been used/active. This actually is another place where the reuse caused problems: the timer that was supposed to switch off the stuff in question was not modified for Ariane 5. After the fact, it also was argued that even for Ariane 4 this switch off was done way too late anyway: as soon as lift-off occured, the sensors in questions were producing nonsense (and as already mentioned: unsued) data anyway. But for Ariane 4 the delay actually was an intended feature that had on one earlier occasion been used to stop and restart the pre-launch countdown in a time-saving way. Note that this indicates yet another mistake: even if the delay feature is intentional and useful as long as the rocket is still on the ground, the software should be written such that it is disabled immediately after lift-off, not X seconds after some pre-launch event. Worst of all, for Ariane 5 the entire setup made no sense at all anyway, not even as a pre-launch time saver.
And then there was the design (actually specification) mistake that any exception had to result in stopping the processor.