Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Strange Loop 2009 Keynote: Minimalism in Computing

A keynote to the Strange Loop conference in St Louis, October 2009. The topic was the influence of Minimalism in art on computing and programming.

  • Inicia sesión para ver los comentarios

Strange Loop 2009 Keynote: Minimalism in Computing

  1. A presentation to the Strange Loop conference re: minimalism in software and computing. Alex Payne St Louis – October, 2009
  2. “understanding simplicity is complicated”
  3. M versus m
  4. Minimalism in context.
  5. “a style distinguished by severity of means, clarity of form, and simplicity of structure and texture”
  6. “the reduction of art to its rudiments”
  7. “What is minimal about Minimal Art is the means, not the end.”
  8. Where do we learn how to do what we do?
  9. Architecture.
  10. “Architecture is a way to understand complex systems. Architecture is a way to design complex systems. Architecture is a way to manage complex systems.”
  11. Assertion: Complexity is making + our software slow + our programs insecure + our jobs harder + our users unhappy
  12. “As computers have increased in complexity, my enjoyment of them has plummeted.”
  13. “Ingenious ideas are simple. Ingenious software is simple. Simplicity is the heart of the Unix philosophy. The more code lines you have removed, the more progress you have made. As the number of lines of code in your software shrinks, the more skilled you have become and the less your software sucks.”
  14. “By avoiding complexity when possible, and containing it when it is unavoidable, we can maximize the probability that the number of security vulnerabilities found remains zero in the future.”
  15. “The only hope is to abandon complex software. Embrace simple.”
  16. Strategies for Minimalist software: + unification + constraint + reduction
  17. Unification of: + object and materials + details and context + code and data
  18. unification of code and data ↓ homoiconicity
  19. unification via homoiconicity 1: #:"Runs a program." myeval:[lambda '[prgm:1 env:env] '[if [isName? prgm] then:/env/prgm else:[apply /prgm/0 prgm env] ] ]
  20. unification via homoiconicity 2: define f == 7 b ! . (* a function *) fb@. (* execute the function (7) *) define a == [15 b !] . (* a quotation *) ai (* execute the quotation *) b@. (* 15 *) 37 a rest cons (* modify the quotation: [37 b !] *) i (* execute the modified quotation *) b@. (* 37 *)
  21. unification via interoperability 1: var myObject = eval('(' + myJSONtext + ')');
  22. unification via interoperability 2: REST and HTTP
  23. Reduction of: + lines of code + linguistic verbosity + abstractions + hierarchy
  24. reduction of code: + leverage encapsulation + remove redundancies + stick to contracts + prefer code to comments + manage dependencies carefully
  25. reduction of syntax: |y| true & false not & (nil isNil) ifFalse: [self halt]. y := self size + super size. #($a #a 'a' 1 1.0) do: [:each | Transcript show: (each class name); show: (each printString); show: ' ']. ^x<y
  26. reduction of abstractions: “I think the major good idea in Unix was its clean and simple interface: open, close, read, and write.”
  27. reduction of hierarchy: “In an extensible system, the key issue is to identify those primitives that offer the most flexibility for extensions, while avoiding a proliferation of primitives.”
  28. Constraint via: + project scope + hardware limitations + operational requirements
  29. Antithesis.
  30. The danger of abstraction: Is Minimalism still valuable if it only exists on the surface?
  31. The risk of irrelevance: Would Minimalism be useful if complexity worked better?
  32. The necessity of complexity: Is it possible to deliver Minimalist software that meets all needs?
  33. Future.
  34. Mobile.
  35. Ubiquitous computing.
  36. A final thought.
  37. Thank you.