scripting-referencelisted

# Scripting Reference for AEC Computational Design ## 1. Scripting in AEC Computational Design ### Why Code Beyond Visual Programming Visual programming environments like Grasshopper, Dynamo, and Marionette have democratized computational design for architects and engineers. But they hit hard walls in practice: - **Complexity ceiling**: Definitions beyond ~200 nodes become unreadable spaghetti, impossible to maintain or hand off. - **Control flow limitations**: Try writing a recursive space-partitioning algorithm in pure Grasshopper. You cannot. Loops require plugins (Anemone, Hoopsnake) that add fragility. - **Performance**: Visual node evaluation carries overhead. A Python loop processing 50,000 mesh vertices runs 5-20x faster than equivalent wired-up components. - **Data management**: Parsing CSV, calling REST APIs, reading databases, writing Excel reports — all trivial in code, painful or impossible in visual programming. - **Version control**: A `.gh` file is a binary blob. A `.py` file is diffable, mergeable, reviewable text. - **Reusability**: Functions, classes, modules, packages — code is composable at every scale. - **Testing**: You can unit-test a Python function. You cannot unit-test a Grasshopper cluster. ### The Scripting Spectrum | Level | Tool | Difficulty | Use Case | |-------|------|------------|----------| | Entry | rhinoscriptsyntax (rs) | Easy | Quick automation, batch ops, simple geometry | | Intermediate | RhinoCommon (Python) | Medium | Complex g