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.
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.↩︎