>Personally the distinction between subroutines and functions always struck me as overly math-centric thinking
Well, the word is taken from math, it seems pretty rude to take a word while preserving nothing of its original meaning. A function is a mapping between sets, it has nothing to do with abstraction or reusability or any of the dozen other keywords said when introducing the concept in programming courses, it's just an association between sets satisfying certain (relaxable) constraints.
From this perspective, a function that returns nothing is a hilarity, it collapses all elements of its domain to a single point. A function that takes nothing and returns nothing is a deviancy, where is the mapping then if nothing is taken and nothing is returned?
Keep in mind that the usage of 'functions' to denote callables* is a new thing that happened probably around the mid to late 1980s. Computer Science always called self-contained pieces of code '(sub) procedures' or '(sub)routines' or '(sub)programs'. Fortran, the oldest programming language, honors the difference until now. Pick any conference paper or book written before 1980 and I guarantee you that 'function' will denote a literal mathematical function used to describe some property of an algorithm or declare a certain constraint on a computational object, and that callable code blocks are always called one of the terms above or their variations.
>because it's not an interesting difference as soon as non-local state exists, which is almost always the case.
The thing is, there is no such thing as 'state' with functions in the first place. The word denotes something in a world that knows nothing about change or time, taking the word and redefining it to include those concepts is meaningless. Imagine if I took numbers, added physical units to them, then insisted that this is the mathematical definition of numbers all along. That's what happened with functions.
Also how exactly is the difference between pure subroutines and mutating subroutines irrelevant when non-local state is involved? it's the exact opposite, the difference is an irrelevant and opaque implementation detail if the mutated state is callee-local and never leaks to the caller, otherwise it's an outsized obsession of life that can mean the difference between a good weekend and a sleepless 24 hour and all things in between. It's exactly when it's non-local that mutable state is revealed as the horsemen of death it is.
* : see? even the verbs don't make sense: how exactly do you 'call' an association? it's a mapping, you either 'apply' it or 'refer' to it or 'look up' an element in a table listing (a sample of) its input-output pairings. Similarly, you don't 'return' from a function, you never 'went' anywhere to return, you had an element and used it to get another element with the help of a mapping between the 2 sets containing the 2 elements, this 'happened' instantaneously, timelessly, there is no instruction pointer in math breathing down your neck and telling you to return here and go there.
Well, the word is taken from math, it seems pretty rude to take a word while preserving nothing of its original meaning. A function is a mapping between sets, it has nothing to do with abstraction or reusability or any of the dozen other keywords said when introducing the concept in programming courses, it's just an association between sets satisfying certain (relaxable) constraints.
From this perspective, a function that returns nothing is a hilarity, it collapses all elements of its domain to a single point. A function that takes nothing and returns nothing is a deviancy, where is the mapping then if nothing is taken and nothing is returned?
Keep in mind that the usage of 'functions' to denote callables* is a new thing that happened probably around the mid to late 1980s. Computer Science always called self-contained pieces of code '(sub) procedures' or '(sub)routines' or '(sub)programs'. Fortran, the oldest programming language, honors the difference until now. Pick any conference paper or book written before 1980 and I guarantee you that 'function' will denote a literal mathematical function used to describe some property of an algorithm or declare a certain constraint on a computational object, and that callable code blocks are always called one of the terms above or their variations.
>because it's not an interesting difference as soon as non-local state exists, which is almost always the case.
The thing is, there is no such thing as 'state' with functions in the first place. The word denotes something in a world that knows nothing about change or time, taking the word and redefining it to include those concepts is meaningless. Imagine if I took numbers, added physical units to them, then insisted that this is the mathematical definition of numbers all along. That's what happened with functions.
Also how exactly is the difference between pure subroutines and mutating subroutines irrelevant when non-local state is involved? it's the exact opposite, the difference is an irrelevant and opaque implementation detail if the mutated state is callee-local and never leaks to the caller, otherwise it's an outsized obsession of life that can mean the difference between a good weekend and a sleepless 24 hour and all things in between. It's exactly when it's non-local that mutable state is revealed as the horsemen of death it is.
* : see? even the verbs don't make sense: how exactly do you 'call' an association? it's a mapping, you either 'apply' it or 'refer' to it or 'look up' an element in a table listing (a sample of) its input-output pairings. Similarly, you don't 'return' from a function, you never 'went' anywhere to return, you had an element and used it to get another element with the help of a mapping between the 2 sets containing the 2 elements, this 'happened' instantaneously, timelessly, there is no instruction pointer in math breathing down your neck and telling you to return here and go there.