Why not just dump a ton of member methods into the language?

This is just an open-ended question. When ColdFusion added the ability to reference member methods (ie, array.filter instead of arrayFilter), I felt like it really improved / modernized the language syntax. But, there are still lots of methods that aren’t in the language. For example, I would have loved to use array.flatMap this morning, but it doesn’t exist.

So, here’s my question to the people, is there a significant downside to beefing-up the standard library in a language? Like, does it slow things down a lot? Increase memory usage to a point where it’s a problem?

I’m not a “language guy”, so I don’t know if there are implications that are obvious but are not obvious to me?

1 Like

I hate java, and I fully admit it. That being said, java app engines load their prospective compiled code into memory, which beyond startup and file size doesnt really impact processing speed.

My belief would be, it would not be a big impact.

though couldnt you do something like this to emulate node flatmap.

That’s good to know, re: Java’s overhead there. I thought maybe that was the reason the language spec wasn’t evolving more methods more quickly. Though, I know there always has to be an eye on backwards compatibility, so you don’t want to add things that will turn out to be bad ideas later on. But, it just feels like there are so many other languages to steal / borrow from at this point.

re: arrayAppend() usage for flat-map, totally. And, what’s more, the arrayAppend() takes a third argument for merging-in arrays (not just single values). So, the language definitely allows for it - but not as seamlessly as calling .flatMap().

But, that was just an example. You could look at Lodash / Underscore and wonder why we don’t just pull in all those things :smiley:


I look at the reason why ColdFusion keeps getting a bad mouthed, its the Java devs.

Look at all their code to do trivial things. multiple files and thousands of lines of code to do what you can do in ColdFusion in a few lines of code.

Unfortunately there are not a lot of Java developers who happen to be ColdFusion developers. Most Java developers I have ran into love their “problem factories” and fully want to avoid turning their many hours of redundant coding into a simple CFTAG.

1 Like

99% of my code is just manipulating Structs and Arrays … but, the more member-methods I can get to help me do that stuff, the less chance I have of writing bugs. And, keeps the code more simple.


Since we’re speaking of member methods and code simplicity, instead of this:

arrayAppend(flattenedArray, doubledNumber);

IMO better (quicker to type and easier to read) doing this:


@Terry_Whitney In my very honest opinion I believe three main issues gave CFML a bad rep:

  1. ColdFusion is proprietary, one of the main reasons why PHP became more popular back in the day, while the existence of open source Lucee isn’t as well known. Open Source gets a lot more street cred, and deservedly so, with Linux being the prime example as the world’s largest software project. But I doubt there’s a significant marketing budget for Lucee?

  2. Tag-based CFML – especially when ALL-CAPS – is extremely:


And despite the far more elegant and generally lowercased cfscript having existed since '98, there are still so many code examples – especially in Adobe documentation – using tag-based CFML. Thankfully this is not so much the case for Lucee documentation and Lucee coders! But again, not as well known.

  1. There is still so much spaghetti legacy code. It’s inevitable when you create a platform that’s easy for HTML coders to learn, you’ll end up with a whole bunch of CFML coders who haven’t taken the time to learn proper software development principles and best practices. I’m not saying that smelly code doesn’t exist in other languages, but I do believe it’s especially true for CFML.

To this day I still have plenty of that ancient stuff in my own code bases. Every time I see it, I cringe and think … I wrote this garbage? Hahaha but that’s because over the years I have learned so very much how to code well, and still learning something new every day! I sprinkle technical debt refactoring here and there as time allows for each task and some day it will all be eradicated!

I’m not too hard on myself about it because way back in the early days of web app development, it was actually pretty awesome and cutting edge, and performance-wise it’s still pretty amazing. And learning is a life-long process, or at least it should be.

But when other devs coding in different languages and using different platforms – especially younger devs with insufficient knowledge of history – see these CFML problems, it doesn’t encourage them to dig deeper and learn all of Lucee’s many capabilities. I’m certain, for example, the vast majority of them have no clue how close cfscript is to JavaScript (though that doesn’t appeal to js-haterz haha).

Anyhoo, @bennadel that’s enough of that tangent from me, as I would also like to know the actual answer to your question! :grinning:

I suspect it’s an issue of priorities and what most people are requesting, but also wonder if it’s … complicated! Or not?


As much as I get that to a programmer less code is poetry, not everyone should be a hardcore programmer to produce their desired application.

If the code runs, and works as intended, its a win in my book. Nobody running the application besides another programmer will ever care what the code looks like.

We have a great language, and I will say that @bennadel has in many ways been one of the largest promoters, if not the largest promoter of practical use of the language for the community.

We as much as you disdain “legacy” code, the hard fact is, applications written in that legacy code in 2000 with little to zero modification still work. Not many dynamic languages can say the same.


You could make your own functions!

I’ve followed the recommendations of some random guy, who, in my opinion, is quite smart. Using functions as he suggested in his article with very good results.

Anyways, I agree completely and was hoping things like this would be implemented in the language.


Yes I already stated that my ancient legacy code runs just fine, but my preference for cfscript is not simply an issue of less code. It is the fact that I can read my own cfscript – even if it’s old – way quicker than my old tag-based <cfml> code. This is super important when I need to fix old bugs or add new features that involve old code. I can get into The Flow of my own code far easier when it’s cfscript, even if I’ve already forgotten what I did yesterday, therefore I can get more stuff done every day!

But how you and I perceive our own code is not relevant to the point you originally raised about why CFML gets bad mouthed. I stand by what I’ve said about that and welcome any feedback, although we might want to take that to its own topic? :wink:


I do love the way Lucee CFML is bringing unique features to the forefront, like the ability to add customized, global functions. But, I also get nervous about changing global behavior. Especially if you start to pull-in other people’s code; I think you run the risk of getting conflicts.


Very true, also we cannot see easily how these functions impacts on performance as you said.

I would love to have more builtin functions as well. There’s always place to use them!