For some non-technical users, Power Query is a better option. If your main purpose is to work with a large data set and then update a PowerBI dashboard, for example, then Power Query sounds like a perfect solution.
But what we see is that there are a bunch of reasons that these non-technical users are excited about Python specifically. Here are two examples:
1. One of the first adopters of Mito, let's call her Shelly, is helping a team of engineers build out a Salesforce dashboard to predict when customers are going to refill an order. Since the engineers don't have the business context to figure out how to make that prediction, its Shelly's job to construct the (in this case pretty simple) algorithm by querying the relevant database, figuring out which fields are accurate (there might be 5 different date fields and figuring out which one is actually when the user last placed an order isn't as easy as it sounds), and then making the prediction for each customer. Shelly then uses the Python code that Mito generates as a communication tool for the engineers. The code is an exact audit log of each transformation she made to her data in order to create the report.
2. Many of the companies that we work with have business specific metrics that they calculate, so they have an engineering team build a Python package that can easily calculate those metrics. Sometimes they will even provide boiler plate Python code snippets to interact with those packages. (In the future they'll be able to import them into Mito!). Its a win for the employees who can rely on the code snippets instead of calculating the metrics manually, and its a win for the engineers who can write Python code instead of M.
The last thing I'll say is that companies are moving to Python because of the openeness and robustness of the Python ecosystem. They are power users of packages like Voila, Plotly. Having employees work in Python opens up a ton of doors for how companies can support them.
Your idea about expressing logic in excel and generating the equivalent code has merit too for a different user base. Let us know when you build it, excited to check it out!
But what we see is that there are a bunch of reasons that these non-technical users are excited about Python specifically. Here are two examples:
1. One of the first adopters of Mito, let's call her Shelly, is helping a team of engineers build out a Salesforce dashboard to predict when customers are going to refill an order. Since the engineers don't have the business context to figure out how to make that prediction, its Shelly's job to construct the (in this case pretty simple) algorithm by querying the relevant database, figuring out which fields are accurate (there might be 5 different date fields and figuring out which one is actually when the user last placed an order isn't as easy as it sounds), and then making the prediction for each customer. Shelly then uses the Python code that Mito generates as a communication tool for the engineers. The code is an exact audit log of each transformation she made to her data in order to create the report.
2. Many of the companies that we work with have business specific metrics that they calculate, so they have an engineering team build a Python package that can easily calculate those metrics. Sometimes they will even provide boiler plate Python code snippets to interact with those packages. (In the future they'll be able to import them into Mito!). Its a win for the employees who can rely on the code snippets instead of calculating the metrics manually, and its a win for the engineers who can write Python code instead of M.
The last thing I'll say is that companies are moving to Python because of the openeness and robustness of the Python ecosystem. They are power users of packages like Voila, Plotly. Having employees work in Python opens up a ton of doors for how companies can support them.
Your idea about expressing logic in excel and generating the equivalent code has merit too for a different user base. Let us know when you build it, excited to check it out!