Andreas Møller is a software engineer and the creator of Toddle, a platform that lets you build web applications without traditional code. They dive into the world of web development and the exciting rise of no-code and low-code approaches. They discuss the power and complexity of Toddle, its unique visual programming language, and how it enables efficient web development. They talk about the nitty-gritty of visual programming and the complexities of version control, so stick around and join us for this deep dive into the ever-evolving world of web development.

DAN: Hello everybody and welcome to another episode of JavaScript Java. On our panel today we've got AJ O'Neill. Hey AJ.

AJ: Yo yo yo coming at you live from tactile keyboard switches. 

DAN: That's a fact that I never actually got but you know I know that people really get excited about it so good for you. 

AJ: It's just the tester board. 

DAN: Okay. And on and another panelist on today is Steve Edwards. How are you Steve? 

STEVE: Been busier than a one-legged man at a butt-kicking contest this morning, but Hello from cold and rainy Portland 

DAN: Hello Steve, by the way, just so you know that I'm sitting here with the window open because the weather is really 

STEVE: And I am I appreciate yeah.

DAN: Yeah nice here, there are other issues as well. There are unfortunately there are other issues so for those of you who don't remember, I'm coming from Tel Aviv, which is in Israel, which is at war, which is in fun, to say the least. And our guest today is Andreas Muller. Did I pronounce it correctly?

ANDREAS: Yes, pretty much. Yeah. Yeah, I'm coming at you from Copenhagen, Denmark. 

DAN: Wonderful, wonderful Copenhagen. Let's see who gets the reference. Everybody is probably way too young.

Hey folks, this is Charles Maxwood. I've been talking to a whole bunch of people that want to update their resume and find a better job. And I figure, well, why not just share my resume? So you, if you go to topendevs.com slash resume, enter your name and email address. Then you'll get a copy of the resume that I use that I've used through freelancing through most of my career as I've kind of refined it and tweaked it to get me the jobs that I want. Uh, like I said, topendevs.com slash resume. We'll get you that And you can just kind of use the formatting. It comes in word and pages, formats, and you can just fill it in from there. 

DAN: Anyway, so Andreas, tell us a little bit about yourself, who you are, what you do. We like to ask people why they, while they're famous, you know, or they think they're famous. 

ANDREAS: I am pretty convinced I'm not famous. I'm pretty sure. Yeah. I'm not.

STEVE: But once you get, once you're on here then your fame increases and you start getting autographed.

ANDREAS: Oh, I mean, for sure. 

STEVE: We've heard that from multiple people in the past. 

ANDREAS: Yeah. No, I expect that. 

DAN: Family members, Steve? 

ANDREAS: Well, I'm famous because I was on the JavaScript Java podcast, which is where people will know me from, I think. Yeah, I'm a software engineer that's been building web applications for what is probably a little bit over two decades now.. uh, and work with a ton of different frameworks, ton of different stacks and technologies, always with a lot of focus on web because I always found the, it kind of to be the most fun platform. The fact that you can deploy apps right away has just always been. Fantastic. 

DAN: But you see all sorts of building and packaging and bundling and transpiling and whatnot getting in the way.

ANDREAS: If only there was a way to get out of that. 

DAN: Yeah, I think that might be what we're going to be talking about today. No. 

ANDREAS: Yeah. So, so, um, yeah, I've been always working with the web and, and in the most recent couple of years, I've been sort of obsessed with this idea. If there's a, at least in my book, a better way of building web applications. Um, like something that lets you ship faster, that you work faster and sort of more seamlessly. And we've seen a ton of sort of progress in this space, I think over the last, especially five years actually, but also the last 10 years, like a lot have happened, right? And most recently, a lot of the new build tools and hosting platforms has just made this process so much easier But every time you make a progress, you can see the next step, you can see the next place you want to go to. So for me, this sort of meant, is there a way to build applications faster? And I spend most of my time building the front end part of applications. So specifically, is there a way to build UI faster for web applications? And that sort of led me to start Tottle, which is a platform for building web applications, without actually writing code So you build all the UI in the Total Editor, just like you would do in a tool like Webflow, or any sort of similar tools to that. But what set Total a little bit apart is the fact that you can build the UI in Total, but you can also actually build the logic and all the data fetching and everything else in Total. So you never have to leave that tool, you can build the entire application. And that is actually, you can do all these things, but actually having to write any code to make that happen.

DAN: Yeah, so no code and low code have been quite the rage in recent years, it seems to me. It's kind of like it's if our market is kind of splitting, you know, some people are betting on, you know, meta frameworks and frameworks and meta frameworks, which are really heavy into the coding part you know, you write your UI as lines of code. Um, others are, like you said, are betting on a no code or low code approach. Of dragging and dropping their way to, um, a web application, a website or web application. And by the way, I mentioned, uh, people who have listened to this podcast probably know that I used to work at Wix up until two years ago, which is very much in this space as well. Its main focus though is on the visual building of the websites only recently as it also started you know starting to target a similar place that you seem to be at which is building actual business logic on top of the user interface that gets constructed. So I looked at the total website and I looked at some of your demos and videos and whatnot And what got me really interesting is less the visual editing part. I mean, it's really cool the way, the fact that you can build the user interface with, with drag and drop, like a bit like you do with, with, like you said, with web flow or maybe with Figma, and then somehow translate it into an actual web web application or website or webpage, but what got me more interested is the way that you implement business logic in a no-code type approach. Your ability to actually specify interactivity and computational parts. And one of the videos that I saw was you actually using your tool to do coding challenges. So it's really using a no-code tool to implement, to solve coding challenges. 

AJ: So how's that work? 

DAN: Yeah, exactly. 

AJ: Are we adding some coding with a visual editor?

ANDREAS: Yeah, that was exactly. I only did the first of December and I released it on the fourth of December to make sure that I was not like giving away anything. But essentially just showing that the flexibility at Totals, especially logic engine means that you can solve advent of code challenges in total. And again, you can do it without writing code. 

AJ: That's the headliner right there.

DAN: Yeah, but it's not exactly not writing code. It's you're kind of drawing code, as it were. I mean, it's NP-complete, I think, for those more technically minded of our listeners, correct? 

ANDREAS: Yes. 

DAN: So can you explain that? 

ANDREAS: Well, so I think this is not entirely new. I realized before we did that.. that someone had done it in Sketch, the visual programming language for children. So we're not exactly the first tool to do that. I think it still surprises a lot of people that it's possible, often because it's not really what we associate. We don't associate visual programming with anything complex. It's generally used. And I think this actually kind of applies to a lot of no code. Most people see it as tools for people who can't code. And so if you know how to code, why would you ever touch one of those? Right? It seems unnecessary. But I think what we're seeing in the more recent years is that there's actually really a point to that and there's a power and a flexibility in this that rivals code. Um, you can do all the same thing. And I think you said sort of, well, it is kind of code. And I think you're right. We, we, I like making the distinction that it's programming, but it's not code. Um..

AJ: So there's my, my wife is an accountant, uh, and she can't write a visual basic script to save her life. It doesn't make sense to her. She will, you know, copy and paste something off of the internet, but like the, the very idea of indentation being a way to logically group something. Like she's done PowerPoint presentations, just bullet points, but for some reason, like that, it just doesn't. Maybe it's a mental block. I don't know. I would, I would say that she is smart enough and capable enough to be able to decide a logical flow. But she no text, she couldn't do it. So I'm wondering if, if maybe this could open up an avenue for people like that, where they, I don't, I don't understand it. But like, just can't grasp the textual representation. Maybe could grasp like a nested flow representation.. 

ANDREAS: Yes, I mean, we're seeing that all the time. So I think there's a very big benefit, which is that it just looks a lot less scary. And the thing is that when you've been coding for a long time, you kind of forget what it was like, like you forget the early days. My wife actually didn't just... 

AJ: I'll never forget PHP. 

ANDREAS: No, but you might forget some of the journey of learning it, right? I mean, my wife just changed to be a programmer. She just got a job last year as a front end developer, which is super ironic now that I'm trying to move the industry away from it. But it sort of has an opportunity for me to go back and see like, oh yeah, it was really hard to figure out how variable bindings work and why this value is there now and not before. It's just, you forgot because you've been thinking about it for years. You've just been thinking in a certain way.

DAN: It's really interesting, you know I Kind of like to compare coding to the way that lawyers write contracts you know, we need to describe something in a super precise way and But it still needs to be kind of readable and writable by humans so lawyers in contracts invented like They took the English language and they kind of twisted it, so it's still English, but it's not the English that you would write as a normal person. It's contract English, you know, party of the first part, party of the second part and so forth. We as programmers took it a step further. We went further away from human languages to something that's, you know, more alien to most people, which is why I think a lot of people really struggle with it. You know, the way that it executes the whole line after line that seems to make perfect sense to us is really challenging to a lot of people that are not from the space. Now, you know, we try to explain it by saying it's like a cookbook recipe or stuff like that, or the instructions that you might get from IKEA. But that just scares people even more. But. But yeah, talking about Total for example, instead of code, which most of our listeners, I assume know how code looks like. Now, obviously this is a podcast, this is not a visual medium, so it's kind of challenging, but can you try to describe how Total programming looks and feels like?

ANDREAS: Yeah, absolutely. So one of the things that are a little bit different with Total than other sort of previous visual programming languages, is that in Total we kind of split programming into three separate parts. So there's the first part, as you mentioned, the visual building, which is just building UI. And essentially saying, I want a div and a button inside the div and it needs some attributes and I need to apply some styling. It is all, if people are familiar with Webflow, it's pretty much exactly the same thing you're doing in Webflow, right? So that's kind of one editor, one part of it. Then we have workflows, which are essentially large flow charts. And they come in every time you have a set of actions you want to perform. So let's say when a user clicks a button, you can attach a workflow and say, I want you to do this. If this, then do that. Otherwise do that, then do this bit. Various sort of flow chart style execution. And it's visually built to look like a field flowchart. It's got our own spin on it, but if you read a flowchart, you can't immediately understand what's going on there. If you're familiar with functional programming paradigms, this is sort of everything that has a side effect is an action in total. So flowcharts are like actions. All like do this side effect, then do that side effect, then do that side effect. So it can be update a variable, it can be call an API. It can be set page title, anything that you sort of making a change in your system, that's an action. And the third part is then the formula editor. And again, this is very much borrowing from functional programming. Formulas are entirely pure. I say entirely, we do have a few like date and time and now, so we're not entirely strict to that process, but there's at least no side effects. So there's only ever like computer value. And this looks, if anybody's ever done Blender, or like 3D, any sort of 3D tool, you know that there's like a material section to do this. This might not be all of your business. But if you've ever seen any 3D tool, you realize that actually, visual programming is huge in the 3D space. When people are building materials and assigning material, like different kind of nodes, They're always doing these massive computation graphs. And in this space, visual programming is entirely dominant. Nobody's writing code for this. I never really understood why. I think the basic reason is just that people didn't, like most material artists, didn't know how to code. So it was easier to build a visual interface. But some of these can be incredibly complex in the 3D world. Totals visually look the same. It's a bunch of nodes with graphs in between. It's essentially function calls. It's essentially like just like you would have a JavaScript function. It produces one output, takes any number of inputs. This is the same thing, just arranged as a big graph. Where on the right side you'll get your output and then every node can have one or more inputs and you have this big tree graph structure. That's your computation graph. 

DAN: Now, so I have a couple of questions about that. I'm thinking about where to start. Okay, so one thing that I remember from looking at your demos and also your videos is that there's a strong reactive aspect to the way that you work. So you talked about actions being side effects, but what I saw is that very often that side effect is actually update a variable, where a variable is basically just a name value that can change. And whenever a variable changes, that variable is bound to things. So it might be bound to some aspect of the user interface, for example, or it might be bound to other computations maybe. whenever you update the variable, then everything that is bound to that variable automatically changes accordingly.

ANDREAS: Yeah, that's correct. And so the basic model here we use for how Todel works is exactly the same you'd see in React or Vue or Angular today. The underlying premises are different between each framework, but the general idea is the same. You have some state, you have either from variables or maybe from an API. And then every time that changes, you update the UI automatically. Each platform has a slightly different mechanism in which that happens, but the overall concept is the same. And again, that's the same model we adopted to total. We tried not to reinvent everything about web development. We're kind of just saying, what is that dominant component architecture that has won so that pretty much every modern framework uses exactly the same idea today, right? And how can we apply that into a visual development concept?

DAN: So a few questions about that. So first of all, just to understand the scope of what you're doing. Everything is running client-side, correct? You don't actually code the backend, or do you? 

ANDREAS:No, Total is front-end only. So it's set up to work with whatever backend you provide. And there's actually quite a few no-code backends you can use as well. But a lot of them are a little bit newer. So I think for larger projects, most of our customers are still coding the backend. 

DAN: And you basically just access the backend via Ajax calls. So an action might be an Ajax call that either sends some data or retrieves some data and then uses it to update whatever part of the user interface. 

ANDREAS: Yeah. 

STEVE: So in terms of backends, from what I was seeing on your list there, it looks like it's stuff that's like headless CMSs that are hosted elsewhere. Can you build in your own, say you want to have your own custom MySQL database for a backend. Is that something you can do as well? 

ANDREAS: Yeah. So, Tuddle just communicates over REST. So, it really works with any backend you want. You can code your own. You can use one of the no-code ones that are established. But as long as it speaks, you can talk to it over an HTTP API. You can use it with Tuddle. 

STEVE: So how does it work with local development? Is this everything is done on the total.dev site, that's where editing happens or is there something you can do locally like if you're working with the local copy of a database? 

ANDREAS: I mean so you could set up total so that it would change based on parameters to redirect to different backends. So you could say for example I would like to use a different base URL for these requests based on whether you're setting a some local storage data whatever you're doing There's no local version of Toddle. That all runs in the cloud on Toddle. 

STEVE: So you could, in theory, set up something like an ngrok URL that's open to the outside and communicate with your REST API that way? 

ANDREAS: Yeah, as long as it's reachable from Toddle's back end. 

DAN: Yeah, although to be fair, I would imagine such a solution, the more popular approach would be to use some sort of a headless CMS rather than trying to run a local database or something like that. So even during development, you're working with a cloud-based service or something like that. 

STEVE: Okay, so going, these are my, this is my geek things coming to mind as a developer. Since I live inside debugging, I'm just thinking about recent hours I spent debugging something because I was able to run everything locally. How does that work? Are you stuck with strictly like log files? Is there a way to use breakpoints and, you know, just access through your web dev tools when you're not local? Or how does debugging gonna work in a case like this? 

DAN: Before Andreas answers, I just have to say that you beat me to the punch because that was exactly going to be my next question. How does debugging work in a visual coding type environment?

ANDREAS: So, yeah, it's a great question. And We don't have a particularly complex debugging setup yet. It's something we've got in the pipeline, but we haven't really needed it very much yet. And that's because quite a lot of times the browser's debugging tools work for like very complex issues. But also, TODL itself, the way the formula editor, as we call it, works, is that you're always working with live data. So As you're building your formulas, you're always seeing the next value that you're producing. And it's very similar in a way to coding in a rebel. Where you're sort of writing each line at a time. Similar here, you see all the data all the time. So when code, we sort of have a tendency to, you know, code for about 10 minutes or maybe 20. If we're getting comfortable with TypeScript or something like that, we'll go and code and then we'll see how it works. And then eventually we'll go and figure out why it didn't work. But in total, you're really running every part of your code all the time. So you have a tendency to catch things really early. So we haven't really had a lot of need for it yet. And therefore, we haven't really prioritized it too much. As we sort of go on, obviously, there are cases where we now end up debugging issues by adding log statements, etc. We're not seeing it that much on the front end to be honest 

DAN: Yeah, to be to be honest You could probably add some sort of a simple log if you don't have it already Could probably add a simple logging mechanism into total so that certain actions You know, like you said an action is a side effect and the side effect might be log so you can easily add an action that either logs locally into the dev tools console or sends it to some sort of a telemetry service to be collected for sessions in general. Stuff like that. You probably want to have some sort of telemetry service at one point or another in any event.

ANDREAS: We have a log-to-console action that we use quite rigorously right now. And it's quite easy because again it's mostly pure functions, almost always pure functions you're working with or formulas, right? you can really just copy part of a formula over and log it out. And you can be quite confident that it's going to generate the same result. So logging, logging is sort of our main approach to debugging when needed. But again, because it's easy to build UI, sometimes you're just like building, we'll just add like a paragraph into the page and write it there. Because then you can kind of track it in real time. Right? So if I'm doing like more complex mouse interactions, like a some sort of swipe demo or something. I'm often just logging values live to the UI. I'll throw in a span and put whatever my mouth offset is in there, and then I can sort of figure out, okay, why is this not working? And as I'm dragging the mouse around, I can see, okay, it's not setting it here, or I forgot to subtract some window width, or whatever it is the problems you always run into when trying to do math.

DAN: So pull it back a bit Can you talk us about through the process of how you actually start using Total? Like, let's say I'm saying, okay, this sounds really cool. I want to try it out. What do I do?

ANDREAS:  So you can simply go to our website and sign up right now. So there's a free tier that's sort of... 

DAN: So it's Total.dev, correct? 

ANDREAS: Yeah. You go to Total.dev and you can sign up right there and then get started building a new project. We have a little tutorial project that's kind of a project built in Total that also at the same time explains to you. There's also a website that explains how to build projects in Total. So you sort of go between interacting with it and editing it to get to the next level all the time to figure out how does this actually work. And each page in that application teaches you a new concept. And after that, I would say if you want to really dive in and understand more, we have a ton of videos on YouTube, both of us explaining different concepts, but also a lot of us just building applications in total and showing how to achieve different things.

DAN: Cool. And what you described is free, correct? If I'm just building a demo website and the restriction is that that demo website is hosted on your own platform, correct? 

ANDREAS: Yeah. Yeah. So it'll be hosted on our domain. You'll get a subdomain of total site. If you then upgrade to paid tier, then you can add your own domain And also remove our little branding logo on the bottom of the app. 

DAN: So, purchasing is a, let's call it the premium plan, basically gets rid of the on-page advertising and gets you your own domain. That you can basically, I purchased a domain somewhere and I can associate it with the total website that I've built.

ANDREAS:  Exactly. 

DAN: Anything else that I can purchase?

 

ANDREAS: Well, so we have different plans. The initial startup plans are for, we sort of priced that quite low at $20 per user. And the idea is for small startups to get started and start building in total. 

DAN: So wait a minute, it's $20 per user, not per website or something like that? 

STEVE: No, it's $20 per month for up to three users and then you pay $16 a month if you do it annually. 

ANDREAS: Yeah. But that is also today per project. So if you have multiple projects, you need to be, that needs to be on a pay plan. You're paying for each. 

DAN: Okay.

 STEVE: So I have a question. What is the tool set used to build Tottal? What's your tech? 

ANDREAS: Ah, well, that's my favorite question. Because, well, there's quite a few things. Our database is hosted by SuperBase, which is also where we get authentication, a few other. So we're running our whole data off SuperBase. Then we have sort of a backend slash middle backend. I don't know if this needs a new word or have one I'm not familiar with, but we're running on Cloudflare Workers. We use them for two things. We both use them for server rendering applications because obviously we're storing total code, if you will. It's like a JSON format. We store all the data in And that needs to be rendered out as HTML. And we do that on Cloudflare workers. So it's very close to the user always. Um, and Cloudflare is also kind of our backend for the total editor. Uh, so we use the feature they have called durable objects that lets you essentially create a singleton instance of a data store where you can in memory store a lot of information. And then you can connect to that with web sockets And it kind of has this property where there can only ever be one instance of that globally. So when you create a branch of your project, you connect to your instance of the server, which in memory keeps all the files up to date. So that means we can get things like live collaboration going by just having people write to that. We can actually solve a lot of concurrency issues by having the server close to people and not and just saying, well, the latest, the latest right wins because there's never more than a few milliseconds latency between the user and the durable object So that's sort of the back end part. All of the front end, the whole editor, our website, our blog, everything is built in total. So we built the whole project in the project itself.

AJ: Nice. 

DAN: That's very cool indeed. So you mean all the complex logic of the editing process and whatnot, all of that is actually done in your visual programming language. 

ANDREAS: Yes. from like the left panel sidebar where you're showing all the element trees with all the different nodes and all the drag and drop interactions of those. The formulator where you can space pan around and zoom in and out while also editing these nodes that are lining themselves. Everything, everything is built in total of that project.

STEVE: So I think the correct phrase is that you're eating your own dog food. Is that correct? 

ANDREAS: Ah, it's such a negative term though, isn't it? But yes,

AJ: I Dont think so.

ANDREAS: I think that's have you had dog food? 

STEVE: Well, judging by some of the ads I've seen as a newer dog foods, it might not be so bad anymore.

ANDREAS: Okay. 

STEVE: Good quality stuff out there. So it depends on what you're eating, I guess. 

This episode is sponsored by Miro. I've been working lately on a whole bunch of different projects for top end devs. Everything from meetups to courses to podcasts to the website and A lot of the things that I've been working on have gotten really, really messy. And even though I have some software that helps me manage the projects, one thing that I figured out was that it really helps to have a tool that you can use to manage kind of the layout and the organization of your project, not just whether or not tasks are being done. And so I picked up a program called Miro and Miro what it does, I'll just give you an example. When I'm building a course, I sit down and I open up their mind map and I just put all of the information into the mind map And I'll do that for probably anywhere from 15 minutes to an hour, just depending on what it is that I'm organizing. And then what I can do is from there, I can actually reorganize it and rejigger it so that it actually makes sense. And it really, really helps me get all of the ideas on paper or on the screen in this case, and get an idea around how these things come together. So if you're looking to put together a project or organize some ideas, you should definitely check out Miro. You can find simplicity in your most complex projects with Miro. Your first three Miro boards are free when you sign up today at Miro.com slash podcast. That's three free boards at Miro.com slash podcast. 

Fellow devs, if you're like me and tired of missing important alerts when your application crashes because you have hundreds of emails in your inbox, alert fatigue is real, but none of us can afford to overlook critical errors or crashes because of a noisy inbox. That's why you need to check out Raygon crash reporting Now integrated with Microsoft Teams and Slack for alerting, you can set up thresholds for your errors based on an increase in error count, a spike in load time, or new issues introduced in the latest deployment along with custom filters that give you even greater control. Assign multiple users to notify the right teams with alerts linked directly to the issue in Ragon taking you to the root cause faster. Never miss a runaway error. Make sure you're quickly notified of the errors, crashes, and front-end performance issues that matter the most to you and your team. Try it in RayGun alerting today, create a world-class issue resolution workflow that gives you and your customers peace of mind. Visit raygun.com to learn more and start your 14-day free trial. That's raygun.com.

DAN: But it definitely highlights the fact that, you know, this tool is powerful. I mean, if you're able to build TODL, then anything that the user might want to build is probably covered.

ANDREAS: Yeah, I would say I've been working on a lot of projects. I used to do a lot of contracting. I lived in London for like six years and jumped company every six months because when you're young, that's really fun. And I've been working on anything from small startups to like enterprise companies. And I don't think I've ever built anything as complicated as a no-code user like this. This is in pure complexity. This is by far the worst because there's so many things You only ever work with recursive data structures, right? That's the only, everything's a tree. Everything's like recursion. Everything is like trying to figure out how, how does it work when you have like 500 components on the screen at the same time, because these editor interfaces are very complex, right? 

DAN: Yeah. I know.. I know, I know what you mean. Uh, as I said, I've worked at Wix, I've worked on the Wix editor. The Wix editor is a huge applications. One of the largest I've ever worked on. It is actually implemented in react. Uh, and it's, uh, hundreds of thousands of lines of code. Um, but to be fair, Wix actually does a lot of dog fooding as well. So the editor is built on native, but a lot of the uh... interfaces there are built using Wix and I think that the same is true for Webflow and I really dig this approach because it really shows that you're serious about the tool you're building when you're able to use it for that sort of a thing but it does bring me up uh.. bring me to another question when you start thinking code you start thinking version control. How do you do version control in total? 

ANDREAS: Well, so that was one of the things I had a lot when I started this project was that there's all these There's all these different things that needs to happen for this to work. And when I say work, I mean work for me. Right. You can build a version. You can build a no code tool that lets you do version control. And most of them have some version of that. But it's usually the live version and the development version. Right. And I mean, I'm coming from teams of like five, if it's a small team or 20 people for last teams and like that is never going to work. Right. And live collaborations, all cool, but the reality is we don't use it very much because people work asynchronously. So you need essentially something like a Git style version control. If you want to be able to work in a team and like we're a small team at Tottle, but we're still pushing like new features all the time and we're working asynchronously. Unfortunately, Git is kind of tied to lines of code. So Git wasn't really an option, or at least I couldn't find any way to make that work based on a different kind of diffing, but you need a different diffing algorithm when you're working with a JSON data structure compared to just lines of code. So we had to build our own and we actually build it in a procedural our database so that we could essentially store all our files. So when we're storing files in SuperBase, we have a table called blobs, which is stolen exactly from Git. I spent like a couple of months trying to figure out how Git actually works. Like going around looking up, looking up like little hash keys and how do I Git LS all these things and Git Kat or whatever they're called, to try and figure out what is the actual storage model and how does this work. And then replicated like probably 3% of that, which is a lot, because Git is massive. But it's the same basic concept, like all files are stored based on the hash of their content so that you can store these snapshots all the time of your files without actually but you don't have to double write files that hasn't changed. And since we don't actually ever do like users never do a manual commit, what we do instead is that every time you save, we basically start a throttle commit timer. So it automatically commits every 10 seconds if you're making changes. And then every one of these becomes a snapshot in the database that has a reference to these content index files.

DAN: It's interesting because a few episodes back we actually had, I forget his name, I'll remember in a second, the guy from Bit.dev. It was Gilad Shoham from Bit.dev. And they also kind of have their own substitute for Git for a different reason. Even though there is a certain amount of similarity in a sense. But it's interesting to see people coming up with Git alternatives effectively for various reasons. Although I'm not sure the term alternative is the correct one, because you're not coming to a regular project and saying, hey, use this instead of Git. You're using Git for your own very special use case, which I appreciate.

ANDREAS: Oh, I mean, if I could have used Skid, I would absolutely have used Skid. I would not have gone down this road if I had an alternative, right?

DAN: But you still have the possibility to go back to a previous revision or version, or maybe even do something like a diff between, you know, or bisecting or stuff like that. All the good stuff that people associate with visual editing. Not visual editing, with source control, I mean, sorry. 

ANDREAS: Yeah. We have a somewhat limited set, like obviously we're not implementing all of Git. So we've made some high level decisions that at least for now seems to work just fine. So it's always trunk based. You're only ever merging out from like branching out from the main branch and only ever merging into the main branch. Right. And that sort of lets you push real quick, like frequently. And that seems to work just fine. That was kind of similar to the workflow we used to have when working in code as well. So for now, we're doing some shortcuts compared to a full Git setup, right? 

DAN: Yeah, by the way, it is worth mentioning that Linus, Linus Torvaldus actually wrote Git in like a weekend. And so people, you know, people know him for Linux, but maybe they should know him for Git. 

ANDREAS: It took me longer to copy it than it took him to write it then. 

DAN: Yeah, he basically was committing git into git by the beginning of the week or something like that. Yeah, it's an interesting story. He's quite the guy. Yeah, so how big do your flow charts get?

ANDREAS: Well, interesting the flowcharts, which is sort of in us the action part. They never get very big. I think. The biggest we have is something like 20 nodes or so. Like they're not they're not that complex. And that's because, again, we all the actual computation logic is moved into formulas. So we have this separation. But the actual steps is like, if this then do that. Each of these workflows are like oneaction happening when you for example you click a button. So if you end up taking a look at like let's say your react code and go well how many things am I doing when I click this button? The reality is you're rarely doing that many. Most of the lines are in order to compute a value and then some of them actually are invoking side effects. So the flow charts are usually quite small. We actually in our UI, we actually have a very small window initially dedicated to them because that sort of sits on top of the editor. Because most of them are just two or three actions in a row, or even one is the most popular, right? Most of the time, it's just when you click this button, do this one thing, or do these two things, or these three things. And so most of them are really, really simple. The more complex one, again, it never gets out of hand for them. Formulas are kind of a little bit different. We have some formulas in total that are definitely not small. But we also have the options of like, you can go and say this part of the logic, I can extract that insight into what we call a component formula, and then essentially give it a name, right? So you have all the same, just like you wouldn't write all this in one function in JavaScript, you can do the same in total. So I'm gonna extract this, assign that a name, so this thing is manageable. 

DAN: And so effectively you only view one flow chart at a time, really, correct?

ANDREAS:  Yeah, yeah. 

DAN: So a quote unquote program might have a lot of flow charts in it, but each one of them would be small. And you only view each flow chart by itself. But you can nest flow charts by associating flow charts with functions. 

ANDREAS: Yeah, we don't really have anything we specifically call functions We sort of functions are divided into actions and formulas. 

DAN: Yeah, I mean, I meant formula. 

ANDREAS: Okay, yeah, 

DAN: Yeah, by the way, so a question about that. I mean, over the years, there has been a lot of research into visual programming. Most of it, by the way, from what I know, kind of failed. Uh, there, there have not been a whole lot of really successful visual programming environments. You might say that small talk was, was a visual programming environment and that it succeeded, but it was actually based on code. Um, and, and actual, and actual solutions, like you mentioned one that was like for, for kids, uh, I know that there were a lot of attempts in that area. So, so. My two questions, I guess, are how did you come with your own unique model for doing it? Is it based on research or just your ideas or what or things that you've read elsewhere? And why do you think yours will succeed where so many previous attempts have effectively failed? 

ANDREAS: That is a good question. And it's very, very true that this is a Like visual programming is not something where most programmers go, oh, that's definitely the future. Because it's very definitely the past, right? And I think it's been fun when people come along, oh, this is brand new. You've got to go. The earliest example I've found is 1976. So it's not that new. It's before we had visual operating systems, the first visual programming language was created So there's nothing new about it, right? It's very much an elephant graveyard of a technology choice to get into. But I think I at least have a theory as to why the other languages failed or why this never really made it anywhere. And essentially whether I'm right or not is probably gonna determine the success. But my theory is that When you take a programming language and then translate it one-to-one into a visual programming language, which most of the attempts are, right? Sketch is also a good example of this, which is the one I mentioned earlier. When you try to do it one-to-one, what you end up with is a programming language that takes up a lot more screen space than code. And so, and Total has the same feature or problem depending on your perspective, right? it takes a lot more space on screen for something that like what would essentially be like four or five lines of code will take up an entire screen in total. And if you start then going through your code and saying, well, if I needed an entire screen for every four or five lines of code, it's very clear why that's not a particularly good setup, right? So the trick to visual programming...

DAN: I'll interrupt you for a second just to make it clear for our listeners why this is the case. One example that I saw in your demos was the simple if statement that in code if is literally like four lines of code if condition you know then something else something else so that's literally like four lines of code and in your case it's a box and a line and a box and a line. So obviously all that visual representation takes much more screen area than, like you said, than just four lines of code. 

ANDREAS: Yeah. And it's kind of the same thing as with code. If it fits on the screen, it's a lot easier to understand than if you have to start navigating, right? Once functions start to not fit on a single screen anymore, they start to get a lot more complicated to work with. It's not the only dimension, but it's a pretty good indication And the same thing is true for visual programming. So if you just translate code one-to-one to a visual medium, you'll just have a, like, you'll do a lot of panning all the time. And that's the worst possible way to find anything, right? That's never gonna work. So the trick is, the trick at least what Toddledoz is always to try and say, when can we break this up into smaller parts that are easy to navigate? And because we sort of broke up at like the actions workflows and the formulas here, it means that normally one workflow with 20 nodes might have been massive, right? It might have been take up like a hundred screens or something, maybe not quite, but something along those lines, right? Because it just takes up so much space. But because you're navigating this visually and quite effectively, you don't have to look at all of it at a time. So you get to sort of break your program up into smaller bits and really easily navigate to the part of your code or visual code in this case that you need to work with. And that kind of lets us get away with using a lot more space for all of it because the tools we've given you to navigate your code, if you want to say like, or your app, are a lot more efficient.

DAN: Interesting. And again, it has to do with the fact that you never seeing the flowchart as a whole, it's never list this one big flowchart. It's always a specific flowchart that's associated with a particular event leading to a particular action. Let's say, uh, through, uh, some formulas. 

ANDREAS: Yeah. 

DAN: And, and I guess also the reactive aspect is also a big help here because again, you split things and at the reactivity boundary. 

ANDREAS: Yeah, for sure. I mean, in terms of it's not entirely something, I mean, nothing is ever something you invented entirely, right? It's always based on a hundred other things. There was a lot of, as you probably heard already me talking about functional programming, I think I took a lot of inspiration for that paradigm. Exactly because it does make this hard split between what is in functional programming pure and impure. It's a quite nice and quite sensible way to divide your program and actually saying okay when if I separate it into what is an action what is the side effect and What is not this this it sort of becomes a nice logical boundary To split your program down and that's a big part of why it works quite well 

DAN: And actions I assume always work as if they're synchronous, correct?

ANDREAS:  Yes, but an action can emit an event

DAN: But if, for example, it's downloading data until you get the data, you won't proceed to the next step. 

ANDREAS: Yeah. So when they're listed sort of underneath each other in an action chain, they're executing synchronously. And if you want to wait for something, right, that action can then say, I'm going to emit it eventually. And then you can start a new workflow off that.

DAN: Okay, cool. So it's really, as you said, you were inspired by various things, but it was really your own invention. 

ANDREAS: Yeah, I mean, it depends on how much you're inspired, I suppose. It's definitely a new take. It's not entirely original. You can find a lot of examples of products and different kind of visual programming that are very similar in many ways, but I hadn't really seen anyone do it in the same way for solving the same kind of problem.

DAN: So really I have two more quick questions. One is what's your solution for authentication? I mean, if you build TODL with it, then obviously you have, I think you mentioned that you have authentication built in, but does it mean that also if I'm using TODL for my own app, I can integrate authentication into it? And the second question is, is any part of it open source?

ANDREAS: Yes, good question. I'll take them in the order given then. So the way we handle authentication is that because we are front-end only, we don't technically handle authentication, right? Authentication kind of has to live with your data, right? Because that's what you're authenticating and essentially limiting access to. So authentication is very much a backend problem. What we've done is essentially create a simple way for storing an authentication token as an HTTP-only cookie. And then we have a proxy layer, also on Cloudflare, where you can proxy API requests too, and we can essentially just smack that token onto it. So let's say you are making a request for your API, and for that to work, it needs to have a specific user token as an out header. What you would do in Todl is essentially you would first authenticate through your service and then either come back to Tottl via redirect or you might be like username password login and then get a token back and then you'd essentially tell Todl to store that token and we'll store it as an out token and that'll be stored in an HTTP only. So there's no even if there's foreign scripts on the site they're not going to be able to sniff that out because it's never actually sent back to the client again. And then when you're making an API request from Total, it first goes through our Cloudflare Worker. And there you can then configure to say, I want to add this token in as authentication for this request. And then that'll make the authenticated request and come back with the data.

DAN: So you're using the Cloudflare Worker as a sort of a segregation layer in this context. You're offloading what needs to be secure off of the front end into the Cloudflare Worker, where third party code can't access it. Interesting take. 

ANDREAS: That was not actually the point of doing that. It's just I really hate course issues. So that's kind of that was the original point of saying, if I just add a real simple proxy here, I never have to deal with that again. And that sounds very nice. But actually authentication became a really nice added solution there. And I think we're sort of looking at Can we build some more interesting... Like right now, we cache response based on the server-sent cache header. But we can see a lot of cases where it might actually be nice to be able to override that locally and say, I know the server said you can only cache for this long, but actually I would like you to cache for just a few seconds or set some stale-vibe and validate for extra performance. So it sort of adds on a lot of benefits that we can also tap into down the line.

DAN: Cool. And about the open source part? 

ANDREAS: There's nothing right now that is open source. We are talking about it. I'm not quite sure. The main reason why it's not open source is actually just that we thought it would take longer to develop in public than private. And the other bit is we're quite tied into Cloudflare at this point, right? There's quite a lot of our techs that just build on Cloudflare. And I think we're probably going even further that way because there's a lot of the technology that just kind of fits really perfectly with this. 

DAN: Well, you know, there's an interesting argument going on happening currently about how tied to Vercell is Next.js. And that's like kind of the quote unquote epitome of open source development environment. Yes, it turned out turns out At least that's what, uh, for example, uh, um, Kent wrote in his, in his critique that it's a lot of it is tied to herself services, but you know, it is what it is. 

STEVE: For those of you who's being at home, that is epitome. 

DAN: Yeah. Epitome. Sorry.

AJ: It's okay. I said it epitome for a long time too, because you read it and you never hear anyone say it. 

STEVE: Did you also say fake aid instead of facade?

AJ: No, but I said subtle when I was in third grade or so I said subtle 

DAN: Before we wrap up because we are really approaching the end of our show Is there anything else that our listeners really need to know about? Total, you know additional things that are worth mentioning

STEVE: Yes, I would like to know where the name came from myself. If you have like little toddlers running around at home or what was the, what were you trying to emphasize with that name? 

ANDREAS:: I do, well, I don't actually have the toddlers right now. I've got a six year old and a three months old. So I've got on either side. But well, the name is, my wife came up with that. I am not sure I entirely understand why it's called Tuddle But when she suggested it, everyone liked it. And eventually I sort of felt powerless to do anything about it. And now I've kind of grown to like it. It's sort of just become, when you name something long enough, right, eventually anything else sounds weird. 

STEVE: Annie Morris, the epitome of a great name. I mean, epitome, sorry.

AJ: It is. So while we've been I've been playing around with this thing and I got into the calculator app because I figured, okay, that's going to be simple programming. I'll be able to understand. And I actually don't, I fundamentally don't get how this is working. Like somewhere, well, I guess I'd have to go through the tutorial, but I just opened up the example app and I go and I click on the equals button. And I look at the click action and I can see there's the flow chart just going down. And it, and it sets result to zero, which seems weird. Cause I'd want it to set the result of whatever the previous operations were put together, it sets the operator to nothing. And then it sets the current value to zero. That's not my experience. When I click on two plus two equals, I get four, not zero. So is there, um, how, what's, what's the paradigm here or the thing that I need to know to make this work from a brain?

ANDREAS:  I think this is less of a total thing and just like I had a really weird idea in my head about how the data model for calculators should be.

AJ: Oh, okay. 

ANDREAS: But it's essentially, it's sort of evolved because I wanted that additional features a lot of calculators have when you keep pressing equals. Like there's a lot of ways when it sort of repeats these things. I ended up doing a few versions of that, and I think this was what I came up with, was a smart way of, in a relatively minimal way, to store this. But yeah, I don't think that it's not so much the total thing as it's just, I mean, I would have probably done the same thing in code had I been in the same mindset at that point. 

AJ: Well, I see where it sets the variable, but I don't see where it actually carries out the actions. Like where is the logic stored in this thing? 

ANDREAS: So the logic is usually stored in the formulas, right? 

AJ: Let me,

ANDREAS: that's usually where you compute the values. 

AJ: Let me check and see. Cause I don't, I don't see it but..

DAN: until AJ finds it, anything else, Andreas, that you want to mention about TODL? 

ANDREAS: Yeah, I think one thing that's because we've been talking very much developer focused on this podcast, but one of the really nice benefits of TODL, and actually one of the main things that we found out we were solving here, is that in a traditional setup, especially when you work on the front end, we sort of end up having like an assembly line of usually a product manager that feeds the idea for a feature to a designer that then builds a design and feeds it to the developer that then goes to a QA. And then all of this goes back and forth in certain circles, depending on how many people get back in the iteration. It rarely ever goes once. And even though we do say agile a lot, and we love saying agile, all of us, I think, it's still kind of an assembly line, right? It still kind of follows this brokite. And one of the things we really found about Tottal that was quite unique is that everyone in our company are building in Tottal. So my co-founder is a designer and he's not, I mean, he's now very capable in Tottal and can do quite a complex logic, but he doesn't like to do it. So he rarely does. He'll just work on the design and the fact that we can build in the same platform and it's not like a handoff where he first does all the visual design in Figma and then shows me a picture of an UI and now can you go and build it from scratch, right? But actually, he'll just build it. And if he needs help with the logic, I can step in and fix that. Or I'll build something and it'll look absolutely horrible, which actually happens a lot. And then he'll just go in after and make it look like what it should look like. The fact that we don't have to work in serial but can work in parallel for this has been an incredible speed boost. And it's not just us, like our new head of marketing is like building our partnership platform in total, because he didn't want to like we were doing other things, right? And this was important. So it was better. He just did it.

DAN: It's an interesting point here. There are a growing number of solutions out there that are implementing some mechanism of taking Figma and translating it into code. So that step seems to be, I wouldn't quite call it solved, but much easier than it used to be. So it's much less about the process of here's a Figma drawing or whatever. Now recreate it in code. You can get the initial code very often these days, or at least something that you can start from. What is missing from my perspective. And I think the total is a very interesting solution here is the other way around. I mean, that, that. Figma to code is kind of a one time thing. You can't really take the code and the changes you've made in the code and then take it back into Figma. And so it's like one shot. And if the designer then wants to make a change, the process needs to kind of happen again in a lot of ways. Or it becomes a very manual process then. And what's really great about the solutions like Podl is that they kind of, you know, this throwing things over the wall doesn't exist. It's the single tool that handles the entire flow. So yeah, for sure, I see a lot of value there.

ANDREAS:  And it's not just designers, right? Like if a product manager goes in and says, like, why on earth is this text there? This is not descriptive. This doesn't make any sense, right? This is the worst way of explaining this feature. They can just go and fix it, right? And it doesn't break everything. It's not going to automatically not compile because they're changing text or they're changing an image. And that's really easy to do. So like a lot of time making a change in Total is as easy as making a Jira ticket for that change. And then you can just not do that. And that the amount of speed and velocity you get from that is like unlike anything I've seen before. And Total right now is a five person company that are building a local platform or a visual development platform for building this, right? It's not an easy problem to solve. And the reason why we can do that is because we can be incredibly efficient with our time by actually using Total to ship this one.

 

 Hey, this is Charles Maxwood. I just wanted to talk really briefly about the Top End Devs membership and let you know what we've got coming up this month. So in February, we have a whole bunch of workshops that we're providing to members. You can go sign up at topendevs.com slash sign up. If you do, you're going to get access to our book club. We're reading Docker Deep Dive and we're going to be going into Docker and how to use it and things like that. We also have workshops on the following topics and I'm just going to dive in and talk about what they are real quick. First, it's how to negotiate a raise. I've talked to a lot of people that they're not necessarily keen on leaving their job but at the same time they also want to make more money. And so we're going to talk about the different ways that you can approach talking to your boss or HR or whoever about getting that raise that you want and having it support the lifestyle you want. That one's going to be on February 7th, February 9th. We're going to have a career freedom mastermind. Basically you show up, you talk about what's holding you back, what you dream about doing in your career, all of that kind of stuff And then we're going to actually brainstorm together, you and whoever else is there. And I, all, all of us are going to brainstorm on how you can get ahead. Um, the next week on the 14th, we're going to talk about how to grow from junior developer to senior developer, the kinds of things you need to be doing, how to do them, that kind of a thing. On the 16th, we're going to do a visual studio, uh, or VS code, uh, tips and tricks. Um, on the 21st, we're going to talk about how to build a software course. And on the 23rd, we're going to talk about how to go freelance. And then finally, on February 28th, we're going to talk about how to set up a YouTube channel. So those are the meetups that we're going to have, along with the book club. And I hope to see you there. That's going to be at topendevice.com slash sign up. 

DAN: Okay, I think we are more or less hitting the end of our show. So before we go to pics, if people want to contact you, Andres, to, you know, learn more about Total, try it out, discuss your thoughts and ideas about no code and stuff like that. What's the best way to reach you and discuss these things with you? 

ANDREAS: So they can definitely find me on Twitter. I'm quite a lot on there. My Twitter handle is Colorfit, which is a character from the Hitchhiker's Guide to the Galaxy, but I spelled his name wrong. So maybe we'll add it in the notes somewhere. But they can also find both me and everything about un-toddle.dev. There's a lot of links to both Twitter and social platforms. 

DAN: And maybe we should have set it up. T O D D L E dot. 

ANDREAS: Yeah,

DAN: yeah, obviously it will be in the show notes and the episode title and what not. Um, okay then I think it's time to push on into pics. So Who wants to start? AJ, you want to go first this time?

Sure. Okay, let's see. What have I got to pick here? Um, I watched the movie A Man Called Otto with Tom Hanks, and I have mixed feelings about it. 

STEVE: You and me both. 

AJ: But so it started out so hilarious. And then about halfway through the movie, it kind of switched from being a comedy to being The message. And I, it just, I, yeah. And then I started to feel like I was getting preached to. And so the ending, I just felt like they've ruined it. They, they had such a strong comedy and then, but they had to make sure that I got the message. It could have just had the elements that they had without explicitly telling us that, you know, men are stupid nitwits and you know, like.. Like it just, it got weird. It got weird somewhere between half and halfway through and three quarters through. And, um, but I think I'd still recommend it because the first half was so good. I just, I mean, just the opening scene was comic gold, comic gold. He's buying a length of rope. 

STEVE: Oh, right. 

AJ: At the hardware store. And, uh, They won't sell him five feet of rope because the computer system doesn't have a way to, it's just, yeah. And he's like, you mean to tell me the computer can't do math on five feet? Anyway, it just, so for me and being a grumpy old man myself, I just, I loved it. It was, it was just so good. Um, and until he got to the part where he's got a really weird relationship with his. a neighbor who is married and has a husband and yet he and her going on dates and it.

STEVE: I didn't see it that way. I thought that part was pretty good. 

AJ: Oh, okay. 

STEVE: But yeah, that scene in the store reminds me of the father of the bride of Steve Martin where he goes to the store and he's raging about how there's so many buns in a hot dog package, but you know, there's more hot dogs in a package than there are buns in a package and he's taking out and gets thrown in jail because of his rampage at the store. 

AJ: Yeah, so that that anyway, so I still recommend it. I just I just wish they would have just kept the comic tone the whole way through rather than switching over to just I don't know whatever it was towards the end there. But but then let's see, other than that, I had something.. had something I was gonna pick and I don't remember what it is. So we'll um We'll uh The i'll pick the super mario brothers movie as well. Oh, no, wait, wait, there was uh the prime again What he did something? Oh now I remember jonathan blow. So the prime again Primogen primogen primogen I keep on saying it wrong. I'm sorry about my my apologies to the the prime, um He he I watched a video of his where he did a reaction to Jonathan blow, but he didn't actually watch the full Jonathan blow video Jonathan blow is another crotchety old man that I would just get along with swimmingly. I am sure and his uh his talk the full one was Uh that the snippet was being reacted to is called preventing the collapse of civilization And there was some pure comic gold in this as well But he talks about how we have all these records of civilizations with ancient mysteries that we can't unravel or we know a Process by which it works or how it works, but we don't know how to reproduce it And he talked about how software engineering Maybe in one of these peaks of civilization Before the decline where the wisdom of the ancients is lost And then people aren't able to, to, uh, you gotta watch the talk actually. And I'm not doing it justice and I'm making it sound probably more complicated and stupid. Uh, but it was super entertaining, great history lesson and, uh, some good laughs. And, uh, now, now I've been watching some of Jonathan blows other stuff and he's based as they say, so Jonathan blow.

DAN: By the way, people are saying that, you know, archeologists are saying that our age is, our era is very problematic, that we're probably not going to leave any records behind because everything is digital. So, you know, in a thousand years, there'll be nothing left that's readable or accessible from this era.

AJ:  And that's what kind of makes us think, you know, maybe the Egyptians did have supercomputers. Maybe AI generated the pyramids. 

DAN: Yeah. Okay, moving on. Steve, what about you? 

STEVE: Let's see. I actually have a couple picks before we get to the high point of the episode, which is my dad jokes, if you didn't know that, Andreas. So first of all, AJ made a comment that reminds me of one of my favorite XKCD cartoons called Wisdom of the Ancients. Uh, and I think about it often. Um, and it basically shows, uh, it says never have I felt so close to another soul and so helplessly alone as when I Google an error and there's one result, a thread by someone with the same problem and no answer last posted in 2003. And it shows the guys shaking his computer monitor It's Denver coder nine actually.

ANDREAS: Where were you Denver Coder 9? What did you see?

STEVE: And I have I've actually used that comic in the past like Where I have posted a question like on Stack Overflow and never got an answer and I'll come back and say In order to avoid being this guy and put a link to this cartoon and then I'll you know provide my answer so It's a great cartoon. It's not quite as good as nerd sniping or Bobby tables in my estimation of XK CD cartoons But it's one of the best

ANDREAS: those are the classics

STEVE: Or the pseudo, pseudo make me a sandwich. That's the other one. Anyway, and then a definite high brow piece of something to pick is an ad I happen to see on Twitter. Normally I can't stand ads on Twitter and just skip past them. But this is a very effective tool made by a company called, I don't know how you say it, Brezik, B-R-E-Z-K. And it is a fart machine toy rubber. It's awesome in that each little thing you hold in your hand, you squeeze it and you can understand, guess the sound that it makes, but looks like a very amazing tool and only 13 bucks. 

DAN: So anybody's got that ad wasn't tempted. 

STEVE: Oh, I was so tempted. Well, it's funny. It reminded me also because I got had a white elephant exchange at my gym here recently within the past couple of weeks. And one of the thingsthat I gave as a toy that somebody else got was a whoopee cushion. So that tells you all you need to know about my humor. Anyway, now to the- 

DAN: Talking about your humor. 

STEVE: Yes, speaking of my humor, the dad jokes of the week. And this is a Christmas themed question. What do you call a broke Santa Claus? Saint Nicholas. Oh, by the way, I did figure out how to upload sound effects. I just got to get it done. So I will have the rim shots back for those who enjoy that. Number two, a Roman walks into a bar, holds up two fingers and says, I'll have five beers, please. You know, five. 

DAN: OK, OK, that's a good one. 

STEVE: If you've ever seen Mel Brooks, history of the world, part one, you know, he's got all the visual gags throughout all his movies like this. And there's one of them is the X and B tent, the X and B sent store.

DAN: know the five and ten remember is that it's good to be the king 

STEVE: yes 

ANDREAS: it's good to be the king

STEVE: I think Patrick Stewart used the same thing in one of the rock in Robin Hood men in tights when he kisses made Marion it's good to be the king and then finally question so how can a room full of married people be empty because there's not a single person in it. Anyway, those are my picks.

DAN: Okay, so now it's my turn before we hand it over to you, Anderson, Andrea, sorry. So if you have a few moments more to think about what you wanna pick. So I usually pick something about the war in Israel and Ukraine and depress everybody. So instead, I won't talk about it that much. I just mentioned that I tweeted something in kind of a relation to that, which is one of the, my tweets that got the most likes ever. I think it got something like nine, 1900 likes, which is a lot for me, which is somebody tweeted that a stupid statement that, uh, uh, that, you know, that Jesus was Palestinian. Now you can be in favor of the Palestinians on this side of the debate. You can be in favor of Israelis. You can in fact be in favor of both sides, which is what I kind of tried to be, especially when I'm in a giving mood. But, you know, don't, don't try to rewrite history, please. You know, Jesus was a Jewish man living in a kingdom of Judea. Yes. 

STEVE: The term Palestinian hadn't even been created yet, wouldn't be for a couple of centuries.

DAN: That's that's kind of true. There was the well, it's not exactly 100% true. I mean the Greeks living there did use the term Palestine or philistine as as a way to refer to the coastal region But the province wasn't called palestine until about a century and a half later Uh anyway, so but you know, so I I I tweeted that and I got a lot of likes for that So whoopi for me about that

STEVE: by the ratio on that tweet was epic, too

DAN: Yeah. Uh, the other thing is that I really liked the community notes feature. I mean, I'm, I'm critical of a lot of things that Elon Musk did, you know, does and did and whatnot, but the community notes are a great addition to Twitter. I think, uh, it, or X or whatever it's called these days, because, you know, it makes a huge difference about these sorts of things and, and in this case as well. I mean, people put You know, after I wrote my tweet, people put a community note in there that basically said something along the same lines. And it's really, I've yet to see a community note, which I really objected to. That's what it this way. Most of them have been really on point. Um, anyway, so, and my final, uh, pick is, uh, we, uh, we watch the series on TV, which unfortunately turns out it's going to, it's going to have this only one season. It wasn't continued, but we really enjoyed it. It's called Lucky Hank. It's with Bob Odenkirk, who might be very familiar from his roles on Breaking Bad and on... 

STEVE: Better Call Saul. 

DAN: Better Call Saul, exactly. I was having like my brain froze. And he plays the department chairman of the English department in this like small college. And it's like a comedy drama and we enjoyed it a lot. And unfortunately, like I said, it's not going to be continued for a second season. But I still really recommend watching this and, you know, we enjoyed it. So those would be my picks. And what. And do you have any picks for us?

ANDREAS: Yes, I do actually have a couple of picks. I think the first one since we had a movie as the first pick, I want to add one in. I just finished watching The Last Action Hero with my wife. Not exactly a recent movie, but you hadn't seen it before. And I got to say, I think that's a classic that still holds up. So that's going to be my first pick. 

STEVE: I can still remember the ads for that when that movie first came out. And they had two voice actors doing spoofs of Stallone and Schwarzenegger. And the one line I always remember for this is more like last action zero, Stallone making fun of Schwarzenegger. But yeah, that brings back some memories.

ANDREAS: Excellent. Just sneaking another dad joke in like that. That's masterfully done by the way. 

STEVE: Oh, thank you. Lots of practice. But I can't take credit because that was actually a line from the ad, but it was still a good one. 

ANDREAS: Fair enough. But yeah, I think that that one still holds up in my book. The other thing is a little bit on topic actually. It's a talk, you can find it on YouTube by a guy called Brett Victor, who is studying different kinds of user interfaces and the kinds of ways we interact with computers. And he did a talk called The Future of Programming. And the whole sort of theme of the talk is that he's pretending to be giving this talk, I think in 1970, something around there. It's actually in like, I think early 2000s, but he's sort of pretending. So he brought an overhead projector on stage and he's changing all the slides and doing the whole thing, playing along. And he's talking about that from this point in time when computers really started to take off. And everybody could see it was going to be the future, but nobody had any idea what that future looked like. He stood there and said, what are the predictions we're making and what will it definitely look like? And obviously, none of those predictions actually ended up being true. But it's a really interesting take both in how many times people couldn't dream big enough compared to what was actually going to happen. But also how many times where we may be settled for something that wasn't what it could be. We could have probably had more, right? Why didn't this happen? 

DAN: The interesting thing about people making predictions is that we generally take what we know and we extrapolate on it. We rarely think about, you know, it's essentially impossible to think about the new ideas. So like when people in like the 50s imagined what our century will look like, they thought, hey, we have cars, we know about planes. So we'll probably have flying cars. But nobody thought about, I don't know, like an iPhone. Because the concept just wasn't there. So you take the ideas that you have and you extrapolate from that. There's a famous story about when semiconductors were starting to happen, prior to that, they had the vacuum tube before they had the semiconductors and transistors. And one of the scientists was actually asked, how small would the single bit get? And he said, as small as possible where you can still replace one when it burns out. Now today, obviously we just take this entire wafer with billions of bits on it and just throw it in the garbage, but he couldn't envision that. So we're kind of stuck in the paradigms that we know. It's essentially impossible to think of an alternative paradigm.

ANDREAS: One of the founders of the university I went to is quoted for saying, flying machines that are heavier than air are impossible. There's a few people that made that quote as well. 

DAN: Yeah, it's an interesting statement. I saw an interesting talk about it where the point of the speaker was that they should have known it was possible because they could have opened the window and looked at birds. If Birds can do it, then it's theoretically possible to build a machine that can do it. Which is his argument why self-driving cars are eventually bound to happen. If people can do it, we can eventually be able to build a machine that does it. Anyway, I think that more or less concludes our episode for today. So Andreas, thank you very much for coming on and explaining TOTAL to us and telling us about it. It's a very, very interesting project and a very interesting take. And I highly recommend for our listeners to check it out. And that's it. Bye, everybody.