# Portability & Pancakes

A UX Study

#hottakesonhotcakes

# Seussical Faulting, Indeterminate Halting

Abstraction, OTP, and Approaching Complex Problems

(Bobby)

# A Fun Proof

 No general procedure for bug checks will do.        Now, I won’t just assert that, I’ll prove it to you. I will prove that although you might work till you drop,              you cannot tell if computation will stop.
 For imagine we have a procedure called p          that for specified input permits you to see   whether specified source code, with all of its faults,            defines a routine that eventually halts.
``````def p(func) do
# Will it blend?
# Will it halt?
end``````

You feed in your program, with suitable data,

and p gets to work, and a little while later

(in finite compute time) correctly infers

whether infinite looping behavior occurs.

``````def p(func) do
# dance until some point before the world ends
# know if the function stops
end``````

If there will be no looping, then p prints out ‘Good.’

That means work on this input will halt, as it should.

But if it detects an unstoppable loop,

then p reports ‘Bad!’ — which means you’re in the soup.

``````def p(func) do
case func.() do
:no_loop       -> IO.puts "good"
end
end``````

Well, the truth is that p cannot possibly be,

because if you wrote it and gave it to me,

I could use it to set up a logical bind

Here’s the trick that I’ll use — and it’s simple to do.

I’ll define a procedure, which I will call q,

that will use p’s predictions of halting success

to stir up a terrible logical mess.

``````def q(func) do
# gonna done goof it up
end``````

For a specified program, say A one supplies,

the first step of this program Q I devise

is to find out from P what's the right thing to say

of the looping behaviour of A run on A

``````def q(a) when is_function a do
a.(a)
end``````

But otherwise Q will go back to the top,

and start off again looping endlessly back

til the universe dies and turns frozen and black

And this program called Q wouldn't stay on the shelf

I would ask it to forecast it run on itself.

When it reads its own source code just what will it do?

What's the looping behaviour of Q run on Q?

 If P warns of infinite loops, Q will quit;               yet P is supposed to speak truly of it!    And if Q's going to quit, then P should say 'Good.'   Which makes Q start to loop! (P denied that it would)
 No matter how P might perform, Q will scoop it:           Q uses P's output to make P look stupid            Whatever P says, it cannot predict Q:    P is right when its wrong and false when its true!
 So where can this argument possibly go?   I don't have to tell you, I'm sure you must know         A reductio: There cannot possibly be      a procedure that acts like the mythical P
 I've created a paradox, neat as can be             And simply by using your putative P      When you posited P you stepped into a snare   Your assumption has lead you right into my hair

 You can never find general mechanical means    for predicting the acts of computing machines;    it’s something that cannot be done. So we users must find our own bugs. Our computers are losers!

# Abstracted the complex

(in the most fun way possible)

# Primitives

## General Qualities

• Built-in
• Simplest unit of the language

# A Process as a Primitive

## Parts we can (mostly) forget about

• Concurrency
• Fault Tolerance
• Shared Mutable State

# GenStage

### and we should keep submitting conference talks about abstractions

- Dijkstra Gatesberg

(also, wasnt that a super cool paper?)