Funny how the top of the article starts with "custom functions without code" and then immediately shows code.<p>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.<p>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.
Great to see Excel adding more features!<p>The argument I've heard against doing this sorta thing was that they wanted to keep Excel simple enough to not alienate many non-technical users, sorta forcing it to be a simple, accessible environment for everyone.<p>It'll be neat to see how the user-base adapts to a more powerful feature-set. I mean, it'd seem like a lot of folks will be thrilled, finally having some extra functionality without having to use macros/VBA/VSTO/COM/etc., though how might non-technical folks feel about a coworker sending them a spreadsheet with function-values?
<i>> The existing Name Manager in Excel allows any formula to be given a name. If we name our function PYTHAGORAS, then a formula such as PYTHAGORAS(3,4) evaluates to 5. Once named, you call the function by name, eliminating the need to repeat entire formulas when you want to use them.</i><p>That's the biggest issue with LET / LAMBDA at the moment. Users are terrified of the name manager and simply do not understand what they are for or what "scope" means. On top of that, copying content from one workbook to another leads to names being copied over as well, which is how I often end up with ancient names such as FXRATE1997
This is <i>almost</i> what I always wanted, but it feels a bit bolted on to be honest. I don't like that you have to put a complex nested function in one cell, rather than using multiple cells with temporary results. While this allows you to concatenate Excel functions, I think it doesn't allow you to write a function in "idiomatic" Excel. If I had to implement functions in Excel, I would use one of two strategies:<p>- You have a special area or special kind of sheet, where some cells are inputs, one is output, and all others are used for temporary calculation<p>or:<p>- You define your calculation as usual, in B5: = 10*A5
- then in C5:<p><pre><code> =MYLAMBDA(B5; A5)(3)
</code></pre>
Meaning: Take the formula in B5, treat A5 as an argument, and return a function. Then call this function with the argument 3.<p>The benefit of this? You can have an area in your sheet where the user can enter formulas and multi-cell-calculations, not just numbers, and they are applied elsewhere.
There is, perhaps surprisingly (or not), already a relevant XKCD mentioning this feature while poking fun at the computational abominations that were already possible in Excel:<p><a href="https://xkcd.com/2453/" rel="nofollow">https://xkcd.com/2453/</a><p>On that note, TFA claims that the introduction of LAMBDA finally makes Excel Turing complete, unlike the kind of Turing machine simulators the stick figure is referring to in the XKCD comic...<p>> (In contrast, Felienne Hermans’s lovely blog post about writing a Turing machine in Excel doesn’t, strictly speaking, establish Turing completeness because it uses successive rows for successive states, so the number of steps is limited by the number of rows.)
This is cool. I work on a lot of spreadsheets at work and am religiously against dropping into VBA for anything. It would often be easier, but it then destroys the portability of the spreadsheet (now it has to be .xlsm, people get scary warnings, etc.).<p>Also, does this:<p>> <i>With LAMBDA, Excel has become Turing-complete.</i><p>sound like a threat to anyone? :)
The blog post's title is an homage to a series of papers from the 70s, which formulated the Scheme programming language and the beginnings of what we now know as "functional programming".<p><a href="https://en.wikipedia.org/wiki/History_of_the_Scheme_programming_language#The_Lambda_Papers" rel="nofollow">https://en.wikipedia.org/wiki/History_of_the_Scheme_programm...</a>
Naive but serious question: couldn't Excel create a special / hidden sheet for lambda functions, thereby allowing them to be easily written on multiple lines, with some kind of standard formatting, then calling a lambda from a cell would be of the form:<p>=LAMBDA(global_function_name, [cell_input_1, cell_input_2, ...])<p>Wouldn't this be a cleaner design? Trying to deal with cells whose formulas are <i>way too long</i> to be put in a single cell is Excel's Achilles Heel (and a footgun that you are nearly guaranteed to enounter sooner rather than later). This LAMBDA proposal as written seems to exacerbate that problem, not improve it.
One small recent thread:<p><i>Lambda: The ultimate Excel worksheet function</i> - <a href="https://news.ycombinator.com/item?id=25923628" rel="nofollow">https://news.ycombinator.com/item?id=25923628</a> - Jan 2021 (4 comments)
Am I the only one who read the title and was immediately reminded of <a href="http://lambda-the-ultimate.org/" rel="nofollow">http://lambda-the-ultimate.org/</a>?<p>(Is the title a deliberate call to that site, or something even older?)
Writing a lambda like that would require documentation. I wish Excel had a mode to look kinda like Jupyter except reactive (or observablehq except a desktop app), so I could easily add documentation for any cell and fold/unfold as I wish.
I've used Excel to automate things like splitting spreadsheets into separate files, and I write functional code with lambdas as a programmer. The way they phrased this makes it sound like their goal is to allow you to do hideously complex things, not to let you do more powerful things simply. I started out excited and ended up scared.
This is great and all, but it struck me that only Microsoft could come up with phrases like "LAMBDA is available to members of the Insiders: Beta program" and "LAMBDA complements the March 2020 release of LET". It sounds like something someone might write in a parody press release on comp.lang.scheme 30 years ago.
This is great, there were a few network functions I used a lot (validate IP format, find network address, find broadcast address, check if address is in subnet, etc) and would always just stick a "scratch" sheet in a workbook duplicated for each time I needed to perform an operation and nobody was ever going to be able to decode after I hit "send" on the email. The additions they've added make this so simple and ubiquitously available I wouldn't even call it ugly for that use case anymore.
If you want to stay on top of what is going on in Excel, the team's Excel Blog is worth checking out now and then.<p><a href="https://techcommunity.microsoft.com/t5/excel-blog/bg-p/ExcelBlog" rel="nofollow">https://techcommunity.microsoft.com/t5/excel-blog/bg-p/Excel...</a>
I really like what these guys are doing <a href="https://numbrz.com/" rel="nofollow">https://numbrz.com/</a> You can build data stores that can be published to other numbrz users. They can augment your data and republish. As the source data changes, everyone's stores are updated.
I always thought the Excel computational model was elegant and useful as it didn't allow for non-termination.<p>Now they lose termination for the use case where someone knows how to program but can't or won't program in some "normal" programming language.
I wonder how a programming language “extension” to Excel works together with the fact that the excel language is localized. Will the lambda function names be similarly localized?
The PhD work of Sruti Ragavan appears to lie behind part of this development. She hasn't defended her thesis yet, but she's been recruited by the MSR Cambridge team behind this work, where she interned in 2018, IIUC just before she began her PhD work.<p><a href="https://sruti-s-ragavan.com/research/" rel="nofollow">https://sruti-s-ragavan.com/research/</a>
I don't understand the point of this function, when Excel already has Power Query. It doesn't seem like anyone who is literate in functional programming would want to use this, and anyone who isn't up to it wouldn't either.<p>One of the most annoying things about Excel is it has so many parts apparently designed by people or groups that didn't talk to each other and didn't have a grasp of all the rest of it, let alone the world of the (various groups of) users.<p>Who ordered <i>another</i> Turing-complete system in Excel? One that is, like all the others, a pain and a half to debug or analyze? Has anyone figured out how to turn this into a security vulnerability yet?<p>Saying "yay people are making videos" only makes me think of all the horrific tutorials on Power Automate. And this: <a href="https://xkcd.com/763/" rel="nofollow">https://xkcd.com/763/</a>
Coming up next: Excel Lambda back-end experimental support on LLVM. (Just a joke)
Excel is a very useful tool for many non-programmers employees. With LAMBDA they can have a more expressive system without the need to touch VBA, JS, PQ M language, nor jump to Python.
Are we able to generate side-effects with it? Like poking the value of a cell?
The "Lambda" paper Steele and Sussman never wrote!<p><a href="http://lambda-the-ultimate.org/papers" rel="nofollow">http://lambda-the-ultimate.org/papers</a><p>Including:<p>"Lambda the Ultimate Imperative"<p>"Lambda the Ultimate Declarative"
Wow, that recursive example is a nightmare. I can't imagine being the person that's asked to debug what's going wrong here a few years down the line.
<i>The Calc Intelligence project at Microsoft Research Cambridge has a long-standing partnership with the Excel team to transform spreadsheet formulas into a full-fledged programming language.</i><p>Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.