Presentation given at OpenWest 2017 conference, entitled Scripting vs Programming. Discusses the terms and biases we have when thinking about scripting versus programming.
Programmer Web Developer System Administrator Software Engineer Application Designer Tools Engineer DevOps Engineer Site Reliability Engineer Quality Assurance Engineer Steve Who are you?
“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
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.
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
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.
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.
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!
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
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
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!
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?