Said Svec

Holy Parenthetical Emoticons, Batman!

I’m glad that Randall has the guts to tackle the tough issues facing the world today: emoticons in parenthesis. Check out the comic.

Since I’m starting my own copyediting and proofreading business, this issue is particularly timely and relevant for me.

Randall outlines the basic options:

• blah (or blah :)
• blah (or blah :) )

The first option looks like the author threw an extra colon in there.  The second option looks like the author mashed the keyboard with her elbow.

We also need to consider these options:

• blah (or blah :-)
• blah (or blah :-) )
• blah (or blah :-D)
• blah (or blah :-D )
• blah (or blah :-)-)
• and what about (this (or this (it gets ridiculous fast :) ) )

“American” English writing style is primarily dictated by two style guides: The Chicago Manual of Style (CMOS) and The AP Stylebook.

I could only find references to emoticons and parenthesis in CMOS, and it dodges the question (source):

Until academic standards decline enough to accommodate the use of emoticons, I’m afraid CMOS is unlikely to treat their styling, since the manual is aimed primarily at scholarly publications. And the problems you’ve posed in this note give us added incentive to keep our distance.

If the experts are no help, what are we to do?

Thankfully the web makes everyone a Certified Internet Expert (including me :) ), so follow along as I puzzle it out.

Round One

• As a programmer I want each open parenthesis “(” to match exactly one close parenthesis “)”.
• As a writer I realize that an emoticon must be considered as a whole, not merely as a collection of individual characters.  Therefore any parenthesis or other character within an emoticon should have no bearing on the punctuation of other words.

Round Two

• As a programmer I know that I will try to visually match each parenthesis pair I see.
• As a writer I find “) )” slightly less offensive than “))”.

Round Three

• As a programmer I will use sed or vim or a Firefox hack to rewrite any text I don’t like, so I don’t really care what you writers think.
• As a writer I want the rules that govern “:)” to match the rules that govern “:D”.

The Decision

As a Certified Internet Expert I decree that emoticons shall be considered as a single symbol.  An emoticon shall always be followed by a space.  If an emoticon ends a parenthetical phrase, the closing parenthesis that matches the opening parenthesis must be used, regardless of whether the emoticon itself contains a parenthesis.

Correct examples:

• He said he would be happy to do it (he lied :) ).
• He lied (she knew he would :D ).

Tune in next time for another exciting episode of geeky grammar.

We have an M&M’s-filled candy machine at work and we wondered:

• What do you call it when you get exactly 6 M&M’s in a single turn of the dispenser, one of each color?  M&M Yahtzee?  Full House?
• And how about when you get more than 6 M&M’s in a single turn of the dispenser, with at least one of each color?

Suggestions?  Please leave a comment!

PS: the 6 M&M’s colors are red, orange, yellow, green, blue and brown.  See for yourself.

A software vendor gave a sales presentation at my office today.

The vendor sent two people to present – a sales guy and an engineer.

The sales guy started the pitch with an overview of the software. Sounds great, says us, but we need a bunch of technical details to know if it’s worth pursuing. This is a critical piece of software, it will interact with a lot of internal systems, and so we need to know what we’re getting ourselves into.

So we ask a bunch of questions which the engineer answers to our satisfaction. Probably 30 or 45 minutes go by, mostly a back-and-forth between us and the engineer. He knows his stuff, and he seems to enjoy telling us about their technology.

The sales guy doesn’t have much to contribute, which is fine. Or rather, it would have been fine, if Mr. Salesguy would have appeared to be paying attention, or at least not acting distracted and bored.

Instead Mr. Salesguy checks his email. Checks his voicemail. Fiddles with his pen. Fools around on his computer for a while. Does a lot of things that tell me he doesn’t care about this sale. All with a look of “Get me out of here” on his face. Which doesn’t exactly inspire confidence or help the sale at all.

What’s the lesson here? When you make a sales pitch / presentation / demo / whatever, make sure that every single member of your team is devoting 100% of their attention to the customer. Even if you’re not currently speaking, even if you’ll never speak – act interested! Better yet, BE interested! And if you can’t get interested, then you probably don’t need to be there in the first place.

http://xkcd.com/319/

I love xkcd.

And no, this “death of the desktop” post is not about how mobile devices or the browser is taking over the world – it’s about taking a step back and rethinking how we actually use computers (desktop, mobile or otherwise), and then trying to take a more usable step forward.

Thanks to Chris Jones for writing about a very interesting talk by Aza Raskin:

Video: Away with Applications: The Death of the Desktop

You should check out Chris’s summary, and the video as well.

This is one of the few videos I’m glad I watched instead of just ripped to mp3 and listened to – a lot of visual stuff, well worth the time.

(cut-n-pasted from my reply to a “Business of Software” forum question)

I resisted using an RSS reader for quite a while, mainly because it was “the new hotness” that I didn’t see any use for.

What made me start using it?

I read a fair number of websites, and I like to know when something new shows up. So I used to check each website every day and scan it for new content. Slashdot. Anything new? Yup, read a couple. Joel on Software. Anything new? No. Paul Graham’s rants. Anything new? No. Steve Yegge. Anything new? Yes, read it. You get the point.

The “load page – see if anything new” loop was getting tedious, especially since frequently there was nothing new to read, so loading the page was a waste of time.

Enter RSS. I chose NewsGator Online, subscribed to the websites/blogs I like, and *bam* – all the new content comes right to me, only one website (NewsGator) to load, no wasted time.

Well, unless you count the time I spend reading stuff on the web as wasted time, which might be accurate.

Watches designed for hard core geeks:

http://www.tokyoflash.com/en/watches/1/

As I said in “Understanding C pointers: Part 0,” I’m going to try to explain how C pointers work.

Let’s start with the basics. Here’s some simple C code:

  int x = 23;
  int y = x;

You can think of each variable as a box which holds the value of that variable. So in this example we have 2 boxes, named “x” and “y”. After these two statements execute the “x” box contains 23, and the “y” box also contains 23. The picture looks like this:

Pretty straightforward stuff. If we add this code:

  x = 17;

the pictures changes to look like this:

Nothing too fancy there.

Next example: let’s add a pointer into the mix.

  int x = 23;
  int y = x;
  int * p = & x;

If the * or & in the above code scare you, please take a deep breath and relax. We’ll get through this, I promise. :-)

“x” is a variable of type integer. So is “y”. The “int *” before p means that p is a variable of type “pointer to integer” otherwise known as an “integer pointer.” Nothing magical there. The “&” before “x” can be read as the “address of x,” or “the box named x.” Which means the pointer “p” points to the box named “x”.

As in the previous examples we have a box named “x” and another box named “y”. This example adds a pointer to an integer called “p”. You can think of this pointer as simply another box, named “p”. The value in the “p” box is a pointer to another box. For the boxes “x” and “y” we can say things like “x holds the number 23,” but for the box “p” we say “p holds a pointer to the box named “x”".

A picture is worth at least a few words:

Watch what happens when we add this next line to the example:

  *p = 17;

The * before the “p” tells us we’re changing the value of what “p” points to. We are not changing the value of “p” itself. The number 17 gets put wherever the value of the “p” box point to – which is the “x” box in this case. After this code runs our picture looks like this:

Notice that “p” has not changed. “p” still points to box “x”. Only the value in the box that “p” was pointing to changed.

Let’s add a couple more lines to that example:

   p = & y;
  *p = 42;

The first line changes the value in the box “p” to be a pointer to the box “y”. The 2nd line changes the value in the box that “p” points to be 42. The result looks like this:

Drawing these pictures may seem unnecessary, but I guarantee that drawing them will help you understand your code. Even if you understand pointers completely, when faced with a pointer-laden interview question it’s a good idea to draw your data structures and pointers. This way the interviewer can see how you’re thinking about the question, which is frequently more useful than simply getting the “right” answer.

Okay, that’s the basics. See – pointers aren’t that bad.

And it turns out that the way a computer actually implements variables/pointers is a lot like our simple “boxes” model. Tune in next time for more about that.

“C/C++ Pointers are evil. Ditto direct control of memory via malloc, free, new and delete. Java, C# and other ’safe’ languages are the wave of the future, man!”

Even if you shouted a hearty, “Amen, brother!” after reading those sentences, the C/C++ languages can teach you something useful. Understanding how to directly control memory with “close to the metal” languages like C and C++ can make you smarter, which is a good goal even if you won’t admit to having used such old-school languages.

Of course that new knowledge may displace other knowledge you want to retain, like Mr. Belvedere episode plot lines or your wedding anniversary. You’ve been warned.

Over the next few posts I’m going to try to explain how C pointers work. I assume you’re at least a little familiar with a C-type imperative programming language – if you’ve ever seen Pascal, BASIC, Fortran, C# or Java you should be fine.

I’ve always heard pointers introduced to students as “a difficult thing, this is hard, you won’t understand it…” – which is baloney. It’s worse than just baloney, actually – it’s spoiled baloney (or bologna, I guess), because it not only tastes bad, but also makes you sick. It sets you up for failure. Telling someone that they can’t learn something, and then attempting to teach it to them is… well, I’ll just say it’s foolish and leave it at that.

Pointers are NOT difficult to understand when explained well – I hope that I’m able to explain C/C++ pointers in an easy to understand way – please let me know if anything doesn’t make sense!

“Understanding C pointers: Part 1” is now available, check it out.

xkcd.

Donald Knuth.

xkcd and Donald Knuth. (check out 21:32 into the video) (yes, it’s safe for home and work)

It doesn’t get much cooler than that.