Skip to content

How To Swear Proper

Or: authentic British usage of swearwords

This is really simple; just use “fuck”/“fucking” as punctuation as well as emphasis.

Disclaimer: my native dialect is West London, which to my ears has the most unpleasant of the London accents. However, I went to a public school, and most of the time I sound close to RP (Received Pronunciation, or “BBC English”), but with a slight nasal twang.

All of the London regions use a similarly restricted palette of swearwords, and English usage in general doesn’t vary by all that much across the country. My favourite example would have to be a transcript from the Trogg Tapes; see Reg Presley’s recent obituary and other articles in the Guardian for an example.

A few comments on some alternative words:

  • “bloody” is the general purpose mild adjective.
  • “bugger” is much more offensive than in American; it refers to the sex act, not insects.
  • “cunt” is rarely used (perhaps surprisingly), and is considered more offensive.
  • “shit” is a popular, mild swear word.
  • “motherfucker” is American, and never used.

For Scots examples I would suggest browsing Billy Connolly on YouTube, and for Irish try Shane McGowan; however, Northern Irish is recognisably different in sound from Southern Irish.

While we are discussing swearing, one American habit is more likely to cause British swearing than any other: talk about beer. We have beer, we have lager, and we have stout (or Guinness, almost synonymous) which are subsets of beer; “ale” is not a word we use, unless by a CAMRA (the real ale society) member. “Pale ale” is said as if it were all one word. Beer is served at cellar temperature, which is cool, not frozen – and we could have a very similar discussion about correct serving temperatures for wine. Most red wine should be served at the temperature of a pre-central heating room, not warm like soup.

2013 03 16 paul Life in General Comments (0) Permalink

Learn lisp

I’m a big proponent of the #pragprog adage that you should learn a new programming language every year, but I have sadly lacking at putting it into practice, despite having an early advantage (BASIC, Fortran, Algol 60, APL, Pascal, Forth, COBOL, , IBM assembler, 6502 assembler, etc). Then in the early 90s I had started to move forwards again, with C and Objective C, and I came across the great lisp wars. Now it is 20 years on, and I’ve taken to (slowly) learn lisp.

Why? Well, not because of functional programming; I get the idea, but it’s oversold, and although lisp can be used for FP, that’s not its raison d’être. Instead, lisp has two big and compelling advantages, over and above its historical importance:

  • lisp is the best way to learn how and when to use recursion;
  • and lisp (at least in some forms) is a very pure and simple programming language, and as such, I would argue, is highly suitable for teaching beginners good habits.

I have even found myself strongly recommending lisp to novices who want to learn good programming habits over the usual C and Javascript suggestions (both of which are, IMHO, poor choices). As a non-expert in lisp, I have nevertheless found out some basic information, and have some ideas on how best to start learning.

First of all: there is Scheme, and there is Common Lisp; both have many variants. Scheme is the simpler of the two, and as such tends to be preferred for computer science instruction; Common Lisp has a more complex syntax (and many more functions), and has more practical instruction available. They are close enough that an experienced programmer could probably handle learning both in parallel. Maybe. There is a third version, which is really just a take on Common Lisp, which is the lisp inside emacs; if you use emacs, then try this as well.

Get Racket (aka DrScheme); this is a Scheme implementation with an IDE. On MacOS X, “brew install plt-racket” will suffice. Also install Common Lisp: “brew install clisp”.

There are two highly regarded source books for lisp, both aimed at Scheme: Structure and Interpretation of Computer Programs(SICP) (online), mobi online videos, and The Little Schemer; search for the pdf version, which is widely available online. Neither of these are really ideal for the lisp beginner. Three other books are recommended as ground up introductions to lisp, suitable for the complete novice:

I don’t have the same depth of resource for the Common Lisp side, but Land of Lisp works well for me, and people in general suggest both Practical Common Lisp, and various titles by Paul Graham.

2013 01 23 paul Programming for Apples Comments (0) Permalink

Letterpress.app Word List

Here is a little utility to assist solving Letterpress games.  It comes largely (almost entirely) from an article on Stack Overflow.  It uses /usr/share/dict/words for the word list, and requires a initial stage to convert this into an anagram dictionary for efficiency.  Even so, it still takes a minute to run on my recent iMac.

The anagrammer.py:

#!/usr/bin/env python

f = open('/usr/share/dict/words')
d = {}
lets = set('abcdefghijklmnopqrstuvwxyz\n')
for word in f:
  if len(set(word) - lets) == 0 and len(word) > 2 and len(word) < 9:
    word = word.strip()
    key = ''.join(sorted(word))
    if key in d:
      d[key].append(word)
    else:
      d[key] = [word]
f.close()
anadict = [' '.join([key]+value) for key, value in d.iteritems()]
anadict.sort()
f = open('anadict.txt','w')
f.write('\n'.join(anadict))
f.close()

And then the solver.py:

#!/usr/bin/env python
# http://stackoverflow.com/questions/5485654/how-can-this-python-scrabble-word-finder-be-made-faster

from bisect import bisect_left
from itertools import combinations
from time import time

def loadvars():
  f = open('anadict.txt','r')
  anadict = f.read().split('\n')
  f.close()
  return anadict

# letterpress scores
scores = {"a": 1, "c": 1, "b": 1, "e": 1, "d": 1, "g": 1, 
         "f": 1, "i": 1, "h": 1, "k": 1, "j": 1, "m": 1, 
         "l": 1, "o": 1, "n": 1, "q": 1, "p": 1, "s": 1, 
         "r": 1, "u": 1, "t": 1, "w": 1, "v": 1, "y": 1, 
         "x": 1, "z": 1}

def score_word(word):
  return sum([scores[c] for c in word])

def findwords(rack, anadict):
  rack = ''.join(sorted(rack))
  foundwords = []
  for i in xrange(2,len(rack)+1):
    for comb in combinations(rack,i):
      ana = ''.join(comb)
      j = bisect_left(anadict, ana)
      if j == len(anadict):
        continue
      words = anadict[j].split()
      if words[0] == ana:
        foundwords.extend(words[1:])
  return foundwords

if __name__ == "__main__":
  import sys
  if len(sys.argv) == 2:
    rack = sys.argv[1].strip()
  else:
    print """Usage: python solver.py """
    exit()
  t = time()
  anadict = loadvars()
  print "Dictionary loading time:",(time()-t)
  t = time()
  foundwords = set(findwords(rack, anadict))
  scored = [(score_word(word), word) for word in foundwords]
  scored.sort()
  for score, word in scored:
    print "%d\t%s" % (score,word)
  print "Time elapsed:", (time()-t)

 

Converting this to use a screen capture from iOS is an exercise left for the reader; QED (which I always translate as: it all goes to show).

Tagged ,
2012 11 03 paul Programming for Apples Comments (1) Permalink

DODOcase Durables – iPhone 5 Wallet

DODOcase are responsible for the lovely Moleskine-like iPad cases and the texturally delicious BOOKback, and when they produced a new line of cases for iPhone/iPad/MacBook Air, I ordered one for my new iPhone 5 immediately.

The case consists of a khaki (they call it “sage”) waxed cotton sleeve lined with orange cotton material (some of their web pages talk about felt, but this isn’t), with a bridle colour (tan) leather wrapper forming a pocket on either side. There is a label sewn inside, and some orange stitching on one side, which is a nice visual touch. It’s pretty, and the wax isn’t the thick layer you find on Barbour and Belstaff jackets that covers everything you touch for a very long time.

My phone slips in very easily, and would slip out equally easily if I held the wallet upside down, which I don’t – this isn’t a problem. The two pockets I am using to replace a card case and money clip, so one hold two credit cards (and could hold an id easily enough as well), and the other hold a few bank notes. There are still a couple of cards left in my card case, but I don’t really need to carry them.

I had intended to carry the wallet in my front jeans/trousers pocket, exactly where I carried the card case and money clip (but with the iPhone in the other front pocket), but it hasn’t worked out that way, as the wallet with the iPhone is significantly larger. As a result, I have mostly moved the wallet to a jacket inside breast pocket. I can easily slip the iPhone in and out of the wallet without removing the wallet from my jacket pocket. This has been convenient so far; I will probably experiment with putting it back in my trouser pocket and shuffle around my pen-knive and handkerchief to find the optimum fit.

With the iPhone out of the case, the cards would easily fall out of the wallet if held upside down; with it in the case, they are a snug fit. This is unlikely to be a problem with my usage pattern, although I would advise owners to be careful of leaving the wallet sitting on a table, etc – exactly as with a normal wallet.

I find it useful to stow my iPhone “head down”, meaning with the connectors (headphone jack and Lightning connector) showing, as then I don’t have to remove it to charge, and can listen to music with the iPhone still in the wallet and in my pocket. I have noticed it occasionally turning on as I put the phone back in, which could be my fumbling, but I suspect is the top edge on/off switch being activated from the “head down” insertion. This isn’t a problem at all, as I keep a passcode active, so no butt-dialling.

I’ve had it for over a week now, and I like the overall feel; the materials are indeed durable and the leather feels luxurious. There is some sign of a patina starting to form on the leather, and the waxed cotton should do the same.

The quality of the materials and manufacturing, as expected from DODOcase, is excellent. As it isn’t an exact match for my previous use pattern, as is replacing several different items, I still have to fully adapt to its use, but I am confident that will happen in time. I like it: a lot.

Tagged
2012 10 14 paul Life in General Comments (0) Permalink

Device Sizes

There’s been blog chatter over this since Tim Bray posted his blog entry, and this is something I have had strong opinions about since the Newton, and even earlier (remember Steve Ciarcia’s lunchbox CP/M computer in Byte? It seems highly unlikely that anyone does).

Continue reading ›

2012 07 11 paul Life in General Comments (0) Permalink

Student Recipe Book

This page is a set of links to my “student” recipe book. These are Pages documents shared on iWork.com, and can be viewed, downloaded in various formats and printed. The basic idea is to create a collection of student friendly recipes that are nutritious, cheap to make and simple to prepare. Continue reading ›

Tagged
2012 04 22 paul Life in General Comments (2) Permalink

How To Buy Things

Which applies to everything, although this is an approach that I discovered (as did many other people) when dealing with very expensive software.

The Wrong Way

This is how most people buy things. Find a list of “features” (features are attributes of a product, and could be anything; true, false, or utterly fictional); then find an alternative product, and measure the length of the two lists. Buy the one with the longest list.

This is wrong because the buyer has no personal involvement in decision making, and swallows whole the tales of the sellers, who obviously have a vested interest in selling their product, by beating a competitor. This is what causes the phenomenon of the people who believe the last person they spoke to, ignoring all others. No discrimination is applied, and this approach will fail.

The Half Right Way

Do you know someone who always buys the cheapest comparative product? We all know someone like this. It’s a poor way of making a decision, but it’s the way governments do it, as well as shoppers in some supermarkets – the cheapest ones, obviously. This approach fails because it doesn’t consider value.

At its heart, value is something very simple. Is it worth more to you than it costs? When “worth” is easy to calculate, which it often is for a business; say, the number of man-months to write a program, or to build a new office, then that decision becomes simple, and anyone in a position to make that sort of decision should know enough about driving a spreadsheet (or a calculator) to be able to reduce the decision down to numbers, to a simple profit or loss.

But when making a decision over two packs of vegetables in a supermarket, or two brands of beans, you have to weigh the worth to you, or your family, or better taste, better nutrition, and better ease of use. Sometimes this can be a clear decision, but more usually it isn’t. in these cases, what works best is to have previously considered the relevant factors, and decided on their priority.

The Right Way

Gather lists of features. Consider them all, and separate them into three parts: “must have”, “nice to have”, and “irrelevant”. Then match each product against these lists. If only one product hits all of your “must have” features, then you know what to do. If more than one product has them all, then you can take into account the “nice” features. If no product has them all, then you can either reassess your feature lists, or (more sensibly) decide not to buy.

This is extremely simple. An easily led person can skew the lists to favour one competitor, but then it becomes obvious to everyone who is cheating, and how. This works for big decisions as well as small, everyday ones. Sometimes a decision seems hard, but becomes obvious when you understand which features are important.

2011 10 09 paul Life in General Comments (0) Permalink

Hiring – how to ignore the guidelines and get it right

I’ve been a hiring manager for twenty years (low ’80s to low ’00s), but I haven’t done any hiring in the last (almost) decade, and I’m disappointed how things have changed in the software industry over that period.

I was hiring for technical support and programmer positions, ranging from IBM assembler and mainframe MVS experience to Java and Objective-C programmers; sometimes this would have been mainstream qualifications, and other times not. I did a good job of this; thinking back, most of my hires received a substantial promotion not long after joining – a real promotion, but just moving from a trainee grade to another; and some left to join Apple and other significant employers. I didn’t like that much, but I think it shows that my hiring approach was working.

Current practice seems to be to require applicants to jump through humiliating hoops to prove their current knowledge of existing technologies – JavaScript, C++, .NET, where the hoops are basic algorithm tests. But this doesn’t get anywhere near the real issues. However, I have the Internet, search engines, auto-completing syntax aware IDEs, and an excellent collections of books; and with new technologies coming out all the time, keeping up with the best solutions can be a full-time job. The exam approach just isn’t a good one; in fact, getting the right employee with this approach can only be a matter of luck, where the hiring manager effectively ignores the guidelines, knowingly or not.

I don’t want a new employee who will be bored with their routine work – I want to stretch them, and I want them to learn on the job; in fact, if they won’t be regularly learning, they are wrong for the job, and I don’t think I can emphasise this enough. I’m not alone in saying this; if you read any of the books and blogs over the last ten years, you’ll have seen this time and time again. So what’s going wrong?

My strategy was simple: I wanted to hire people like me. Specifically, people who can think, can learn, and were motivated to achieve. I also had a hiring trick: my benchmark, if you like, was (and is) the classic hacker, as described in the appendix to Eric Raymond’s Jargon File (see here). The Pragmatic Programmer book covers the same ground from a different direction, but the conclusion is just the same.

2011 10 02 paul Programming for Apples Comments (0) Permalink

SOE Status: iPhone app for monitoring SOE game servers

SOE Status is in the App Store now (http://itunes.apple.com/gb/app/soestatus/id463597867?mt=8). Link is to the UK store, US store link is: http://itunes.apple.com/us/app/soestatus/id463597867?mt=8

This takes the data from the new SOE status page at http://www.soe.com/status/ and displays it on your phone; you can select data for a single game and refresh that display if you wish.

It runs on iPad as well as iPhone – it probably won’t run on iPhones using OSes older than 4.1. Now that it’s shown up in the store, there’s a couple of minor tweaks I will make and resubmit. Any suggestions or bug reports are welcome.

Tagged
2011 09 14 paul Programming for Apples Comments (4) Permalink

Pragmatic Thinking and Learning, by Andy Hunt

Recent reading has included “Pragmatic Thinking and Learning” by Andy Hunt, from @progprog. Most interestingly, it covers almost exclusively topics that I have absorbed over the last 30 years or so – meditation, context switching, personality types, left/right brain thinking, mind maps, GTD, and so on. I didn’t realise that I knew so much! Continue reading ›

Tagged ,
2011 08 18 paul Life in General
Programming for Apples Comments (0) Permalink