The existing energy companies can just invest in promising alternates
They do and have been doing. This is an oversimplification, the stages do overlap a lot. Drill into small isolated pockets. Lots of places have some but not much oil. Primary recovery. Drill a hole and pump out the oil. Very cheap production. Secondary recovery. Pump water into the formation so you can get more oil out. Tertiary recovery. Pump a propant under sufficiently high pressure to fracture the formation so you can get more oil out. Tar sands. Mine the tar sand, extract the bitumen with steam, run the bitumen through a coker and combine the lighter product into a synthetic crude oil. Oil shales. Like tar sands but requires hard-rock mining and messier extraction. Low-grade coal reserves. Run through cracking or coal gassification.
We're a long way from running out of energy sources. What we're running out of are lots of cheap and easy energy sources.
Microsoft isn't responsible for the underhanded tactics of spyware pushers.
Sorry, I can't let that one go. Microsoft is responsible for the dark which gives the spyware pushers lots of places to hide their underhanded tactics.
[x] Hide File Extensions. [x] Hide System Files and Folders
Something like This page contains ActiveX components that might not be safe. Only choice is to click OK.
Microsoft may not be doing it, but it seems like Microsoft is doing everything in its power to encourage it.
That last vulnerability in Mozilla/FireFox/whatever. With open source, it's a bug, It's a vulnerability. With Microsoft, the same behavior is a feature. Regardless of who discovers or closes which holes, the net result is completely predictable (trend since Melissa), and Microsoft has been, is, and will continue to get precisely what it has been asking for. With or without the new service pack, the next round will even worse. If the service pack actually closes a bunch of stuff, whoever is doing the malware will just have to work a little harder. Open Source is hardly perfect, but it can react fast, and can, when and if necessary, cut to the root of the problem.
I've done this on a couple occasions when programs have failed and I needed them not to.
The program is a tool. You have a beginning state, do some stuff, and have an ending state. As long as you wind up with an ending state which adequate for your purposes, you shouldn't have to care what kind of snit the program happens to get itself into.
The program has certain core functionality which went in early and should be both well debugged and robust. It will have gathered into itself a fair amount of cruft (aka improvements) which are somewhat sensitive, not well debugged, and not very robust. They are particularly prone to failure in contexts where they are extraneous to what is going on an being done.
dBASE5 for DOS has an option for error control where the user can choose to cancel or ignore the error. This is IGNORE not FIX. However about 95%+ of the time the IGNORE is as effective as FIX, in fact seems like most seem to think it does mean FIX. Even more fun in a debugger, since there's not reason to let the mere fact that a program is unrunnable keep you from running it.
It allows it to survive errors but on the downside those exceptions are triggered for a reason. From the inside, there is a problem with computing the sum of 2+3+beware-the-gonkulator. From the inside there is no way to ascertain the significance of the error. From the outside, if gonkulators were important, the inside would have no troble handling them. There are no internal constructs for add this if you can find it or store this if the place exists to store it in. Something like an ON ERROR NEXT at least keeps the whole mess from stopping cold on irrelevant errors.
[Obligatory Windows bashing] If you use the GUI to copy a mess of files from one place to another and the copy runs into any problem, it stops there, after having processed the stuff it did in random order. Very annoying.
Smart Users, Dumb Computer. You can actually accomplish a lot more that way. Also it gives you at least a fighting chance against the "click on everything".
You do not need every math to be a great software architect. [Emphasis added]
The statement is true if there exists any math which is not required to be a great software architect. The statement is totally irrelevant regarding "taking a lot of math will make you a better software developer". It's been over a century since any mere human was capable of knowing every math.
If you did understand the required maths, you could stick the whole of software architecture into a tiny corner of algebraic topology and actually be capable of producing usable software architectures.
Don't you think IBM thought rolling their own would have alienated the community back when
I dpn't think it would have alienated the community so much as it would have made IBM politically dependent on a single vendor for its own purposes.
Also cutting edge is sometimes bleeding edge, things break, and it's highly desirable to be in a position that avoids any appearance of complicity or duplicity when... well, when reality happens. A little bit of leftover debugging code can stir up an awful lot of controversy. IBM still remember its anti-trust rounds and is in no mood to go there ever again.
An IBM boxed set of Linux would sell very well, but this is exactly the business that Red Hat decided to get out of. (Curses, etc., but I can't really blame 'em). Official Red Hat Professional 6.2 in a nice big box. Later boxes smaller (even with more "stuff") in them. Sure there's Fedora Core, but you can't buy a boxed set.
benefits of a 'fire engine' without a siren, hose or ladder I'd be more interested in the pump and the tools to connect to an available fire hydrant, without which the stuff that looks like fire engine isn't going to do much good. There's lots of fires where a grown-up version of a toy fire engine is pretty much useless.
If it's efficient and stable I'll definitely be pushing students this way rather than letting them use MySQL (with which I've been massively disappointed
For your purposes, probably better. A toy is something you can play with. Desirable for students. Industrial-grade, due to factors such as sheer volume, has non-toy aspects. A PC lives in a big-computer, small-problem world. You do things on a PC because you want to. A mainframe lives in a small-computer, big-problem world. You do things on a mainframe because you have to.
At any point in real time, MySQL has exactly ONE system state. This state is advanced by atomic SQL statements. This means that readers and writers DO interfere with each other. This also vastly simplifies the overall system as there is never a system-induced rollback due to two or more concurrent versions of the system depending on incompatible uncommitted updates. The penalty is that you need to know what you are doing.
Where readers do not interfere with writers, there must be concurrently more than one system state to accomodate the forked state of the system. An update within a transaction may conflict with an update in a different transaction. Depending on when cognizance is taken, something that thought it completed successfully will be informed that it did not. Now what? As a general rule, the world of error recovery is an order of magnitude more complicated than normal and will be permitted an order of magnitude less resources with which to accomplish its requirements. SOP with flakey Windows systems is to kill power. Do not "Shut down". Do not "Log off". Coming back up from a power failure has been pretty well tested and debugged. Saving and restoring whatever strange state you got the system in has probably never even been considered for testing, let alone doing anything about it. Whatever brain damage is currently in memory do not give it a chance to make it permanent.
It's nice and easy to set up and a lot of easy stuff can be done without thinking, but MySQL is not a toy. What would be intersting would be to see a comparison of the hardware base from a maxed-out MySQL to a "real" DBMS capable of handling the same load.
Probably better. The MySQL system is consistent with atomic SQL statements The design of MySQL is (at least was) to have a SQL-looking interface to a system that
You see some things and are blind to some things. You know how to do some things (in a particular way) and can't see them if they're done in a different way. You see patterns and react to what you expect to be there. There just isn't enough time to read everything.
The above "you" is a me too.
This does have relevance for "Intellectual Property" in that: You can have a bunch of petty fiefdoms each guarding its own petty turf with the net result that stuff has much less tendency to flow from place to place. Imagine the freeway system where each farmer collects a toll from the traffic that passes through what once were his fields. Imagine Customs and duties paid on all traffic that passes through state and city borders. Goods from far off become exhorbitantly expensive and people make do with less and much less of what comes from far off and we're all the poorer for it, including the toll collectors. The state-of-the-art is maybe improving, but it doesn't take a lot of petty hassles and annoyances to make it very unworthwhile to upgrade much of anything.
IF you are measuring it. IF you know the lines come from the exact same point, THEN you know that any circle around that point is exactly 360 degrees. But not if the 2-space is non-Euclidian. Mapmakers have this problem.
Working with computers, you should learn how much the precision affects your calculations. If you can CALCULATE to a higher precision, then do so. Until you run into rounding problems. There's a reason for COBOL's packed decimal. Things like nnn.nn add straight without coming up with silliness like 123.444444444497. Working with higher precision has the annoying property of ensuring round-off anomalies.
Machines do not cope well with ambiguity, at least not any that I've ever run across. Humans have always had to cope with an ambiguous world. It isn't just a problem of parsing, it a problem of what the elements are that it is parsed into. The meanings of the words are in part determined by the context in which they are used.
It's a victory for Microsoft, because Microsoft isn't having to lower their prices for everyone else.
I wouldn't be too sure about that. Best delay any high-price committments and see what develops. Otherwise you risk buying it a week before it goes on sale.
Not exactly. I'd say the point is to be Unix without being called Unix. By being better it cuts the ground out from under the ownership of the name.
Vastly oversimplifying, and a lot of this is by association with the hardware it run on. Unix 1. AT&T Unix. Very expensive and underpowered hardware by today's standards. Unix 2. Berkeley Unix. Amazing what you can do with cheap grad student labor. Unix 3. Linux. Triumph of anarchy. Product of the internet.
The name Unix is applicable to Unix 1 and some variants of Unix 2. GNU utilities make Unix useable. GNU/Linux further undermines the name. Linux on IBM mainframes and supercomputers (and everything else) is a new (GNU if you like puns) generation. Even if it's mostly due to the hardware, you gotta stick a lablel on it.
How do they know Google isn't doing the same, only more subtly?
Google has their standards. This does not mean that I know what they are. This does not mean that Google always follows them. This does not mean that they are always the highest in the industry.
The same will apply to the New York Times (and I'm sure plenty of others). Reporter fakes stories and the powers-that-be "are not amused".
Both are "main-line" and I see no reason either should feel any compulsion to feature any and all crack-pots that come along. They both have some sense of journalistic integrity and a reputation that they value and will do things to destroy it light. I'm not saying there's anything in common between them except that both seem rather trustworthy and likely to remain so.
If I choose Google, then I halfway expect and am not annoyed by Google giving itself some kind of preference. If I do not choose MSN, but have it thrust upon me, any indication of preference by Microsoft's MSN to other entities tied to Microsoft that put Microsoft's name in my face to further Microsoft's idea of Microsoft's mind-share of Microsoft's captive audience, becomes more than a little annoying and Microsoft becomes a synonym for aggravation. It's not that Google can do no wrong, it's that they'd have to fall so far to match Microsoft that "Google can do no wrong" is an effective abbreviation of the long-winded fully qualified reality.
That has been the perception and that is the point of the Microsoft ads. It doesn't really, but that's another issue.
Considering the technical knowledge of management in most companies, these are exactly the hands that you do not want to have power. Errrr, there's something backwards here. The fundamental nature of management is that it is management that has the power. IT is there to serve the priorities of management, not the other way around.
What is happening is that Windows is slowly taking over the joint, and to be perceived to be doing so by PHBs. The PHBs will not like that.
Something I read a long time ago put a value of 85% on the overlap of the skill set for good programmers and good managers. Both have to deal with conflicting priorities and limited resources.
"The bug isn't here, we tested this module thoroughly."
You haven't seen many bugs, have you? Sorry, I'm sure you have, but bugs are extremely adept at hiding in places where you "dont have places". I've run into too many doubles and even a triple where the interactions were subtle enough that a bug was discernable only in the combination. Fix either (any in the case of the triple) and the problem goes away. Fix both,... repeat.
I would class as a bug, any behavior which departs from what the specs should be. If the specs are wrong that doesn't make the program right. If it is impossible for the bug to show itself, there is still a bug. I think part of the problem is the implicit assumption that it is even possible, let alone easy, to write bug-free code. With the possible exception of some stuff by Knuth, nobody does.
is an oxymoron. Difficult if there is no logic and no interactions.
Scripts will be of some help. Probably best will be long complicated sequences of operations whose net effect must logically be precisely nothing.
If you're lazy like me, integrate first, and every module is responsible for not going beserk in the presence of buggy neighbors. Too much software seems designed to assume that everything else is perfect. The old game of "gossip" shows that even if everything is perfect, your idea of perfect and my idea of perfect may not perfectly coincide.
Exactly, assuming you mean worth or value as opposed to effort or cost.
There is also the fact that it takes considerable time skill and effort to make something smaller.
I think we can do this project with $BIGFOO KLOC" with a straight face scares me.
What the program does -- asset. The lines of code it takes to do it in -- liability.
As a measure of what it would cost to do it, maybe reasonable. There is a trap if KLOC are considered a usable metric of progress. Following the rule of 90% of anything is garbage, it should be possible to spend 90% of the time on the first 10% that matters and get it right, then spend 10% of the time on the remaining 90% garbage. Any trust in a KLOC metric will do the 90% garbage first, making the "remaining" 10% non-garbage essentially undoable. Odds for which view will be takern?
Yes, but it's always a good idea to be able to tell the difference. UltraDev at least used to have a server behavior (chunk of code) that would check if the user's login was valid. If invalid, the code would send a redirect and then fall through and proceed merrily to produce the html that the user was supposed to be locked out of.
There's a psychological trap in the ON ERROR or try... catch in the assumption that one can/should actually be able to do something about trapped errors. The problem space is about an order of magnitude more complicated and the required tools simply do not exist (probable exception of LISP) to do a fix-up and a retry or ignore with the proper scope. What annoys me is using medium effort to field a small error that becomes then a big error. With PHP or Perl, if you don't want to die, then don't say die.
Slashdot Mirror
The existing energy companies can just invest in promising alternates
They do and have been doing.
This is an oversimplification, the stages do overlap a lot.
Drill into small isolated pockets. Lots of places have some but not much oil.
Primary recovery. Drill a hole and pump out the oil. Very cheap production.
Secondary recovery. Pump water into the formation so you can get more oil out.
Tertiary recovery. Pump a propant under sufficiently high pressure to fracture the formation so you can get more oil out.
Tar sands. Mine the tar sand, extract the bitumen with steam, run the bitumen through a coker and combine the lighter product into a synthetic crude oil.
Oil shales. Like tar sands but requires hard-rock mining and messier extraction.
Low-grade coal reserves. Run through cracking or coal gassification.
We're a long way from running out of energy sources. What we're running out of are lots of cheap and easy energy sources.
This sounds extremely implausible.
I don't follow the scene at all anymore, but unless things have changed drastically, that would be the norm.
Microsoft isn't responsible for the underhanded tactics of spyware pushers.
Sorry, I can't let that one go.
Microsoft is responsible for the dark which gives the spyware pushers lots of places to hide their underhanded tactics.
[x] Hide File Extensions.
[x] Hide System Files and Folders
Something like This page contains ActiveX components that might not be safe. Only choice is to click OK.
Microsoft may not be doing it, but it seems like Microsoft is doing everything in its power to encourage it.
That last vulnerability in Mozilla/FireFox/whatever.
With open source, it's a bug, It's a vulnerability.
With Microsoft, the same behavior is a feature.
Regardless of who discovers or closes which holes, the net result is completely predictable (trend since Melissa), and Microsoft has been, is, and will continue to get precisely what it has been asking for. With or without the new service pack, the next round will even worse. If the service pack actually closes a bunch of stuff, whoever is doing the malware will just have to work a little harder. Open Source is hardly perfect, but it can react fast, and can, when and if necessary, cut to the root of the problem.
I've done this on a couple occasions when programs have failed and I needed them not to.
The program is a tool. You have a beginning state, do some stuff, and have an ending state. As long as you wind up with an ending state which adequate for your purposes, you shouldn't have to care what kind of snit the program happens to get itself into.
The program has certain core functionality which went in early and should be both well debugged and robust. It will have gathered into itself a fair amount of cruft (aka improvements) which are somewhat sensitive, not well debugged, and not very robust. They are particularly prone to failure in contexts where they are extraneous to what is going on an being done.
dBASE5 for DOS has an option for error control where the user can choose to cancel or ignore the error. This is IGNORE not FIX. However about 95%+ of the time the IGNORE is as effective as FIX, in fact seems like most seem to think it does mean FIX. Even more fun in a debugger, since there's not reason to let the mere fact that a program is unrunnable keep you from running it.
It allows it to survive errors but on the downside those exceptions are triggered for a reason.
From the inside, there is a problem with computing the sum of 2+3+beware-the-gonkulator. From the inside there is no way to ascertain the significance of the error. From the outside, if gonkulators were important, the inside would have no troble handling them. There are no internal constructs for add this if you can find it or store this if the place exists to store it in. Something like an ON ERROR NEXT at least keeps the whole mess from stopping cold on irrelevant errors.
[Obligatory Windows bashing] If you use the GUI to copy a mess of files from one place to another and the copy runs into any problem, it stops there, after having processed the stuff it did in random order. Very annoying.
Smart Users, Dumb Computer. You can actually accomplish a lot more that way. Also it gives you at least a fighting chance against the "click on everything".
You do not need every math to be a great software architect. [Emphasis added]
The statement is true if there exists any math which is not required to be a great software architect.
The statement is totally irrelevant regarding "taking a lot of math will make you a better software developer".
It's been over a century since any mere human was capable of knowing every math.
If you did understand the required maths, you could stick the whole of software architecture into a tiny corner of algebraic topology and actually be capable of producing usable software architectures.
Don't you think IBM thought rolling their own would have alienated the community back when
... well, when reality happens. A little bit of leftover debugging code can stir up an awful lot of controversy. IBM still remember its anti-trust rounds and is in no mood to go there ever again.
I dpn't think it would have alienated the community so much as it would have made IBM politically dependent on a single vendor for its own purposes.
Also cutting edge is sometimes bleeding edge, things break, and it's highly desirable to be in a position that avoids any appearance of complicity or duplicity when
An IBM boxed set of Linux would sell very well, but this is exactly the business that Red Hat decided to get out of. (Curses, etc., but I can't really blame 'em). Official Red Hat Professional 6.2 in a nice big box. Later boxes smaller (even with more "stuff") in them. Sure there's Fedora Core, but you can't buy a boxed set.
benefits of a 'fire engine' without a siren, hose or ladder
I'd be more interested in the pump and the tools to connect to an available fire hydrant, without which the stuff that looks like fire engine isn't going to do much good. There's lots of fires where a grown-up version of a toy fire engine is pretty much useless.
If it's efficient and stable I'll definitely be pushing students this way rather than letting them use MySQL (with which I've been massively disappointed
For your purposes, probably better.
A toy is something you can play with. Desirable for students.
Industrial-grade, due to factors such as sheer volume, has non-toy aspects.
A PC lives in a big-computer, small-problem world. You do things on a PC because you want to.
A mainframe lives in a small-computer, big-problem world. You do things on a mainframe because you have to.
At any point in real time, MySQL has exactly ONE system state. This state is advanced by atomic SQL statements. This means that readers and writers DO interfere with each other. This also vastly simplifies the overall system as there is never a system-induced rollback due to two or more concurrent versions of the system depending on incompatible uncommitted updates. The penalty is that you need to know what you are doing.
Where readers do not interfere with writers, there must be concurrently more than one system state to accomodate the forked state of the system. An update within a transaction may conflict with an update in a different transaction. Depending on when cognizance is taken, something that thought it completed successfully will be informed that it did not. Now what? As a general rule, the world of error recovery is an order of magnitude more complicated than normal and will be permitted an order of magnitude less resources with which to accomplish its requirements. SOP with flakey Windows systems is to kill power. Do not "Shut down". Do not "Log off". Coming back up from a power failure has been pretty well tested and debugged. Saving and restoring whatever strange state you got the system in has probably never even been considered for testing, let alone doing anything about it. Whatever brain damage is currently in memory do not give it a chance to make it permanent.
It's nice and easy to set up and a lot of easy stuff can be done without thinking, but MySQL is not a toy. What would be intersting would be to see a comparison of the hardware base from a maxed-out MySQL to a "real" DBMS capable of handling the same load.
Probably better. The MySQL system is consistent with atomic SQL statements
The design of MySQL is (at least was) to have a SQL-looking interface to a system that
You see some things and are blind to some things.
You know how to do some things (in a particular way) and can't see them if they're done in a different way.
You see patterns and react to what you expect to be there.
There just isn't enough time to read everything.
The above "you" is a me too.
This does have relevance for "Intellectual Property" in that:
You can have a bunch of petty fiefdoms each guarding its own petty turf with the net result that stuff has much less tendency to flow from place to place.
Imagine the freeway system where each farmer collects a toll from the traffic that passes through what once were his fields. Imagine Customs and duties paid on all traffic that passes through state and city borders.
Goods from far off become exhorbitantly expensive and people make do with less and much less of what comes from far off and we're all the poorer for it, including the toll collectors.
The state-of-the-art is maybe improving, but it doesn't take a lot of petty hassles and annoyances to make it very unworthwhile to upgrade much of anything.
With Windows, this is a feature.
;-)
With Linux, this is a vulnerability.
Now guess which one gets all the malware.
And counting vulnerabilities gives you the wrong answer
IF you are measuring it. IF you know the lines come from the exact same point, THEN you know that any circle around that point is exactly 360 degrees.
But not if the 2-space is non-Euclidian. Mapmakers have this problem.
Working with computers, you should learn how much the precision affects your calculations. If you can CALCULATE to a higher precision, then do so.
Until you run into rounding problems. There's a reason for COBOL's packed decimal. Things like nnn.nn add straight without coming up with silliness like 123.444444444497. Working with higher precision has the annoying property of ensuring round-off anomalies.
The plural of virus is Microsoft.
Longer than 10 years.
out of sight, out of mind.
Extremely parallel
out of foo, out of bar
me no see-um.
me forget-um.
gone and forgotten.
gone from view, gone from memory.
out of sight -- cannot be seen -- invisible
extrinsic property is translated to intrinsic property
out of mind -- doesn't stand on it's own,
so the meaning of forget is unreachable.
Machines do not cope well with ambiguity, at least not any that I've ever run across. Humans have always had to cope with an ambiguous world. It isn't just a problem of parsing, it a problem of what the elements are that it is parsed into. The meanings of the words are in part determined by the context in which they are used.
This sentence no verb.
It's a victory for Microsoft, because Microsoft isn't having to lower their prices for everyone else.
I wouldn't be too sure about that. Best delay any high-price committments and see what develops. Otherwise you risk buying it a week before it goes on sale.
The whole POINT of GNU is that it's not Unix
Not exactly.
I'd say the point is to be Unix without being called Unix. By being better it cuts the ground out from under the ownership of the name.
Vastly oversimplifying, and a lot of this is by association with the hardware it run on.
Unix 1. AT&T Unix. Very expensive and underpowered hardware by today's standards.
Unix 2. Berkeley Unix. Amazing what you can do with cheap grad student labor.
Unix 3. Linux. Triumph of anarchy. Product of the internet.
The name Unix is applicable to Unix 1 and some variants of Unix 2. GNU utilities make Unix useable. GNU/Linux further undermines the name. Linux on IBM mainframes and supercomputers (and everything else) is a new (GNU if you like puns) generation. Even if it's mostly due to the hardware, you gotta stick a lablel on it.
How do they know Google isn't doing the same, only more subtly?
Google has their standards.
This does not mean that I know what they are.
This does not mean that Google always follows them.
This does not mean that they are always the highest in the industry.
The same will apply to the New York Times (and I'm sure plenty of others).
Reporter fakes stories and the powers-that-be "are not amused".
Both are "main-line" and I see no reason either should feel any compulsion to feature any and all crack-pots that come along. They both have some sense of journalistic integrity and a reputation that they value and will do things to destroy it light. I'm not saying there's anything in common between them except that both seem rather trustworthy and likely to remain so.
If I choose Google, then I halfway expect and am not annoyed by Google giving itself some kind of preference. If I do not choose MSN, but have it thrust upon me, any indication of preference by Microsoft's MSN to other entities tied to Microsoft that put Microsoft's name in my face to further Microsoft's idea of Microsoft's mind-share of Microsoft's captive audience, becomes more than a little annoying and Microsoft becomes a synonym for aggravation. It's not that Google can do no wrong, it's that they'd have to fall so far to match Microsoft that "Google can do no wrong" is an effective abbreviation of the long-winded fully qualified reality.
Microsoft is highly profitable. I'd say that a rather robust indicator they're doing something right.
Same argument applies to con men, to armed robbers, to the mob.
As a result of the interaction, it's Microsoft that winds up with the money.
Some of us English are French (Norman).
Why is Brittany in France?
It's all a pretty mixed brew in any case.
Windows puts power in the hands of management
That has been the perception and that is the point of the Microsoft ads.
It doesn't really, but that's another issue.
Considering the technical knowledge of management in most companies, these are exactly the hands that you do not want to have power.
Errrr, there's something backwards here. The fundamental nature of management is that it is management that has the power. IT is there to serve the priorities of management, not the other way around.
What is happening is that Windows is slowly taking over the joint, and to be perceived to be doing so by PHBs. The PHBs will not like that.
Something I read a long time ago put a value of 85% on the overlap of the skill set for good programmers and good managers. Both have to deal with conflicting priorities and limited resources.
"The bug isn't here, we tested this module thoroughly."
... repeat.
You haven't seen many bugs, have you? Sorry, I'm sure you have, but bugs are extremely adept at hiding in places where you "dont have places".
I've run into too many doubles and even a triple where the interactions were subtle enough that a bug was discernable only in the combination. Fix either (any in the case of the triple) and the problem goes away. Fix both,
I would class as a bug, any behavior which departs from what the specs should be. If the specs are wrong that doesn't make the program right. If it is impossible for the bug to show itself, there is still a bug. I think part of the problem is the implicit assumption that it is even possible, let alone easy, to write bug-free code. With the possible exception of some stuff by Knuth, nobody does.
is an oxymoron.
Difficult if there is no logic and no interactions.
Scripts will be of some help.
Probably best will be long complicated sequences of operations whose net effect must logically be precisely nothing.
If you're lazy like me, integrate first, and every module is responsible for not going beserk in the presence of buggy neighbors. Too much software seems designed to assume that everything else is perfect. The old game of "gossip" shows that even if everything is perfect, your idea of perfect and my idea of perfect may not perfectly coincide.
OTOH, it's a poor measure of useful work
Exactly, assuming you mean worth or value as opposed to effort or cost.
There is also the fact that it takes considerable time skill and effort to make something smaller.
I think we can do this project with $BIGFOO KLOC" with a straight face scares me.
What the program does -- asset.
The lines of code it takes to do it in -- liability.
As a measure of what it would cost to do it, maybe reasonable.
There is a trap if KLOC are considered a usable metric of progress. Following the rule of 90% of anything is garbage, it should be possible to spend 90% of the time on the first 10% that matters and get it right, then spend 10% of the time on the remaining 90% garbage. Any trust in a KLOC metric will do the 90% garbage first, making the "remaining" 10% non-garbage essentially undoable. Odds for which view will be takern?
Sometimes it is, sometimes it's not.
... catch in the assumption that one can/should actually be able to do something about trapped errors. The problem space is about an order of magnitude more complicated and the required tools simply do not exist (probable exception of LISP) to do a fix-up and a retry or ignore with the proper scope. What annoys me is using medium effort to field a small error that becomes then a big error. With PHP or Perl, if you don't want to die, then don't say die.
Yes, but it's always a good idea to be able to tell the difference.
UltraDev at least used to have a server behavior (chunk of code) that would check if the user's login was valid. If invalid, the code would send a redirect and then fall through and proceed merrily to produce the html that the user was supposed to be locked out of.
There's a psychological trap in the ON ERROR or try
That example is a bit more devious than it appears.
The problem is to print stuff from a file.
Perl (PHP would do the same) will print it or die trying.
Java code will print it (or an error message)
and keep on going regardless
Single entry, Single exit
Whether it works or not.
This is progress?