When we first introduced FormulaMap, we wanted the name to communicate its action—in this case, “map” meaning that the formula is being applied across a collection of objects. But without programming familiarity, that terminology might be meaningless.
In our effort to ensure that anyone can build with ease in Coda, we’re launching a formula alias for that same function. Now, you can choose ForEach or FormulaMap to apply an action to a list. For example, multiplying each number in a list by 10.
The new alias aligns more closely with the way our makers naturally describe the action, making it more intuitive to code in Coda. You can find ForEach in the formula library today. We can’t wait to see what you build with it.
ok - this IS a better name by far… well done indeed!
as you say, 99% of coda makers will instantly understand what it does and THAT is what matters.
but we will have many developers objecting on several grounds to this name…
FormulaMap() is more accurate as it is the equivelent to the map() functions in most programming languages (it is a pure functional function with no side-effects, returning an array etc)
For Each in other programming languages is a statement with no return value and DOES have side-effects - unlike ForEach() in Coda which is totally different
(in fact I see these objections appearing on several forums already)
well SO WHAT? the coda formula language is NOT a programming language and does NOT need to be compatible with any of them.
if ForEach() is UNDERSTOOD better by the majority of (non-programming) Coda Makers - then THAT is what matters the most.
in my experience, the FormulaMap() formula has been seen as INTIMIDATING by most new Coda Makers until they try it out and get their brains around it.
calling it by a more user-friendly and more understandable name will help enormously with removing that intimidation.
so…
what other formula names are “intimidating” and obtuse and would be nice to rename - and to what?
my own first candidate is to provide an alias for Filter() → Where()
CustomerOrders.OrderValue.Where(Country='USA' and OrderType='Online').Sum()
my clients did not get ‘filter’ in this context - but find ‘where(condition)’ more understandable
Thanks for making small, but super valuable changes to make things easier. Not a dev, but seem to recall that ForEach () is also more similar to JavaScript function, which is nice.
Small correction; any language that instructs a machine to do something is a programming language, a program is just a routinised series of instructions. Examples of programs that do not instruct machines, are a TV program, news programming, a morning program, or a biological program.
A subset of formulas do not interact with machines (such as chemical formulas), however some do, including digital spreadsheet formulas, which include coda formulas.
This doesn’t mean that those who have written computer programs without recognising it, need to identify as programmers; however, certainly, they could.
Despite this correction, you are correct that there is no law dictating language conventions, and that evolving languages in accordance to the preferences of its speakers is reasonable.
I have to admit, I only really understood what FormulaMap did (and how useful it is!) when I saw someone else use it. It’s an absolute essential for me now and I think the renaming will help a lot more people learn about it.
