Skip to content

experience: scripting vs programming - 1 #17

@AmitKumarDas

Description

@AmitKumarDas
  • Given: Most of your day job is around file handling, packaging, etc.
  • Given: Alternatively, you work in build & release operations
  • Then: Scripting seems to be a natural choice with its terse logic, &
    • the plethora of CLIs available to further reduce the lines of logic
  • Fact: File operations & unix philosophy goes hand-in-hand
  • However: Addition of business requirements makes scripting a bad choice
  • E.g.: I want to dry run the logic in production systems
  • E.g.: I run the logic in mission critical environments
    • Like hospitals, meteorology, transport, telecom, industrial automation, etc.
    • Or even your startup where you do not want to lose a customer for a syntactical error
  • E.g.: I want to run the logic in different OSes & architectures
  • E.g.: I want to bank on multiple release versions due to complex maintenance windows
  • E.g.: I want to run your tests in my systems (i.e. enduser platforms, etc.)
  • Then: We must switch to programming languages that are designed to be safe
  • E.g.: Above translates to following technical requirements:
    • Compile time checks,
    • Idempotent operations,
    • Supply chain security,
    • Build reproducibility,
    • Forward & backward compatibility,
    • Testing, etc.
  • And: Above translates into several non technical requirements like:
    • Investing in teams, plans / sprints, designs, etc.
  • Summary: Ensure correct logic instead of writing logic in few lines of code
  • Summary: Simple logic (or less lines of code) is relative
  • Summary: Instead focus on production grade logic

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions