Future of Coding - Looker's Lloyd Tabb on Growing Languages Through Deprecation

Episode Date: August 25, 2017

In this episode, I speak with Lloyd Tabb, co-founder and CTO of Looker, a data analytics platform build around a SQL modeling langauge, LookML. He talks about how he created a successful business around a language, and how he continually improves the language through deprecation.Support us on Patreon: https://www.patreon.com/futureofcodingSee omnystudio.com/listener for privacy information.

Welcome to the Future of Coding. This is Steve Krause. Today, I have my friend, mentor, and old boss, Lloyd Tabb, on the podcast. He began his career as a database and language architect at Borland. He then founded Commerce Tools, which was acquired by Netscape, where he then went on to be the principal engineer on Netscape Navigator Gold. Lloyd also helped shape Mozilla.org. Then he went on to be the CTO of LiveOps, the co-founder of ReadyForce,

and founder and then advisor to Luminate. Lloyd is now the founder and CTO of Looker, a software platform analytics that's revolutionizing how people get insights from their data. I joined Looker in 2014 as their 30th employee, and they are now well over that size. I think they're maybe 10 times the size that they were just three years ago. Lloyd also happens to be one of the truly kindest and most benevolent people I know, and I'm really thankful that he took the time out of his busy schedule to do this interview.

I hope you all get as much out of it as I did. And without any other further ado, I bring you Lloyd Tapp. So I have Lloyd Tapp here on the podcast. Welcome, Lloyd. Thanks, Steve. So as I mentioned in your introduction, you've been working with programming languages for like decades at this point. So could you just tell us a bit about how you got started building programming languages? You know, when I was in college, I was studying finance and I started taking computer classes. And I just got fascinated with all the different

programming languages that there were and what you could express in them and what they were good at. And so there was a language called Turbo Pascal at the time. It was for CPM machines. I'm that old. And I was fascinated by it. I had used a couple of different compilers, and then this compiler compiled so fast and allowed such expressiveness. And I started I wanted to actually get closer to the machine so I was doing some assembly

language programming and it'll let you do inline assembly and I was I was I became fascinated with with with turbo Pascal and the design of it because the there were extensions to it that were just really incredibly crafted and the software was crafted beautifully so it's's kind of a long story, but I ended up coming out to Borland International, which was the company that made Turbo Pascal, to try to sell some software that I was writing in college. And then they had offered me a job if I ever wanted to work there.

I went, I was driving out there, ended up in Colorado and worked for two companies, one which was making operating systems and the other one which was just me and another guy writing a brand new programming language called Force. It was a database programming language that had a native code compiler in it. And for me, the expressiveness in language is pretty incredible. It's this, I don't know, the way my mind works is that building language is the best way to solve a problem. You know, I think there are people who think imperatively.

I kind of think in a very data-driven way, in a functional way. And so language design is kind of natural to me. So since then, I was at Borland, and Borland had some of the best language designers in the world. So I ended up working with the guy next door to the guy, Anders Heilsberg, who wrote Turbo Pascal and ended up writing C Sharp. And at Borland, I ended up doing several different languages. One was a common scripting language called Lucy, which we put into a bunch of different products. And we rewrote the language for Dbase in a new object-oriented way. And so I've been building databases and languages for a really long time. Yeah, it sounds like it.

And I really like how you made the distinction between some people think in an imperative way and you think more in a data-driven way, you said. Would you say that declarative is a word to describe the way you think? So before, it's funny. When I started programming, there wasn't object orientation, right? But the code I always wrote was dispatched through function tables. So basically building state machines is kind of the way my brain works. And really what they are is it's data with function pointers embedded in them, essentially.

Object orientation is a form of that, which is a way that you build polymorphism of objects. But again, it's through V tables or function pointer tables. And in the languages that I built at Borland, they were all functional languages so that function pointers were basically first class variable types. So you could dispatch, basically you could assign an object a function and then dispatch it through a call operative the same

way JavaScript does. Yeah, so I think at least from my perspective, that's like, I guess it's not a new thing, but it seems like it's a thing that a lot of programming languages haven't always had, like first-class functions. Were you guys way ahead of your time at Borland? Yeah, well, we were building languages that were for scripting our applications.

So we had Quattro Pro, we had Brief, an editor, we had D- an editor, we had Dbase Paradox, and we had languages in each of these programs, and we were building a common language to do this. So we thought deeply and long about scripting. And actually, there was a guy from Lotus who came there, a guy named Ivar Wold, who was brilliant. And he taught me about closures. And the functional part of this, it became obvious that in order to bind events,

basically it's for event binding. You have a UI element, you want to tie some event to it. Basically, you want to bind a function pointer to an object, but when the function gets invoked, you want the context of the object to be available. And so that's where we did the this pointer and the ugly form pointer, like the parent pointer was also bound in some of the languages too. But yeah,

the idea that you would bind a function to an object and then when it was invoked, the context of the object would be available. And that's basically the nature of scripting. We did all of that development there. When you started your first company, Commerce Tools, there was a programming language that you created for that company as well, right? Yeah, so what happened at Borland was I was building languages, and we had just shipped Dbase for Windows, which had an object-oriented language in it, and it was a database.

And then my friend Eric Swenson, who's still a good friend, showed me Mosaic. And I realized that the world was about to change, that this web thing was going to be huge. And so me and a couple of other guys quit our jobs, and this was before VC, so I had saved, I was saving money for the day when I was ready for this. I had saved $100,000 to start a company. And so then it was basically so I could support my family for a year while I was building the software. And we built, we started building the very first application server for the web. So we were tying a database and a programming language. And it was a scripting language, an object-oriented scripting language.

And it eventually shipped at Netscape as LiveWire. And it had the session request, it was object-oriented so that it was the model that was copied by Microsoft, which was the ASP model and Sun with the JSP model for the web servers.

It was a naive design in the sense that it didn't handle clustered servers very well, but from a programming point of view, it made it very simple to program web servers. So we pioneered the object. So when a request came in, you had access to the request object. It was automatically bound, and you could hang variables off of that and or the session object. What ended up happening, so we got acquired, actually.

It actually wasn't even an acquisition. It was a, hey, come do this over here kind of thing. That was the way things were done back then. So we ended up, the four of us ended up going to Netscape. I ended up writing Navigator Gold, which was the word processor. Because at the time we believed that we needed a GUI development environment to build a programming language. So the thought that you would build a programming environment without a GUI behind it was not something that made sense to us. In retrospect, we were wrong. So I ended up building the Navigator Gold there.

Yeah. I'm curious. So when you say a language with a GUI behind it, what do you mean? A designer. Like, so you remember, so every language had a resource editor, and the resource editor would let you draw dialogue boxes and forms and data input. And, you know, I don't know if you remember Dreamweaver, but Dreamweaver, there were people who would hand code HTML, but Adobe believed that nobody would ever do that, and so they built Dreamweaver, which was this complicated builder for HTML, right? And I built Navigator Gold, which was this complicated builder for HTML, right? And I built Navigator Gold,

which was this complicated builder for HTML, which was an editor basically for HTML. And what ended up happening was that people ended up going back to language to build stuff. So it was a return to a language-based way of constructing code. In the early 90s, we had moved very much to a GUI way of building code. Oh, that's really interesting. And I think, as we'll talk about later, I think that it kind of foreshadows how you built Looker on top of a language. Yeah. The thing, so I've been the CTO of a bunch of different companies. After Netscape, I did a bunch of stuff,

but one of the things I did was CTO over at a company called LiveOps, where we were the first crowdsource company. We had 30,000 home-based telephone operators. Actually, LiveOps is still cranking along. And we needed everybody to see call data in order for the business to work. So I built some custom tools that allowed, through a web interface, people to see what was going on in telephone calls. And I realized that that was a really important way for... It was a real key to success of LiveOps.

LiveOps grew from, you know, like 10 people to 150 million in revenue in three years. You know, it was crazy how fast we grew. And we had 350 people in the company. And everybody was looking at the call data to see what was happening on the calls, being able to look at the calls in aggregate, but also be able to drill in and listen to the calls. And then I was CTO of a company called Luminate, and we built another tool to look at ad tech data. And then I was at a company called ReadyForce, and we built a tool so that everybody could

look at their staffing data. And what happened was that I realized that generally being able to have large groups of people query data in a way that they would normally write SQL queries for through a web interface was key to success. So given my database background from Dbase and Paradox and my language background from building languages at Portland and before, I realized that it needed a language-based solution to this problem.

What's strange is that the alternative to the web-based environment was mostly the people were running SQL queries. They would just type in some SQL, run it, and look at, and render the results, and they'd have basically Rolodexes full of SQL that they would use to try to investigate this data, or they were using something weird. The other tools that were available were really archaic PC-based tools. There wasn't anything web-based that could do this. And so I took a close look at SQL and figured out how to decompose it. And so the problem with SQL is that it has terrible reusability characteristics. I mean, awful.

If you have a query and you wanted to do something slightly different, it's a copy of the entire query and then replaced some part of the string, some part of the query. And you get generational errors in SQL because there is no encapsulation model. And I'm talking about querying here. I'm talking about the SELECT statement itself,

not the inserts or anything else. But the actual analytical function of SQL, which is really the SELECT statement, is not very reusable. And so what I did was design a language that basically blew up the select statement into its composite parts and then allowed you to encapsulate logic in each of the parts and then make something entirely reusable out of it.

So at its core, that's what LookML does, is it's a reusable version of SQL. It's basically, if you think of SQL as assembly language, then LookML to SQL is basically like C++. It's an object-oriented language that allows you to create interfaces to query data. I think the Looker architecture is so fascinating, and that's part of why I love the product and wanted to come work for you guys. And whenever I talk to my friends, they find it really fascinating when I explain how the Looker architecture works, where you have this. And I think in particular, what they find fascinating is how you have this, and I think in particular, what they find fascinating is how you have this, the customization layer, the modeling layer

is itself a language. So it like kind of separates concerns. So you can have the analysts build out the model in LookML and then it exposes like a GUI interface to the business people. So yeah, I almost see it as a, as LookML is what customizes the user interface in a way. Yeah, the thing, so to understand, a SQL query basically allows you to pull back tabular results out of it.

Essentially, all select statements return you a table as a result. And the way that you invoke Looker, so there's this Looker language model that describes a whole bunch of different, it describes a universe of tables. And then every single query is represented as a function call, basically, with five parameters that will return a result set, which is a table. And the parameters are the model itself, basically the starting table that you want to start from, the scalars, the scalar computations, the aggregate computations, those are measures and dimensions, and those are just named fields. Those are just names of things. So it's a list of names, field names. How you're going to filter the data and how you're going to sort it. With those five parameters, you can pull back any piece of data through the model. It will craft the SQL for you.

But it's not just simple SQL queries either. You can do very, very complex transformations that are multi-layer and persisting and materializing views. Basically, anything that you can do in SQL, you can represent in LookML. But then access it through this very simple functional interface. DAN GALPIN- Yeah, it's amazing.

And not only can you do anything you could do in SQL and LookML, but there are some things in SQL that are so complicated that logistically you wouldn't be able to do practically in SQL because they're just so complicated. You need a tool like LookML to help you do these complex abstractions. DAN GALPIN- Yeah. So some of the complexities of SQL are basically, depending

on how you join something, a join is basically combining two tables. And if one table has more rows than the other, the data fans out. So you're starting with a small matrix, say the users, and you're joining orders. Your result is the orders table with each order getting the user's name represented. But if you want to do any kind of aggregate computation against users at that time, say you wanted to average the user's age, but you've joined in orders, that computation becomes impossible in SQL because of the nature of the join. And look about solves.

We have this thing called symmetric aggregates, where all our aggregate computations, you don't have to worry about join patterns. You can think about your data in a very logical way and what you want to measure in a simple way, and Looker figures out how to write the complex queries that you wouldn't normally have the patience to write. Yeah, even that, which might sound a little simple for someone who doesn't know SQL, is just magic. That's such a beginner problem that I remember facing with SQL that just entirely goes away. But before we move on, I want to just articulate kind of how a simple piece of LookML would work. So for example, like a named field. I remember the example that you guys had in your documentation is the user's name, and it concatenates first name and last name. Could you kind of walk us through how even something as simple

as that works in LookML? Sure. So basically, the flow of LookML is that for every table that you want in your model, for every physical database table, we call that a view. And the reason it's a view is that it's a logical abstraction on top of the table. So for every field that's in the table, you'll probably declare a dimension. It's a scalar.

So you basically declare a dimension for each of those. You can build computed dimensions. So the example that you gave, which would be I have a first name field and a last name field, and I want first name space last name as the name field. It doesn't physically exist. I can create a dimension that is that. And then you can also, in the view, declare any aggregate computations that you want. So say you have one that's always

automatically generated is the count. So you could count the number of users, for example. You might also compute the average user's age, so you could create a measure. It would be a type average and the SQL for it would just reference the age field in the users table. And at that point, to query, if you simply wanted to query the average user's age,

you would start with a model, you would reference the users table, which we would call the users explorer, and you would compute average user's age, which would be the name of the measure and that would be it that would you would get a result set that would be one one one row and it would have the result would be a column in the would be average users age and the value would be whatever that that number computed to be if you wanted to look at it by state you could then do the exact same query feeding two fields in.

One would be the state and the average user's age, and it would produce a two-column table by each state producing the average user's age. And just so our users have a picture in their mind, the way Looker works, or the way it looks, is that you have on the left side of the screen, you have a list of dimensions and aggregates, and on the right side of the screen, you have the results that were returned. And one thing about Looker that I thought was really fun is there was a tab, the SQL

tab that you could click on so that when you're adding dimensions and measures to your query, you see the SQL getting constructed in real time. So it kind of allows you to see how connected they are, how Looker's really writing a SQL for you. Right. Yeah, no,er's really writing a SQL for you. It's been a blast. What's amazing is how many, how good the adoption has been

of this. I'm an entrepreneur and a language designer. I don't know there are very many of me in the world. The road here is littered with dead companies of people who've tried this. So it was not a it was not a I guess I guess, you know, it's not it was it was a business plan out of my heart as opposed to an out of one that like made any sense because there were so many naysayers about,

oh, you're really going to start a company that's based, you know, at its core has a programming language. And the value that we provide, of course, is the ability to see data. But the technique that we used is designing a new language. And that was not a, it didn't inspire a lot of belief. What did inspire was when people used it, they saw how great it was. But from an outside perspective, it did not sound like a sound business plan. Yeah, I think for a lot of people listening to this podcast, I think that's definitely something they can agree with.

There aren't too many successful businesses they can point to that are built around a programming language. But to brag on you, to talk about how successful it's been, first, I would like to confirm that it is amazing to use a product. When I was a customer, I was so obsessed with it. I remember

when I was trying to think about where to go next in terms of a job, I was talking to my friends about how there was no to think about where to go next in terms of a job, I was talking to my friends about how there was no companies that were exciting to me. But then later, five minutes later, I was talking about how much I loved using Looker. Five minutes later, I'm talking about how much I loved it. And they're like, well, why don't you work there? It seems like you love that product.

And I think that's a common thing. I think Looker hires a lot of their customers because the customers who use Looker just become missionaries. Everyone loves the product. You know, Margaret, who is one of our early hires, said to me one day that we'll be successful when we have a thousand true fans. And that's really the driving philosophy of Looker. Getting a fan base, Looker should be so't, you know, I want, you know, getting a fan base, getting,

Looker should be so good that it changes your life. And if it changes your life, then you'll become a fan and you'll talk about it. I'm a big fan of Seth Godin, who's, who wrote The Big Boo. You have to be remarkable and remarkable, meaning worthy of talking about. So what we do is, what I love about Look ml is that it's a non sequitur there isn't anything you know a lot of languages are well that's it's like you know it's a lot like X Y & Z language except that it's does this you know it's it's Java with closures it's you know it it's but you look at if you look at look ml it doesn't look like anything else that came before it. There isn't anything to look at.

And that's what makes it so different. It's actually why I'm really proud of it. It's really a non sequitur in this space. I think for other aspiring programming language entrepreneurs, what advice would you have around building a company around a language? And in particular, I think the story you tell about how you noticed that you had a problem, this problem at other companies, I think could be relevant to people here. Yeah. So I didn't design a language because I wanted to design a language. I designed a language because I wanted to design a language. I designed a language because I wanted to solve a problem.

So the problem was that you can't really see data very well. And so there's a notion of domain-specific languages that are coming out. And so Looker is a domain-specific language around representing data. of domain specific languages that are coming out and so looker is a domain specific language around around representing data um and and so uh it's not a simple derivation on on it wasn't trying to make programmers more efficient it was trying to make something possible hmm and what exactly are you trying to make possible that's that's the important part here

what is what when you program and look about what do you get you get a web interface to data And what exactly are we trying to make possible? That's the important part here. When you program in LookML, what do you get? You get a web interface to data and you get an API to data. That's all that LookML does. It's not an imperative language. It's a functional language. It produces a function library to get at tabular data. That's what it language. It produces a function library to get at tabular data. That's what it does.

And it produces an API that a visual builder uses and an API can use. And then from that, we build the whole Looker platform, which is dashboards and interactive applications. And we have shareable components that are in the description, so we have these things that let you share. You can grab a data set and then a LookML definition for Salesforce or for Zendesk or for segment data and be able to immediately get value out of that data and also be able to, you know, it's all version controlled and you can modify it

and share it between projects. And so there's a tremendous amount that you can do with this thing, but what it is at its core is a way of building interfaces to data. You know, my advice is, what are you trying to accomplish? Right, what is the core thing you're trying to make happen? And, you know, is that a 10x improvement or is it an incremental improvement?

Right? And incremental improvements don't tend to go very far in my experience. You know, the VC in me says, you know, you want to see a 10x improvement in order to be able to have something that's going to have uptake. So, and I want to drill into some of the language design choices you made, because I think they're really interesting. So, when you first built, the first version of LookML that I saw was built on top of YAML. So, I'd be curious to know why you chose YAML as opposed to XML or JSON or a GUI interface. Well, a GUI was out. I learned a long time ago that there were a bunch of GUI builders in databases,

and hiding code underneath buttons and dialogue underneath UI elements makes it very difficult to read or understand the flow. I'm a real fan of Noam Chomsky and Noam Chomsky says that if you don't have language to express something you can't think it. He's got the language theory and that there are different languages that are better at producing, at expressing different ideas. So that this needed to be a language was obvious to me. And so that's why I didn't do the GUI. Actually, at the keynote at Join last year,

I talked a lot about why language is so important. The second part of it was, okay, so I'm going to build a language, and we were going to be scrappy. It was just me and Ben. We wanted to get going. I didn't want to spend six months writing a parser. And XML is horrible to read.

It's not readable. But YAML is basically a version of XML that's designed to be human readable. The whole point of it is basically writing human readable data structures. It's simple, there are libraries everywhere that make it available to read it in any language. So it became very, as a jumpstart, starting with YAML was really easy. So we built LookML based on YAML.

And then a few years ago, you transitioned to a more custom syntax. YAML had some problems. You had to understand YAML first, then LookML. And YAML has some quirks in it about indentation that are not necessarily obvious. If the indentation is wrong, the YAML parsers just give up. They go, yeah, no. And we could have rewritten the YAML parser so it was more forgiving or did better error checking. So we already hooked into the YAML and had gotten pretty deep with it. But we decided that we wanted a full-fledged IDE with suggestions and, you know, things that

IntelliJ offers you, you know. Like you're declaring a view object. What are the possible things you can do here? And so we created a slight derivation. It's not very far from the original LookML. It uses curly braces to begin in an object. It uses spaces or new lines to eliminate between name-value pairs. And basically, it's all name-value pair based. So there's an object declaration and then a bunch of parameters to those objects.

Because remember, LookML is a functional language, not necessarily an imperative language. And it also has the ability to embed SQL in it or HTML in it. So we created a very simplified syntax. It's very easy to machine read. Our IDE can do a great job displaying it. It's very quick to parse, and so we switched over to our new syntax. And how did the—because I know as a language person it's like terrifying to transition people to a new language. How did the transition go for your users?

You know, we wrote a translator. So you hit a button and a machine translates your whole project. So the transition happened very quickly. I think we're, I don't know the stats, but we're mostly everybody's transitioned over to New Look ML now. Wow. You know, it's great it's you know it's it's hit it's hit a button it happens fix a couple of we'll highlight a couple of errors and you're off and running wow holy crap that is i like you never hear about a language upgrade that drastic that goes so well that's amazing well you know so

what's different about like inventing a language then language is that you're going to get it wrong a lot. So, and the important thing is to deprecate what went wrong and make it better. So early LookML does not look at all like LookML looks today. LookML is a very live language. We are very careful to make it upward compatible, and we're very careful about what we add, but it gets easier and easier to use each year.

So the first year it was like GAML, and it was hard to understand, and the objects were, for an example is that we had joins embedded in views, which was very difficult to understand the join hierarchy of a set of related tables. We moved that into a tone object.

So there's another object called an explorer, which basically describes all the relations between the tables and what the keys are and for key and primary key relationships, so that you can understand that in one spot. You can just go look at it and go, OK, well, this is how these tables are all related. That's separate from how all the the aggregates computations are happening or the or the dimension cup happened um but look ml didn't initially do it that way and but we were able to uh add the new way of doing it add warnings about the old way of doing it and eventually deprecate it so that it doesn't support

it anymore and um so it's it's it And so it's important to have a live language, but it's also important to know there's fatigue too. So we don't want to fatigue our customers too much. They learn one thing one way, they can do it. We want to make it easier for the new customers coming on. So we have this balance of adding complexity. What is painful enough that we're very conscious about what's hard to understand. We're always trying to make it easier. There's a tax, a complexity tax, when you're dealing with language that you're always trying to

reduce that complexity tax so that the concepts are easy to understand. And a lot of languages leave bad stuff in for too long, we think. So we try to get the bad stuff out. Example of that is like Perl. There's 15 ways to do things. I love Perl. There's probably a great style of Perl that you could write in. There's just too many ways to do things.

And so we want to reduce the number of ways of doing something and we want to make it as clean and as simple as possible. If Perl had deprecated some stuff, I think it would have been more successful. That's so interesting. I think you're inspiring me here

to do a better job with my programming language platform, WoofJS, that my students use in the after-school program. I'm so terrified of changing the language because kids have learned it already that I really don't deprecate as much as I probably should. Well, if you find that there's something that's hard for the kids to understand, don't get stuck there. The thing that happened with early looker was,

so we were talking about the measures earlier, and depending on the join pattern that would happen, measures would not be available in certain cases if you, you write a measure in a view, average user's age, and you're in the orders view, and the early looker could not compute the average user's age because we hadn't figured out how to do it yet. And it created this mental tax on everybody who was programming in LookML.

The first question that they would ask is where do my measures go? How come my measure's not showing up? Well, you know, we, it drove me crazy. It was a question that everybody who used the, who, who used the language would come up against. I knew they would come up against, I knew they would come up against the question. You can't put it as the first thing, but it's got to be the third thing that they see.

And when we solved this problem, I was ecstatic because we were able to eliminate a piece of complexity in the language by figuring out how to do the computation anyway, that made the whole thing much simpler. The whole language got dramatically simpler because we could do this computation. And it's pretty fascinating that if your language has a rough spot in it, just stick with it and try to figure out how to get the complexity out and don't worry about changing it. As long as what you're doing is providing value, you can keep the old people working in the way that they were using it.

If you have a warning system, you can warn that that's the old way. You can hide the old way of doing it and drop it out or mark it in the documentation that it's not there and then eventually drop it out. But there are a number of ways of doing this. But deprecating and enhancing, you're not going to get the language right in the first go. You're absolutely not. DAN GALPIN- That's really great advice. There are a few places that I'm thinking about would be

good for that in my language. I worry that my language is a JavaScript library, so I don't think it would always be so easy. I couldn't build a translator the way you did for your first version to the second version because things are a little bit, there's too much going on some of the time. So I guess what I'd end up having to do is what you just said.

I'd have to let the old people kind of stick with the version they were using and then new people will get a newer version. Right, I mean, so function, API versioning is a pretty standard way of doing things, right? So if somebody's building to the version one of the API, you can let them choose the version of the API that they're dealing with, and then do version two of the API,

which doesn't contain the things that you don't want in it anymore, so that anybody new coming along will actually deal with the 2.0 version. Totally. OK, so one thing that we've talked about a bit, but I wanted to get more of your thoughts on, because it's particularly relevant to the people in the world, people who are today trying to build

a future of programming. A lot of us think that the future isn't in text, but it's more like a GUI type of thing, or more of a structured editor. And I think what's really interesting about you is that you thought that too, and then you tried that way, and it didn't work, and now you're back on text. So the question to you is, do you

think 30, 50 years from now, 100 years from now, are we always going to be programming text? Is there something after text? Yeah, how do you think about that? So I think that it's, yeah, I think it's going to be text. Wow, forever. You know, I think that human beings read. You know, and you might have a flow chart that kind of shows

you might have something generate pictures for you that make it easier to understand. But I think that we think in language. You know, I mean, you can look at everything in the 80s was visual programming. In the 80s and 90s was visual programming. And it was terrible. None of that stuff really, you know, nobody loves that stuff. There isn't anybody who who who goes yeah i love

programming that way yeah that's true uh i think that's part of looker success is uh people are the competing tools have these like you know kind of glitchy interfaces and um and when people see how clean and beautiful that just you know coding in text at Looker is, that's part of what I love so much. There's a, who was it? This guy from Mentor Graphics. I saw him speak once. And he was talking about GUI interfaces versus language interfaces. And when you're a baby, you point at things. So like the original, so the, the, um, Microsoft windows and, uh, and, and window

based operating systems, right. Are drag and drop. And nobody has ever built a really good scripting engine for, uh, for Mac OS X or windows, right. Because the gestures don't have words. You drag the window over here, it's very imprecise. You have a big finger that you're moving around, and those scripting engines for Automator or

any of the flows that you would do in the GUIs are terrible because there's no words associated with them. But on the flip side of that, all of them have great command line access, right? Because you can string these things together. You can take a bunch of commands, throw them into a function or a batch file, right?

And then reuse that and reuse that. And so it's because there's language. It's shitty language. It's bash, right? But it's it's it's it's because there's there's language it's it's it's shitty language it's bash right but it's language at least right and so you can combine these things you can actually get multiple steps so the the visual stuff you know the the fact the fact that I can see two pieces of things interlocking together and maybe they have a you know a shape of the edge that I can see that they would fit together the way Scratch does. That's cool, but it becomes unnecessary very quickly, which is why Wolf.js is so interesting. It's the step from, okay, I can see how these things visually get together, to language.

Yeah. Okay. Thank you. language. Yeah. Okay. And I think that once you make that leap to language, you don't want to go back to GUI. Yeah. And I totally agree. That's why we got Wolf. The one thing that frustrates me, because I work with children, and like you said about how you always got frustrated because people would always, like the third thing would be that they didn't understand where to put the aggregates,

and it just hurts you emotionally. I think I feel a similar way with my kids when they delete a bracket somewhere, and their whole code is broken, and there's no way for them to figure it out. It's very impractical to expect them to figure it out and they're really stuck until an adult comes to help them. And so the amount of time and frustration

and sadness and stuckness that kids have to go through in order to build a parser in their head makes me emotionally sad. So that's my motivation to move past text. So I'm wondering if you... But if you had a better way of teaching syntax? Like if before you taught them anything else that you had a game that let them look at what a well-formed sentence syntactically looked like?

Yeah, well, so I guess... I'm guessing at an answer here. But you know, we learn, when we're learning to speak, we learn the order in which we put words before we learn a lot of words. Yes. So we learn how to name something. Dada, mama, book, tree, right? And then we learn, I don't know, I'm not a linguist, but want tree, want book.

Right? So we learn very simple sentences. And so it's something to me about, OK, figuring out how to get them the syntax separately from solving the problem might help you. Yeah, that's a good perspective. And then one last question on this topic. I know in the past all visual programming languages have kind of failed miserably.

And so that would lead you to believe that it probably won't succeed in the future um but a lot of people listening to this to this podcast kind of like hope that we'll be able to figure it out if we're just like clever enough would you would your advice be to like kind of not waste our time in that it's like probably a dead end or you think you know maybe there's a chance someone can figure it out okay so um one thing in life that I have learned is that I can predict. I'm pretty good at saying, at predicting what winners are. Like, oh, yeah, Apple, when Apple in 2003, when they came out with the OSX and the MacBook, I was like, yeah, they're going to win because it's a Unix-based operating system.

Windows at the time was super heavy and buggy and security problems. And I'm like, oh, Apple're going to win because it's a Unix-based operating system. Windows at the time was super heavy and buggy and security problems. And I'm like, oh, Apple's going to win here. So I was like, I even made a stock bet that paid off crazily well. But picking that winner was easy, right? Because it coincided with things that I was observing. Okay? Going on the other side of the market, I can't do. I cannot tell you what's going to lose.

I can't tell you what I can't see. Yeah, that makes sense. So somebody might have a great idea that I don't understand does not mean it's not a great idea. Cool, yeah. The way my brain works is, I think, the way my brain works is human beings need language in order to be able to express complicated ideas. That's my belief. And I've made bets on that, and it's worked for me.

Yeah. Am I right? I have no idea. Okay, cool. Yeah, yeah. Could someone prove me wrong? Absolutely. It's just that I'm not betting that way. It doesn't mean that I, yeah. Yeah, yeah, totally. That's well put.

And I guess that brings me to my last question. So what else would you place bets on today, specifically in the future of technology, the future of programming space? What else do you think is going to be in the future that most other people don't yet see? DAN GALPIN- So I've loved how the last couple of years have been, or the last 10 years have

been fascinating in languages. So we've seen, we saw a bunch of people go to Python and to Ruby for fast development and JavaScript and abandoning the strongly typed languages of the past, which allowed for rigor and testability. And now we're flipping around and we're starting to see some really interesting languages that give you a lot of the agility of these powerful scripting-style languages with strong typeness. And I think it's fascinating. I think it's a very good time for programming languages. It's an exciting time.

Yeah, I agree. So if you had to place a bet, would you place the bet on stronger types or more dynamic languages? You know, I think strong typing, we're developing software in the large more. So I think strong typing in the, you know, we're developing software in the large more. So I think strong typing has such advantage in machine code generation, which isn't as important as it used to be. But it's, you know, it's important. But more importantly, it's in rigor and the ability to find bugs during compile time. It's actually so much better.

So you can build better software in a strongly typed system. And so I'm excited in the large. So I think we're going to see more of it. Cool. Another question that I wanted to ask you is, because you're like the SQL expert, if you could talk a bit about what you're the SQL expert,

if you could talk a bit about what you like about SQL, what you don't like about SQL, and why SQL is going to win over the NoSQL model. Well, OK, so there's transactional SQL and analytical SQL. And I would separate SQL into two different things. There is the transactional SQL, which is the create table, insert, update, begin transaction, end transaction world. Okay.

I don't have a dog in that fight. All right. There are some really good NoSQL solutions here. I mean, I took a deep look at Spanner, which is NoSQL. The replication, you know, it offers some amazing things. Like the way it does replication is that it writes simultaneously to multiple places. And then when you read back, you read back one that is from the least loaded node. So there are no replication delays, which really simplifies writing software

because if you're in a MySQL world and you're in a replication chain, you write to a master and you read from a slave and there's a delay and there's a possibility that you wouldn't get the data that you just wrote, things like that. And all of that goes away. So from transactional SQL,

I don't really have a, I'm not talking, that's not the SQL I'm talking about. Analytical SQL is a totally different thing. There are a lot of people who write interfaces to data that are what I would call Turing incomplete. Okay? There is no way through the interface to express something so that you can get the data out. And what I like about SQL with the SELECT statement is that it's essentially Turing complete for analytical data. I can ask, if I've got a modern SQL on top of a set of tables, I can pull the data out that I'm looking for.

I can write the SQL. There is a way to write the SQL to get the thing that I'm looking for, and I can pull anything out of it because the language is complete. And so the interface, that abstraction is correct. It's ugly as shit. It's old. It's, but nobody, you know, and LookML arguably simplifies that and it does a better job of that.

It takes that, like I said, thatl is assembly language but it it is fully complete you know it's turing complete for data you can actually get anything out you can express you can it has enough fun the core fundamentals in the language so that you can actually pull anything out of that data now is it easy to pull it out no but with but but but that's why i think i don't think it's going anywhere and everybody everybody else who's tried to do that without has screwed it up. So like Druid, interesting, great, totally Turing incomplete. The aggregates aren't there. The ability to combine sets is not there.

It's for pulling a single table out. But it's fast, right? But it's incomplete. So there are these systems that pull data out that are scanning, but they're not complete. Yeah, I think you really hit the nail on the head there. Because I can say from my own experience, I use Firebase as my back end. And one of the biggest headaches I have is I can't do anything close to the expressivity of SQL in

Firebase. It's so limited in what I can ask out and how. Right, exactly. And the value of data often comes from combining a lot of different sources. So it's not, I'll give you an example. We have a model that's for your AWS billing data. So it shows you like all

your hosts and what what you spent on each host and amazon publishes this data into into your s3 into s3 for you and we can we can we have a data model against that and um we also have our salesforce data in the database and it's really useful to combine the AWS billing data by Salesforce ID. So I know what I'm spending, pulling a data set out, which is the week, the Salesforce account ID, and how much we spent on that account

in AWS to get our cost of goods sold. And we can join that back into our finance data. So the value of being able to combine these things, if you don't have SQL to do this, you're just kind of doomed. Yeah, that's, yeah, it's totally,

yeah, that's exactly right. Thanks for going into that. Yeah, for whatever reason, I didn't quite realize that it was SQL itself that like enabled the like turn completeness. I think that that's a really good distinction to make. Yeah. So one last question for you. When I worked at Looker, there was this thing

that you would do that seemed like magic to the rest of us. There would be some big customer problem that seemed impossible to solve. And then we come into work on Monday, and you'd be like, yep, I spent all weekend doing it, and it's solved now. And you would walk us through how it worked, and it would be magic.

So I was wondering if you could kind of unpack, like, behind the scenes, how were you able to solve these incredibly hard SQL problems? What are some techniques that you use? Oh. Well, I need to know the specifics to know. Sure. Yeah, I can give you a specific.

There was, I think, one of the problems, so I guess maybe like, for example, the symmetric aggregates. I think that, I don't know if I was there when you solved that one, but that one seems like a problem that you probably went off some weekend and solved it and then came back. Yeah. and solved it and it came back. Yeah, so it was... The way Symmetric Errors works is... I did not realize up at that point that most sequels had decimal arithmetic to basically infinite precision.

And the problem with... What I was looking for, and they also had the ability, and most sequels also had the ability to do sum distinct. And so, which is a very strange function, right? It's like find all the unique numbers and add them up. And so what we were able to do is we were able to combine the primary key as a number and the number that you wanted to sum together, compute that as a sum distinct, and then compute the sum distinct of the primary keys and subtract that out. And it would always produce an accurate sum regardless of whether or not the data had fanned. And it was that somebody had said, oh, look at this, some distinct. Great, that's cool.

Wow, some distinct. Why do they have that? Okay, and then I went and looked and saw the decimal type and realized it was possible and got very excited and went off and crafted and wrote it one weekend.

Wow. You know, I mean, that was like, when I saw that it was possible, because like I said earlier, I was marinating on this problem for a really long time. It was bugging the hell out of me that, that, that, that, that aggregate computations would disappear based on join patterns. And the ability to make that go, to make, to make that representable in the, the language could already represent it.

We just couldn't compute it. And then figuring out how to compute it was just, that was great. Yeah. Okay, so I guess the actual steps are, one, like, be focused on a problem, like, totally marinate on a problem. And then just step two is keep your eyes open until it kind of comes true. Until you can see a way to solve it, right? And then make a run at it.

Also, you know, the other thing is also, you know, what you probably, you mentioned that it was, like like a customer problem. Yeah. So very often I would listen to like a customer and then they would point out a flaw in the way that Looker worked and I would be embarrassed by the flaw. So I remember one weekend it was, I think it was the way we, so Looker allows you to pivot data on two dimensions. Take, dimension and have a table and the dimension goes down the side and another dimension goes across the top and then all the measure values are repeated. And early on at Looker, filling in that grid was tricky. And if you had a very sparse data set, that we might not fill in the grid. And I wanted to try to figure out a way to make sure that the grid was filled in.

And so I think that's the other thing that you, I think I remember you being, I went off one weekend and did that. Yeah. But it's just, it's making stuff happen. It's like going and looking at it, thinking about it, and then going, yeah, I think it's, I think that's computable.

Damn, that's so impressive. One last question. I'm sorry I keep saying one last question. I keep that's so impressive. One last question. I'm sorry I keep saying one last question. I keep coming up with interesting things to ask you. So I think I found one thing that you did at Looker that's a little less technical, but I found also really fascinating, is you started the company,

and then you decided not to be CEO, but instead to be CTO. So can you walk me through how you made that decision? Yeah. So when we started Looker, we got customers very early, built the minimum viable product, actually started selling ourselves as a service so that, hey, we'll build this interface to you so that you can see your data. But they never got, so the first people never really saw LookML. I just did, I wrote the LookML. And the rule was that all the customization happened.

Anything that we were going to do specifically for a customer had to happen in LookML. That was how I knew that LookML would be strong enough to survive. And so the first customer was that way. The second customer, it was a pretty technical shop. So I had them try LookML. The third customer, again, it was a pretty technical shop, so I had them try LookML. The third customer, again, it was consulting. Fourth customer was back to them trying to do stuff in LookML and so on. And then the fifth and sixth, we crafted the model first and then tried to hand it off to them.

So we were learning different patterns. But very quickly, we became cash flow positive because of the consulting model, which enabled us to wait until we raised money until almost a year to the first round. So I funded for the first, or we self-funded for the first, and then we got going. Once we had raised money, I was able to hire actually someone to do some selling. Because up until then, I was doing all the selling and stuff. So realizing early on, I'm doing every single job in the company. So I'm programming. My co-founder, Ben, is also programming.

And he's a fantastic programmer and then we hire another programmer but so I'm programming too but all the non-programming tasks that were not finance I had somebody who was helping us do bookkeeping

I was doing and then Mark Randolph later on came in and started advising me about what to do next and how to price things and those kinds of things. And it was a great thought partner in how to actually get this thing rolling. So Roll Forward, we just launched. We had a bunch of customers. We're doing really well. We'd raised $2 million, hadn't had a bunch of customers. We're doing really well. We'd raised $2 million, hadn't spent a lot of money.

And I met Frank, and Frank had been giving me advice all along. He was at Green Plum, which is a big NPP database. And what had happened was he knew a ton about the market. And my board kept asking me, okay, it's time for you to hire a sales team. You need to hire someone to manage sales and do all this stuff. And I'm like, I am not, you know, it's not something I've ever done before. I'm not going to be very good at it. I'm world class at building software and product, but I'm not world class at, um,

at, at running a company. It's not something I've ever done before. So I can make a lot of mistakes. Um, and so Frank came on actually as president and I was, um, CEO for the first few months. And then Frank started bringing in great people and he was doing an amazing job and we went out and we raised a bunch more money because Frank was hiring great people and and right after the fundraising it was like okay I you know I there I don't want to be the front-facing person in this thing I want to be the person that's working on product I want to do what I'm world class at. And that's being a CTO. And so we kind of swapped titles. I was chairman and

CTO and Frank was the CEO. And that's worked out fantastically well. Yeah. And I guess one of the things that I, about the story that I guess you may not know is that it's so inspiring to hear that, because so many people want to be CEO almost like as an ego thing, to know yourself so well to be able to say, I'm not world class at something. I want to focus on what I'm good at. It was part of why I came to work at Looker in the first place. I was talking to a venture capitalist about Looker, and they spoke specifically about how well you knew yourself

and how impressive it was that you made this decision so early on. It was tricky. It was a leap of trust. It was like a bet the company decision. And that Frank was willing to come and be president showed that he believed in enough in what we were doing that he was willing to come anyway be president showed that he was, he believed in enough in what we were doing that he was willing to come anyway, right?

But then mutually what's best for the company was that Frank was CEO. Yeah, so this might be like an impossible question to answer but for those of us who aren't fortunate to like happen to know someone like Frank who like might be able to be CEO of our company, if you hadn't run across Frank, do you think you would have kind of done like an executive search? Like you would have looked around for a CEO or you would have waited until you kind of came across someone more naturally? So I ascribe to what I call paintball management.

And, you know, when I think, you know, first of all, the reason for Looker's success is the team. Like, it is absolutely not my success. It is our team's success. And it is because people like you came to work at Looker. It is these brilliant people who've come and said, I get it. I see why this is different.

This is, I like the way you, I like the way Looker feels. I like what Looker makes. I like the way the company Looker feels. I want to be part of that. And that's all that Looker is, right? If you look at Looker, if you were to rob Looker on the weekend, come into the weekend trying to steal from Looker,

steal Looker's secret sauce, you come into a building that's full of, you know, it's a beautiful building, full of monitors, right? No computers. And there's nothing here, right? So the only thing that Looker really is, is the software that we make, is the people that actually service, that build the software, build the company, help the customers. You know, all we are is the people, right? And so Looker's success is really all of, is the people. And so the people that you can bring around you is probably the biggest success, is what's going to make you successful. I mean, you may have a great idea, but there are a lot of great ideas that one person had that didn't go anywhere,

right? And if you want to build a great company, you've got to build a great company, which is finding great people. And so the paintball management thing is when you're early, you find people of different skills, and you have to see whether or not that person fits into your organization. So if you kind of threw everybody's skills up on the wall as a spatter pattern and you look and you go, what are our holes? Well, before Frank came along, I had a big hole about sales management, you know, knowing of enterprise. I mean, there was a huge hole in the wall, right? And so when he showed up and started showing, demonstrating to me that he could fill that giant hole in the wall, it was really important to get Frank, right? And it was an enormous hole that we had. And if we were going

to be successful, we needed that hole filled. And if it wasn't Frank, other people would have, you know, I would have talked to other people and they might, and it might've been three people filling that hole. Right. But it wouldn't be as filled as consistently or as thoughtfully as one person being able to fill a big part of it. And then, you know, I was filling big parts of the wall at that time. And slowly my the pattern of the wall that I was filling would get smaller and smaller. You know, I was doing I was doing it being the analyst. I was being it, being the analyst. I was running product. And slowly, over time, that has shrunk

because we've gotten amazing people to fill in various parts of that. Yeah, well, that's really helpful to hear about how you think about it. I like the paintball analogy a lot. Yeah. Yeah, so before we end, I want to give you an opportunity

to tell people how to get at you, whether that's Twitter or email, however you want people to follow you. And then if you wanted to make a – I know Looker is growing like crazy. So if you wanted to make a pitch for anyone who wanted to work there, what kind of things you're hiring for, things like that. So we're always hiring. So if you go to, if you go to our website, you know, we always looking for,

for talent, really great, talented people who are inspired. It is a great place to work. We are, we, we treat people like adults. You know,

it is a, it is a compassionate, nice place to work. It's probably some of the nicest people I've ever worked with. They're terrific. And we are doing great work and we're growing. So if you're an engineer or you're into data or you're marketing or you're into sales, we have great positions. And we've been growing tremendously over time. We've actually, up to this point, we've never missed our plans. Unbelievable.

Unheard of. Which is crazy. Someday that might not happen, but right now it's been. To just spell that out for everybody. So every quarter, Looker sets like sales goals. And every quarter, they hit them. And then they set even more ambitious, like unhittable sales goals. And then they hit them every single quarter, quarter after quarter.

And you never miss a quarter. That's right? That's right, yeah. Oh, my gosh. And, you know, that won't always be true, but it's been fantastic in that, you know, and it's a testament to our customers and to the, it's just amazing. There's tremendous passion around the product inside and outside, and I love that. Totally.

So, yeah, so if you're interested in working in a great startup, Looker is great. Yeah. I would definitely confirm all of those things when I was at Looker. It was just the best experience. So, I would totally agree. Sorry. I interrupted you. Go.

Okay. I'm sorry. There was another part of your question. If you wanted people people is there any links like your website or oh i'm probably i i'm not very visible on the on the internet i i steve as a i i haven't done one of these before i i'm mostly invisible but i did this for you thanks lord i guess that's like um uh for anyone considering working at looker that's like um one thing that might not be obvious is is when I was a customer of Looker,

like Lloyd was always available as like a mentor and just as like a thoughtful person for me. And then when I joined Looker, the whole team, especially you, Lloyd, have been so wonderful to me. And then even after I left Looker, just like throughout the years, giving me advice and mentorship and coming on coming on the show i really appreciate it and it just shows how um how thoughtful and and caring you are to like all the people in your world so if you want to say thank you so you can you can tweet at me at lloyd i'm lloyd tab on twitter so if you want to great awesome great cool thanks again so much for being on the show i think i learned a lot of this conversation so i hope the listeners did too great great talking to you steve thanks