131–140 of 142 posts
Check out Budibase. It's the leading open source low code platform and perfect for building UIs on top of spreadsheets https://github.com/Budibase/budibase
Budibase looked perfect until I learned there is no option for hosting locally. Doesn't make sense.
Earlier quoted context omitted.
Most forecasting doesn't really work, as in, most falls between "not useful for predicting the future" and "outright wrong." You could get your forecasts for free or you could pay millions of dollars, pretty much same result. Not an Excel thing in any way.
Indeed, the spreadsheet I am thinking is particularly hot garbage, but slap some dorky corporate bar-charts on there and it's like beer-googles for suits.
The guy's spreadsheet seems to work. He's delivering what his bosses want to see. You might have an issue with the final output but they apparently don't. What exactly is the problem you think you can fix?
Excel is great and versatile, yet lacks some critical features. - It's easy to load data from database or API without VBA, yet impossible to write updates back without VBA. With VBA it's still messy string concatenation of SQL queries. - VBA is security nightmare - Version control is bad. Distributing spreadsheets in emails and collecting changes back is nightmare. Sharing a file on network drive lacks fine-grained p…
> Impossible to make reusable blocks. The click and drag down feature results in a kind-of code reuse. It bypasses the need to consciously name things. Is this generalisable? For small scale code, these concerns may be overkill.
Imagine taking a data pipeline and renaming all columns and variables alphabetically and then asking someone to check the business logic
Also it pushes people to include excessive parts of formulas into a single calculator rather than breaking them into comprehensible and testable chunks.
Earlier quoted context omitted.
Indeed, the spreadsheet I am thinking is particularly hot garbage, but slap some dorky corporate bar-charts on there and it's like beer-googles for suits.
But why are you associating that with Excel? Every analytics tool features charts front and center regardless of how it is delivered, web, BI, dashboard, Jupyter, etc, and no matter what language it is written in (R: ggplot, Py: matplotlib, JS: highcharts etc.). The guy's spreadsheet seems to work. He's delivering what his bosses want to see. You might have an issue with the final output but they apparently don't. Wh…
I am on the side of excel being used like this, even if it's hot-garbage. The worst that can happen is that it collapses upon itself and then others need to come in and do it right, or migrate the thing to something else entirely.
Earlier quoted context omitted.
Honestly, your story just indicates that someone senior needs to have a discussion with the applied mathematician about their coding practices (and they may even need a bit of training in that regard).
His code style is fine. His problem is that he is short on the discipline and focus to validate his results in meaningful ways. An exhortation to follow some vague "coding practices" won't fix that - he'll respond e.g. by writing lots of tests, none of which catch the problem his code actually has. The two ways I know to get correct work out of him are (1) review it and kick it back to him when problems are found, (2…
Earlier quoted context omitted.
I’m trying my best to create such a product. What you’re describing is something that (1) amateur spreadsheeters can use, (2) the power users, and (3) programmers, will be able to use and not feel out of their depth or patronized. I personally think that given that Excel is a pure-ish declarative language, then building on a declarative language that programmers use is a solid attack on this, which is why I’ve chosen…
Would love to hear more
* There’s a language which is like Haskell/Elm/PureScript in terms of being purely functional and statically typed. But with syntax that looks more like Excel.
* Purity gets us fearless recalculation.
* Static types let us build UI elements automatically based on the inferred types of code.
* It’s content-addressable like Unison. That means every expression and “cell” has a unique SHA512 hash of it which refers to only that expression.
* Content addressability makes cache invalidation of results trivial.
* It also makes it easy to say “I want exactly this version of that person’s cell and for all time.” Makes it impossible to break someone else’s code once it’s working.
* It also lets you fearlessly federate, if ever needed.
* Content addressed also means you can write tests against code and have them run on every change. Only the tests whose dependencies changed will be rerun. That’s not normal in Python or Haskell, but in a spreadsheet it is.
There are other design choices related to your comment but I don’t want to ramble on.
Earlier quoted context omitted.
His code style is fine. His problem is that he is short on the discipline and focus to validate his results in meaningful ways. An exhortation to follow some vague "coding practices" won't fix that - he'll respond e.g. by writing lots of tests, none of which catch the problem his code actually has. The two ways I know to get correct work out of him are (1) review it and kick it back to him when problems are found, (2…
It just sounds like he was never actually trained to program, and letting these bad habits persist isn’t doing him any favours.
What specific bad habits do you think can be addressed?
I know it's hard to diagnose anything from some forum posts, but I'll take your speculation as to what he should maybe work on.
Earlier quoted context omitted.
It just sounds like he was never actually trained to program, and letting these bad habits persist isn’t doing him any favours.
I'm not sure I understand the idea that people who are "trained to program" manage to avoid these mistakes. What specific bad habits do you think can be addressed? I know it's hard to diagnose anything from some forum posts, but I'll take your speculation as to what he should maybe work on.
While I was writing my thesis and job hunting, I attended a few workshops aimed at “grad students breaking into industry”. The main thing I noticed from applied mathematics students in particular was they would write out long functions (really hard to debug) or they worked exclusively in Jupyter notebooks (these have super complicated state, so it takes a lot of discipline to be able to translate these into usable code).
Earlier quoted context omitted.
Meh, depends on the data teams (and their chosen suite of tools)... Or on the Excel users Both sides can either hack together horrible work-arounds (a matter of "when you have a hammer, everything looks like a nail...") as well as brilliantly thought through solutions. Each tool should be used for it's best use cases, but not bent into what it wasn't designed for! IMHO spreadsheets excel at intuitively manipulating t…
> how to make the modern data stack more intuitive? I'd start with getting people to learn relational data modeling and SQL [1][2] at a deep level. Stop reaching for python and pandas/spark for every basic data manipulation task or query. Stop adding in layers of Airflow/Dagster/Prefect when a simple cron would work. Stop adding in Kubernetes/GKE/Fargate to manage the aforementioned. Stop moving data between systems…
I definitely agree with the over-hype making simple mundane tasks way harder than they should be.
So yeah, do NOT over-engineer!!
But, on the other hand, doing everything with a single Postgres and spreadsheets seems to go with the hammer-to-nail adage. And all too often, you end up with unmaintainable duck-taped hack-arounds... Which is clearly NOT better (nor necessarily worst) than the over-engineered solution.
In some cases (maybe not 1% but clearly not the majority either), it does make sense to look at other tools that might be available.
That being said, there are waaaay too many options to filter through, because of that darn hype bubble.
I've learned products designed to replace spreadsheets have a huge hurdle because the people who use spreadsheets treat operating the sheet as their job. Replacing them removes their autonomy and control over an information process, and subsumes the value they bring to their employers - so they will resist products that threaten that. Excel is a complete management subculture. The other advice I give is if you are ge…
I think there is scope to replace Excel, but it’s hard. You’re seeing a gradual spread of “data science” tools in finance, as the more technical analysts start to use Python over Excel. But as you say, the management layer still uses Excel to poke and prod a model. I think that there will be a generational shift here - you are not going to train an SVP to use Python, but the next generation of SVPs might have more ex…
Or they have formulas, but the author calculates a few numbers and throws it away. In this case they’re like a scratch pad, or a calculator with a visible memory.
I think it’s certainly possible to make better business modeling tools, and have played with some designs in that space. But they’ll never be Excel. And that’s ok