Code Reuse

Musings on Future Workflows

I've been programming a long time (over 20 years), and almost half that time was in a simple little IDE known as QBasic. Now I’m not one for complex IDEs and can’t stand to use XCode of Visual Studio, but I really miss certain features from QBasic when I’m doing modern JavaScript development.

One feature I loved was the ability to pause execution of the program and edit the code or run code in the repl-style “immediate” window. Browser dev tools are getting pretty good in this regard today. I don’t think it’s possible to hot rewrite js functions without reloading the page/process, but otherwise, it’s pretty powerful.

The other feature is a little harder to explain. When writing a program, it was often a single long file, but you didn't see the whole file at once. You created subroutines and only one was visible at a time. There was an overview dialog where you could see the subroutines and jump between them.

I want to merge this idea of each function being it’s own module with the modern practice of sharing small, single-purpose packages with the internet. There are many people who advocate publishing many small modules to npm for maximum code reuse. This is great, but I feel it’s way too much overhead to be used this way by most people. You need to:

1. Think of a name that’s still available in the global npm namespace. (naming is hard, especially given global uniqueness constraints)
2. Create a github repo with similar or same name (there are different namespace rules here)
3. Clone the github repo and copy your code into it.
4. Add a README with documentation on how to use the code
5. Add some tests to ensure the code does what it claims to do. (If you’re hard-core TDD, you do this before writing the code in the first place)
6. Fill out a package.json file with metadata like author, version, name, license, link to repo, issue tracker, command to run unit tests, etc..
7. Declare any dependencies in package.json and in require calls in your code.
8. Publish to github and npm.

Now the order of these operations isn't strict and there are tools to automate some of this, but I see some serious issues for mainstream adoption for use in all functions I write for my project.

Not every function I write is going to be it’s own open-source project complete with formal docs, unit tests, issue tracker, etc. Many function are unique to my application and in either case, I don’t know up-front which code will be globally useful and which will not. The global public namespace makes things really tough in this regard.

Ok, we’re all aware of the difficulty in maintaining hundreds of such “projects”, but what is the solution?

Imagine a world in which your editor worked like QBasic. There was a dialog for creating a new module. It would take just a few seconds to create a new module. Then you could write the code, click a button and add docs or unit tests if you so desired and then you were done. The module would be tagged with information required to find it later when you wanted to use it.

In this system, a programmer would have a local library of modules that they could curate and nurture. They could reuse their code between projects. The modules could be organized or tagged by project, type of work, etc and the library browser would make it easy to discover and organize things. The programmer could mark which modules were ready for public use and mark them as public and include the code license.

In addition to the local library, the programmer could browse the public library that contains all code published (made public) by their peers. This could have a social network of friends who’s code you prefer to use because you trust them, but you could also discover code written by strangers. There would be no global namespace, but rather a decentralized network of personal libraries.

If you wanted to make changes to a friend’s project, you could import it into your library and make local modifications (assuming the license permitted it). The system would know where the original source was and would allow you to push changes back upstream. You could make your local fork public and others could use it directly in case the original author didn't take the changes.

This is the system I’m slowly developing. Js-Git and Tedit are just the start. My goal is to encourage discoverability and reusability of decentralized code libraries.

I want to make writing and publishing a code module as simple as posting a message to FaceBook. I want code source hosting and published modules hosting to be the same thing and decentralized. I want to make programming approachable.