a blog about things that I've been thinking hard about

The Ten Commandments of Code Execution

30 August, 2013
execute my code now, and nothing more

Write stdout to stdout. Without delay.

When you are finished, finish.

And if it crashes (or fails to parse), tell me what went wrong, and where.

Prelude

Whatever your programming language or non-programming language or framework is, please, please, please obey the following commandments.

Also, don't consider your application "finished" until it does obey them.

Personal note: these commandments are not just made up (even though I cheat slightly to get to a total of ten, because really commandment 5 is a direct corollary of commandment 4). Each one of these commandments is based on at least one actual episode of suffering which has occurred in my life.

1. Thou Shalt Provide a Command to Execute a Source File of Code

$ executewhateveritis hello-world.thesourcecodeextension

Don't make me go into some stupid UI just to run some code.

And God forbid, don't require me to start some "application server" just to print out "Hello World".

2. Thou Shalt Execute the Code Without Requiring a priori Compilation

If compilation needs to happen, figure it out and make it happen. It's not that hard.

For example, like Python.

3. Thou Shalt Output the Output to Standard Output

I want to see what my program is saying. I don't want to have to find the file where you decided to put the output. I don't want to run tail -f. Just write stdout to stdout.

(All known graphical web browsers fail this commandment. Your internal developer tools UI may be lovely, but sometimes I just want standard output going to where I want it to go.)

4. Thou Shalt Not Drop Into An Interactive REPL When Execution Has Finished

I don't want to execute my code and then enter interactive commands – I just want to execute my code. If you drop me into a REPL, then the script I called is uselessly waiting there for input when I already want it to be finished.

5. Thou Shalt Not Require An Explicit "exit()" Command To Terminate Execution of the Code

It's just annoying having to put that into my source files, and sometimes I have to run someone else's source code where I don't have the option of inserting an exit() command.

And what if my code is sometimes the top-level code and sometimes it's not the top-level code?

Do I have to write my own tricky test code to determine whether or not the end of that particular program is the end of everything being executed?

I don't want to.

6. Thou Shalt Not Buffer Standard Output

I want to see my program output right now, as it is happening.

Not some time in the future when enough output has appeared to fill the output buffer.

Right now.

(And Python and Ruby, having options to disable output buffering is not quite good enough. In fact, in general, having options to obey any of these commandments is not good enough.)

7. If There Is A Syntax Error, Thou Shalt Identify the Error and the Source File and the Line Number

Extra brownie points for also stating the position in the line.

8. If There Is A Runtime Error, Thou Shalt Write a Stack Trace with Line Numbers to Standard Error (or Output)

When something goes wrong, I want to know what went wrong and I want to know where it went wrong.

9. If There Is An Internal "eval" Command, It Shall Obey These Same Commandments

FAIL example: all known Javascript engines, which fail on commandments 7 and 8.

If Ruby can do it, then so can you.

10. When Suffering Users Ask How to Do These Things With Your Execution Script on StackOverflow, Do Not Ignore Them

For anything that your execution script should do that it doesn't do, eventually someone will ask a question on StackOverflow asking how to do it.

Do not answer the question with "It can't be done", knowing that you are going to get StackOverflow points because that is the "best answer".

Go to your application's implementation and fix the problem.

Thank you.

Vote for or comment on this article on Reddit or Hacker News ...