the indexes' entry for "Recursive Procedure" includes the page number of the entry itself
That index entry looks more like an example of a loop than recursion. Recursive functions should have an end-condition. The entry compounds the confusion between loops and recursion unless it is trying to make the point that any recursive function can also be implemeted as a loop.
Other people have replied attributing it to Ben Franklin, but this being the older quote is the more original.
The quote from Poor Richard's is: "Three may keep a Secret, if two of them are dead."
This quote goes back to Chaucer: "For iii may keep a counsel if twain be away."
A contemporary of Shakespeare, John Heywood also used a version of the Chaucer quote ("Three may keepe counsayle, if two be away") in his collection of proverbs (1562). The nurse in Romeo and Juliet presumably misquotes a proverb that would probably be familiar to the audience.
Shakespeare also wrote something similar in Titus Andronicus, act iv. sc. 2.:
The empress, the midwife, and yourself:
Two may keep counsel when the third's away:
Chaucer and Heywood could have been quoting a common saying so it's hard to know where Shakespeare may have heard it.
Third, there are scalability problems with LSI. The author of the Perl article writes:
For all its advantages, LSI also presents some drawbacks. The poor scalability of the singular value decomposition (SVD) algorithm remains an obstacle to indexing very large collections. While techniques have been developed for making incremental updates to a scaled collection, these changes typically cannot exceed a certain threshold without triggering a rebuild [7,8]. These constraints make LSI ill suited to the kinds of large, rapidly changing document collections typically found on the Web.
A further disadvantage to LSI is the difficulty in interpreting the underlying reduced term space [4]. This makes it difficult to select an optimum number of singular values to retain in the SVD for a given collection, or allow domain exert adjustment of relevance values in the reduced space once the SVD has been calculated.
As a result, the author is now pursuing something called Contextual
Network Graphs and has written a Perl module that was updated as recently as last August.
The e-mail and archiving system in Moodle is one of its greatest features. Students post their messages on the Moodle web page, but the messages are sent out to all subscribers as regular e-mail after a teacher-determined delay, of say, 15 or 30 minutes. This gives the writer a chance to review the message and revise it if necessary
All messages appear with a tiny mugshot of the sender, with a smiley face for those who haven't uploaded a digital version of themselves yet. This small feature goes a long way towards building 'community' since it allows students to place a face with a name.
The fact that Moodle has given some thought to email as an education tool is probably an indicator of the thought that has gone into other components.
Did yo know that the chinese symbol for boat means 8 persons. Is this a coincedence with the number of people on the biblical ark?
It's a stretch. The Chinese symbol for boat is said to combine three other symbols: vessel, the number eight, and the symbol for mouth. The symbol for mouth has to be taken as meaning people, which it does in some symbols but it can also mean a port or the mouth of a river. The symbol taken to mean eight resembles the chinese symbol for eight but it is not identical. It also resembles the symbol for table.
Even one Web site that argues that many Chinese symbols correspond with stories in Genesis shows the symbol for vessel as meaning "small boat" despite the fact that Noah's ark was a large boat.
The whole idea that a Chinese symbol retells a story is a dubious proposition. Like any story, they can be twisted to mean anything you want.
A variation on this yarn is a question on an exam for admission to officer's candidate school in the U.S. Army: Given a barometer, a length of rope and a stopwatch, how would you measure the height of a building?
Supposedly an acceptable answer is: I would give the three items to an enlisted man and say, "Soldier, take these things and find out the height of that building."
Enrico Fermi supposedly failed every single person who ever took his Quantum Mechanics course at the University of Chicago.
This story is not likely.
Fermi only gave the quantium mechanics course once in 1954 in the last year of his life. He was known as an outstanding teacher, always willing to help students. His notes for the course were published in a book titled Notes on Quantum Mechanics with additional material supplied by one of the students. None of the reviews I've found mention the story about all the students failing.
Fermi's legendary classroom teaching was the fruit of careful preparation. He seemed to derive pleasure from the act of teaching, without regard for the result. He never showed annoyance at a student's failure to grasp on the first try (or even the second) what he was trying to explain. On the contrary, if Fermi had to repeat an explanation, his pleasure appeared to be doubled.
Good quality search engines have lots of qualities that Google lacks.
One solution is to use google to locate a superset of the target articles and then use a more powerful search engine to winnow the google result set. For an individual, this approach would mean maintaining a personal index of the articles but that is a problem of storage space and bandwidth which is relatively cheap.
The two main problems that google solves is
having access to the articles in the first place
reducing the number of possible articles to a managable level
One could imagine a plugin for browsers that would add the additional search facilities to a google search. Until then, Google Hacks will get you started.
TCO is used for calculating RoI and the smaller it is for equivalent structures, the highter is RoI (is everything else is equal).
True but TCO for IT usually deals with the issue of "everything else being equal" strictly within the IT department. In the operating divisions, no two systems are the same. When looking at a system you have to do a cost-benefit analysis which would show, for instance, that a system that is more expensive to support might have compensating benefits in increased revenue or lower staff costs. The support costs would go to the IT department while the benefit would go to the operating division.
You are right that at some point TCO has to enter into the equation. My point was that that TCO is often used in isolation to justify choosing one system over another. ROI necessarily takes into account more than cost and thus is a better indicator of what a system is worth than TCO.
If one solution gets you a productivity hit, that becomes part of its TCO...
The article doesn't mentioning calculating TCO to include the effects on the organization as a whole. It says:
"The costing models include expenses such as workstations, servers, networking, IT staff, consultancy fees, internet service charges, file, mail and print servers, e-commerce servers, SQL and network infrastructure servers, internet and intranet servers, line-of-business software, desktop productivity applications, external training, printers as well as miscellaneous systems costs," Zymaris said.
Typically, TCO tries to look at costs of running a system over time rather than just at the aquisition. There should be something called Total Benefit of Ownership. You could then calculate TBO/TCO and see whether lowering the TCO makes a bigger difference in the equation than increasing the TBO.
TCO is a PHB metric. Managers who don't understand the role of technology in their organization view technology as a necessary evil and want to keep the cost as low as possible.
Before looking at TCO, managers should looks at:
how much IT increases productivity
how much IT cuts costs in other parts of the company
These metrics are notoriously hard to measure while TCO is mostly contained within the IT budget and so is easier to calculate. An astute office politician can claim some benefits just by reducing his IT costs while ignoring the effects on the rest of the organization.
However, the big gains are outside IT. If IT offers a mere 1% increase in productivity in the organization as a whole it would dwarf any savings in IT costs. If IT isn't providing those types of benefits annually, it is doing something very wrong.
Return on investment, not TCO, is a better measurement of value. Businesses that think they can cost-cut their way to success are generally doomed anyway.
And a 1,000 megawatt plant uses 4 million tons of coal a year, resulting in the release of 5.2 tons of Uranium and 12.8 tones of thorium.
If the proponents of nuclear power were genuinely concerned with the release of radioactivity in the environment, they would be much more concerned with by-products of mining uranium than that of burning coal.
As this report points out, the leftovers from uranium mining dwarf radioactive coal residue:
Uranium mill tailings are normally dumped as a sludge in special ponds or piles, where they are abandoned. The largest such piles in the US and Canada contain up to 30 million tonnes of solid material. In Saxony, Germany the Helmsdorf pile near Zwickau contains 50 million tonnes, and in Thuringia the Culmitzsch pile near Seelingstädt 86 million tonnes of solids.
These tailings are nearly as radioactive as the original ore and pose both an immediate and long-term threat to the environment. Even the Alex Gabbard article cited says the danger from radioactivity from burning coal is well in the future and can be reduced by new technology.
The dangers of radioactivity in other parts of the nuclear energy production cycle, including mining uranium, disposal of nuclear waste, and nuclear accidents, is much greater than from burning coal.
When the proponents of nuclear energy resort to such a blatantly selective use of evidence to bolster their case, it makes one wonder how strong their case really is.
Take a look at some of the research and data on how much naturally radioactive particles are released into the atmosphere through burning of fossil fuels...
The report says (page 44) that because the radioactive elements are not burned, they concentrate in the ash instead of spreading in atmosphere.
As for the danger of the ash, the report says:
EPA has reviewed radionuclide concentrations in coal and ash in connection with other regulatory programs (EPA 1989a, 1989b, 1995c). One of these studies examined potential exposures of worker and nearby resident to radioactivity from ash released from coal pile through wind and runoff erosion. Exposure from direct contact, inhalation, and ingestion were estimated to fall below natural background radiation exposure levels even for a worker standing on the ash pile.
The report concludes that the risks from non-radioactive elements in coal (selenium, arsenic, aluminum, and boron) are of much more concern.
Autonomic computing: a systemic view of computing modeled after a self-regulating biological system.
In conventional system design, the Rs of reliable systems are: (1) Robust, (2) Repair, and (3) Redundant.
Robust means the system is less likely to fail.
Repair means a secondary system looks for signs of failure in the primary system and repairs the problem.
Redundant means a secondary system takes over when the primary system fails.
Biological systems use all three methods to varying degrees but the problem is that biological systems do not survive as individuals, they survive as a species by tolerating a high degree of failure and using a fourth R: Replication.
For computer systems, this biological systems approach would mean replacing every component of the system on a regular basis the way all the cells in the human body are completely replaced every seven years. Periodically, you would throw out the entire system and replace it with two or three new ones that have undergone a period of testing and development.
The replication approach, which is key to the survival of biological systems, runs counter to most business thinking, which is to replace multiple systems with fewer, more powerful systems. This limits reliability to the first three Rs.
There is much that can be done to increase reliability with these 3 Rs but if biological systems are any indication (as well as some theoretical limits), they are inadequate.
The problem of reliability could ultimately be a flaw in the way business works rather than a technical problem.
Suboptimal design like this is actually the strongest evidence for evolution.
It's a minor point but there is stronger evidence for evolution than suboptimal design.
I've often thought that the proponents of Intelligent Design would have a better case if they argued that suboptimal design was evidence of a conscious intelligence. If one looks at other products of engineering like cars designed without seatbuilts, padded dashboards or protected gas tanks, one could plausibly argue that organisms were designed with the same carelessness. Surely, organisms that combined breathing and eating in the same orifice would have died out by the forces of natural selection.
It is interesting to note that organic systems have solved the problem of complexity by tolerating a high failure rate. It's evidence that if intelligent design is at work, the intelligent designer is not a lawyer.
The suggestions are stupid because they aren't relevant to designing a good GUI.
And yet earlier jeif1k said:
Yes, and if you established that that "if" is actually satisfied for an application of Fitt's law, removing all other confounding factors, you would have made a significant contribution to usability research. So far, however, that is just conjecture.
The clear implication here is that "an application of Fitt's law" is relevant to designing a good GUI. Indeed, it would be a "substantial contribution to usability research", not stupid.
He just says that doing usability testing is generally a good idea...
Actually, his main point was the usability testing isn't always possible but you still can make reasonable judgments about UI design without it. He said, "My point was that we shouldn't give up on usability because of this." This point deals with your objection that his conclusions haven't been tested.
So far, however, that is just conjecture.
It's conjecture but it's a reasonable and plausible extension of his application of Fitt's law, which itself has been rigourously tested. Within the limits he sets for Fitt's law, he concludes:
1. Make commonly used controls larger and distinctive
2. Use the edges and corners of the screen to make your controls virtually infinite
3. Never, ever put controls 1 pixel away from a screen edge or corner
Whatever their limitations, these suggestions are far from stupid. One would reasonably expect that they would speed up the apparent if not the real speed of the interface.
Which is just another example of Fitt's law stupidity: you shouldn't ask the user to confirm the delete at all...
The confirmation dialogue has nothing to do with Fitt's law, which he says states "that the larger and nearer to the mouse pointer an on-screen object is, the easier it is to click on."
If you want to claim that Fitt's law has something to do with usability, the burden of proof is on you to demonstrate that.
He addresses this objection in the FAQs as well:
While there actually is evidence backing up most of my claims in the article, most FOSS projects don't have the time, money or people to do detailed usability testing. I can't sit fifty users down and video them using SiEd. My point was that we shouldn't give up on usability because of this.
you have to demonstrate that designing a UI so that the user can hit a particular button a little faster actually increases overall speed and does not decrease any of the other aspects of usability.
The actual speed and the apparent speed are two different things. If Fitt's law increases the apparent speed of the UI then it contributes to the user's comfort even if the actual speed increase is negligible.
For example, parts of UIs are designed to slow down the user to prevent mistakes. The confirm-on-delete dialogue is an example. Fitt's law will not speed up deleting a file significantly but it can contribute to the user feeling he is clearing the dialogue box expeditiously.
Many people took my Fitt's law comments to mean that all controls should be put against the edge of the screen. This wasn't what I said or meant. I merely pointed out that larger controls are easier to click on, and that controls against the edge of the screen are effectively much larger. Controls which belong near the edge of the screen (window decorations, scrollbars and menus) are therefore much better put at the edge of the screen.
What you should focus on is making your UIs intuitive, unobtrusive, internally consistent, unsurprising, and pleasant to look at.
These are good things but his article was aimed at something more fundamental: usability. He writes, "These five points represent a small but important part of UI design. They are not in any way commandments or miracle cures for UI problems. Following their principles in designing an interface should, in my opinion, greatly improve the usability of an application."
In fact, a UI can be unobtrusive, internally consistent, unsurprising and pleasant to look at but still not be especially usable. To some extent, his article was written to deal with that problem.
The most basic point in all computer UI design is that the user does not want to use your application. They want to get their work done as quickly and easily as possible, and the application is simply a tool aiding that.
There is also a class of user, more common that one might expect, that does not want to get his work done quickly, although he may say he does. UIs designed for the lowest common denominator are often dedicated to trying to get this user to do something he's not inclined ever to do. As a result they fail to satisfy this user as well as the other type who really does wants to get his job done quickly and easily.
Among the quickly-and-easily crowd, there are two types of the users: those who use the product a little and those who use it a lot. You can argue about what is most intuitive for the use-it-a-little segment, but keyboard shortcuts are usually what experienced users prefer. If you really want to get your work done quickly and easily, keyboard shortcuts are what you want.
As a result, for people who use the product the most, an intuitive interface may not be all that important except as a learning tool.
A succinct case for Perl as a first language is made by Simon Cozens, one of the co-authors of the book:
It's ideal because it's a real-world language, unlike one designed specifically for teaching, such as BASIC (Visual or otherwise). It's a high-level language that deals naturally with natural concepts like strings and lines of text, unlike something like C; and it allows easy data and text manipulation without a tortuous syntax, unlike something like Python or Tcl.
A more interesting question is what is the best second language. Now that programming has your attention, should you move to something that teaches the fundamentals like Assembler or C or do you move to something with a broader scope like C++ and Java? Or do you choose something mind-expanding like Lisp or Smalltalk?
It assumes no prior knowledge of Perl or of programming in general.
Books that assume no prior knowledge of programming should also give the student an idea of what else they need to know beside programming before they can do any real work.
A partial list would be:
Database design
A database application and SQL
An operating system
A web server
cgi
html
version control
documentation
I also recommend:
Debugging Perl: Troubleshooting for Programmers by Martin Brown
Perl Medic: Transforming Legacy Code by Peter J. Scott
Head First Design Patterns by Elisabeth Freeman, Bert Bates, Kathy Sierra, Eric Freeman
Also, alert the student that it takes 5 years to become proficient and every 5 years half of what he knows is obsolete.
Slashdot Mirror
the indexes' entry for "Recursive Procedure" includes the page number of the entry itself
That index entry looks more like an example of a loop than recursion. Recursive functions should have an end-condition. The entry compounds the confusion between loops and recursion unless it is trying to make the point that any recursive function can also be implemeted as a loop.
Here is the same joke using self-recursion.
Other people have replied attributing it to Ben Franklin, but this being the older quote is the more original.
The quote from Poor Richard's is: "Three may keep a Secret, if two of them are dead."
This quote goes back to Chaucer: "For iii may keep a counsel if twain be away."
A contemporary of Shakespeare, John Heywood also used a version of the Chaucer quote ("Three may keepe counsayle, if two be away") in his collection of proverbs (1562). The nurse in Romeo and Juliet presumably misquotes a proverb that would probably be familiar to the audience.
Shakespeare also wrote something similar in Titus Andronicus, act iv. sc. 2.:
Chaucer and Heywood could have been quoting a common saying so it's hard to know where Shakespeare may have heard it.
it sounds like it's just a big ol' LSI System
A Perl implimentation of LSI can be found at Building a Vector Space Search Engine in Perl
However, there are at least three problems. First, it doesn't look LSI can answer questions like "Who is the Prime Minister of Canada?"
Second, the approach is patented by Telcordia Technologies.
Third, there are scalability problems with LSI. The author of the Perl article writes:
As a result, the author is now pursuing something called Contextual Network Graphs and has written a Perl module that was updated as recently as last August.
Or, as Samuel Johnston put it:
Has anyone used Moogle?
That would be Moodle. The section on Moodle for Language Teaching has some interesting ideas and shows it is widely used for this purpose.
An essay on using Moodle has this comment:
The fact that Moodle has given some thought to email as an education tool is probably an indicator of the thought that has gone into other components.
Did yo know that the chinese symbol for boat means 8 persons. Is this a coincedence with the number of people on the biblical ark?
It's a stretch. The Chinese symbol for boat is said to combine three other symbols: vessel, the number eight, and the symbol for mouth. The symbol for mouth has to be taken as meaning people, which it does in some symbols but it can also mean a port or the mouth of a river. The symbol taken to mean eight resembles the chinese symbol for eight but it is not identical. It also resembles the symbol for table.
Even one Web site that argues that many Chinese symbols correspond with stories in Genesis shows the symbol for vessel as meaning "small boat" despite the fact that Noah's ark was a large boat.
The whole idea that a Chinese symbol retells a story is a dubious proposition. Like any story, they can be twisted to mean anything you want.
A variation on this yarn is a question on an exam for admission to officer's candidate school in the U.S. Army: Given a barometer, a length of rope and a stopwatch, how would you measure the height of a building?
Supposedly an acceptable answer is: I would give the three items to an enlisted man and say, "Soldier, take these things and find out the height of that building."
Enrico Fermi supposedly failed every single person who ever took his Quantum Mechanics course at the University of Chicago.
This story is not likely.
Fermi only gave the quantium mechanics course once in 1954 in the last year of his life. He was known as an outstanding teacher, always willing to help students. His notes for the course were published in a book titled Notes on Quantum Mechanics with additional material supplied by one of the students. None of the reviews I've found mention the story about all the students failing.
One of his colleagues writes:
Good quality search engines have lots of qualities that Google lacks.
One solution is to use google to locate a superset of the target articles and then use a more powerful search engine to winnow the google result set. For an individual, this approach would mean maintaining a personal index of the articles but that is a problem of storage space and bandwidth which is relatively cheap.
The two main problems that google solves is
One could imagine a plugin for browsers that would add the additional search facilities to a google search. Until then, Google Hacks will get you started.
TCO is used for calculating RoI and the smaller it is for equivalent structures, the highter is RoI (is everything else is equal).
True but TCO for IT usually deals with the issue of "everything else being equal" strictly within the IT department. In the operating divisions, no two systems are the same. When looking at a system you have to do a cost-benefit analysis which would show, for instance, that a system that is more expensive to support might have compensating benefits in increased revenue or lower staff costs. The support costs would go to the IT department while the benefit would go to the operating division.
You are right that at some point TCO has to enter into the equation. My point was that that TCO is often used in isolation to justify choosing one system over another. ROI necessarily takes into account more than cost and thus is a better indicator of what a system is worth than TCO.
If one solution gets you a productivity hit, that becomes part of its TCO...
The article doesn't mentioning calculating TCO to include the effects on the organization as a whole. It says:
Typically, TCO tries to look at costs of running a system over time rather than just at the aquisition. There should be something called Total Benefit of Ownership. You could then calculate TBO/TCO and see whether lowering the TCO makes a bigger difference in the equation than increasing the TBO.
TCO is a PHB metric. Managers who don't understand the role of technology in their organization view technology as a necessary evil and want to keep the cost as low as possible.
Before looking at TCO, managers should looks at:
- how much IT increases productivity
- how much IT cuts costs in other parts of the company
These metrics are notoriously hard to measure while TCO is mostly contained within the IT budget and so is easier to calculate. An astute office politician can claim some benefits just by reducing his IT costs while ignoring the effects on the rest of the organization.However, the big gains are outside IT. If IT offers a mere 1% increase in productivity in the organization as a whole it would dwarf any savings in IT costs. If IT isn't providing those types of benefits annually, it is doing something very wrong.
Return on investment, not TCO, is a better measurement of value. Businesses that think they can cost-cut their way to success are generally doomed anyway.
And a 1,000 megawatt plant uses 4 million tons of coal a year, resulting in the release of 5.2 tons of Uranium and 12.8 tones of thorium.
If the proponents of nuclear power were genuinely concerned with the release of radioactivity in the environment, they would be much more concerned with by-products of mining uranium than that of burning coal.
As this report points out, the leftovers from uranium mining dwarf radioactive coal residue:
These tailings are nearly as radioactive as the original ore and pose both an immediate and long-term threat to the environment. Even the Alex Gabbard article cited says the danger from radioactivity from burning coal is well in the future and can be reduced by new technology.
The dangers of radioactivity in other parts of the nuclear energy production cycle, including mining uranium, disposal of nuclear waste, and nuclear accidents, is much greater than from burning coal.
When the proponents of nuclear energy resort to such a blatantly selective use of evidence to bolster their case, it makes one wonder how strong their case really is.
Take a look at some of the research and data on how much naturally radioactive particles are released into the atmosphere through burning of fossil fuels...
According to this Report to Congress on Wastes from the Combustion of Fossil Fuels, radioactivty in fossil fuels is not a problem.
The report says (page 44) that because the radioactive elements are not burned, they concentrate in the ash instead of spreading in atmosphere.
As for the danger of the ash, the report says:
The report concludes that the risks from non-radioactive elements in coal (selenium, arsenic, aluminum, and boron) are of much more concern.
I thought that there *was* honor among thieves...
The correct phrase is "There is honor even among thieves", apparently first recorded in 1630. Also, "Thieves are never rogues among themselves."
There's an authoritative discussion here. (The ODEP mentioned is the Oxford Dictionary of English Proverbs).
Thereby reducing the average IQ of cats, while greatly increasing that of MBAs.
The poster is alluding to a quote by Mark Twain:
More Twain quotes on cats here.
The IBM links says, under "The Solution":
In conventional system design, the Rs of reliable systems are: (1) Robust, (2) Repair, and (3) Redundant.
Biological systems use all three methods to varying degrees but the problem is that biological systems do not survive as individuals, they survive as a species by tolerating a high degree of failure and using a fourth R: Replication.
For computer systems, this biological systems approach would mean replacing every component of the system on a regular basis the way all the cells in the human body are completely replaced every seven years. Periodically, you would throw out the entire system and replace it with two or three new ones that have undergone a period of testing and development.
The replication approach, which is key to the survival of biological systems, runs counter to most business thinking, which is to replace multiple systems with fewer, more powerful systems. This limits reliability to the first three Rs.
There is much that can be done to increase reliability with these 3 Rs but if biological systems are any indication (as well as some theoretical limits), they are inadequate.
The problem of reliability could ultimately be a flaw in the way business works rather than a technical problem.
Suboptimal design like this is actually the strongest evidence for evolution.
It's a minor point but there is stronger evidence for evolution than suboptimal design.
I've often thought that the proponents of Intelligent Design would have a better case if they argued that suboptimal design was evidence of a conscious intelligence. If one looks at other products of engineering like cars designed without seatbuilts, padded dashboards or protected gas tanks, one could plausibly argue that organisms were designed with the same carelessness. Surely, organisms that combined breathing and eating in the same orifice would have died out by the forces of natural selection.
It is interesting to note that organic systems have solved the problem of complexity by tolerating a high failure rate. It's evidence that if intelligent design is at work, the intelligent designer is not a lawyer.
The suggestions are stupid because they aren't relevant to designing a good GUI.
And yet earlier jeif1k said:
The clear implication here is that "an application of Fitt's law" is relevant to designing a good GUI. Indeed, it would be a "substantial contribution to usability research", not stupid.
He just says that doing usability testing is generally a good idea...
Actually, his main point was the usability testing isn't always possible but you still can make reasonable judgments about UI design without it. He said, "My point was that we shouldn't give up on usability because of this." This point deals with your objection that his conclusions haven't been tested.
So far, however, that is just conjecture.
It's conjecture but it's a reasonable and plausible extension of his application of Fitt's law, which itself has been rigourously tested. Within the limits he sets for Fitt's law, he concludes:
Whatever their limitations, these suggestions are far from stupid. One would reasonably expect that they would speed up the apparent if not the real speed of the interface.
Which is just another example of Fitt's law stupidity: you shouldn't ask the user to confirm the delete at all...
The confirmation dialogue has nothing to do with Fitt's law, which he says states "that the larger and nearer to the mouse pointer an on-screen object is, the easier it is to click on."
If you want to claim that Fitt's law has something to do with usability, the burden of proof is on you to demonstrate that.
He addresses this objection in the FAQs as well:
you have to demonstrate that designing a UI so that the user can hit a particular button a little faster actually increases overall speed and does not decrease any of the other aspects of usability.
The actual speed and the apparent speed are two different things. If Fitt's law increases the apparent speed of the UI then it contributes to the user's comfort even if the actual speed increase is negligible.
For example, parts of UIs are designed to slow down the user to prevent mistakes. The confirm-on-delete dialogue is an example. Fitt's law will not speed up deleting a file significantly but it can contribute to the user feeling he is clearing the dialogue box expeditiously.
Erase Fitt's law from your mind. To the degree that it matters, it will be obvious to you anyway. And in subtle cases, it's a treacherous guide.
He deals with this objection in the FAQs:
What you should focus on is making your UIs intuitive, unobtrusive, internally consistent, unsurprising, and pleasant to look at.
These are good things but his article was aimed at something more fundamental: usability. He writes, "These five points represent a small but important part of UI design. They are not in any way commandments or miracle cures for UI problems. Following their principles in designing an interface should, in my opinion, greatly improve the usability of an application."
In fact, a UI can be unobtrusive, internally consistent, unsurprising and pleasant to look at but still not be especially usable. To some extent, his article was written to deal with that problem.
The most basic point in all computer UI design is that the user does not want to use your application. They want to get their work done as quickly and easily as possible, and the application is simply a tool aiding that.
There is also a class of user, more common that one might expect, that does not want to get his work done quickly, although he may say he does. UIs designed for the lowest common denominator are often dedicated to trying to get this user to do something he's not inclined ever to do. As a result they fail to satisfy this user as well as the other type who really does wants to get his job done quickly and easily.
Among the quickly-and-easily crowd, there are two types of the users: those who use the product a little and those who use it a lot. You can argue about what is most intuitive for the use-it-a-little segment, but keyboard shortcuts are usually what experienced users prefer. If you really want to get your work done quickly and easily, keyboard shortcuts are what you want.
As a result, for people who use the product the most, an intuitive interface may not be all that important except as a learning tool.
It allows programming to be FUN.
A succinct case for Perl as a first language is made by Simon Cozens, one of the co-authors of the book:
There's an informed discussion of the question at PerlMonks.
A more interesting question is what is the best second language. Now that programming has your attention, should you move to something that teaches the fundamentals like Assembler or C or do you move to something with a broader scope like C++ and Java? Or do you choose something mind-expanding like Lisp or Smalltalk?
It assumes no prior knowledge of Perl or of programming in general.
Books that assume no prior knowledge of programming should also give the student an idea of what else they need to know beside programming before they can do any real work.
A partial list would be:
I also recommend:
Also, alert the student that it takes 5 years to become proficient and every 5 years half of what he knows is obsolete.