Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#84 - Debbie and Wilker Lúcio
17 Plays2 years ago
We invited super cute and fabulous Debbie the Corgi and also Wilker who happened to be in the same room to talk about Clojure - creator of Pathom and EQL!
Check out the his blog on https://blog.wsscode.com/
Recommended
Transcript
Introduction with Dogs
00:00:15
Speaker
So welcome to Deafn. Yes, episode number 84 with me, Vijay, with his border collie, and with Bowie, not a border collie. I think he'll get offended if I don't say his name. I have a name, you know. Say my name. Say my name. And we have Ray with Yula.
00:00:44
Speaker
And special guest today, the Corgi, I forgot the name, sorry. And we need to mention your dog's name. We haven't had his name yet. We haven't got his name. Her name actually. It's called Debbie. Her name. It's Debbie. See? Debbie. It's Debbie. Princess Debbie. Nice. So we have Debbie. I mean, her guy, some dude. I'm just here to bring the dog in the scene. Don't mind me.
00:01:13
Speaker
So welcome, welcome, welcome to Daffan. You've got to give him his full name as well, you know. Yeah, that's true. So, um, yeah, welcome. Welcome to the, welcome to
Recollections of Dutch Clojure Day
00:01:23
Speaker
the show. Uh, yeah, as I was just saying, it's been a long, long time since we saw each other as well. So what's happening with you and where are you right now? Well, before that, what about, what about the, uh, where you met him? Was that.
00:01:36
Speaker
Yes, we met at Dutch closure day because he gave a talk about a pattern at that time. Yes. In Amsterdam. Yes. I think it had a different name. I can't remember the name of my talk right now. It's okay. It's there on the internet. I'm pretty sure.
00:01:57
Speaker
It's people that are more important. I must have missed that, must have missed that episode. I thought I went to all every Dutch closure days, but I don't remember the, uh, the pattern talk. So God damn it. It's me. It's being alone. Yeah. It's a great excuse to go through the Netherlands implementing graph APIs with closure. Yes. This was 2018. Yeah.
00:02:22
Speaker
Yeah, it was 2018. Oh, no, I do remember that talk. Yeah. Yeah. It was, uh, it was a good one. It was lots of details. It wasn't about GraphQL mostly. Yeah. No, yeah. I had my comparisons because back then, like GraphQL was a bit edgy. So if I want to get something closer that people can rely on,
00:02:45
Speaker
Was that a joke, by the way, that GraphQL was edgy? It was edgy on the graphs. It doesn't matter. Okay. Now it's a bit naughty. Yeah.
00:03:02
Speaker
But it's been, yeah, when, I mean, it's not, it's not that long ago. I mean, 2018 is, but you know, thanks to the pandemic, it's like 20 so long. Yeah, exactly. Yeah. I think 20 and nothing as well, isn't it? You know, one of the dog owners in the park today, we were talking about stuff and he was like, Oh yeah.
00:03:22
Speaker
It was a year ago when the beginning of the pandemic, and it's like, no, it's two years ago. It's like, shit, you know. I think everyone feels like that, you know, that it was just a year ago, but actually, yeah, it's two years and you've got to like, like, you know, touch yourself to realize, God, you know, time has really passed, you know? Yeah, yeah. Anyway, yeah, it was in 2018, I think. So what have we up to, Wilker? I think we should talk about, where are you based, by the way? Are you still in Brazil?
Comparing Healthcare Systems
00:03:51
Speaker
Yes, I am in the center of Sao Paulo here, still. Yeah, and they were called Moema. And yeah, I mean, right now I'm working in a company called Pippo Saoji that's, we sell, have insurance for companies. So it's a business B2B thing. And working with Closure and trying to get better in your planes.
00:04:18
Speaker
So is Brazil like America then? You have like health insurance. You don't have like a health service, like a government health service. We have that too. We have some public things, but it's very common, especially in companies to have private ones as well, because that is easier to get like better consultations and exams. But if you don't have, there is a public option here, a public free option. Yeah. Okay.
00:04:45
Speaker
And that's actually, for example, in my hometown city, because I'm not from Sao Paulo, I'm from Mississippi.
00:04:51
Speaker
Like the hospital, one of the public hospitals there is actually one of the best. Like if people get really bad situation, could be, or I mean, some sickness or even somebody got shot or something, they are the best. Even if you have private, they usually go there first, just for the first attendance, you get like to don't die. And then if they have conditions, they get transferred after to some more comfortable place.
00:05:18
Speaker
Okay, so it's kind of like, like, make a hospital more like a hotel, this insurance. Yeah, as well. But in the day to day things is better to use it, right? I was talking a lot more extreme case Google there. Okay, say that we have that this public hospitals have very good doctors for like this emergency stuff. Like very emergency. Yeah, very urgent stuff.
00:05:46
Speaker
So it's not like the US then. I don't think there's any public insurance in the US, right? No, it's not. I think in the US you have to pay anyway, right? I think there are public hospitals. No, I mean, come on. There must be. Wasn't that a big series in the US? Sent something or other. Sent elsewhere? There was a big TV series called Sent Elsewhere. I think if you have to go to the hospital, they will assist you, but then they'll send you the bill.
00:06:15
Speaker
Oh, okay. I thought there were public hospitals, but they're kind of like...
00:06:23
Speaker
run down, not exactly run down, but overwhelmed. I'm no expert. Things may have changed. The most complicated thing that I hear from American friends and American friends, please ping me if I'm wrong about this, is that there's a complexity around what is in the plan. If you have an insurance plan,
00:06:45
Speaker
then it's difficult to know which doctors or which medical conditions or which particular aspects of your health care are covered by the plan that you have, which seems mental to me. It just seems like it seems like completely a crazy idea that you can't have insurance and just say, okay, right now, just treat me please in the best possible way.
00:07:08
Speaker
Because I get all my knowledge
Automating Insurance Processes
00:07:11
Speaker
from the Twitter or feed. Oh my God. Probably citations and everything, fact check. Anyway, somebody was tweeting a thread about the US medical system. So even if you go to a hospital where everything is covered in the insurance, the doctor might not be covered. Oh my God. How crazy is this?
00:07:34
Speaker
Yeah. So they're listing out like all sorts of waste, like how, um, how many ways, like ambulance is not covered, for example. And that's run by a different company. So that's my part of this one. And the insurance people can say, Oh, why did you use this drug? Because we are only going to pay 80% of the other drug and your doctor prescribed this drug. So we are going to only pay 50% of it.
00:07:57
Speaker
So it's, it's, it's a fucking maze, you know, the whole trend was. Yeah. But is that like, is it like that in Brazil or Volca or is it more like, uh, like your kind of essentially queue jumping, if you'll go private, you know, I think like there is a, I see a trend that is gagging more in that direction. Sadly, it doesn't used to be like that used to be like, I just pay for a plan, which is relatively cheap. And then you get everything.
00:08:24
Speaker
Right now, those plans to exist, but they're getting more and more expensive. They are creating over time RMR, this specific stuff, like you are just saying. So it's kind of sad. Hopefully, hopefully, if we change presidents, maybe we can get started.
00:08:41
Speaker
So, so what does your business do then in that, in that respect, you know, you're, you're selling insurance to businesses. Do you get involved in that kind of like, uh, have to understand all of those options and, uh, complexity? I may, I may, I may have to get you it eventually. Uh, of course I have some exposure because we have to see like all these plans and even to make the quotes and things like that. It's quite a complex process because everything's super menu.
00:09:09
Speaker
So they don't have any assistance. Like they have some, if you are trying to sell for a company that it's up to a hundred people, then they have some automatic things to get the budget, like the value for it. Or if it's not, then you have to send an email for somebody that's going to get the information process for like a week and then send you back another email.
00:09:31
Speaker
And then you have to have many more people to get that because they are not consistent at all. So every company does its own way. Some companies have consistent between themselves. Some companies don't even have that. So it's a bit complicated to inject technology there. So you have to do a lot. So there's a lot of groundwork to be done if we want to really get to a fully automated, efficient system. But trying to move in that direction.
00:10:00
Speaker
So what, how does like, how does closure like fit into that? Are you kind of like using, what are you, what are you exactly are you building? I mean, is it, is it, is it okay to talk about that or is it
Using Clojure at Pippo Saoji
00:10:11
Speaker
a still early days? Or maybe, maybe we should start from, you should start from the, the beginnings. Oh, come on, come on. I asked you a nice question. How did you end up in Brazil? Wasn't he part of the public health system? You know, it's like,
00:10:30
Speaker
We have to get there because that's what you're working on, you know. I mean, we use Closure mostly because this company is founded by an ex new banker. As myself, I actually worked with him on my first team at Newmake. So we believe Closure is good, so we're kind of just using it. And I'm also in the company because it does Closure because nowadays I'd have to have a really, really strong reason to join a known Closure company because I love Closure.
00:10:59
Speaker
Yeah, yeah, it would be weird. Yeah, without parodies, how can edit code without parodies? I don't know how to do that anymore. Yeah, occasionally I've got to dive into other code bases like JavaScript or, you know, or Go or Rust or something or C. And it's, it's a nightmare because everything, you always want to open the parentheses, you know, it's like, you know, now it's hard coded in, you know.
00:11:26
Speaker
Now I have to remember this thing about operator predecessors, like order of operators. I think we should have like, you know, every language should have a list version that transpiles into the language. So when you move between languages, you just keep writing lists.
00:11:45
Speaker
Seems like we're going in that direction, right? Yes. Clark or Ireland. Hopefully one day we got to feel all of it. Yeah, exactly. That sounds like an idea. Perfect situation. Yeah.
00:12:00
Speaker
So what is the stack you're using at the new company then? I mean, it's kind of inevitable that you and the founder both are in a enclosure. So you pick closure everywhere, I guess. Yeah. I mean, yeah, the company is two years old, but I joined it like a couple of months ago, I think about six, seven months. So I'm not there for that long. Yeah. But the rest of the stacks mostly event sourcing things. So we use a lot of Dynamo and Kafka. Yeah.
00:12:30
Speaker
And they're trying to add some datomics to the game as well to improve things. Because event sourcing is good, but they're trying to do event sourcing for everything. And that has some difficulties for evolving, because changing an event system is a bit trickier. So we're trying to improve the developer efficiency by moving to a more database-centric instead of just event sourcing.
00:12:57
Speaker
But that's experimenting now. But it's very early stages. Most of it is still running on top of living source. But is it mostly API sort of thing? Or do you have website and other front ends? Just for the business, for the companies that hire. So they have some web UI that can see some things and help fill up documents. A lot of the problems is with this filling up of things.
00:13:26
Speaker
like getting all the data you need to send
Attribute vs. Entity-based Modeling
00:13:28
Speaker
to the insurance companies so they can approve or not or give the price. Okay, okay. So are those really old? Like you get all this data and then you have to create soap, envelope, and then you don't call it. Soap. Yeah, I mean, a lot of things go through spreadsheets, man. Like I just spreadsheets. Yeah, I just said, shit comes back. Soap is very important, you know? At least it's a programmatic interface, you know?
00:13:53
Speaker
Yeah. Yeah. But CSV is basically you send an Excel sheet and then somebody does the Excel sheet and then sends it back and then you pass it to them. I think these industries, they never move beyond that one. Yeah. Yeah. They seem like there's no much incentives there until somebody goes and change something. They're not like a
00:14:23
Speaker
We don't care that much has been working for them. And then you have to get somebody to just change the game and say, OK, if you don't do that now, you're going to be behind. I mean, if you if you see from the from the other other perspective, like from the business perspective, I think supposed to last and every two days, you know, we as software people show up and then say spreadsheets of the best man, you need to use debase or whatever. And they're like, OK, fine, I'm going to buy it. And four days later,
00:14:50
Speaker
You know what, you need to switch to Windows 3.1 and then install one of the fuck the children. Lotus Notes is the big deal and then, oh shit, I need to migrate again. And then, so you can imagine from the other side, like every five years or every three years, you know, state of the art keeps changing and they need to reinvest the money. Then probably the business of people are like, well, fuck it.
00:15:12
Speaker
I think the other thing that's really, I think that the people are kind of like, let's say, I don't say they're rejecting, but I think they're beginning to kind of like get a bit fed up with, is always having to ask IT for things or the developers for things. And they would like a little bit more like,
00:15:31
Speaker
The people who are experts in the domain, they would like to be able to maintain their own system. Yeah, but is it something changing? No, I thought that is the whole point of having Excel and spreadsheets, right? Because they took control in a weird way to have the process, to have the macros, whatever the written pivot tables and Excel formulas and sheets and magic.
00:15:56
Speaker
But I think what usually happens is your experience is different from mine. But my experience was that people used Excel to develop solutions to work out what the business looked like and how it should work.
00:16:12
Speaker
And then they kind of within their own work group that they use this excel sheet, but then they wanted to kind of spread it further along the company and it just didn't scale because that person who's looking after excel spreadsheet. Well, I don't know if he's going to stay with the company be.
00:16:30
Speaker
he doesn't really know what he's doing anyway you know he's done this spreadsheet but he doesn't know like he doesn't necessarily want to evolve it he doesn't want to be in he doesn't want to stay with that spreadsheet for the rest of his life you know yeah yeah um and also it just doesn't scale it turns out you know as you add more and more groups and more and more people and they've got more and more demands that he doesn't take or she doesn't care about um it's it all becomes problematic
00:16:56
Speaker
So typically then you get it involved in a make a web front end and make a database back end and everything turns to shit basically what they keep on bobbing it if it's forever enough. What nowadays you can run javascript on the spreadsheet so you can just solve all these problems there.
00:17:15
Speaker
Oh, yeah. As the saying goes, then you have a million more problems. Then you have an undefined problems, you know. I never write off JavaScript is the JavaScript people say never write off JavaScript. Interesting. Anyway, so
00:17:37
Speaker
Yeah, but I mean, but let's, let's, but let's say they are using all these spreadsheets and so how do you, how do you like motivate them Wilker to use your software?
Convincing Companies to Adopt New Tech
00:17:48
Speaker
Um, I mean, I guess kind of strategies trying to automate what we can write, uh, the parts that we see that have some consistency, you can try to automate doing parts of that, maybe even get through some OCR at some point. Yeah.
00:18:04
Speaker
and uh you're in ocr still it's that you actually paper no no we're not we're not doing it that's just a possibility all right okay
00:18:17
Speaker
That's an advanced future system that you perceive. Yeah, it could be at some point. But also, there are different types of company, right? Some of them are most modern than others. So you can also talk to them and explain to them, getting me to say, hey, what do you think about we try to do it this way and we can be more efficient and
00:18:42
Speaker
trying to talk and convince and maybe little by little we can get there like we once we have one working pretty well maybe we can show see with this one we can work very fast and like yeah I guess that's the that's the way that I see it may maybe evolving over time
00:18:58
Speaker
From their perspective, what do they get out of it? Apart from efficiency, efficiency is a code word for something, but what does it mean? Does it mean more money or does it mean better service for their customers? What's the kind of narrative that they're buying into? Depends on the persona we're talking about here. If you talk about the
00:19:28
Speaker
The insurance providers maybe could be getting faster deals or less cost in operation because we can reduce the operational cost of them if we can automate a bunch of stuff.
00:19:43
Speaker
There is for the companies that are hiring the service, because right now it's kind of a painful process to fill all the data because they have to get a bunch of data from the company, a bunch of data from every member of the company, like what illness they have, like age, where they leave, like many different steps require a lot of information and the HR people are like,
00:20:07
Speaker
fed up with a lot of stuff to do. And then they suddenly have to get all this data to send us because all the doubt. And sometimes they even think that we are wanting this data. Like, no, no, it's not going to be one. Insurance companies need that. Otherwise they can't give us a quote for your thing. So trying to get
00:20:25
Speaker
all of this flowing better because it takes a long time. Sometimes it can take like three or six months for somebody to get health insurance ready. Wow. Now, this is a question I've got for you, which is kind of like, I think it's a hot topic. Well, I think it is in the UK anyway. I'm not sure what it's like in Brazil or in Europe or in America.
00:20:47
Speaker
But, well, I can guess. Just to be clear, okay, everything that I'm saying is my kind of personal opinion. Yeah, yeah, it's okay. It's okay. No, I mean, this is... You're the spokesperson of your company. Yeah, come on. Yeah.
00:21:06
Speaker
I don't think anybody is going to take it as word to word. No, we're not going to hope. No one's going to call over this lot. Nobody's listening to this stuff. Trust me.
00:21:21
Speaker
We'll just have moved away from this nonsense. But there is a sort of a super interesting question for me about health data and personal data, which is like privacy, you know, because medical conditions and all these kind of things. So it's I mean, and again, I don't know whether closure specifically helps us here with all the immutability because you can't get rid of the fucking thing.
00:21:44
Speaker
you know just what is it about like healthcare data and all this kind of stuff which must be super private how do you deal with that in a kind of yeah respectful way and a sensitive way. Yeah i think that's a complicated issue.
00:22:01
Speaker
It makes me remember, I think when I was with you, Vijay, was right when the LGBT law stuff was starting to get in practice and everybody was like, oh my God, I use the atomic, what do I do now?
00:22:17
Speaker
Yes, because at the point, there was no accession in the atomic, right? You can't, yeah, specifically for that. Yeah. Yeah. Yeah. Yeah. Although, although it's accession is not really a feature for that, because it's really painful to do an accession. So you can't do like routinely, like if every week,
00:22:36
Speaker
Two or three people remove their data. It's not something you want to be doing like that often. So far, what I see people doing is more about going via encryption. So you encrypt the data of somebody with specific key and you can just lost this key. That's as valid as removing the data. And in Brazil, we have two different categories of information, of private information. You have the PII, which is the personal identity information.
00:23:04
Speaker
Yeah, but ours there is the PMIs, that's personal medical information, because this one you have to even care much more than the PIIs. So right now it's done via encryption as well, like similar strategy. We're also, we don't have an answer for that. I don't have at least my head, but I believe it would be something around this encryption thing. And that's where I like, I think the attribute design,
00:23:33
Speaker
stuff like modeling things around attributes can help a lot because it gets much easier to like, I can mark an attribute as a PMI. And then my whole system can know that's PMI. So if any part of the system can be aware of that, we can write constructs that deal with that properly, no matter where it's being stored or winter.
00:23:56
Speaker
So it's part of your model, then, like every attribute that you have has a tag or something all the way in the database to application layer. Everybody knows that it is a specific type. Yeah, this is the way I think could be a way to solve this, like to handle this problem. Yeah. OK.
00:24:17
Speaker
Because the other way I've seen it in cryptography is that what you do is you have assaulted hash and then basically you lose the salt, you know? So you can kind of like, that's a nice way of doing it because it's very fine-grained. Yeah, because of the salt, fine-grained. It doesn't matter. It's true. Also, it's funny, you know?
00:24:46
Speaker
Anyway, of course, coarse-grained. Yes, indeed. That's a, that's a very fancy salt, that one. Yeah. The rock salt. Anyway, yeah. So I mean, that's, I think that's really interesting. Is it, but just quickly, I mean, this, this like, um, do the atomic and functional programming and mutability.
Healthcare Data Privacy in Brazil
00:25:05
Speaker
Does that play into your thinking in those terms? Or are you just like, no, we're using cryptography. So it's like a completely orthogonal thing. I think it's a bit orthogonal.
00:25:16
Speaker
The thing that helps is to me, personally, I think the idea of attribute driven because when you compare, you guys may have seen me talking about this before already, but it's what we call the container types when you map stuff like person, like company, this is the pervasive model. And this model is quite hard to
00:25:41
Speaker
navigate across a whole company thing because your models, they are not generally very portable. And you don't know what you're talking about because you may have a person and then you have a simple person, a person with something. Yeah. Exactly. And they will share attributes, but there, there, there is no, like a robust definition that says when that the name for a person in the name for a patient are the same thing. A human might infer that.
00:26:11
Speaker
but systematically as a program, you can't know that attributes across types mean the same thing, which means you have to keep repeating their definitions. And that doesn't cross boundaries of languages, boundaries of run times. And that's where I think when you design things with the attribute modeling in mind, the attribute is just a name that you put some semantics on it and say, Hey,
00:26:39
Speaker
This is my name. The type of this is a string. The generators I have for these will generate human names. And this is our personal information. I'm there. I have whatever database that says could be identical over map. Let's say these attributes PII true or false. Yeah. So you can, and because the attribute is just a name, you can, you can rely on the semantics anywhere you use that name. You don't have to care about if it's in a person, in a patient, in a doctor. So.
00:27:09
Speaker
This is kind of part of the research that I kind of do for battle and attribute modeling because I'm very interested because I believe when you use this, you can have this kind of leverage about your information that otherwise gets consistently repeated. Yeah. Do you know about like this, um, this thing in the security world of airbag and RBAC? No, I'm not familiar with.
00:27:35
Speaker
Yeah, because they basically have a very similar idea. They have something called role-based authority and attribute-based authority, or role-based access controls, which is RBAC, and ABAC is attribute-based access controls. And it's a very similar model because the problem with role-based access controls is that
00:27:57
Speaker
Like you said, everybody has different versions of this roles or different interpretations of this roles. You look at LDAP database, there's a certain point as the company scales and scales and scales. I remember talking to a security company about this, that the number of groups in the LDAP exceed the number of users.
00:28:22
Speaker
Yeah, because you have to have all the subsets, right? Because every intersection you have to have more stuff. Yeah, so their answer is to move. But it's still an ongoing thing, and like you say, it's a research thing now. They have models for it.
00:28:37
Speaker
The problem comes with it with a back, which is this attribute based access control is that you need a programmable model programmable interpreter. You need a way to compose those attributes at runtime, some glue code basically to create those access controls for those attributes.
00:28:58
Speaker
So I guess that's an interesting aspect for you as well. How do you compose all of those attributes together in a way that's meaningful for the developers? Well, that's pretty much what Pato does, right? Yeah, well, you know. Well, I'm helping you. Yeah, thanks. Let's enter on that. Because, I mean,
00:29:24
Speaker
It's much easier to understand pattern if you first understand the motivations between this attribute modeling idea. Because then once you think like, OK, I will have these huge bags of attributes and data. And then what pattern helps to do is to unify that in a single graph without caring about how many different sources of data they are. So you get your attributes as an abstract definition.
00:29:52
Speaker
And then you create the mappings between the attributes themselves. So, to provide an attribute to the user, you have to write an implementation, our resolver, that's what I call it, a resolver to provide that attribute. And that's something that's indexable and lookable. So for example, if you want to have something private, just make sure you only have one implementation for it, or that all the implementations for it have that security code attached to the resolver.
00:30:22
Speaker
Because then you can write any code you want for that resolver part. And even if some information depends on that, because Python can do the traversal, right? It can jump, call many resolvers to get to the attribute. It's going to have to go through that function. So if you have a policy on that function, it's going to ensure that that's the only path to get the data. So that makes it easier to see what maybe are the open spots in your code base.
00:30:53
Speaker
What was the trigger for you? What was the motivation? Because Python went through several iterations, right? We are at Python 3 now. So where did this start? Why did you decide to tackle this? Why did you decide, OK, you know what? I'm going to click New Repository, or line new, whatever, and then I'm going to solve this problem. And I mean, Python started much modest.
00:31:20
Speaker
For a long time, it was just a file that I copy over from project to project when I was learning omNEXT. Even the name come from omNEXT because path and one from omNEXT back then. So at first was just because I was interested in omNEXT applications. I like the idea how they connect the relay thing with the Fokker thing, have a single database, but
Developing Pathom from Om Next
00:31:48
Speaker
Wrong on next was a bit raw. So when you have to implement the server side of it, you have to do a lot. You have to literally implement the parser. Yeah. And if you do it over and over again, you start seeing like, okay, a lot of this is repeated stuff. Let's try to encapsulate this repeated stuff. So pattern was born with that's just a namespace with a bunch of tools to help create parsers for next.
00:32:15
Speaker
The big leap for petal was the connect part of it. Because connect is what the resolvers indexing and traversing and all the cool features people like about petal are actually from this connect part of it. And in the beginning, it didn't exist. The first implementations were just like, imagine one multi-method that we have one implementation for each attribute.
00:32:43
Speaker
So just implemented with one attribute at a time. But in, I was at new bank, I was trying to use it for, uh, for creating the back office application. Because, um, I was into full crew already. By that time, full crew is, was already a thing.
00:33:02
Speaker
And I look at that, and you look at that UI. That UI is just a huge number of widgets that could grow. And widgets are written by different teams, but they have to load together in a page efficiently.
00:33:17
Speaker
So that looked to me like a great case for using full-flow in EQL. Because okay, you can have teams writing their widgets, composing their queries, and then you can manage the processing. So we started small, tried to write just one widget using it. And that was a hackathon. We wrote the service that handles the backend. And I was trying to implement things using the previous pattern before connect.
00:33:45
Speaker
And one specific moment was that I'll try to load customer data, let's say customer name, customer email. But the problem is this has two options. You could either get by the user ID or by the user's social security number.
00:34:02
Speaker
So when you look at the practical side on that, when you write the customer name attribute, you have to do like, if there is a customer ID in this, then you're going to call this function. If there is a social security number, you're going to do that. And you have to repeat that for each of those like 15 to 20 attributes.
00:34:21
Speaker
They're like, you know, like, Oh, this, this does not look nice. It's not going to scale. No. Yeah. It's not going to scale. This is not going to scale. And they're like, you entered a desperate moment because like us trying to push this idea and then suddenly like, Oh, that's a problem. Like I don't want to push it. It's that way. And, and I was just thinking home and suddenly the idea came up to me like, okay, what if I change this definition type instead?
00:34:52
Speaker
And I get the definition closer to the implementation because each endpoint is a real implementation in this case. So what if I can somehow implement just once for each endpoint and I can say, okay, I depend on a customer ID and I'll speech you these attributes, or I depend
Pathom's Resolver Concept
00:35:08
Speaker
on a social security number. And then the idea started to just fill in the head, you know, just
00:35:13
Speaker
okay, if I delegate the control out, then I can start indexing this information. Then I can take control of the runtime instead of doing this. That's just more like direct, right? Which feels like how GraphQL, if you implement it in a GraphQL API, it's going to be more like that. You have the types and for each attribute of the type, you can have a function or something.
00:35:35
Speaker
In this case, I take control, do the indirection, so I can make a lot of more interesting things below. And that's how the connect started and how all this attribute, mambo-gentle started to evolve. The one thing that always like with these, and again, I'm sort of going back to the attribute-based security stuff, but one of the questions you always get is like, well,
00:35:58
Speaker
How do you, how can you predict with tooling and stuff like that? What, what you've got, what you've got in the database and what the actual access paths are and what, you know, so essentially the same question for Patham is like, well, what are your entities? What are your, you know, you've got all these attributes, but how do I know like who can access his system or when I, how do I know what the people are that can access these things? So it feels to me like that's what you're building now. You're building something which can essentially tell people this stuff.
00:36:28
Speaker
Yeah, there are different ways to go about it. In the case of new bank was actually pretty easy for us because we don't have to do anything about it. And the reason we don't have to do anything about it is because the endpoints are already secure. They have like access tokens. And when a user, like our services was pretty much a huge controller, right? Our service doesn't have any data by itself. It just was asking data for other services in the company.
00:36:57
Speaker
So since, and the person that asks our services, sending their token and you're getting the token forwarding, forwarding for all the other service. So that token is responsible for deciding if it has access to something or not. So since we are a proxy, we don't have to do anything like the end goal, the inside would handle that for us. But in a case where somebody may be using pattern to do more direct access to the data, then,
00:37:23
Speaker
It enters a more experimental ground. But my suggestion in what people at FOCR side does is just do it by resolver, since a resolver is where you're exposing the data. So you can go there and make sure that the user has something. But part of the resolver called there's the environment. So you can pull a token from the user or something. And then you can design in any way you want. It could be by scope. It could be by attribute. I think there is...
00:37:52
Speaker
I personally have not had a chance to do a lot of that. I just have some ideas that it could be even by attribute base or entity. There's something interesting exploration to be done there. These things, I mean, I'm kind of like pulling back from a dim and distant past, but these kind of things always remind me of this project in the 2000s, I think called Java Spaces, which was this kind of
00:38:21
Speaker
Again, an attribute based idea, but you built up views of things on demand, essentially. And I feel like those ideas, I think they were called, what was it? There was a general concept. Was it tuples or something?
00:38:38
Speaker
the Tupel views, maybe it's a Tupel space, I think it was based on Veejo, do you remember? When you say Tupel, you remind me about RDF, like the triplets on RDF. I think it kind of like was around, maybe it was a springboard from that. Yeah, but these kind of concepts where essentially you're always composing views, basically. You're never
00:39:04
Speaker
You're never bound into a particular entity or a particular data model. You're always doing it on the fly, on demand, on a particular need. This seems to me like it's going to be the future, you know? Yeah, I think the point here is
00:39:24
Speaker
is that the bag doesn't matter, right? Any entity is just a bag of data. It's like this is how the atomic works and how Clover's back works as well. That's how those libraries see the world. And that's a different model that
00:39:41
Speaker
I hope we get more traction. Right now, it's still a niche. Yeah, I think because I think we're all, maybe not all of us, but when you start from the object-oriented thinking, it's always like you first define the entity and then entity encapsulates all this state. Yeah. Because we're free-floating
00:40:04
Speaker
because I was just showing my datomic schema definition to someone who is from normal SQL world and they're like, oh, why are they just floating around? You keep just defining attributes and then there is nothing that is defining like a person table and then person table contains these columns sort of way. So this is a...
00:40:26
Speaker
It's a bit of a tricky thing to get a hang of because you tend to think, or at least if you're trained or maybe old people like me, we tend to think, oh, there is this table entity object that I start with, and then that has some things. And then, as you said, when there is kind of an overlap, you always get into this weird fucked up situation like child classes, inheritance, and object oriented side, and the tables, it's all a big mess of weirdly normalized shit.
00:40:56
Speaker
The switch seems to be fairly difficult if you are coming from that direction, right?
00:41:01
Speaker
Yeah, it's also spreadsheets we've been talking about. But the spreadsheets are kind of the same thing. You have a table. And then you have to get to the person and say, OK, imagine that you have just one table that has all the columns of all your different tables in the same table. That's what it's like. You're not bound by the system. All the attributes are in the same space. They are not enclosed by different spaces.
00:41:30
Speaker
Yeah, but also all these, all these SQL people, um, you know, they argue all this, this way, but in fact, you know, um, uh, all app databases and, um, and sort of data warehouses and data cubes.
00:41:46
Speaker
are all about getting things denormalized again. They're all about saying, actually, we find all of those kind of constraints of the operational database completely horrible. So let's give us the ability to custom query our data, please. Yeah. And also, I think because on OLAP, you're usually interested in aggregations, right? So it's
00:42:12
Speaker
you're less interested in transactions and you're more into transactions as in database transactions well yeah but i could get you trying to be in the bags that will cause talking about yeah yeah yeah yeah totally yeah.
Challenges with Attribute Modeling
00:42:25
Speaker
Yeah companies like start right that's use rdf to do normalization when.
00:42:32
Speaker
when one giant company buys another giant company and they have these databases that know nothing about each other, then they rely on this highly enterprise RDF companies to make everything iterative based so they can make sense of it. Why don't start that way? Yeah, it makes merging a lot easier. Yeah, that's for sure. Yes, it does. You could just point and yeah.
00:42:59
Speaker
I imagine actually if you just thinking that thought experiment through a little bit more, it wouldn't be that easy because if you have all the attributes in one company and all the attributes in another company, it would be easier in one sense, but then you do have a mapping hell, I think.
00:43:17
Speaker
You have, but at least you can have a layer that's only about that. I can tell you, for example, I recently wrote, I used Python to write migration code because we are migrating from one CRM to the other. So what I have done, we wrote some resolvers that read from the CRM8. So they all have namespace and they all have the names that are related to the CRM8.
00:43:47
Speaker
And that's it. That, that layer is purely about this here. And let's, let's hope their name is plumes. Yeah. And then it's all about that. There's only plumes names. And then we got to the HubSpot, which was the other on their API. And then you say, okay, what we want to write, this is the query. I want to like, this is the QL that represents the data that needs to be available for me to create that entity on the other side, create a company or to create a member.
00:44:15
Speaker
And then once you have the data from one side and the query from the other, now you can have in a separate file just resolvers that are like alias resolver, like this name is the same as this name. This name is the same as this name. And then when you need, for example, maybe the data format from one is not the same as the other. And then you write one resolver that does the translation making the conversion.
00:44:36
Speaker
So you can work attribute by attribute until you have the queries you need fulfilled. And what's nice is that they are all very separate. Like the layer that loads data knows nothing about the layer that's on the outside. And that's, I think, it's an interesting way because you can see it and you can follow it. And doing by attribute, you got a lot of leverage because you only kind of do things once. Or each and you can evolve easier. That's why I experienced doing it this way.
00:45:03
Speaker
Maybe it's, I'm just thinking out loud, isn't it going to be a kind of an issue when everybody tends to, I'm not thinking about the users of this data, right? Imagine that we are looking at this attribute-based database, data maker, whatever, that is something.
00:45:24
Speaker
there has to be either some discipline in saying what exactly a person means, like across the organization that everybody knows that this is the, because the taxonomy needs to be shared, right? So yeah, because if one application thinks employee is this and the other API thinks employee is something else, then you're in a weird situation because either you don't show the data or you don't update the data properly, whatever. So how do you tackle this thing then? Is it gonna be like,
00:45:53
Speaker
another API layer or... Yeah, I mean, to me, what makes the big difference here is not naming the container types like a person. We never have anything called a person because that's going to crash short real quick. That's where attributes are different from entities. Attributes, they are much more durable pieces because what's the usual problem, right? You get
00:46:19
Speaker
you get an account and then you try to find out an account. And then you say, oh, an account is required to have a number, it's required to have an ID, it's required to have this, this, this and that. And then for example, and then let's say you use that validation across your system. And then next day you want to temporarily save an account where you allow for partial data, then your model is screwed.
00:46:44
Speaker
Because now you have to create another one and then you have to replicate. And that's why the entities kind of fall short while attributes don't. Like a person name, if you define that that's a string and that has the semantics, this is not going to change easily.
00:46:58
Speaker
Also, if one attribute is broken for some reason and you realize, OK, we modeled this wrong, you don't have to lose the whole entity. You just create a new attribute. And if you use pattern, you can make mapping so you can still use the old attributes converting to the new or other directions you need. So you get something that you can evolve without breaking this way because the attributes don't break as big when entities break. Yeah, yeah. And for the.
00:47:27
Speaker
So does that mean that I can use pattern with any kind of storage? Or is it only? Yes. You can use pattern with any kind of storage. Because the pattern resolvers, they are open functions. So you can do anything you want inside of them. So you're never limited by any specific data source. It could be from memory. It could be databases. It could be other services. Yeah.
00:47:53
Speaker
Nice. So what is there? So you started with omnext, essentially building something for omnext. And then now it has become like a full fledged. What is the elevator pitch for Patham? What would be the simplest way to explain it in two sentences? I tried to work that for a long time now. But I would say it's a library.
00:48:21
Speaker
Yeah, that helps you unify data sources via attribute modeling. I guess that's the concise way I can help.
00:48:30
Speaker
Yeah, I can see it. Well, Patham3 on the readme says logic engine for attribute processing. Oh, I gotta change that. That's out there. Get on it immediately. He's just pushing in your paper readme right now. Yeah, this keeps changing, but I will actually take a note because right after this call, I'm changing it.
00:48:55
Speaker
But it's always tricky to explain when it is not, you know, the underlying models are not well known, right? You know, it takes a while for, especially
00:49:08
Speaker
People need to know what you're talking about and then if you know that, if you know the taxonomy, if you know the words, then it's much easier to relate to it. Otherwise, it sounds super confusing. Please go ahead.
00:49:25
Speaker
And I was going to say that one thing that I see from practical experience on the new bank project where, I mean, we were a platform team, so we make the infrastructure for other teams and people to code. And what I see is that for people to understand just how to include more endpoints and more resolvers in the system, it used to be very simple. You just show them, hey, there's this attribute. So you're probably relying on a customer ID to pull
00:49:53
Speaker
to pull some purchases or anything like that. So your writer is over, you map that, your input of your endpoint.
00:50:01
Speaker
And then you get the output, which usually doesn't have namespaces. So just put the namespaces on that, and you're golden. And that's it. And to do it is like this day-to-day operation. People seem to gag it really fast. When things go wrong, it's where people get confused. But that's where I see it's a way to get people to start understanding this, because they have an easy experience. They say, oh, it's just that? That's fine.
00:50:27
Speaker
just to add pieces to it seems to be easy, but you have somebody designing it, knowing enough to design the basics of it so other people can just replicate. That's something that the number of people that like have been thinking about it is not that large. Yeah, yeah.
Discovering and Adopting Clojure
00:50:45
Speaker
So before, because you're at New Bank for, you know, closure, how did you end up at New Bank? How did you end up in closure then? Or did you start with closure?
00:50:56
Speaker
No, before closure, I've been a language junkie, though I found my passion. My coding life started with HTML and JavaScript, so just kind of web development and making websites. And then I did a lot of C, CMS, and things like that. And then I migrated to PHP. I did a lot with PHP.
00:51:26
Speaker
then rails. And because of rails, I knew uncle Bob Martin. And I see his presentation about the last programming language. Have you guys seen that? Yeah. Yeah. Yeah. Yeah. Okay. That was the presentation that triggered closure for me. Yeah. Yeah. And I said, okay, that's interesting. Let's have a look. And then I did, I got some books and closure, tried for a while, but it's, uh,
00:51:51
Speaker
It wasn't passion in the first, it wasn't love at first sight. But then a couple of months later, I was seeing a presentation on React and the guy will react and say, Hey, by the way, people on Closure are going crazy because they finally now have a way to do functional UIs. And I mean, UIs is the thing that I actually like the most. And I said, okay, time to look on Closure again.
00:52:14
Speaker
And then since then, I got in love and I thought, oh, this is awesome. I just want to do this now. And that's how I got to New Bank. I was just looking for a closure job. And like, there's no, there's closure in Brazil. I knew then from the conjure in 2014, I met them there. It's like I was attending closure conference and I wasn't working with closure yet.
00:52:37
Speaker
Trust me, I mean, as an ex-conference organizer it used to be, it is probably still a thing. I mean, you get so many people who are, you know, closure enthusiasts rather than practitioners. Yeah, closure enthusiasts. Yeah. And then that's how I got to Newbank. And I got to Newbank since school. I had a company in Sao Paulo, and I talked to them, and they started to hire me, and then I moved here.
00:53:02
Speaker
And then I have my happy life do closure full time. Nice. Are you still, are you still doing the, the UIs as well? Okay. Is that, is that in your role or are you mostly in this middleware now? Yeah. Okay. I mean, uh, I do, I do, I do, I mean, people is a startup, so we do. Yeah, exactly. Well, that should be done. Yeah. Yeah.
00:53:26
Speaker
But yeah, I like UIs a lot. I mean, I was listening for your podcast about Membrane with Adam. And that was, I find that idea super cool as well. I like how I am following Tonski with all his key job stuff. Yeah. Yeah. Humble UI stuff. Yeah. Yeah. I know I maintain my stuff like pattern vis is some UI that I keep maintaining the edge. Like I like Chrome app. Yeah.
00:53:57
Speaker
Are you also contributing to FullCrow? Because I know you picked a FullCrow pretty early as well, and then you're working on libraries for FullCrow. How do you see your PHP Rails experience against Closure Web Experience leading into FullCrow and other stuff now?
00:54:17
Speaker
I think there was a big difference because when I did up to Rails, I was most doing like the server rendering, like development way and not SPA's. And then migrate to SPA's was about the same time I migrated to plotter and plotter scripts. But I was a fan of React back then. As you may know, React to conciliate with Rails kind of took over. They're not like very friendly to each other.
00:54:45
Speaker
But for application states, I think Closure Glare Script is super suitable because you can get one of the best hot reloading experiences because it's all immutable data. So we had Bruce doing FigWell way before people were having happiness with their storybooks and things of that.
00:55:06
Speaker
But yeah, it just changes that the communication thing becomes, the API thing becomes a thing when you're doing the SPAs. Like when you're doing the server side rendering, you don't care, you don't care about it, right? Just write all the getters, write it right on your template and that's gonna fetch, reach the database right when it's rendering the play plate and it works great. That was like the before the MVC stuff. But when you're going through the web, the API side things change. That's how the whole movement of GraphQL start up because people got fed up
00:55:37
Speaker
about how many endpoints do I have to write. Now I have an iPad client, a mobile client, a desktop client. And they like all the possible subsets. And that's the same problem. Exactly the same problem as I was going to say. Exactly the same problem of the types and the mixing of the things. It's all the same problem.
00:55:57
Speaker
Yeah, I think this is what David was saying, David Nolan was saying about that, which was essentially you may give the give the client the ability to query things. And it makes life easier, you know, that the problem with it. Well, it makes life easier in one sense. But then
00:56:14
Speaker
Again, I mean, it's a security issue. It's like, well, how do you make sure that people can see only the attributes that they're allowed to see or only the non-medical information, for example? This is the kind of thing which GraphQL, it was a struggle at the beginning with GraphQL, I think, to inject that kind of constraints, let's say, of the view.
00:56:44
Speaker
Yeah, it has a slight difference. But to be honest, I don't see this being that much different from resting points. Because that's kind of the same thing, right? The way it's always controlled access. I don't know anybody that's in production allowing, just putting a system out there allows full database access. I mean, nobody does that. You always have to put your access points in front of it.
00:57:10
Speaker
So if your access point is a resting point like that, and you are in that problem, we discussed about mobile iPads in itself.
00:57:17
Speaker
then you may have to write that in multiple controllers. And I think that's kind of the same thing when you're doing GraphQL or Petal. When you write the code that allows for the access of it, that's where you need to do it. Of course, because of navigation, I guess what people in GraphQL and Petal might fall short on that is because since the traverse of the data may become a bit more automatic,
00:57:43
Speaker
You may let some point, let some of these breath edges pass without being seen. That's kind of the problem and you are not aware that this is happening and then suddenly you have this path for people to
Future of Attribute-based Systems
00:57:58
Speaker
access what they find. Yeah, everything has to be more dynamically evaluated. I think that's the key thing. Yeah.
00:58:05
Speaker
Yeah, but I believe with time, we can have these things more standardized. And it doesn't have to be something that everybody has to think about it. Because nowadays, it's like everyone that's designing a solution will have to stop, sit, and think, OK, how do I do these control access? I hope over time, we'll have this better documented so people already have
00:58:29
Speaker
uh, pathways set for them to go up. Well, maybe we can like merge the attribute based access control and the attribute attribute based queries. Um, you know, those things could be merged. That seems like, uh, I don't know. It seems like something new we've just thought of. Yeah, let's do that. I'll hit you up afterwards. Okay. Let's see if we can make a framework.
00:58:59
Speaker
But where do you see this going? Because, of course, we're not talking about unifying everything to be it. Because I don't think there is any other, quote unquote, mainstream databases that make a tribute other than Datamic, right? Or maybe Tupperstorages or whatever, if they're available. But they're used in a very specific context. So Datamic is
00:59:27
Speaker
Yeah, I think mostly closure, you know, a subset of closure people knowing the power of Datomic and using it. I haven't seen anybody shouting from the rooftops like, hey, Datomic, and then we're done. And then let's use it in, I don't know, Rust or whatever. So because it seems to be like it's kind of at odds with the rest of the programs that you design with closure, there seems to be,
00:59:53
Speaker
to use this weird, weasel word, like a synergy between language and code and data and the database. But do you see any other things popping up like this or do you see that this is going to, you know, picked up by other mainstream technologies? Yeah. I mean,
01:00:14
Speaker
I think this is about culture, right? The reason we have so many databases and things modeled this way is because it's our mainstream culture of programming. And that's one reason why the nice thing about patterns is that you can wrap and you can add your namespaces so you don't have to rely on a data source that's using attributes under the hood. Like you can have this translation layer.
01:00:41
Speaker
So we can leverage, we need to be able to leverage all this database because otherwise we'd be stuck. One like a non-conventional example that I can say is that you guys are familiar, are aware of auto merge. Yes.
01:01:00
Speaker
It's like that with merging documents in different times, you know, different timelines. Yeah. CRDT. Okay. Yeah. CRDT. CR. Yeah. Yeah. Auto merge is an implementation of CRDTs by Martin Kaplan. Martin Kaplan. So I trust the guys work. And one of the architectures I've been experimenting with another day was that I put a pattern code on a web worker.
01:01:29
Speaker
with auto merge. So now you can have the data going for an auto merge and have all these clients synchronizing over it. But the thing is with auto merge, you really don't want to have a single document because the documents in auto merge, they are kind of like the atomic, they kind of grow forever. Then you have all the history of everything that happened. So they use for the purposes of merging.
01:01:55
Speaker
So what people tend to see people doing when they want to scale this up is just have many documents. So we have documents pointing to documents. And this is just standard JavaScript interface. And you can completely totally wrap that on pattern so you don't see any of this fuss of looking in a file, looking for another file, looking for a needs in the file. And you map that. Because down the layer, if you agree with the attribute modeling, you only have two things, entities and attributes.
01:02:25
Speaker
linking each other. Yeah, how this is happening doesn't really matter. And the developer that's using the data don't need to care about it. Yeah, so I think it could be a culture shift if a lot of people start doing it and seeing the value of modeling things this way. Because then the SEO. Yeah, but like, one company I see with using better is that I'm really annoyed by having all these adapters that I have to write like
01:02:55
Speaker
add namespace here, remove namespace there, add namespace here, remove namespace there. But that's a really important part button, so you can't really go without it. But it could be there at some point. People are like, okay, I'll do all of this. Maybe my database can save stuff like that, and the atomic can. So who knows? Who knows? We can dream about a future like that.
01:03:18
Speaker
So I mean, it's more like application design choice rather than the data storage engine, because, you know, that that can be relevant by using things like things like bathroom. OK. Yeah. Interesting. But also, can you I mean, is it something which you can have as data that you can store on the side in a database that you're aware of or don't you want to get into that game? You know, you don't want to get into the game yourself of
01:03:48
Speaker
of having a channel into the database or a channel into the persistence environment? Right now, it's not any focus of pattern to do that. Pattern is just to be really... Pattern is a big controller, really. Pattern doesn't have any specific things for read or write. It's just the communication layer that you can use via EQL to make all these communications.
01:04:11
Speaker
Like you can, you can design a whole system that is purely EQL based on communication. Cause you can ask anything you want by asking the course by attributes and you can do the mutations which are just symbols with are pretty much like function calls that you define what they mean on each context. So this, the, the details of the implementation need to be really open. And that's kind of my focus now, right? You get this part working well because I,
01:04:41
Speaker
I have a bigger plan. That's like my dream architecture. That's when here first folks, we already, we already said a completely new design design
Integrating APIs with GraphQL
01:04:55
Speaker
idea. None of this. Okay. Okay. Come on. Spill it to you then. No, it's this, but this is about, this is a consequence of this design is more of a consequence. Yeah. Something you can get you and there is how you can integrate these kinds of services.
01:05:10
Speaker
because you can integrate multiple GraphQLs via Federation. I don't know if you guys read about it. The problem is that the federated GraphQL needs to be designed for Federation.
01:05:25
Speaker
So you can't just like say, oh, I have GitHub GraphQL and I have GitLab GraphQL. Let me just merge those together. That's not so easy to do because you have to care about what's on the query route and they don't collide. The same type problems we've been discussed, right? You can't easily map things from one to the other. But on the attribute-based systems, if you have those two,
01:05:56
Speaker
then the names are completely different for starters. So there is no collection on that. And you can write manual mapping. So part of the work on pattern three was to allow for this feature, the feature that let's say, let's say those searches are already in pattern or during save.
01:06:18
Speaker
If you want to integrate with GraphQL and GitHub, all you have to do is make a way to make a requester. If you give me a way to make a requester and get the response, that's all you need. Because then Petone is going to ask for indexes of that service. Then Petone puts those indexes on your current instance.
01:06:39
Speaker
And when you make queries, Petal can do the orchestration and say, okay, this part of the query needs to go to GitHub. This part of the query needs to go to GitLab. So you can use all the data from one other plus there is over zero right on your own. So you create this system where the integration becomes just pointing to it and you don't have to
01:07:01
Speaker
It would be much, much easier to integrate any APIs in this way than any form I know nowadays. I don't know if this is an interesting diversion, but what future do you see for EQL? Because for me, it's a sort of underplayed hero in a lot of environments, EQL.
01:07:29
Speaker
But I don't know if a lot of people are really fully aware of it, you know, this even query language. Yeah. And I mean, I just baptized it, to be honest, they've not learned the responsible for creating most of it. The reason that the name EQL system exists is because there is full-flow and pattern and both needed it. So me and Tony K, that's the guy who writes and maintains full-flow. Yeah. I was like, Oh, okay.
01:07:59
Speaker
Yeah, and we're answering for questions on Slack and say, yeah, they all next query syntax. They all next query syntax. And we have both the non-name in the code duplicated between pattern and folder. They say, let's fix it up. So I just extracted the code, put a name on it. EQL, it sounds like catchy, short, small. Let's just call it there. Yeah.
01:08:23
Speaker
Let's call it that and then reuse it. And I mean, I think Crux also uses it in Pyramid. I think the new libraries are using the name as well, which is nice and cool. They are using the names and the code from EQL. And EQL is just about the shape description, like it's the layer we can use to communicate. So as a communication layer, I think it's great. And that ultimately is,
01:08:52
Speaker
just one implementer of a query processor for EQL, but FullQuery itself has its own implementer for it that reads from the local map database because it's more efficient for them because it's very specific, while Python tries to be more dynamic and broad and do complex data services.
01:09:14
Speaker
But people can use the QL as they see fit. And if we all at least agree on the syntax, it's easier to reuse across different sources, right? So it's not directly competing with GraphQL then. Or is it something? I think it does. It's recursive, so it is.
01:09:40
Speaker
Yeah, it is competing with GraphQL. In that sense, they're just both a language to describe requirements. But the URL is much lightweight because the URL was designed with the principle that the language itself is data.
01:09:58
Speaker
And that gives us some leverage, for example. We don't have to write features for partials or variables or any of that, because it's all data. If you want a partial, just drop the thing inside of it. Because while GraphQL was, when they designed it, they thought about, okay, people are going to use this as strings, like SQL.
01:10:22
Speaker
So because they're going to use it as strings, I need to have interpolation features and extension features. And then they have all these crazy features, like conditionals and this kind of stuff that we don't need because for us it's just data. Yeah, all the parts and all this stuff. You can't just do a read string on it. Yeah. And I can bring, I feel, another interesting thing about the attribute modeling where I can say we did
01:10:52
Speaker
is that you can have generators for the attributes as well, right? So one thing that I found was really efficient, like people like this, is that when you're creating a new widget, maybe you don't have the server stuff ready yet, or you don't want to hit a server to try it. So because the queries are just EQL, we had a processor for EQL that it just scanned a query and used generators to fill everything. Like it doesn't try to be a system anyway.
01:11:22
Speaker
This is super cool because then you have the component when you're trying. We use workspaces there. That's like dev cards differently. And then you can have a widget that you create and you just keep progressing the restart button and keeps generating data. So you can keep seeing the component. You can interact with the component without having any real server. And just because these attributes are flowing this. Yeah.
01:11:48
Speaker
So that makes the whole UI development much more, I think, realistic, because you're actually playing with the data, right? Yeah. Nice. Yeah, and easier. Yeah. Because we don't have to have dependencies. Like, I need to find a user that has these status, or this, or this, or that. You can both just or fill manually, or just keep refreshing until the state kind of looks like what you want to see. Yeah. Nice.
01:12:15
Speaker
So maybe going back to Closure because you've been using Closure for a long time already. So are there any things that you miss? Maybe not from PHP.
01:12:35
Speaker
I mean, let's put it this way. Are there still any pain points that you think, okay, this is something that got to change hopefully one day in Closure, or Closure ecosystem, or tooling, or everywhere? Is there something like, you know what? Fuck this, I'm going back to PHP moment. No, I mean, the only thing there was really nice about PHP in that sense is that the deployment was kind of easy, right? Yeah, I just put the file in there.
01:13:05
Speaker
Yeah. Back then, we even added only FTP. Exactly. We fixed back to FileZilla editing. You can repel into the thing, but it's not the same experience. I agree. But this is one of the frustrations for me and one of the reasons I like depth.Eden is that depth.Eden gives you that capability again. You just drop your files in and just restart the application and bam, you're done basically.
01:13:30
Speaker
Yeah, but on PHP, you just, you don't, there is no restarting. So it's just, yeah, and you're done and there is nothing there. Well, it breaks in mysterious ways. But anyway, the connection that you have to manage without an application, every application. Exactly. Yeah. Yeah.
01:13:49
Speaker
Good old times. But isn't that like if you think about the way that you have an application, you can have file watches on your FTP site or your server side, and you can just restart yourself. It's actually quite easy to do that. You don't need to have a whole full redeploy and everything. But nowadays, we actually have a very close to PHP option to do that. There is deploying with Babashka.
01:14:18
Speaker
Just deploy a service with like those and jinx proxies and you have a basket that's working pretty much like a PHP process. Welcome full circle back to CGI. It's just a scripting environment.
01:14:37
Speaker
Yeah, so we have that, so I can't miss that from PHP anymore. Sorry, PHP. That's true. What you're saying is that bork dude has like written PHP for you. Yeah. I'm saying you should be proud of that. Along with the many, many awesome things you have been doing.
01:14:56
Speaker
I'm sure Mickey will be delighted to know he brought PHP to Closure. From that sense, he would. I'm sure he would be. What I mean, my question is, when somebody is going to write my Closure to PHP compiler?
01:15:10
Speaker
Exactly. Yeah. I think don't give him ideas. He's got enough ideas. We don't need to give him any more. I find Varduk awesome because like sometimes you see a problem that you don't even care that much about the problem. Just like, oh man, yeah, this is not working. But you know, it's not a big deal. Like my last experience with Dean was kind of with me in there.
01:15:36
Speaker
I was like, yeah, definitely with Babash because they can't use me. And it's kind of like, why? They say, oh, not running. And then, and then I like, I go do something else and I back to my computer one hour later, later there's work to do. Hey, by the way, 80% of it's working out. I just have to finish this. This is like, what? He's awesome. He's awesome. Yeah, definitely.
01:16:04
Speaker
So that seems like a feature of the podcast, almost every closure podcast these days, you know, it's the book dude is awesome feature. He's also one of the release notes. Anyway, there is a book watch or something that on the closures that
01:16:20
Speaker
Yeah, because I mean, you have to separate. Yes. He needs his own segment in every closure media. Yeah, because he alone produces half of the open source work of the closure community. Exactly. He needs to be protected at all costs. The bus factor is ridiculous.
01:16:47
Speaker
But on that note, so is there any, I mean, but the question was, it was reasonably serious, I think, you know, like, is there something that, you know, closure you're waiting for, or something that is going to, based on your experience, that this is going to, you know, take closure to the next level that you think
01:17:14
Speaker
apart from the deployment stuff that you talked about. Yeah, not right now. There was a feature I was waiting for a long time, but landed on Clojure 111. That was the lightweight aliasing of keywords. I even tried to pouch for it, put it into my talk, say, hey, I care a lot about this issue.
01:17:35
Speaker
That was the big one for me, because this makes much more easier to handle the long attributes. If you're really trying to go full in on that, it was a pain in the past that you have to have a namespace if you want to use Alias, or you have to write the full thing. So now that you can have that, especially in Closure Script, because in Closure, you could hack it out by writing require and then alias on the app itself, and that would work.
01:18:05
Speaker
but not on Clover Script. So now I think this opens the space for it. Other than that, maybe better error message access, but... I think at this point, everybody got used to it. I think if it changes, then everybody is going to get pissed, I think, now. If the error messages get better, then everybody's like, what the fuck is this? I can't understand anything anymore. I want those 2,000 line stack traces with Closure RT.
01:18:32
Speaker
I think they see it as a solved problem now, you know? Yeah. I mean, I don't have much a problem with them, but since a problem, there are a lot of complainants, especially beginners. Yeah. Yeah. I mean, I don't think it's a solved problem, but I think it's, I don't think it's high on the list anymore. Yeah.
01:18:52
Speaker
Yeah. What about you guys? You have something you are waiting for before we move on. What about like the difference between like, we don't use Closure anymore. We just use Python and PHP and BHB. Yes. That's why we're so excited about Babashka, the PHP. There's a question I had for you about the Closure stuff was like, you're using spec, I think with, um, with some of the Python stuff. So how is that working out?
01:19:21
Speaker
Not with petal itself. I mean, for petal development, I use guard rails, which is, uh, from Tony K as well to spec the functions, but it only runs if you specifically ask it to, uh, you can do it via a flag on the JVM or via a define some color script.
01:19:41
Speaker
So it helps me out because keep checking the input and output of every function. I like that for it. But on pattern itself, if you just use pattern window nothing, spec is something you can plug on the outside or not. One thing that I've been doing in that sense is that I wanted to use the QL as a language to also not adjust to the main data, but also to validate data.
01:20:09
Speaker
So this kind of looks like what spec2 does. But I wanted to do with spec because we're all waiting for spec2 to be final to start using. But I wanted something like that. So write a small library that can get an EQL, get a piece of data and validate. So we can ensure it has all the attributes you ask and if the attributes match the specs they have.
01:20:32
Speaker
And this is what we want to use for validating messages or any kind of a chip, any points we need. So if you're like a Kafka message, you can, you can specify the scheme of that using an EQL schema. So that's the closest thing I've been using. The most interesting thing, the way I think of using spec lately. Yeah.
01:20:56
Speaker
I wasn't aware of that actually, but that's really, yeah, that's really interesting. Nice. So I think I still have my question left, so use the Macs of some other shit. I have listened to the last released episodes of you, so I'm not sure what happened on the one you didn't release yet. But if that wasn't in Macs, I'm breaking the streak here.
01:21:23
Speaker
Because there was a lot of emacs going on. Then I'm not going to publish this episode. You know that. It depends on the answer. We only need to use emacs episodes now. That's why all the episodes have emacs episodes. Yes. Sorry, we've been going for an hour and a half now, but if you don't use emacs, it's a waste of time. Exactly. The entire audio file goes to dev novel and we're done.
01:21:50
Speaker
And then if somebody asks Wilker, Wilker who? I have no idea. I mean, normally you ask this question early doors to kind of cut the conversation short. Yeah. Yeah. Yeah. Usually this is the first question. And then that decides whether we should record or not. Yeah. Well, I've been, I've been a VN user for a long time, actually. Okay. But nowadays I am an IntelliJ user for the most. Yeah. But I recently also be thinking about trying the MX thing. So it's on my,
01:22:20
Speaker
It's all right, Lisa. I feel like I'm ready to try a new editor. I knew editor. I just been there for 40 years. Yeah, I knew for me. I knew editor for me. Yeah, of course. I mean, I went home in Vin. I spent five, six years doing Vin. And then I went to IntelliJ because it just worked. And then I said, oh, I made a lot of Emacs. Sounds interesting. They're like, oh, I have to learn a lot of these key bindings again. I'm not. And then I put it for a rest. And that was like four years ago.
01:22:49
Speaker
So now I think I'm on a point that I'm ready to try again because I've been trying other editors. I made a setup for me on Sublime, on VS Code or Atom Australia.
01:23:01
Speaker
But kind of all they suck to be honest. Yeah. For you anyway. They always have this. Yeah.
Exploring Emacs and Editors
01:23:08
Speaker
So I think they have given a new chance to Emacs. I mean, they all have their browser cons. Yeah. I think you're just licking his toes at the moment though. Come on.
01:23:21
Speaker
Just try to get your episode published, you know. Yeah, exactly. We have to do the politics, right? I mean, all this time I show my dog, I have to get this dog published. The only reason we continue to record is because of your dog. And now with Emacs, you are going to be willing to try. So that's fair enough, I think. Yes, I got it. Yes.
01:23:45
Speaker
I think if you're really into WIM, then I can recommend, I think, trying Doom Emacs maybe, because that's a really WIM fanatic. Yeah. But to be honest, I replaced my idea. For example, for me on IntelliJ, for example, I do use something called Ace Jump, I guess. Yeah, that's there. That's already there in WIM and Emacs. Yeah.
01:24:09
Speaker
You're getting very excited now Wilco because he's like, oh, oh, oh, maybe, maybe he will be using that. That is a funny thing because.
01:24:20
Speaker
The reason why, you know, Emacs or WIM are still there is because they are like time tested, open source shit. And regardless of all these editors are going to die in. Okay. There are a few other ones exceptions like BB edit, for example, on Mac, which has been like 30 years now, which is crazy. So there are some... Who's to use next mate?
01:24:41
Speaker
Yeah, exactly. I think it has its peak when Rails was hip and everything, and then it just disappeared. It's still open source, so it's a reasonable editor, but that is the nice part about these things, that they're going to be there. The source is there, so you can compile, you can run it, which is the key part that the whole
01:25:03
Speaker
free as in beer sort of thing that people keep missing and it's not just because it has features I'm not saying it's the best editor because I do you know every now and then I'm poly editor sometimes and then I switched to other ones and recently I started using noah which is like a commercial editor from panic which is a those guys are mac software builders for ages what's what's the exciting thing about this editor
01:25:29
Speaker
No, it's just a native editor. And they actually wrote their own text engine because they found a lot of bugs in Apple's text kit. And then they just made their own thing. And it's blazing fast. And it's beautiful to look at because it takes all the Mac aesthetics into it. But anyway, nothing is going to make me go away from Emacs anyway. That's the whole point.
01:25:54
Speaker
Yeah, I mean, if you use Ace Jump, for example, there is Ace Jump for everything in Emacs, including buffers and all that shit, and everything can be Ace Jump. It's super cool.
01:26:07
Speaker
Yeah, I mean, I think when you combine this jump and par edits, then I don't miss the VIN stuff anymore. Yeah, yeah, that's anywhere. And I can operate with this structure stuff. So these makes me don't miss as much the VIN, the VL, the VIN surrounds and deletes. Yeah, yeah, yeah. And do you think this editor like compare?
01:26:28
Speaker
Oh, I was just curious when the editor you're saying, how do you compare it with Sublime text in terms of performance? Because Sublime is, like, well- That's true. Yeah, yeah. I haven't used Sublime in anger, but I'm pretty sure it would live on par. Because also, it's very much optimized for Mac, right? So it's really just one hardware application, one software application. So it's a, yeah.
01:26:57
Speaker
It's an expensive one, but some of the Mac software that I buy, because there is a certain sense of aesthetic to it. They just look nicer on Mac. They play well with the whole operating system. The rest of the shit looks like the electron crap, and none of it works as it is supposed to. Sorry.
01:27:25
Speaker
Anyway, I think that concludes our editor segment of this.
Conclusion on Editors Discussion
01:27:30
Speaker
Any other things that we missed, Welker? Because I know you've been at doing Pathoom for, I think, what it seems to be like 30 years now. After pandemics, yes. Yes, exactly. Did we miss anything? Anything you want to highlight before we conclude? Oh, no. I think we went through all the important stuff.
01:27:53
Speaker
I mean, the other project I work sometimes is workspaces, but then I think it ended up being a niche, a niche productive thing for full-flow developers. But if anybody wants to take a look, I think it's a nice alternative for dev cards or storybooks. But to be honest, storybooks better. And if you can do storybooks, just go for it.
01:28:15
Speaker
Yeah, you're not a great salesman. He wants to archive it. That's it. Nice. Anyway, but Wilco, it's a pleasure to see you again, virtually at
Closure D Event in Berlin
01:28:31
Speaker
least. Hopefully, we'll meet again in person. I know that
01:28:35
Speaker
So Closure D is on, will be there. The whole, the entire crew and cast of DeafN will be there. So all three of us. What Closure D? Yeah, Closure D in Berlin. When is it again? June? June 11th. Yeah. June 11th. I can't check it. Maybe you should fly in. I should check. I have a festival to go to in Europe this year. Oh, okay.
01:29:03
Speaker
They're going to be waiting for you. I got the ticket in 2019, so I'm really looking forward to it. That's a common thing, isn't it? Yeah. Keep on canceling and then saying they'll do it again. I actually see the dates, yeah.
01:29:18
Speaker
to do about that and shoot with Debbie, right? I have to now care about Debbie. That's a blocker for traveling now. I'm bringing my dog to Closet D, so, you know. It's not as far away in fairness as it is. Yeah, it's just, I mean, give or take a few hours compared to Brazil. Yeah, I'll see if I can show up. I'll be really good.
01:29:43
Speaker
Yeah, that'd be super nice. Yeah. Yeah. Yeah. Well, I mean, you know, maybe as we can, maybe as we can come to some conference in Brazil, you know, closure south.
Closure Developers in Brazil
01:29:52
Speaker
Oh yeah. Yeah. That would be pretty much entire closure. 99% of the closure developers are in Brazil now. So it makes sense to show up there, I think.
01:30:04
Speaker
Yeah, they got not just the thing, they got locked the company and then they told me everything. We've got no excuse not to go there. It seems like Brazil is the new Mecca foreclosure. We just need to go there and then make a pilgrimage. I think if we can put it on business expenses, it works for me.
01:30:25
Speaker
We should always do that. That's why it's great to do the talks abroad, right? We have company expenses for the trip and it works great for everyone. Totally. Excellent. I think we should say, go and subscribe to our Patreon, so give us money so we can go to Brazil. Oh, yeah. Definitely. Definitely. You want us in South America. Yes, we do. Taking some kayaking and stuff like that.
01:30:52
Speaker
Yes.
Guest’s Contribution and Future Projects
01:30:55
Speaker
Awesome. Welcome. It's been a pleasure and, you know, awesome work doing, you know, with with Patham and also full crew work. I know you've been, you know, very active in the community in that sense. And also you're you're pushing things forward, right? You're thinking about the next level of next next way or better way to solve the problems that we have. So that's that's really amazing. So
01:31:19
Speaker
You know, we'll keep an eye for the new thing that you're thinking about. So I think by the time this episode pops out in a few weeks, I'm pretty sure you will have a new repository and your whole architecture will be there. So no pressure. And I'll bet the project's going to be called Debbie. Yes. She's very super cute. So look after her and take care of yourself. Yeah.
01:31:47
Speaker
I like to thank you. Thank you very much. Thank you for having me. I love your podcast. I think you do awesome work. Thank you. People are spreading things around like I've been listening to a lot of podcasts and like it's a great place to get to the edgy high-end stuff. So I really appreciate all the work you're doing as well. So thanks for having me.
01:32:10
Speaker
We don't, we don't, you know, we're not high on information, but you know, with the noise, yes. Signal to noise ratio is pretty shitty, but okay. No, no, it's just nice. Thanks a lot Wilko and good luck with Debbie. And, you know, please post photos on
Dogs and Their Appeal
01:32:31
Speaker
Twitter. So, you know, when they start having problems with her, I'll ask her tips, dog tips from, you know, of course.
01:32:40
Speaker
This podcast is moving over the dogs. I mean, yeah, it's a wider audience. I mean, you know, we can certainly two more people then close it up. Fantastic.
01:32:54
Speaker
Thank you for listening to this episode of DeafN and the awesome vegetarian music on the track is Melon Hamburger by Pizzeri and the show's audio is mixed by Wouter Dullert. I'm pretty sure I butchered his name. Maybe you should insert your own name here, Dullert.
01:33:11
Speaker
food there.
Supporting the Podcast
01:33:13
Speaker
If you'd like to support us, please do check out our Patreon page and you can show your appreciation to all the hard work or the lack of hard work that we're doing. And you can also catch up with either Ray with me for some unexplainable reason you want to interact with us, then do check us out on Slack, Closure in Slack or Closureverse or on Zulep or just at us at Deafened Podcast on Twitter.
01:33:40
Speaker
Enjoy your day and see you in the next episode.
01:34:16
Speaker
Hello, everyone. I'm not sure where this part shows up in the magic that Walter does later.