Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Scripting vs Programming presentation

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.

5f5812aa81bff9a3e1e7a081e76c284c?s=128

Spencer Christensen

July 13, 2017
Tweet

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