Ever heard of event-based programming? Nope? Well, here we are.

This is a software design pattern that revolves around controlling and defining state and behaviour. It has a temporal component (the code can rewind to a previous point in time), and is perfectly suited for writing state machines.

I think I could use some peer-review on this idea.

Here's the original spec for a full language: https://gist.github.com/voodooattac...

(which I found to be completely unnecessary, since I just implemented this pattern in plain TypeScript with no extra dependencies. See attached image for how TS code looks like).

The fact that it transcends language barriers if implemented as a library instead of a full language means less complexity in the face of adaptation.

Moving on, I was reviewing the idea again today when I discovered an amazing fact: because this is based on gene expression, and since DNA is recombinant, any state machine code built using this pattern is also recombinant[1]. Meaning you can mix and match condition bodies (as you would mix complete genes) in any program and it would exhibit the functionality you picked or added.

You can literally add behaviour from a program (for example, an NPC) to another by copying and pasting new code from a file to another. Assuming there aren't any conflicts in variable names between the two, and that the variables (for example `state.health` and `state.mood`) mean the same thing to both programs.

If you combine two unrelated programs (a server and a desktop application, for example) then assuming there are no variables clashing, your new program will work as a desktop application and as a server at the same time.

I plan to publish the TypeScript reference implementation/library to npm and GitHub once it has all basic functionality, along with an article describing this and how it all works.

I wish I had a good academic background now, because I think this is worthy of a spec/research paper. Unfortunately, I don't have any connections in academia. (If you're interested in writing a paper about this, please let me know)

Edit: here's the current preliminary code: https://gist.github.com/voodooattac...

***

[1] https://en.wikipedia.org/wiki/...

Here is my idea for a time machine which can only send one bit of information back in time.

@Wisecrack has asked me about it and I didn’t want to write it in comments because of the character limit.

So here we go.

The DCQE (delayed-choice quantum eraser) is an experiment that has been successfully performed by many people in small scale.
You can read about it on wikipedia but I'll try to explain it here.
https://en.wikipedia.org/wiki/...

First I need to quickly explain the double slit experiment because DCQE is based on that.
The double slit experiment shows that a particle, like a photon, seems to go through both slits at the same time and interfere with itself as a wave to finally contribute to an interference pattern when hit on a screen. Many photons will result in a visible interference pattern.
However, if we install a detector somewhere between the particle emitter an the screen, so that we know which path the particle must have taken (which slit it has passed through), then there will be no interference pattern on the screen because the particle will not behave as a wave.
For the time machine, we will interpret the interference pattern as bit 1 and no interference pattern as bit 0.

Now the DCQE:
This device lets us choose if we know the path of the particle or if we want wo erase this knowledge. And we can make this decision after the particle hit the screen (that is the "delayed" part), with the help of quantum entanglement.
How does it work?
Each particle send out by the emitter will pass through a crystal which will split it into an entangled pair of particles. This pair shares the same quantum state in space and time. If we know the path of one of the particle "halves", we also know the path of the other one. Remember the knowledge about the path determines if we will see the interference pattern. Now one of the particle "halves" goes directly into the screen by a short path. The other one takes a longer path.
The longer path has a switch that we can operate (this is the "choice" part). The switch changes the path that the particle takes so that it either goes through a detector or it doesn't, determining if it will contribute to the intererence pattern on the screen or not. And this choice will be done for the short path particle-half because their are entangeld.
The path of the first half particle is short, so it will hit the screen earlier.
After that happened, we still have time to make the choice for the second half, since its path is longer. But making the choice also affects the first half, which has already hit the screen. So we can retroactively change what we will see (or have seen) on the screen.
Remember this has already been tested and verified. It works.

The time machine:
We need enough photons to distinguish the patterns on the screen for one single bit of information.
And the insanely difficult part is to make the path for the second half long enough to have something practical.
Also, those photons need to stay coherent during their journey on that path and are not allowed to interact with each other.
We could use two mirrors, to let the photons bounce between them to extend the path (or the travel duration), but those need to be insanely pricise for reasonable amounts of time.
Just as an example, for 1 second of time travel, we would need a path length about the distance of the moon to the earth. And 1 second isn't very practical. To win the lottery we would need at least many hours.
Also, we would need to build the whole thing multiple times, one for each bit of information.

How to operate the time machine:
Turn on the particle emitter and look at the screen. If you see an interference pattern, write down a 1, otherwise a 0.
This is the information that your future you has sent you.
Repeat this process with the other time machines for more bits of information.
Then wait the time which corresponds to the path length (maybe send in your lottery numbers) and then (this part is very important) make sure to flip the switch corresponsing to the bit that you wrote down, so that your past you receives that info in the past.

I hope that helps :)

I was so fed up with being spammed with generic messages from recruiters on Linkedin I decided to create a parody generator - Linked xD (http://devpurge.com/linkedxd/en). It was first launched in Polish and went viral; a few months later I heard even recruiters started to use it on a daily basis as an anti-pattern.

I'm still learning so take it easy on me, I'm trying to learn typescript and Factory pattern, hope I did it correctly this time :)

Link: https://pastebin.com/99AL3qah

Its only one class in hope I got it right so I can continue with the others

I have searched the universe of how go lang developers modularize their api server.... I couldn't find any.. Except for this git repo https://github.com/velopert/...
So, what kind of architecture or pattern do you use? Oh, and I am more interested in MVC