There's been a lot of discussion about the local entertainment district's problems with people committing liquor-related offences, such as fighting or urinating in public. The common line that people are taking is that there need to be harsher fines, and ones which aren't so easy to evade.
Apparently, the fines are only $58, which many feel makes them little more than a slap on the wrist, especially considering that they appear to be easily evaded.
I have a suggestion for a more direct solution. Everyone is required to produce government issued photo-ID to enter clubs, bars, etc., or purchase alcohol. Currently, all this does is provide proof of age. I say we step it up a notch.
Much like some driving fines come with a suspended license, I think we should make alcohol purchase a privilege, not a right. It would be simple to implement. Simple install card readers at the clubs/bars. You have to swipe your license to get in. The card reader would go out and check your age, and whether you had any restrictions.
Next, make the liquor related offenses come with alcohol restrictions. If someone fights in public and receives a ticket, they get barred, for two months, from entering clubs or bars, and from purchasing alcohol at licensed restaurants or BC liquor stores. Now, maybe that ban should only extend over the affected area, but it could be extended to include other liquor related offences, such as drunk driving. Imagine that if someone were convicted of drunk driving, not only would they lose their license, they would also lose the ability to purchase their own alcohol in this province for, say, two years after they're out of jail! That consequences of a penalty like that might be enough to coerce people into slightly better behaviour.
The infrastructure is not unlike the one in place already to ensure that you don't get conflicting prescriptions from two different doctors. And the consequence scheme is not unlike the suspended license. The big difference is that liquor consumption appears to be considered a right.
Thursday, August 2, 2007
Wednesday, August 1, 2007
You should all buy macintosh computers.
Now, for those who know me, this will sound like heresy. I personally don't like macs. The reason for this is simple: I don't have any variety. For hardware, I don't have the massive selection of the PC industry. For software, I don't have--scratch that, all the software I want to use is GPL'd and most of it is available for mac.
Now, if you're a gamer, it's a bit of a harder sell. But still, the more of an installed mac base there is, the more game developers will be willing to think of the mac user. So it's a chicken/egg problem. And by buying a mac, you help to produce more chickens.
It used to be that I wasn't a fan of macs in large part because of the OS. I found it too limiting for what I could do. Now that OSX is built on a BSD kernel, and there's a significant amount of *nix functionality exposed, that argument no longer stands.
Do I want to use a mac? Not particularly. I don't feel that you get a lot of value for the money. But I'm a techie. I can deal with weird things in windows or strange configuration problems in Linux. Most people would rather not have to deal with either of these.
On top of that, Windows is left inherently insecure. Most people use an administrator account by default because other accounts are too restrictive. On other platforms, that idea is ludicrous. You simply use super-user privileges when necessary and otherwise, you're a standard user. This is, in part, why Windows is so vulnerable to virii.
So why am I suggesting Macs if I don't want one myself? Well, it's simple. First, I think most people--excluding gamers, due to lack of games--would actually enjoy their use more than a standard PC. Second, it might just save you from the horror that is Windows Vista. Third, it will force software companies to start looking beyond the windows market.
The jump from supporting a single OS platform to supporting two platforms is huge unless the software has been written to be portable from the start. The jump from two platforms to three is minimal. Added to this is the benefit that Mac OSX is not only POSIX compliant, but a lot of the kernel, and API is pretty similar to Linux.
The end result is that the more software there is written for Macs, the more software will be available for Linux. Which is what I'll be running.
Now, if you're a gamer, it's a bit of a harder sell. But still, the more of an installed mac base there is, the more game developers will be willing to think of the mac user. So it's a chicken/egg problem. And by buying a mac, you help to produce more chickens.
It used to be that I wasn't a fan of macs in large part because of the OS. I found it too limiting for what I could do. Now that OSX is built on a BSD kernel, and there's a significant amount of *nix functionality exposed, that argument no longer stands.
Do I want to use a mac? Not particularly. I don't feel that you get a lot of value for the money. But I'm a techie. I can deal with weird things in windows or strange configuration problems in Linux. Most people would rather not have to deal with either of these.
On top of that, Windows is left inherently insecure. Most people use an administrator account by default because other accounts are too restrictive. On other platforms, that idea is ludicrous. You simply use super-user privileges when necessary and otherwise, you're a standard user. This is, in part, why Windows is so vulnerable to virii.
So why am I suggesting Macs if I don't want one myself? Well, it's simple. First, I think most people--excluding gamers, due to lack of games--would actually enjoy their use more than a standard PC. Second, it might just save you from the horror that is Windows Vista. Third, it will force software companies to start looking beyond the windows market.
The jump from supporting a single OS platform to supporting two platforms is huge unless the software has been written to be portable from the start. The jump from two platforms to three is minimal. Added to this is the benefit that Mac OSX is not only POSIX compliant, but a lot of the kernel, and API is pretty similar to Linux.
The end result is that the more software there is written for Macs, the more software will be available for Linux. Which is what I'll be running.
Tips
Over the past two days, there have been a lot of letters to the editor surrounding the practice of tipping.
The fact is that a lot of people who are waiters/waitresses rely on tips to make up some portion of their income. Like it or not, that's how the industry is structured.
Tipping has some good points. It's one of the few ways in which customers can give monetary feedback on how well someone in the service industry has performed their duties. I actually wish that more service positions worked that way.
Commission is a similar concept, but in reverse. It gives equivalent feedback to the personnel, but the source of the feedback is the organization, rather than the customer. In this case, the feedback is based more on units sold rather than on customer experience. The two are linked, but not as intimately as tipping.
Tipping is ingrained in our culture. It needs to be looked on less as an obligation and more as an opportunity to let people know how well they're doing.
The fact is that a lot of people who are waiters/waitresses rely on tips to make up some portion of their income. Like it or not, that's how the industry is structured.
Tipping has some good points. It's one of the few ways in which customers can give monetary feedback on how well someone in the service industry has performed their duties. I actually wish that more service positions worked that way.
Commission is a similar concept, but in reverse. It gives equivalent feedback to the personnel, but the source of the feedback is the organization, rather than the customer. In this case, the feedback is based more on units sold rather than on customer experience. The two are linked, but not as intimately as tipping.
Tipping is ingrained in our culture. It needs to be looked on less as an obligation and more as an opportunity to let people know how well they're doing.
Tuesday, July 31, 2007
Control Loops
Part of my work is programming; as such, I occasionally run into a limitation of a language. Today, the language is C/C++ and the limitation is control loops.
Here's my beef:
If I want to make a loop where I do a complicated test every time I go around the loop, there are two options open to me:
First, I can use a while loop, and duplicate code.
The second option is that I can embed my other calls in a function with references, and use a for loop.
This one's not much better. It requires an extra function call per loop, and still requires a duplicate function call. I'd rather have a structure where I can always perform the same "init code" before the test. An extended do-while loop, if you will. Here's an example:
It could be used with a for loop as well; for loops could be extended into a do-for loop.
The most interesting thing about this is that there is no good reason that this structure shouldn't exist. It would implement perfectly well in assembly. The loop test would simply not be the loop entry point.
So where's my do-for loop? And do any other languages implement this very useful and frequently used structure
Here's my beef:
If I want to make a loop where I do a complicated test every time I go around the loop, there are two options open to me:
First, I can use a while loop, and duplicate code.
This is ugly. It demonstrates the problem, however. If xyzzy(), zxc(), and bop() are functions that are not fast to execute, saving them to a variable is imperative to performance. They can't simply be combined into a single true/false variable because gazonk needs them separately.
foo()
{
a = xyzzy();
b = zxc();
c = bop();
while (a-b>c){
gazonk(a, b, c);
a = xyzzy();
b = zxc();
c = bop();
}
}
The second option is that I can embed my other calls in a function with references, and use a for loop.
foo()
{
for (bar(a, b, c); a-b>c; bar(a, b, c)){
gazonk(a, b, c);
}
}
bar(&a, &b, &c)
{
a = xyzzy();
b = zxc();
c = bop();
}
This one's not much better. It requires an extra function call per loop, and still requires a duplicate function call. I'd rather have a structure where I can always perform the same "init code" before the test. An extended do-while loop, if you will. Here's an example:
foo()
{
do{
a = xyzzy();
b = zxc();
c = bop();
} while (a-b>c){
gazonk(a, b, c);
}
}
It could be used with a for loop as well; for loops could be extended into a do-for loop.
foo()
{
do{
a = xyzzy();
b = zxc();
c = bop();
} for (int i=0; a-b>c; i++) {
gazonk(a, b, c, i);
}
}
The most interesting thing about this is that there is no good reason that this structure shouldn't exist. It would implement perfectly well in assembly. The loop test would simply not be the loop entry point.
So where's my do-for loop? And do any other languages implement this very useful and frequently used structure
Subscribe to:
Comments (Atom)