[HN Gopher] Methods in Languages for Systems Programming (2023)
       ___________________________________________________________________
        
       Methods in Languages for Systems Programming (2023)
        
       Author : surprisetalk
       Score  : 15 points
       Date   : 2026-03-16 16:51 UTC (6 hours ago)
        
 (HTM) web link (blog.xoria.org)
 (TXT) w3m dump (blog.xoria.org)
        
       | cv5005 wrote:
       | Not a fan of methods.
       | 
       | Why should the first argument be so special? And how do you
       | decide which struct should get method if you have a function that
       | operates on two different types?
        
       | 12_throw_away wrote:
       | IMO the best arguments for using methods have nothing to do with
       | language semantics, but are just grug-brained "this makes my life
       | easier" stuff. Methods are great because they work unreasonably
       | well with autocomplete, they're very easy to find in API docs,
       | and they let you write easily readable call chains without a 10
       | nested levels of parentheses that need to be read inside-out.
       | Plus, as the article says - it's sometimes nice to have another
       | code organization tool at your disposal.
        
       | stmw wrote:
       | Good blog post, good balance. One thing to add is that in systems
       | programming, very often the struct is not arbitrarily defined by
       | the programmer - it may be defined by the hardware or another
       | system entirely. So the Data, including its bit-by-bit layout, is
       | primal. It kind of makes sense to have procedures to operate on
       | it, rather than methods.
        
       | miguel_martin wrote:
       | 'We believe that data and code should be separate concepts; data
       | should not have "behaviour".' is flawed, but I don't believe
       | that's the point being made. Instead, I believe the point
       | actually roots in a "programmer mindset" thing when using
       | methods/member functions, due to this explicit separation of data
       | and procedures. With methods/member functions you naturally fall
       | into an "individual element" mindset, see
       | https://www.gingerbill.org/article/2026/01/02/was-it-really-... -
       | yes it's semantically equivalent (given the examples in the
       | article and many other cases), but humans are humans and they are
       | biased.
       | 
       | In my opinion: there is a better argument for making new
       | languages _not_ have methods, or more accurately member functions
       | (as what the author describes).
       | 
       | Consider the following situation: you are user of a library that
       | declares a type called SomeType which has "methods" (member
       | functions) in it. You want to add more "methods" to this type.
       | 
       | Now, there is a problem regarding consisteny w.r.t syntax, your
       | new "methods" now have to be called via `foo(&bar)` instead of
       | `bar.foo()`. You as a user of the library and language have to
       | choice to make (regarding code style):
       | 
       | 1. Accept this difference in syntax. Maybe you like this style
       | difference, because now you can clearly see what procedures are
       | declared in your codebase vs. the library's codebase, or:
       | 
       | 2. Use freeform functions everywhere. Well actually, you can't do
       | this without a refactor of the library (or with additional
       | language features), i.e. you will need to fork the library and
       | rewrite SomeType and the associated member functions in this
       | freeform function/procedure style.
       | 
       | From a language designer's perspective, you can choose to solve
       | the problem by either (a) forcing the declaration of procedures
       | to be consistent or (b) introducing language features to make the
       | calling code consistent. Odin obviously chose (a), but languages
       | like Swift and C# chose (b) - whereas languages such as Nim chose
       | both (a) & (b).
       | 
       | For (b), here's some possible features you could add:
       | 
       | * Extension methods (Swift, C#). This let's user declared
       | "methods" feel like like "proper methods" of the class/struct, or
       | 
       | * UFCS (Nim, D). Declare everything as a freeform
       | procedure/function but enable the syntax `arr.push(10)` when the
       | procedure is declared as `proc push(arr: var Array, x: int)`
       | 
       | From this, you can see why languages such as Odin chose to go
       | with option (a). It's simpler.
        
       ___________________________________________________________________
       (page generated 2026-03-16 23:01 UTC)