Different Languages…

Sometimes I think it’s a tragedy that two people merely think they’re speaking English to each other, but in reality, they’re not only talking past each other, but speaking completely different languages.


Okay, I’m going to vastly oversimplify things here, but I’ve got another proposition. Engineering speak is not english. Neither is computer-geek speak. Neither is builder speak, physics-speak, contractor speak, architect speak, navy speak, or doctor speak.

Sure, the words sound like English. Some of them. At least until you hit that which we call “jargon” but is really your first clue you’ve left english as most people know it. Some of the words even share a similarity of meaning with their common origins.

An old joke to illustrate:

If you give the command “SECURE THE BUILDING”, here is what the different services would do:

The NAVY would turn out the lights and lock the doors.

The ARMY would surround the building with defensive fortifications, tanks and concertina wire.

The MARINE CORPS would assault the building, using overlapping fields of fire from all appropriate points on the perimeter.

The AIR FORCE would take out a three-year lease with an option to buy the building.

It’s hoary, and too-often told, but aside from what it illustrates about stereotypes of the various armed services, it also illustrates that while those services are using something resembling english, they have an entirely different set of assumptions and definitions for what appear to be the same sound symbols, when operating in a military context, than when using regular English.

Sure – look the word “secure” up in the dictionary, and you’ll see enough different definitions to support all of those interpretations. This allows us to walk away secure in the knowledge that we’re only speaking one language.

Of course, we are talking about the language that mugs other languages for spare grammar. Where Spanish, German, and French might use one word each to describe a range of nuances, based on context, English borrows a word from each of them, and uses each for a subtly different meaning.

It gets worse when you talk programming languages. Sure, the vocabulary is smaller, and the rules of grammar and syntax, while different for each, are fairly rigid and well defined. Yet, if you look at the actual words used – if, until, go, class, procedure, etc., they look like english. English with very formalized meanings.

A non-programmer looking at code from several languages like Ruby, Perl, Java, C, and Python might have a hard time telling that they’re even different languages. Well, except Python, which happens to be pretty visually distinctive. And yet, while the languages have many commonalities, the subtle differences in between them, and between these languages and other languages like Smalltalk and Haskell, result in completely different metaphors and methods for solving the same problem. Completely different ways of thinking about things, different models of thought.

Each language, each set of restrictions, each context, each set of grammatical and syntax rules, that tells us how to interpret and understand these symbols which often look alike, result in you having to think in a completely different way to solve a problem. In much the same way that the different grammar, structure, and conjugation rules for German, Spanish, and Lithuanian require you to approach speaking a simple statement in completely different ways.

Learning to be a carpenter involves not only learning words you may have never heard of that only apply to carpentry, but definitions of words, and terms of art, that may have completely different meanings from those outside of that context.

And learning those multiple contexts and the different patterns and assumptions and metaphors behind them make it easier to find solutions that people who’ve only seen one of those concepts may never have spotted. Programmers are often recommended to learn several languages, especially oddball ones with completely different idea structures like Haskell, because even if they never make a living programming in those languages, it will help them become better programmers and problem solvers.

The same is true of learning a new skill like carpentry, painting, hiking, skating, or shooting. It gives you a new language (even if it sounds like english) and a new set of thought-patterns and symbols.

Which brings me to another, final thought.

Most of these “languages” I’ve discussed here are still, in the end, subsets of English. But, while the lessons and tools they give you may be different, just like a ‘real’ foreign language, they give you a very similar experience in mapping a new set of mental tools.

But it really does confuse communication when two people think they’re talking “English” – and they’re not. At least not the same english.

New Options for Version Control for the Mac

If you’re writing code. Ever. Be it Java, Python, Objective-C, Perl, or plain old C, you really, really need to get in the habit of using a version control system for managing your code. It allows you to experiment, and to easily roll back your code if you completely mess something up.

There are several excellent and simple systems available. My preferred system is Git, but Mercurial is also an excellent, modern system to use. It’s also fairly easy to set up. And if you don’t want to mess around with the command line a lot, or don’t want to pay for the (excellent) Tower, then there’s a new, free option for managing your git repositories at the popular online service GitHub. (Note – you don’t need to host your repositories online – they never have to leave your computer. Unless you want to share them with other people not in your home or office).

Markdown and Writing

While major writing projects requiring lots of research, sometimes I just want to write up several paragraphs in an article without a lot of fussing about. Text editors are perfect for this, while also guaranteeing, unlike Word, Pages, or even more open formats, maximum future readablity and recoverability. Unfortunately, going back in to properly add links, italicize or quote text, etc., can be a pain.

Thus was born Markdown. Markdown is both a plain-text syntax for tagging text for web/formatted output and a program of the same name that converts text in the markdown syntax to valid HTML. Since the formatting and syntax use conventions already long common in emails, it’s very easy to mark up the text, and text formatted this way is highly readable even as plain text.

Since I don’t feel like breaking out a massive writing tool like Open/Libre Office or Scrivener every time I want to write up a few paragraphs, and since I absolutely hate going back after the fact to format everything in even the best WYSIWYG implementations when I could do it from the keyboard as I type, I really appreciate the ease of use.

I also appreciate the fact that it’s widely available. While blogger doesn’t directly support it, it’s fairly easily added to WordPress, and is available for Posterous and Squarespace.

So here’s my cheat sheet that I keep in Emacs when I need a reference. Most of it is paraphrased from the original, and further details or nuance are linked to on a section-by-section basis to Gruber’s original spec:

Markdown reference:

You’ll note the headers for each section link to the respective section in Gruber’s syntax page for more information on the available options and nuances.

Block Elements

A paragraph is simply one or more consecutive lines of text, separated
by one or more blank lines

This is a new paragraph.

use two


Two types.

This is H1 (with ===== underneath)

This is H1 (with ===== underneath)

This is H2 (With ------ underneath)

This is H2 (With —— underneath)

Alternately, you can use ‘#’

# One '#' for h1

One ‘#’ for h1

## Two '##''s for h2

Two ‘##”s for h2

Three '###' for h3, and so forth.

Three ‘###’ for h3, and so forth.


Markdown uses email-style “>” characters for blockquoting. They can be
nested by adding additional levels of ‘>’. They can also contain other
markdown elements (headers, code blocks, etc…

> This is a blockquote with two paragraphs. Lorem ipsum dolor sit amet,
>> Inset second level.
> Donec sit amet nisl. Aliquam semper ipsum sit amet velit. Suspendisse

This is a blockquote with two paragraphs. Lorem ipsum dolor sit amet,

Inset second level.

Donec sit amet nisl. Aliquam semper ipsum sit amet velit. Suspendisse


Markdown supports ordered (numbered) and unordered (bulleted) lists.

Unordered Lists

Unordered lists use asterisks, pluses, and hyphens — interchangably — as list markers:

- Item a
- Item b
- Item c
  • Item a
  • Item b
  • Item c

Ordered Lists

Ordered lists use numbers followed by PERIODS. Order is irrelevant.

1. Dog
2. Cat
3. Kids
  1. Dog
  2. Cat
  3. Kids

List items separated by a space have the content of the <li> wrapped
in a <p> paragraph tag.

Code Blocks

To produce a code block in Markdown, simply indent every line of the
block by at least 4 spaces or 1 tab. For example:

This is a code block.

A code block continues until it reaches a line that is not indented
(or the end of the article).

HTML in a code block is converted to entities, and Markdown syntax is
NOT processed within a code block.

Horizontal Rules

You can produce a horizontal rule tag (<hr />) by placing three or
more hyphens, asterisks, or underscores on a line by themselves. If
you wish, you may use spaces between the hyphens or asterisks.


Span Elements


Inline or reference. In both styles, the link text is delimited by
[square brackets]. See the original
for a
more thorough explanation of reference-style links.

This is [an example](http://example.com/ "Title") inline link.
[This link](http://example.net/) has no title attribute.

Reference-style links

[This is linked] [id1] to something
[id1]: http://www.midknightgallery.com/  "Midknight Gallery home Page"

This is linked to something

Also, a reference can be implicitly identified by the linked content

  [The Midknight Gallery][] is a great site.
[The Midknight Gallery]: http://www.midknightgallery.com/ "Home"

The Midknight Gallery is a great site.






Emphasis can be used in the middle of a word:



Backslash to escape literal asterix’s like this: \*.

Span of Code

Wrap a span of code within a paragraph with backtick quotes (`)

To include a literal backtick character within a code span, you can
use multiple backticks as the opening and closing delimiters:

``There is a literal backtick (`) here.``


Inline image syntax looks like this:

![Alt text](/path/to/img.jpg)
![Alt text](/path/to/img.jpg "Optional title")

Reference-style image syntax looks like this:

![Alt text][id]

Followed by the same syntax as reference links:

[id]: url/to/image  "Optional title attribute"


Backslash Escapes

Markdown provides backslash escapes for the following characters:

\   backslash
`   backtick
*   asterisk
_   underscore
{}  curly braces
[]  square brackets
()  parentheses
#   hash mark
+   plus sign
-   minus sign (hyphen)
.   dot
!   exclamation mark

Automatic Links

Simply surround the URL or email address with angle brackets.


Markdown will turn this into:

<a href="http://example.com/">http://example.com/</a>

Emacs Fixes: Issue 2 – Transmit Compatibility

Transmit is an excellent FTP client, and hands down my favorite for the Mac. One of its niftier features is that of opening up a file on the remote server in a local editor, and uploading the changes automatically as they are saved in the editor.

This didn’t work out of the box in emacs, but I found a fix (h/t to Justillilly.com). 

In your user directory, you’ll find a hidden file called “.emacs” Edit the file to add the following:

(setq backup-by-copying t)

Or, you can use the in-emacs preferences. If you type M-x (refer to the tutorial if you’re not sure what that means), and then “customize”, you’ll get to a customization screen. Select “Files”, then “Backup,” and toggle “Backup By Copying” on, and save the results. This will automatically add the entry to your ‘.emacs’ file.

Emacs Fixes: Issue 1 – Command Line Access

BBEdit and Textmate have a nifty tool they install so that when you’re in the command line, you can use a command like “mate” or “bbedit” to open a specified file. When the file opens in the editor, you can even close out the terminal window without crashing the graphical environment.

While it’s possible to open the GUI version of emacs from the command line with a specific file, it’s not quite so graceful if you forget and close out the terminal window – it crashes. I’ve tried several workarounds, but none of them are truly satisfactory, especially given that I don’t have to open up the terminal to see hidden files in the first place.

So of course you learn the basics well enough that opening up emacs in the terminal allows you to get done what you need, and then realize that to open a file anywhere on the drive, even hidden files and ones hidden from you by the computer, is drop dead simple. 

C-x C-f (Control -X followed by a Control-f) allows you to open up the file browser, starting at your home directory (shown by a “~”). Hitting return then changes the display – the buffer – to the specified file or the contents of the selected directory. From there you can navigate through the file system with much of the same ease as you can through the terminal. 

The lesson here is that you don’t even need the terminal to open up a hidden file. If you are in the terminal because you want to pipe the results of a command to emacs, you can either deal with the terminal – emacs is emacs – or bring up the graphical version. In the last case, just don’t close  out the terminal window before closing out the graphical one.

In short – this isn’t an issue so much as it just works different. 

Making Emacs Work the Way I Wanted it To.

Not all was sweetness and light. Changes mean things are different, and comfortable habits die hard. 
Several things I missed from BBedit and/or TextMate, that were my priorities for “fixing” were:
  1. Some things just are different. The graphical version doesn’t open from the command line without a few clunky integration issues, but it’s something that isn’t really needed either. 
  2. Out of the box, emacs didn’t save things back to disk so that Transmit, my FTP client of choice, would copy the changes up to the server.
  3. Out of the box, the gui version of emacs doesn’t do color themes beyond the stock syntax-coloring-on-white. 
  4. Emacs didn’t do syntax hilighting for web pages using several programming languages (php, Javascript, and of course HTML are common), out of the box.
  5. The syntaxt hilighting for multiple languages is still somewhat clunky due to a few bugs. Javascript is different from what I’m used to in BBedit, but just as good. 
  6. I am still learning how to implement “lint”-based debugging of javascript  – a module that was available for TextMate.
  7. I still need to learn how to program for emacs. I also haven’t learned to replace the convenient snippet structure that TextMate had, but the programming built into emacs is powerful enough to write entire games that run within emacs.
  8. I still haven’t learned how to do a diff well – BBedit and TextWrangler (the free version with less features) still rule here.
First of all – keep in mind why I’m making this change. I’m finding myself in a position where I need a tool I can use anywhere. So, I’ll address how to tackle each of the first five that I’ve already solved, and any other issues that I fix to my satisfaction. 

Getting Started on Emacs for Macs

Getting started on learning, really, really learning emacs is not, in and of itself, that hard, but will be markedly different from almost anything you’ve done in Word, Notepad, or any word processor you’ve used in the last ten years. Especially if you’ve started out on Macs in the first place.

You’ll have to unlearn a lot that you “know.” Also, if you’ve used other high-end text editors like BBedit, you’ll find some features not available right away out of the box. 

As usual, the best way to learn is to actually do it. 

A good site to learn more about about emacs as you get started is the Emacs Wiki. The site includes all sorts of information, including where to get different versions, and how to setup certain features. They also have an excellent page on where to get and set up Mac versions. I recommend you download the version compiled by Vincent Goulet because it includes several common packages and needed adjustments to work smoothly with the MacOS clipboard, and then that you skip on to do the tutorial.

The tutorial? Emacs is ‘self-documenting,’ and includes an excellent tutorial that leads you through the basic commands to move through a document and modify it. To start the tutorial, first start up emacs, and then type CNTRL-h (hold down the control key and press ‘h’, often referred to in emacs as C-h), followed by a ‘t’. 

I’ll be back later to work around some things I missed from using BBedit and TextMate.

Necessity is a Mother

Simplicity is a balance. When it comes to tools, it’s often a balance between factors that cause drag like clutter and analysis paralysis, and the issue that a srewdriver makes a piss poor hammer. Too many tools for a job prevent you from mastering the ones you have and waste your time choosing between them. Not enough tools and you end up wasting time making do.

When discussing programming earlier, I discussed that you should choose a text editor, and stick with it, learn it. I also outlined why I chose the text editors I was using. 

Well, circumstances have changed, and so have my tools.

One of my two go-to editors (TextMate) still has not seen any real progress. Any promises of an updated version fixing the problems I and others experienced still being so much vaporware. Also, I was spending most of my programming time in Xcode, and while Xcode has its faults as a text editor, losing the integration, code completion, etc. just wasn’t worth it. Lastly, I’ve found myself spending a lot more time in not only the Mac terminal, but working with other, linux computers, and needed to finally buckle down and learn an editor that would be available – or installable – almost anywhere I was logging in without having to learn yet another set of tools.

Thus I’m back to learning Emacs.

Why two tools? The friction of working around Xcode’s external editor support when it did exist – it’s not available in the latest update – was just too much trouble, and I still needed something I could use everywhere else. Screwdriver and a hammer.

So yes, there’s a learning curve. Emacs is insanely powerful and was designed in a pre-mouse world for handling text in a number of different contexts. But the basics are the same in the OSX terminal, Cocoa, a linux terminal, Windows, XEmacs under gnome or KDE. Whatever I learn, I learn once, and I can use it anywhere.

In Support of “Laziness”

Reminiscent of Lazarus Long’s story of “The Tale of the Man Who Was Too Lazy to Fail” from Time Enough To Love, I recently stumbled into this quote:

Code you don’t write is the easiest and fastest to debut, test, document, read and support.

This quote to me outlines several principles. 

First – while I strongly believe in learning by trying the hard, slow, painful way, by going through the basics, this doesn’t apply to when the priority is to actually produce. Also, the whole point of of doing it hard, slow, and from the basics is to gain an intuitive grasp of how to do it more efficiently, to improve the quality of your work, so that you get better at it, not to be a masochist.

This applies to code as to anything else. Brevity matters. As the quote attests, any line of code you don’t have to write is not only less time spent typing, but the time figuring out how to do it in fewer steps often pays itself back in better performance, and easier maintenance. Lastly, the next time a similar solution is needed, you don’t have to think about it anymore, and you still get the rest of the benefits.

Learning by Doing, part Three

I’ve discussed before my friend Mike, and his quest to learn new things by mastering them, by taking the time to do them the painful, hard, and slow way so that he could get a nearly intuitive feel of what was involved. 

Again, the goal here wasn’t to knock out as many tomahawks./bows/etc. of a good quality in as short a time as possible – in which case he would have had no problems with modern power tools like dremels, etc., but to learn the skills required at a deeper level.

That depth takes time.

We’ve seen the books. “Learn php in Seven Days!” 

Let’s try the reality: Teach Yourself Programming in Ten Years

In the article, Peter Norvig, researcher at Google, utterly skewers the attitude that you can “learn to program in ‘x’ in seven days.”

Again, it takes time. It takes practice. It takes repetition and challenging yourself to build new constructs and try new things so you don’t just understand the basic theory, but you have a near-intuitive grasp of how they fit together. You have a model in your head of what actually works, and what doesn’t.

The key is persistence.