Scripting vs Programming Spencer Christensen Sr. SRE Adobe Analytics, Adobe 

Programmer Web Developer System Administrator Software Engineer Application Designer Tools Engineer DevOps Engineer Site Reliability Engineer Quality Assurance Engineer Steve Who are you? 

What do we mean by scripting? What do we mean by programming? Wha’chu talkin’ ‘bout Willis? Terminology 

“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 

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 

General Purpose Scripting Languages ● Perl ● Python ● Tcl ● Ruby ● JavaScript ● Lua ● Erlang ● PHP ● Lisp, Scheme ● Shell (bash, ksh, csh, etc.) 

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 

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. 

Or is it? 

Brains and Lenses 

Once upon a time... 

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 

Perl programmer ● ● ● 

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. 

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. 

Learning a language warps your brain. 

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 

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 

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 

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 

Scripting Quick and dirty. Not maintainable. Not scalable. Not readable. Ok for some things, but not for “real” programming. Not testable. Breaks- not reliable. 

Programming Style standards. Version controlled And peer reviewed. Readable code. Tests. Scalable. Enterprise ready. Robust- handles errors well Maintainable. 

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! 

What do you value in a programming language? 

What do you value in a programming language? ● Ease ● Expectations ● Laziness ● Assumptions ● Hard things made easy 

Language continuum C Shell 

Language continuum C Shell Manipulate complexity well Whip things up quickly 

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 

Language continuum C Shell 

Language continuum Manipulexity Whipuptitude C Shell 

Language continuum Manipulexity Whipuptitude C Shell Language X 

Language continuum Manipulexity Whipuptitude C Shell Language X 

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 

Version Control ● Have a standard policy and practice for tracking changes. ● Have appropriate access control. ● Minimize exceptions. 

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. 

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. 

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. 

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? 

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! 

Simple Complex Braid or twist 

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. 

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 

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 

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) 

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 

● 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? 

Thank You