Why this interview?

Scott McKinney is the creator of Manifold, a plugin that supplements Java with powerful features. In this interview with Scott McKinney, we’ll try to figure out more about his work.

Here there are some quotes I found particularly interesting:

We built the rules engine, and it was very successful. And then that led to “Well, maybe we can use this over here. Maybe we can use that over there”. And one thing led to another, and one day you wake up and you have a general purpose language.

Manifold is a plug-in that offers an SPI, which is a service plug-in interface, and API for other people to plug in. So, if you want to write an XML or an XSD Manifold you can do that. Now, all XSD files, all XML files, they suddenly all are alive in your IDE, and there’s nothing more you have to do. All the changes you make are automatically recognized.

Other languages, like C-Sharp, Scala, Kotlin, a lot of the newcomers, they have extension methods. You can add your own method, logically anyway, to another type. Well, Manifold does that now, using the same general principle here. (…) . It’s basically a projection of code that the compiler believes is the types code. And then, you’re just sort of faking out the compiler that it thinks that method is on a clash, but it never really gets there, in terms of byte code on disc. It’s just a façade. And then internally Manifold rewrites the byte code to make it call this other thing that you invented.

Manifold doesn’t make you do anything strange (…) You just put the stuff in your gradle or Maven dependency list, and add a compiler argument, and that’s basically it. It’s a little more involved but not much, and it’s on the website. And it’s sort of self explanatory, but I think getting people to that place, where they want to experiment with it, that’s the trouble, at least with the type Manifold aspect.

Federico Tomassetti: Hi, Scott. Thank you for being here with us today. Very happy that you find the time for this interview. And how are you today?

Scott McKinney: Oh, I’m great. Great. Thanks for having me.

Federico Tomassetti: Good. We will getting started with the first questions. And can you just tell us a bit about you and your work history?

Scott McKinney: Sure. I’m an old guy, so I’ve got kind of a long work history, but I’ll try to be brief while still covering the interesting bits. Let’s see, I started my career with Borland International.

Federico Tomassetti: Mm-hmm (affirmative).

Scott McKinney: They’re here in California where I am. Well, actually, they’re not here anymore, but they were based in Scotts Valley, and I spent a few years there, starting in 91, and that was very interesting for me. I learned a lot there. And then, let’s see, I was part of a program that started. So, very interesting project. Myself and another guy were mostly the only people involved, and that was later sold to Paul Allen’s company, Asymetrix, in Washington.

Scott McKinney: We worked down here for awhile, then we all just moved up there, and then six months later they shut everything down. So, I moved back here, and I started working at Netscape for awhile, and that was a lot of fun. And then, after that, sort of wound down a bit. I left there and started a company with another colleague from Borland, and we started an analytics company. And that was pretty successful. We sold that, and part of that sale involved a contract, a three year contract, that ended sort of abruptly with a .com bust. And I took some time off because I had been working a lot.

Scott McKinney: Then we started with a brand new startup called Guidewire, where I’m at now …

Federico Tomassetti: Mm-hmm (affirmative).

Scott McKinney: … Still, many years later. Let’s see, that was 2002. So, it’s 18 years. And most of my time at Guidewire was working on a language called Gosu, which is a JBM language, general purpose OOP, a lot like Kotlin but predates Kotlin, if you’re familiar with that one.

Federico Tomassetti: Mm-hmm (affirmative).

Scott McKinney: And what we’re going to talk about later is Manifold, and that’s something I’m doing on my own, and a lot of the … A lot of the lessons learned from Gosu are now applied to Manifold, which is a whole separate …

Scott McKinney: We’ll talk about that later …

Federico Tomassetti: Yeah.

Scott McKinney: … But just sort of separate project that concentrates purely on Java.

Federico Tomassetti: Yeah, it’s a very interesting topic, and I think was the main excuse we found for this interview. So, I think we will dive into this. And okay, you name a lot of interesting company, but for someone that is working in this field, building tools special for developers, I am very interested in your experience at Borland. Can you tell us a bit more how it was to work there?

Scott McKinney: Well, my time at Borland, particularly in the beginning, I was just a young guy right out of college, and I worked on a … You’ll probably have to cut this out. I worked on object vision, which was Borland’s first … It was their first product on Windows. And back then that was Windows 3.1 I believe. And that project was acquired, it didn’t start at Borland, it was acquired from another company in Texas. So, a very small start up, a group of guys. Those are the guys that I got to know really well and learned a lot from them in the beginning. One of those guys was a colleague that had started that company that I had mentioned earlier.

Federico Tomassetti: Oh.

Scott McKinney: And yeah, I think I’ve learned more there than probably anywhere else at any given time, which is a lot, cause I’ve learned a lot for the past few years. And I wouldn’t say the lessons that I learned there were not just purely technical. It was, you know, how to be a developer, and how to get along, and that sort of stuff. They were great mentors, those guys.

Federico Tomassetti: Yeah. It’s fascinating, like, certain companies seems to be more influential and maybe for Borland was …

Scott McKinney: Yeah. Borland was … I mean, it was a great place to be. It was very exciting at that time because they were sort of at the peak of language development. They were also experimenting with desktop applications. They had a word processor. Of course, we had Quattro Pro. Older people might remember that. It’s a spreadsheet. It was a very, very, very well produced product. And Microsoft wanted to destroy them probably more than any other company at the time.

Scott McKinney: I don’t want to spend too much time on this, but I think Borland they’re probably as much to blame as Microsoft, I think, for their demise back then. Some of the decisions … This is my own opinion, but you know, they made some mistakes along the way, like spending, I think, just more than a year developing IBM0S2 versions of their products, and that sort of set everybody back because we didn’t have separate teams for the 0S2 system. So, we had one team working on that. So, that sort of set us back. We lost a year, at least, in terms of our competition with Microsoft. So, I don’t think that helped much, but there are other things. It was an exciting time, probably the most exciting I’ve had since I sort of peaked early, in that sense. I could never, you know, I could never compete with that again.

Federico Tomassetti: Well, I think you built some very exciting things. I think it would be nice to speak about the first one, Gosu. I know that this is not your main focus right now. We will speak more about your main focus, Manifold, but I think Gosu is interesting because as far as I know was one of the first JVM language that came up. Now we are starting to see a few, like you named kotlin before, or, Groovy, and so on. But Gosu, as far as I know, was one of the first, one of the first ones, and it’s also some interesting idea. So, can you maybe tell us a bit about Gosu?

Scott McKinney: Sure. So, when I started at Guidewire I had no intention of building a general purpose programming language, or any language really. I was hired to work on their architecture. They were just beginning to build. So, just a background, they build property and casualty insurance software for mostly medium to large insurance companies. Right now I can’t even keep track of our customers any more. We’ve got a lot of big ones. So, we start out with just a few guys, and now we have thousands of people and many, many customers.

Scott McKinney: Anyway, I was hired to work on architecture, and one of my first tasks there was to research building a rules engine in language and tools because we did know we needed some type of business logic that we needed to present to the what we called “knowledge workers” at the time.

Federico Tomassetti: Mm-hmm (affirmative). Yeah, that’s a good term.

Scott McKinney: Yeah. Yeah. So, not necessarily programmers, but programmers. It’s marketing always has this dream of somehow connecting the dots between non programmers; it just never works. We just sort of accept it and say, “Okay then.” But I didn’t have a whole lot of luck with finding tools that could satisfy our needs. There were a few rules engines in languages. You know, a lot of them tend to work the natural language side of the spectrum. What we really wanted was something like a good, solid scripting language but that was also statically typed because we also needed stuff like code completion and stuff where you really want to have static analysis, at least a static analysis that’s approachable. There really wasn’t a language like that. You know, just an imperative, nice little language.

Scott McKinney: So, I said, “Okay, we can build this.” I’ve built languages in the past, nothing big. So, we can do this, you know, a nice sort of expression language with some constructs to get us what we need, that sort of thing. Well, we did that. We built the rules engine, and it was very successful. And then that led to well, maybe we can use this over here. Maybe we can use that over there. Okay, well … And one thing led to another, and one day you wake up and you have a general purpose language. That’s sort of how it developed. It didn’t take long, maybe over the course of three years, I think. By the time we had object orientation and all of the ingredients you’d expect, and then over time it just kept on flushing out more and more.

Federico Tomassetti: Yeah.

Scott McKinney: So, accidental language.

Federico Tomassetti: Yeah, because I guess that if you went to the managers the first day, and you asked them if you could build a general purpose language to use all over the company probably they would have said, “No.”

Scott McKinney: Yeah. It was an ending “no.” In fact, I think we talked about this awhile ago, but our company has gone through many phases of why are we doing this? Why do we have this language? You know, the history isn’t there. So, a lot of the newer executives come in, and they look at this and go, “Why? This is for an insurance software company. Why are we …”

Scott McKinney: And I’ve had to give many presentations on the “why” part, and I’ve had to convince a lot of people over and over, you know, sometimes the same people, over and over why we’re doing this. And right now we’re in another one of those phases where I think … We’re emerging from one of those phases where they’re realized, well, okay, we do need it. Now we want to spend more time and resources on it again.

Federico Tomassetti: Yeah. Maybe companies when they are smaller they’re more tolerant to making choices that are uncommon because they need a competitive advantage when they’re establish …

Scott McKinney: Absolutely.

Federico Tomassetti: Yeah.

Scott McKinney: Absolutely. The company now, that we call “Guidewire,” is vastly different from the one, you know, the first five years of our existence. That’s true for any successful company. They’re going to go through changes, and they’re not going to be the same. So, like you said, the kinds of decisions we had to make earlier on were sometimes desperate ones. You know, we have to do this, and we’re under time constraints. We only have one or two customers, and we have to meet their needs.

Scott McKinney: So, features stem from more hostile environments than they do now where we get to call the shots, not so much the customers. You know, when you become so successful that you kind of own the market you can sort of dictate what their needs will be. You sort of set that pace, and that’s sort of where the company is now. And it explains our most recent lapse into this phase of, “Why are we doing this again?” So, yeah.

Federico Tomassetti: Mm-hmm (affirmative). Makes sense. Was it difficult to build a language on the JVM? I mean, I guess the JVM was built originally having just one language in Java. Right? So, I don’t know if it was constraining, or …

Scott McKinney: It really wasn’t.

Federico Tomassetti: Mm-hmm (affirmative).

Scott McKinney: I don’t think the JVM was really ever sort of a roadblock. Well, we really need this feature that isn’t there. There are definitely times where I wanted features that weren’t there because I wanted some other feature to go to, and I had to sort of work around it. But the JVM’s never really been a problem. In fact, really, earlier on, go to wasn’t compiled.

Federico Tomassetti: Okay.

Scott McKinney: That’s not really altogether true. It was compiled into an intermediate form where we sort of had this odd AST that had execution sort of bolted onto it. So, we could execute the AST at run time, if you can wrap your head around that.

Federico Tomassetti: Mm-hmm (affirmative).

Scott McKinney: Which it had a lot of advantages, actually. It was nice, but it was slow. And you know, there came a time when it really caught up to us. The profile was flashing red all over the place, and so we had to make some changes, and of course you have to compile at some point when there’s enough use of your language. So, transforming the old compiler to the new one where we’re generating byte code, that wasn’t that much of a big deal either.

Scott McKinney: It was a learning lesson for me because I really didn’t know that much about byte code at the time. I wasn’t an expert at it. So, I had to learn along the way, but that was an interesting process, learning all that, you know, learning the oddities of byte code and the JVM. Why does tri-catch finally work this way? Why didn’t they … And all these sort of questions and expectations that you have. But I never really felt like the JVM or the Java language was in the way, so to speak. It’s always been a pleasure to work with really. And that extends to our next topic as well. I’m surprised because it’s so old, and I would expect it to be difficult, but it never really was.

Federico Tomassetti: And talking about the challenges of building a language, and this is also a topic that leads the way to Manifold, can you tell us a bit about the tool support and how, if it was difficult, how much effort did it take compared to build the rest of the language?

Scott McKinney: So, if I understand your question, just tooling in general with Gosu …

Federico Tomassetti: Yes. The IDE especially, I mean, building support …

Scott McKinney: Sure. Originally, we had our own IDE that I also built with my team, cause I had done a lot of that in the past as well, and ever since Borland really, and even before Borland, in school doing it, that was my interest. And that lasted only so long. And we had a debugger, and it was very capable, but at some point it breaks down, especially with source control and other integrations that you need in an IDE for a real solid professional headstone work. And as demand increased for the language to be applied in different places in our technology stack we just couldn’t do that any more. So, we were targeting Eclipse in the beginning, and then that just became a nightmare. Eclipse was never really designed for language independence.

Federico Tomassetti: Mm-hmm (affirmative).

Scott McKinney: The JDT and … It’s meant for Java. So, there’s a lot of ways you can sort of change its behavior to fit your language. Weaving and all these things you end up having this huge mess, or you basically take your own branch of Eclipse and build your own, but that sort of defeats the purpose because now you’re off the reservation. You can’t necessarily use the same plug-ins and any of these other things that you’re there for in the first place.

Federico Tomassetti: Yeah.

Scott McKinney: And I’d also, earlier on, had built debugger support and IntelliJ for Gosu as a separate sort of project, with some minimal editing or sort of a lightweight plug-in. But in doing that I realized, wow, JetBrains did this right. This API is exactly what I need, and I want this now. And I actually convinced the IDE team, Guidewire, that we ought to be, you know, let’s drop this Eclipse stuff, and let’s jump over to JetBrains. Internally were were using IntelliJ anyway. So, most of the developers understood, at least, the benefits of the IDE and could … They weren’t so attached to Eclipse. They weren’t so biased, maybe, to it. So, that helped. We went that route.

Scott McKinney: And then, we had several iterations of our Gosu plug-in as well. The first one, it basically piggy-backed on the Gosu parser.

Federico Tomassetti: Mm-hmm (affirmative).

Scott McKinney: Because we didn’t really want to write another one. There was a lot of advantages in that, but there were also disadvantages, and a lot of the disadvantages started to really get in the way. So, we switched over to building a real parser, you know, in IntelliJ terms. And our time constraints were our enemy there. We ended up making a lot of shortcuts and using a lot of Java code from JetBrains to make stuff work. And it turned out a lot better than I expected.

Scott McKinney: The team that was working on that, they were awesome. They got a lot done in a short amount of time, but it showed after awhile. We had yet another iteration to fix up a lot of that stuff. So, now it’s in much better shape, much, much better shape. That’s where it’s at now. It took awhile. It took, I’d say, we’re at, I’m just going to guess, say eight years maybe, before we finally settled on something that we feel good about. It’s always that way, though, with these things. You’ve got product cycles, and if you’re going to sell products and make money you have to decide which of these things am I going to do and which things am I not going to do? Because I can’t get them all. It’s classic.

Federico Tomassetti: But I think your experience with idea, the platform from JetBrains, came very useful when you started working on Manifold.

Scott McKinney: Oh, absolutely. Absolutely. So, Manifold, that grew out of one of these stagnant periods of Gosu within my company, the most recent one. And I had a lot of ideas brewing in my head anyway about there’s a lot of stuff I could do with Java that I think would be really useful, just for my own purposes. But if it’s good for me it’s got to be good for everybody else. And a lot of the ideas came from Gosu. Where else am I going to draw it from?

Scott McKinney: So, I don’t know what subjects you might want to cover there, but yeah, definitely my experience with IntelliJ plug-ins, with Gosu, definitely helped a lot. Otherwise, I don’t think I would’ve had a lot of these ideas. So, it’s one thing to think about the language. Oh, this would be a great feature. I can maybe weave that in through a Java compiler plug-in. Blah, blah, blah. But then you’ve got this other mountain you’ve got to climb that’s the IDE because at least, in my mind, language features are nothing if they don’t have IDE support.

Federico Tomassetti: Yeah. I totally agree with that.

Scott McKinney: Yeah, a lot of guys … You know, I was one of these. Before I started at Guidewire I used the IDE for de-bugging, and I felt like I don’t need all that stuff popping up. I don’t need all that. I use my head. I can remember where all these things are, and what the names are, and what methods run. I can do refactoring and use Grap and blah, blah, blah, blah, blah. All the same excuses.

Scott McKinney: Luckily, one of the guys in particular at Guidewire, really great guy, he was patient with me, and he convinced me, okay, you’ve just got to give this a try. Just do it. I’m like, all right. I’ll spend a week in it. I’ll just immerse myself in this, and I’ll throw my code editor away, which I still like. Just throw all that stuff away, and I never came back. I think it took maybe a day, and I’m like, “Oh, geeze.”

Scott McKinney: I’m glad … His name was John. “I’m glad, John, that you sat me down and made me do this because this was great.” Really, I never looked back. I can’t fathom programming professionally with statically typed language without having an IDE, I wouldn’t say like IntelliJ, but there just isn’t another one like it.

Scott McKinney: I’ve used them all. I’ve used Eclipse for long periods of time, and it’s great and all that, but IntelliJ is up here.

Federico Tomassetti: Yeah.

Scott McKinney: I don’t know much longer it’ll stay up there, but those guys are just … They know what they’re doing.

Federico Tomassetti: I had a similar experience because at some point I was an Eclipse guy because I was writing plug-ins for Eclipse using the Eclipse model and framework, and I was very happy until a colleague of mine, a trip advisor, asked me to take a look at IntelliJ, and I was a bit resistant. But then I tried it, and said, “Okay. What I was doing?”

Scott McKinney: Yeah. It really is. Yeah. And that’s … I can’t believe they’ve kept the pace. Their innovation, for how long? This has been 2002, like it’s 18 years for me.

Federico Tomassetti: Mm-hmm (affirmative).

Scott McKinney: They just, they keep getting better and better. Some things I wish they would just leave alone, but they keep getting better. It’s amazing.

Federico Tomassetti: Okay. Now let’s dive into Manifold. And it’s something new. So, I think it’s difficult to explain to someone that has not seen it before. We will include some video in the article connected to this interview. Can you give us an overview of what Manifold is, what it enables you to do?

Scott McKinney: Sure. Manifold does a lot of things, and that’s maybe one of its weaknesses, is that it does too much. But at a high level what it does is it redefines this notion of a code generator.

Federico Tomassetti: Mm-hmm (affirmative).

Scott McKinney: A lot of the language community will call the subject “type bridging,” where you’ve got your language, and your type system, and then you’ve got some structured data over here, and you need to access that structured data, and how you do that. And for decades the answer has been write a code generator or write some library where you lose type safety.

Scott McKinney: I don’t know about you, but I’ve worked on a lot of code bases that involve a lot of code generation, including the one I’m on right now at Guidewire. And I can’t talk too much about what we have internally, but there’s a lot of code that’s generated, and it adds up. And dealing with it becomes, I think, a liability over time. There are a lot of issues that you have to, or problems, that you have to solve that just don’t go away. And over time you just accept it for wat it is because you don’t really think there’s another way out. And you just … It’s just something that you accept.

Scott McKinney: So, it’s like riding a horse to work. If that’s all you know exists, it sucks, but that’s what you do. But had you known there was a car and roads maybe you would do that instead. So, I’m not saying Manifold is that much of a difference, but I think it’s a compelling difference. And what it does is it changes all of that by teaching the compiler how to deal directly with this structured data. And when I say “structured data” I mean almost any kind of information. I often refer to it as a resource, and Java programmers know what resources are. You might have X amount of resources, or JSON resources, or even JavaScript. You know, you might have other languages, craftQL, Sequel, whatever.

Federico Tomassetti: Maybe let me try to see if I understood. Let’s suppose that you have an XML file that is maybe very, written, according to some, XML Schema. So, normally, you could use in Java the API to get a note of a certain kind, and then you know that this note is always this couple of attributes, but the XML library doesn’t know that. So, it would not suggest, for example, when you have a note of this type you can have the attribute at a known name and address. So, you can try to use it, but you are not sure it will return the results. If you misspell the attribute name you get an error. So, you could instead generate Java classes for each kind of XML note for which you have the structure, but this is cumbersome. It is Schema change. You have to regenerate the code, or you could use Manifold and this would solve this kind of problems.

Scott McKinney: Yeah. That’s pretty much it. You know, you could either use a code generator for XML, as many of those have been around for awhile. Right. But the problem with that is there is this disconnect, and that’s why they, why it, is called type-bridging. Right? You’ve got to bridge. Java’s type system, which is over here, with this XML stuff, which is over there, and that’s where all the bugs are is in between. Right? All of the code generators and writing them, and managing when do I run the code generator? How do I hook this up in the build? Now, in my IED, I can’t … There’s this disconnect. I want to … Where does this method come from on here? Where is this type from? What is this thing? How do I change it? All that stuff is out the window.

Federico Tomassetti: Yeah.

Scott McKinney: Right? And let’s say you could change it. You do know where to go to change it. Okay, I have to change this Schema file, or maybe it’s just a plain XML file. I go make the change. Now what do I do? Oh, okay. I have to recompile everything. Or some smart guy wrote some integrations whatever IDE you’re using, and all this stuff, and that happens to all work. But that’s like a one-off thing that can break. That guy gets hit by a bus. He’s probably the only guy that knows how to fix it.

Scott McKinney: There are all these problems that really pile up, and I’ve just scratched the surface. You’ve got caching issues, all sorts of stuff. And what Manifold does is say, okay, all right, so the main problem here is the compiler doesn’t know what that XML type is. Let’s solve that problem by sort of inverting it. Let’s make the compiler ask for the type and have a way to plug into the compiler to satisfy that type resolution. And that’s really what it is. Manifold provides this connection for you.

Scott McKinney: So, Manifold is a plug-in that offers an SPI, which is a service plug-in interface, and API for other people to plug in. So, if you want to write an XML or an XSD Manifold you can do that. Now, all XSD files all XML files they suddenly all are alive in your IDE, and there’s nothing more you have to do. All the changes you make are automatically recognized. All the …

Scott McKinney: And this is another issue. There is an IntelliJ plug-in, and an Android Studio plug-in where any type Manifold you write that plugs into Manifold automatically works in IntelliJ. So, all the navigation, I want to do control B here, and it automatically connects to the element or attribute in the XML file over there, or what have you, in GraftQL or JSON, or whatever it is. It all just works, and that’s how the code is generated. The API also includes annotations that you can include in your code that make all that work in a standard way.

Scott McKinney: So, just by saying, okay, maybe we can open up the compiler so that the type system is more open and agreeable to this stuff. And all the sudden all these problems they just melt away. But it’s very very hard to get this across. I’ve been waving my hands and flapping my lips to you for several minutes now, and maybe you still don’t understand it. Right? So, using it … Maybe you do. You probably … I think you do by now.

Federico Tomassetti: We have spoken before when I saw the video.

Scott McKinney: Yeah. Yeah.

Federico Tomassetti: It’s true that it’s maybe a problem that some level developers feel but probably something that they say, you know, it’s just how the line of my work is. So …

Scott McKinney: Yeah.

Federico Tomassetti: Do not expect there to be a solution.

Scott McKinney: Absolutely. Yeah, and I can’t blame them. I can’t say I would feel any differently either. Right? I’m comfortable what I’m doing here. I’m dealing with this. You know, maybe it is a mess, but it’s my mess, and I know how to work with it, and I don’t want to change anything because I don’t want to disrupt stuff.

Federico Tomassetti: Yeah.

Scott McKinney: That’s fine. I can’t say that I would do anything different, but just having people understand. Most people just don’t, that I encounter, that want to know, or they email me, or they’ll contact the slack channel for Manifold. And it’s difficult to get that … This face-to-face we’re having, there’s more to face-to-face communication than meets the eye. I can have an easier time explaining this with you than over a slack channel, or email, or something. I don’t know; I’ll just give it some more time. In fact, I’ll just say, like today, on Hacker News, there’s a front page linked to Manifold that was…

Federico Tomassetti: Yeah, I saw it last night. Well, it was last night for me.

Scott McKinney: Yeah.

Federico Tomassetti: It had … I think it just started at five points. I saw the title. I click on it. So …

Scott McKinney: All right. All right.

Federico Tomassetti: Then I was … So, it was rising up.

Scott McKinney: Yeah. Yeah. That was interesting. But still, the commenters on Hacker News they are what they are, but it’s just kind of frustrating sometimes. Okay. Yeah, I’m doing my best.

Federico Tomassetti: I think it’s very difficult to promote these ideas, even when they have a lot of merit, because these are not things that people Google for. Right?

Scott McKinney: Right. Right.

Federico Tomassetti: Because they couldn’t express this problem they feel they have. So, I don’t know if maybe focusing on specific problems could … And I’ll rephrase that, you were saying that Manifold does a lot of things. And so, to explain Manifold to me you were explaining it in a certain way, at a meta level. So, you were explaining the class of problems it solves, while maybe it’s easier for someone to understand a single problem, like, oh, I have this problem with the database.

Scott McKinney: Right. Absolutely. Yeah. That’s the approach really. Like I said, it does too many things at once. You know, if you go to the Manifold page I try to give a nice high level, like, perspective on what its capabilities are, but even that I look at it, and I go, “Oh, this is too much.”

Scott McKinney: Yeah. Yeah, for instance, we have just talked about the general, what a type Manifold is, as opposed to a conventional code generator. Another aspect of the type Manifold, as well, okay, I can own types in the compiler. I can claim ownership of these things. That means I can own existing types, not just new ones that I want to say and create from an XML file. What we get out of that is this notion of extensions.

Federico Tomassetti: Mm-hmm (affirmative).

Scott McKinney: So, other languages, like C-Sharp, Scala, Kotlin, you know, a lot of the newcomers, they have extension methods. You can add your own method, logically anyway, to another type. Well, Manifold does that now, using the same general principle here, where, okay, I’m going to feed the compiler this code. It’s basically a projection of code that the compiler believes is the types code. Here! And then, you’re just sort of faking out the compiler that it thinks that method is on a clash, but it never really gets there, in terms of byte code on disc. It’s just a façade. And then internally Manifold rewrites the byte code to make it call this other thing that you invented. But that’s there too and as well as a lot of other things.

Scott McKinney: A lot of other things have nothing to do too with the whole code generation type Manifold stuff. There’s other features that I thought would just be nice to have. While I’m in there mucking around in Java C code, I might as well add a pre compiler and what string, I call them string templates, but there’s a fancier name for it, string interpolation. There’s a list of stuff, and it’s too much for any one person to compile all at once.

Federico Tomassetti: Maybe once you get the features you’re glad you have them. Maybe at the beginning it’s overwhelming. There are so many things, and it’s … Yeah.

Scott McKinney: Yeah.

Federico Tomassetti: But maybe it’s a little bit like explaining an IDE. If you didn’t know what an IDE is you will say, oh this is things where you can say you can see a list of the methods of your class, and there you can connect to a repository, and there you can find the usages. It’s until you try it you’ll not see the holistic view and how all the piece fits together, and how they improve the way you develop.

Scott McKinney: Yeah, I think you’re right. I think that’s … You can’t point the fire hose at somebody and just unleash the 20,000 gallons on them all at once. You’ve got to give them a drink of water. Yeah, I think that’s absolutely the problem. Yeah. I’ll find a way.

Federico Tomassetti: So, you will say that now your challenges are more on explaining the idea behind Manifold and technical challenges?

Scott McKinney: Well, there’s always some technical challenges. There’s always something else on my horizon that I’m about to tackle that I may need to learn about. But the primary issue with Manifold, as far as adoption getting traction, is … Yeah, it’s explaining it. It’s not self-explanatory, and I’m not really a … I’m not the best writer in the world. I try to do my best on the website, and you know each part of Manifold is broken down into a separate dependency you can use in your Maven or Gradle build.

Scott McKinney: So, it’s all modular, and each module has a standard read-me file in GitHub, where you can go check out what’s going on in there, with examples and so forth. But it’s still just, I think, too much. There needs to be some other sort of entry level kind of way for someone to settle into this thing. Yeah.

Federico Tomassetti: And now that the simplest way to take a first look at Manifold is to install the IntelliJ plug-in or is there another approach that is easy?

Scott McKinney: Yeah, I would not … You can use Manifold without the IntelliJ or Android plug in, but it’s designed to be used in those environments. The static typing, it wants to be used in an environment like that. You’ve got so much more potential that the development experiences, or the magnitude, better in those environments. So, yeah, I would say absolutely install the plug-in in your IDE. And you can tinker with it.

Scott McKinney: You don’t have to install everything at once. You can go to the Manifold website, and you can read the high level bits about the features. And each bit will tell you here’s how you can use this. Here’s how you can incorporate this into your build. You can have existing projects. Manifold doesn’t make you do anything strange, like, okay, well, now your whole system has to work a different way, or you got to use these weird class loaders. It doesn’t do any of that stuff. It just … You just put the stuff in your gradle or Maven dependency list, and add a compiler argument, and that’s basically it. It’s a little more involved but not much, and it’s on the website. And it’s sort of self explanatory, but I think getting people to that place, where they want to experiment with it is that’s the trouble, at least with the type Manifold aspect.

Scott McKinney: Other aspects, like the pre processor, or string templates, string interpolation, like turning off check acceptions. That’s in there too. We have people that are using newer languages like Kotlin, Scala, they understand the benefits in doing that. It’s kind of a controversial topic, but it’s there for you if you want it. There’s other stuff in there that don’t need much explaining, but the okay, now you can use XML, people are kind of hesitate to jump into something like that. I think GraphQL has been probably the most successful of the different type Manifolds that are there because it’s newer. There’s not a whole lot of legacy stuff that you have to be nervous about changing, and I’ve gotten a lot of good feedback on it. So, I think that’s helped, GraphQL being relatively new and people more willing to experiment with something like this. That’s helped a lot.

Federico Tomassetti: I guess when people have worked in certain ways for 30 years it’s …

Scott McKinney: Yeah.

Federico Tomassetti: … Difficult …

Scott McKinney: Yeah.

Federico Tomassetti: … To convince them to change. I think the processor could be useful for a problem I was facing the other day. Basically, I have a piece of software that I can’t sale with a license or I could use in other projects without a license. And of course I would like to have a way to disable that license enforcing code. Right?

Scott McKinney: Yeah.

Federico Tomassetti: Mm-hmm (affirmative). Yeah.

Scott McKinney: Yeah. Yeah, that’s another issue with Manifold is there has to be some way for me to support this development. Right? Free software is great, but it can only last so long. Right? What I do with Manifold is I give it away, go to GitHub, download it all day long. It’s free. It’s Apache 2. Same thing with the IntelliJ plug-in for … They’re free stuff. If JetBrains has a free product like Community Dish and IntelliJ it’s free for that as well, but the line in the sand is when you cross over into, say, IntelliJ Ultimate. That’s their commercial product. If you’re there then you also pay for …

Federico Tomassetti: After all you are selling an extension to a paid product. So, the extension to the paid product is commercial. The extension to the product is free.

Scott McKinney: Yeah. Yeah, and I think that worked out pretty well. Some people were pretty upset about that in the beginning, when it started, and I said, “Well, you can use Community Addition.” And it just didn’t work so well for some people.

Federico Tomassetti: Yeah. Sometimes I think people feel entitled do receive things for free.

Scott McKinney: Yeah. Yeah.

Federico Tomassetti: And, yeah. I think every open source maintainer has experienced that, everyone with a blog experienced that.

Scott McKinney: Yeah.

Federico Tomassetti: So …

Scott McKinney: I don’t understand that mentality myself. I can see, okay, I’m using software. I’ve been using somebody else’s software that has been free for awhile, and now all the sudden they change you over to paid. You know, it’s commercial. Okay, not I’ve got to pay for this. Just consider yourself lucky having not to have paid for it in the past. Right? If it’s not worth paying for then don’t use it. Right?

Federico Tomassetti: My blog has a few hundred articles, and some of these articles maybe when you reach half of the article there could be a box where you can subscribe to the newsletter, or maybe sometimes there is a pop-up that comes up after you have read it for awhile. And I had a person writing me insults because I dare to put on my own website some advertisement …

Scott McKinney: Oh no.

Federico Tomassetti: It’s crazy. People just expect whatever you do it comes for free.

Scott McKinney: Yeah. Yeah. I don’t know. I’ve had people do some worse stuff, but not own my own site, but on other sites. They’ll go and badmouth it and say, “Don’t use this. This guy charges for it now.” And all this stuff. Sorry. I feel bad. I can’t help but feel bad like, oh, I’ve disappointed this guy. But at the same time …

Federico Tomassetti: I’m sure the guy works for free.

Scott McKinney: He probably does. Yeah.

Federico Tomassetti: Okay. Sorry for the … Okay. So, you have a website that I think is manifold.systems. Is that correct? Okay.

Scott McKinney: That’s right.

Federico Tomassetti: We will put the link so people can go there and learn more. They can install the free program for the community addition, and they like it, and they want to use for the JetBrains idea, Ultimate, or equivalent versions. They can buy it. So, that should help people who are interested in exploring this more. I think we are running out of time. I took over one hour of your time already.

Scott McKinney: That’s okay. As long as you want. But yeah, that’s probably too much of me though.

Federico Tomassetti: I think it’s been very interesting, and you have done a lot of stuff and had a lot of interesting experience. So, I think it was interesting to dive in this. But before we wrap up I wanted to ask you if there is anything that I didn’t ask, we didn’t discuss, that you wanted to add?

Scott McKinney: I think we covered a lot. I don’t think there’s anything really that we missed. Maybe later I might think, “I wish we would’ve…” But I don’t think so. I think we covered plenty here.

Federico Tomassetti: Yeah. And in any case we could have a second one.

Scott McKinney: Okay. Any time.

Federico Tomassetti: Yeah. Okay. So, we have already discussed where people can find more about Manifold, at manifold.systems. Is there any other source that people should use?

Scott McKinney: No, again, there’s the GitHub for Manifold also, but there are links to that from manifold.systems. And just Google. You can just Google “Manifold Java,” like, those two words and you’ll see a page of Manifold stuff. So, there’s always that. That’s probably all anyone would need to begin looking at it.

Federico Tomassetti: Perfect. Then, well, at this point I will thank you a lot for spending this time for us, for writing Manifold, and for telling us about it. So, thank you.

Scott McKinney: Thank you for having me. It was great talking with you.

Federico Tomassetti: Thank you. Okay. Bye.

Scott McKinney: Bye, bye.

Download the guide with 68 resources on Creating Programming Languages

Receive the guide to your inbox to read it on all your devices when you have time

Powered by ConvertKit