GOTO Considered Harmful

Grilled Cheese Considered Harmful

Portability & Pancakes

A UX Study

#hottakesonhotcakes

Seussical Faulting, Indeterminate Halting

Abstraction, OTP, and Approaching Complex Problems

Hi, I'm @yburyug

(Bobby)

I love really simple slides

The Halting Problem

Are all problems decidable?

Kurt Gödel:

No. (in math)

Turing:

No. (in CS)

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"
    :infinite_loop -> IO.puts "bad"
  end
end

(This soup is sad)

 

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


that would shatter your reason and scramble your mind.

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

If P's answer is "Bad!", Q will suddenly stop,

 

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!

 

 

 

 

Our Computers Are Losers

Like, no, seriously, we broke most of the computers

What did that proof do?

Abstracted the complex

(in the most fun way possible)

Choice of Abstraction

Ruby:

Syntax & developer happiness

SciPy/Numpy:

Hard (but quickly computed) math

Haskell:

Reinforcing Your Inferiority Complexes

JavaScript:

The Interwebz

Primitives

General Qualities

  • Built-in
  • Simplest unit of the language

Let's look at a random one...

Numbers

With love, from JavaScript

The 'simplest' building blocks can become quite complex

A Process as a Primitive

Parts we can (mostly) forget about

  • Concurrency
  • Fault Tolerance
  • Shared Mutable State

This lets us concentrate on what we really need to build

How to Parallelize and Isolate Bottlenecks

Umbrella Apps

Separate our concerns

GenStage

Think about the steps, not the throughput

OTP makes some Stuff really easy

and we should keep submitting conference talks about abstractions

- Dijkstra Gatesberg

(also, wasnt that a super cool paper?)

Seussical Faulting, Indeterminate Halting

By Bobby Grayson

Seussical Faulting, Indeterminate Halting

  • 957
Loading comments...

More from Bobby Grayson