## Emacs 24.5

The Change Log is here.

## Sacha Chua and John Wiegley on Elisp Development

Sacha Chua has a great video chat with John Wiegley on Elisp development. If you work with Elisp, you really should spend the time to watch it.

Chua and Wiegley start by discussing paredit and its capabilities. I've been using paredit for years and still learned a couple of things from their discussion. As I and others have said, it can be difficult to get used to but once you do, you won't want to live without it.

After the discussion of paredit, Wiegley makes the same observation that I often have: Emacs is really more of a Lisp environment than an editor. He even explicitly casts it as a descendant of the Lisp Machines. His remark was fleeting but captures, I think, why Emacsers are so devoted to their editor. It provides an easy-to-customize environment for getting work done. All sorts of work, not just editing.

Next they move on to discussing debugging and edebug. I found this one of the most useful parts of their discussion. It's something I've long wanted to learn more about. As Wiegley says, using print statements in your code to debug works well in most languages—Elisp included—but the Emacs debugging facilities are so good you don't need to do it when debugging Elisp. If you want to learn more, Nic Ferrier has an excellent 10 minute video on edebug that I wrote about here.

Wiegley shows how easy it is to use edebug. If you write any Elisp at all, it's worth spending a bit of time learning the basics. Ferrier's video can help with that as can Wiegley's discussion.

After the edebug discussion, Wiegley moves on to several Emacs functions that can help with development. These include

• elint-current-buffer
• elp-instrument-function and elp-results
• memory-use-counts
• ert

The video is just over an hour so you'll have to schedule some time but, again, you should because it's well worth your time. Happily, Chua hinted that they'll be doing more of these videos. I hope so because they're really useful.

Speaking of Chua/Wiegley chats, there's also a nice video on Wiegley's use-package package. I had intended to write about that but wanted to watch it again first. Sadly, life intervened and I lost the moment so I'm glad to have a chance to mention it here. This is another great video and well worth your time.

## Python Tools for Emacs

Sean Dague, who works on OpenStack, has a nice post on Emacs Python tools he uses to deal with the large Python code base of the project. If you work in Python, you'll want to take a look at his post. You may pick up some useful ideas.

If you're familiar with cscope, you will probably be interested in PyCscope, a project that parses your code's Python AST to build a cscope index. The project's README says that using the Python AST gives a much more accurate index than using cscope alone.

He also mentions fly-hack a backend for flymake that extends flake8 with some additional rules. Again, if you're writing in Python, you may get some ideas.

Dague discusses other tools as well so you should definitely give his post a read.

Posted in Programming | Tagged , | 5 Comments

## Abrams on Literate Programming

Howard Abrams has a nice post on Literate Programming. By now that's a fairly hoary subject—the idea dates back to Knuth in the early 1980s—but Abram's post is nice because it considers how to do this with Emacs and Org mode.

If you've been reading Irreal for a while, you know that I really like and use Org Babel all the time. It's perfect for reproducible research and keeping all your calculations and data with the rest of your report or paper. John Kitchin has really leveraged this idea for his group's publishing. His publications are generated directly from Org mode with the calculations performed in Org mode code blocks right in the source file.

Another possibility with Org mode and code blocks is to export the code to another file using the tangle command. That way the code can be compiled separately while at the same time appearing as part of the documentation. Since the code source file is generated directly from the documentation, the code and documentation never get out of sync (although the commentary may, of course). Abrams shows how to do this with a nice, easy-to-follow example and then shows both the finished document and the resulting code files (one for the code, one for the tests).

If you'd like to try Literate Programming but want a lighter weight approach than CWEB, give Abrams post a read. It's really easy to try the method out to see if you like it.

Seems right to me:

The//Intercept has an excellent article on how to choose secure passwords that are (relatively) easy to remember. The problem with passwords is that they are almost never secure. Most people choose stupid ones (password, 123456, $\dots$) and even those of us with a bit more of a clue can almost never choose a good one. The reasons for that are psychological but the TL;DR is that humans appear to be preprogrammed to prefer patterns even when they're trying not to.

Because of this, the only secure passwords are randomly chosen ones where the human proclivity to impose order and pattern on them can not come into play. That's why secure password management requires a password manager such as 1password, KeePassX, or similar program. These programs choose long random sequences of characters that are very secure for passwords and then store them in an encrypted database.

The only remaining problem is choosing a password for the password manager. It holds the crown jewels so passwords like password are non-starters. The//Intercept's recommendation is one that I've given here many times: Diceware. The idea is that you roll 5 dice to randomly choose a word from the Diceware list. Do that 5, 6, or 7 times and you have 5, 6, or 7 random words that together have enough entropy to resist even NSA brute forcing. This, of course, is the idea behind the famous XKCD Correct Horse Battery Staple cartoon. The big advantage of a sequence of random words like this is that while they have the same or more entropy than a long random sequence of characters, they are relatively easy to memorize.

I previously posted a Lisp implementation of Diceware that uses a cryptographically secure random number generator and is therefore very secure. There is also C version that's a bit has a tiny bit of bias and is therefore slightly less secure. It would be easy to make it completely secure by using the 8K Diceware list that the Lisp version uses.

UPDATE: Intercepts → Intercept's

## Ferrier on Agile

InfoQ has a nice interview with Nic Ferrier on good software and agile. Irreal has mentioned Ferrier several times: he's a good hacker and someone who deserves to be taken seriously.

Ferrier's take is the agile is a way to improve communication among a development team and that many of it's most contentious features are not really so much essential to agile as a possible way of increasing that communication.

Take a look at the interview to get the best idea of his views. I don't know much about agile and therefore don't write about it very much because I don't want to be this guy:

## Discovering Calc

As some of you know, learning more about about calc has been on my TODO list for sometime (that's literally true—it's in my agenda). I last wrote about it just last week. I've finally stopped procrastinating and starting learning calc.

I began by reading the first of the three manual sections, Getting Started. This section gives a brief demonstration of how calc works and highlights some of its capabilities. Like those who came before me, I was left in awe. I knew it was quite capable but had no idea how capable.

One of the big items for me is arbitrary-size arithmetic. It seems I'm always fiddling around with large numbers and native 64-bit integers simply aren't big enough for a lot of what I do. That's why I usually bring up a Lisp REPL for my calculations—the big int arithmetic. I'm not going to give up my Lisp REPL, of course, but for quick calculations calc seems like a real win.

My next step is to tackle Part 2, Tutorial. As I work through that, I'll probably make occasional posts of interesting things I discover. So far, my only regret is that it took me so long to get started. If you have to do non-trivial calculations and use Lisp, or Python, or something similar, you really should give at least the first part of the calc manual a read. It may suggest a new—and sometimes better—approach.

If reading the manual seems too arduous, Karthik C has a nice video that shows off some of calc's capabilities. It's just short of 49 minutes so you'll have to schedule some time. Very much worth your time though.

## New Programming Jargon

Recently, I wrote about the glories of the Jargon File and remarked that the hacker jargon it records is often hilarious. It's easy to burn up a couple of hours browsing around in it.

Now Jeff Atwood over at Coding Horror has a list of his 30 favorite new terms that he's culled from Stack Overflow. These are very funny and definitely worth a couple of minutes of your time.

Some of my favorites are:

• Yoda Conditions
• Higgs Bugson
• Common Law Feature
• Protoduction
• Jenga Code

I'll let you check Atwood's post for their definitions. Go ahead; you need a bit of comic relief.