Scripting vs Programming presentation

Presentation given at OpenWest 2017 conference, entitled Scripting vs Programming. Discusses the terms and biases we have when thinking about scripting versus programming.

Transcript

1. Scripting vs Programming Spencer Christensen Sr. SRE Adobe Analytics, Adobe
2. Programmer Web Developer System Administrator Software Engineer Application Designer Tools Engineer DevOps Engineer Site Reliability Engineer Quality Assurance Engineer Steve Who are you?
3. What do we mean by scripting? What do we mean by programming? Wha’chu talkin’ ‘bout Willis? Terminology
4. “Suppose you went back to Ada Lovelace and asked her the difference between a script and a program. She'd probably look at you funny, then say something like: Well, a script is what you give the actors, but a program is what you give the audience. That Ada was one sharp lady…” - Larry Wall Terminology Ada Lovelace 1815 - 1852
5. What is “scripting”? • Writing programs in a scripting language • Scripting languages are typically: ▪ Very high-level languages ▪ Used to automate system calls that alternatively be run manually “glue language” ▪ Interpreted (instead of compiled) • Scripting languages can be: ▪ Used as an extension language (plugins, macros, etc.) • Domain-specific language ▪ General purpose
6. General Purpose Scripting Languages • Perl • Python • Tcl • Ruby • JavaScript • Lua • Erlang • PHP • Lisp, Scheme • Shell (bash, ksh, csh, etc.)
7. What is “programming”? • Using a formal language to specify a set of instructions or algorithms for computers to perform • Programming language elements: ▪ Syntax • Grammatical structure • Defined by specification or by dominant implementation as reference ▪ Semantics • Declaring things before using them • Function calls with correct number and type of arguments • Variables used in correct context ▪ Typing System • Typed vs untyped languages • Static vs dynamic typing
8. Programming is hard Computers are hard to understand. You need to be REALLY smart to program Computers! • Programming requires creativity and craftsmanship. • Programming takes a lot of effort to know what you’re doing. You deal with a lot of complexity. • Not everyone can do it. It takes a certain kind of person to be a programmer. • Programming is building cool applications that do complex things.
9. Or is it?
10. Brains and Lenses
11. Once upon a time...
12. Bias in your value system What do you value? Processes, tools, design patterns, editors, languages, etc. value is weighted by: 1. What you learned first 2. What you are most comfortable using How do you value them? You establish a set of values, or criteria, by which other things are compared. Judgment calls: • Easy to learn • Easy to use • Time saving • Powerful features • Better
13. Perl programmer • • •
14. Your view of “normal” • Resource usage and performance ▪ “Oh, it will be faster in production.” • Relying on complex tools, frameworks, middleware, variety of dependencies to do “normal” programming. ▪ Normal Bloat • Software Development Life Cycle ▪ Process, procedures, timelines, deliverables Your bias is a lens you look through.
15. Your view of “normal” • Acknowledge your bias. • Try to see the complexity and bloat in your view of normal. • Try to understand that “normal” may be very different for someone else.
16. Learning a language warps your brain.
17. 2012 Study in Sweden on language learning: “MRI scans showed specific parts of the brains of the language students developed in size whereas the brain structures of the control group remained unchanged.” https://www.theguardian.com/education/2014/sep/04/what-happens-to-the-brain-lan guage-learning
18. Learning a programming language affects your mindset. You establish your understanding of • Programming concepts • Expectations - systems, yourself, interactions • Limits and constraints • Inputs, outputs • Resource usage • Dealing with complexity
19. Learning a second and third programming language increases your understanding of: • Programming concepts • Expectations - systems, yourself, interactions • Limits and constraints • Inputs, outputs • Resource usage • Dealing with complexity
20. Learning a second and third programming language increases your understanding of: • Programming concepts • Expectations - systems, yourself, interactions • Limits and constraints • Inputs, outputs • Resource usage • Dealing with complexity
21. Scripting Quick and dirty. Not maintainable. Not scalable. Not readable. Ok for some things, but not for “real” programming. Not testable. Breaks- not reliable.
22. Programming Style standards. Version controlled And peer reviewed. Readable code. Tests. Scalable. Enterprise ready. Robust- handles errors well Maintainable.
23. Values and comparisons In scripting language A: You can't even think about doing X! There's only one way to do X! There's more than one way to do X! There are too many ways to do X! In programming language B: You can't even think about doing Y! There's only one way to do Y! There's more than one way to do Y! There are too many ways to do Y!
24. What do you value in a programming language?
25. What do you value in a programming language? • Ease • Expectations • Laziness • Assumptions • Hard things made easy
26. Language continuum C Shell
27. Language continuum C Shell Manipulate complexity well Whip things up quickly
28. Language continuum “If you were a Unix programmer you either programmed in C or shell. And there really wasn't much in between. There were these little languages that we used on top of shell, but that was the big divide. The big revelation that hatched Perl, as it were, was that this opened up into a two-dimensional space. And C was good at something I like to call manipulexity, that is the manipulation of complex things. While shell was good at something else which I call whipuptitude, the aptitude for whipping things up.” - Larry Wall http://www.shlomifish.org/humour/fortunes/show.cgi?id=larry-wall-big-divide
29. Language continuum C Shell
30. Language continuum Manipulexity Whipuptitude C Shell
31. Language continuum Manipulexity Whipuptitude C Shell Language X
32. Language continuum Manipulexity Whipuptitude C Shell Language X
33. Best of Both Worlds Version Control Scripting can and should be approached like any other programming work. Programming can and should be simple and flexible like scripting. Testable Code Reusable Code Readable Code Commented Code Simplicity Maintainable Code RAD
34. Version Control • Have a standard policy and practice for tracking changes. • Have appropriate access control. • Minimize exceptions.
35. Readable Code • Use meaningful names. • Use helpful comments (addresses “why?”, hard-coded values). • Use standard indentation and coding styles. • Use whitespace to separate logic “paragraphs”. • Avoid “clever” code. • Avoid line noise.
36. Maintainable Code • There is value in coding a language in the conventions of that language. • Use standard best practices. • Use modular/reusable code. • Do refactor code to reduce complexity. • Ease the cost of maintenance.
37. Testable Code • Have testing in mind- How can I test this? • Have a “dry-run” mode. • Use standard testing tools/frameworks for your language. • Share tests- documented, scripted, etc.
38. Reusable Code • Take advantage of libraries, modules, etc. if available. • If not available, create your own repo of reusable libraries. • Don’t re-invent things! • Try to increase DRY- How could I reuse this code?
39. Chose Simplicity • Simple or complex code can be written in any language. • Hiding complexity isn’t the same as simplicity. • Avoid adding complexity- enough inherent complexity already!
40. Simple Complex Braid or twist
41. Programming is hard Computers are hard to understand. • Computers are exacting- following Instructions exactly. • There are many systems, interactions, and dependencies for your software to work. • As software systems scale up, complexity also increases. • Most software systems are too large for one person to understand all of it.
42. Simplicity • Easier to understand • Easier to maintain and update • Easier to debug • Easier to separate concerns, features, dependencies • Easier for new person to learn and come up to speed
43. Complexity • Harder to understand • Harder to maintain and update • Harder to debug • Harder to separate concerns, features, dependencies • Harder for new person to learn and come up to speed
44. Good programmers vs Bad programmers “The difference between a bad programmer and a good programmer is understanding. That is, bad programmers don’t understand what they are doing and good programmers do.” - Max Kanat-Alexander, Code Simplicity, (2012)
45. Best of Both Worlds Version Control Scripting can and should be approached like any other programming work. Programming can and should be simple and flexible like scripting. Testable Code Reusable Code Readable Code Chose Simplicity Maintainable Code
46. • Acknowledge our language biases. • Scripting can and should be approached like any other programming work. • Programming can and should be simple and flexible like scripting. • We want better coders with better understanding to write better software. So what?
47. Thank You