51–60 of 123 posts
Show HN: I've built a C# IDE, Runtime, and AppStore inside Excel
The spreadsheet paradigm is immensely intuitive and arguably the only alternative to the standard procedural programming currently in use in number crumching.
But therein lies also a major weakness when used for important tasks: hard to validate.
Once you further combine it with API calls and whatnot, the situation gets totally out of hand: how do you reproduce anything?
The landscape around user interfaces, computational capability and (most importantly) the ever deeper embedding of such tools in decision making suggests to start taking the humble spreadsheet seriously and maybe that requires going back to the drawing board.
The big problem is that this is exactly backwards. I rarely want to access Python from my Excel. I quite often want to access Excel from my Python. A spreadsheet is a great GUI for a lot of things. A lot of people are employed creating "shitty version of Excel but can be driven from any of " Being able to easily drive Excel from an external Python program would make for a nice cross-platform application substrate.
I’ve used it at work some years ago, and it’s a great product.
The big problem is that this is exactly backwards. I rarely want to access Python from my Excel. I quite often want to access Excel from my Python. A spreadsheet is a great GUI for a lot of things. A lot of people are employed creating "shitty version of Excel but can be driven from any of " Being able to easily drive Excel from an external Python program would make for a nice cross-platform application substrate.
:)
Earlier quoted context omitted.
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-sour…
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.
(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.
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 whic…
Didn't read it but, couldn't this be a "battlefield" where LibreOffice could have unbeatable advantage?
What's the state of things at Libre office regards to this? Do they support python or other languages for macros and for formula/expressions?
> We wanted an alternative to VBA, but got an alternative to the Excel formula language
Optimistically, I would guess that the powers that be inside MSFT wanted to show they "integrated" Python into Excel but didn't really want to mess too much with a product that has stabilized over the past 30 years. Cynically, I would say that they've messed up the implementation on purpose so they can put a bullet through the "Python in Excel" idea without actually doing anything useful.
A much better way to add Python (or any modern scripting language really) to Excel is to 1. Make a special library that can be called from the language and which only works with Excel. 2. Bundle a minimal interpreter so that the scripts can be run locally without pushing everything to some godforsaken Azure datacenter. Make this a downloadable plugin for all currently supported versions to ensure backwards-compatibility.
This is a much better way to ensure that Python becomes the glue language for Excel. There are so many applications where reporting, analysis and visualization can be better achieved through automation using scripting languages. VBA is old, limited and is yet another thing for someone to learn if they want to script any Office product. All of these are hurdles that can be easily removed. I guess though that the part that really sucks is that these are all things that the MSFT of the 80s/early 90s would have done in a heart beat if it meant more people would use Excel (they built in bugs from Lotus 1-2-3 for God's sake) but I guess it's a different story today when everybody does use Excel.
Didn't read it but, couldn't this be a "battlefield" where LibreOffice could have unbeatable advantage?