LAMP "showed significantly better software quality" above the report's baseline with an average of.32 defects per 1,000 lines of code, according to Coverity. The average for open source projects analyzed is.42 per 1,000 lines.
So if LAMP open-source is simply more verbose than other kinds of open source, the number of bugs per line of code can go down? How about just adding a million lines of bug-free but totally bogus code to your project -- and completely winning the race of "Defects per 1,000 lines of code"?
If I remember correctly Coverity has been discussed on slashdot previously and they used the same diseased statistical thinking back then, too.
People care more about these long term issues when they're young. And they care more about them if they have lots of kids. I'm well into middle age without kids and find that these sorts of issues just don't move me the way they did when I was 20.
The US population is aging and having fewer kids. The European population is aging even faster and having even fewer kids. Except that the European Arabs are young and having lots of kids. Mix it all together and let me know if you figure it out...
Teaching people about computers is a little like teaching drivers about the internals of the internal combustion engine and the transmission. They're not supposed to have to know.
The stuff they really need to know about is how everything is just bits and the computer is mostly stupid. A friend was today amazed that a spell checker just compares text to a list of words. He thought it knew spelling. Persuade them that the box is a robot that learned how to spell. It's close enough.
Hardware changes and is becoming increasingly hidden. Aside from the power switch and the fact that more money is needed to buy more bits, ignore it. Otherwise you'll end up teaching them the quantum mechanics of silicon transisters.
What they need to know depends on who they are and what they are trying to do. By and large the user community should only be forced to learn to use the content tools they need to manage their email, novels, photos, videos, music, pirated films, and so on.
Beyond that, all they need to know is that it's all a bucket of bits and it needs to be backed up. And you don't know if the backup is any good until you try to use it. Oh, and don't be scared of it. The only kind of damage you can do, if you don't set fire to it, is erase the data. That's right, 99.99% of all damage is data erasure. The bits are still in the hardware but they've been all turned to zeroes or "De-allocated" as we like to say.
Consider the ethics of teaching them about DRM and it might be wrong to steal.
And teach them to run the security programs that they need but aren't supposed to.
And email them to yourself at home with the source. Remove everybody else's comments. Soon you will be the only person who understands the code! Hell -- use a scrambler to dis-organize the code. They're called obfuscators. See this site for an example. If that doesn't work delete the source and keep on patching the binary! I'm serious! I knew a coder who kept his job for 15 years that way. I do not exaggerate. Of course, when he finally left, he was completely out of touch and obsolete, but he didn't mind! I kid you not!
The disadvantage is that you are stuck on that project forever! They can never move you to new code since you're indispensible. A boring life but secure if you want it.
The computer screen is "Halfway" between the reading distance and the far focus. Reading glasses are for closer focus. Hence, computer glasses are highly recommended. I wouldn't be caught without mine.
Astigmatism is not caused by strain but is a (genetic?) defect. Strain makes astigmatism more of an issue.
Just break down and go to a good ophthalmologist. You might have something more serious than eyestrain, and the slashdotters can't diagnose it over the web!
I am a little suspicious of their calculation of errors per kloc. This means they are calculating the number of errors per thousand lines of source code. With this metric, you can halve the error rate by doubling the number of source lines.
Indeed, their technique seems to rely a lot on the sort of "Executable Comments" that act like assertions and other semantic statements. It could throw off their statistics.
Why is it that software engineers have to write so many dang essays? Maybe if we were as terse and un-expressive as the civil engineers our programs would work better. You ever see a few dozen essays on civil engineering in the bookstore?
The development of the language is too slow. People and machines are learning and growing faster than that. I don't much like C++, I think it's complexity is a problem. A lot of learning to program C++ is learning to work around the problems of the language, not in solving the problem at hand.
Spoken (Natural) languages are extremely complex and extremely useful. Programming languages can profitably be just as complex if they were good enough to last for as many decades as we use natural languages! If you're going to learn a new language every 5 years it constrains how complex that language can be. If you're going to use it for 50 years it's a different story. C++ isn't good enough to use for enough years to be worth the complexity.
Nevertheless, the choice of programming languages should not determine whether the app is garbage-collected or not. Although that will greatly impact libraries.
C++ is a research language that should be replaced by something that is not afraid to be incompatible with it. Java and "D" are nice tries but tie garbage collection to the language. C# is disappointing considering the size of the organization behind it. And is also tied to GC.
Software systems often contain components that need to be coded close to the machine to obtain maximum performance or flexibility or power. At least the OS. Those same software systems always contains portions of glue and convenience code that does not need to be coded close to the machine and should be coded at as high a level as possible. The challenge to language designers is to create a programming system that spans as great a height as possible without forcing the coder to migrate to different syntaxes and toolsets. C++ and OO are an attempt but don't really make it.
Server Farms like those run by Google and Amazon will, now that things can be remotely operated, moved to cooler climes like Alaska and Yellowknife, Canada. They'll put the facility in the center of an office complex that has to be heated anyway and probably provide working-hours power for free. Maybe there's one with a mall attached to extend the working day.
The result will be a new nexus of high-tech growth in the semi-polar regions. Server Farm Workers will migrate, but not as often as regular Farm Workers.
The aluminum smelting industry is even more power-dense (they locate them next to hydro-electric dams) but is too polluting to be in a city center, of course.
Don't be a diehard user. Over your career, things will change. If you're a diehard user you'll die hard when things change.
C# is a better system, technically, but Java is more popular. By that I mean the C# language is a bit more advanced. This may change. But I like the way C# handles array arguments and class-versioning. That is, when you're superclass changes on you it's a lot less likely to bite you in the butt.
In any case they'll send your job to India and invite you to work as a software tester. A CS/SE degree by itself isn't worth too much. Get another degree in something else to go with it. Math or business or genetic engineering or physics or something.
When you graduate, the interviewers may ask you if you tested anything. Lie and say no, just my unit tests. This way you avoid jobs as a software tester. Say "I just never got the hang of testing -- wrong psychology". "The other folks on the team did the testing". Or any other bull that comes to mind.
Learn lisp. It was officially declared obsolete years before you were born but that turned out to be a mistake.
Learn APL. It's so weird it will open your mind.
Do not learn PL\1.
Learn smalltalk. It's the mother of a lot.
If you want to be a software engineer/coder/hacker learn assembler. It will teach you about the machine.
C# is not a jit-based interpretive language..NET languages generate an intermediate form called IL that is similar to java byte codes but is compiled to native machine code before execution. That is, the IL is never interpreted in the sense that byte-codes are.
I've always assumed that one of the motivations for publishing IL instead of machine code was so that a single binary could distributed for different architectures. The decision to go for IL was made when Intels Itanium looked a lot better than it does now.
I don't know that MS has made claims for the execution speed of the.NET languages specifically. I am suspicious since the installation license forbids publishing benchmarks. I think that ought to be illegal. Really.
Perhaps the most useful language and most widely used is also the slowest: javascript.
But the programmers API isn't nicely documented in RoR, although there is a web page that claims to do that. For example, to search the RoR API web page you have to use google. Half the time I come up with a blank document. That is, the entry for the function I want is a blank page, and there is no context (no "up" button) so I can't use it as a starting place for more navigation.
The result of the somewhat sloppy documentation is that if I find a function that does something (like by looking at the source) I don't know if it is guaranteed to be there next release. The existing book ("Agile web programming...") is too chatty and not complete and accurate like a reference manual would be.
So I'm somewhat blindly following the examples and when something doesn't work I have to backtrack. Still, all in all, I like it. I need the speed.
And, like a lot of people, I found I had to go back and study Ruby a few times. The existing Ruby docs are great.
But I desperately want a good Rails reference manual.
Strangely enough, the US troops are defending the Iraqis right to vote. There does seem to be a constitutional democracy birthing over there in Iraq.
After living through Saddam Hussein and the two wars to take him down, a truly ghastly sequence, the Iraqis just weren't scared of the insurgent threats to stop the voting. As far as I can see, they aren't afraid of anything.
Science, not fiction, "Microbe Hunters" by Paul De Kruif. Good for all teenagers and adults of any gender whatsoever. An absolute must read in the age of AIDS, Avian Flu, and Ebola. Order it now.
See the amazon page for more info. Great as a Christmas gift. Also Hannukah, New Years, and even National Pie Day (December 2nd in the US).
Comment the data before the algorithm. Data is easier to understand. Decades ago, IBM invented a HIPO outline: Hierarchy, Input, Processing, Output. This is a checklist of what should be commented first.
Comment code by sprinkling examples: ...// Sname = "Joe User" ...// fSname = "Joe" and lSname = "User" ... ...// This regex makes sure fSname isn't '23skiddoo ...// nCount = 17 iff there are 17 people named "Joe User" in our database.
The idea is that people figure out the general from the particular better than they figure out the particular from the general. Learning goes in the reverse direction from math. First they see the pattern in the data then they begin to understand the abstract theme.
Source Code control system and IDE's need to invent a way to allow code reviewers and testers to comment the code, even when they are not allowed to alter the source.
Coding By Contract helps document things. So do assertions and Unit Tests. Executable comments, so to speak, are more believable.
Names matter. The more obscure the variable, the longer the name.
I may need to write some code with manual memory allocation, and I would then like to write the rest using GC coding methods.
I shouldn't have to change languages, change IDE's, and change the rules of disambiguating overloaded operators in order change coding paradigms.
Granted, you may not want to mix paradigms in the same thread, but having a multi-threaded app with some threads use malloc/free or C++ new-delete and other threads use GC seems entirely reasonable.
Even hard real-time systems often have portions of the code that can live with the occasional GC pause.
I shouldn't have to change languages to change paradigms, just declare a threads memory type and be consistent. Inter-thread communication will have to accomodate this, of course.
Java could have made much more of a contribution if it had done this. And C++ could have supported a standard interface to GC earlier on, to support GC code in C++. MS C++ now allows coding for managed code, but it's a little late in the game for C++. And the managed environment generates IL, not machine code, so "Managed code" is not exactly equal to "Uses GC".
Slashdot Mirror
If I remember correctly Coverity has been discussed on slashdot previously and they used the same diseased statistical thinking back then, too.
I have recently become a fan of test-driven design and recommend the discipline.
If you can use GC/managed code, then go for it. At least in those parts where you can. Memory mis-management is an important source of errors.
Get help with testing and with regression testing.
The US population is aging and having fewer kids. The European population is aging even faster and having even fewer kids. Except that the European Arabs are young and having lots of kids. Mix it all together and let me know if you figure it out...
The stuff they really need to know about is how everything is just bits and the computer is mostly stupid. A friend was today amazed that a spell checker just compares text to a list of words. He thought it knew spelling. Persuade them that the box is a robot that learned how to spell. It's close enough.
Hardware changes and is becoming increasingly hidden. Aside from the power switch and the fact that more money is needed to buy more bits, ignore it. Otherwise you'll end up teaching them the quantum mechanics of silicon transisters.
What they need to know depends on who they are and what they are trying to do. By and large the user community should only be forced to learn to use the content tools they need to manage their email, novels, photos, videos, music, pirated films, and so on.
Beyond that, all they need to know is that it's all a bucket of bits and it needs to be backed up. And you don't know if the backup is any good until you try to use it. Oh, and don't be scared of it. The only kind of damage you can do, if you don't set fire to it, is erase the data. That's right, 99.99% of all damage is data erasure. The bits are still in the hardware but they've been all turned to zeroes or "De-allocated" as we like to say.
Consider the ethics of teaching them about DRM and it might be wrong to steal.
And teach them to run the security programs that they need but aren't supposed to.
Without a good eye doctor you can't be sure if it's eye strain or eye cancer. Go get checked.
The disadvantage is that you are stuck on that project forever! They can never move you to new code since you're indispensible. A boring life but secure if you want it.
Astigmatism is not caused by strain but is a (genetic?) defect. Strain makes astigmatism more of an issue.
Just break down and go to a good ophthalmologist. You might have something more serious than eyestrain, and the slashdotters can't diagnose it over the web!
Indeed, their technique seems to rely a lot on the sort of "Executable Comments" that act like assertions and other semantic statements. It could throw off their statistics.
Why is it that software engineers have to write so many dang essays? Maybe if we were as terse and un-expressive as the civil engineers our programs would work better. You ever see a few dozen essays on civil engineering in the bookstore?
Spoken (Natural) languages are extremely complex and extremely useful. Programming languages can profitably be just as complex if they were good enough to last for as many decades as we use natural languages! If you're going to learn a new language every 5 years it constrains how complex that language can be. If you're going to use it for 50 years it's a different story. C++ isn't good enough to use for enough years to be worth the complexity.
Nevertheless, the choice of programming languages should not determine whether the app is garbage-collected or not. Although that will greatly impact libraries.
C++ is a research language that should be replaced by something that is not afraid to be incompatible with it. Java and "D" are nice tries but tie garbage collection to the language. C# is disappointing considering the size of the organization behind it. And is also tied to GC.
Software systems often contain components that need to be coded close to the machine to obtain maximum performance or flexibility or power. At least the OS. Those same software systems always contains portions of glue and convenience code that does not need to be coded close to the machine and should be coded at as high a level as possible. The challenge to language designers is to create a programming system that spans as great a height as possible without forcing the coder to migrate to different syntaxes and toolsets. C++ and OO are an attempt but don't really make it.
Uh, what drugs do they want us to test?
The result will be a new nexus of high-tech growth in the semi-polar regions. Server Farm Workers will migrate, but not as often as regular Farm Workers.
The aluminum smelting industry is even more power-dense (they locate them next to hydro-electric dams) but is too polluting to be in a city center, of course.
Let's see who was right and who was wrong. Otherwise, why try to be right?
C# is a better system, technically, but Java is more popular. By that I mean the C# language is a bit more advanced. This may change. But I like the way C# handles array arguments and class-versioning. That is, when you're superclass changes on you it's a lot less likely to bite you in the butt.
In any case they'll send your job to India and invite you to work as a software tester. A CS/SE degree by itself isn't worth too much. Get another degree in something else to go with it. Math or business or genetic engineering or physics or something.
When you graduate, the interviewers may ask you if you tested anything. Lie and say no, just my unit tests. This way you avoid jobs as a software tester. Say "I just never got the hang of testing -- wrong psychology". "The other folks on the team did the testing". Or any other bull that comes to mind.
Learn lisp. It was officially declared obsolete years before you were born but that turned out to be a mistake.
Learn APL. It's so weird it will open your mind.
Do not learn PL\1.
Learn smalltalk. It's the mother of a lot.
If you want to be a software engineer/coder/hacker learn assembler. It will teach you about the machine.
I've always assumed that one of the motivations for publishing IL instead of machine code was so that a single binary could distributed for different architectures. The decision to go for IL was made when Intels Itanium looked a lot better than it does now.
I don't know that MS has made claims for the execution speed of the .NET languages specifically. I am suspicious since the installation license forbids publishing benchmarks. I think that ought to be illegal. Really.
Perhaps the most useful language and most widely used is also the slowest: javascript.
Oh, but it's hype that has made Java into what it is today...
And can I run my pictures of Jessica Simpson on the Linux screensaver that's running in my Windows screensaver?
The result of the somewhat sloppy documentation is that if I find a function that does something (like by looking at the source) I don't know if it is guaranteed to be there next release. The existing book ("Agile web programming...") is too chatty and not complete and accurate like a reference manual would be.
So I'm somewhat blindly following the examples and when something doesn't work I have to backtrack. Still, all in all, I like it. I need the speed.
And, like a lot of people, I found I had to go back and study Ruby a few times. The existing Ruby docs are great.
But I desperately want a good Rails reference manual.
Anyway, I actually bought a copy of it in the 60's (or was it the 70's?) and was not too impressed. I probably still have a copy somewhere...
Duh!
It's online, of course! And just as boring now as it was 30 years ago. Really, a world-class snoozer.
After living through Saddam Hussein and the two wars to take him down, a truly ghastly sequence, the Iraqis just weren't scared of the insurgent threats to stop the voting. As far as I can see, they aren't afraid of anything.
Apparently even the Indians are desperate for jobs now...
See the amazon page for more info. Great as a Christmas gift. Also Hannukah, New Years, and even National Pie Day (December 2nd in the US).
Comment code by sprinkling examples:
... // Sname = "Joe User"
... // fSname = "Joe" and lSname = "User"
...
... // This regex makes sure fSname isn't '23skiddoo
... // nCount = 17 iff there are 17 people named "Joe User" in our database.
The idea is that people figure out the general from the particular better than they figure out the particular from the general. Learning goes in the reverse direction from math. First they see the pattern in the data then they begin to understand the abstract theme.
Source Code control system and IDE's need to invent a way to allow code reviewers and testers to comment the code, even when they are not allowed to alter the source.
Coding By Contract helps document things. So do assertions and Unit Tests. Executable comments, so to speak, are more believable.
Names matter. The more obscure the variable, the longer the name.
Fix slashdot to allow <code>, dang it!
I shouldn't have to change languages, change IDE's, and change the rules of disambiguating overloaded operators in order change coding paradigms.
Granted, you may not want to mix paradigms in the same thread, but having a multi-threaded app with some threads use malloc/free or C++ new-delete and other threads use GC seems entirely reasonable.
Even hard real-time systems often have portions of the code that can live with the occasional GC pause.
I shouldn't have to change languages to change paradigms, just declare a threads memory type and be consistent. Inter-thread communication will have to accomodate this, of course.
Java could have made much more of a contribution if it had done this. And C++ could have supported a standard interface to GC earlier on, to support GC code in C++. MS C++ now allows coding for managed code, but it's a little late in the game for C++. And the managed environment generates IL, not machine code, so "Managed code" is not exactly equal to "Uses GC".
For my own 2 cents, I say defund radical Islam by seizing the oil fields. Stop paying for oil!