Forum Discussion
DISCUSSION: A future for Excel as a programming platform
As for Lambda functionality and my thought to many that are asking for added functionality that include more VBA type of actions (modifying other cells, system functionality interactions, etc...) I want to say that my hope and excitement for Lambda is the added functionality in an inherently safe playground (i.e. we don't need macro permissions and hopefully soon excel online should be able to natively allow their functionality). If they want to expand Lambda further then it should have some clear delimitator such that user permissions are not needed for standard added Lambdas but only required when that expanded 'LambdaVBA' is embedded .
Even if I'm for decades in IT business I'm not a professional programmer, more street developer, and afraid can't support such discussion, just have not enough skills. However, few comments from practical point of view.
Functional programming in general and lambdas in particular have a long history and have their own niche, and, as everything in this world, they have their strong and weak points. Among weak ones are poor maintainability and complicated re-use. From this point of view I'm bit disappointed by Andy Gordon comments that he has no idea how lambdas will bi distributed and supported, perhaps through Twitter. LAMBDA in Excel needs to have more support, these are additional functionality like MAP(), more rich IDE compare to current formula bar and Name Manger and perhaps kind of framework. Without that it will be quite limited usage.
Declaring of Minimum Viable Product (MVP), which was quite popular few years ago, applied to LAMBDA is a bit formal. MVP is a great approach, but it's not a golden bullet which solves everything and need it's own set of tools to support.
Liam_Bastick knows much more about financial modeling in particular and about Excel in general, perhaps he comments. From my point of view the core of FAST is to ensure reliability and maintainability taking into account current status of Excel. From that point of view it's quite reasonable.
Despite of some scepticism I consider introduction of lamdas in Excel as a great step forward. With some further support it will have it's own niche, how wide it depends on supporting tools. But IMHO, that doesn't mean LAMBDA or nothing.
I think you are under-selling the depth of your understanding! Like you, though, I have never been a professional programmer. I did develop and prototype computer methods for the design of aircraft, but the final coding was done under contract. I missed the early days of spreadsheets because I was using VAX and Prime computers.
When I did get involved, I was not especially impressed with the code developed by user interaction on the worksheet, nor by macro recorder (highly impressive mechanisms for developing bad code?). What I look for in code is readability, relating data objects to their business context, and I want the process intent to be clearly expressed. By 2010, my workbooks were dominated by Names and Array formulas. I had discovered that array formulas worked when committed via Name Manager but had no way of telling whether that was the intended behaviour or some accident. When FAST came out (in 2015?), I took it to be a claim that its proposed methods represented 'best practice' and other approaches were to be deprecated. After a lot of discussion with Andrew Berkley of F1F9, we agreed to differ on the detail, with me accepting that their need was for shared practices that could be deployed by end-users.
Dynamic arrays, LET and now LAMBDA make my life so much easier, building on things I was doing anyway but without the pain of CSE and allowing me to use local names far more freely. One case that I do argue is that 'simplicity' is not achieved by adopting to most primitive methods; it requires the most appropriate. What I try to avoid it moving from being 'thought provoking' to being just plain annoying; that is very difficult to judge.
