Thanks @liveink! I'm Benn, another one of Mode's cofounders - we're excited to launch it! As an analyst myself, I've wanted this combination of SQL + Python ever since I learned SQL, so this is a feature we've been thinking since the early days at Mode. It was always a bit of a dream until a couple engineers built a prototype at our first hackday last fall. We all got really excited about seeing it in action - even a smoke and mirrors version - and feeling how much it could change the way we worked in Mode. We began doing some research, and kicked off the work in earnest this winter. Regarding R and other languages, we're always thinking about how to make Mode better for analysts and data scientists. Python made a lot of sense to build first for a number of reasons, but if there are folks out there who like the combination of SQL and Python but are avid R users (few things seem to stir data scientists' emotions like debating which of the two is better…), we'd love to hear from them. And yup, we also launched new, more flexible pricing options today! Anyone can now sign up to use Mode, including Python Notebooks, for $19 a month. We believe that analytics tools shouldn't be affordable to only those with analyst in their job title. One trend we’ve seen among a lot of our customers is that people you wouldn't necessarily expect to be using SQL - PMs, QA engineers, operations teams, content marketers, and others - are creating and sharing reports in Mode. We wanted to make sure Mode is accessible to anyone who wants to be analyze data, whether they're a tenured data scientist, someone who works with data part-time, or just looking to learn.

@shanacarp Hi Shana! We have a couple philosophies when thinking about languages like Lua (as well as R, Julia, and others). Mode started as a tool that only supported SQL and a couple databases. Today, we support a number of different types of databases (including SQL-like DBs like Presto, Hive, and BigQuery), Python, and Javascript visualization languages. Mode isn't built to be tied to one language, but instead aims to fit into a workflow, regardless of which languages it incorporates. And how we define and understand that workflow comes from feedback from our customers and the community (so thanks for sharing!). We also want to make sure that we're allowing analysts and data scientists to play on their home court, not ours. We want to enable people to work in the languages they already know (whether it's a particular flavor of SQL, Python, or a language like Lua). That means if we move toward tools like Lua, we want it to be as "native" as possible. So, while we don't support these things currently, we hear you. In the meantime, I unfortunately don't know of any services that offer this combination all at once (which is one reason why we built it - we wanted it for ourselves). Are there any particular aspects to Mode that you like, or would want to see in other tools? Finally, regarding off-site hosting, we aren't planning on moving that way any time soon. That said, we are looking into ways to enable folks to run Python on much larger machines, which would allow data scientists to scale up their Python environments to something much bigger than what they can use locally.

@bennstancil so this goes into a much deeper conversation about the idea of "data politics" (ok I made up that term, but it is a truth) which is way longer than a post on product hunt could cover. I'll give you a starter example, but the full conversation is really an email/call because I've seen these issues go very deep in organizations and I want to get a better feel on what you think/need from the outside EG: I've seen various reactions to me when I say "I dislike SQL and I also really dislike excel for larger projects, and therefore I fully have switched over to python when I can, or google sheets with javascript if you really need a spreadsheet*" All of those reactions are external to the data and questions at hand, or work, because processes I never fully "got" SQL as a language. I also dislike how different implementations treat the actual spec - especially roles and assignments and where the actual "primary data source" is when you have a database accessing data from another table in a different database and pseduo copying it over. I have a deep terror of deleting everything - and that is before the frustration of not being able to poke at the system while "fake tables" are being created in order to get the best quality merges. Between all of this, I think the idea of using a more fully fledged coding language with a strong barrier of roles embedded in it a much safer idea, since the way things are defined in something like python (ducktyping), or even C or Java where you have to declare type is just very different than SQL itself. I've thought about it seriously enough to wonder if I, who I don't think is a particularly good engineer/coding person and is someone who really dislikes SQL, should try to build on top of PANDAS + a few other funday sunday libraries to extend out PANDAS to allow it to send merge operations to SQL written in python, and then get back a dataframe. (all of the major set operations are already in PANDAS/scipy/numpy, the biggest problem is when you need to do merges in merges, or something complicated). Excel is just crashy past a certain size and bad at versioning. While I can do all of the same things, why bother when I can do them faster with python and have versioning? *google sheets' macro language is javascript

@robertprince Thanks! We do offer discounts for most nonprofits. If you send us a quick email at hi@modeanalytics.com, we can get you set up!