Not because they're any better of a fit for BI stuff mind you. At my place of work, the BI department is a black hole you can keep shoving more compute into, and they'll just come up with worse queries.
It's still early in the space, but there are real advantages to defining visualisations, metrics, and reports in a code-first way. Aside from being able to do more powerful things with something like pandas as opposed to Tableau, being able to check your dashboards into git, create reusable libraries internally, review changes in PR format etc., goes a long way to making things reproducible and less of a black hole. Also, creating reports and dashboards programmatically opens up some interesting use-cases where a drag and drop tool would break down.
We're building an open-source framework for creating reports and dashboards using Python, which you might find helpful: https://github.com/datapane/datapane. You can think of Datapane as the view layer / interface for any BI analysis you're doing using the open-source Python ecosystem. Any feedback would be much appreciated!
I mostly agree, but I think there's a reason behind the madness. Back in the early 00s to early 10s they really were more productive, "secret alien technology"-type tools.
But these days obviously ten lines of python (or whatever else) calling the database do exactly the same thing, except you actually have git, debuggers, ides, etc.
Many BI departments still cling to them because they're comparing 2020s no-code tools to early 2000s programming languages.
It surely is fast enough, I'm not blaming people who use Tableau.
But "faster" compared to what? It's not faster than pandas/seaborn, not faster than d3... even just for super simple stuff where GUI tools shine.
If the final solution needs to be somewhat self-service, then sure, you can't expect the end user to write python or javascript, and Tableau is fine. If the end result is just a report that some technician has to prepare, then I sincerely doubt it's the fastest way to get there, even ignoring maintainability, source control, etc, where it's just a no contest.
Comments
Not because they're any better of a fit for BI stuff mind you. At my place of work, the BI department is a black hole you can keep shoving more compute into, and they'll just come up with worse queries.
It's still early in the space, but there are real advantages to defining visualisations, metrics, and reports in a code-first way. Aside from being able to do more powerful things with something like pandas as opposed to Tableau, being able to check your dashboards into git, create reusable libraries internally, review changes in PR format etc., goes a long way to making things reproducible and less of a black hole. Also, creating reports and dashboards programmatically opens up some interesting use-cases where a drag and drop tool would break down.
We're building an open-source framework for creating reports and dashboards using Python, which you might find helpful: https://github.com/datapane/datapane. You can think of Datapane as the view layer / interface for any BI analysis you're doing using the open-source Python ecosystem. Any feedback would be much appreciated!
I mostly agree, but I think there's a reason behind the madness. Back in the early 00s to early 10s they really were more productive, "secret alien technology"-type tools.
But these days obviously ten lines of python (or whatever else) calling the database do exactly the same thing, except you actually have git, debuggers, ides, etc.
Many BI departments still cling to them because they're comparing 2020s no-code tools to early 2000s programming languages.
Tableau is way faster to demonstrate your work on.
These professions need to get shit done fast. The workplaces that need them are extremely reactive to the market, etc.
So having debuggers isn’t necessarily a thing they’re interested in.
Now if you’re in a slower paced BI environment that’s where you generally see more traditional programming tooling be used.
It surely is fast enough, I'm not blaming people who use Tableau.
But "faster" compared to what? It's not faster than pandas/seaborn, not faster than d3... even just for super simple stuff where GUI tools shine.
If the final solution needs to be somewhat self-service, then sure, you can't expect the end user to write python or javascript, and Tableau is fine. If the end result is just a report that some technician has to prepare, then I sincerely doubt it's the fastest way to get there, even ignoring maintainability, source control, etc, where it's just a no contest.