Outsider perspective

Micha,

I like almost all of what you stated, with a few exceptions:

  • I don’t think .lucee would be a suitable file extension, but .lcfm and
    .lcfc could distinguish “pure Lucee” from ACF-compatible code and would
    distinguish components from view code.
  • I think you mean “deprecation” instead of “depreciation” - a common
    point of confusion, just ask @dfgrumpy on the CFHour podcast. :wink:
  • I agree that setting ACF-compatibility in the administrator is not
    ideal. What if instead there was a “this.acfcompatibility” setting added
    to application.cfc. It would take a struct, and each deviation from ACF
    that Lucee takes would have a distinct key name and boolean value:
    • this.acfcompatibility= { supportsomeACFscrewup: true,
      supportsomeotherACFscrewup: false };

But overall, I like where the thinking is going.
-Carl V.

about the extension, it is not my intention to call it “.lucee” that was
just to make it clear that there could be a lucee specific extension.
so let’s think about it:

Distinction between component and templates?
So the first question is, do we need a distinction with the extension?

Nope.

I didn’t see any point in discussing it further prior to clarifying
whether you were simply speculating, or whether it was going to happen.
Which you still haven’t. If it was merely a “what if…?” then my reaction
is "lovely, but can we discuss something concrete pls, otherwise we’re just
wasting our time”.

It is going to happen if the community wants it to happen. That is people
discussing it. So you have to throw ideas out there to the community. Micha
did say: "If the community likes the idea, we go for it! technically there
are no hurdles we cannot cross.”

That is to “discussion” what a stick of celery is to a BBQ.

There’s clearly more to the idea that Micha is floating regarding diverging
code “styles” from simply CFML to something else which one might put into
a file with an entirely different extension
, and unless he’s gonna
actually add some substance to it, I see little point in fucking around
trying to guess what he’s on about.

Which leaves the most interesting part of the discussion to be quibbling
over the merits or otherwise of a five character file extension.

Your mileage might vary.

Ah, templating… endless options here…

Personally…

  • Using one extension for both script and template files seems to discard
    an available bit of info when eyeballing a collection of files. But a) in
    most cases directory structure should make the distinction clear, and if
    not, it’s certainly arguable that there are larger problems afoot. b)
    Nothing stops you from using two extensions, just register both lucscr and
    luctmp (say), and use the appropriate one by convention.

  • There’s no way I like <%= user.name %> more than #user.name#. Maybe it’s
    not as buzzword compliant, but it sure is cleaner and less verbose, at the
    expense of having to double # signs if to display one. Arguably <cfloop and
    friends are somewhat uglier, and apparently there’s a lot of desire to get
    away from the ‘cf’ baggage, so I’m not sure where that leaves us.

  • If Lucee is going to make fundamental changes in this area, it seems
    unlikely we need to reinvent the wheel. Don’t know how easy it is to drop
    an existing package into Lucee, but that’s probably the best plan. Is
    template handling another aspect of the language that should be modular
    rather than core, so you can drop in jsp, mustache, haml, cfml, etc?

  • Unless template files are fully compatible with some widely supported
    convention, this sort of change would render every IDE and code editor
    useless. Extensions are typically configurable in an editor, but template
    parsing within a given language typically is not. That seems like a
    significant downside. It’s hard enough gaining enough momentum to enhance
    the decent but clearly less than ideal CFML support that exists in current
    IDEs. The community (myself included) didn’t manage to improve IntelliJ’s
    CFML support, even though it’s amazingly great as an IDE (IMO). Starting
    over from zero means there won’t be anything available for some time.

Dave

Sorry for the misunderstanding, Micha, but I thought it was pretty clear
that the vast majority was very much in favor. There’d be no other reason
to discuss the extension. :slight_smile:

To be extra clear, I personally could not possibly be more in favor of the
idea of moving forward and leaving Adobe completely in the dust so that
“outsiders” can be enticed to give it a try, and this idea is quite likely
the best way to do just that.

To infinity and beyond!

:slight_smile:

Just my 2 cents, but why worry the extension name at all…make it a
setting in the Serve and/or Web admin so that people can use whatever
extension they want forneach of the 3 file handlers (CFML, CF Component and
Lucee). Use a comma delimited list or something.

yeah i was thinking about that, but there are 2 problems

  1. mark already explained the first, second is that most people are
    depending on existing applications (FW/1, coldbox …), so they need at
    least a default extension, a common ground.

I’m with Adam; not a fan of wasting time. I can’t even imagine what Lucee
Server would be without its CFML engine. So many other languages that run
on the JVM already. The modules Micha has proposed are great ideas. Make
Lucee’s core an efficient as possible. If I want ORM, I’ll add it.

But how about Lucee gets to a point where there are some installers ( that
work on Windows, Mac, Linux ), and the current CFML language is cleaned up
( as proposed by Micha ) and documented well ( like ColdBox ) and in a
year, assuming it takes that long to get there, then we talk about how to
appeal to outside developers. Adobe isn’t going to clean things up, and
they’ve proven to be rather incompetent at fixing bugs in a timely manner.
I for one, would love for Lucee to be the ColdFusion Server we’ve always
wanted. Otherwise, the choice isn’t which CFML server to use - it is which
other server to switch to - NodeJS, Groovy, .NET, etc.

So should I name my first file Sweet.lucee or Sweet.lucy?

Just my 2 cents, but why worry the extension name at all…make it a setting in the Serve and/or Web admin so that people can use whatever extension they want forneach of the 3 file handlers (CFML, CF Component and Lucee). Use a comma delimited list or something.

it’s funny, no body is discussion about the general idea, only about the
extension for it :wink:
It’s like we asked if we should get a new car and everybody is already
discussing about the color of the car.

Adam asked what “what if” means, if this is already in the pipeline or just
a idea?
If the community likes the idea, we go for it! technically there are no
hurdles we cannot cross.

Micha

I’m with Adam on this one, there is nothing wrong with .lucee and makes it
very clear what the file is for.

Also would like to see the “coldfusion” support moved out into an extension
so you only install it if you want it, so then Lucee becomes a language in
it’s own right that has CFML support if you want/require it.

Kind regards,

Andrew

I didn’t see any point in discussing it further prior to clarifying whether you were simply speculating, or whether it was going to happen. Which you still haven’t. If it was merely a “what if…?” then my reaction is "lovely, but can we discuss something concrete pls, otherwise we’re just wasting our time”.
It is going to happen if the community wants it to happen. That is people discussing it. So you have to throw ideas out there to the community. Micha did say: "If the community likes the idea, we go for it! technically there are no hurdles we cannot cross.”

And the file extension “conversation” only cropped up because someone admitted being too lazy to type five characters for a file extension. I didn’t think it needed conversation at all. The extension should be “.lucee”, and should be the same for both class and view files.
Adam Cameron <@Adam_Cameron1>

Makes it easier for parsers and what have you. Which is where the next question for me is, how is the lucee language going to look? Can we finally remove the "<cf” from view tags pls?

Still: ppl like chatting… there’s nothing wrong with that.

If I ruled, people wouldn’t chat, they would converse!

MD

it just loved the dynamic of the discussion …

Micha

Pascal died back in the 80s.

I shed a tear for it’s passing - it was the first programming language I
learned in depth, back in ’79 (I’d done a little Algol 60 before then).

Pascal FTW! “The king is dead, long live the king” Re: Delphi (and such),
which I did some work in a couple years ago-- I hadn’t even known from
whence it sprang, at first. Pascal is what got me into assembly
language… good times!

-Den

.lc would be a nice extension if it’s not commonly used. I’m
imagining typing .lucee 10,000 times…

Yeah, but you’re not exactly typing it 10000 in a row. How many new
files are you creating within a given day?

And, like .java, .groovy… we’re not all scared of keystrokes.

Agreed. Besides, if a real IDE is supported, no one will ever have to type
the extension, anyway. I’m not sure I’ve ever typed “.groovy” other than
just now in this email.

I really like the idea of having a common-ground support of CFC and CFM and
adding a new extension to segment the new from the old.

I feel like the homepage of lucee.org says it all:
“Lucee is a light-weight dynamic scripting language for the JVM that
enables the rapid development of simple to highly sophisticated web
applications.”

It doesn’t say anything about CFML, open source alternative, etc. It’s a
JVM scripting language. Continue to position it as such, shed the stigma
and the baggage and it becomes attractive to other developers again and the
eye rolls start to go away. Instead you get curious interest “You work with
Lucee? What’s that?”. To echo others, chipping away at ACF’s pool isn’t
going to grow this community and project very much. It’s been a downward
trend. Infuse new blood in from other places. We’ve hired some people who
had more .NET and Java exposure in the past who have picked up writing
script based CFCs up quick and have found it to be pretty easy and straight
forward to work with and get what they need done.

-Dan Kraus
(I can add something about being a Lucee Supporter to my signature line or
something, right? That was one of the perks, right? I want a membership
card!)

Moving stuff to extensions

depreciation framework

ACF compatibility

Wow… sometimes I’m really just too short-sighted.

Great ideas all of them. +1

– Denny

+1 Having two servlets, web.xml is easy enough to customize and we can continue using whatever extensions we want by editing the relevant servlet-mappings.

I’m totally digging this concept. Move on from .cfm/.cfc, move the language forward while maintaining compatibility for those who need it.

I am extremely excited for Lucee and where she will take us!

Micah, I was assuming that Lucee could adjust the web.xml file automatically based on the users input, however I have no clue as to whether the admin has/could have access to that file. Regarding the common ground issue…I agree and would just implement the basic defaults which probably leads us back to the file extension discussion…and I just don’t care what it is.

Your the Ninja Master so I’m happy to sit back and do what I’m told.

Regards,

Tanner Bachman

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.