SOBRE ESTE EPISÓDIO
Our guest in this episode is Patrick Alff, an experienced technical manager and entrepreneur. During his long career, Patrick was involved in several large projects that use domain-specific languages and model-driven development to tackle complexity with great success.
HighlightsI’ve always been very keen in the well structured approach, and I’ve always been very intrigued by inception (…): how do multiple people create something together? And also about collaboration: how do you make it such that people of different backgrounds, different knowledge, understand each other, can communicate together? I think these things brought me into this model-driven design and DSL environment and made me a big fan of all that.
If the software development takes, let’s say, one day, all the activities around it take four days (…) It’s mind blowing, really. That’s how I got into this thinking about, “Okay, how can we make this more interactive, faster, less expensive? (…) That’s how we started this whole MARTE Project.
When you draw a diagram of something, and/or you describe a protocol of something that’s ruled or something, it’s very abstract. (…) The sooner you can make it executable and simulated and make it work, the sooner (…) the inventor or the creator of the process or the algorithm, can actually put himself into the shoes of the user, and see, “No, it’s not quite doing what I thought it would be doing,” and fix it.
The medical people got way more involved in the design of the algorithm. Whereas before we had basically one iteration with maybe on second iteration to fix whatever was really broken at the very end after 18 months, now, they would get immediate feedback on how that algorithm worked.
If you cannot see any communication problems between different expertises, then you don’t need DSL. It’s domain-specific, that’s what the DS stands for. (…) But if you need to communicate your code or co-design your code, I mean the code not the GUI, with people of a business or often industry who are not in the software industry, then you should consider a DSL.
We want to develop what we call the Virtual Mental Health Clinic, which is a behavioral digital therapeutic solution. (…) We will be using something that’s recent as well, which is what we call Behavioral e-Biomarkers. It will enable the psychiatrist to manage the therapy based on data collected by the patient’s behavior in a companion mobile app.
TranscriptPersonally I believe that DSLs are great. Don’t abuse, but for a right purpose they are just great. Now what’s very unfortunate is it’s not a mainstream thing. It’s not a buzzword, nobody talks about DSLs. (…) Don’t underestimate the work you need to do to sell it within your organization and to your management, because you have no outside support.
Sergej: Welcome to Beyond Parsing. This podcast is dedicated to language engineering, creating custom languages, and using them to develop domain-specific software tools.
Federico: We are your hosts, Federico and Sergej, two language engineering consultants.
Sergej: Our guest in this episode is Patrick Alff, an experienced technical manager and entrepreneur. During his long career, Patrick was involved in several large projects that use domain-specific languages and model-driven development to tackle complexity with great success.
Federico: Hi, Patrick. Thank you for joining us. Me and Sergej are very happy to have a chance to talk again with you. We have all worked together in the past, but for our listeners it would be nice if you can introduce yourself and tell us a bit about your experience.
Patrick: First, thank you very much for inviting me to your podcast sessions. I’ve been looking forward to that for a long time. Yeah, well, what can I say? I graduated as a software engineer a long time ago in 1983. I guess some of our audience wasn’t even born when I graduated, but I’m still a software architect at heart. Since 1984, I spent most of my career in enterprise communications, network technologies, developing mainly software products and leading R&D teams. Throughout my career, I was very fortunate because I got an opportunity to work with brilliant people and great products as well. I spent 10 years that were very exciting back in California. Led some really great teams in Paris, in London, in Luxembourg, and in Brussels, too. So, I’ve been traveling quite a bit over the years. Yeah, that’s what I can say about me.
Federico: One of the reason why we wanted to talk with you is because of your experience both with model-driven development and with domain-specific languages later. It would be nice if you can tell us about the project in which you use model-driven development.
Patrick: Yeah, for me, that started back around the year 2000, actually. When I was in California, I joined Infonet Services Corporation, which was a company that built enterprise networks. We had to develop, let’s say, management tools, capacity planning, and network planning tools for the infrastructure learning. The only way to do this, because it was very, very complicated, was really to start describing the models and then implementing those models. That’s how I got into this approach.
Patrick: Back in 2000, of course, at that time we didn’t really have a lot of tools to do it, so a lot of it had to be done manually. But then later, in 2006 I led a project at British Telecom where we actually used the Eclipse EMF environment, and that was a solution to provision complex enterprise networks. We did that together with Cisco and NTG, which is the Network Management and Technology Group. That was very interesting because they had a model-driven provisioning tool for the routers and network gear, and we built on top of that a model-driven environment to configure the services that BT were selling to their customers using this environment. That was the very beginning, and later on, I joined Voluntis, and that’s where we got to work together.
Federico: So, in these projects, the users of your model-driven solution were engineers, like telecommunication engineers?
Patrick: Yeah, so the difficulty at the BT environment and at Infonet we had similar problems is that although we had all engineers who were working together, we had to make, let’s say, software engineers talk to network engineers talk to process engineers. They all have different representations if you like. One to use clichés, the software engineers thinks in class diagrams, the network engineers thinks in network diagrams, and the process engineers thinks in workflows, basically. It’s not very easy, because they try to say the same thing but they have a very different representation.
Patrick: If you draw a cloud, we use two boxes on each side and a line connected to the cloud, that speaks to a network engineer. Software engineer doesn’t really know what this whole thing is supposed to do, right? And the process engineer has no clue what to do with this diagram. We said, “Okay, we need to have one underlying model and have different representations of this model to different people, although they were all engineers in fact, yeah.”
Federico: Okay, so it seems that thanks to the fact that you used model-driven development you build a better common understanding between the teams, right? Common terminology or common view. Is that right?
Patrick: Yeah, the view is not always shared. In the BT environment, we really had to have different perspective with different representation of the same model to different people, which is called multi-perspective view into a model.
Sergej: So, the model is shared but the view is not?
Patrick: Right, that’s exactly it. It’s a shared model but it’s a view that is distinctive from each expertise or each domain.
Federico: Did you use this shared model to generate something or did you interpret it directly somehow?
Patrick: Yeah, the model itself was executable, so it was executed or it did run in a runtime environment, and it was actually going out and provisioning a network gear on the network. These are big, big, huge networks, right? And to make sure everything is consistent, so something is configured on one side in Paris that matching configuration was implemented somewhere else in other part of the network.
Federico: Was it difficult to make the company accept this model-driven idea or were they resistant to it?
Patrick: It is a very interesting question. Because in fact I came into BT, BT had acquired a company I was working with was Infonet Services Corporation, and BT had huge difficulties managing their enterprise networks because it was too complex for traditional approaches. Since we had already started doing model-driven design in Infonet we had this expertise. So, when we actually came in they basically considered us as the saviors basically to solve their problem. It was quite easy to convince them because they had tried a lot of things before that didn’t work, and when we came and we showed them something that had worked in our environment they said, “Okay, that looks like it works.” That was, I wouldn’t say cakewalk, but not far from exactly, yeah.
Federico: Okay. Yeah, it’s difficult to resist when you have a solution already developed that works, so.
Patrick: Yeah, the difficulty then becomes actually to cut loose your legacy investments because it’s millions of things that didn’t work properly. Now they come in and tell them, “Okay, forget all that. Let’s do it differently.” That’s the most difficult part we had to deal with.
Federico: Yeah, I guess there is also some ego involved, someone that decided to invest in a certain direction then you come up with a better solution, it must be difficult to accept it.
Patrick: It is difficult. Beyond that, in fact when you cut loose a platform in a company like that, that means that some people lose their job or their assignment. That’s another difficult decision that you have to take, yeah.
Federico: Yeah, that’s one side. Always to consider more than just the technical aspects. It makes things more complicated.
Patrick: It always comes down to the human factor, and then humans are quintessential in everything we do.
Federico: Yeah. About the human aspect, you have a very interesting experience as you worked both in US and in Europe, and within Europe you worked in France, in UK, in Luxembourg and Belgium. So, I was curious, did you notice any difference between the way of working in software development or in particular about model-driven development if there is a different attitude?
Patrick: Yeah, so what I can say, and this is my personal experience. I can’t speak for all nation, but in the US people are, I think, more pragmatic and they just want things to work. They don’t care that much about how it’s done, so you don’t need to talk a lot about why using a DSL or model or something is going to be great. You just need to show them that it works and it works well and it’s scalable. Once you’ve passed this step, then usually you can move on very quickly. In Europe, there’s a whole, I would say, we talk a lot about proof of concept, proof of technology, and we like to demonstrate it with words and we want to have people who will say, “What if we do this, and what happens if there …?” And something. So, we ask a lot of questions in Europe.
Patrick: This preliminary phase is much longer in Europe where you need to prove that your thing works and answer all the what-if questions. I think what happens a lot then is that it’s difficult to get past this proof of concept, because you spend so much effort and time improving it. It’s very seldom that you get, or it’s more difficult to get to the point where you can actually implement it and scale it and industrialize it.
Sergej: Is this concerning regulated industries like medical or do you find it’s a general trend in your experience?
Patrick: I think it’s a general trend if I look at my BT versus Infonet experience. At Infonet, which was an American company, nobody would ask too much about theory behind it and its architecture, et cetera. If it worked and you proved it worked and it was scalable, then they would go for it. At BT when there were a lot of, let’s say, architects and engineers that you had to convince, managers you had to convince. You had to do more work to convince, or a more convincing work, basically, than in US.
Federico: One question that I wanted to ask you is, how did you find out the first time about model-driven development?
Patrick: Well, because already back in ’90s, I was using a lot of modeling in the networking. And so I’ve always been very fascinated about modeling, and then there was some movement about the UML models and all that that started back then. And so I started looking into all that, and I thought, “Okay, it’s interesting. It would be even better if I could actually make it implementable, right?” I’ve been following this quite closely since the ’90s actually. I’ve always been very keen in the well structured approach, and I’ve always been very intrigued by two things. Basically, inception, so how do you create something, right? How do multiple people create something together? And also about collaboration. How do you make it such that people of different backgrounds, different knowledge, understand each other, can communicate together? I think these three things brought me into this model-driven design and DSL environment and made me a big fan of all that.
Federico: Very good points. We should write them down for our marketing page, because that is just crucial benefits. Now, I will like to start talking about the Voluntis project. We all met because we collaborate on a project at Voluntis, and I will like you to explain to our listener a bit about this project. What was the context? Why you decided to start using DSLs during your time at Voluntis?
Patrick: It was a very exciting and amazing project. First, let me try to explain a little bit what Voluntis is doing. Voluntis is a company that does what we call digital therapeutics, which is basically treatments that are supported by software, right? So, sometimes the software itself can be the treatment. We’ll talk about that later. In general, we have medical treatments or medical protocols, what they like to call them, that medical people come up with, and that we need to translate into executable software. It’s not that trivial. When I joined the company it was like six years ago, and they were doing everything by hand using general purpose languages and they were doing native developments; Android, iOS, .NET.
Patrick: Well, when you do these things the traditional way then you have like a medical doctor who writes the protocol, I like to call it, and then you have requirements engineers who will translate that into technical requirements, and then you had developers who will implement that, and then you have testers who will test that. And 18 months later, you will actually have a piece of code that’s executable, and that’s not doing exactly what the doctor thought it would be doing. That’s in short what was I facing there. This is regulated environment. We need to see e-Mark. If you build something for Europe you need an FDA clearance.
Patrick: If you market something on the US market, so that requires compliance standards, very complicated standards that require a lot of traceability, a lot of documentation, design files, and tons of documentation. It’s a very slow process. It’s very labor intensive, and just to give you an idea, if the software development takes, let’s say, one day, all the activities around it take four days. That activity is like testing, writing specifications. Activities like writing regulatory documentation, doing risk analysis, doing human factor analysis. It’s mind blowing, really.
Patrick: You see that, and it’s like, “Wow, okay, this is just too complicated. It’s like so many different experts who need to work together, and do not understand what they’re doing.” If the medical doctor had found out the day he wrote his protocol or the next day that he was not going to do what he thought he would be doing, and then he might have changed it right away, and it would’ve been much less expensive to change it. That’s how I got into this thinking about, “Okay, how can we make this more interactive, faster, less expensive? How can we make it such that the doctor actually comes up with is exactly what he wanted to do and not something he thought he would be doing, right?” That’s how we started this whole MARTE Project. That’s what it was called. It’s still called at Voluntis.
Sergej: So, there are actually two problems here, right? One problem is that the doctor writes something but the software engineer implements something slightly different. And the other problem is the doctor writes something but the doctor actually wanted to write something else, because what he wrote already doesn’t do what he intended, right?
Patrick: Yes, so it’s two different problems. It’s good that you pointed. One is two experts not understanding each other, which is a doctor writes something and there is a certain interpretation of that, of the requirements engineer or the software engineer who writes it as a requirement. In fact, the implementation itself can differ from requirement as well. So, you have several step issue there. Test engineer might actually have a misunderstanding as well, so it’s like all the way to delivering the final product, there are different experts who can have different interpretations. That’s one thing.
Patrick: The other thing is, and I’m glad you brought that up, it’s very important point, is when you draw a diagram of something, and/or you describe a protocol of something that’s ruled or something, it’s very abstract, right? You’re not in execution mode. You would always forget something, or always something would come up that, “I didn’t think about it that cornercase.” The sooner you can make it executable and simulated and make it work, the sooner the person who is, let’s say, the inventor or the creator of the process or the algorithm, can actually put himself into the shoes of the user, and see, “No, it’s not quite doing what I thought it would be doing,” and fix it. It’s very important to do that very early on in the process, and not wait 18 months for you to go back and say, “No, it’s not doing what I thought it would be.”
Sergej: Right. 18 months sounds a bit extensive.
Patrick: But that’s what it takes for a medical software. You go through the different phases. Some of them are just not compressible. It takes 18 months. If you’re lucky, it could take 12 months, but-
Sergej: So, of course, your solution was to use DSLs, right? That’s why we’re in this podcast.
Patrick: Yes. Of course, yes. Because there’s one big difference between what happened in the telco industry and what happened in the medical industry. In the telco industry they were all engineers, and so they had different disciplines but they were all engineers. Now, in the medical world, you have medical people and you have engineers. The brain is not wired the same way, I can tell you that. So, they really have a hard time understanding each other, so I think it’s not realistic to believe that a doctor, an average doctor, can actually write code using a DSL. But what you can do is you can have an engineer write code on a DSL that’s specific to the medical domain that you’re working with, and you can have the medical person understand that DSL or that program that’s been written in the DSL. That is what we’ve been trying to do in Voluntis, and that worked.
Federico: I think in this case whatever reduce the time from 18 months to less than 18 months to figure out the problem because you can show the application sooner to the medical doctors. There’s a lot of saving.
Patrick: Yeah, as you know, Federico and Sergej, the Voluntis solution in DSL was actually interpreted in runtime environment, and so we actually built a simulator where the medical staff and the consumer could simulate the algorithm right away. That was very useful. First, as good engineers, of course, we all thought that, “Okay, this is drastically going to reduce the time to develop an algorithm. And then once the algorithm is ready we just drop it in the application, and hey, magic happens and it works.”
Patrick: Then what happens, of course, is that the medical people got way more involved in the design of the algorithm. Whereas before we had basically one iteration with maybe on second iteration to fix whatever was really broken at the very end after 18 months. Now, they would get immediate feedback on how that algorithm worked, right? They could play with it in simulator as if they had it on the patient’s app, and then we would say, “No, no, we’ve got this cornercase that we need, and this other cornercase, et cetera.”
Patrick: So, what happened then is that medical people were just like, “Keep adding stuff to the algorithm modifying it, changing it. We had one algorithm where we had 18 iterations just to get one algorithm solidified. And then we faced another problem which is that in the end the algorithm is so complex that we as engineers felt very uncomfortable putting it out there. It was like, “Wow, how are we going to test this? How are we going to make sure it works?” This is way too complicated. Then the solution to that was, “Okay, well, that medical people can’t understand, we’ll tell them, ‘Well, if it’s too complicated, there’s a big risk that they will make mistakes and things go wrong, so we need to simplify it.”
Patrick: But then they don’t have no sense for what is a simple and what is a complicated algorithm? So, they have to basically implement the complexity index that was computed based on the different branches and operations that were in the algorithm. And then we told them, “Well, you cannot see this particular level of complexity for this type of risk in an algorithm.” And that worked. They scaled back and they said, “Okay.” We trimmed the algorithms, and then we scaled it back slightly so that it would fit the criteria that we had defined. But the difficulty becomes now, how do you test it? Because we would have thousands and thousands of possibilities and datasets that we need to crunch through the algorithm to verify that it’s working properly, because for the FDA, for the regulators you need to prove that every branch of the algorithm and different combinations have been tested and that we have a high level of confidence that the algorithm will works as designed.
Federico: I was thinking what you were saying that you had the 18 iteration if I’m not wrong, that if each iteration took 18 months as it took initially one, that would’ve been 27 years, something.
Patrick: Yeah.
Federico: Maybe a bit long.
Patrick: It’s a lifetime project right now.
Sergej: But that looks like this new success brought with it some new problems.
Patrick: Yeah, so in fact the algorithms became way more advanced and complicated than before. Now, because we had to deal with this complexity that emerged from it, we still have to reduce the time to develop. We’re not talking 18 months any more to do a development, but we still have a lot of iterations, a lot of interactions. The good thing is also with this kind of approach it’s quite easy to validate an algorithm with a broad of doctors, because usually we have one or two medical people actually would work on protocol, right? And then they need to validate it with what they call key opinion leaders and different people.
Patrick: It’s so much easier when we can show them how it behaves in the real world, and then showing them tons of paper on how it works, right? All that was great for Voluntis is that in the end Voluntis is recognized as the world leader in algorithms for digital therapeutics. Everybody sell out Voluntis, yeah. Voluntis has the most advanced algorithms in oncology together with this stuff. That’s the good side effect that we have.
Federico: Quite impressive. Frequently we focus just on the languages we build but sometimes we forget about what they make possible. It’s also good to think about the context from time to time.
Sergej: I guess it wasn’t all smooth sailing, right? It probably never is. So, did you also have to convince people at Voluntis that DSLs are the way to go like you had at BT?
Patrick: I had to convince people but at a different level. So, because in the, let’s say, medical device and pharma industry, people are very theoretical in their approaches, basically. It was not difficult to convince them that, “Hey, this mighty approach was going to be a big game for us.” It was way more difficult to solve the software engineers. In particular those people who are in general purpose language and developers who developed for iOS or Android. Usually, they’re not very pragmatic. They’re very dogmatic, as I call it, about using the designed patterns that Apple has imposed on them. And then when you come with something new that they need to include in their app, that’s very hard for them.
Patrick: It’s been really hard some of them to accept that, and it got to the point where actually one of the lead developers had to quit the company because he refused to implement.. because the runtime environment was written in C++, and so it was a library that we needed to include and he refused to do that.
Federico: As you were saying that the human factors has always implementations.
Patrick: Yes.
Sergej: But hat’s an interesting kind of a fallout or a side effect, but you introduced DSLs into the company and somebody quit because they don’t want to use C++ libraries in iOS or a totally different side effects somewhere else.
Patrick: Side effects by nature are usually unexpected.
Federico: We need the DSLs also to model that.
Patrick: Actually, if I can maybe elaborate a little bit on that, it is important also that we do not try to convert somebody who is an iOS developer or an Android developer or software developer to be using your DSL because most of these people don’t want to do that. So, it’s much better if you bring in an engineer, like in our case things like health engineers. Those are people who usually work, I don’t know, scanners or imaging or some kind of diagnostic tools or whatever. But they know enough about medical world, and they know also about software. These kind of people are very eager to have the programming language that’s more restrained and that’s very focused on what we need to do, and they are really good developers, with DSLs. I highly recommend to take that past reasoning trying to convert the GPL developer to DSL.
Federico: I think I will like to talk also the next three hours about the MARTE Project, but I want to make sure we also talk about your new company. I don’t know, Sergej, if you have more question on MARTE before we move on?
Sergej: Yeah, I guess maybe not specifically on MARTE but we have this newsletter about our podcast, and before recording this episode we sent a question to the readers to ask if they have any questions for you. One of the questions was, how do you know when you don’t need a DSL? Because sometimes you think you need one, but actually it turns out it doesn’t make sense for some reason. Because, Patrick, you are a big DSL advocate, how would you recognize a case for example where you would not use DSL?
Patrick: I would say if you cannot see any communication problems between different expertises, then you don’t need DSL. It’s domain-specific, that’s what the DS stands for. If there’s nothing domain-specific you need to solve, and if everybody in your team can understand whatever you’re using, whether it’s HTML or Java or whatever, then it’s not an issue. But if you need to communicate your code or co-design your code, I mean the code not the GUI, with people of a business or often industry who are not in the software industry, then you should consider a DSL. That would be my short answer to this.
Sergej: Can we also say that heuristic for model-driven development is the same or do you see some difference between DSL and MDD here?
Patrick: I have a tendency to cross-pollinate the two, and to me DSL in the end represents the model. You’re going to build the model with your DSL and with the concepts, our concepts that are in the model. So, they’re tightly linked in my opinion.
Sergej: Yeah, and I think we can say they’re in a way tightly linked or interchangeable sometimes even.
Patrick: Some people talk about the domain-specific modeling language. I liked it then but I cannot easily distinguish the two. It’s difficult to me.
Federico: Okay. I think now it’s a good moment to start talking about your new adventure. So, can you tell us, what are you working on right now?
Patrick: Now, I’m setting up a new company. It’s called ODDITY-X, and this company will be specializing in e-mental health. Many people don’t realize it but mental health has become a big issue in our society, and mental disorders affect one in three people in their lifetime, and one in five each year. The World Health Organization tells about the global crisis. For example, in France, we had a few years ago 11,000 suicides. That’s three times more people who committed suicide than people that got killed in roads. It’s a huge problem.
Patrick: We’ll lack psychotherapists, psychiatrists, and then we need urgent action to be taken in this area. We need to get people easier access to the treatments. We need to have some self-help tools, and we need to improve the efficacy of behavioral therapies. That’s where the technology can really help. We want to develop what we call the Virtual Mental Health Clinic, which is a behavioral digital therapeutic solution. It will be considered as a medical device, so it’s a medical device Class II AOB depending on.
Patrick: We will be using something that’s recent as well, which is what we call Behavioral e-Biomarkers. It will enable the psychiatrist to manage the therapy based on data collected by the patient’s behavior in a companion mobile app. That’s what I can tell you at this stage about ODDITY-X and what we’re doing there.
Federico: I think it’s very important thing, mental health, and I think there is more and more awareness about the problem. It’s a simple fact that I learned about recently. In most countries now when you do private health insurance, it doesn’t cover mental health, but this is changing. For example, now it’s illegal for that to happen in countries like Ireland, so I think it’s a sign that more people in our society are understanding the importance of mental health. That also means probably good business opportunities in the future.
Patrick: Yeah, well, it’s a complicated field. It’s very complicated because psychiatry is really distinct from other medical disciplines. I just spent three days at the psychiatric hospital talking with psychiatrists and participating in consultations and all that. It’s really very different, because in medicine, you identify the cause. I don’t know, if your leg aches then they’re going to take an X-ray or something and find out what’s broken or what’s wrong with your leg. In the brain, it’s really, really more complicated, and it’s based on symptoms that the therapist needs to find out, and then they’re going to say, “Well, okay, this person has bipolar disease or has schizophrenia disease or whatever.
Patrick: But the cause, the dysfunction of the brain could be very different cause for two people who have the exact same symptoms. So, it’s really difficult, and that’s why psychiatry is not well regarded within the medicine discipline because they don’t have the absolute proof of what’s broken and how to fix it. It’s really complicated.
Federico: For a moment I thought that psychiatry is to medicine in general what software engineering is to the other engineering disciplines in the fact that in the other disciplines it’s easier to give answers while in software it’s so always difficult to do estimates, it’s always difficult to have something that is objectivem, ut’s clear, it’s certain, seems a little bit the same in psychiatry.
Patrick: Yeah, it is, and it’s good that you mentioned this. In fact, prescribing some drug is something easy to do, but it does not necessarily work well for some of the mental diseases or mental health conditions. Yeah, in fact, there’s a statistic that was made in the UK where 78% of the general practitioners, the doctors actually said that they’ve prescribed dose to patients with mental problems just because they didn’t know what else to do, and they didn’t know how to deal with it.
Sergej: That’s a bit sad.
Patrick: Yeah, it’s a big percentage, but we need to avoid these situations and help people, really help them, and not just give them some sleeping pills or something to solve their problem.
Sergej: I don’t know if you can go into a little bit more detail about how ODDITY-X will work, or you mentioned some e-biomarkers, can you maybe describe what these could be?
Sergej: I don’t know if you can go into a little bit more detail about how ODDITY-X will work, or you mentioned some e-biomarkers, can you maybe describe what these could be?
Patrick: Traditionally, mental health does assess, let’s say, the condition of a patient using what they call standardized questionnaires. It works with scores, and so these are filled in by the patients or by the therapist if the patient can’t do it. Now, that’s one way to look at things, but then there’s no reality check behind this, right? You don’t know once the patient leaves the doctor’s office how he behaves and what happens. And so recent studies and clinical trials have demonstrated that by observing the social behavior and the activity of a person, you can actually say a lot about their mental health.
Patrick: For instance, if someone who has depression has a tendency to not being physically very active, or someone who suffers from a bipolar disease will have mood swings, and those translate into variations in their physical activity. Their use of social networks or a visit to certain places and friends. So, by observing how the patient behaves, you can say a lot of things. For instance, if somebody, let’s say, is diagnosed by a marker for depression. Depression means you become really slow and not motivated, and you don’t do a lot. But that’s what we call unipolar disease, so it’s a condition.
Patrick: But there are people who have a bipolar disease, and that’s different. So, they have phases where they’re completely depressed, and they have phases where they’re extremely active; euphoric. They do things, and they’re hyperactive almost, right? When they get into this hyperactive mood, that can actually turn into a crisis where they really need to go to a hospital and can’t manage themselves and do crazy things. This bipolar disease is not necessarily detected by a doctor. It’s difficult to say because if each time the patient comes in and says, “I’m depressed, I don’t feel like living any longer,” doctor does not know that when next day patient is going to be in a different state.
Patrick: By observing the behavior of patients these things can be made visible to the therapist. Also, the therapist can compare what the patient says to what has been observed, right? So, a good example is sleeping. When you ask a patient, “How’re you sleeping?” If the patient slept well for the last three days he’ll say, “I’m sleeping well. Everything is fine, right?” But if the week before he didn’t sleep at all, we will forget about that. We will not mention that but it might be really important to the doctor to know that, right?
Patrick: That’s where biomarkers come in. There’s other biomarkers and things like prosody, that’s the way you speak, and that can be an indicator for schizophrenia crisis for instance. Or there’s eye tracking technology as well. That’s predictive for conditions like post-traumatic syndrome or for even depression and schizophrenia, even autism can be detected that way. There’s a lot of things, behavior, that actually show our mental condition. Another one that’s very impressive is by looking at the facial expression of somebody you can actually say whether the person is depressive or not. It’s like 18 points that they identified in the face, and by analyzing that, you can actually diagnose somebody to be depressed or not.
Sergej: That sounds incredible. How reliable is this, do you know?
Patrick: An engineering question, yes. Well, in fact there have been studies made. There’s one study they made in California which is very impressive where they did diagnose patients, I think it was cohort of 50 patients using questionnaires like they do traditionally, and using biomarkers. Guess what, the biomarkers were as reliable as the questionnaires. It’s a 90% reliability they had in this particular study.
Sergej: Okay, it sounds very impressive.
Patrick: Yeah. Yes, so there’s a lot of things there to explore, and I’m really looking forward to work in this field and make it available to therapists. Because today, a lot of it is still in the labs. We really want to bring it into the practice. That’s what we want to do.
Federico: Before we conclude that, we will like to ask you if you have a closing message or something you want to tell to our listeners?
Patrick: Yeah. Well, what I can say is that personally I believe that DSLs are great. Don’t abuse, but for a right purpose they are just great. Now what’s very unfortunate is it’s not a mainstream thing. It’s not a buzzword, nobody talks about DSLs. It’s not like machine learning, artificial intelligence, data, cloud, and what have you. When you’re throwing these buzzwords and everybody says, “That’s great.” You talk about DSL and people look at you, “What’s he talking about?”
Patrick: There’s no big names behind them as well. The gaffers are not really working on it, so it’s an insider thing, and to make these paradigm shifts happen in companies it’s complicated because you have no real outside support, so you need to prepare very well for that. You need to think beyond your proof of concept and how you’re going to scale it and how you’re going to apply it. You need to get buy-in across the company. I think that’s really important, and that would be my message. Don’t underestimate the work you need to do to sell it within your organization and to your management, because you have no outside support. You will not have an IBM or an Amazon that will sit alongside you and tell you, “This is great. Do it.” That’s my message.
Federico: Hopefully, over time we can build an ecosystem that support companies that use DSLs, but it’s true that right now there is not the IBM of DSLs.
Patrick: No, but it’s much better than 10 years ago, so we have to look at that way.
Federico: Well, then I will like to thank you Patrick for taking the time and share your expertise. For me it was super interesting, and I think it will be also for our listeners. So, thank you very much.
Sergej: Thank you.
Patrick: Thank you for having me, and this was really a pleasure for me. Thank you.
Sergej: Thank you for listening to this episode of Beyond Parsing. We are your hosts, Federico and Sergej, two language engineering consultants.
Federico: If you want to learn more about domain-specific languages and language engineering visit beyondparsing.com.
The post Interview with Patrick Alff appeared first on Beyond Parsing.
