My main point was that it's unfair to pick on PHP because of something which - when done properly - isn't a problem.
I think that's where we differ. Your suggestions about how PHP ought to be written are reasonable, but I actually am picking on PHP for its poor design. When I say "broken" I don't mean a bug as in the implementation deviating from a spec, I mean Broken As Designed.
When PHP was created, a choice had to be made about what == would mean. And that choice was made in such a way that it would invite bugs; it practically guarantees confusion. In no other language does equality fail to be transitive.
The == operator is typically described as:
A == B tests whether A and B are equal.
but in fact what it really does is:
A == B tests whether A and B are equal or if either of A or B is a number then it tests whether they have the same numeric value, where strings containing common formats for integers and floats are converted to the corresponding numeric value, strings not containing recognizable numbers are converted to zero, and undefined values are converted to zero.
That behaviour is unnecessarily complicated. I claim the design choice was poor, and the widespread misunderstanding and misuse of the == operator provides some empirical support for that claim.
The == operator in PHP has nothing to do with set theory. It's called the "equal" operator, so either it should behave in a manner consistent with equality or it should be named and written differently.
You're the one trying to convert "spam" into an integer.
Really. Tell me, where in
$a == $b
did I say "convert to an integer"? No, it was PHP's idea to convert... but only sometimes.
Why PHP should NEVER be taught to beginners.
on
A Decade of PHP
·
· Score: 1
The most fundamental aspects of the language are broken, and will probably never be fixed because they are so entrenched. Here's an example.
Suppose A equals B, and also B equals C. Any reasonable person would expect that A equals C, right?
Oh yeah?
Scanning for viruses is the wrong answer. It is impossible to determine the intent of a program by scanning it.
Downloaded software should not be given the power to mess with your system in the first place. This is a fundamental flaw in the design of Windows. Because it gives every running program the full power of the user account, Windows is B. A. D. (Broken As Designed). Linux and Mac systems have the same flaw.
I grant you that hydrogen-as-energy-carrier could replace fossil-fuel-as-energy-carrier (given significant advances in hydrogen technology). However, i don't think it's fair to describe hydrogen as a "replacement for fossil fuels" without carefully qualifying what that means, for two reasons:
Most people primarily value and think about fossil fuels as an energy source, not a carrier. The Physics Today article promotes exactly this -- it begins by identifying the problem that fossil fuels are a limited energy supply and then immediately presents hydrogen as a replacement. Or look at the conclusion: "The hydrogen economy has enormous societal and technical appeal as a potential solution to the fundamental energy concerns of abundant supply...." I find that highly misleading.
Fossil fuels are both a source and a carrier. Hydrogen is only a carrier. If i sold you just a pair of speakers claiming that they would be a "replacement" for your whole stereo system, wouldn't you feel ripped off?
I just submitted the following letter using Physics Today's form for Letters to the Editor. I urge you to write and submit your own letters if you feel the same way.
Dear Editor,
Hydrogen is an energy carrier, not an energy source.
In Physics Today 57(12), Crabtree, Dresselhaus, and Buchanan write, "Hydrogen, like electricity, is a carrier of energy, and like electricity, it must be produced from a natural resource." The authors point out that "it does not occur in nature as the fuel H2," yet contradict themselves by describing hydrogen as a "promising alternative to fossil fuels".
Until fusion becomes practical, hydrogen is not a naturally occurring energy source. It therefore cannot replace fossil fuels, which are a naturally occurring energy source.
Although hydrogen has promise as a compact energy storage medium, to call hydrogen a replacement for fossil fuels is inaccurate and irresponsible.
Ka-Ping Yee
University of California, Berkeley
Or please tell me what is wrong with my thinking. I just don't understand how three established scientists can publish something containing such blatant contradictions.
Instant runoff voting does not solve this problem. The IRV system is widely misunderstood.
1. IRV only allows you to safely vote for a third party as long as the third party has minimal support. Once the third party begins to gather substantial support, IRV prevents it from winning exactly as the current system does.
2. In many realistic situations, IRV exhibits crazy behaviour in which voting for a candidate can cause him to lose. No other seriously proposed voting system has this problem.
3. IRV is complicated to explain and expensive to implement. The ballots cannot be totalled up; instead, information about every individual ballot must be sent to a central location to determine the winner.
Approval voting has none of these problems. In approval voting, you vote for as many candidates as you want, and the candidate with the most votes wins. It is extremely simple to implement, easy to understand, works with existing ballots, and truly allows you to vote for any party you like because all your choices are independent.
I have a friend who could do some good design work for you. If you like, I can put you in touch with her. Go to my website at zesty.ca and scroll down to see my e-mail address.
I agree with you that capabilities are great, EROS has the right approach, and NGSCB is the wrong approach. Alas, SELinux does not have "capabilities" in the EROS sense.
Unfortunately, the term "capabilities" was misapplied to "POSIX capabilities", which are what SELinux has. These are not capabilities at all in the original sense of the word (the sense they are used in EROS). For a detailed explanation of the differences, please see http://zesty.ca/capmyths/usenix.pdf.
Calm down a minute and look more carefully at what i'm saying. I'm sorry if i wasn't clear enough.
I recognize that there are standard shortcuts for commands common to most applications, such as the ones you mentioned (Save, Print, Close). I agree that this is a great thing.
Here's my point: there should be a convenient and predictable way to get to everything in the menus.
Not everything has a shortcut. And many shortcuts are application-specific; i don't think it's reasonable to expect users to have them all memorized.
Even some standard commands don't have standard shortcuts, like Zoom, for instance. The only obvious way to get to Zoom is to hit Fn-Ctrl-F2, hit the arrow buttons a few times to get to the Window menu, and then hit down twice or hit Z. Presumably this is because the Apple developers decided that they wanted to reserve Command-Z for Undo and didn't think Zoom was important enough to deserve a specialized shortcut key. That's cool; the space of available shortcut keys is limited and the space of human memory is limited, so applications shouldn't be obligated to assign shortcuts to everything. That means you're going to need a reasonably convenient way to deal with the rest of the menu commands.
It would greatly improve keyboard accessibility if there were a standard way to get to all the menu commands in just a couple of keypresses. Windows can do this (Alt, first letter of menu, first letter of command in most cases). That doesn't make Windows better as a whole; it's just one particular thing that Windows does better, and that would make Mac OS X accessibility better as well.
Please read my post more carefully. I'm talking about a universal way to get to all the menu commands when you haven't memorized all the shortcuts.
All right, so "Print" was an inappropriate example because it has a standard shortcut in every application, which is good. But not all menu commands have shortcuts, let alone standard ones, and users can't be expected to memorize them all.
Many applications have menu commands with no shortcuts, like the "Repeat One" command i mentioned in the original post. It shouldn't take 5 to 10 keypresses to get there. As far as i can tell, selecting "Repeat One" requires at least 8 keypresses if you are willing to enter an unpredictable sequence, or 14 keypresses for a predictable sequence. (By "predictable" i mean it doesn't depend on knowing everything else in the menu.) It ought to take just 2 or 3 predictable keypresses.
Strange... i am also using OS X 10.3.3 and TextEdit 1.3 (v202). I don't know what triggers this problem; it appears to be intermittent. But it definitely happens; i just tested it and sure enough there is no blue focus border.
Someone else mentioned that you can hit Command-D to activate "Don't Save", which does work even when there's no blue focus border. Not very consistent though.
I just came across another instance of this problem, and it's worse: if you try to quit TextEdit when you have multiple windows with edited material, you get a pop-up prompt: "You have 2 documents with unsaved changes. Do you want to review these changes before quitting?" In this prompt window, neither Tab nor Command-D works.
I think you missed a couple of things i wrote in the original comment. I said "assume you haven't memorized the shortcuts yet". Not all menu commands have shortcut keys, and you can't expect users to have all the shortcut keys memorized. The issue is how you get around a new application to all the menu commands when you haven't memorized them yet.
Look at the "Repeat One" command in iTunes, for instance. There's no shortcut for that one. In a Windows environment, you could get there by pressing Alt, C, R, R. On a Mac it's a lot harder.
Return is the key you are looking for to activate the glowing button on a sheet.
I know. I said that in the original post. The point i was trying to make is that sometimes the highlight doesn't appear and Tab doesn't select anything.
I think you missed my point. I said "assume you haven't memorized the shortcuts yet".
The nice thing about pull-down menus is that you can explore them to find out what you can do. Of course Print happens to have a standard shortcut across most applications. But menu commands don't always all have shortcut keys, and you can't expect users to memorize all the shortcut keys for every application.
Using single-letter accelerators to open menus and activate pull-down menu items is a nice universal way to get to all menu commands regardless of what shortcut keys the user has memorized. Windows applications let you activate any menu command just with Alt and a few letters (almost always two), and it would be nice if it were that easy on the Mac as well.
I'm telling you, there is a bug. I've already turned on full keyboard access. When you see the prompt sheet, you get a highlight that you can move to different buttons by pressing Tab. I don't.
That's my point: sometimes it's there, sometimes it isn't.
Really, I would love to be proved wrong. I just want a fast way of getting around with the keyboard, and keyboard operations don't behave in ways that are obvious and convenient to me.
Are there better ways to get at the menus, for instance? Is there a way to operate dialog buttons that works consistently in all dialogs? If I'm missing something, I do want to know.
That only works in some dialog boxes. It would be nice if it worked everywhere.
Command+letter can't be the rule for all sheets, since sheets only grab window focus, not application focus. If sheet buttons took over Command+letter combinations, you wouldn't be able to use Command+letter shortcuts to talk to the application. For example, in a browser window, a password prompt might drop down as a sheet, but i wouldn't want a button starting with "W" to prevent me from pressing Command+W to close the window.
Pressing the letter alone, for any dialog boxes that have only buttons, is probably a better solution.
I do love many things about Mac OS X, but it's a terrible shame that its keyboard accessibility is so far behind that of Windows and Linux. I don't really understand how they could have gotten this so wrong.
Complete and convenient keyboard access is essential for vision-impaired users (and a great boon to fully sighted users who just want to get around more quickly). Unfortunately:
1. Full keyboard access isn't "full".
In some cases, even when full keyboard access is turned on, the blue border highlight never appears and pressing the Tab key does nothing. This causes parts of the user interface to be completely keyboard inaccessible. For example, if I start TextEdit, type in something, and press Command-W, a sheet drops down asking if I want to save the file before closing it. There are three buttons and the "Save" button is glowing, but there is no highlight, so it is impossible to select buttons using the keyboard. It is still possible to activate "Cancel" by pressing Escape, but "Don't Save" is completely unreachable.
There are also some controls that Tab never reaches, even if full keyboard access is enabled. For example, pressing Ctrl-F5 in Safari doesn't move the highlight to the toolbar. Pressing Tab never highlights the toolbar buttons, the bookmarks bar, or the tab bar. In the main iTunes window, pressing Tab cycles between the Source pane, the song listing, and the Search field. But when you first start iTunes, no song is selected, so the song listing is never highlighted; there is no way to tell that the song listing has the focus.
Keyboard access should be properly enabled in every window and sheet. Tab should navigate to all controls, and the border highlight should always be visible, even around list boxes.
2. Responding to prompts is tedious.
Prompt boxes usually present two or three buttons to choose from. The only universal way to operate these prompts from the keyboard is to press Tab several times and then press Enter. Not only does this require more keypresses, it also requires the user to watch for feedback because he must look for the highlight in order to predict which button will be activated. The user cannot simply hit a key and know in advance what will happen.
Buttons should be assigned accelerator keys by the operating system so that they can be activated by pressing a single letter (the first letter on the button, if possible). Pressing Command and the first letter of the button text sometimes works, but this seems to be a rare feature of particular prompts. Single-letter access should be enabled everywhere.
3. Access to menu commands is tedious.
Assume for a moment that you aren't yet totally familiar with an application and haven't memorized the Command shortcuts. The only way to access the menus from the keyboard is to press Fn-Ctrl-F2, a fairly arcane key combination, and then repeatedly press the arrow keys to get the desired menu. Then one can press the Up and Down arrows to choose a command. Although commands can be selected from menus by pressing letters, the association between letters and commands is strange and hard to predict. For example, in Safari's File menu, pressing C activates "Close Tab" (why not "Close Window"?), pressing D activates "New Tab", and pressing W activates "Save As...". In the Apple menu, pressing S once activates "Shut Down..." (why not "Software Update..." or "Sleep"?) and pressing S again activates "System Preferences...". This doesn't make any sense.
Windows users can simply press Alt-F-P to print. But Mac users have to press Fn-Ctrl-F2, Right, Right, Down, Down, Down, Down, Down, Down, Down, Down, Down, Enter. Or, if they are clever, they can press Fn-Ctrl-F2, Right, Right, P, R, Enter. This is tedious, but the more severe problem is that the Mac key combination is not fixed. If the menu changes (by inserting, removing, enabling, or disabling items), the number of times to press the arrow keys can change, and the number of letters one has to type to be certain of se
Some nouns can be counted, like "two sticks". Others cannot, like "rice".
"A mail was sent around" is just as grammatically incorrect as "She ate a rice" or "That boy has a courage". The poster should have written "Mail was sent around" or "A message was sent around".
Slashdot Mirror
I think that's where we differ. Your suggestions about how PHP ought to be written are reasonable, but I actually am picking on PHP for its poor design. When I say "broken" I don't mean a bug as in the implementation deviating from a spec, I mean Broken As Designed.
When PHP was created, a choice had to be made about what == would mean. And that choice was made in such a way that it would invite bugs; it practically guarantees confusion. In no other language does equality fail to be transitive.
The == operator is typically described as:
but in fact what it really does is:
That behaviour is unnecessarily complicated. I claim the design choice was poor, and the widespread misunderstanding and misuse of the == operator provides some empirical support for that claim.
If what you're implying is that == shouldn't be used to compare strings, then I agree with you.
Now tell that to all the hordes of PHP programmers out there who do this EVERY DAY.
== isn't broken, it's ambiguous and complex.
:)
Bwahahaha! Thank you, yes, that's the perfect wording. PHP isn't broken; it's merely ambiguous and complex.
Not in set theory.
The == operator in PHP has nothing to do with set theory. It's called the "equal" operator, so either it should behave in a manner consistent with equality or it should be named and written differently.
You're the one trying to convert "spam" into an integer.
Really. Tell me, where in
did I say "convert to an integer"? No, it was PHP's idea to convert... but only sometimes.The most fundamental aspects of the language are broken, and will probably never be fixed because they are so entrenched. Here's an example.
Suppose A equals B, and also B equals C. Any reasonable person would expect that A equals C, right? Oh yeah?
Try explaining that to a first-time programmer.Ten years and the == operator is still completely broken. Any hope of fixing it in the next ten?
Suppose A equals B, and also B equals C. Any reasonable person would expect that A equals C, right? Oh yeah?
Try explaining that to a first-time programmer.Funny that you should mention this. :)
Check out Polaris.
Scanning for viruses is the wrong answer. It is impossible to determine the intent of a program by scanning it.
Downloaded software should not be given the power to mess with your system in the first place. This is a fundamental flaw in the design of Windows. Because it gives every running program the full power of the user account, Windows is B. A. D. (Broken As Designed). Linux and Mac systems have the same flaw.
To truly solve the virus problem, limit the authority of running programs.
I grant you that hydrogen-as-energy-carrier could replace fossil-fuel-as-energy-carrier (given significant advances in hydrogen technology). However, i don't think it's fair to describe hydrogen as a "replacement for fossil fuels" without carefully qualifying what that means, for two reasons:
- Most people primarily value and think about fossil fuels as an energy source, not a carrier. The Physics Today article promotes exactly this -- it begins by identifying the problem that fossil fuels are a limited energy supply and then immediately presents hydrogen as a replacement. Or look at the conclusion: "The hydrogen economy has enormous societal and technical appeal as a potential solution to the fundamental energy concerns of abundant supply...." I find that highly misleading.
- Fossil fuels are both a source and a carrier. Hydrogen is only a carrier. If i sold you just a pair of speakers claiming that they would be a "replacement" for your whole stereo system, wouldn't you feel ripped off?
(I'm a CS grad student at Berkeley.)I just submitted the following letter using Physics Today's form for Letters to the Editor. I urge you to write and submit your own letters if you feel the same way. Or please tell me what is wrong with my thinking. I just don't understand how three established scientists can publish something containing such blatant contradictions.
Instant runoff voting does not solve this problem. The IRV system is widely misunderstood.
1. IRV only allows you to safely vote for a third party as long as the third party has minimal support. Once the third party begins to gather substantial support, IRV prevents it from winning exactly as the current system does.
2. In many realistic situations, IRV exhibits crazy behaviour in which voting for a candidate can cause him to lose. No other seriously proposed voting system has this problem.
3. IRV is complicated to explain and expensive to implement. The ballots cannot be totalled up; instead, information about every individual ballot must be sent to a central location to determine the winner.
Approval voting has none of these problems. In approval voting, you vote for as many candidates as you want, and the candidate with the most votes wins. It is extremely simple to implement, easy to understand, works with existing ballots, and truly allows you to vote for any party you like because all your choices are independent.
See this document for a detailed comparison.
I have a friend who could do some good design work for you. If you like, I can put you in touch with her. Go to my website at zesty.ca and scroll down to see my e-mail address.
I agree with you that capabilities are great, EROS has the right approach, and NGSCB is the wrong approach. Alas, SELinux does not have "capabilities" in the EROS sense.
Unfortunately, the term "capabilities" was misapplied to "POSIX capabilities", which are what SELinux has. These are not capabilities at all in the original sense of the word (the sense they are used in EROS). For a detailed explanation of the differences, please see http://zesty.ca/capmyths/usenix.pdf.
Calm down a minute and look more carefully at what i'm saying. I'm sorry if i wasn't clear enough.
I recognize that there are standard shortcuts for commands common to most applications, such as the ones you mentioned (Save, Print, Close). I agree that this is a great thing.
Here's my point: there should be a convenient and predictable way to get to everything in the menus.
Not everything has a shortcut. And many shortcuts are application-specific; i don't think it's reasonable to expect users to have them all memorized.
Even some standard commands don't have standard shortcuts, like Zoom, for instance. The only obvious way to get to Zoom is to hit Fn-Ctrl-F2, hit the arrow buttons a few times to get to the Window menu, and then hit down twice or hit Z. Presumably this is because the Apple developers decided that they wanted to reserve Command-Z for Undo and didn't think Zoom was important enough to deserve a specialized shortcut key. That's cool; the space of available shortcut keys is limited and the space of human memory is limited, so applications shouldn't be obligated to assign shortcuts to everything. That means you're going to need a reasonably convenient way to deal with the rest of the menu commands.
It would greatly improve keyboard accessibility if there were a standard way to get to all the menu commands in just a couple of keypresses. Windows can do this (Alt, first letter of menu, first letter of command in most cases). That doesn't make Windows better as a whole; it's just one particular thing that Windows does better, and that would make Mac OS X accessibility better as well.
Please read my post more carefully. I'm talking about a universal way to get to all the menu commands when you haven't memorized all the shortcuts.
All right, so "Print" was an inappropriate example because it has a standard shortcut in every application, which is good. But not all menu commands have shortcuts, let alone standard ones, and users can't be expected to memorize them all.
Many applications have menu commands with no shortcuts, like the "Repeat One" command i mentioned in the original post. It shouldn't take 5 to 10 keypresses to get there. As far as i can tell, selecting "Repeat One" requires at least 8 keypresses if you are willing to enter an unpredictable sequence, or 14 keypresses for a predictable sequence. (By "predictable" i mean it doesn't depend on knowing everything else in the menu.) It ought to take just 2 or 3 predictable keypresses.
Strange... i am also using OS X 10.3.3 and TextEdit 1.3 (v202). I don't know what triggers this problem; it appears to be intermittent. But it definitely happens; i just tested it and sure enough there is no blue focus border.
Someone else mentioned that you can hit Command-D to activate "Don't Save", which does work even when there's no blue focus border. Not very consistent though.
I just came across another instance of this problem, and it's worse: if you try to quit TextEdit when you have multiple windows with edited material, you get a pop-up prompt: "You have 2 documents with unsaved changes. Do you want to review these changes before quitting?" In this prompt window, neither Tab nor Command-D works.
Look at the "Repeat One" command in iTunes, for instance. There's no shortcut for that one. In a Windows environment, you could get there by pressing Alt, C, R, R. On a Mac it's a lot harder.
I know. I said that in the original post. The point i was trying to make is that sometimes the highlight doesn't appear and Tab doesn't select anything.
I think you missed my point. I said "assume you haven't memorized the shortcuts yet".
The nice thing about pull-down menus is that you can explore them to find out what you can do. Of course Print happens to have a standard shortcut across most applications. But menu commands don't always all have shortcut keys, and you can't expect users to memorize all the shortcut keys for every application.
Using single-letter accelerators to open menus and activate pull-down menu items is a nice universal way to get to all menu commands regardless of what shortcut keys the user has memorized. Windows applications let you activate any menu command just with Alt and a few letters (almost always two), and it would be nice if it were that easy on the Mac as well.
I said pressing the letter alone was a better solution for any dialog boxes that have only buttons.
I'm telling you, there is a bug. I've already turned on full keyboard access. When you see the prompt sheet, you get a highlight that you can move to different buttons by pressing Tab. I don't.
That's my point: sometimes it's there, sometimes it isn't.
Really, I would love to be proved wrong. I just want a fast way of getting around with the keyboard, and keyboard operations don't behave in ways that are obvious and convenient to me.
Are there better ways to get at the menus, for instance? Is there a way to operate dialog buttons that works consistently in all dialogs? If I'm missing something, I do want to know.
Thanks in advance.
That only works in some dialog boxes. It would be nice if it worked everywhere.
Command+letter can't be the rule for all sheets, since sheets only grab window focus, not application focus. If sheet buttons took over Command+letter combinations, you wouldn't be able to use Command+letter shortcuts to talk to the application. For example, in a browser window, a password prompt might drop down as a sheet, but i wouldn't want a button starting with "W" to prevent me from pressing Command+W to close the window.
Pressing the letter alone, for any dialog boxes that have only buttons, is probably a better solution.
I do love many things about Mac OS X, but it's a terrible shame that its keyboard accessibility is so far behind that of Windows and Linux. I don't really understand how they could have gotten this so wrong.
Complete and convenient keyboard access is essential for vision-impaired users (and a great boon to fully sighted users who just want to get around more quickly). Unfortunately:
1. Full keyboard access isn't "full".
In some cases, even when full keyboard access is turned on, the blue border highlight never appears and pressing the Tab key does nothing. This causes parts of the user interface to be completely keyboard inaccessible. For example, if I start TextEdit, type in something, and press Command-W, a sheet drops down asking if I want to save the file before closing it. There are three buttons and the "Save" button is glowing, but there is no highlight, so it is impossible to select buttons using the keyboard. It is still possible to activate "Cancel" by pressing Escape, but "Don't Save" is completely unreachable.
There are also some controls that Tab never reaches, even if full keyboard access is enabled. For example, pressing Ctrl-F5 in Safari doesn't move the highlight to the toolbar. Pressing Tab never highlights the toolbar buttons, the bookmarks bar, or the tab bar. In the main iTunes window, pressing Tab cycles between the Source pane, the song listing, and the Search field. But when you first start iTunes, no song is selected, so the song listing is never highlighted; there is no way to tell that the song listing has the focus.
Keyboard access should be properly enabled in every window and sheet. Tab should navigate to all controls, and the border highlight should always be visible, even around list boxes.
2. Responding to prompts is tedious.
Prompt boxes usually present two or three buttons to choose from. The only universal way to operate these prompts from the keyboard is to press Tab several times and then press Enter. Not only does this require more keypresses, it also requires the user to watch for feedback because he must look for the highlight in order to predict which button will be activated. The user cannot simply hit a key and know in advance what will happen.
Buttons should be assigned accelerator keys by the operating system so that they can be activated by pressing a single letter (the first letter on the button, if possible). Pressing Command and the first letter of the button text sometimes works, but this seems to be a rare feature of particular prompts. Single-letter access should be enabled everywhere.
3. Access to menu commands is tedious.
Assume for a moment that you aren't yet totally familiar with an application and haven't memorized the Command shortcuts. The only way to access the menus from the keyboard is to press Fn-Ctrl-F2, a fairly arcane key combination, and then repeatedly press the arrow keys to get the desired menu. Then one can press the Up and Down arrows to choose a command. Although commands can be selected from menus by pressing letters, the association between letters and commands is strange and hard to predict. For example, in Safari's File menu, pressing C activates "Close Tab" (why not "Close Window"?), pressing D activates "New Tab", and pressing W activates "Save As...". In the Apple menu, pressing S once activates "Shut Down..." (why not "Software Update..." or "Sleep"?) and pressing S again activates "System Preferences...". This doesn't make any sense.
Windows users can simply press Alt-F-P to print. But Mac users have to press Fn-Ctrl-F2, Right, Right, Down, Down, Down, Down, Down, Down, Down, Down, Down, Enter. Or, if they are clever, they can press Fn-Ctrl-F2, Right, Right, P, R, Enter. This is tedious, but the more severe problem is that the Mac key combination is not fixed. If the menu changes (by inserting, removing, enabling, or disabling items), the number of times to press the arrow keys can change, and the number of letters one has to type to be certain of se
Some nouns can be counted, like "two sticks". Others cannot, like "rice".
"A mail was sent around" is just as grammatically incorrect as "She ate a rice" or "That boy has a courage". The poster should have written "Mail was sent around" or "A message was sent around".
The CTO is named Randal Null? "Mr. Null, i presume." Naturally this man must name his son Devon...