Computer Simulation – Further Examination

So, you are probably living in a computer simulation. Now what?

Recursive Simulations

It might have occured to you to wonder about the people that (may have) made the simulation you (may be) living in. Doesn’t the same logic apply to them, indicating that they are probably living in a computer simulation?

Well, just like you, they probably are. Eventually, though, the odds will be overcome. Eventually, somewhere in the (probably long) string of simulations that would be assumed to exist, there must be an original simply by chance. However, note that as soon as you accept an additional level of simulation recursion, the chances of being biological decrease drastically. If N is the number of minds presumed to be in all simulations created by a society, S is the number of societies per simulation that develop simulations themselves, R is the number of recursions accepted, and P is the number of biologically real entities in the universe, then the chance of being real is given by:

As you see, each additional level of recursion reduces the chance of being original by (S*N), the number of simulatons created within each simulation (or within reality): a very large number, presumably.

Religion In Simulated Reality

An interesting side effect of living in a simulated reality is that it makes God-based religions inherently possible. We were created by someone, maybe, who may have a purpose for us. However, the idea lends itself best to Taoism, which is complicated to summarize but basically believes in a central “life stream” called the Tao, or Way, that it is your job to follow. This is very easily applicable to life inside a computer program, which has a general flow of execution, and similarly applicable to life as a computer program, which is designed naturally to do specific things. This is good because I also think that Taoism is an extremely valid philosophy for life even if it’s not in a computer simulation.

Life After Death

Basically there is probably none. Your consciousness ends, your thread in the program is terminated. However, depending on the intent of the system, it could be that certain essential aspects of your personality, assigned when you are born, are recycled for future threads (purely speculation based on the use of the simulation. If it is designed to examine how certian types of individuals act in different environments, then your “type of individual” might be recyclable). And the memory used by your consciousness’s thread probably will be recycled in any case, but that is hollow: one object that uses memory doesn’t influence objects that use that same memory later.

Functional Programming in Clojure: The Nature of the Beast

This tutorial series assumes a basic understanding of Clojure’s data types, syntax, etc. To learn about this stuff, check out here or here or the Clojure website. If you’re still here, very well. We shall learn together!

Clojure is a functional programming language. What does that mean? It means that, like Haskell (for example), Clojure has immutable data structures. You can make a list or a vector or whatever, but you can’t change it later, only make another one. This raises lots of questions for people coming from an imperative programming background (C, C++, Ruby, Python, etc.): Wait! You mean I can’t change variables? How do I do my FOR loops? The problem with this thinking is that you can’t do your FOR loops. However, anything you could accomplish with those, you can still accomplish in a different way. Another major aspect of a functional programming languages are first-class functions, meaning that functions can be treated just like data. You can pass a function to a function as an argument with nary a whistle (And you will, believe me!)

Anyways, let’s talk about how a functional program looks. Generally, you define a bunch of functions, and then you use them in your main function that runs when the program is executed. In Clojure, you don’t really need a main function; just like in an imperative language, anything that isn’t a definition is just run right off, and the compiler just works its way down the file…but you should pretend that this doesn’t happen! Define as much as you can in functions, and then have a single, main function that executes your program. It’s the Functional Way. (If you must muck around with multiple-function mainloops, I suppose it won’t make stuff explode). Here’s an example:
(defn read-data-from-file [file]
... ) ; returns the data that was read from the file.
(defn write-data-to-file [data, file]
... ) ; returns...a 0, I guess. Doesn't much matter.
(defn mess-around-with-data [data]
... ) ; returns the altered data
(write-data-to-file (mess-around-with-data (read-data-from-file "/home/lolcats"))) ;Main function (not wrapped in a defun)


This method of programming may look odd, or seem unmaintainable (You end up with one big function, I mean, geez. Big functions are bad) but in reality this sort of code is even more maintainable than imperative code. In fact, this is a major selling point of functional languages. I’m not going to push you too hard, though. If you don’t want to program functionally, then just don’t (or start practicing in a language that supports functional and imperative paradigms, like Common Lisp…or Perl). After all, it will only make you a better programmer and make concurrent programming simpler.

In future episodes of FPiC, I will describe some fun functions and tricks for functional programming. Don’t touch that–wait. The internet doesn’t have dials.