Blog -- Page 2

When to use TeX vs Org-Mode vs OpenOffice

Originally posted 2016-02-09

There are a number of tools out there which allow you to compose documents. Three of my favorites are TeX, Emacs org-mode, and OpenOffice. Each of these tools is open-source and allows the user to script and modify their experiences.

Below are some factors which I think are helpful to consider when choosing between these document-preparation tools.

Use TeX when:

  1. You want output with very high quality appearance.
  2. You want to take advantage of TeX's powerful layout algorithms and routines.
  3. You want to typeset a bunch of mathematics.
  4. You want the document to be version-controlled using Git or similar SCM system.

Use Emacs org-mode when:

  1. Content is king, and you don't at this stage want custom layout.
  2. You don't need access to the underlying layout engine.
  3. You want to enter content, including mathematics, in a distraction-free and straightforward way.
  4. You want easy export to LaTeX, PDF, and HTML.
  5. You want the document to be version-controlled within Git or similar SCM system.

Use OpenOffice/LibreOffice when:

  1. Ease of composition is more important than highly polished end-product.
  2. You are content with fairly standard and simple layout conventions – and don't require pixel-perfect control or algorithmic layout optimization.
  3. Mathematical typesetting is not that important to the document.
  4. You need to edit the document in conjunction with other users who are not technical and do not know TeX.
  5. You want integration with OpenOffice Calc (spreadsheet).
Post Truncated Read Full Post

Fundamental Principles in Writing Computer Code

Originally posted 2016-01-25.

1 Introduction

There are a huge variety of programming languages out there, an infinite number of concepts, and numerous ways to think about any given problem. How can one logically discriminate among these choices to make wise programming decisions?

First off, there exist a number of software-design camps, each with their own design methodoligies and folk-loreish guidelines.

Some people claim that you should thoroughly document your code with comments, others claim that you should use comments sparsely lest they become out of date and misdirect future readers.

Most people think it's important that programmers "write understandable code." But how does one define what is understandable and what is not? Is it better for code to be concise and dense (ala APL) or verbose and wordy (ala COBOL)? Some people argue that verbose code is easier to understand, as it can sometimes be "self-documenting", while others claim that dense code is easier to read, as it is shorter.

Object Oriented designers love applying acronyms such as SOLID and GRASP to software. Functional designers love applying principles and techniques such as immutability, declarativity, currying, and higher-order functions.

Every programmer has a preference for a certain programming language – probably the one which she has spent the most time with. People get into passionate debates comparing languages and software ecosystems.

Post Truncated Read Full Post

Prognostication vs Software Development: Subjectivity and Complexity

Posted 2016-01-25

"Crede, ut intelligas" – "Believe that you may understand"

– Saint Augustine, Sermon 43.7

As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality.

– Albert Einstein, Geometry and Experience

1 Uncertainty in Life

Underlying every experience in life is uncertainty. It is in general impossible to obtain complete confidence about anything.

When a human walks through a room, she can instantly filter out irrelevant details. The reason that she can filter out irrelevant details is that we as humans subconsciously accept certain truths and foundational beliefs. Without making these operational assumptions, we would have to consider an untold number of possibilities at any given point in time and we would not be able to function in the real world.

Examples of details which we safely disgard include:

  1. The ceiling is not going to fall on me, I do not need to analyze its structural integrity.
  2. The pattern of light on the wall is still, therefore it is unlikely that it is a threat to me but rather is just light shining through the window.
  3. The laws of gravity, force, and momentum will continue to stay in effect.

Subconsciously accepting these beliefs and many others about how our world functions allows us to focus on important threats and goals, such as

  1. My little sister just stuck out her leg to trip me.

Post Truncated Read Full Post

Why I Prefer Emacs+Evil to Vim
Originally Posted 2015-10-22
  1. Variable width font support.

    I studied my own reading speed on a variety of documents, and found that I read variable width text about 15% faster than fixed width text. I don't mind writing code in fixed-width fonts, but if I am going to use one text editor for everything, then I very much appreciate having variable-width support.

  2. org-mode > markdown

    Org-mode allows you to write structured content within Emacs, and supports the writer with a variety of useful features and tools. Besides the rich editing, export, and extension possibilities offered by emacs org-mode itself, I find that the org format is superior to markdown for my purposes. Two primary reasons for this are that org provides syntax (such as drawers) for defining all sorts of metadata about your text, and also that org is designed in such a way that it is basically equally usable as variable-width text and fixed-width text. In particular I dislike the extent to which markdown relies on fixed-width text for its display features.

  3. evil >= vim.

Post Truncated Read Full Post

Common Lisp Standard Draft

Originally posted 2015-10-11.

UPDATE 2017-04-26: Updated this page to link to my new and improved version of the ANSI CL standard draft which now includes a pdf sidebar outline.

Below is a link to a build of the publicly available ANSI CL standard draft, which has been somewhat modified to include a pdf sidebar outline. The sidebar makes it much easier to navigate this 1200 page plus document!

If you are curious to see what modifications I had to make to the tex sources to obtain the above pdf, please refer to the gitlab repository hosted here.

1 Backstory

The Official Common Lisp standard ANSI X3.226-1994 (now referred to as ANSI INCITS 226-1994) is available from ANSI for a cost of $60. However, besides the fact that this document is expensive, it is also known that this document is actually a low-quality scan of the original.

Many people apparently use the Common Lisp Hyperspec, but I personally find this document highly confusing and difficult to learn from in any meaningful way. It is from the early days of "hypertext" and employs so many links as to be basically unreadable in my opinion.

According to Franz Inc"free use, copying, distribution"Tex sourcesPostscript copies

Post Truncated Read Full Post

The Scientist's and Engineer's Guide to Digital Signal Processing

Author: Steven W. Smith

I found this to be an excellent book which makes DSP concepts and terminology accessible to self-learners. The author intersperses examples aimed at giving an intuitive understanding of the subject matter throughout the book, and backs up these examples with clear explanations of the concepts themselves. HIGHLY RECOMMENDED.


Prev Page
Next Page