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.

Spencer Christensen

July 13, 2017
Tweet

More Decks by Spencer Christensen

Other Decks in Programming

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

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

    View Slide

  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

    View Slide

  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.

    View Slide

  9. Or is it?

    View Slide

  10. Brains and
    Lenses

    View Slide

  11. Once upon a time...

    View Slide

  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

    View Slide

  13. Perl programmer



    View Slide

  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.

    View Slide

  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.

    View Slide

  16. Learning a language
    warps your brain.

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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.

    View Slide

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

    View Slide

  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!

    View Slide

  24. What do you
    value in a
    programming
    language?

    View Slide

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

    View Slide

  26. Language continuum
    C Shell

    View Slide

  27. Language continuum
    C Shell
    Manipulate
    complexity well
    Whip things up
    quickly

    View Slide

  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

    View Slide

  29. Language continuum
    C
    Shell

    View Slide

  30. Language continuum
    Manipulexity
    Whipuptitude
    C
    Shell

    View Slide

  31. Language continuum
    Manipulexity
    Whipuptitude
    C
    Shell
    Language
    X

    View Slide

  32. Language continuum
    Manipulexity
    Whipuptitude
    C
    Shell
    Language
    X

    View Slide

  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

    View Slide

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

    View Slide

  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.

    View Slide

  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.

    View Slide

  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.

    View Slide

  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?

    View Slide

  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!

    View Slide

  40. Simple
    Complex
    Braid or twist

    View Slide

  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.

    View Slide

  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

    View Slide

  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

    View Slide

  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)

    View Slide

  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

    View Slide

  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?

    View Slide

  47. Thank You

    View Slide