Beauty and programming

Beauty is a recurring theme when talking about programming and system design in general

And a lot of our references for how things should be designed talk about beauty. Why is that?

Transcript

1. Beauty  and  programming   Björn Andersson @gaqzi   Saturday  15  June  13  
2. What  is  beauty?   Beauty is a characteristic of a person, animal, place, object, or idea that provides a perceptual experience of pleasure or satisfaction. Saturday  15  June  13   @gaqzi  
3. "Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defense against complexity." -- David Gelernter, Machine Beauty: Elegance and the Heart of Technology Saturday  15  June  13   @gaqzi  
4. The UNIX Philosophy Rule of modularity – build small simple programs that work together Rule of clarity – build with other people in mind, not computers Rule of Least Surprise – programs should behave the way expected by an experienced user Rule of Generation – programmers should avoid writing low-level code, write in high-level languages that generates code. This to avoid human error. Saturday  15  June  13   @gaqzi  
5. The UNIX Philosophy Rule of modularity – build small simple programs that work together Rule of clarity – build with other people in mind, not computers Rule of Least Surprise – programs should behave the way expected by an experienced user Rule of Generation – programmers should avoid writing low-level code, write in high-level languages that generates code. This to avoid human error. Saturday  15  June  13   @gaqzi  
6. The UNIX Philosophy Rule of modularity – build small simple programs that work together Rule of clarity – build with other people in mind, not computers Rule of Least Surprise – programs should behave the way expected by an experienced user Rule of Generation – programmers should avoid writing low-level code, write in high-level languages that generates code. This to avoid human error. Saturday  15  June  13   @gaqzi  
7. The UNIX Philosophy Rule of modularity – build small simple programs that work together Rule of clarity – build with other people in mind, not computers Rule of Least Surprise – programs should behave the way expected by an experienced user Rule of Generation – programmers should avoid writing low-level code, write in high-level languages that generates code. This to avoid human error. Saturday  15  June  13   @gaqzi  
8. The UNIX Philosophy Rule of modularity – build small simple programs that work together Rule of clarity – build with other people in mind, not computers Rule of Least Surprise – programs should behave the way expected by an experienced user Rule of Generation – programmers should avoid writing low-level code, write in high-level languages that generates code. This to avoid human error. Saturday  15  June  13   @gaqzi  
9. Saturday  15  June  13     The Zen of Python, by Tim Peters   Beautiful is better than ugly.   Explicit is better than implicit.   Simple is better than complex.   Complex is better than complicated.   Flat is better than nested.   Sparse is better than dense.   Readability counts.   Special cases aren't special enough to break the rules.   Although practicality beats purity.   Errors should never pass silently.   Unless explicitly silenced.   In the face of ambiguity, refuse the temptation to guess.   There should be one-- and preferably only one --obvious way to do it.   Although that way may not be obvious at first unless you're Dutch.   Now is better than never.   Although never is often better than *right* now.   If the implementation is hard to explain, it's a bad idea.   If the implementation is easy to explain, it may be a good idea.   Namespaces are one honking great idea -- let's do more of those! @gaqzi  
10. Saturday  15  June  13     The Zen of Python, by Tim Peters   Beautiful is better than ugly.   Explicit is better than implicit.   Simple is better than complex.   Complex is better than complicated.   Flat is better than nested.   Sparse is better than dense.   Readability counts.   Special cases aren't special enough to break the rules.   Although practicality beats purity.   Errors should never pass silently.   Unless explicitly silenced.   In the face of ambiguity, refuse the temptation to guess.   There should be one-- and preferably only one --obvious way to do it.   Although that way may not be obvious at first unless you're Dutch.   Now is better than never.   Although never is often better than *right* now.   If the implementation is hard to explain, it's a bad idea.   If the implementation is easy to explain, it may be a good idea.   Namespaces are one honking great idea -- let's do more of those! @gaqzi  
11. Saturday  15  June  13     The Zen of Python, by Tim Peters   Beautiful is better than ugly.   Explicit is better than implicit.   Simple is better than complex.   Complex is better than complicated.   Flat is better than nested.   Sparse is better than dense.   Readability counts.   Special cases aren't special enough to break the rules.   Although practicality beats purity.   Errors should never pass silently.   Unless explicitly silenced.   In the face of ambiguity, refuse the temptation to guess.   There should be one-- and preferably only one --obvious way to do it.   Although that way may not be obvious at first unless you're Dutch.   Now is better than never.   Although never is often better than *right* now.   If the implementation is hard to explain, it's a bad idea.   If the implementation is easy to explain, it may be a good idea.   Namespaces are one honking great idea -- let's do more of those! @gaqzi  
12. Saturday  15  June  13     The Zen of Python, by Tim Peters   Beautiful is better than ugly.   Explicit is better than implicit.   Simple is better than complex.   Complex is better than complicated.   Flat is better than nested.   Sparse is better than dense.   Readability counts.   Special cases aren't special enough to break the rules.   Although practicality beats purity.   Errors should never pass silently.   Unless explicitly silenced.   In the face of ambiguity, refuse the temptation to guess.   There should be one-- and preferably only one --obvious way to do it.   Although that way may not be obvious at first unless you're Dutch.   Now is better than never.   Although never is often better than *right* now.   If the implementation is hard to explain, it's a bad idea.   If the implementation is easy to explain, it may be a good idea.   Namespaces are one honking great idea -- let's do more of those! @gaqzi  
13. Saturday  15  June  13     The Zen of Python, by Tim Peters   Beautiful is better than ugly.   Explicit is better than implicit.   Simple is better than complex.   Complex is better than complicated.   Flat is better than nested.   Sparse is better than dense.   Readability counts.   Special cases aren't special enough to break the rules.   Although practicality beats purity.   Errors should never pass silently.   Unless explicitly silenced.   In the face of ambiguity, refuse the temptation to guess.   There should be one-- and preferably only one --obvious way to do it.   Although that way may not be obvious at first unless you're Dutch.   Now is better than never.   Although never is often better than *right* now.   If the implementation is hard to explain, it's a bad idea.   If the implementation is easy to explain, it may be a good idea.   Namespaces are one honking great idea -- let's do more of those! @gaqzi  
14. Saturday  15  June  13     The Zen of Python, by Tim Peters   Beautiful is better than ugly.   Explicit is better than implicit.   Simple is better than complex.   Complex is better than complicated.   Flat is better than nested.   Sparse is better than dense.   Readability counts.   Special cases aren't special enough to break the rules.   Although practicality beats purity.   Errors should never pass silently.   Unless explicitly silenced.   In the face of ambiguity, refuse the temptation to guess.   There should be one-- and preferably only one --obvious way to do it.   Although that way may not be obvious at first unless you're Dutch.   Now is better than never.   Although never is often better than *right* now.   If the implementation is hard to explain, it's a bad idea.   If the implementation is easy to explain, it may be a good idea.   Namespaces are one honking great idea -- let's do more of those! @gaqzi  
15. Python  programmers  eschews  complexity     We spend our days finding the most beautiful way of expressing our ideas in code   And this is what allows us to perform amazing things Saturday  15  June  13   @gaqzi  
16. Machine learning Saturday  15  June  13   Natural Language Processing Robotics @gaqzi  
17. Do  androids  dream  of  electric  sheep?   but… Saturday  15  June  13   @gaqzi  
18. Do  hackers  dream  of  beau=ful  code?   I think so. Saturday  15  June  13   @gaqzi  
19. THANK  YOU   Saturday  15  June  13   @gaqzi  
20. REFERENCES   Beauty: https://en.wikipedia.org/wiki/Beauty The UNIX Philosophy: http://en.wikipedia.org/wiki/Unix_philosophy The Zen of Python: http://www.python.org/dev/peps/pep-0020/ Saturday  15  June  13   @gaqzi