[mathnode]

Without interacting with it myself, none of this is surprising.

I have used excel in the past, and I am a long term python user. But if you asked me today what I really wanted to make my life easier and ultimately a product or business better using only excel? I would ask for lua or scheme. I don’t need a batteries included environment embedded into a spreadsheet. I just want sane syntax for common functionality which does not require arcane knowledge and long forgotten wisdom.

[smcin]

Your personal use-case might prefer Lua or Scheme, but most casual Excel (or SQL) users are non-programmers so they won't. They'll want the equivalent of decently-documented macros or boilerplate they can easily and quickly use without modification. (One common Excel use-case will clearly be "import/munge lots of data from various sources, then pass it into some AI model, then process the output". Can't see people writing that in Lua.) The real target customers for this one are commercial/enterprise non-programmer Windows-stack users whose legacy workflow/data is built around/glued to Excel and are already locked into paying $$ monthly/annual subscription. From looking at Reddit, I don't see much other takeup of Python in Excel.

I don't get your "shouldn't need batteries-included environment" objection; MSFT is bundling Anaconda distribution libraries with Excel. I'd expect it works seamlessly online and offline, as far as everything supported by Python stdlibs. (Can you actually point to any real problem with the batteries?) Really the only part I see you can quibble is things that are currently only implemented in uncommon third-party libraries, i.e. not stdlibs/numpy/scipy/scikit-learn/pandas/polars and the main plotting, data-science, ML, DB and web libraries.

> I just want sane syntax for common functionality which does not require arcane knowledge and long forgotten wisdom.

Show us some Python syntax for common functionality in Excel which does require arcane knowledge and long forgotten wisdom. Otherwise, this is purely your conjecture.

(If anything, bundling Python with Excel will stimulate healthy discussion towards which Python stdlibs need to be added/enhanced/changed, and which third-party libraries should be upgraded to stdlibs.)

[superb_dev]

Python in excel is a feature I would only expect to be used by power users. Someone who spends a lot of time in excel. Calling these people “non-programmers” isn’t true, excel itself is a pretty esoteric programming language.

I personally don’t think python is the problem here, but if their users can learn python they can certainly learn lua.

[smcin]

That's exactly what I said above: most Excel users are non-programmers. Hence Python in Excel would only be used by a subset of Excel power users.

Moreover, having to pay $$ recurring subscriptions for that stack to run open-source software (Python) they could run for free elsewhere mean it'll only be used by commercial/enterprise Windows-stack users who are already locked into some legacy workflow/data built around/glued to Excel. For example, financial users, or users who have some expensive license seat of some enterprise product(s). Means an even smaller subset of users.

We're saying the same thing.

[superb_dev]

Are we? I’m arguing that lua would have been a better choice than python.

Any traditional programming language that you put in excel is going to be a feature mostly for power users, and I think they could pick up lua just as easy as python

[jimbokun]

They could, but a lot more people already know Python than Lua.

[smcin]

Most Excel users (not the power users, just the 1.1 billion everyday ones, including many of the enterprise ones) don't know how to program in any language. You're coming at this with a HN mindset.

"Python vs Lua" is not even on their radar. And even if it was, their criteria would be dominated by platform lockin and compatibility with other licenses (e.g. commercial SQL, Tableau, MSFT, etc.). Not by "which open-source language?"

[extr]

IMO you're the one coming in with an HN mindset. Python has massive mindshare even among people who have never programmed. It is the numeric computing language du jour. In any given financial company there are definitely already python users. Lua, a language primarily known for plugin scripting, with no numeric computing libraries, that has zero mindshare among non career programmers, is not even in the conversation.

[smcin]

Nobody here has made a case for Lua in Excel. I wrote "Python vs Lua" is not even on the radar of most Excel users, not even the subset that are programmers.

(Why are people here aggressively misreading everything I type, today?)

> Python... is the numeric computing language du jour. In any given financial company there are definitely already python users.

The original post didn't say "financial Excel users". Not all Excel users are financial; most aren't. I've worked with legal informatics users, e-commerce users, bioinformatic users, among others. Those sectors never use Excel for numeric computing, IME (drawing the occasional chart isn't numeric computing). They are more familiar with SQL, SQL macros, SQL query generators, importing/exporting to/from SaaS, etc. Like I said.

[TZubiri]

>excel is too bleh >python is too blah >myLanguageOfChoice is just right.

We can't all be special snowflakes, python and excel are lingua francas.

[Spivak]

Lua is pretty uncontroversial as the embedded language of choice and is actually made specifically to be embedded and play nice with the surrounding application.

I get why they chose Python for this and it's not all that hard to embed, well the interpreter anyway, compiled modules are another story.

[TZubiri]

Yeah if what you are making are videogames.

If you are doing grown up stuff, you use a grown up language.

[BenFranklin100]

+1. I’ve had to fire guys like the OP. Smart guys often, but nearly impossible to work with productively.

[bitwize]

> I would ask for lua or scheme.

Scheme? Did somebody say... Scheme?

https://apexdatasolutions.com/home2/acce%CE%BBerate/

It's a paid addon, but still...

[andylynch]

The likely target users for this are analyst/ quant types. Very likely they are also using Python on the same tasks already.

[mhh__]

All of that is much easier in Python where you have access to a lot of other people data wrangling utilities