Simple Made Easy

原文:https://www.infoq.com/presentations/Simple-Made-Easy/

 

simplicity’s virtues over easiness

 

 while many choose easiness they may end up with complexity, and the better way is to choose easiness along the simplicity path.

 

  • We should aim for simplicity because simplicity is a prerequisite for reliability.
  • Simple is often erroneously mistaken for easy. "Easy" means "to be at hand", "to be approachable". "Simple" is the opposite of "complex" which means "being intertwined", "being tied together". Simple != easy.
  • What matters in software is: does the software do what is supposed to do? Is it of high quality? Can we rely on it? Can problems be fixed along the way? Can requirements change over time? The answers to these questions is what matters in writing software not the look and feel of the experience writing the code or the cultural implications of it
  • The benefits of simplicity are: ease of understanding, ease of change, ease of debugging, flexibility.
  • Complex constructs: State, Object, Methods, Syntax, Inheritance, Switch/matching, Vars, Imperative loops, Actors, ORM, Conditionals.
  • Simple constructs: Values, Functions, Namespaces, Data, Polymorphism, Managed refs, Set functions, Queues, Declarative data manipulation, Rules, Consistency.
  • Build simple systems by: 
    • Abstracting - design by answering questions related to what, who, when, where, why, and how.
    • Choosing constructs that generate simple artifacts.
    • Simplify by encapsulation.

 

 

Simple vs. easy

  • 1:09 "Simplicity is a prerequisite for reliability". - Edsger W. Dijkstra
  • 1:23 We need to build simple systems if we want to build good systems.
  • 1:27 There is not enough focus on building simple systems.
  • 2:02 The roots of "simple" are "sim" and "plex", and means "one twist". The opposite, which would be complex, is "multiple twists" or "braided together".
  • 2:30 The central point of the talk is seeing software as being folded together or not.
  • 2:37 People usually interchange "simple" with "easy".
  • 2:54 The latin origin of "easy" is the root of "adjacent", which means "to lie near" and "to be nearby".
  • 3:28 Addressing multiple dimensions is important in software design.
  • 3:34 Simple things are those which have one role. They fulfill one task, they have one objective, they cover one concept.
  • 3:56 Simple things may be one dimension of a multi-dimensional problem they attempt to solve.
  • 4:02 Simple things are focused, they do not address multiple issues.
  • 4:12 Simple does not mean one of a kind. An interface does not have to have only one method to be simple. Cardinality does not matter here. What is important is not to have interleaving of issues.
  • 4:49 Simplicity is objective, it can be probed.
  • 5:16 The origin of "easy" implies "nearness". Something that is near can be easily touched or grabbed.

 

Simplicity vs. easiness in software development

  • 5:58 In software development, easy means being near to our understanding, being in our skillset, being familiar.
  • 6:20 Easy is overrated in the software industry. "Can I get this running in 5 seconds?" It does not matter if the result is a large ball of mud. All it matters is to be done quickly.
  • 7:03 All that is new is somewhat unfamiliar. Do not avoid it even if it is harder to grasp or do at first. 
  • 7:14 People usually feel uncomfortably to say about something that it is beyond their capabilities.
  • 8:17 Easy is a relative term. Something may be easy for someone and difficult for someone else.
  • 8:44 Many times, developers say about some that is simple, but they mean easy, because they mean it is something they are familiar with.
  • 9:05 The distinction between simple and easy is relevant when dealing with software constructs and artifacts.
  • 9:36 The attributes of an artifact are how it runs, what's the performance, how it can be changed over time. These attributes are not the original construct (code).
  • 10:06 People focus too much on the construct, on how easily they can write something or how easily is to replace one developer with another, considering just the familiarity of the tools used, not the simplicity or complexity of the code the new developer needs to deal with.

 

Why simplicity matters in software development

  • 11:36 We should ask ourselves these questions: does the software do what is supposed to do? Is it of high quality? Can we rely on it? Can problems be fixed along the way? Can requirements change over time? The answers to these questions is what matters in writing software not the look and feel of the experience writing the code or the cultural implications of it.
  • 12:34 "We can only hope to make reliable those things we understand". And there is usually a tradeoff. When evolving a system, making it more extensible and dynamic, it may become harder to understand and decide if it is correct.
  • 13:24 People can juggle only a few things at a time, a small number. The same with the number of things one can think of at one time. That becomes even harder when things are intertwined, because one cannot reason about them in isolation.
  • 13:45 Intertwining raises complexity combinatorially.
  • 14:35 To be able to change existing software one needs to understand it and decide how and where to apply changes. If one cannot reason about a program, he can make those decisions.
  • 15:45 Q: What happened to every bug out there? A: it passed the type checker, and it passed all tests. 
  • 16:08 Having tests should not encourage someone to change code without being careful.
  • 17:35 Only people running very short races can use their maximum speed from the beginning of the race. Some attempt to cheat life by firing the starting gun every 100 yards and call it a new sprint.
  • 13:45 Intertwining raises complexity combinatorially.
  • 14:35 To be able to change existing software one needs to understand it and decide how and where to apply changes. If one cannot reason about a program, he can make those decisions.
  • 15:45 Q: What happened to every bug out there? A: it passed the type checker, and it passed all tests. 
  • 16:08 Having tests should not encourage someone to change code without being careful.
  • 17:35 Only people running very short races can use their maximum speed from the beginning of the race. Some attempt to cheat life by firing the starting gun every 100 yards and call it a new sprint.
  • 13:45 Intertwining raises complexity combinatorially.
  • 14:35 To be able to change existing software one needs to understand it and decide how and where to apply changes. If one cannot reason about a program, he can make those decisions.
  • 15:45 Q: What happened to every bug out there? A: it passed the type checker, and it passed all tests. 
  • 16:08 Having tests should not encourage someone to change code without being careful.
  • 17:35 Only people running very short races can use their maximum speed from the beginning of the race. Some attempt to cheat life by firing the starting gun every 100 yards and call it a new sprint.
  • 24:24 Because we are limited in how many balls we can juggle in the same time, we need to decide how much incidental complexity vs. problem complexity we want.
  • 27:35 "LISP programmers know the value of everything and the cost of nothing."
  • 28:08 Programmers like to emphasize only the benefits of a new new tool or method, but they rarely mention the downsides or the tradeoffs.
  • 28:50 Complex: state, objects, methods, vars, inheritance, switch, matching, syntax, imperative loops, actors, ORM, conditionals, inconsistency. Simpler: values, functions, namespaces, managed refs, polymorphism, data, set functions, queues, declarative data manipulation, rules, consistency.
  • 31:36 "Complect" means to interleave, to entwine, to braid. Complect results in bad software.
  • 33:08 Complect means to braid together. Compose means to place together. Composing modular components is not simple if the modules are highly interconnected.
  • 34:30 Simplicity enables partitioning (horizontal separation between components) and stratification (vertical separation). 
  • 35:40 State is easy but introduces complexity because it intertwines value and time. State intertwines everything it touches directly or indirectly, and it is not mitigated by modules and encapsulation.
  • 38:00 vars or refs do not make state simpler.

 

Constructs that generate complex artifacts

  • 39:27 The following constructs are complex because they intertwine ...:
  • State - everything it touches
  • Object - state, identity, value
  • Methods - function and state, namespaces
  • Syntax - meaning, order
  • Inheritance - types
  • Switch/matching - multiple who/what pairs
  • Vars - value, time
  • Imperative loops - what/who
  • Actors - what/who
  • ORM - OMG

 

Conditionals - the rest of the program

  • 42:58 One can better write sophisticated systems with simpler tools that let one focus on the system rather the constructs of the language or tool.

 

Constructs that generate simpler artifacts

  • 43:50 The following constructs are simpler:
  • Values - use final, persistent collections
  • Functions - use stateless methods
  • Namespaces - use a language with good support for namespaces
  • Data - use maps, arrays, sets, XML, JSON, etc.
  • Polymorphism - through protocols, type classes
  • Managed refs - Clojure, Haskell
  • Set functions - via libraries
  • Queues - via libraries
  • Declarative data manipulation - via SQL, LINQ, Datalog
  • Rules - via libraries or natively in Prolog

 

Consistency - through transactions or values

  • 47:22 One needs to learn to live with environmental complexity: CPU, memory, inherent complexity related to implementation (GC, for example), etc.
  • 49:05 Programming is not about typing on a computer keyboard, it is about thinking.

 

posted @   PanPan003  阅读(86)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· DeepSeek R1 简明指南:架构、训练、本地部署及硬件要求
· 没有源码,如何修改代码逻辑?
· NetPad:一个.NET开源、跨平台的C#编辑器
· 面试官:你是如何进行SQL调优的?
点击右上角即可分享
微信分享提示