Read the show notes and download the full episode here.
Michaela Light 01:10
Hey, welcome back to the show. We're here on sea of life with two mega geniuses of cold fusion, Luis majano and Brad wood at water solutions. They're joining us actively Spain and from Kansas, so and I'm right now in Austin, Texas, so we're quite spread out here, but we're here today to talk about box Lang, the new cold fusion engine that is joins the stable of cold fusion engines, of Adobe cold fusion and Lucy, and it's now an alternative to that, which I think, and I'll tell you why I think it's really great thing to have for the Cold Fusion community later. But I'm going to let Luis and Brad talk about that. But before I do if you don't know who Luis is, he is the founder of all his solutions. He's behind a lot of those box products, cold box, you know, wire box, you name it. Box. It's got a box in it. He's probably had his hands in it, except for command box, which Brad. Had his hands all over so and then Brad is, as I said, the father of come on box, but he's been heavily involved in all the box products and does amazing things in cold fusion land. Both of them are great speakers there. They've spoken at CF Summit, which is coming up soon, and into the box and CF camp and probably any other cold fusion event you can think of. So welcome Brad and Luis.
Luis Majano 02:35
Thank you. Thank you. Happy to be here.
Michaela Light 02:37
Yes, I'm very excited. So yeah, first New Cold Fusion Engine in maybe 14 years. I forget when Reylo came out and then morphed into Louis Lucy, but it's a while, so very exciting. So tell us briefly, just in short, you know, just what's the capsule overview? What is box lag?
Luis Majano 02:58
Sure. Well, first of all, it's not a CFML engine. So let's start there. Let's start with that one, the big one. So it's not. It's a new language that can actually talk cofusion. Let's put it that way, or CFML. Let's not use the CO fusion world, because everybody gets confused between co fusion and CFML. So let's say co fusion is Adobe. CFML is the language. So let's stick with that one. So box Lang is a new language for the JVM, inspired by CFML, inspired by groovy, inspired by Rusk, inspired by icon, inspired by PHP, inspired by many languages. So I think it's been a conglomerate of different languages that have really been playing with us as we've been working for more than 20 years and in the space, and that's what basically motivated us in several different places, for box flying. But box flying is a new JVM language that can talk csml.
Michaela Light 04:04
All right, so for those who don't know what a JVM language is. First of all, JVM is the Java Virtual Machine that ColdFusion runs on top of, and other languages run on top of it too. So basically, ColdFusion is compiled into Java bytecode that runs in the JVM or is interpreted into it, depending on how you run code. So you're saying box Lang is also compiled into Java bytecode or current so it'll
Luis Majano 04:31
be similar to the groovy language. Will be similar to other JVM languages out there, like Clojure and Scala that basically compile down to Java bytecode and get executed in the Java Virtual Machine. And basically just like these other languages, we box Lang. It's unique in that sense. Now, the major difference that, why don't we call ourselves a CFML engine, is that we have no web server in the core. The language has been designed from scratch, the team, we sort of several months basically went through the whole idea of what a new language would look like in 2024 and beyond, right? And that's why we designed the language to be hardware first, right? And that's why it's incredibly small. We wanted to make these decisions not based on a web server or a web application, but based on just the language. And that's how the language core for box line is around seven megabytes in size and extremely tiny, extremely lightweight. And then we came up with the concept of multiple run times that can basically, like an onion, be producing layers around the language according to different deployments or styles, etc. And one of those, of course, is a web server, right? We also have a new concept called the Mini server that Brad created as well. We also have serverless, which is AWS lambda support, which we have created, an upcoming Azure functions as well. The other runtimes could be Jakarta runtimes. It could also be Android deployment. It can be used for Android development. Later on, we'll be focusing on WebAssembly and iOS. But the whole idea is that boxline is very tiny at its core, but then depending on where you deploy or where you're targeting your runtime to be, then it can basically expand.
Michaela Light 06:27
So that's analogous to the packages that happen in Adobe ColdFusion, where they add in extra features. But so how would it be different from that? It sounds like you did it a different way, correct?
Luis Majano 06:38
So those features are you talking about? Are more kind of the modularity of the actual framework, per se, of Adobe, and for us, we also have modularity as well. So not only do our modules enhance basically the entire runtimes, but we can have a different run different modules for different runtimes, right? So we do have a full modular architecture that we've developed in box Lang. This is not using or. SGI, like Adobe or Lucy, we actually created this inspired by coalbox that we've created for more than 15 years, actually 18 years now, I'm sorry, so we wanted something extremely lightweight and extremely fast and extremely contained, and we were able to achieve that. We have over 30 modules now in such a brief span of period of time and and so that's the differences. Run Times are completely different. This actually allows you to run the language in different hardware and different software deployment avenues, and then our modules basically enhance the language and more of its framework capabilities, right? And this could be from ASAP modules to PDF Document Services, FTP services, etc,
Brad Wood 07:55
yeah, I would say that one of the biggest differences is our modularity goes to a much deeper level. The rscf engines, you know, started as just, you know, both of them started as as large projects that incorporated all the features that CF offers, and then the modularity was added later, where they kind of, you know, broke those pieces back out. And so we've learned a lot about that over the years. And we started from the beginning with a tiny core and the module pieces. But our modules aren't just for pulling out the pf the PDF tag, or the sapping functions, or the or on or rim functionality, you know, we broke apart the very core most of a language to be just the pure language all by itself, like you would run Python from the command line, and then, you know, all the web functionality is a separate piece which isn't part of the core, and the AWS lambda is a separate piece that's not part of the core. So at the very smallest level, we've been able to break that out. And one of the problems in the past, you know, if you wanted to use CF and an AWS lambda, you had to deal with the fact that the installation could be hundreds of megabytes and could take, you know, several seconds to start up. And that's why, you know, we wanted to be able to have these run times that have all of the unnecessary pieces stripped away. And you know, that's why we have a six, seven megabyte jar that can start up in just a couple 100 milliseconds. Because, you know, CF just wasn't, wasn't functioning where we needed to for some of these deployment targets, and people weren't able to use it there, and we wanted to be able to, you know, bring it to that place. But that required some, some drastic architectural differences in how we started with just absolute, you know, minimum functionality in the core, which also even goes down to the Java the third party Java libraries we incorporate are incredibly minimal. That gives us a smaller surface area, fewer vulnerabilities that we have to deal with in third party libraries, and it just keeps everything as tight and compact as as possible on the core, and doing that from day one, starting with an empty repository, and just building from scratch as small as possible, kind of helped us focus on, on that small, lightweight runtime to be able to compete a bit more easily with a lot of the other languages out there. You have, you know, node and Java and Python, and you can just do these little, you know, tiny command line, you know, executions of things. I mean, we wanted that in in box lane, but obviously still having the add ons to be able to, you know, support everything CF does,
Michaela Light 10:32
that's great. So just for folks listening who may not understand how big the core is currently in Adobe cold fusion, 2023, or the current version of Lucy, you got happen to know how big their their minimal core is? Yeah, it's
Brad Wood 10:45
a tricky question. What modules you would have? Um,
Michaela Light 10:48
you have no modules cool well, so
Brad Wood 10:55
questions before cold fusion with modular the WAR file was about 300 megabytes. Wouldn't included everything, oh, and the Lucy WAR file that included all of the extensions was around maybe 120 megabytes, but OSGi was always a kick in the pants, because with OSGi, you have two to three copies of every single jar that get kind of put around your hard drive. And that's another big difference. We don't have this sort of giant installation folder with like, hundreds of jars and files that kind of expand. Lucy could be upwards to two or 300 megabytes, if you had all the extensions and you had all the included, all the runtime caching and OSGi bundles, because you would have every OSGI bundle would be in the Lucy jar, it would be in the bundles directory, and it would be in the Felix cash directory. And so you'd get this like multiplication of three, sort of explosion that OSGi did without the modules, Adobe, cold fusion, 2023 their WAR file, I want to say, is down. To maybe 120 megabytes. Um, I can look it up. I have it in my artifacts here. Yeah,
Michaela Light 12:13
we'll update it in the show notes.
Luis Majano 12:14
Just compare with with the other languages. Node, for example, is about 80 megs. So
Brad Wood 12:21
yeah. And then perspective as well. Lucy, just the core jar with no extensions, is pretty small. It's down around 20 megabytes before you start it. But again, once you start it, it blooms back up to about 70 or 80 megabytes, because I'm all the jars that get spread around from OSGi. So our core jar is six or seven megabytes, and most of it's designed to not unpack a bunch of stuff. All of your hard drive is pretty self contained. You can just say, you know, Java, dash, jar, box, Lang, and then you can, you know, run a file directly. And we have, we have a handful of conventions, as far as a place in your home director, you can put a config file and where some log files will go, and where you can install modules, but generally speaking, we try to keep everything just as self contained as possible, like a more traditional Java application where you download a jar, it kind of has everything you need.
Michaela Light 13:18
Okay? So it sounds like you're at least 10 times smaller than a typical Adobe cold fusion, or Lucy runtime? Well,
Brad Wood 13:30
actually, for 2023 is 169 megabytes. It's bigger. I thought it was, yeah.
Michaela Light 13:40
Well, what? Maybe, after the show, you can dig into what those numbers are, because I think that's good information for people interested in box Lang, how much more efficient you actually are.
Luis Majano 13:50
I think the kind of the main point there to follow up on, Brad is it's not only about sites, right? It's not like, Oh, this one's smaller. I think the important thing to address for us was that we had the luxury to really sit down for months and design what we wanted, right? To really design what would be the most viable product, basically minimal viable product that you could have as a language design from from the operating system point of view, right, and then build upon that for the different runtimes that we could target, because that gave us the capability that we could deploy runtimes down the road in any way and capacity without restricting us to changing things. So we wanted to be extensible and change things very quickly by just extensibility, right? So I think that was our main intent there is to make sure that we were flexible enough for the future where we're not stuck with a monolith, right? We wanted to make sure that we could grow it organically, right? And be able to to have this modular systems in place, not only for extending capabilities, but also for the runtimes themselves, right, which is not like before, right before, where only web servers were available, right? So in our case, this is, this is what we wanted, right? We wanted to be operating system first, right at the lowest level possible, and then keep growing depending on the needs of developers or where they wanted to deploy their box on source code, right point. Also, the last one is that we're super strict, also on third party jars, and I think that this has been a mishap, for example. Of other frameworks and engines is that they basically any single Java library available, they include it right? So we're extremely meticulous on on what to bring into the core, and that's why it's so tiny, because there are a majority of things are are available already in the jdk Now, because it's so modern, not like before. So I think that has really benefited the project, because we don't have to basically bring in every single JAR file out there just to bring certain capabilities in. Yeah, and
Brad Wood 16:09
that's really a huge thing Lisa just touched on, because Java used to be kind of like Internet Explorer, right? You'd get a new version, like, every five years, and it didn't really do a whole lot. But, you know, in the last 10 years or so, you know, Oracle's really done a lot of stuff with Java after, you know, Java eight was a big, giant, stable stopping point in the Java world, which was a great release. I had a lot of stuff in Volk dynamic is as old as Java eight streams came out in Java eight, and since then, started in Java nine, is when they introduced a lot of new modularity into the core. And they've started making changes, breaking changes, adding features. And there's a whole bunch of stuff that kind of modern Java, you know, Java 21 Java 22 does that you couldn't do back in the day. You had to have libraries around. And one of the one of the big points for us was we want to start monitoring. We want to stay a modern we're not going to be how old of a version of Java do we support? We're like, no, no. We. Support Java 21 that's our minimum, right? We want to use everything Java has to offer today and not be held back by all this old stuff. You know, that's always kind of dragging, dragging people back in that regard. So everything has a minimum Java requirement of Java 21 and we're using all the new features of a language. So there's a bunch of stuff Java does today that it didn't do. And so we're kind of freed from some of those Apache libraries that in the past, you always had to use to make HTTP calls do XML, you know, manipulation, a lot of the parallel threading stuff that's all part of the concurrent libraries. Now we just tap into those things directly in the core. And since we're not worrying about supporting all these old versions of Java, that was able to really lighten the load on the number of third party libraries we needed, because there's so much stuff built into Java nowadays, and that was a really big difference for us, just to keep everything just as simple and close to the core of Java as possible.
Michaela Light 18:05
So does that? I'm sort of hearing it only works with Oracle Java, no other JVMs are supported. Is that true?
Brad Wood 18:13
All the JVMs based on Oracle Java, which is all the JVMs. So here's the thing, Oracle's the company pushing Java forward, but all the open JDKs out there are all a few commits behind, you know, Oracle's, Oracle's Java. So, yeah, you can use Box sign with any of the distributions of Java. So there's, there's no requirement to use Oracle. And honestly, that's very typical of pretty much any other JVM language out there. They, you know, they're certified to work on on any version of Java, no matter whether it's, you know, adopt DM or um, you know, coretto or azul, or whatever it is, you know, you can bundle that. We have an installer that'll get, you know, Java for you. You can also, you know, package it whatever with whatever version you want. So we want to keep that easy so people can always they can stay on an upgrade path and always be updating their Java, not getting behind.
Michaela Light 19:11
So as long as their Java engine is based on Oracle version 21 or higher, they should be okay, running box, laying on it. Yeah, sounds good. So any other drastic architecture differences? We talked about a whole bunch there, but the only you missed out that we want to highlight.
Brad Wood 19:30
Well, there's like a billion, but I don't know how many to get into. The other biggest one we have is really around our parser and around our AST. I don't want to get too far off the weed, because most people don't care about it right. As long as they write the code and they save the file and they refresh the web page and the magical stuff works, they're like, whatever. I don't care, right? It's all part of the black box. But we did a bunch of work in the front end of this project. It was months before we even had really a working runtime, because we started with the parser and thinking about how that was going to work at the runtime. And so one of the huge sort of deviations we have is we sort of have a multi parser system right now. We have two main separate parsers. We're using antler, which is an industry standard library for parsing code. Adobe cofusion appears to use antler based on the jar files that you know they bundle. It's a very popular library, but we have two completely separate parsers, one that parses boxing code, which is based on and similar to cold fusion, but has a bunch of extra features and dynamic language enhancements we've added to it. And then we have a second parser that parses cold fusion code as it's defined today by Adobe and Lucy, including all of its little works and peccadilios and odd things that it does. And this was our opportunity to say there's a bunch of little, kind of weird things that cold fusion does that we wish it had never done. And we want to kind of be able to break that and say box slang fixes those right? This is the way it should have been. We've gotten rid of the profit that shouldn't have been there. Have Been there. We fixed the things that were wrong. We've renamed the things that were never named correctly, right? And that's what the box sign parser does. But then we have a separate parcel. It'll still parse exactly cold fusion as it is today. Because compatibility and being able to take code as you have and just run it is obviously, you know, very important. Otherwise we'd have effectively, you know, no users right away. But that all consolidates down to what's called the AST. The AST is an abstract syntax tree that's basically a collection of objects that represent your source code. And this is very common with programming languages, and so the AST doesn't necessarily track every curly brace and semicolon. It just tracks the fact that you have an if statement, and the condition looks for this variable, and then inside the if statement you have 10 statements, you know, and one is a try catch, which has these statements inside, and you have a while loop, right? You set a variable, they st, tracks basically what the code's doing at a high level. And whether or not you parse cold fusion script or cold fusion tags, or box Lang script or box Lang tags, which is really sort of four separate, you know, parsing avenues, you wind up with the same consolidated abstract some text tree, and that's what we compile down to bytecode. So the runtime kind of exists down here, and it doesn't care what language you came in from, right? The runtime just has all, you know, all the logic to run the code. But that allows us to break with compatibility. The problem Lucy always had, in my opinion, and I don't fault them for this. If they wanted to push cold fusion forward, they wanted to do things cold fusion wasn't doing, but they had to just bolt things onto the side of cold fusion, which sort of diverged the language in multiple places at multiple times. And now you have, like, different flavors of cold fusion, certain functions that only exist in one place, right? Then cold fusion adds a function similar to Lucy, but they do it differently, and that was always a bit of a problem. The separate box length parser allows us to innovate in breaking change ways. But over in the box, Lang parser, leaving the cold fusion parser alone. So you can opt into playing around with the new box. Lang features by, you know, switching your file from dot CFM to dot bxm, or from CFC to.bx and now you can use the box Lang source code. And the other thing the abstract syntax tree gives us, which is, quite frankly, huge, is the ability to do linting and code quality and actual, you know, syntax help in the IDE we have, you know, an entire extension for VS code written with a running language server protocol and does all the syntax highlighting. And as you're typing the code, it's parsing it through our parser, and like any other language would cold fusion, developers don't even know what they're missing. Sometimes you know you type something wrong, you have an incorrect syntax, or even if you return a string from a function that says it's going to return a number. We can detect those things now, and we can do that by parsing through that abstract syntax tree that's generated, which is available to create all sorts of tooling. I have proofs of concept for replacements for the query, brand scanner, for the bar scope scanner finding unexcad variables and HTML, but aren't using, you know, the sappy functions. There's all sorts of code followed detection we can do now based on that abstract, abstract syntax tree that can become command line tools, code checker, type tools, IDE tooling, and that's never been available in any sort of open source way. Lucy doesn't really have an AST. It just does like a custom built parser, straight to bytecode, really fast, right? But it's not an extensible thing. You can reuse Adobe uses antler, and they may have an AST, I'm not sure, but they're obviously closed source, so it's not something people can build on. But boxsign, you can take our parser, our open source parser, our ASTs, you can extend it. There's interception points. You can write your own visitors that can say, don't allow variable names that have the word Brad in it, right? That's a few lines of code to be able to write a visitor for AST and create your own, you know, code quality metrics. And that was one of those huge like, missing black holes of functionality that cfers never really had. And we were like, We need to fill in this gap. We need to have the real IDE tooling. Need to have the real code quality metrics, we need to really have a parser that's, you know, solid allows us to innovate without screwing around and touching what cold fusion is. Leave that alone. And so, to answer your question from five minutes ago, I would say that's the other really big architectural thing, is that we started from scratch and spent several months just nailing down what the parsers were going to look like. And then we also have the ability to take cold fusion code in the cold fusion syntax, and we can transpile that for you into the box Lang syntax. So we've renamed the, you know, serialized JSON function to be JSON serialized, because that's what it should have been called in the first place, right? That's how cold fusion works. You have the name of the data type and you have the action you're performing, struct, depend, array, new, right query, add, should have been JSON serialized, so we fixed that name, but we fixed it in the box saying parser. So we even have tooling. Then if you want to player on a box sign, you can give it a cold fusion of file, and we'll just go boom, and we'll convert it to boxing for you, which includes all the little renames and little syntax changes we've done. So we've made this easy kind of transitional bridge that you can just grow your cold fusion code of boxing and say, run this, and then we'll go, okay, or you can say, You know what? I'm going to play around some of the new syntax offered the box Lang parser, right? I want to be able to import java classes directly and just use them, right? I want to have bridges from my functional interfaces, right? Like every other JVM language, but cold fusion has so you can take files, you can transpile them over to box Lang, and then you can kind of easily switch between them. So the tooling around the parsing was something we knew we had to really nail from the beginning before we really even got into the running runtime. Yeah. Well,
Michaela Light 27:06
that sounds really exciting, Brad, thanks for explaining that. I just want to say for the folks listening at home that, as I understand this, correct me, if I'm wrong here, all this fancy casting and ATS does not affect runtime performance in one piece, because once it's compiled, it's in bytecode, none of that stuff is running in whatever that's exactly
Brad Wood 27:28
correct. Yeah. And so a lot of the transpilation we do is on the fly during the parsing phase. So when we parse cold fusion code and we see you have a serialized JSON function, we swap that out with our compile time transpiler, and the byte code no longer cares, because we've already swapped the name out to the right name, and then it just runs as fast as possible. Yeah,
Michaela Light 27:49
and bytecode doesn't care about naming in the in the original. And
Luis Majano 27:55
like Brett said, tooling was was hugely important for us. We wanted to make sure that not only you had a great language, right, but the tools are really, really important. And that's where we you know, the kind of like the CFML world has always failed is because the tooling has also been subpar. So we really wanted to design to focus on tooling and bring it from day one day zero, actually. So
Michaela Light 28:19
maybe we can do a future episode about the opportunities in tooling, because I know we're on time here, and
Brad Wood 28:27
I didn't even mention the debugger. We have an entire debugger built. I think
Luis Majano 28:32
that one deserves to be mentioned, which is the the inline debugger. So this is line by line debugging that you can do in VS code from operating system, code from command box, servers from web servers from any runtime. You can target the debugger, and you can basically do it line by line, debugging,
Brad Wood 28:49
yeah, introspection of your scopes, everything. We spent months on that, and it's all part of the VS code extension that's out there.
Michaela Light 28:59
And so that's something that third party is built for cold fusion, but they had to retrofit it. You've got it built in to the language.
Brad Wood 29:06
Yeah. Adobe added some debugging functionality when they made their VS code extension. Lucy has nothing in the core. There is some, there are some third party libraries out there in the community, but it was important for us that it was, it was made by us in the core as part of our, you know, open source offering from the beginning.
Michaela Light 29:29
And then I just want to dig into that word transpiling, because people may not have heard that before. Is that mean it? It converts from one language to another, but I think also it means it's transparent. You don't have to transpile your code now. You've lost your original code, you continue to edit in your legacy code, for your code, if that's what turns you on, right? And you can run it in box Lang, and you know as far as your
Brad Wood 29:55
so basically, there's two avenues. What you said is correct. There's a couple ways you can approach it so you are correct. The transpiler is something that takes one language definition and then transforms it into another language, right? So box flying is very similar to cold fusion, but still a distinct language. So if you run a cold fusion file directly, we do the transpiler automatically for you behind the scenes as we parse and compile it, and once it hits the bytecode, it's all done. You don't really have to think about it if you want to play around with the writing in the box, Lang syntax and some of the new features that offers you can do a one time transpiler command that will create a copy of your file somewhere else in the new syntax. You can look at it and you can run that directly. So we have a couple of different ways you can get to it, based on whether or not people want to play around with the new features, or if they want to say, You know what, I don't care about that. I just want to take my cold fusion as I have it today. I just want it to run on box Lang. That's also a totally balanced scenario. And in that case, you don't really have to think about it. We just do it for you. Okay,
Michaela Light 30:57
so two quick follow ups there. First of all, what do you call the box Lang language? Because I don't think you're calling it CFML. Is it? Bfml? Yeah.
Brad Wood 31:07
BX is the acronym we use a lot like our file extensions are analogous to the cold fusion file extensions. So a CFM file, we call that bxm For box Lang markup, CMS, which Lucy six had his support for, which is cold fusion script. We have BX s for box Lang script, and then a CNC file, which is a cold fusion component. We just call that.bx just for box slang.
Michaela Light 31:33
We have
Brad Wood 49:30
terminology changes. One of the big things is we didn't want box slang to be a tagged first language, which was always something that sort of haunted cold fusion was people saw cold fusion as a tag based language, and CF script was a bolt on. Now, I never really saw that way. I really thought CF script was, was a great, you know, fully fledged language, but the the way people viewed cold fusion always had this kind of tag mentality hanging over it. And so we. We built the script parser and box Lang first. It's the first thing we had working right. We hadn't built any tags. We hadn't built any any of the built in functions, just pure scripts constructs, like if you're writing Java code, right? And that was the core, the language we built first, and everything else was added all along with it. So we use the word component now to refer to tags. So the cfhp tag, you can use it in script. So was it really a tag? Yes, no. We just call that the component. The cfhp component just a small little language change we made to try to distance ourselves from this tag based mentality. And so cold fusion components use the word component. We just call those classes now. So the BX
Luis Majano 32:48
file, like every other language in the world, yeah, match. You
Brad Wood 32:52
have your whole language, like literally in the world, unless it's called a class, right? That's what we used. If the word we'd use today, if we were making a language from scratch, we'll just call it a class. So BX files, we just call that a class. We don't call them components anymore. Still works the same. And, you know, a small example of one of the one of the tiny syntax changes we've made is class files and box slang don't use the keyword component. They use the keyword class, which is what you would expect in Java or Kotlin or most other languages. You know, we've added real quote, unquote annotations so you don't have to put them inside the comments anymore. There's lots of little enhancements to be done, but a lot of it just has to go with the way we sell box slang. Because we don't want just cold fusion developers running the cold fusion code on box slang. We want a language that Java developers or groovy developers, or no developers, can say, Hey, this looks like a fun dynamic language. I'm a JVM. I want to learn this. And, you know, just like I would learn Python or rust or some other, you know, fun language to build things in, and we want to make sure that we market it in a way that sounds modern and sounds scripty and sounds, you know, dynamic. And we don't want to focus on the tag first mentality, the legacy first mentality. And so that's always just been important. So we kind of have several rules of thumb, which is, well, how would we do it? If we did it the way that no good language design would be in 2024, right? Not. How does cold fusion do it? How would we want to do it? What makes sense? And then, how do we support that? And then also have the ability to transpile whatever cold fusion does. And in some cases, we're like, you know what? We love? How cold fusion does this? There's nothing wrong with it, and we're going to do the same thing. You know, everything's really a case by case basis on, you know, what really made sense in cold fusion? What didn't make sense? You know, where do we diverge and how do we still support everything? Yeah.
Luis Majano 34:43
I mean, we, even in our docs, were calling this the the templating language, the box line templating language. And I think that's what it really is. Just like confusion is has a templating language, or other languages have a templating language, like groovy, for example, we have which has the GSP, right? So that's where we're headed. In that sense, is to say, No, we have classes and we have the templating language, the functionality comes through modules and components.
Michaela Light 35:36
All right, so let me ask you this by transpile permanently my cold fusion code into box Lang, can I go backwards if I want to go back to the cold fusion syntax for whatever reason? Sure,
Brad Wood 35:49
the transpiler tool doesn't leave your cold fusion code. You still have it no but no.
Michaela Light 35:56
Converted it, and now I've edited in box Lang, and for whatever reason, I want to get it back into CFML. Can I currently do that?
Brad Wood 36:06
Or you can build one way back in the cold fusion files, if you'd like. Not
Luis Majano 36:08
right now, where you can, you can get a license, and case, get support, and maybe we'll build a module for you to go backwards and All right,
Michaela Light 36:16
so it's technically possible to do that. You just have to implement a year. If there's demand or people pay for it, they can have that
Luis Majano 36:23
correct. I don't think interest to create it, though.
Michaela Light 36:29
I would argue that, because if someone's experimenting, they want, usually with with more open products, you can export your quotes data, in this case, your code back out. You're not locked in. So I'm just proposing that, but it's your language. You know. You
Brad Wood 36:49
do what you Well, here's the thing. You can write a box Lang module right now, and you can put it on forge box, and it can listen to our parse interception point, and it can take the AST, and you can write a pretty printer that prints out cold fusion. You can do it right now, open source. Oh, cool, because that's based is we take the AST and we put it through a box, like pretty printer. So
Michaela Light 37:08
yeah. And to be fair, the BX language. It looks like cold fusion script to me.
Brad Wood 37:14
Yeah. Syntax is very, very similar. Most of what we added are just additional features. We have an instance of operator like Java. We have a cast as operator, I don't want to say like SQL, but along the same vein, we have like, real annotations, like an app. Line, annotation, Name above, functions, properties and classes, we have just a handful of things that are just things. Doesn't do the base script is very similar, and the tag based script is also quite similar. But instead of using CF, we use BX colon as the prefix for our tags. So, yeah, I mean, there's not a huge departure from full fusion. A lot of the things we did was, honestly, like cleaning up and renaming, you know, bits that just seemed a bit sloppy, or, do you know, didn't seem cohesive. And obviously, no, we have the benefit of looking back through time, you know, and looking at like, 800 built in functions. And that's not an exaggeration. It's literally more than 800 built in functions. I
Michaela Light 38:14
know, with all of them
Brad Wood 38:20
on Yeah, we have the benefit of looking back through history and seeing it all at once and saying, yeah, these here didn't really follow the right naming convention. And so we can fix that. Now, you know, we can start from scratch and make it, make it make sense.
Michaela Light 38:31
So let's just step back from these technical details, which have been wonderful talk about, I want to ask, what is box Lang really?
Luis Majano 38:41
So let's put it in two words. So we've gone through the whole language, portions of it, right? So it's a complete JVM dynamic language, right? 100% interoperable Java, which we haven't really talked about much, but it's completely interoperable with Java. So that means that you literally almost code like Java. There's no bridges like that. It exists on on currency, FML engines, right? We wanted to burn those bridges. We wanted to have full ability to import java classes, easily to declare interfaces, easily extend from Java classes, implement from Java classes, everything that a dynamic language based on the JVM should do, right? So all that is there as a language. Second of all, we've built a lot of framework capabilities into the language itself. Mostly we've been doing frameworks and building frameworks with Brad for over 18 years, and a lot of that experience has seeped in into box Lang to make your life productive. And this is really what the ethos of CO fusion was, right, to make you productive, right? And that's still our ethos, right. That's where we were born from, right, from from CO fusion. So all that is there, and we wanted to keep that productivity, but take it to to even further levels, right? So you will find that in in box slang, you have tons of these framework like capabilities, example, event driven programming, right? This has been huge in other languages. This is core to the language. Everything can be extended through events and interception. You can listen to a CFC when it to a class when it's created. You can listen to when a caching element is being removed from the caching engines, right? You were like Brad said, parser events as well. And all these events are available to developers to finally extend everything without basically touching kind of the core functionalities, right, even the dump, for example, the dump capabilities, right? You can listen to the dump capabilities, which we're building a module right now that you're going to stream all the dumps into VS code and actually have a panel seeing all the dumps from your live web application going in, into VS code, so you can analyze them and view one, right? So that's one example. The other one is the caching engine, right? I built cache box almost 15 years ago, right, as a caching engine, enterprise caching engine, with distribution capabilities, ability to have an agnostic API to tap into other caching engines that has been ported in, right? So you have a full enterprise caching engine already built in, into the language and extensible, or, you know, through different cache portions to other engines like Redis and Couchbase and that we will also be bringing pretty soon here, right? So it's, it's bringing a lot of those capabilities. Another major one is a synchronous and parallel computing that's built in thanks to the all the features of the JVM, this is nowhere near to what the other tml engines have done. We We have really innovated in the in the area of a synchronous and parallel computing because the JVM has moved forward that, and we've been able to bring that into the box Lang as a framework capability. So you can very easily create a synchronous computations and create functional stories around parallel programming, right? And that basically built into the other framework capabilities like scheduling, right? So, you know, obviously cofusion and do see have done schedule tasks, right? That have their their cons and pros. The majority of them are using, for example, the quartz engines, which is something that is, that is built by Java developers, right? But we built one for call box a long time ago, and we've been able to port that into the language as well. So developers can have really a nice. Easy of use of building scheduled tasks without the need of a Webster, right? You can source control your tasks, you can describe your tasks, you can program your task, you can unit test your tasks, which were incredibly important to us, right? And now you have all those framework capabilities built in, right? So those are just quite a few examples. There's many, many more that we can point out. But like you said, What is box Lang? I think it's, it's multifaceted, right? Is the language? Right? That gives you, just like any other modern language built to today, probably further than than any other language that we've done in the JVM, because we basically extend everything in the JDK and the framework capabilities of the language right to bring true the ethos of CO fusion, of productivity. So those are kind of the two facets that we focus focused on and we'll be focusing on.
Michaela Light 43:21
So you're saying it's more a more modern language, not just than Adobe or Lucy CFML. It's more modern than all the other JVM languages out there. So
Luis Majano 43:24
I'll give you an example now one invoke dynamic was a feature that was introduced into the JV, into the JDK, around JDK eight, six or seven, I think, yeah. So it was basically the capability that the language engineers at Oracle introduced into the Java Virtual Machine for dynamic languages, things that are not built using static constructs. And this was the new way to basically build upon on the JVM for four dynamic languages only. Quite a few have adapted a few things from it, right? Kochman has adapted a few things in their in their approach. Even though they're not a dynamic language, they're static language. I know what's the one that Sean Corfield uses, Brad closure. Closure has a few delvings into invoked dynamic but we have really adapted it right? And I think that that's one of been our biggest advantage here, to bring performance speed and really sticking true to what the Java developers when they created invoke dynamic for what, which was the initial, you know, purpose of it, which is to use dynamic approaches. And we've taken that and build an entire framework that we call dynamic object. And this is really, really new in any language on the JVM which basically allows us to treat any class. It doesn't matter if it's actually coming from a Python loaded JVM class or a box line class, or actually even a Lucy class or whatever class. We can wrap any class into a dynamic object, and we can treat it as a dynamic construct, right? And this has allowed us to do even things that we never saw possible before, right, in cold fusion and in other languages. And Brad can speak a little bit more because I developed the framework, and he's been adapting it and using it, and it has been a great thing that we've innovated that is very rare still in other languages, yeah,
Brad Wood 45:36
and there's a lot of performance capabilities that comes with using the Invoke dynamic as well, because Lucy and Adobe are still using Java reflection for all of this, and Java reflection is as old as Java version one or two, and so that's one of the big architectural changes we wanted to do, was say all of our dynamic, you know, anytime you call a method in a Java class, things like that, we want to make sure we're doing it the way that Java wants us to do in, you know, using the modern practices. So it's opened up a lot of a lot of doors there.
Michaela Light 46:11
Very exciting. So do you guys have a comparison chart between box slang and not just a Adobe call fusion and Lucy, but, like groovy and rust and clutch or and all these other ones you've mentioned? Or is that something you might have in the future? If you don't have
Luis Majano 46:25
it, we will have it. We will have it in the future. We're still developing a bunch of these things to do comparison. So people want to compare things. So we do. We're creating it as as we speak. I have a document that Jorge sent me, actually this morning, of several of the different value propositions coming from other languages. And so we're trying to do our due diligence. And people can can see that, and can see the benefits of of you know the languages right now. Consider this to modern day. Today, there's not a lot of differences in semantics between languages, right if statements are if statements for loops are for loops, closures are closures. Classes are classes. I think the major differences for us and especially
Michaela Light 47:06
is that. Why? Because the UCD, we had Lisp and we had Fortran, they were wildly different languages all seem much the muchness, yeah,
Brad Wood 47:17
it's like vehicles, right?
Michaela Light 47:21
That's a whole other discussion. Why are all cars more or less the same? Where's the personality
Brad Wood 47:27
that's that's a good analogy. You, though, right? So, I mean, you could say the API for driving most cars is very similar. You have a gas pedal on the right, you have a brake pedal in the middle. You might have a clutch on the left, right. You have a steering wheel. You turn it to the left, you go left. Turn at the right, you go right. You probably have a gear shift, right. You know somewhere social button, you push key, you turn. The radio probably has similar volume knobs. Those are creature comforts and what you expect when you sit down in a car and you feel like you can be productive driving the
Michaela Light 47:57
car. How many of those are really the best ergonomics? You know, like the QWERTY keyboard, it was designed to be unergonomic, right? I think some of those car interfaces, yes,
Brad Wood 48:08
things will have developed because they were the most ergonomic, right? I mean, you had your high beam switch in the floor. You had to push it with your foot, but most of the time, that's on the tree now. But here's the point, that doesn't mean that every car engine runs the same, right? Because when you push the gas pedal behind the scenes, there can be all sorts of differences between what's actually happening and so I don't know if these are public or not. If you have a chance. Kai Koenig did a really good talk on box sign. We had no clue what he was even going to say in it at CF camp. And he talked about this. He talked about how most languages have the same basic constructs, but how the differences between languages, what makes some languages better, more popular and more successful really boils down to things like the community, things like the tooling, things like the IDE capabilities. There were more of the peripheral things that really make some languages more successful and more convenient and easier to code in than just the fact that you have a for loop. I thought that was a really good comparison,
Luis Majano 49:12
and I think that was what nailed it, right? Is what really made really cool fusion productive, right? Is that other things that are not just the language, right? And I think that's eco Sato community,
Michaela Light 49:26
exactly. And you guys are big focus, and you guys have really contributed to the ecosystem and to the community. So thanks for doing that. Yeah, so that's really great.
Luis Majano 49:34
What, uh, what, like you said is, like, this is our main differentiator, right? Is the framework capabilities, you know, we've been built. The entire Ortis team is involved. It's not only one person, right? There's over 15 developers involved in box Lang with their different responsibilities and different areas of interest, and everybody brings to the table of all their experience through 18 years of building over 350 open source libraries that we still manage and we'll continue to right. So I think that that that's something that's really our differentiator for us is not only is it a language, but is the framework capabilities and productivity capabilities that we want to bring not only through core, but through Module, through that community, and foster that community so anybody can be building modularities and grow the ecosystem. Now,
Michaela Light 50:23
I know we're running out of time here for this episode. We're happy to have you come back and talk more about other aspects, very exciting development in cold fusion land. I've got a few quick questions that you know people are out asking out in the cold fusion community. Firstly, is Adobe ColdFusion or Lucy somehow embedded in box Lang there seems to be a misunderstanding here, perhaps. Yeah,
Luis Majano 50:45
I think we've asked that question before, and the answer is no, obviously, Adobe's closed source, so we have nothing to do with them and Lucy as well. Even though they're open source, our approach was completely different. So there might be certain things that were inspired from both engines in terms of functionality, but no, there's nothing embedded. Our CFML capabilities are because we built our CFML parser from scratch and all the runtimes has been built from scratch. And you can even go to GitHub and see the entire history of the repository, and you will see how we started with two files and grown to over 3500 tests, right? Brad,
Brad Wood 51:23
oh no, no, no, we're over 6000 tests now. Sweet. Yeah, we, I'd have to look, but when we I think it's still true. When we announced box slang in May, we had more tests than we had commits in the repo. So we have had unit tests on on all of box slang from the very beginning. Um, yeah, we've added a ton. We have 1000s and 1000s of tests, and we plan to keep So
Michaela Light 51:50
although you will have extensive knowledge of what Adobe cofusion does, you never really saw the source code inside, because it's closed source. And although Lucy is open source, you separated your development. You kind of had a Chinese wall separation, like we say in the financial industry. You didn't cheat and copy from Lucy you created, and you didn't want to, because you wanted to just have a fresh start.
Luis Majano 52:15
I think that if we wanted to, we would have just forked it, and we actually analyzed
Michaela Light 52:19
Why didn't you fork it? That was a good question. So tell us why you didn't just fork it. Lucy is open source. They'd have been happy for you to fork it. Well, totally.
Luis Majano 52:28
Well, we, we, we actually analyzed it from over a month and a half the entire source code, okay, I'm not going to say line by line, but the majority of it, we analyzed internally and we created a feasibility study, right? So we actually dedicated two resources to this, to basically do a full analysis of what it would take to do a fork, right? The conclusion of our analysis was, first of all, it was completely bound to a servlet, right? The historical aspects of it and the decisions made on that project are made by one person alone, and there's really not a lot of documentation to guide us, to really propel us on why this? Why that? Right? We wanted industry standards for parsing mechanisms. We didn't want something that was homegrown. That was another differentiator, the decision to use OSGi is something that we knew after being a reality that was not the right, correct decision to use. So it basically boiled down that we weren't checking any checkboxes on a reason to do right. Plus, we really wanted to focus on really a tiny, tiny approach to it, and we wanted to use invoke dynamic to build the bridges for dynamic languages. So basically, after our conclusion was that it will take us even longer if we forked, because we would have basically just dismembered it on day one, right? We would have basically
Brad Wood 53:53
wanted to do with it. It would have to have looked completely different. That was the whole point. So
Luis Majano 53:59
it there. The consensus was that it's not in our best interest to fork it. It's in our best interest if we designed it like we want to design it and focus on on what a 2024, language would look like from here to the next 3050,
Michaela Light 54:15
100 years. And dumb question, why not just suggest always improvements to Adobe
Luis Majano 54:21
we have. I mean, we've been, actually, we've had tremendously and let's not get Brad started on this one. He laughs,
Brad Wood 54:29
but we have hundreds of tickets in the backlog, and
Luis Majano 54:33
we've been very stern with them for years and years of what we needed to do as a community to really evolve, right and go to the next approaches. And it hasn't happened. So, you know, it gets to a point where, you know, if you try to do the same thing, it's called insanity, right? So we wanted to break off of that insanity. And you can see the majority of things that are built right now in box Lang, there are tickets for those in both trackers Lucy and Adobe, yeah.
Brad Wood 55:07
12. We have 15 years implemented. We have implemented in box slang now, and I can show you the tickets that have been for years and years and the other bug trackers. And there just becomes a point where, you know, we say, you know, we need to be able to nest exceptions when we throw them right. We need to be able to, you know, have these JVM interoperabilities extending Java classes we've been asking for years and years, and we can't be held back any longer. We need to be able to push forward. And if we have to build that in order to do it, then we're going to build it right?
Luis Majano 55:38
Yeah, and I think that was another major issue, is that we want fast innovation. I think this is the way of the world now. We need to be able to be quick. We need to be able to be agile. We cannot be waiting for two years, three years, for innovation to come. I mean, right now we're on our 15th release. I mean, 15th release that we've done for box Lang. Every Friday there is a new release. So the speed of innovation and this
Michaela Light 56:06
every Friday, every Friday or so releases every year.
Luis Majano 56:12
Yes, and this has been proven to be great, but this is
Michaela Light 56:18
like, a par release, right? These are beta releases or something, correct? Are you intending to have a weekly release cycle once it's in production?
Luis Majano 56:25
I don't think. Why not. I mean, I think that we're used to it by now.
Brad Wood 56:30
I mean, so I, like Lucy does. Now, we've always had a snap, instant snapshot releases. And that was always a good thing about Lucy was, you know, if you put in a bug and it gets fixed and they you can test it like that day, right with Adobe, sometimes the ticket may be closed, and it may be months before you even have a chance to test it, unless they send you a custom hot fix jar. And so we've always had, we have an entire CI process spread across all of our repositories, and everything gets immediately built and deployed. And you know, if we fix something reported in Slack, right then you can test it 15 minutes later. And so, you know, the weekly betas basically just give people kind of stopping points they can pin to and they can test that they know aren't going to, you know, change.
Michaela Light 57:18
I think we want to hold box for versioning, or, come on,
Luis Majano 57:20
we always, we always use semantic versioning for everything that we do right and moving forward, that's what we'll continue always to do with all our products. Products, right? One box will be part of box line. Excellent.
Michaela Light 57:35
Very exciting. Well, I have like 300 other questions to ask, but we have to say for future episode, because I know Luis, you have a hard stop. What are you looking forward to? A CF summit next week?
Luis Majano 57:46
I'm looking forward to seeing everybody teaching a class this coming Saturday and Sunday, we're going to be building RESTful services with callbox. So that's always exciting. So I'm very excited to see everybody in CF Summit. I don't know if some of the Adobe folks are going to be excited to see me, but we'll
Michaela Light 58:04
see. Course they will. People ask you more questions about box Lang when you're there, yeah,
Luis Majano 58:11
for sure. I mean, I want to be as as full of integrity as possible. I'm not there to go promote box Lang, obviously, right? It's an Adobe event, so I want to be very, very cautious about it. So if you will, do have a questions about it, just pull me aside, right? I want to be respectful of everybody's time and my presence as well as respectful as I can. That's it. So
Michaela Light 58:35
how about you? Brad, what are you? You're going to CF Summit? I think I saw you might be speaking. No,
Brad Wood 58:45
I actually didn't get any Ali submitted one talk, and they didn't accept it this year. So this will be the first year ever I'm not speaking at any person CF summits. Well, I
Michaela Light 58:49
mean, you're more available for hallway track conversations.
Luis Majano 58:54
I will see he's gonna, he's gonna stay coding in box line, yeah, all
Michaela Light 59:00
right. Where can people find box Lang, online. Where would they go?
Luis Majano 1:16:35
So they can go to box lang.io, very easy, and they can see pretty much everything that we have there, not only the open source version, but the commercial versions are available there in terms of what we offer as well. They can go to try.boxline.io and actually try it. We have actually built a full online editor, and you can test box on code online as well. This is analogous to try CF, but we've actually built this using two runtimes to showcase the power of box Lang, using AWS lambdas and using command box servers. So you can go try that out and learn. And then we've written completely a whole new book. It's called Box lang.orchestbooks.com, it's still in process, but we've made a tremendous amount of progress already, so we're trying that every single feature is fully documented. You know us by now, and we love our documentation. So this will be a new book once we're completed. It will also go to Amazon, so you can be able to purchase it as well. And
Michaela Light 1:00:09
then there's probably a GitHub repo right looking around, which will dig up the URL for that
Luis Majano 1:00:15
is correct? That will be github.com/ortiz-box, line. And that's our organization, and you can see all our repositories there as well.
Michaela Light 1:00:25
Excellent. Well, thanks so much for coming on the show. Both you have a fabulous time at CF summit in Las Vegas, and look forward to talking to you about boxing and other topics in the future.
Luis Majano 1:00:36
Yes, thank you so much. We
Brad Wood 1:00:40
really appreciate you. Thanks for having us
