"Coldfusion" is a proprietory trademark and has strong negative connotation of 'dead language'. "Lucee" name is largely unknown beyond our swamp. "CFML" is obscure. We definitely need a brand.

I think the Ortus team have been smart in creating BoxLang as a sort of "modern CFML 2.0" that happens to have a transpiler from CFML to BoxLang (essentially; the mechanics are different because there's a BoxLang to AST to Java path and then a CFML to AST path as an add-on). Of course, BoxLang is also unlikely to go mainstream, and any associations with CFML are going to tar it with the 'dead language' brush too...

I hope guys know who they target with BoxLang, who's the audience. If it's not CFML, then... what it is 🙂

@rodyon, the following SDTimes interview with Luis Majano goes some way towards an answer to your question: https://sdtimes.com/softwaredev/boxlang-a-revolution-led-by-rebels-an-interview-with-luis-majano-ceo-of-ortus-solutions/ (tip: press F5 to ignore the advert)

a bit of marketing talk, honestly... not bad, but not answering my questions, sorry

Yeah, that interview is... a load of ol' bollox really... It doesn't really answer any concrete questions and it's full of hyperbole (and a lot of the claims are only true in a comparative context vs CFML not the broader JVM ecosystem of languages). I think that Ortus is doing the right thing for them and I think the CFML world "needs" it insofar as showing what CFML could (should?) be: general purpose, highly modular, highly extensible. I think it's good that they're starting from a much more modern baseline (JDK 21+, InDy, etc). But they designed the language itself around their near-two-decades of CFML experience and it shows (the same basic syntax, with just a few fixes; all the same BIFs, instead of taking a critical eye to that list; etc). Their obvious "first target market" is CFML developers but that's a niche market and they're already battling Big Tech (Adobe) in one corner and Open Source (Lucee) in the other. I think they need to be much, much clearer about "general purpose dynamic JVM language" -- with zero CFML "baggage" -- and then also have a very separate "BoxLang for CFML developers" approach to show a migration path. Their message is pretty murky right now. From a purely technical p.o.v., that they've managed to build the system they have, in less than a year, to the point where it already is -- very impressive. That it has a (fairly) compatible "CFML mode" too is also impressive. Whether they can translate that into a "successful new JVM language" is the question... I wish 'em luck. BoxLang has already proved a "win" for us at work.

About the interview, we should forgive Luis for the hyperbole. I suppose he and Ortus are pumped up with the anticipation and euphoria that come with giving birth to something new. Still, the interview is not all hyperbole. It conveys some of the emotion powering Team Ortus, and is sprinkled with technical tidbits throughout. In any case, we all seem to agree on BoxLang: so far, so good. From what I understand, it is still being developed. I think that, at this stage, Ortus must be careful not to burden their baby with too much responsibility. My stance is therefore: let's wait and see. About a new brand name, I don't think that is something we can decide from one day to the next or "by committee". A brand name needs not only a following; it also needs time. Which is why most brand names only emerge over time. For example, Dyson vacuum cleaners have been selling for three decades. However, in the UK, a lot of people still say they are Hoovering the carpet, even when they are using a Dyson to do so. That said, I hope it hasn't escaped your attention that the Box brand has been around for a while.

Kinda surprised we don't have an ortus or box emoji here 🙂

I hope guys know who they target with BoxLang, who's the audience. If it's not CFML, then... what it is

@rodyon This is a great question-- and the answer is both, really. Sean hit the nail on the head that • our first obvious users are CF folk, who prolly don't care a great deal about the new BL syntax and source files, but really only care if it's compat and will run their code with minimal changes. For these folks, the association with CF is very important • We are also interested in a wider marketing reach as a general purpose JVM language. We've seen the other JVM communities grow and then level off and we think there's a lot of potential there to tap into. For a Groovy person or even a Node or Ruby person to take a look at BL as a new dynamic language to toy around in, they will be immediately turned off at the idea that it's just another CF clone. That puts us in a tricky place marketing-wise as we have some very different audiences we want to cater to. I think it's fair to say any posts in the CF Communities should be directed at the first bullet. Our web site and docs however we want to keep Primarily BL centric with the CF compat bits in their own section.

Brad, thank you. I will definitely check BL, but will not lie, CFML is my primary focus, and I check BL as runtime for CFML. If I may, couple of thoughts: • a new language will serve better to your clients, will be more control and faster movement, which Adobe and Lucee cannot provide. But caution - I can tell for myself and people in outsourcing industry - they going to look very carefully whether to invest time and effort in new technology. I personally had a flop in my career, when I invested more than a year to learn and develop using Adobe Flex just to see it shut down. I regret I didn't invest into learning emerging Javascript frameworks instead. I'm not comparing BL to Flex, again I hope for the better future, but caution must be applied. Young developers tend to go where the money is 🙂 • fit into 'cloud' mentality - for example running as Lambda in AWS - I think it's impossible to beat Node written in C with language written on top of JVM on speed, but I will be happy to be wrong. New language has to be cloud-friendly, fitting into modern workflows, I feel we in CFML world are a bit behind of everything 😞 • over time I started to see CFML as nice small language to spit out HTML pages and JSON APIs. Personally I don't need general purpose CFScript 🙂 I discovered Python and happy to use it as a multi-tool 🙂 I would remove monstruosities of A/M/A/CF legacy and limited CFML to webdev/apidev framework with good interoperability. In other words, cfquery-cfoutput, or cfhttp-cfoutput, or cffile-cfoutput I see as CF's primary use case. For the heavier stuff, I'd use Java classes or external service. For example, I'd move image manipulation, pdf and spreadsheet functions out of runtime. That's just my vision. I will definitely check where BoxLang is going and wish you 'godspeed' . ✌🏼

Roddy and I come at this from very different places. I've always felt that Allaire's biggest mistake (and every corporate steward since) is that they tied CFML specifically to the web request/response idiom and built-in a lot of language features tied to that, instead of designing a general purpose language that had a really good web add-on. I think that's absolutely the smartest aspect of BoxLang: a small, core engine, focused on a general purpose language that can be used for scripts and background processes and so on, with an explicit web context module that you install. I do wish the core language was a bit more streamlined and more of the BIFs were in optional libraries -- there is some terrible cruft there which doesn't belong in a modern language and should be in

bx-compat

IMO, and I really would have liked to see a much smaller set of tags available by default (or perhaps to have all of the tags/html support in an add-on module) -- but the direction overall is good. There's a lot of support for running JVM-based solutions in the cloud, even as lambda functions -- the Java industry has too much invested in the language not to make that work effectively, and that raises every JVM language's boat, so I don't buy the Node comment there at all. Java, Scala, Kotlin, Clojure, etc are all reasonable options for anything in the cloud these days, and that now includes BoxLang (because it focused on being a general purpose "command line" language at its core). I do agree that there is always going to be a concern about longevity for a new language created by a company as an OSS project -- that was true about Clojure for several years, and even today it is still very much a niche language: but it has grown a healthy ecosystem (in all the measures I see, it has a much larger public footprint/community/OSS ecosystem than CFML -- but CFML probably does better in the corporate/government world, where they can deal with "Big Tech" Adobe).