Funny how the top of the article starts with "custom functions without code" and then immediately shows code.
I get that calling code by its name can make it sound scary, but this whole notion of it being 'easy because it is not code' seems to be a big fat lie for comfort. Same goes for the magic no-code systems where code is replaced with 'expressions' or graphical 'workflows' which essentially is exactly the same thing, only shaped slightly differently.
This makes me wonder if it wouldn't be much better if we could focus on making people be able to code and have more 'coding capacity' instead of having less of that capacity and then reducing it even more by using some of it to create 'let us pretend this is not code'-applications.
There is one discipline which truly allows defining functions without code: Programming By Example[1]. It is particularly useful in data wrangling, at the 'Transform' part of ETL.
Microsoft has some initiatives exploring it[2] (including the limited autocomplete in Excel as a toy version of the concept), but this is not it.
While formulas are definitely code in a general sense, 'code' the Excel-verse generally refers to VBA code embedded in the workbook.
VBA's potential as an attack vector results in it being unavailable or heavily restricted in many corporate environments through stuff like Group Policies[1]. And I've worked with some clients whose IT goes a step further and completely blocks sending or receiving emails with .xlsm[2] attachments.
Since lambda-defined logic is all formula-based, it's not considered 'code' in that sense and can be used and passed around as a standard Excel file without any of the VBA-oriented restrictions. So you can approach your Excel workbook more like a programming project, centrally defining your complex logic once and referencing it elsewhere every time you want to use it. This is super helpful for audibility and maintenance, while staying within the bounds of what'll be applicable/usable across any Excel environment.
If you agree to the statement that any accountant which uses Excel formulas to do bookkeeping is also a software developer, then yes, you and OP are correct.
> If you agree to the statement that any accountant which uses Excel formulas to do bookkeeping is also a software developer
They are as much a software developer as they are a writer because they write e-mails; a presenter because they present the annual accounts to the CFO; and a cleaner because they put away their mugs at the end of the day (usually.. hopefully..)
You don’t have to be someone because you sometimes do something that other person also does.
I get that calling code by its name can make it sound scary, but this whole notion of it being 'easy because it is not code' seems to be a big fat lie for comfort. Same goes for the magic no-code systems where code is replaced with 'expressions' or graphical 'workflows' which essentially is exactly the same thing, only shaped slightly differently.
This makes me wonder if it wouldn't be much better if we could focus on making people be able to code and have more 'coding capacity' instead of having less of that capacity and then reducing it even more by using some of it to create 'let us pretend this is not code'-applications.