our SQL devs write the longest most headache inducing code and never listen to reason. and they use the most evil invention ever, temporary tables. when there is no reason to
If you think temporary tables are the most evil invention ever, you may need to learn some more SQL yourself.
I sure wouldn't want the government or military to be able to turn off our weapons, and I sure don't support laws that say only the military and police can have the most powerful weapons. That puts the balance of power away from the people.
Yeah, I've thought about that and realized that if the purpose of the Second Amendment is to allow citizens to overthrow the government if necessary, it was completely undermined long ago. Law abiding citizens can't generally own many of the most basic weapons required to fight a modern army such as machine guns, armored vehicles and artillery.
They're still government properties, their frequencies, brands, copyrights and studios belong to the taxpayers, who paid to develop all of it. They'll be on the block soon, just like many municipal water utilities and public power utilities already are. More of the neo-liberal hogwash about how private industry is always more 'efficient' somehow will be used as the justification, or maybe "deficit reduction".
You are dead wrong. According to PBS themselves, they are not and never have been part of any government:
PBS is a private, nonprofit corporation, founded in 1969, whose members are America’s public TV stations -- noncommercial, educational licensees that operate more than 350 PBS member stations and serve all 50 states, Puerto Rico, U.S. Virgin Islands, Guam and American Samoa.
Both organizations get a significant minority of funding from the Federal government-funded Corporation For Public Broadcasting but neither NPR nor PBS is owned by the Federal government any more than the multitude of private organizations which receive some Federal funding. They probably wouldn't exist today if they hadn't been funded by the CPB and if the CPB stopped funding them altogether, they would suffer greatly. However, no part of the Federal government can sell either PBS or NPR and even if all Federal funding were cut off, they'd still have a chance of surviving on their other sources of funding.
We should be thankful for TLC (it isn't even programmed on my TV at home, but I do have to hear people talk about some of the shows at work). Anyway, TLC is the poster child for why we should never cut all funding for PBS. Because that is what the lowest common denominator turns it into.
Indeed, I hope more people are inspired to fund PBS. I haven't done my part so far but I plan to rectify that.
Regardless of what you call, no agriculture has ever been natural. Agriculture is by its very nature people manipulating nature to get a more desirable result than would occur naturally. Until people understand this basic reality, they can't think clearly about the subject. There are of course many methods of manipulating nature which can be used or misused. You may be right about the current abuses of genetic manipulation but the fault lies with those using it, not the technology itself.
Cross contamination & subsequent loss of organic certification isn't an issue then?
How about Monsanto dragging innocent farmers into court?
I don't see any mention of Monsanto in Lynas's statement. To villify genetically modified crops because Monsanto does bad things is like villifying smart phones because of Apple. Organic certification is a legal process for the purpose of marketing and has nothing to do with science or environmentalism.
I give it until the next presidential election before PBS and NPR are just plain auctioned off. They're doing their best to 'privatize' (aka 'sell public property for pennies on the dollar) everything else. Before long the Pentagon will be the only thing the taxpayers still hold the title to, and that will just be so that we can pay to protect the mega-corps overseas properties at no charge to them.
PBS and NPR have not been getting a majority of funding from any government so the Federal government cannot "privatize" them.
TLC has been owned by the same company as the Discovery Channel since 1991 so you shouldn't be surprised that the channels are moving in similar directions. I already noticed shows in common between the two channels in the mid-90s. Until I just read the Wikipedia article, I was completely unaware of TLC's origins from Federal agencies. It sounds like it may have been much better in the 70s and 80s.
Look, c has "real strings." They're trivially easy to deal with; if such management is actually beyond a programmer's skills, they're working in the wrong field. Starting with the basic 0-terminated model, you can create any kind of string management / data structure you want. That's the beauty of c. You can do anything you think you need to.
If only we could clone you millions of times, we wouldn't have buffer overflow vulernabilities, but I doubt people would be able to stand so many elitist pricks.
Look, c has "real strings." They're trivially easy to deal with; if such management is actually beyond a programmer's skills, they're working in the wrong field. Starting with the basic 0-terminated model, you can create any kind of string management / data structure you want. That's the beauty of c. You can do anything you think you need to.
malloc() is a crutch. If you can't write your own allocator, you don't deserve to call yourself a programmer.
The Heemeyer Bulldozer had a very different purpose, which was to allow Heemeyer to continue destroying buildings while the police tried to stop him. Neither offensive firepower nor maneuverability was a priority, but protection was. This vehicle is probably meant to protect those inside while it's going somewhere, implying a need for more maneuverability at the cost of protection. It is also apparently intended to be used against enemy soldiers. It's clearly far from an ideal design, but even an ideal one likely wouldn't be as well-protected as the Heemeyer Bulldozer.
A tank requires three things: heavy armor, a turret-mounted gun capable of anti-tank combat, and the use of tracks instead of wheels.
This arguably fails all three. It's a wheeled vehicle, and that 7.62mm gun may as well be paintballs to other tanks - it's a common caliber for the coax gun on modern tanks, for use when you don't want to waste your expensive ammo against mere infantry. The armor is definitely insufficient to handle modern tanks, but it would have been enough for 20's and '30s tanks (or perhaps WW2-era Italian or Japanese tanks), so you could probably squeeze it in.
That said, as long as the rebels use it intelligently, an armored car is a very useful tool. Keep it in the cities, where tanks have difficulty maneuvering, but use its mobility to outflank infantry. It will be interesting to see how long it lasts - it doesn't look like it could handle modern anti-tank missiles, but it *might* stand up to an RPG-7 or so.
It's certainly true that this does not come close to the commonly accepted definition of "tank" since the 1930s. However, it's interesting to note that the term evolved quite a bit from its first use. The original tanks in WWI did have tracks, but they did not have turrets, anti-tank guns or thick armor. There were designed to protect the crew from enemy machine gun and artillery fire, which is probably all this vehicle is intended for. The RPG-7 can penetrate at least 260mm of steel, more than ten times the thickness on this vehicle.
So I did some more looking and it really is a death trap. The wheels are still exposed, and the steel is at most 1/4 to 1/2 inch thick, which would easy be penetrated by an AK-47 or an Nato 556 round. It is really just a death trap.
You may be right about it being a death trap, but TFA says it has 25mm armor (about one inch). That would certainly not be easily penetrated by most small arms.
It does look like an interesting design, but making an armored vehicle surive enemy fire is a lot harder than mounting cameras on it. This vehicle has slabs of steel, not the composite or reactive armor found on truly state of the art vehicles. That's what costs the big bucks.
As soon as Steamboat Mickey is in the public domain I'm going to burn that shit on billions of DVDs and just sell it on the street. I will be RICH cuz everyone wnats da Steamboat Mickey
Who is this "Mickey" you speak of? Perhaps you meant Steamboat Itchy.
W. RIchard Stevens had a pretty good approach to error-handling in "Advanced Programming in the UNIX Environment". In most cases, he wrapped system calls or library calls in wrappers that would test for errors and abort with an error message on failure. These wrappers meant that the main program could forget about error-checking.
In the relatively rare cases in which the main program felt it could recover from an error, it would call the system call directly and handle the error itself. This led to pretty clean but still very safe code.
Naturally, this approach is inappropriate for authors of library code, but it's great for the main body of an application.
That just sounds like a crippled version of the exception system in many modern languages. It'll throw exceptions but offers no way to catch them.
The biggest problem with exceptions is that they get thrown too far, changing them into comefroms (the opposite of a goto). And like gotos, they encourage spaghetti code. The best way to deal with them is to limit them to thrown exceptions only to their callers. That way, all exceptions become part of the subroutine's interface. Remember, for a programmer, out of sight is out of mind. If it's not part of the interface, it will be forgotten. For those who are interested, you can read my blog for details and an example.
Yeah, writing five exception handlers, each just throwing the exception again is so much better than handling it once.
It doesn't matter whether we use exceptions or error codes to signal the errors as long as the program is designed to accurately interpret the errors that do occur. In some sense, exceptions may be easier to implement in today's event-driven interactive interfaces. Regardless, though, the design must not allow errors to be lost.
Good luck anticipating every error condition possible during your program's run time.
Ultimately while I'm not usually a fan of web apps in general, they are a perfect solution for email (which is probably why webmail is so popular).
What exactly have you had terrible luck with? What IMAP servers or services have you used? I use Thunderbird to access my mail both on the company's IMAP server (running Dovecot) as well as Gmail all the time. Since I discovered IMAP in the late 90's, I never looked back. Of course, there have been buggy servers and clients, but I've had far more success than failure.
So far the state of standalone clients compared to webmail is pretty dismal. I'm using Thunderbird now but I really miss a search function that works, as well as an addressbook that doesn't have arbitrary limitations such as a maximum of two email addresses per contact.
Thunderbird's search certainly works, but it's not as good as Gmail's. Its conversations are also useful but not as nice as Gmail's. Those are the areas it could really stand to improve.
I really haven't used a desktop client for email in years. Where's the gain for the user?
I want my mail and calendar wherever I am. So why keep multiple copies of gigabytes of mail on multiple machines. I just don't see the gain for the average user. I think the lack of demand from users who are moving to webmail is why the Thunderbird is getting less developer attention.
What I'd really like to see is improvement in the webmail interfaces available to us. Gmail is fast, but I find the interface limiting and clunky. The best I have experienced was Zimbra, but it really prefers to be run on a standalone machine and is pretty resource intensive.
Perhaps you're not aware of a little thing called IMAP. You may be able to run your own web mail server, but that's not realistic for the vast majority of users. For some people, Gmail or another hosted web mail system is good enough. For everybody else, email clients are still important.
I used to be a big fan of white spaces and for small projects it is easy to keep in your head the nesting level at which code should be, but when you are editing someone else's code in a 1000 KLOC project it is much more difficult to remember where it should be. As I said it is an inordinately common source of bugs.
Are those million lines of code in one module? Is the nesting depth greater than 8? Those are indications of poor code organization regardless of language or block style. If your modules are not too big and code is not too deeply nested, the way the language indicates block structure has little interaction with the overall size of the project. I read and write Python code written by me and others all day long and almost never encounter bugs resulting from white space.
That a consequence of improper polymorphism, not static typing. Again once you get past 100 KLOC it gets very hard to keep types and names straight. You need the compiler/interpreter to flag you went you write ParetoOptimizer instead of ParetoOptimized or some similar type error.
You need something to check for bad names and syntax errors. It doesn't have to be a compiler or interpreter. I run several static code checkers constantly via my editor so I can immediately see if I misspelled a variable name or left off a closing paren or something. If you would run a compiler to check static correctness of C or Java, why not run a checker on Python? There are several commonly used checkers. Here's a discussion comparing their relative merits.
Slashdot Mirror
our SQL devs write the longest most headache inducing code and never listen to reason. and they use the most evil invention ever, temporary tables. when there is no reason to
If you think temporary tables are the most evil invention ever, you may need to learn some more SQL yourself.
I sure wouldn't want the government or military to be able to turn off our weapons, and I sure don't support laws that say only the military and police can have the most powerful weapons. That puts the balance of power away from the people.
Yeah, I've thought about that and realized that if the purpose of the Second Amendment is to allow citizens to overthrow the government if necessary, it was completely undermined long ago. Law abiding citizens can't generally own many of the most basic weapons required to fight a modern army such as machine guns, armored vehicles and artillery.
They're still government properties, their frequencies, brands, copyrights and studios belong to the taxpayers, who paid to develop all of it. They'll be on the block soon, just like many municipal water utilities and public power utilities already are. More of the neo-liberal hogwash about how private industry is always more 'efficient' somehow will be used as the justification, or maybe "deficit reduction".
You are dead wrong. According to PBS themselves, they are not and never have been part of any government:
PBS is a private, nonprofit corporation, founded in 1969, whose members are America’s public TV stations -- noncommercial, educational licensees that operate more than 350 PBS member stations and serve all 50 states, Puerto Rico, U.S. Virgin Islands, Guam and American Samoa.
.
NPR is a "privately and publicly funded non-profit membership media organization."
Both organizations get a significant minority of funding from the Federal government-funded Corporation For Public Broadcasting but neither NPR nor PBS is owned by the Federal government any more than the multitude of private organizations which receive some Federal funding. They probably wouldn't exist today if they hadn't been funded by the CPB and if the CPB stopped funding them altogether, they would suffer greatly. However, no part of the Federal government can sell either PBS or NPR and even if all Federal funding were cut off, they'd still have a chance of surviving on their other sources of funding.
We should be thankful for TLC (it isn't even programmed on my TV at home, but I do have to hear people talk about some of the shows at work). Anyway, TLC is the poster child for why we should never cut all funding for PBS. Because that is what the lowest common denominator turns it into.
Indeed, I hope more people are inspired to fund PBS. I haven't done my part so far but I plan to rectify that.
Regardless of what you call, no agriculture has ever been natural. Agriculture is by its very nature people manipulating nature to get a more desirable result than would occur naturally. Until people understand this basic reality, they can't think clearly about the subject. There are of course many methods of manipulating nature which can be used or misused. You may be right about the current abuses of genetic manipulation but the fault lies with those using it, not the technology itself.
Cross contamination & subsequent loss of organic certification isn't an issue then?
How about Monsanto dragging innocent farmers into court?
I don't see any mention of Monsanto in Lynas's statement. To villify genetically modified crops because Monsanto does bad things is like villifying smart phones because of Apple. Organic certification is a legal process for the purpose of marketing and has nothing to do with science or environmentalism.
I give it until the next presidential election before PBS and NPR are just plain auctioned off. They're doing their best to 'privatize' (aka 'sell public property for pennies on the dollar) everything else. Before long the Pentagon will be the only thing the taxpayers still hold the title to, and that will just be so that we can pay to protect the mega-corps overseas properties at no charge to them.
PBS and NPR have not been getting a majority of funding from any government so the Federal government cannot "privatize" them.
TLC has been owned by the same company as the Discovery Channel since 1991 so you shouldn't be surprised that the channels are moving in similar directions. I already noticed shows in common between the two channels in the mid-90s. Until I just read the Wikipedia article, I was completely unaware of TLC's origins from Federal agencies. It sounds like it may have been much better in the 70s and 80s.
Look, c has "real strings." They're trivially easy to deal with; if such management is actually beyond a programmer's skills, they're working in the wrong field. Starting with the basic 0-terminated model, you can create any kind of string management / data structure you want. That's the beauty of c. You can do anything you think you need to.
If only we could clone you millions of times, we wouldn't have buffer overflow vulernabilities, but I doubt people would be able to stand so many elitist pricks.
Look, c has "real strings." They're trivially easy to deal with; if such management is actually beyond a programmer's skills, they're working in the wrong field. Starting with the basic 0-terminated model, you can create any kind of string management / data structure you want. That's the beauty of c. You can do anything you think you need to.
malloc() is a crutch. If you can't write your own allocator, you don't deserve to call yourself a programmer.
The Heemeyer Bulldozer had a very different purpose, which was to allow Heemeyer to continue destroying buildings while the police tried to stop him. Neither offensive firepower nor maneuverability was a priority, but protection was. This vehicle is probably meant to protect those inside while it's going somewhere, implying a need for more maneuverability at the cost of protection. It is also apparently intended to be used against enemy soldiers. It's clearly far from an ideal design, but even an ideal one likely wouldn't be as well-protected as the Heemeyer Bulldozer.
That is not a tank. That's an armored car.
A tank requires three things: heavy armor, a turret-mounted gun capable of anti-tank combat, and the use of tracks instead of wheels.
This arguably fails all three. It's a wheeled vehicle, and that 7.62mm gun may as well be paintballs to other tanks - it's a common caliber for the coax gun on modern tanks, for use when you don't want to waste your expensive ammo against mere infantry. The armor is definitely insufficient to handle modern tanks, but it would have been enough for 20's and '30s tanks (or perhaps WW2-era Italian or Japanese tanks), so you could probably squeeze it in.
That said, as long as the rebels use it intelligently, an armored car is a very useful tool. Keep it in the cities, where tanks have difficulty maneuvering, but use its mobility to outflank infantry. It will be interesting to see how long it lasts - it doesn't look like it could handle modern anti-tank missiles, but it *might* stand up to an RPG-7 or so.
It's certainly true that this does not come close to the commonly accepted definition of "tank" since the 1930s. However, it's interesting to note that the term evolved quite a bit from its first use. The original tanks in WWI did have tracks, but they did not have turrets, anti-tank guns or thick armor. There were designed to protect the crew from enemy machine gun and artillery fire, which is probably all this vehicle is intended for. The RPG-7 can penetrate at least 260mm of steel, more than ten times the thickness on this vehicle.
So I did some more looking and it really is a death trap. The wheels are still exposed, and the steel is at most 1/4 to 1/2 inch thick, which would easy be penetrated by an AK-47 or an Nato 556 round. It is really just a death trap.
You may be right about it being a death trap, but TFA says it has 25mm armor (about one inch). That would certainly not be easily penetrated by most small arms.
It does look like an interesting design, but making an armored vehicle surive enemy fire is a lot harder than mounting cameras on it. This vehicle has slabs of steel, not the composite or reactive armor found on truly state of the art vehicles. That's what costs the big bucks.
As soon as Steamboat Mickey is in the public domain I'm going to burn that shit on billions of DVDs and just sell it on the street. I will be RICH cuz everyone wnats da Steamboat Mickey
Who is this "Mickey" you speak of? Perhaps you meant Steamboat Itchy.
W. RIchard Stevens had a pretty good approach to error-handling in "Advanced Programming in the UNIX Environment". In most cases, he wrapped system calls or library calls in wrappers that would test for errors and abort with an error message on failure. These wrappers meant that the main program could forget about error-checking.
In the relatively rare cases in which the main program felt it could recover from an error, it would call the system call directly and handle the error itself. This led to pretty clean but still very safe code.
Naturally, this approach is inappropriate for authors of library code, but it's great for the main body of an application.
That just sounds like a crippled version of the exception system in many modern languages. It'll throw exceptions but offers no way to catch them.
The biggest problem with exceptions is that they get thrown too far, changing them into comefroms (the opposite of a goto). And like gotos, they encourage spaghetti code. The best way to deal with them is to limit them to thrown exceptions only to their callers. That way, all exceptions become part of the subroutine's interface. Remember, for a programmer, out of sight is out of mind. If it's not part of the interface, it will be forgotten. For those who are interested, you can read my blog for details and an example.
Yeah, writing five exception handlers, each just throwing the exception again is so much better than handling it once.
It doesn't matter whether we use exceptions or error codes to signal the errors as long as the program is designed to accurately interpret the errors that do occur. In some sense, exceptions may be easier to implement in today's event-driven interactive interfaces. Regardless, though, the design must not allow errors to be lost.
Good luck anticipating every error condition possible during your program's run time.
Please, tell us how to handle errors correctly, oh enlightened one.
Yeah, if the network connection resets, the user probably bumped the cable. File not Found? User error. Such lusers don't deserve to use software.
Personally I've had terrible luck with IMAP.
Ultimately while I'm not usually a fan of web apps in general, they are a perfect solution for email (which is probably why webmail is so popular).
What exactly have you had terrible luck with? What IMAP servers or services have you used? I use Thunderbird to access my mail both on the company's IMAP server (running Dovecot) as well as Gmail all the time. Since I discovered IMAP in the late 90's, I never looked back. Of course, there have been buggy servers and clients, but I've had far more success than failure.
So far the state of standalone clients compared to webmail is pretty dismal. I'm using Thunderbird now but I really miss a search function that works, as well as an addressbook that doesn't have arbitrary limitations such as a maximum of two email addresses per contact.
Thunderbird's search certainly works, but it's not as good as Gmail's. Its conversations are also useful but not as nice as Gmail's. Those are the areas it could really stand to improve.
I really haven't used a desktop client for email in years. Where's the gain for the user?
I want my mail and calendar wherever I am. So why keep multiple copies of gigabytes of mail on multiple machines. I just don't see the gain for the average user. I think the lack of demand from users who are moving to webmail is why the Thunderbird is getting less developer attention.
What I'd really like to see is improvement in the webmail interfaces available to us. Gmail is fast, but I find the interface limiting and clunky. The best I have experienced was Zimbra, but it really prefers to be run on a standalone machine and is pretty resource intensive.
Perhaps you're not aware of a little thing called IMAP. You may be able to run your own web mail server, but that's not realistic for the vast majority of users. For some people, Gmail or another hosted web mail system is good enough. For everybody else, email clients are still important.
I think the white space is mainly a red herring,
I used to be a big fan of white spaces and for small projects it is easy to keep in your head the nesting level at which code should be, but when you are editing someone else's code in a 1000 KLOC project it is much more difficult to remember where it should be. As I said it is an inordinately common source of bugs.
Are those million lines of code in one module? Is the nesting depth greater than 8? Those are indications of poor code organization regardless of language or block style. If your modules are not too big and code is not too deeply nested, the way the language indicates block structure has little interaction with the overall size of the project. I read and write Python code written by me and others all day long and almost never encounter bugs resulting from white space.
That a consequence of improper polymorphism, not static typing. Again once you get past 100 KLOC it gets very hard to keep types and names straight. You need the compiler/interpreter to flag you went you write ParetoOptimizer instead of ParetoOptimized or some similar type error.
You need something to check for bad names and syntax errors. It doesn't have to be a compiler or interpreter. I run several static code checkers constantly via my editor so I can immediately see if I misspelled a variable name or left off a closing paren or something. If you would run a compiler to check static correctness of C or Java, why not run a checker on Python? There are several commonly used checkers. Here's a discussion comparing their relative merits.