# Software

One regret I have is that I’ve never released much software to the public. That’s not because I haven’t written much software. Over the years, I’ve written many tens of thousands of lines of code in a variety of languages, most of which is related in some way to economic research.1 It’s easier to learn new concepts if I can write an implementation.

The primary reason for not releasing software to the public is the amount of overhead involved. You have to:

• Clean the code up.
• Write good enough documentation.
• Make sure it works on many different platforms other than your own.
• Prepare a repo or another form of website.
• Respond to questions.

I simply do not have time at this stage of my life/career to dedicate several hours a week to writing and maintaining code I don’t use. That may strike some as selfish, but as we teach in ECON 101, there’s always an opportunity cost. If I say yes to giving away software, I have to say no to one or more competing uses of my time, and the cost-benefit analysis has not worked out in favor of code sharing.

This site is a small move in that direction. For now, here are three projects.

tstools. Repo | Documentation for a few functions | Installation instructions I created this package many years ago for one of my classes. A few years later, someone created a different tstools package, having nothing to do with mine, and uploaded it to CRAN. If you install the CRAN package using install.packages, what you will find is that nothing works as planned. That is the correct behavior. I will delete support request email messages without a response if you installed the package from CRAN rather than installing my package. For some reason, even after telling people this, I have occasionally still received email bug reports about nothing working as anticipated.

embedr. Project page In my opinion, D is the best option out there for writing fast code for economics research, due to it feeling like a scripting language but running like C.

sfb. Repo | Blog example | Wiki example I’ve been working on related projects for years, but eventually came to appreciate the convenience of having an entire website in one file. Some use cases:

• A Git repo that you might not visit for a few months. You want to open one file in your browser and have a complete website. You do not want to mess around with dependencies and web servers and figuring out how to build things.
• A wiki you want to share with someone else. The ideal case for this is documentation for a software project.
• Documenting a project you’re working on in case you will have to return to it in the future.
• When you want to quickly post something for someone else without worrying about building a website.

There are a variety of situations where a website (multiple html files that are connected with hyperlinks) is useful, but where the overhead of building and/or doing more than opening one file in a browser is too much of a burden. Single file websites are my solution. I have a wiki version (with tag support, interwiki linking, and backlinks) and a blog version (with automatic generation of the index).

It’s inspired by TiddlyWiki, and superficially similar to it, but the two are rather different in practice. A single file website is edited directly in a text editor. TiddlyWiki realistically requires a web server and allows you to create posts inside the browser.

1. Although I’ve tried many languages (having started programming in the mid-1980s), most of the code I’ve written in the last five years has been R and D, with some Perl and Javascript on the side, and other languages for odds and ends.↩︎