Multiple sites does not seem to be supported, but you *can* add "site:yourfavoritecodingsite.com" to a Google query to search just that site. I guess you can just write a small script that does this for each of your favorite code related sites, use that script to enter your search queries, and hey, presto.
Failure to understand the contract of an API is what gets people. It's fine for basic functions like the C mem{cmp,move,cpy,set} functions to assume inputs are correct.
Agreed. Of course when developing that API, it's important to make the right choices for that contract, to balance performance vs. safety. In the original PC BIOS* a high priority was given to safety of the code; as such, screen I/O performance was dead slow. One could of course argue that they made the wrong choice. But hey, at least the BIOS would never crash. (* See "Personal Computer XT System Technical Reference" for the actual commented BIOS listings).
Avoiding GOTO was always about the structure of the code. It's all too easy to mess up the structure of code when GOTO is used, so as a rule of the thumb it should be avoided. However, over time people have missed the point entirely and turned the GOTO debate into a discussion about syntax, rather than structure.
It's perfectly possible to use GOTO, yet write completely structured code - how did you think a compiler translates a WHILE loop? It will use JMP/GOTO for this. Did you think the compiler changes the structure of your code even the slightest bit? Think again, because it won't. You can draw out the flow diagram of your code and it will be absolutely identical.
Not all languages have a try..finally construct. In such a language, in a function that opens, reads and closes a file, rather than duplicating cleanup code several times over for each possible error that occurs, a GOTO can be an elegant way around this; saving maintenance, maintaining readability, but most importantly, maintaining structured code.
Don't get me started on preventing programming mistakes. If I'd address the most common programming mistakes that I've ran into in the wild and write an article about each of those mistakes at a time, I would end up with a whole book on the matter and would probably call it "Growing Better Software".
I find the given top 12 list of mistakes a bit weak- I'd be able to avoid all of these and yet write horrible code. My personal recommendation for a top 12 of programming mistakes to avoid would be:
1. Failing to check function parameters before using them: null pointers, limits, lengths, etc. This will make your program unstable and/or unpredictable.
2. Spending too little time thinking about and designing the data structure of the application. This will make you get stuck when maintaining/extending your application.
3. Following every market hype - When the marketing bubble bursts, you'll have to start over again.
4. Designing user interfaces without actually involving users - You'll be surprised how easy it is to confuse users.
5. Infinitely deeply nested if/else statements - This will make code absolutely unreadable.
6. No documentation whatsoever - Who's going to maintain your code after you change jobs?
7. Ignoring existing, universally accepted standards - so you'll cause interoperability issues or be doomed to either reinvent the wheel.
8. Hard-coded values/magic numbers - as a result, any change must be made in code rather than allowing power users to configure their own system.
9. Littering code with global variables - this implies statefulness of code, making it pretty near impossible to predict how a function will behave next time it is called.
10. Being unaware of the "Big O" order of your algorithms, causing code to be unnecessarily inefficient.
11. Strong platform dependency: This can shorten the lifetime of your application to whenever the next platform upgrade takes place, or keep you stuck at the current version of the current platform forever.
12. Thinking you can figure out everything by yourself - In learning by doing, experience can only follow from making mistakes. By getting yourself a mentor or an education, you can actually learn from the mistakes that thousands have made before you.
I authored a moderately successful anti-virus program and am bothered by the reasoning that basically accuses AV authors of writing viruses. Stop it, please.
Seriously- how many viruses are out there again? Tens of thousands? Do you *really* think writing one more virus is going to have a measurable (positive) impact on anti-virus sales?
On the other hand, if Kaspersky or McAfee would be writing viruses and they were found out, what do you think that would do to their reputation? How many people do you think would drop their product like a hot potato?
The point is that with tens of thousands of viruses already out there, there is simply *no point* in spending any time and effort on writing viruses. As an AV company, rather than spending time and money on writing your own viruses, it's best to leave the virus making to virus makers. They will be doing that anyway - and so you'll have your virus ecosystem handed to you for free, without any investment from your side.
Then again, speaking as an AV author, the best anti-virus there is, is common sense combined with a (mostly) secure OS. A slight touch of raving paranoia helps as well.
Organs and bones are harvested (and bones replaced by lengths of broomstick or pvc pipe). Due care is taken for these organs and they're being used to save lives, which is arguably better than just throwing them away.
The dark side of the whole thing is that a corpse is worth roughly GBP 200k-300k in spare parts, so ethics are out of the window and organs are harvested without the consent of the deceased nor those who stayed behind.
As usual, money is the driving factor here, so there is something you can do to stop this practice if you have objections to it: Sign up as organ donor. If there are enough organ donors, the law of supply and demand will take care of the rest and make sure this practice is no longer profitable, so it will cease to exist.
Not all programmers are able to adapt to constantly changing requirements, but some are and they are the ones who succeed with agile programming.
I bet those programmers would typically be the ones that get their Information Analysis right from the start. This allows systems to be flexible enough to change. As a result, these same programmers would be successful regardless of the presence of agile.
Likewise, there are developers that don't know how to design data structures/databases that are flexible to changes. No amount of so-called agile practices will save them, as bad data structure design *will* have a SEVERE impact on maintenance. And this maintenance will only increase as the system evolves from a quick hack into legacy software.
"Does this mean that if I build PCs with Linux (Ubuntu/ChromeOS/Fedora) and sell them I am at risk of getting sued by Microsoft? "
No. They've got far more to lose than to win. Consider why anyone would need to pay MS for a product they didn't develop nor invest time in. If MS tries suing anyone for royalties, they risk being counter-sued for anti-competitive behaviour (what *else* would you call it when MS charges royalties for Linux?). They *really* don't want to be in court for anti-competitive behaviour, again. Last time it cost them, what, US$1.4 billion? 497 million euros? In any case far more than they'd ever get by suing little entrepreneurs.
I've wondered on occasion if this problem is really only due to scheduling. After all, most of us still write our file access code more or less as follows:
x=fopen('somefilename');
while ( !eof(x))
{
print readln(x,1024);/* ---- */
}
fclose(x);
Point being, there's nothing that tells the marked line that the process should gracefully go to sleep while the drive is doing its thing, and there's no callback vector defined either- nothing that indicates we're dealing with non-blocking I/O. I'd like to think that our compilers have silently been improved to hide those implementation details from us, but I have no proof that this is the case. Unless the system functions use some dirty stack manipulation voodoo to extract the return address of the function and use that as callback vector?
5. The police notice the homeless guy with professional photography gear matching your description, confiscate it and find the DNA tag 6. The police helpfully deliver your stolen goods to your door
Step 5 and 6 are more likely to be "5. The police give you a case number to chalk up for your insurance, which will then go up, and never look at the case again" and "6. Homeless guy gets away with your fancy equipment and is never to be seen again".
Why do you think the police don't care? Because they're too busy. Why are they too busy? Because the crime rates are too high. Why are the crime rates too high? Because the criminals can get away with their crimes. Why can the criminals get away with their crimes? Because the police don't care. It's not getting any better either. Now get off my lawn.
Headline should have read "Manufacturer Claims Own Product Better Than Competitor". That's all just marketing. In the end, it's up to the consumer to decide what suits them better. For me, it is the platform that does what I tell it to, rather than the platform that tells me what I can or cannot do; no amount of so-called "integration" is going to sway me to the other side.
1050 bytes for 3.75 seconds of speech is the equivalent of 2240 bits per second- good enough that an old-school 2400 baud modem would be able to transfer speech in realtime. Impressive.
But I seem to recall that the speech synthesizer of the TI-99 stored voice audio in as little as 1200 bits per second. It was well-documented enough that TI emulators emulate the speech synthesizer as well. But the sound quality left
to be desired, which is probably one area where codec2 shines.
I've listened to the example files and the sound quality seems fine- I can't tell the difference in audio quality between source and target files. Partially this may be because the source material already seems to be bandwidth-limited- probably using an 8 kHz low pass filter as is common for telephony applications.
The killer feature of HTML 5 is the canvas which permits client-side drawing. Unfortunately, the only way to enjoy this rich functionality is by having JavaScript enabled. If memory serves, JavaScript was at the base of ALL serious security vulnerabilities in the recent past. Unfortunately as well, there is no other standardized way to provide this kind of interactivity (no, Flash is not a standard). So at some point, we're going to have to choose between limiting functionality (not an option), using a nonstandard solution (introducing cross-browser compatibility problems) and/or fixing the possible security holes.
Originally JavaScript was pretty well thought-out, as scripts could only be included in the header of an HTML page. This at least made script injection in HTML pages impossible. We've got a fine company in Redmond to thank for allowing scripts in the body of HTML pages as well. Now that the can of worms has been opened, there's no way we're gonna be able to close it again. So this is a typical case where we're just going to have to deal with things. If security is an issue, don't allow JavaScript- and therefore, don't use the canvas tag.
Wow, you can deduce anything like that! Let's see- all cars are red.
Proof: Assume there are red cars. That means that there must have been a car that was the first ever red car. But paints weren't developed enough at the time to *really* call that car red- maybe it was slightly off to the purplish side. Therefore, all cars are red, even if they're not.
Up next, I'm going to deduce your mom's phone number.
And while we're at it, move your is_needle function to above find_needle. If you include files or import modules, you do that at the start of your script, not at the end! This is a leftover from the one-pass compiler days- functions are defined (or at the very least declared) before they are used.
Failing to do this will at best cause your code to compile more slowly; but worse, you'll be slapped with bad puns from your fellow developers who will complain that finding your is_needle function is like looking for needles in a haystack. You definitely don't want that to happen!
If it can't be measured with currently-available tools it doesn't exist, right?
Wrong. Their existence may be predicted by theory, and tools (such as the Large Hadron Collider) may be developed to test that theory- proving or disproving their existence. This works fine as long as the nature of that which is being measured is understood well enough. In the process, our understanding of the universe grows and new insights emerge.
In contrast- if my 4 year-old kid says he saw an invisible pink unicorn, I'm not going to go through the effort to try to prove or disprove it. After all, I've gone through such a process myself. In fact, if something however is defined as being invisible and pink at the same time, that's a contradiction in terms, so I'll be taking a leap of faith and disbelieve it. I won't tell him that though- he's only a four-year-old and doesn't know any better. Hopefully a few decades from now he'll have the sense to realize the truth- that there never was an invisible pink unicorn in the first place.
Slashdot Mirror
And PS/2 keyboards are much easier to interface with microcontrollers.
Multiple sites does not seem to be supported, but you *can* add "site:yourfavoritecodingsite.com" to a Google query to search just that site. I guess you can just write a small script that does this for each of your favorite code related sites, use that script to enter your search queries, and hey, presto.
Agreed. Of course when developing that API, it's important to make the right choices for that contract, to balance performance vs. safety. In the original PC BIOS* a high priority was given to safety of the code; as such, screen I/O performance was dead slow. One could of course argue that they made the wrong choice. But hey, at least the BIOS would never crash. (* See "Personal Computer XT System Technical Reference" for the actual commented BIOS listings).
Mod parent up.
Avoiding GOTO was always about the structure of the code. It's all too easy to mess up the structure of code when GOTO is used, so as a rule of the thumb it should be avoided. However, over time people have missed the point entirely and turned the GOTO debate into a discussion about syntax, rather than structure.
It's perfectly possible to use GOTO, yet write completely structured code - how did you think a compiler translates a WHILE loop? It will use JMP/GOTO for this. Did you think the compiler changes the structure of your code even the slightest bit? Think again, because it won't. You can draw out the flow diagram of your code and it will be absolutely identical.
Not all languages have a try..finally construct. In such a language, in a function that opens, reads and closes a file, rather than duplicating cleanup code several times over for each possible error that occurs, a GOTO can be an elegant way around this; saving maintenance, maintaining readability, but most importantly, maintaining structured code.
Don't get me started on preventing programming mistakes. If I'd address the most common programming mistakes that I've ran into in the wild and write an article about each of those mistakes at a time, I would end up with a whole book on the matter and would probably call it "Growing Better Software".
I find the given top 12 list of mistakes a bit weak- I'd be able to avoid all of these and yet write horrible code. My personal recommendation for a top 12 of programming mistakes to avoid would be:
1. Failing to check function parameters before using them: null pointers, limits, lengths, etc. This will make your program unstable and/or unpredictable.
2. Spending too little time thinking about and designing the data structure of the application. This will make you get stuck when maintaining/extending your application.
3. Following every market hype - When the marketing bubble bursts, you'll have to start over again.
4. Designing user interfaces without actually involving users - You'll be surprised how easy it is to confuse users.
5. Infinitely deeply nested if/else statements - This will make code absolutely unreadable.
6. No documentation whatsoever - Who's going to maintain your code after you change jobs?
7. Ignoring existing, universally accepted standards - so you'll cause interoperability issues or be doomed to either reinvent the wheel.
8. Hard-coded values/magic numbers - as a result, any change must be made in code rather than allowing power users to configure their own system.
9. Littering code with global variables - this implies statefulness of code, making it pretty near impossible to predict how a function will behave next time it is called.
10. Being unaware of the "Big O" order of your algorithms, causing code to be unnecessarily inefficient.
11. Strong platform dependency: This can shorten the lifetime of your application to whenever the next platform upgrade takes place, or keep you stuck at the current version of the current platform forever.
12. Thinking you can figure out everything by yourself - In learning by doing, experience can only follow from making mistakes. By getting yourself a mentor or an education, you can actually learn from the mistakes that thousands have made before you.
13. Stopping at 12.
I authored a moderately successful anti-virus program and am bothered by the reasoning that basically accuses AV authors of writing viruses. Stop it, please.
Seriously- how many viruses are out there again? Tens of thousands? Do you *really* think writing one more virus is going to have a measurable (positive) impact on anti-virus sales?
On the other hand, if Kaspersky or McAfee would be writing viruses and they were found out, what do you think that would do to their reputation? How many people do you think would drop their product like a hot potato?
The point is that with tens of thousands of viruses already out there, there is simply *no point* in spending any time and effort on writing viruses. As an AV company, rather than spending time and money on writing your own viruses, it's best to leave the virus making to virus makers. They will be doing that anyway - and so you'll have your virus ecosystem handed to you for free, without any investment from your side.
Then again, speaking as an AV author, the best anti-virus there is, is common sense combined with a (mostly) secure OS. A slight touch of raving paranoia helps as well.
That's just because a rock accidentally gets misplaced here and there.
Organs and bones are harvested (and bones replaced by lengths of broomstick or pvc pipe). Due care is taken for these organs and they're being used to save lives, which is arguably better than just throwing them away.
The dark side of the whole thing is that a corpse is worth roughly GBP 200k-300k in spare parts, so ethics are out of the window and organs are harvested without the consent of the deceased nor those who stayed behind.
As usual, money is the driving factor here, so there is something you can do to stop this practice if you have objections to it: Sign up as organ donor. If there are enough organ donors, the law of supply and demand will take care of the rest and make sure this practice is no longer profitable, so it will cease to exist.
"Female boa constrictors are capable of giving birth asexually" - Shocker indeed. I thought snakes laid eggs, rather than giving birth.
I bet those programmers would typically be the ones that get their Information Analysis right from the start. This allows systems to be flexible enough to change. As a result, these same programmers would be successful regardless of the presence of agile.
Likewise, there are developers that don't know how to design data structures/databases that are flexible to changes. No amount of so-called agile practices will save them, as bad data structure design *will* have a SEVERE impact on maintenance. And this maintenance will only increase as the system evolves from a quick hack into legacy software.
Clap....
clap...
clap.
Congratulations, America. Well done.
What's next, indeed.
You forgot Chuck Norris.
"Does this mean that if I build PCs with Linux (Ubuntu/ChromeOS/Fedora) and sell them I am at risk of getting sued by Microsoft? " No. They've got far more to lose than to win. Consider why anyone would need to pay MS for a product they didn't develop nor invest time in. If MS tries suing anyone for royalties, they risk being counter-sued for anti-competitive behaviour (what *else* would you call it when MS charges royalties for Linux?). They *really* don't want to be in court for anti-competitive behaviour, again. Last time it cost them, what, US$1.4 billion? 497 million euros? In any case far more than they'd ever get by suing little entrepreneurs.
I've wondered on occasion if this problem is really only due to scheduling. After all, most of us still write our file access code more or less as follows: x=fopen('somefilename'); while ( !eof(x)) { print readln(x,1024); /* ---- */
}
fclose(x);
Point being, there's nothing that tells the marked line that the process should gracefully go to sleep while the drive is doing its thing, and there's no callback vector defined either- nothing that indicates we're dealing with non-blocking I/O. I'd like to think that our compilers have silently been improved to hide those implementation details from us, but I have no proof that this is the case. Unless the system functions use some dirty stack manipulation voodoo to extract the return address of the function and use that as callback vector?
Step 5 and 6 are more likely to be "5. The police give you a case number to chalk up for your insurance, which will then go up, and never look at the case again" and "6. Homeless guy gets away with your fancy equipment and is never to be seen again".
Why do you think the police don't care? Because they're too busy. Why are they too busy? Because the crime rates are too high. Why are the crime rates too high? Because the criminals can get away with their crimes. Why can the criminals get away with their crimes? Because the police don't care. It's not getting any better either. Now get off my lawn.
Headline should have read "Manufacturer Claims Own Product Better Than Competitor". That's all just marketing. In the end, it's up to the consumer to decide what suits them better. For me, it is the platform that does what I tell it to, rather than the platform that tells me what I can or cannot do; no amount of so-called "integration" is going to sway me to the other side.
... taking bribes?
Or by using multiple lasers at lower intensities- so tumors will only burn where the beams cross.
Telling people not to swear is basically censorship. Guess what- censorship doesn't work, as aptly demonstrated by this video.
1050 bytes for 3.75 seconds of speech is the equivalent of 2240 bits per second- good enough that an old-school 2400 baud modem would be able to transfer speech in realtime. Impressive. But I seem to recall that the speech synthesizer of the TI-99 stored voice audio in as little as 1200 bits per second. It was well-documented enough that TI emulators emulate the speech synthesizer as well. But the sound quality left to be desired, which is probably one area where codec2 shines. I've listened to the example files and the sound quality seems fine- I can't tell the difference in audio quality between source and target files. Partially this may be because the source material already seems to be bandwidth-limited- probably using an 8 kHz low pass filter as is common for telephony applications.
The killer feature of HTML 5 is the canvas which permits client-side drawing. Unfortunately, the only way to enjoy this rich functionality is by having JavaScript enabled. If memory serves, JavaScript was at the base of ALL serious security vulnerabilities in the recent past. Unfortunately as well, there is no other standardized way to provide this kind of interactivity (no, Flash is not a standard). So at some point, we're going to have to choose between limiting functionality (not an option), using a nonstandard solution (introducing cross-browser compatibility problems) and/or fixing the possible security holes. Originally JavaScript was pretty well thought-out, as scripts could only be included in the header of an HTML page. This at least made script injection in HTML pages impossible. We've got a fine company in Redmond to thank for allowing scripts in the body of HTML pages as well. Now that the can of worms has been opened, there's no way we're gonna be able to close it again. So this is a typical case where we're just going to have to deal with things. If security is an issue, don't allow JavaScript- and therefore, don't use the canvas tag.
Wow, you can deduce anything like that! Let's see- all cars are red. Proof: Assume there are red cars. That means that there must have been a car that was the first ever red car. But paints weren't developed enough at the time to *really* call that car red- maybe it was slightly off to the purplish side. Therefore, all cars are red, even if they're not. Up next, I'm going to deduce your mom's phone number.
They'd affectionately call it "Twinkle twinkle".
And while we're at it, move your is_needle function to above find_needle. If you include files or import modules, you do that at the start of your script, not at the end! This is a leftover from the one-pass compiler days- functions are defined (or at the very least declared) before they are used.
Failing to do this will at best cause your code to compile more slowly; but worse, you'll be slapped with bad puns from your fellow developers who will complain that finding your is_needle function is like looking for needles in a haystack. You definitely don't want that to happen!
Wrong. Their existence may be predicted by theory, and tools (such as the Large Hadron Collider) may be developed to test that theory- proving or disproving their existence. This works fine as long as the nature of that which is being measured is understood well enough. In the process, our understanding of the universe grows and new insights emerge.
In contrast- if my 4 year-old kid says he saw an invisible pink unicorn, I'm not going to go through the effort to try to prove or disprove it. After all, I've gone through such a process myself. In fact, if something however is defined as being invisible and pink at the same time, that's a contradiction in terms, so I'll be taking a leap of faith and disbelieve it. I won't tell him that though- he's only a four-year-old and doesn't know any better. Hopefully a few decades from now he'll have the sense to realize the truth- that there never was an invisible pink unicorn in the first place.