For those not yet familiar with the awesomeness of Strangeloop, it is a yearly conference about “emerging languages, concurrent and distributed systems, new database technologies, front-end web, and security.” This year, Strangeloop was at the Peabody Opera House in St. Louis, and I found it informative, inspiring,and incredibly fun.

I decided to take some time and compress my experience into a reasonable blog post, focusing on only the things that jumped out as interesting or worthy of exploration.

I took notes about these talks (but went to many more):

The Mess We’re In

Deterministic Simulation Testing of Distributed Systems

Consensus Without Consistency

Idris: Practical Dependent Types With Practical Examples

The Wolfram Language

Transducers

Spreadsheets for Developers

Cap’n Proto And Rust

You Can Be a Kernel Hacker

Clojure in Unity 3D

You can read about all the sessions here. Checkout the archives if you’re from the future, or any of the repositories on github.com/strangeloop.

The most interesting topics I learned (grouped by talks I took notes about) were:

###The Mess We’re In:

  • It’s incredibly fun to think about the ultimate computer and what it could do. Imagine black holes as computers! And check this out: “Ultimate Physical Limits to Computation” — http://www.signallake.com/innovation/SLloyd021400.pdf

  • URIs are leaky and broken; how about something like hash://988881adc9fc3655077dc2d4d757d480b5ea0e11? Instant verification of a piece of content? Noticing changes easily? How do you design a nice, general resource identifier with better guarantees than URIs? This allows us to refer to something without names or locations

  • How about “least compression difference” as a metric to figure out file similarity? A ~ B if size(compress(A)) ~ size(compress(concat(A,B)). Joe calls this a good step in making a “Condenser” (a reducer of entropy; just merge all very similar files somehow, along with only having unique files)

  • Joe compares the number of possible states of a computer program to the number of atoms in the universe. Shouldn’t the comparison instead be to the number of possible configurations of atoms in the universe? That’s a lot more, right? But programs definitely are complex beasts.

Deterministic Simulation Testing of Distributed Systems

  • Will recommends debugging the simulation of a distributed system instead. I think this ends up working as an approach because in the process of building this simulation, you nail down your assumptions as code and actually codify, somewhat, the possible lifetimes of your system. Instead of just coding up the system (while testing individual bits inside the system), now you’re doing that and also incorporating knowledge about possible run times.

  • I really like Will’s point about trying to make your CPU’s more efficient than the real world. I mean, the universe is trying to find bugs in your distributed system (as people use it, bugs arise), and so is your deterministic simulation testing setup. Your job is to find those bugs faster than the universe finds them. I guess this is why they chose Flow and C++, for performance reasons. The more possible lifetimes you can simulate, the more bugs you can find before they actually appear.

  • To explore: Hurst exponent, stable parisian distributions, Paxos and how the common approach might not correspond to real behavior of unreliable processors

Consensus Without Consistency

  • CAP theorem: Consistency, Availability, Partition tolerance, pick two.

  • Systems like Paxos, Raft, Zab, and Viewstamped Replication represent the solutions that prefer Consistency and Partition Tolerance

  • Systems like Cassandra, Riak, Mongo, and Couch represent the solutions that prefer Availability and Partition Tolerance

  • Things to explore:
    • CALM principle (consistency as logical monotonicity)
    • ACID 2.0 (of course, it’s atomicity, consistency, isolation, and durability)
    • CRDT (conflict free replicated data)
    • Fan out on write vs fan in on read
  • project to check out: https://github.com/soundcloud/roshi

Idris: Practical Dependent Types With Practical Examples

Brian McKenna (@puffnfresh) talked about using Idris to do real things.

  • To explore: window manager written using Idris

  • Example given:
    • wrote up a type for binary characters and a binary string
    • mentioned how refl simply uses the inference that Idris makes
    • mentioned how proof search is like asking Idris to just find whatever fits the bill
    • incorporate computational complexity right in the program as invariants… huh!
  • programming in Idris looked like proof writing

The Wolfram Language

  • super cool demos of the language. Deployment is super easy apparently.

  • it’s a batteries-included language with a power plant for batteries.

  • Ethiopian multiplication algorithm

  • Rosetta Code is cool, btw

  • I especially liked the live manipulation of camera input.

Transducers

transducers

  • Clojure!

  • “Transducers are composable algorithmic transformations. They are independent from the context of their input and output sources and specify only the essence of the transformation in terms of an individual element. Because transducers are decoupled from input or output sources, they can be used in many different processes - collections, streams, channels, observables, etc. Transducers compose directly, without awareness of input or creation of intermediate aggregates.” – clojure.org

  • Rich gave the example of loading luggage onto an airplane. When instructing somebody to do this, you would hear yourself say “while the luggage is coming down the belt, check that each one is closed and pick separate by brown or any other color” and not “while the luggage is coming down the belt, check that each is closed. Now, while the luggage is coming the belt again, separate by brown or any other color”. It makes no sense to concretize sequences when you’re doing multiple transformation on the elements; you should be able to express the transformations without reference to any concrete collection.

  • Visual typing language used to describe transducers and to illustrate the very particular spec that they have.

Spreadsheets for Developers

Fálienne Hermans

  • turing complete spreadsheet? nice!

  • selection sort in a spreadsheet!

  • ! game of life would be fun to implement in a spreadsheet

  • interesting features of spreadsheets:

    • conditional formatting

    • intersection of two ranges. just ‘=A5:Q5 someotherrange’

    • named ranges

    • arbitrary value in constants

    • dereference (kinda) with INDIRECT

  • The paper “Analyzing and Visualizing Spreadsheets” is worth checking out for more details

  • test coverage……

    • even complexity metrics. Write this test first. hmm

  • “spreadsheetlab.org”

Cap’n Proto And Rust

  • Encoding how long something exists in types! Zero overhead check against unsafe pointers (pointers to garbage)! More. “A lifetime is a static approximation of the span of execution during which the pointer is valid: it always corresponds to some expression or block within the program.”

  • This is really effing cool!!!

You Can Be a Kernel Hacker

  • Nice haircut!

  • strace magic. Figure out how an arbitrary executable behaves, what files it accesses, what messages it sends out, all the nitty.

    • strace -etrace=open google-chrome

    • it’s dtrace on OSX

  • some system calls:

    • execve
    • open
    • sento/recvfrom
    • connect

  • debug lib problems by running strace!

  • track l1 cache misses. holy shit. perf

  • instrument specific kernel functions, using trace

  • /proc to get deleted files back!!!

  • treat programs you use as a black box

  • strategies to learn:

    • livegrep.com
    • source.apple.com

  • kernel modules as an easier method

  • rickroll kernel module

  • kernel modules

    • init()
    • cleanup()

  • eudalypta challenge

  • linux weekly news

  • GSOC

Clojure in Unity 3D

Ramsey Nasser and Tims Gardner @ra and @timsgardner

  • why’s game dev hard?

  • necessary components:
    • input, state, time
    • performance, stability
    • subjectively good

  • Brandon Bloom : solve every hard cs problem 60 times a second

  • Clojure <-> Clojure-CLR <-> Mono <-> Unity

  • covered:
    • components
    • repl
    • interop
    • hydration
  • todo:
    • gui integration
    • documentation
    • examples
    • guanrantees
  • possibilities:
    • snapshotting
    • logic driven design. generate whole collection of all possible levels. generative puzzles!
    • procedural meshes
    • speculative AI
  • github.com/clojure-unity