The problem with all of these "BI as Code" things is that _nobody_ that you want to use this knows Python or Markdown. If they did then they would just use Python and Markdown like they usually do.
This stuff is all pointless. There is no audience for it.
With the rise of large language models I have a lot more faith in "as code" approaches and a lot less faith in "low-code" or "no-code" approaches to doing the same thing. Large language models expand the workforce capable of using Python and Markdown at all, and they make that workforce more efficient.
I honestly think people who used toolsets that abstracted the code away from them (But still obviously used code under the hood, just indirectly) screwed themselves over. A tool like this provides abstraction while still allowing for text-based input and that's a winning combination moving forwards.
You are wrong. I work in FinTech and use Python and markdown. I am very interested in this. The current visualization tools in the Python space are very hamfisted. Dash and Plotly all hit a wall when trying to do complex visualizations.
I haven't used Evidence so can't speak to its capabilities. It's been a while since I've used Dash and Streamlit so I can't recall exactly what caused me to throw it aside but I do remember that formatting was hell and to even get close to what I wanted I had to use components from plotly express, dash, streamlit, essentially every Python data viz library. It was just too much of a hassle.
Yeah. The frameworks solve the 80 percent problem quite well but once you start trying to be as specific as the business often wants, I would find them lacking and end up popping JSON to d3 (or some such)
There's a lot of ... sub par BI devs who want to point and click through horrendous PowerBI interfaces and such. Personally i find that style to hamper my ability to express what the business units need out of data products.
Comments
The problem with all of these "BI as Code" things is that _nobody_ that you want to use this knows Python or Markdown. If they did then they would just use Python and Markdown like they usually do.
This stuff is all pointless. There is no audience for it.
With the rise of large language models I have a lot more faith in "as code" approaches and a lot less faith in "low-code" or "no-code" approaches to doing the same thing. Large language models expand the workforce capable of using Python and Markdown at all, and they make that workforce more efficient.
I honestly think people who used toolsets that abstracted the code away from them (But still obviously used code under the hood, just indirectly) screwed themselves over. A tool like this provides abstraction while still allowing for text-based input and that's a winning combination moving forwards.
As an example, GitHub Copilot is already quite good at writing “evidence flavoured” markdown, and it’s really helpful.
That worked for evidence users the minute copilot came out. How long will it take tableau to ship something equivalent to that?
You are wrong. I work in FinTech and use Python and markdown. I am very interested in this. The current visualization tools in the Python space are very hamfisted. Dash and Plotly all hit a wall when trying to do complex visualizations.
I'm curious what you hit in dash and plotly that evidence let you overcome.
(FTR, I use all of them, lightdash, streamlit, (as well as drop down to flask) etc.)
I haven't used Evidence so can't speak to its capabilities. It's been a while since I've used Dash and Streamlit so I can't recall exactly what caused me to throw it aside but I do remember that formatting was hell and to even get close to what I wanted I had to use components from plotly express, dash, streamlit, essentially every Python data viz library. It was just too much of a hassle.
Yeah. The frameworks solve the 80 percent problem quite well but once you start trying to be as specific as the business often wants, I would find them lacking and end up popping JSON to d3 (or some such)
Sean, my cofounder, and I previously led the data team at a PE fund. This absolutely tracks with our experience.
I'd be interested to hear who you think the audience is here that can't code?
We're positioning the tool towards data teams who already manage their ETL layer using SQL, so our take is that they _do_ know SQL.
From the business-user perspective, it's just a website. Click to navigate around, drill into data etc.
(as a side point, there is no python, but I think the sentiment of this comment is around it being code, rather than the language specifically)
There's a lot of ... sub par BI devs who want to point and click through horrendous PowerBI interfaces and such. Personally i find that style to hamper my ability to express what the business units need out of data products.