As both a Grasshopper user and teacher, I am concerned about how GH2’s terminology will affect existing users, new students, and how Grasshopper is perceived as a computational-design tool. GH2 can open GH1 definitions, which is excellent, but preserving more of GH1’s established language would make the transition much easier.
Terms such as Parameter, Domain, Index, Construct, Deconstruct, and Reparameterize are not language problems; they are core computational concepts. Tooltips can explain them in plain English, while component names remain compact, precise, and computationally meaningful.
What I have noticed, however, is that GH2 often replaces this established terminology with names shaped more by linguistic consistency and descriptive English than by computational-design logic. Some of the names feel as though they were chosen primarily for linguistic neatness rather than by people deeply familiar with how Grasshopper users think and work.
Below are some areas I believe need to be reconsidered.
1. Component names should behave like operators, not miniature tooltips
GH1 names such as:
Arc 3Pt
Arc SED
Circle CNR
Vector 2Pt
Cull Index
List Item
Set Difference
etc
are short, but they are not meaningless abbreviations. They communicate operations, signatures, and relationships.
Several GH2 names instead read like English instructions:
Arc 3 Points
Arc From Tangent
Circle From Normal
Vector From 2 Points
Cull By Index
Item From Index
Dissect Plane
The extra words often add no computational distinction.
Vector 2Pt already tells a Grasshopper user exactly what it does. Vector From 2 Points only uses more canvas space to explain something already visible through the inputs and tooltip.
The same principle exists in Rhino commands. A command such as OffsetSrf is compact because users run it repeatedly. Writing it as a complete English phrase may help for the first few seconds, but after the tool is understood, that extra wording becomes permanent clutter.
Grasshopper components are also scanned repeatedly across large definitions. A name should be learned once and read efficiently thousands of times. Semantic compression is a feature, not an accessibility failure.
2. Grasshopper should preserve reusable naming conventions
GH1 teaches a clear relationship:
Construct Point <-> Deconstruct Point
Construct Vector <-> Deconstruct Vector
Construct Plane <-> Deconstruct Plane
Construct Path <-> Deconstruct Path
Construct Mesh <-> Deconstruct Mesh
This is not merely wording. It communicates that structured data can be assembled and decomposed.
GH2 replaces this convention with Dissect across many types:
Dissect Arc
Dissect Rectangle
Dissect Path
Dissect Date
Dissect Complex
Dissect Mesh
Dissect Box
Dissect Interval
Dissect Plane
Dissect Point
Dissect Vector
Dissect Quaternion
Dissect is a physical or biological metaphor. It does not form a clear inverse relationship with the various From constructors. As a result, constructor components are now scattered across unrelated naming patterns, with no shared language connecting them.
It also loses the direct connection to decomposition, destructuring, fields, tuples, and structured data in programming.
New types such as Gradient or Quaternion are a reason to extend the established Construct/Deconstruct convention—not abandon it.
Deconstruct Gradient
Deconstruct Quaternion
would preserve a naming pattern users already understand.
3. Boolean predicates should look like predicates
Programming systems commonly use Is, Has, and Contains because those names predict a Boolean result:
Is Planar
Is Closed
Is Valid
is - something?
Names such as:
Curve Planarity
Surface Planarity
Curve Closedness
Mesh Closedness
name properties, but they do not clearly indicate whether the component returns a Boolean, measurement, deviation, or classification.
Once a student learns that an Is... component performs a predicate test, that knowledge transfers across the system.
If the result is Boolean, Is Planar is clearer than Curve Planarity. If the result is a measurement, a name such as Planarity Deviation would communicate that difference.
Naming should help users predict output type and behaviour.
4. Reparameterization should not be hidden
In GH1, the logic is direct: a curve has a domain, and Evaluate Curve evaluates it at parameter (t). When needed, the user can reparametrize the domain to ([0,1]).
Reparameterization is not always easy to teach, but it is an essential computational concept. Once users understand it, they understand that a curve domain can be changed to any useful interval.
GH2 places evaluation behind Locus and options such as:
Natural
Normalized
Length
These options may make the immediate operation convenient, but they hide the relationship between parameters, domains, normalized factors, and arc length.
Users may learn which option produces the desired result without understanding what is being computed.
This may feel simple to experienced users who already understand parameterization, but it can be more confusing for beginners because several different concepts are now combined into one workflow and hidden behind multiple clicks.
The old system taught a transferable concept. Reparameterization connected directly to curves, surfaces, NURBS mathematics, scripting, derivatives, and computational geometry.
I also could not find an equivalent direct surface-reparameterization option in the current version. If surface domains can no longer be explicitly reparameterized in both (u) and (v), an important computational workflow has been hidden or removed.
5. Some expanded names are longer but less informative
Consider:
Arc 3Pt -> Arc 3 Points
Vector 2Pt -> Vector From 2 Points
Arc SED -> Arc From Tangent
Circle CNR -> Circle From Normal
Expanding Pt to Points adds no computational meaning. It could be handled through search aliases without replacing the compact name.
More importantly:
-
SEDmeans Start, End, and Direction. -
CNRmeans Centre, Normal, and Radius.
Arc From Tangent mentions only one part of the constructor and hides its two point inputs.
Circle From Normal mentions only the normal and omits the centre and radius.
The new labels are longer but contain less of the component signature.
The same issue appears in names such as:
Polyline -> Polyline From Points
Loft -> Loft From Curves
A polyline is already defined by connected points. Anyone who understands the term Polyline already knows it must be created from points. Likewise, curves are the normal inputs of a loft, so From Curves add no useful distinction.
Descriptive naming is helpful when the operation is unfamiliar or when it identifies a specific variation, such as Control Point Loft. In that case, the additional words provide information the basic term Loft does not.
Full explanations belong in tooltips and documentation.
6. Standard mathematical and algorithmic terms should remain standard
Set Difference is the established set-theory term for (A \setminus B).
Changing it to Set Subtraction replaces a precise mathematical operation with arithmetic language. Subtraction can imply numbers, vectors, or other behaviours. Difference is the more transferable term.
Algorithm names also matter:
Circle Fit
Sphere Fit
Fit Line
Plane Fit
tell users that the result is fitted to a collection of samples.
Names such as:
Circle N Points
Sphere N Points
Line N Points
Plane N Points
only describe the input form. They do not tell users whether the operation interpolates, approximates, regresses, or exactly satisfies those points.
Fit is the important computational information.
There are good changes in GH2. Power becoming Exponentiation improves mathematical precision, and correcting Carthesian Product to Cartesian Product is clearly worthwhile.
The objection is not to change itself. It is to changes that reduce precision, predictability, or continuity.
7. Name the data being changed, not the selector
Replace Items -> Replace Indices
is particularly misleading.
The indices are not being replaced. They select the items that will be replaced.
Replace Items already identifies the operation correctly and does not need to become a longer English sentence.
The same principle should apply throughout the interface: name the operation and the data it affects accurately.
8. Prepositions should add meaning, not merely complete a sentence
Examples include:
Cull Index -> Cull By Index
Cull Pattern -> Cull By Pattern
Divide Distance -> Divide By Distance
Divide Length -> Divide By Length
Divide Curve -> Divide By Count
By does not add a computational distinction. It mainly makes the label sound more like ordinary English.
The old names are faster to scan and already communicate the operation.
A compact family remains clearer:
Divide Count
Divide Distance
Divide Length
Divide Ratio
Divide Span
Grasshopper component names do not need to form complete sentences.
9. Established verbs should keep their computational meaning
Move Seam uses the wrong verb.
In Grasshopper, Move already means spatial translation. Changing the seam of a closed curve does not translate geometry through space. It changes the curve’s start location or parameterization.
The old name, Seam, was already sufficient. If a verb is required, Adjust Seam or Set Seam would at least avoid suggesting a Euclidean transformation.
Similarly:
XZ Plane -> World XZ
adds the useful context World but removes Plane, the output type.
World XZ Plane would preserve both pieces of information. Names should not gain conversational clarity by dropping the data type they produce.
10. Data-tree names should preserve Grasshopper’s levels of abstraction
Stack Data -> Stack Items
Repeat Data -> Repeat List
reduce broader data-tree operations to a single level.
Grasshopper behavior depends on whether data is structured as items, lists, or branches. Grafting, flattening, and tree structure can change how an operation behaves.
Data was broad, but that breadth was useful. It did not force the user to think only in terms of items or only in terms of lists.
Grasshopper’s item–list–tree distinction is foundational. Component names should support that mental model rather than collapse it.
11. The type system should use one consistent language
Constructors, deconstructors, parameters, inputs, outputs, and categories should expose the same relationships.
For example, mixing:
Mesh From Facets
Construct Facet
Dissect Facet
Facet category
forces users to learn several linguistic patterns for one type system.
A consistent relationship is easier to understand:
Construct Face <-> Deconstruct Face
Construct Mesh <-> Deconstruct Mesh
The exact terminology can be debated, but the system should feel coherent rather than like a collection of independently named tools.
12. “Flip Matrix” communicates the operation; “Flip Tree” does not
Flip Matrix gives users a clear computational model: the data can be understood as a grid, and the component performs an operation similar to transposing that grid by exchanging rows and columns. The name explains how the structure is transformed, not merely what type of data enters the component.
Flip Tree removes that model. A tree could be “flipped” in several ways—by reversing branch order, reversing items within branches, exchanging path dimensions, or transposing a regular two-dimensional structure. The name identifies the data type but does not clearly describe the operation.
Matrix is useful here even though a Grasshopper data tree is not always a literal matrix. It provides the analogy that makes the operation understandable and connects it to transposition in mathematics, spreadsheets, arrays, and programming.
Final Thoughts
These changes may not prevent experienced users from working, but they make the transition harder for students and existing users. These are my thoughts based on what I have seen so far. Anyone who agrees, disagrees, or has additional examples is welcome to share their perspective.