To get back to the original post, I understand people's concern about
having to change existing code and systems that run on ACF or Railo. Nobody
wants to do that in a corporate environment when you have something in
place that just works. For people like that, maintaining 100% (or close to
that) backwards compatibility with ACF/Railo is very important, and they
can justify it better to corporate heads.
However, by doing that I fear that Lucee will simply fall on the wayside,
just like ACF has been for the last years, and unfortunately Railo as well.
To have a language move forward you need new people to pick it up, with
vitalized energy and excitement of the potential, to blog about it, talk
about it, come up with awesome frameworks and plugins, make pull and push
requests to git, be active. That is never going to happen if the language
plays it safe. In a few years, there will be no need for ACF, Railo or
Lucee. Look at all the people that we used to look up to for blogs and info
- they may still publish a blog once in a while on CF, but they really
don't have anything new to talk about anymore. It's all been said and done.
If you are a developer who wants to write about the language, what do you
really have to write about regarding CF, other than finding bugs in Adobe's
or Railo's implementation?
Once we agree on a radical new approach to the language, then a lot of
exciting things can happen. Micha talked about a new extension for example.
Personally, I don't care if the extension is
".awesomenewjavajvmweblanguage", ".luc" or what not. The idea that we can
lay a foundation for backwards compatibility, make that a starting point
for the race, and then run forward with it is brilliant. I don't even care
for backwards compatibility 1-2-3 settings (like Micha suggested). If
someone wants to write ACF compatible code then stick with ACF, pay their
fees and shut up. If you want to be involved with a sweet language that
evolves, then go with Lucee.
One other thing I want to mention is the difficult distinction that needs
to exist with the language itself and frameworks. I understand that those
are not one and the same, and where the language stops, it's the
framework's function to step in to make our life easier as a programmer.
Frameworks like FW/1, ColdBox and so on really do make our lives easier
(some would argue that), but I am a believer in what they try to achieve.
If you look at a framework like Laravel, and create an app with it, the
first thing you will ask yourself is what in the world are you doing
writing CF? It's just plain awesome. You might say Laravel is not PHP
though, and PHP sucks. I agree on that, PHP is not the best thought out
language, but it moves forward, and it provides an incentive for frameworks
like Laravel to come out and flourish. So, having that distinction in mind,
I would still love to see an effort in the language itself to standardize
things, in a sort of recommended framework approach to writing an app.
There are just not enough people to create something like Laravel, and
perhaps throwing some effort behind frameworks like FW/1 would really help
bring new people in from other languages. To bring an example of what can
be done, look at the way we write CFM and CFC nowadays, mixing script and
tags in both. Lucee could make scripting mandatory for both, have one
extension for both, and implement a Blade style template engine, where
instead of writing HTML and injecting tags or script in templates, you
would instead write script and inject HTML.
Honestly, I am happy we are having these type of conversations and excited
to see what we can do.