Strange Loop Notes - Day 2

Tagged as programming
Written on 2012-09-25 10:17:00

Computing like the brain

SDR Properties:

  1. Similarity: shared bits = semantic similarity. A similar bit vector has similar semantics.

  2. Store and Compare: Store indices of active bits, don't traverse the whole thing. Subsampling is OK though!

  3. Probability shows errors are very unusual even with subsampling. If you do make a mistake, it's a close/semantically similar one.

  4. Union membership: Sets! Is this SDR (10..001) a member of this union of SDRs (00..001)? Very high correctness.

  5. The key to machine intelligence is sparse distributed representation.

Sequence memory:

Predictive Analytics Today:

Future of Machine Intelligence:

Behind the Mirror: The birth of Light Table

35 years later...

Runaway Complexity in Big Data

Missed due to chatting with Chris Granger and other awesome folks.

Computer Architecture from the 1960's

Guess Lazily: Making a Program Guess and Guess Well

Okay, I couldn't keep up and had you been there you wouldn't blame me.

But this was cool and analagous to the Byrd/Friedman running programs backwards and forward stuff from yestereday.

Also, Buyer Beware: Oleg's papers may be more clear than his presentation style. :P

An Audobon Society for Partial Failures

Expressing Abstraction, Abstracting Expression

Aspects of Expressiveness:

Expressiveness over performance, every time! (in Ioke)

Types of Abstraction:

Macros!

Different kinds:

  1. C-style Preprocessor macros. No structure. Just string processing! AAAAAGHHHH.
  2. AST macros. Work on S-Expression, not AST.
  3. Same language available as transformation language and host language. Metalanguage, etc.
  4. Often use functions in a complex macro.
  5. Template macros. Type-directed expansion, turing complete.
  6. This is scary because they are TWO different languages.
  7. Similar situation to complex Type Systems in Haskell/Scala.

Modularity!

Static typing!

Generics!

Lin-guis-tics:

Communicating indirectly with many audiences though. The machine, team members, ops, etc. Even business stakeholders! Totally unique to programming.

Syn-tax:

Visible Programming

5 Principles to aim for:

  1. Must enable the programmer to read the vocabulary (program).
  2. Must enable the programmer to follow the flow (Call-flow-graph).
  3. Must enable the programmer to see the state (as it executes).
  4. Must enable the programmer to create by reacting (iterative, interactive development).
  5. Must enable the programmer to create by abstracting (what sort of tools?).

Examples of these principles in a hypothetical environment: (JS & Processing for this talk)

  1. Normally we go to the docs or source. This sounds like using 4 sliders to choose arguments to something in Photoshop. UI garbage.
    • Mouseovers/tool-tips on each token in the code. Make meaning transparent!
  2. Great explanations show, not tell. Make it possible to see the output of a given form as inputs change. Explain in context!
    • Imagine a cooking show that introduces ingredients and then cuts to the result. You can do it yourself!
    • Step through execution via a slider. This helps but it is not enough. We can't see patterns in execution.
    • Plot it on a timeline. Which lines executed when? what patterns or alternate executions could there be?
  3. It is common to expect programmers to manipulate code in their heads. WHY?
    • It is the responsiblity of the environment to show what changes a line causes in the running program.
    • Show what lines executed, when, and what effect they produced.
    • Larger programs just become a data visualization problem.
    • Show the data, show the comparisons, eliminate hidden state.
    • Making global variable change visible is an option for inherently stateful lines.
    • More programs running forward and back. (editors note: you guys are jerks and you hurt my heart)
  4. Composing things in your head doesn't scale. Maybe this is why only small programs are beautiful! Use the environment as an external imagination.
    • Live coding is one way to approach this. Bit of a straw man argument here.
    • Core idea is you want to have program supply you ideas, not just keep you from hitting recompile.
    • Take completion further, what if autocompletion lists also included suggested values?
    • Useful but clearly limited to the domain of this specific problem: Processing/GUIs and visualization.
    • Dump all the parts on the floor so you see your raw materials. Functions are lego blocks. Have API browsing. Offers another problem-specific example.
  5. Encourage starting with constants, than adding variables and functions later once you know what behavior you want.
    • Editor can help by offering "factoring relations".
    • I know this wasn't intended to resemble a working production system but I was hoping for more than this.
    • I thoroughly agree with his premises but I do not think this was a convincing way to demonstrate their need.
  6. How does this scale to real-world programming? I have answers but I think it's better to question the question.

  7. Asking how to scale to everyday programming is like asking how engines benefit horses. We have to work like this.

  8. Argues against static runtimes. I agree but this was a weak treatment. There is tooling to work around this.

  9. "There is no future in destroy-the-world programming. It's got to go." - Agreed.

The State of Javascript

Apparently all that was library and application improvements. What about code generators?

So bytecode...

Epilogue

I was going to have to miss the last keynote and two talks as well as all the camaraderie that would occur after. Delta had screwed up my flight and I didn't have a hotel room for the night. Thankfully, some Loopers came to my rescue though Delta still managed to extract $170 from me. Soulless corporations! It was totally worth it. I can't think of a more worthwhile or energizing way to spend 3 days. I'd like to thank everyone I was able to spend time drinking and chatting with especially Scott Vokes, Paul Snively, Andreas Fuchs. Brian Rice, and Jose Valim. Obviously, I never want to go home.

Previous
Next
comments powered by Disqus

Unless otherwise credited all material Creative Commons License by Brit Butler