Notes from Rich Hickey's talk on "Effective Programs"

notes.txt

effective programs - rich hickey

"if 100 people use this, it will be outrageous"
a look back at motivations behind clojure
takes time to understand what and why and what you were thinking
hot take : there was NO grand plan for clojure - it involved the community
clojure is opinionated "wow, this is forcing me, at every turn, to do something a certain way"
only a few strongly supported idioms, with a lot of support for them...
design is all about making choices
in clojure there was  a big choice about what to leave out
"there's a big part about choice - that comes with experience"
before clojure, Rich had been programming for 18 years
"I had it. I was tired of it."
15+ years of experience...
C++ for 8 years, then Common Lisp
Scheduling systems and software for "yield management"
"I was a C++ person and I really 'loved' C++ for some value of 'love' that involves no satisfaction at all"
"situated programs"
  - sit in the world and are entangled with the world
  - execute for an extended period of time
  - deal with "information"
  - time-extensive 'memory'
  - deal with real-world irregularity
  - interact with other systems
  - interact with people
  - remain in use for long periods of time
  - are situated in a world that is changing
  - use other people's code
cares about these programs being "effective"
  - producing the intended or expected results 
programming is all about making computers effective in the world
humans leverage experience to enable good decisions and successful activities
we turn experience into "predictive power"
experience == information == facts about things that actually happened
programming is not about
  - itself (that's mathematics)
  - algorithms / computation
"mathematics may be defined as the subject in which we never know what we are talking about, nor whether what we are saying is true..."
  - Bertrand Russel
in a world of situated programs, logic is actually a small part of the program
programs are actually dominated by information processing
"the value proposition of algorithms is in delivery, how it gets to the user"
"it doesn't matter if google has the best algorithm if users can't easily load the page and search"
"what happens if you make up your own protocol (as a language author) ? -- JSON"
"you'll end up with different languages if your target work is "
  - compilers, theorem provers,
  - device drivers
  - phone switches
  - information-driven situated programs
  - "what are YOU doing ?"
clojure - "make a lisp I can use instead of C#/Java"
"maybe clojure is just a language for cranky, tired, old programmers"
  - "and you know, I wouldn't be embarrassed if it was"
clojure - "there's a big, large standard library - you just need to learn the idioms"
"(information) this is the thing that bothers me about statically typed programs"
  - information is sparse
  - often things are unknown
  - information keeps accumulating
  - information should be composable 
    (how do I compose information such that multiple parts of your system know about different part of a piece of info)
  - classes and algebratic data types are terrible for this
  - programming languages would benefit from a "compositional algebra" for information
"I'm really unhappy with ... abstraction ... as a way of providing a name for something"
abstracting should be a way of drawing from a set of exemplars some essential thing
"relational abstraction - that's an abstraction"
"datalog, that's an abstraction"
"your classes, no... those are concretions"
"positional semantics, parameterization DO NOT SCALE"
"flowing type information and structure are a major source of coupling / brittleness"
experts in java switch from parameterization to ... SPRING
  - this isn't a joke
  - this is real - parameters are brittle, it won't SCALE
"I think that types are an anti-pattern for program maintenance and extensibility"
  - "the cost they introduce is coupling and it makes them harder to maintain and understand in the first place"
"the more elaborate the type system, the more parochial the types"
  - "tyranny of the container"
  - are SSN, email, etc REALLY 'owned' by some class / type ?
  - thwarts information composition
"smalltalk and common lisp are clearly languages written by people FOR other people"
  - there's a systems sensibility in these languages that's undeniable
  - "this is a tradition that I think has largely been lost in academia"
  - "there's still SO MUCH to pilfer from these environments"
  - "any sufficiently large c/c++ program has a poorly implemented lisp"
  - "it's true - just look at Spring"
"epochal time model"
  - an answer for concurrency that involves pure functions and immutable data structures
edn data model
  - this is the heart of clojure
  - this is how we send and receive values over the while
Simon Peyton-Jones
  - types guarantee an absence of certain kinds of errors
  - is a partial machine-checked specification
  - are a design languages
  - "help support software maintenance"
but..
  - biggest errors still not caught - you need testing
  - names dominate semantics (e.g.: reverse: [a] -> [a] versus foobar: [a] -> [a])
  - maintenance: you still need to overcome the coupling they create 
  - performance optimization is MUCH helped by static typing
"when you're young, you have a lot of free space"
  - and you can fill it with whatever you like
  - these type systems, they're quite fun
  - from an endorphin point of view, solving puzzles gives you a rush
where are we going in programming ?
  - we can't explain how to drive a car
  - we can't explain HOW to play Go
  - ergo we can't explain to a computer how to do this
  - movement toward information trained brain (deep learning, etc)
  - real-world safety will need to come from experience, NOT proof
I think it's quite critical to be working in a programming language that is ITSELF programmable
  - that is amenable to manipulation by other programs
  - it will be fun to use clojure for brain building
programmable programs (clojure is suited to this)
  - generic way to represent information 
  - generic way to compose arguments without adopting / understanding an elaborate type systems
  - "it's hard enough to drive a car, if you have to understand monads too, it's just not going to work"
  - a reified system is subject to dynamic discovery, and I think spec (combined with clojure) is a great way to make systems that other systems can learn about
so, I encourage you to embrace that Clojure is different
  - solve problems, not puzzles
  - we all get infactuated by programming languages, but I think they are a small part of programming

  



takeaways
---------
clojure is great at writing long-running situated programs driven by information
clojure has interesting "compositional information" benefits