RubyFringe: Day 2 Notes, Part 1

If Kant Had a Computer (Geoffrey Grosenbach)

- Super special trivia fact: Only speaker to wear utilikilt

- I was going to throw the word "philosophy" into the title of
  this presentation, but I remembered what Hawking wrote in
  "Brief Hisory of Time": his publisher said that for every equation he put
  in the book, he'd halve the readership

- This isn't going to be a super-practical talk
- My degree was in philosophy
- Had computers been around back then, some of the philosophers may have hacked;
  I think it would've appealed to them
- But since they did not have computers, they became mathematicians and thinkers
  instead
- A number of philosophy and programming concepts were the same

- Immanuel Kant's most famous work is "Critique of Pure Reason"
- Written in German, but it's so obtuse that even German students
  read the English translation, which is supposedly easier to understand
- Kant wrote easier-to-read follow-up in which he lambasted people for
  not being able to follow Critique of Pure Reason
- Don't worry: I found ideas from books that are easier to understand
  than Kant's

- The natural vs. the simulated
    - Philosophers like to think that their thoughts match up in the real world
    - a priori vs. a posteriori knowledge
    - Mythical Man-Month: We're building things out of pure thought-stuff

    - In philosophy, I learned about different ways of thinking, arguing
      and fallacies
    - I can see where this knowledge would help -- I recently read a
      "Rails doesn't scale" post in a blog, where the rebuttal in the comments
      went "Too much emphasis on REST and not enough on internationalization
      is why it doesn't scale!"
    - Philosophy teaches us that a single argument against something
      is not enough to refute it

- Consider these three points below. Where are they from?:
    1. Limit new features to a well-defined scope
    2. Implement the feature, analyze the result
    3. Take the result into account for subsequent features
- Did they come from a 37signals manifesto? Scrum? Agile?
- No, it's the scientific method!
- The method is centuries old: take an idea, test it, measure, record and report the results
- As developers, we're kind of detached from the process:
    - In many cases, we just do the implementation
    - Sometimes the idea's not ours
    - Oftentimes we don't do the analysis or consider the result for
      subsequent features
- Exercise for the reader: Contrast the scientific method with development

- Music
    - I play the double bass, a big instrument
    - Everyone knows what a cello is, but nobody recognizes an upright bass
    - Been playing for a while, but finally found a great jazz teacher
    - I learn by doing, being made to perform with other musicians in the class
    - Old ideas have been around for a long time
    - As a bass player (as mentioned in the jazz presentation yesterday),
      my is to provide the root. Typically, I want to play the lowest note
      possible
    - That's a constraint -- I'm working within a set of rules

- Working with Less
    - Miles Davis: criticized for playing too few notes
    - Improvising: instead of starting out by running through the notes,
      start with silence, play a note or two, and then just get on with it

- DeMorgan's Law:
    - not (p or q) = (not p) and (not q)
    - A useful identity!

- Recent study of PhD's: the philosophy majors were the most employed group
- Philosophy is just math expressed as statements of logic

- Terms, referents, proper names, designators, initial baptism
    - Saul Kripke: Naming and Necessity
        - Descriptivist theory of names
        - For any name, we can come up with a list of descriptives that
          identify that name
            - For example, for the name "Hampton Catlin", we can come up with
              descriptives like: "Works at Unspace", "Lives in Toronto",
              "Changes his hair frequently"
        - Causal theory of reference (advocated by Kripke): When a baby is born
          and given a name, from that point on we can have a causal sequence...
    - This also applies to programming:
        - Creating an object involves naming it
        - We can match up a name with the object it references
        - We also have the decriptivist theory of names with duck typing:
            - Consider the respond_to? method and other forms of introspection
              we use to get descriptives attached to a named object

- Natural Kinds
    - Philosophers like to ask themselves about the way we group or categorize things:
      Are the groupings we create inherent in the nature of the grouped objects,
      or are these artificial groupings that we have assigned based on some
      perception we have of those things?
    - In web development, we like the idea of REST
        - It's an artificial grouping
        - It's the result of a decision by a person that a certain way of
          grouping things is the right way to do it
        - You need to understand REST is not a hard-and-fast natural way of
          organizing things, but an arbitrary way

- Spinoza
    - He's a philosopher with an interesting life: born somewhat wealthy, worked as lens
      grinder, excommunicated from his church, ended up turning down a lot of honours
      in his life, gave family inheritance to his sister, died early
    - He said that the whole universe is just a single substance
      (you can spend weeks studying just what he meant by "substance")
    - Each of us is just different states and concentrations of this substance
    - Reminded me of cloud computing
    - Problem: under his philosophy, we have no free will
    - As programmers, we like free will (we like our programs doing
      what we intend them to do)

- The Sapir-Whorf Hypothesis
    - Go look up the Sapir-Whorf hypothesis if you haven't already heard of it
    - Benjamin Whorf's quote: "We dissect nature along lines laid down by our
      native languages. The categories and types that we isolate from the world
      of phenomena we do not find there because they stare every observer in the
      face; on the contrary, the world is presented in a kaleidoscopic flux of
      impressions which has to be organized by our minds - and this means
      largely by the linguistic systems in our minds. We cut nature up, organize
      it into concepts, and ascribe significances as we do, largely because we
      are parties to an agreement to organize it in this way - an agreement that
      holds throughout our speech community and is codified in the patterns of
      our language."
    - The practical upshot: language anchors thought (Kant thought the same
      thing)
    - Why I like Ruby: helps me organize my thoughts
    - Since a programming language can shape the way you solve problems, you
      should stretch yourself and:
        - Learn other programming languages, especially if their paradigms
          are quite different from ones you're used to
        - Write different types of apps -- if you're used to writing web apps,
          try writing a desktop app, and vice versa
        - Do you typically write apps? Try your hand at writing a library!
    - Stretch your thinking!

Ruby Beyond Rails (John Lam)

- John works for Microsoft, so it's fitting that they used the Imperial Theme
  from "Star Wars" to play him in

- I've been looking at the audience and making mental notes of yesterday's
  presentations -- I've decided to take a less conventional approach to this
  presentation

#1: \"The Man\"" width="375" height="500" />

- In yesterday's presentation, Dan Grigsby said "You're not really on the Fringe
  if you work for the Man."
- I was in a meeting with "The Man": Steve Ballmer, talking about how to recruit
  young programmers straight out of school who might not think of Microsoft as
  an option -- perhaps they've bought into the hype about Google
- "Are you gonna go work at Google and just so you can increase their market
  share from 65 to 66%? Come to MS where every day is a glorious day!"
- I believe that if you want to change things, the best way to do so is work in
  difficult circumstances

- Three things I want to talk about
    - Go see Steve Jobs' Stanford commencement address
    - He talks about "connecting the dots backwards" in viewing his life
    - Looking at that path, he was able to see that he was going to end up where
      he was today
    - People talk about how they accidentally wind up where they are,
      but really, it's all a result of the choices you make

- Back when I was a kid, 6502-based machines were all the rage (Apple ][,
  Commodore 64 and so on)
- (I'm old but I have the Asian mystique working for me)
- I came up with a lot of things that I didn't know already existed
    - Metaprogramming
    - 6502 assembly very limited
    - Built a 16-bit interpreter kind of thing
    - All my 16-bit instructions were prefixed with a BRK (break) instruction,
      which triggered a call to an IRQ routine which would then start the
      interpreter
- Another thing I did as a kid: building bridges between tech
    - Commodore disk drives had their own processors
    - I used to build bridges to conenct these smart peripherals to all sorts
      of things
    - Kids today, they're spoiled! You have to remember that a floppy drive
      back then had throughput similar to a 1200 baud modem. Anyone remember
      those?
- Went to University for a while
    - Did not do computers in university, I did chemistry and got a doctorate
    - I used computers, but did not program them
    - Learned lots of skills, the most of important of which are:
        - Teaching
        - Writing
    - In undergrad, when you turn in a paper, you just get a grade and
      don't care about the feedback
    - In grad school you can't do this; your supervisor won't okay it
      until s/he likes it
    - When I graduated, I realized I didn't want to "do the science thing"
      and ended up doing computers
    - Looked to see of there was a hot new thing that people weren't doing --
      in a drag race, if there are fewer competitors, I'd have a good
      chance of winning
    - I took up Delphi
    - My advice: look for something that people aren't much into and link it to
      someething hard
    - I did this by building bridges between Delphi and COM
    - By doing this work, introduced to Michael Edigan, who ended up
      being a mentor who opened my eyes to new things, including GSL jam
    - One of these things was XML, which was trendy, hip and even
      fringe at the time
    - Ended up working with Don Box (SOAP spec, amongst other things) --
      SOAP was awesomeness if you looked at the original intent
    - This was all before I got into dynamic languages, so I built code
      generators to make my life easier

    - Does anyone remember the Treedragon blog? (a couple of hands go up,
      including mine)
    - I remember its author, Rhys, ranting about dynamic languages, saying they
      sucked
    - I truly believed this

    - I recommend this book: "Advice to a Young Scientist": P.B. Medawar
    - Back when I was getting started, wanted to build stuff for people to use
    - Like many people, the way I did this was via open source
    - There's an open Source entrepreneur problem: the belief that "if you
      build it they will come"
    - Building it might actually be the easy part; getting people to come to
      your solution may be the hard part
    - You can get around that by working for a big company
    - When I interviewed at Microsoft, they didn't tell me what I was
      interviewing for
    - I met with Scott Guthrie, who created ASP.NET, after my interview -- he
      told me about the plan to release a cross-platform version of the CLR
      and its support for dynamic languages

- IronPython is the fastest implementation of Python out there
- Of course, "fastest" needs to be defined. After all, there are three kinds of
  lies, damned lies and bechmarks
- It's fastest in terms of throughput, but its startup is slow
- It was harder to build IronPython than it should have been
- It took a smart guy (Jim Huginin) and a smart team to make lots of
  little decisions well
- Could we get a win the second time and extract a DLR -- dynamic language
  runtime -- from IronPython?
- To prove it would work, we would use the DLR to build other dynamic languages
- That was the ideal, then there's the reality
- Back in May, we demoed Rails running under IronRuby -- really slowly and
  consuming a lot of memory
- We're now working on performance
- Startup time turns out to be more important than you think it is
- Unit tests are the worst kind of code you want to run through a compiler
  -- many are run only once
- Realized that we had to go off and build an interpreter
- We were working backwards from a compiler
- In getting from the language front end to IL, you have to build two trees --
  a language-specific tree and a corresponding, more general DLR tree
- There's cost in building those 2 trees, and the DLR tree is 10x as costly
  as the language-sepcific tree
- The ideal: we could put effort into building the DLR
- We have a working interpreter, just not that fast
- Have to adjust goals

- The world of Ruby development is "a sea of Macs", which sometimes makes people
  wonder who the intended audience of IronRuby is
- Ask yourself: What parts of my app should I write in Ruby?
  What shouldn't I write in Ruby?
- You're on .NET because of the library
- If Rails were "done" -- for some level of "done" -- should portions of it be
  written in a statically-typed language?
- Why should you care what languages the libraries are written in?

- (See slide above -- a photo of balaclava'd protester kids rushing a police
  barricade)
    - Don't be one of these kids: it's all gesture, no result
    - If you really want to make change, you should "enter the belly of
      the beast"
    - Find an ally in the beast -- mine was Jim Huginin -- and make the
      change you want to see from within