arguments against .lucee extension

[Ryan Guill]

I would like to argue two points.  First that a new extension should not be created, and second, if it is created it should not be called ".lucee".

I have just read through the group and all of the arguments that I could find for a new extension to separate the way code is processed are because of the following needs: deprecation of existing code features and idioms, addition of new features and idioms that would not be backwards compatible, and a way to break away from the stigma of CFML.

Deprecation can happen inside of the existing cfml files without the need for a new extension.  Deprecation of tags, functions or idioms can be handled at the engine level in many ways - the easiest I can see would be a pragma rule in Application.cfc that sets a language level. Something similiar to "use strict" in javascript.  Any CFML engine (such as ACF) that does not implement these pragmas can just ignore it.  Any use of deprecated functionality or idioms can start throwing errors if the pragma is used.  If necessary, the pragmas could have levels of enforcement, for instance to throw a warning into a log file instead of an exception at a certain level.

New features that are not backward compatible could be handled with the same sort of pragma rule. The way var works in a block vs function scoping for instance - at a certain pragma level it can have the new implementation.

Again, a pragma is just one way - using "this." settings is another, or a specific file that would sit alongside Application.cfc. I'm sure there are others we could come up with.

Breaking away from the stigma and baggage of CFML is a valid concern, but I would like to argue that the likelihood of lucee appealing to a wider audience outside of the current CFML community is low.  There are just too many options for other languages on the JVM alone, languages that have been designed from the ground up with a consistent vision and with modern features.  Also, unless the intention for "lucee.next" is to start an entirely new language from scratch, you are still going to be taking at least some of CFML's baggage with you regardless.  Calling it a new name in hopes to trick some newcomer that lucee isn't the CFML they've heard about isn't going to work for very long. IMO the best way to appeal to a broader demographic is to expand the interoperability with other languages - both using those languages inside of CFML and using CFML inside of other languages.  See the work Sean is doing with cfmljure.  Using CFML as a templating language from groovy would have a lot of appeal I believe.  Being able to use JS via Nashorn in lucee would be amazing.  I know there has been some talk about JSR-223 in the past which is a step in the right direction - the ability to use those other languages inside of CFML would be just a nice.

That said, if you find that it is necessary to have a new extension, please reconsider using ".lucee" specifically. Firstly it makes compatible forks and language implementations harder if not impossible.  Consider if this idea had come up a few years ago and ".railo" had been used.  When it was forked and became Lucee we would have been in the same boat that we have been in with the .ra files, only it would be a much worse situation.  I'm sure its hard to consider that Lucee might be forked by the same crew again, but surely it cannot be ruled out completely? The same would also apply to anyone else wanting to come along and fork lucee into a compatible engine.

It also means that Adobe cannot / will not be able to implement the advances made.  No matter what your opinion of Adobe and their handling of the language, they have implemented features initially developed in Railo and there is no reason to believe they wouldn't continue to do so.  And even if you think that Lucee should forge its own path away from ACF, that doesn't mean that we should preclude them from being able to take up these features, and make a compatible engine going forward.  Using ".lucee" means that at best they will implement the same features with a different extension.  This will also make things harder on library authors hoping to support multiple engines, something that is at least possible today.  Using ".lucee" will ultimately lead to a lack of choices for developers. We already have a documentation problem in all engines.  In the past week alone I have used the ACF documentation for lucee code many times. I have used railo documentation in the past for ACF code because of holes they have. Ultimately if you at least consider that the CFML history is not something that we will be able to shake completely, we are a stronger community together than we are individually.  Of course Adobe might not pick up any of the advances made here - but I just don't see any good reason for making it harder for them to do so.

There are other options available if a new extension is necessary.  ".cfs" for cfscript or ".cfn" for CF-next. I'm certain that if necessary there are other - more inclusive - options available. In an ideal world we could get to a broader language specification and the file extension could reflect the version of that language, but of course I don't believe that to happen anytime soon.  

[Adam Cameron]

Excellent post, Ryan!

On Tuesday, 10 March 2015 00:36:35 UTC, Ryan Guill wrote:

I would like to argue two points.  First that a new extension should not be created, 

I'm heading in this direction too. I am severely doubting there's a place for it in the market, and it could ever get sufficient traction to be anything other a dilution of Lucee's - very scarce - dev resources.

But equally I think ppl have had some good ideas that aren't compatible with CFML: either in the sense of Adobe's "reference" version, or just the language the way it is, even ignoring the Adobe side of things, so not sure what to do about that.

and second, if it is created it should not be called ".lucee".

This had not occurred to me, and you go on to make a very good case. So if the Lucee Association did decide to go with a new language, the language's name short be divorced from the vendor producing it? Makes good sense, for the reasons you cite.

 

Deprecation 

New features

I think the issue for me is less how this sort of thing is handled - it's all doable as you say - but I am hesitant about the divergence from Adobe all within the same language.

 

Breaking away from the stigma and baggage of CFML is a valid concern

I think Lucee needs to pull its head in on this one. Whilst CFML has some bad press, at least it has some press (*). I don't think Lucee has the resources (or, to be brutally honest, the ability) to market a new language contender in such a way as the new project will me more successful than simply marketing it as a better CFML engine than Mother Ship's. Perhaps with the new dialect they should be marketing it as CFML++ (not actually in those terms literally), rather than starting from scratch.

There are other options available if a new extension is necessary.  ".cfs" for cfscript or ".cfn" f

Well: neither of those actually are available though:

http://filext.com/file-extension/cfn

http://filext.com/file-extension/cfs

But still, yes - detail aside - I think you're right.

I was initially very enthused by the exciting shiny new direction that the Lucee Association could take us. But as the dust settles after the launch, I don't see it as being viable any more to be too excited about stuff. I think they need to retrench and re-message. Embrace that what they are is a CFML variant, work on converting and growing the existing CFML base instead of trying to invent another one, and accept that what they do is CFML. Just do a better job of it than Adobe does (and perhaps have a bit more aspiration than that. That's just daming with faint praise ;-)

That said, I also think the dust is still settling after launch so I am still watching with - slightly muted now - enthusiasm - but I've reigned my expectations back in a bit too.

What I'd like to see from Lucee is this:

* some sort of indication of a roadmap of where they intend to take the project as a whole. Not a technical roadmap (no mention of functions or tags or file extensions), but a marketing one. How are they planning on improving its install / usage base.

* a more coherent plan of what the story is with the new dialect. I am concerned there's gonna be a half-baked jump into the unknown here, rather than something well planned and considered before they start.

There needs to be more to this project than Micha and Igal pushing releases out. I'm hoping someone else is behind the scenes doing some actual business planning of all this. It's lack of this stuff that has me most concerned @ the mo'.

-- 

Adam

(*) as far as I know there's still not even an official press release stating Lucee exists. My blog article is about as close to that as we've got, and my blog doesn't have appropriate credibility for that to be a valid approach.

[Dominic Watson]

I agree, and think it would be great to have a discussion around the topic, "What can Lucee do to break free from CFML compatibility, while still supporting the CFML community?". A new language set, controlled by a different extension is certainly one way - but I wonder if the community has any other ideas (rather than debating the wrong question of "Should we have a .lucee extension?").

What I think may muddy matters here is that there is already code to make this new extension work, it just has not yet been added to the Lucee core. So there is already personal investment in this for those involved. I for one would urge Lucee to be cautious of moving into core too early.

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/c5fcc7bf-c7ee-49f0-99c9-8c86855abd2d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Pixl8 Interactive, 3 Tun Yard, Peardon Street, London SW8 3HT, United Kingdom T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: in...@pixl8.co.uk

Follow us on: Facebook Twitter LinkedIn

CONFIDENTIAL AND PRIVILEGED - This e-mail and any attachment is intended solely for the addressee, is strictly confidential and may also be subject to legal, professional or other privilege or may be protected by work product immunity or other legal rules. If you are not the addressee please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead, please email it back to the sender and then immediately permanently delete it. Pixl8 Interactive Ltd Registered in England. Registered number: 04336501. Registered office: 8 Spur Road, Cosham, Portsmouth, Hampshire, PO6 3EB

[Adam Cameron]

On Tuesday, 10 March 2015 09:34:26 UTC, Dominic Watson wrote:

What I think may muddy matters here is that there is already code to make this new extension work, it just has not yet been added to the Lucee core. So there is already personal investment in this for those involved. I for one would urge Lucee to be cautious of moving into core too early. 

I think that would be premature in the same way the various disparate documentation site projects jumped the gun making their prototypes public.

Still: I s'pose the Lucee Assn can do whatever it likes, well-planned or otherwise: it's their project.

-- 

Adam

[Dominic Watson]

> Still: I s'pose the Lucee Assn can do whatever it likes, well-planned or otherwise: it's their project.

Indeed, best we can do is voice concerns eh. What I'd like to see is a 5.0.0 release without the dialect, there's plenty in 5 to get excited about already without that. Then some more solid information about what is in the new dialect and how it will work before adding it in 5.1 (or not at all), giving time for community input which seems to have been Lucee's mission statement from the get go.

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/0fdd8736-a6d8-4141-922e-3a7dac73bce6%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Ryan Guill]

I think the issue for me is less how this sort of thing is handled - it's all doable as you say - but I am hesitant about the divergence from Adobe all within the same language.

That is a fair position to take, but to be clear - my argument is not against diverging from ACF or CFML's history - it is against using a file extension as the gate to those changes.  I am for the deprecation and new features in general (I reserve the right to be against any of them specifically).

 

 

Breaking away from the stigma and baggage of CFML is a valid concern

I think Lucee needs to pull its head in on this one. Whilst CFML has some bad press, at least it has some press (*). I don't think Lucee has the resources (or, to be brutally honest, the ability) to market a new language contender in such a way as the new project will me more successful than simply marketing it as a better CFML engine than Mother Ship's. Perhaps with the new dialect they should be marketing it as CFML++ (not actually in those terms literally), rather than starting from scratch.

I agree.  My opinion is that the best chances in the future is lucee marketed as a better, more evolved CFML. 

There are other options available if a new extension is necessary.  ".cfs" for cfscript or ".cfn" f

Well: neither of those actually are available though:

http://filext.com/file-extension/cfn

http://filext.com/file-extension/cfs

We would hardly be the first to use the same extension as some other filename.  Rust uses .rs which is also taken: http://filext.com/file-extension/rs.  Ruby's .rb files are the same extension as real basic files.

But yes, those were just examples, I don't particularly like either one of them.  

 

[Ryan Guill]

What I'd like to see is a 5.0.0 release without the dialect, there's plenty in 5 to get excited about already without that. Then some more solid information about what is in the new dialect and how it will work before adding it in 5.1 (or not at all), giving time for community input which seems to have been Lucee's mission statement from the get go.

I tend to disagree - if we can come to a conclusion about a different way to gate the new features and breaking changes id like to see at least an initial implementation of it if it is ready in the 5.0 betas - that gives us something to level against and start talking about concrete implementations instead of the abstract ".lucee extensions could work this way" that we are doing now.  If the features aren't ready for prime time they could be left out of the released version. 

I have a few different proposals I'd like to make, but i'm waiting for 5.0 to see what is in there and how this new dialect will be implemented to know how best to proceed.

[Dominic Watson]

My position on that is that 5.0.0 has been pretty much ready for what seems like a very long time indeed and that it should get released without any new major features.

This dialect should first be released as an extension to Lucee in my opinion (if that is indeed possible). It can then be safely evaluated without the slightest furore.

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/e146c5ac-c735-427d-88d3-28edd87a85ab%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Ryan Guill]

This dialect should first be released as an extension to Lucee in my opinion (if that is indeed possible). It can then be safely evaluated without the slightest furore.

I am still reserving judgement on the extensions until I get to actually play with them and how they are handled, but if this could be incubated in a non-required extension first I think that is a great idea. I am interested in how the extensions managed by lucee themselves will be handled from an open source perspective - where they will live and will they have their own bug tracking / documentation / etc.

[Gert Franz]

Here’s my take on it.

 

The extension .lucee is questionable, but let’s not forget that the extension cfm contains the name ColdFusion in it as well.

 

And I don’t agree to adding settings to the Application.cfc, since then everything will then depend on switches which makes the code slower in the end and harder to debug. These settings could come from anywhere. And partly they are compiler settings which CAN NOT be made in an Application.cfc.

 

Whether the name is ok or not, doesn’t really matter. Adobe will, no matter what, do their own thing – if they follow Lucee in the first place – even if we could call it somewhat different. It has happened several times in the past already.

 

The only thing I personally have against the name .lucee is that it is too verbose and that it is the name of the product.

 

Sincerely
Gert Franz

 

RASIA GmbH

Spittelgasse 7

5103 Moeriken-Wildegg

Email: ge...@rasia.ch
Skype: gert.franz

Phone Switzerland: +41 76 5680 231

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/e146c5ac-c735-427d-88d3-28edd87a85ab%40googlegroups.com.

[Adam Cameron]

On 10 March 2015 at 12:47, Ryan Guill <ryan...@gmail.com> wrote:

I'd like to see more about the vision for .lucee (or however it manifests) before even thinking about code, and which release it might be in. I realise the Railo (then Lucee) bods have jumped the gun a bit there: working on the code before delivering the vision & involving the community @ that point, which is unfortunate.

Still: I will maintain a demeanor which is on the positive side of the dial. Just not one that's cranked all the way to 11.

But... screw that. Get the docs sorted out properly first. Let's get the CFML side of Lucee's house in order first, before we start worrying too much about where else and into what to sink time.

-- 

Adam

 

[Gert Franz]

And I hasten to add, that I would prefer it being already in Lucee 5.0.0 as beta or even alpha too… Since then people can get familiar with it and we can improve it if there are lots of downsides etc.

 

Sincerely
Gert Franz

 

RASIA GmbH

Spittelgasse 7

5103 Moeriken-Wildegg

Email: ge...@rasia.ch
Skype: gert.franz

Phone Switzerland: +41 76 5680 231

 

Von: lu...@googlegroups.com [mailto:lu...@googlegroups.com] Im Auftrag von Ryan Guill
Gesendet: Dienstag, 10. März 2015 13:48
An: lu...@googlegroups.com
Betreff: Re: [Lucee] Re: arguments against .lucee extension

 

 

What I'd like to see is a 5.0.0 release without the dialect, there's plenty in 5 to get excited about already without that. Then some more solid information about what is in the new dialect and how it will work before adding it in 5.1 (or not at all), giving time for community input which seems to have been Lucee's mission statement from the get go.

 

I tend to disagree - if we can come to a conclusion about a different way to gate the new features and breaking changes id like to see at least an initial implementation of it if it is ready in the 5.0 betas - that gives us something to level against and start talking about concrete implementations instead of the abstract ".lucee extensions could work this way" that we are doing now.  If the features aren't ready for prime time they could be left out of the released version. 

 

I have a few different proposals I'd like to make, but i'm waiting for 5.0 to see what is in there and how this new dialect will be implemented to know how best to proceed.

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/e146c5ac-c735-427d-88d3-28edd87a85ab%40googlegroups.com.

[Sean Daniels]

Good points raised here all around. One item not mentioned yet, which I would consider an argument for creating a separate extension would be the ability for us to intermingle .cfm and .lucee (or whatever) files within an application. Allowing me for example to take advantage of features like full null support or case-sensitive struct keys in my own code, while still utilizing 3rd party code (ColdBox for example).

As it stands (or at least last I checked), ColdBox breaks when you flip the null support and case sensitive keys on at the application level. So to me it would be better to keep these out of the application settings. 

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/01fc01d05b32%2460efe010%2422cfa030%24%40rasia.ch.

[Jon Clausen]

+1 on verbosity and tying the extension to the product.  Though I think we’re spending an awful lot of time on file extension names, it is kind of important for the sake of longevity and easy identification of the language.  I also like the component file extension in CFML, if only for ease in scanning a new project.  

That said, what I *don’t* see us spending any time on discussing is concurrency and async behavior.    I’m getting the sense that we’re heading down the same sync-prioritized model of processing, which, IMHO, doesn’t distinguish the capabilities of the language from anything that is out there.  Scala is moving in that direction (http://docs.scala-lang.org/sips/pending/async.html ) even more and their Futures and Promises are really interesting implementations, even if I’m not a fan of their syntax.

Node/IO/JS has so many inherent problems for server-side programming, but it does prioritize async over synchronous blocking and it’s blazing fast for basic tasks.

I hope that discussions around the future will maintain a balance between the academic functionals of the language and looking ahead toward future application development needs/problems which could be addressed in a new language.

As we can all see from these discussions so far, once something is implemented and it ends up in our applications, there’s a great deal of passion and discussion involved when someone proposes to “kill our darlings”

[Adam Cameron]

On Tuesday, 10 March 2015 13:47:44 UTC, Jon Clausen wrote:

That said, what I *don’t* see us spending any time on discussing is concurrency and async behavior.    I’m getting the sense that we’re heading down the same sync-prioritized model of processing, which, IMHO, doesn’t distinguish the capabilities of the language from anything that is out there.  Scala is moving in that direction (http://docs.scala-lang.org/sips/pending/async.html ) even more and their Futures and Promises are really interesting implementations, even if I’m not a fan of their syntax.

I think we pretty much discuss any topic that's actually raised. If you see a shortage of conversation on Futures / promises, etc well... start one.

I await with bated breath (I mean really, I am... it'll be an excellent topic).

-- 

Adam

 

[Jon Clausen]

Fair enough. :)   I’ll start a separate topic on this later today. -J

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/dd86c1ff-eb2b-4cfd-a7e4-fd7c57524680%40googlegroups.com.

[Ryan Guill]

 One item not mentioned yet, which I would consider an argument for creating a separate extension would be the ability for us to intermingle .cfm and .lucee (or whatever) files within an application. Allowing me for example to take advantage of features like full null support or case-sensitive struct keys in my own code, while still utilizing 3rd party code (ColdBox for example).

A pragma could be used on a per file, or even a per function basis if that is the way it was implemented.  I agree though, we need a way to specify this on at least a per file level, but we have options other than extensions to do so. 

[Adam Cameron]

On Tuesday, 10 March 2015 14:27:19 UTC, Ryan Guill wrote:

 One item not mentioned yet, which I would consider an argument for creating a separate extension would be the ability for us to intermingle .cfm and .lucee (or whatever) files within an application. Allowing me for example to take advantage of features like full null support or case-sensitive struct keys in my own code, while still utilizing 3rd party code (ColdBox for example).

A pragma could be used on a per file, or even a per function basis if that is the way it was implemented.  I agree though, we need a way to specify this on at least a per file level, but we have options other than extensions to do so. 

But, really, wouldn't the file extension approach be a bit cleaner than the pragma approach? This sort of differentiation is kinda what file extensions are for after all? Why reinvent the wheel, and using an octagon as a template?

Or am I missing something?

-- 
Adam

[Ryan Guill]

And I don’t agree to adding settings to the Application.cfc, since then everything will then depend on switches which makes the code slower in the end and harder to debug. These settings could come from anywhere. And partly they are compiler settings which CAN NOT be made in an Application.cfc.

I am sympathetic and sensitive to performance issues, but I implore you not to use compiler settings or administrator settings or anything that is not in the code itself.  Dependencies or switches that the code relies on to perform in the way it is intended belong in the code.  I'd like to understand more about what cannot be made inside of Application.cfc or something equivalent.  Every time something like `complete null support` comes along that is a system wide thing it limits your ability to use libraries or existing code in and alongside new code.  Compiler options are much harder to debug because you have to know the state of things outside of the code you are looking at to be able to reason about it.  Source code repos and gists need a readme to go along with them to make sure that things are being deployed properly.  This is one of the reasons i'm skeptical about extensions the way they have been described - I really hope we wont have to restart a server to be able to install dependencies.

[Ryan Guill]

But, really, wouldn't the file extension approach be a bit cleaner than the pragma approach? This sort of differentiation is kinda what file extensions are for after all? Why reinvent the wheel, and using an octagon as a template?

Think of every code snippet you share - do you want to also have to specify that it goes in a particular file extension to work? File extensions convey that it isn't CFML, its something else - everything ive seen Micha say on the topic says that this is an evolution of CFML not something new - and that is what I am also hoping that we are talking about.

File extensions would mean that IDE's and source control systems need to be updated (although depending on the features some updating of syntax highlighting at least will need to happen in IDE's anyway).

Again, if file extensions really are the best way to do this then fine, but hopefully use something besides ".lucee". 

[Jean Moniatte]

I think it is important that we can run both cfml and lucee (or whatever the name) code within the same request, so that applications can be only partially migrated to the new dialect. Controlling the behavior via application.cfc would not allow this as far as I understand.

Thanks,

Jean

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/f835c7cd-4a23-4bf4-9abb-dc8e6902daf9%40googlegroups.com.

[Jesse Shaffer]

Well said, Ryan.  I am torn on the issue also, mostly for the point you made about the market being too saturated with JVM languages.  However, I keep coming back to the thought of how far can you go, really, in defining a new dialect before it becomes a new language?  And shouldn't a new language have its own extension?

Something that comes to my mind is when C was extended and became C++, the .cpp file extension was introduced to prevent confusion even though it wasn't really a new language, just a superset of features.  And even then, older .c files were allowed to be compiled and included right along side .cpp files as C++ is C.  I see this as exactly what is being suggested for Lucee - which sounds great to me.  

Gert also has a very valid point:

... let’s not forget that the extension cfm contains the name ColdFusion in it as well ...

It was only later that a distinction was drawn between ColdFusion the Engine and ColdFusion the Language (more specifically, ColdFusion Markup, the Language).  The same sort of distinction would need to be made for Lucee the Engine vs Lucee the (Dialect/Language/whatever).

Overall, I think that a new file extension (and .lucee was only one suggestion - I would prefer something along the lines of .lc, or .luc, or .lcm/.lcc, or .lcs) offers the clearest distinction as to what code the file actually contains.  Adding pragma means as a developer, it becomes harder to look at a particular section of code and determine what rules are being applied.  It also means I cannot look at various packages of code and know immediately which ones work on ACF/Railo/Lucee, and the those that work exclusively on Lucee.

[Adam Cameron]

On Tuesday, 10 March 2015 15:53:15 UTC, Jesse Shaffer wrote:

Well said, Ryan.  I am torn on the issue also, mostly for the point you made about the market being too saturated with JVM languages.  However, I keep coming back to the thought of how far can you go, really, in defining a new dialect before it becomes a new language?  And shouldn't a new language have its own extension?

I started using the word "dialect" when discussing .lucee (as opposed to .cfm / .cfc) stuff because ppl were getting uppity about being "left behind" and CFML being marginalised.

But in reality, if whatever this .lucee concept is isn't basically a new language, it'll be a waste of everyone's time. IMO. We don't need CFML-and-a-half. No-one does. But if the Lucee Association wants to deliver both a CFML solution and a [new language of their invention because they think they can make a go of that, good on them]. I'll help & support them. If it's CFML-and-a-half... I'm out.

There's no prob with it being inspired by CFML (as you say, Jesse: C -> C++, or C++ -> C# etc), but it actually has to be something in and of itself. Not just a coupla incompatible things bolted onto CFML. That would bite.

-- 

Adam

[Ryan Guill]

I started using the word "dialect" when discussing .lucee (as opposed to .cfm / .cfc) stuff because ppl were getting uppity about being "left behind" and CFML being marginalised.

But in reality, if whatever this .lucee concept is isn't basically a new language, it'll be a waste of everyone's time. IMO. We don't need CFML-and-a-half. No-one does. But if the Lucee Association wants to deliver both a CFML solution and a [new language of their invention because they think they can make a go of that, good on them]. I'll help & support them. If it's CFML-and-a-half... I'm out.

There's no prob with it being inspired by CFML (as you say, Jesse: C -> C++, or C++ -> C# etc), but it actually has to be something in and of itself. Not just a coupla incompatible things bolted onto CFML. That would bite.

This is why its important to get a roadmap and clear direction from lucee about what we are even talking about here.  I don't like how this sounds as an ultimatum - i'm just some guy on the internet, I don't necessarily want lucee to change to fit me, I want lucee to make its intentions clear so I can make decisions - but I have pretty much the exact opposite of your opinion Adam.  If this new dialect is somethings radically new i'm not interested.  There are far too many other and better options out there to invest in. And I assert that a new language isn't going to appeal to the one opportunity for growth that exists for lucee today - existing CFML devs.

I feel like i'm missing some nuance to your position though Adam.  Earlier in your thread you said: 

I think Lucee needs to pull its head in on this one. Whilst CFML has some bad press, at least it has some press (*). I don't think Lucee has the resources (or, to be brutally honest, the ability) to market a new language contender in such a way as the new project will me more successful than simply marketing it as a better CFML engine than Mother Ship's. Perhaps with the new dialect they should be marketing it as CFML++ (not actually in those terms literally), rather than starting from scratch.

I have plenty of opinions, plenty of which seem to be at odds with the majority here, and thats great - im just part of some groups personally and professionally that are trying to make long term decisions - so whatever the decisions are we would just like to know what to expect. 

[Adam Cameron]

On Tuesday, 10 March 2015 16:58:22 UTC, Ryan Guill wrote:

This is why its important to get a roadmap and clear direction from lucee about what we are even talking about here.  I don't like how this sounds as an ultimatum - i'm just some guy on the internet, I don't necessarily want lucee to change to fit me, I want lucee to make its intentions clear so I can make decisions - but I have pretty much the exact opposite of your opinion Adam.

Which is fine. You don't, btw, have to apologise for being "just some person". We all are. All any of us are doing is expressing an opinion. This is why mailing lists exist.

 

 If this new dialect is somethings radically new i'm not interested.  There are far too many other and better options out there to invest in. And I assert that a new language isn't going to appeal to the one opportunity for growth that exists for lucee today - existing CFML devs.

Cool. You seem to be frightened to not agree with people, Ryan. It's fine. I think hyour opinions are well-formed and worth everyone reading and giving consideration to. I can do all this whilst not actually necessarily agreeing with them. So oght everyone else be able to, I reckon (I have no reason to doubt this).

 

I feel like i'm missing some nuance to your position though Adam.  Earlier in your thread you said: 

I think Lucee needs to pull its head in on this one. Whilst CFML has some bad press, at least it has some press (*). I don't think Lucee has the resources (or, to be brutally honest, the ability) to market a new language contender in such a way as the new project will me more successful than simply marketing it as a better CFML engine than Mother Ship's. Perhaps with the new dialect they should be marketing it as CFML++ (not actually in those terms literally), rather than starting from scratch.

I have plenty of opinions, plenty of which seem to be at odds with the majority here, and thats great - im just part of some groups personally and professionally that are trying to make long term decisions - so whatever the decisions are we would just like to know what to expect. 

You're conflating (at least) two things. Lucee is actively shying away from an association with CFML. People have observed that its roots were very downplayed in the first pass of the marketing website. There were a few "cautious" comments from posters here who noticed this initially.

Previously I was all good with them distancing themselves from CFML, and I see where they were coming from. However they've distanced themselves from CFML, and then replaced that with... nothing. That's daft. If they don't want to mention CFML, they have to then replace that with something better. As they haven't achieved that, I suspect they don't have any further idea on the subject, therefore I think the idea to distance themselves from CFML - whilst admirable - was a mistake.

As for whether I think they should do the .lucee dialect or not? Well I think... no. No they shouldn't. I used to think they should, but I don't think they should any more. I don't think they've got the personnel to achieve what they need to achieve here. So they ought to instead focus on delivering a performant, low-footprint CFML engine. This is playing to their strengths.

However they're going to do it, we all know this, so my position there is "in for a penny, in for a pound" (or as is actually going through my head "piss or get off the pot"). CFML-and-a-half is a waste of time for what I think they ought to be wanting to do. Whether or not I think they should be doing it at all.

And, in case this somehow got lost in translation... all of this is solely my opinion and I have no expectation for everyone (or even anyone) to agree with me, or to action anything, or to do anything with this info at all other than to note "oh, OK, that's Cameron's opinion". I also reserve the right to adjust my opinion in part or entirely as more information comes to hand. It's bloody stupid I feel I need to say that, btw.

-- 

Adam

[Andrew Dixon]

Adam, what is the difference between:

 So they ought to instead focus on delivering a performant, low-footprint CFML engine. 

and 

CFML-and-a-half 

As you say the Lucee team should do the first but not the second, but to me they sound like one and the same thing!!!

Kind regards,

Andrew

about.me
mso - Lucee - Member

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/097262a4-ec38-4f09-ba3e-cbafb4b21497%40googlegroups.com.

[Ryan Guill]

Which is fine. You don't, btw, have to apologise for being "just some person". We all are. All any of us are doing is expressing an opinion. This is why mailing lists exist.

 

Cool. You seem to be frightened to not agree with people, Ryan. It's fine. I think hyour opinions are well-formed and worth everyone reading and giving consideration to. I can do all this whilst not actually necessarily agreeing with them. So oght everyone else be able to, I reckon (I have no reason to doubt this).

I am not worried about not agreeing with people, it's why I started the thread after all.  I'm just not personally comfortable with my efforts being perceived as my saying "Do things my way or i'm taking my toys and going home" which is the way I feel like some of this comes across.  I want to offer my opinions and let the powers that be decide - and I want them to make those decisions without some veiled threat influencing them.  I hope that decisions will be made on practical, reasoned and researched information, not the perception from the outspoken few that are brave enough to step up in the discussions. But ultimately I just hope to spur *some* decision.

 

And, in case this somehow got lost in translation... all of this is solely my opinion and I have no expectation for everyone (or even anyone) to agree with me, or to action anything, or to do anything with this info at all other than to note "oh, OK, that's Cameron's opinion". I also reserve the right to adjust my opinion in part or entirely as more information comes to hand. It's bloody stupid I feel I need to say that, btw.

Would you say that is your 2 cents then? ;) 

[Adam Cameron]

On Tuesday, 10 March 2015 17:48:16 UTC, Ryan Guill wrote:

 I'm just not personally comfortable with my efforts being perceived as my saying "Do things my way or i'm taking my toys and going home" which is the way I feel like some of this comes across.

You don't come across that way at all mate.

 

 

And, in case this somehow got lost in translation... all of this is solely my opinion and I have no expectation for everyone (or even anyone) to agree with me, or to action anything, or to do anything with this info at all other than to note "oh, OK, that's Cameron's opinion". I also reserve the right to adjust my opinion in part or entirely as more information comes to hand. It's bloody stupid I feel I need to say that, btw.

Would you say that is your 2 cents then? ;) 

Well yes: precisely. Hence my revulsion at the thought I felt I needed to say it. 

-- 

Adam

[Adam Cameron]

On Tuesday, 10 March 2015 17:25:56 UTC, Andrew Dixon wrote:

Adam, what is the difference between:

 So they ought to instead focus on delivering a performant, low-footprint CFML engine. 

and 

CFML-and-a-half 

As you say the Lucee team should do the first but not the second, but to me they sound like one and the same thing!!!

Well there's some low-impact feature augmentations (new closure functions for example) which I think are a good fit for a slight divergence from Adobe's CFML, and seem OK to me to create a backwards compat issue.

But I don't think some of the more ambitious changes Micha has in mind are a good fit for a CFML engine. They just strike me as straying too far off the CFML path.

-- 

Adam 

[Robert Munn]

Don’t take my word for it, because I don’t represent LAS, but from what I have gleaned from the discussions, the current plan seems to be:

- Lucee on the market ( done )
- Get the CFML community informed about and interested in Lucee ( ongoing )
- Installers, docs, wiki for Lucee on the market ( ongoing )
- Design new language / dialect for Lucee ( ongoing, and note from the spreadsheet of features that there has been a lot of discussion behind the scenes about it )
- Lucee 5.0.0
- new dialect
- extension packs for non-core parts of CFML (ORM, etc. )
- other ( ? )

I don’t think there is any reason to debate the new dialect. If the members of LAS want a new dialect, Lucee will include it. CFML will still be supported, so it really isn’t an issue to be concerned with, IMHO.

Beyond these features, there is a whole world of features future versions of Lucee could include. I would like Nashorn integration, others might like Clojure integration, etc. Whether they are included is up to the members of LAS.

[Abram Adams]

Good points all around.  I'm in the camp that a "CFML-and-a-half" is exactly what Lucee should be.  Well, maybe a-better-CFML-and-a-half.

Most language splits I've witnessed over the years end up with way too many folks on both sides of the split for way too long.  This is because they've always been an all-or-nothing switch.  One of the upcoming "splits" is Angular 1.x to Angular 2.x.  Breaking changes abound.  However, what the google team is doing is providing a way to trickle in the new stuff as you go.  You can use 2.x controllers, components/directives, etc... against your existing 1.x stuff (and the other way) and just convert as time allows.  So those that are invested in Angular 1.x or rely on external dependencies don't have to start completely over to adopt 2.x.  I think goolge employs some pretty smart people, and if that is what they've banked on to bridge the gap I think it's worth considering for cfml in lucee.

I personally don't care if there is a new extension, or if it's named .lsd or .imnotnoreverwascoldfusionsodontevengoogleit_plz.  If you're doing it right your dev team will be the only ones that have to look at it.  To me the important part is that both cfml and lucee-script (because lucee should NOT have it's own markup) should be able to coexist on the same server and in the same context.  Why not support all the lucee goodies in a cfc with "use strict" or whatnot (as others have suggested) *and* in a new extension if someone wants to use it without the "use strict"?  Shouldn't be that hard, right?

To echo others that have said it already (and to repeat myself), we really need some sort of roadmap.  Without it we're just driving, wasting fuel, getting nowhere.

[Dominic Watson]

Re the 'distancing from CFML' and 'CFML + a half'. A conversation was had in which the following paraphrased position was raised, and I think it is a good one:

> Lucee should be a safe home for ColdFusion developers to come to if and when Adobe pull the plug on ColdFusion. This should never change. It should also be a place for those who want to see the language move on without the restriction of Adobe's failings to listen to its community.

While I'm hesitant about it, the new 'dialect' could well be a key to that position (though other options may well exist such as backward compatibility extensions).

I'd rather the new dialect start out *solidly* but not overly ambitiously. Once it has proved its viability, begin to raise the bar with ambition. I, like Ryan, would definitely not want to see a radical new language. The competition is simply too stiff.

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/2ab29c20-929d-42e8-a640-8cef9ae61db8%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Michael Offner]

When I have started Railo I disagreed with a lot of behaviour in the ACF implementation.

Some of them, we simply handled differently like for example "pass array by value" or we did a setting in the administrator, like for example for "scope cascading".

But doing a setting like this in the admin, means to break compatibility for the whole web context/server, what is simply not possible for most users, because the relay on frameworks/applications that are ACF compatible and because of that setting like this are not well adapted.

In a second step we introduced a lot of the admin settings in the Application.cfc, so you can have this settings independent of what is defined in the administrator, but the problem with breaking 3 party frameworks/application remains.

Some of the settings are also available on code level, for example "local scope mode", you can define the default behaviour in the admin, in the application.cfc and in the function itself.

But doing this in the function also produce an unnecessary "noise" in the function!

Let me take the "local scope mode" setting as an example, I personally like this setting a lot, in my opinion this makes scope act as they should do.

When I do testcases I cannot set this in my admin or my application.cfc because it would break Testbox, so the only option for me is to set it inside the function itself, what I do sometimes, but many times I simply add a "local." to my functions ... .

Same with full null support enable, I love this feature but I never have used it yet, because I can only do in the admin and it always breaks existing code.

So in my personal opinion all this settings Lucee  has are great in theory, but are more or less useless in real life for most people, because you cannot use them without breaking existing code.

That was the reason I was coming with the idea of an extension, this extension allows me to control all this settings simply by using a different extension, so if I do a test case, I would use the .lucee extension and I had no troubles using all this features, even i'm using frameworks like testbox that are realing on a different environment than my template does.

So the idea of this extension is not to do a new language, it is to have a different way to control this existing settings on template level.

so it is all about controlling the runtime and compiler behaviour on template level.

Micha

 

On Tue, Mar 10, 2015 at 1:36 AM, Ryan Guill <ryan...@gmail.com> wrote:

I would like to argue two points.  First that a new extension should not be created, and second, if it is created it should not be called ".lucee".

I have just read through the group and all of the arguments that I could find for a new extension to separate the way code is processed are because of the following needs: deprecation of existing code features and idioms, addition of new features and idioms that would not be backwards compatible, and a way to break away from the stigma of CFML.

Deprecation can happen inside of the existing cfml files without the need for a new extension.  Deprecation of tags, functions or idioms can be handled at the engine level in many ways - the easiest I can see would be a pragma rule in Application.cfc that sets a language level. Something similiar to "use strict" in javascript.  Any CFML engine (such as ACF) that does not implement these pragmas can just ignore it.  Any use of deprecated functionality or idioms can start throwing errors if the pragma is used.  If necessary, the pragmas could have levels of enforcement, for instance to throw a warning into a log file instead of an exception at a certain level.

New features that are not backward compatible could be handled with the same sort of pragma rule. The way var works in a block vs function scoping for instance - at a certain pragma level it can have the new implementation.

Again, a pragma is just one way - using "this." settings is another, or a specific file that would sit alongside Application.cfc. I'm sure there are others we could come up with.

Breaking away from the stigma and baggage of CFML is a valid concern, but I would like to argue that the likelihood of lucee appealing to a wider audience outside of the current CFML community is low.  There are just too many options for other languages on the JVM alone, languages that have been designed from the ground up with a consistent vision and with modern features.  Also, unless the intention for "lucee.next" is to start an entirely new language from scratch, you are still going to be taking at least some of CFML's baggage with you regardless.  Calling it a new name in hopes to trick some newcomer that lucee isn't the CFML they've heard about isn't going to work for very long. IMO the best way to appeal to a broader demographic is to expand the interoperability with other languages - both using those languages inside of CFML and using CFML inside of other languages.  See the work Sean is doing with cfmljure.  Using CFML as a templating language from groovy would have a lot of appeal I believe.  Being able to use JS via Nashorn in lucee would be amazing.  I know there has been some talk about JSR-223 in the past which is a step in the right direction - the ability to use those other languages inside of CFML would be just a nice.

That said, if you find that it is necessary to have a new extension, please reconsider using ".lucee" specifically. Firstly it makes compatible forks and language implementations harder if not impossible.  Consider if this idea had come up a few years ago and ".railo" had been used.  When it was forked and became Lucee we would have been in the same boat that we have been in with the .ra files, only it would be a much worse situation.  I'm sure its hard to consider that Lucee might be forked by the same crew again, but surely it cannot be ruled out completely? The same would also apply to anyone else wanting to come along and fork lucee into a compatible engine.

It also means that Adobe cannot / will not be able to implement the advances made.  No matter what your opinion of Adobe and their handling of the language, they have implemented features initially developed in Railo and there is no reason to believe they wouldn't continue to do so.  And even if you think that Lucee should forge its own path away from ACF, that doesn't mean that we should preclude them from being able to take up these features, and make a compatible engine going forward.  Using ".lucee" means that at best they will implement the same features with a different extension.  This will also make things harder on library authors hoping to support multiple engines, something that is at least possible today.  Using ".lucee" will ultimately lead to a lack of choices for developers. We already have a documentation problem in all engines.  In the past week alone I have used the ACF documentation for lucee code many times. I have used railo documentation in the past for ACF code because of holes they have. Ultimately if you at least consider that the CFML history is not something that we will be able to shake completely, we are a stronger community together than we are individually.  Of course Adobe might not pick up any of the advances made here - but I just don't see any good reason for making it harder for them to do so.

There are other options available if a new extension is necessary.  ".cfs" for cfscript or ".cfn" for CF-next. I'm certain that if necessary there are other - more inclusive - options available. In an ideal world we could get to a broader language specification and the file extension could reflect the version of that language, but of course I don't believe that to happen anytime soon.  

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/a35d3439-828a-48cd-bc9f-3581ecc88187%40googlegroups.com.

[Adam Cameron]

On Wednesday, 11 March 2015 07:34:20 UTC, Micha wrote:

So the idea of this extension is not to do a new language, it is to have a different way to control this existing settings on template level.

so it is all about controlling the runtime and compiler behaviour on template level.

If that is the rationale then I think .lucee is a poor approach to solving the issue at hand. .lucee compared to .cfm implies a far greater departure than just some compiler settings. You should probably be positioning it as .cfm2 or something like that.

Or explore Ryan's pragma solution more, as I think that's perhaps a better fit for what you're trying to achieve.

-- 

Adam

[Michael Offner]

it is not only about compiler settings, most settings are runtime settings!

I forget to say that this would also include a rethinking of all functions and tags ...

Micha

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/f27b38e7-fcba-4b2d-9d92-7d1038e37e11%40googlegroups.com.

[Denard Springle]

The CFML community... dragging developers kicking and screaming into modern development practices since 2003. Emphasis on the kicking and screaming part.

I favor a 'radical new language' from Lucee. Preferably one that allows developers of any other modern language to use it effectively. The idea that there's too much stiff competition to do so I disagree with. If that were the case, there would be no competition at all - we'd all still be writing QWBASIC. :)

I also favor ditching the CFML baggage whilst also being an effective, lightweight and uber fast CFML engine. Direct replacement for and compatibility with ACF should no longer be a primary consideration. Sorry, but breaking changes are how languages evolve, and CFML needs to evolve.

Doing some of the 'use strict' type of stuff may help to lead CFML developers towards the 'radical new language' over time, as having both syntax gives developers the ability to take advantage of new language features while remaining comfortable with their currently acquired CFML knowledge. Learning the differences would be no more difficult than learning new features when they're added to ACF. And, if it is for someone, then they can just use ACF and avoid using Lucee. We shouldn't hold back the language for those that cannot (or will not) move forward with it.

My 2 cents on the matter.

Having added my 2 cents, I'd also like to state that while we can all eagerly express our opinions on the topic - nothing ever gets done when decided by committee. I've seen good projects and ideas go way, way south in the muck and mire of opinion. Any excitement once shared rapidly dissolved by the back and forth disagreement among CFML developers. We're not politicians... we need to work towards a compromise of opinions and support LAS in their efforts to provide us with the rich opportunity to provide input... but we need to be focusing on providing positive input. We need consensus, which will only ever come through compromise. Everyone has valid concerns and opinions - now... where is the middle ground we can all live with?

-- Denny

[Adam Cameron]

07:34:20 UTC, Micha wrote:

so it is all about controlling the runtime and compiler behaviour on template level.

07:53:30 UTC, Micha wrote:

I forget to say that this would also include a rethinking of all functions and tags ...

[exasperation]

I think I'm going to try to ignore all discussions about .lucee until you work out what it's all about, and provide us with a coherent plan/roadmap.

-- 

Adam

[Andrew Penhorwood]

The .lucee extension make more sense then pragma or other options presented in my opinion.  At a glance I can tell that .lucee templates will process differently.  The extension is easy to control, easy to recognize, and gives easy to understand outcomes.

I do agree that we need a roadmap of where the Lucee Association want to take this.

Andrew Penhorwood

[ADK]

Micha,

OK, I am confused. First I thought a new extension was for a new language direction, perhaps altogether new.

Then your statement above seems to indicate that a new ext. would really just be a way to do away with all of the admin flags (i.e. perhaps files with .lucee will all, for example, have full null support, keep struct keys case sensitive, etc.) but otherwise be the same? (I think? Something close to that?)

But then you chimed back in with: "I forget to say that this would also include a rethinking of all functions and tags". But not really any explanation as to what that meant or why it would be needed?

So... yeah... I am totally baffled.

I get that you guys have a ton going on and appreciate the various efforts and that you're trying to do a whole lot in a short time to get off of the ground, but it sure would be nice to understand what the plan is, because as someone who's read EVERY post on this list (and Railo's for that matter) ... every time I think I know what you're all on about, I then get thrown for a loop and find I don't know what's what.

I don't mind weighing in on extensions and language direction, etc. but at this point I feel there really needs to be some more guidance from the Lucee team because it seems to be kind of a free for all. There was talk of a roadmap, etc. a while back... that would certainly be a step in the right direction! Even a roadmap about the roadmap would be welcome!

[Michael Offner]

I was never speaking about a new language, I was always speaking about a dialect on top of the engine.

The current idea is as follows.

We review all possible runtime and compiler settings and we define for every one the default behavior for this dialect, this includes of course also settings new to lucee 5 like "handle unquoted tag attributes as variable|string".

We review the core tag and function library, for example we remove the function "dateFormat" and rename  "lsDateFormat" to "dateFormat". 

The libraries also define the prefix of tags (cf) and if not existing tags are ignored or not. So we can also control this behavior.

All I was taking about is covered by this...

Micha

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/0cde0e0f-e733-4bf9-a411-64efc3595e9e%40googlegroups.com.

[Adam Cameron]

On Friday, 13 March 2015 15:47:32 UTC, Micha wrote:

I was never speaking about a new language, I was always speaking about a dialect on top of the engine.

The current idea is as follows.

We review all possible runtime and compiler settings and we define for every one the default behavior for this dialect, this includes of course also settings new to lucee 5 like "handle unquoted tag attributes as variable|string".

We review the core tag and function library, for example we remove the function "dateFormat" and rename  "lsDateFormat" to "dateFormat". 

The libraries also define the prefix of tags (cf) and if not existing tags are ignored or not. So we can also control this behavior.

All I was taking about is covered by this...

It has to be more ambitious than that, otherwise it's not a good use of your time, IMO.

What pain point is what you describe actually addressing? Is anyone actually clamouring for these compiler/runtime settings to be "hardcoded" via using a different file extension? Is starting a new file extension so as to be able to obsolete/tweak some functionality something you see other languages doing?

It really seems *to me* that this is an exercise in quelling your own annoyance about some of the idiosyncrasies that CFML has acquired over the years. I think you'd just gotta accept that you chose to do your own implementation of somebody else's idiosyncratic language, and just live with the idiosyncrasies like the rest of us do. What you're describing isn't a language "dialect", it's more like doing a spell check.

Well when I think about it now... it's more actually dealing with some of the shortfalls in Railo's approach to things, in that it accumulated all these settings which varied how the compiler and runtime works. Maybe you should just ditch them from Lucee (5) and revert to simply behaving how ColdFusion does, in all these non-conformist areas. I think the gain in cross-compat and coherency would perhaps be a better solution than having a whole new file extension to sort out some dodgy settings.

What you're suggesting will just dilute Lucee's credibility even further (than it has been after forking from Railo, I mean).

Now I could understand if you were taking the lessons we've all learned from CFML's shortfalls and then creating a new language "inspired" by that (and diverging from the bad rep CFML has, etc), but... that's a huge undertaking (language design and marketing), and I think you (both Micha and LAS) would be over-extending yerselves there, and on a very risky project. As others have said... there's no shortage of well-established alternate languages out there already, and something would need to be pretty bloody special indeed to penetrate that space. "greatly improved CFML" won't be that thing.

In conclusion: my opinion is to rethink this whole ".lucee" idea entirely. Then put it to bed.

-- 

Adam

[Chris Blackwell]

On 14 March 2015 at 09:05, Adam Cameron <dac...@gmail.com> wrote:

Is starting a new file extension so as to be able to obsolete/tweak some functionality something you see other languages doing?

this is my main objection to the whole .lucee concept.  Unless you're doing something radically different in language structure, then don't invent a new language.  changes to compiler flags, scoping behaviours etc should be handled by having a clear road map, a deprecation period and then breaking backward compat at some sensible predetermined point, like a major version release.

Other languages seem to have survived breaking backward compat without too much problem, but its seems people are still worried about compat with ACF, or this really wouldn't be an issue.  Its really a case of "shit or get off the pot".  Either LAS feels it has the capability to move CFML forward and evolve the language, or it wants to remain an ACF compatible language.

Which will it be ?

[Adam Cameron]

On Saturday, 14 March 2015 09:18:35 UTC, Chris Blackwell wrote:

 Either LAS feels it has the capability to move CFML forward and evolve the language, or it wants to remain an ACF compatible language.

Which will it be ?

TBH, my opinion of Lucee has circled round back to where my opinion started with Railo when I first encountered it (v3): just copy ColdFusion. Make the app server faster, smaller, etc, make the code compile into better bytecode, but from the CFML perspective... don't diverge at all: follow Adobe's lead.

As bad as some of the decisions Adobe make are, I don't see some of the decisions going into Railo being that much better at times, and given Adobe don't seem prepared to pay attention to how Railo has initiated change (eg: the way the generic tags->script was implemented in CF was completely different to how Railo was already doing it), then I think Railo^h^h^h^h^hLucee is actually doing the community a disservice by attempting to drive the language forward. It just leaves a mess for us CFML developers to have to work around.

I think a lot of the things Railo initiated were very good when taken in isolation, but the reality has so transpired, IMO, that one can't take it in isolation.

-- 

Adam

[Andrew Dixon]

How is it Lucee/Railo fault that Adobe choose to copy but implement it differently? Surely that is a ACF issue and not a Lucee/Railo issue. It is Adobe causing the incompatibility not Lucee/Railo.

At this point I think it is just a matter of Lucee doing its thing and ignoring Adobe entirely. Lucee needs to be Lucee and that's that from my point of view. Micha is trying to find a middle ground with the .lucee extension so that we can bring CF developers along and have somewhere for them to go when (not if) Adobe abandon CF. Lucee cannot be held back by Adobe and their "manager" (not developer) centric view of how the language should develop (cfclient).

Kind regards,

Andrew

about.me
mso - Lucee - Member

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/77e452b4-3258-4719-835c-11c962c61c31%40googlegroups.com.

[Adam Cameron]

I think you need to polish your reading & comprehension skills, Andrew. The only one mentioning "fault" here is you.

If anything, I implied the fault is Adobe's, but I was also observing that "this is the reality that we live in".

Given Lucee knows that Adobe won't follow their lead, then I think it's unhelpful - to the CFML community - for Lucee to persist as if it does lead CFML development. It doesn't. Adobe - for better or for worse - does. Lucee I think needs to be realistic about this.

There was a point at which Railo had possibly enough traction behind it to start leading CFML dev, and perhaps it could sway Adobe: Adobe did copy a few things Railo introduced, after all. However it's clearly not on Adobe's agenda to be helpful to their community, so bearing that reality in mind, I think Lucee kinda needs to not make things worse by pretending it does lead CFML development. I think diversifying CFML only serves to dilute it, not make it stronger.

I also think the fork from Railo to Lucee lost a lot of the traction and credibility that Railo used to have. Perhaps once Lucee re-establishes itself as a working, credible CFML solution, then they can see whether it's viable for them to try to lead again. There's more to this sort of thing than the fact the underlying codebase and dev personnel are the same, I think.

-- 

Adam

[Andrew Dixon]

I think you need to polish your reading & comprehension skills, Andrew

That will be my chronic dyslexia getting in the way!!!

Anyway, you can't lead when you are copying what has already been done by your rival!!! 

Adobe are clearly not developer focused, as you well know, and the Lucee team is. My point is that Lucee just needs to get on and do what it does best and serve the developer community it has. 

Therefore if the community wants ACF compatibility, which it clearly does in some case does, then that is part of what Lucee needs to do, but it also has another set of developers, like myself and my team, that want to be able to use stuff outside of the ACF compatibility realm then Lucee needs to do that as well, hence the suggestion of a two tier approach. 

Most of the arguments here (not from yourself) seem to be about people believing they are going to lose the ACF compatibility and that is entirely not the case. Lucee is going to keep the ACF compatibility but extend out into a new realm with the Lucee "dialect" (CFML++, CFML 1.5, CFML Next, whatever you want to call it). 

At some point down the track the community position might have moved so far away from ACF compatibility that it is not longer worth keeping and at that point then Lucee could choose to remove it, but for now it is going no where, in fact Micha did a "fix" this week for an ACF compatibility bug (see "requesttimeout="0" throws exception on Lucee 4.5.1.000" post).

If the decision was taken by LAS to only follow Adobe's "lead" then I for one would be, as they say on Dragon's Den, "out".

Kind regards,

Andrew

about.me
mso - Lucee - Member

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/f75a03d9-8a8a-43b4-8db6-160e51a68ad6%40googlegroups.com.

[Jeroen Knoef]

I'd like to introduce a slightly different angle in this discussion, which is the observation that CFML is first and foremost a framework. This is the framework that accepts the request, passes control to CFML code (with or without Application.cfc) and makes available the different scopes. All CFML code is tightly coupled with this framework, it cannot live outside it, which makes this framework actually more important than the CFML language itself.

Thinking about this, isn't it strange that nothing has really changed in the CFML framework since its inception? I mean, we've had application.cfm, request.cfm, etc. since which version? Maybe since before the millennium even. The progress and insights outside of CFML, mainly MVC, have lead to many frameworks built with CFML, but you could hold the view (maybe I do) that this was, in hindsight, actually patching up the CFML framework. Maybe the CFML framework itself should have adapted, like the .NET framework incorporated MVC at some point. Additionally, things like websockets and REST are not first citizen but more or less glued on afterwards. The CFML framework is aging, to the point of outliving itself.

This might be an opportunity for Lucee: change the framework. Take the Play framework for example (https://www.playframework.com/). What if Lucee was built on top of that instead of JSP? This may be a bridge too far for the moment, but I see some big advantages:

• We get all the new stuff, battle tested and all. Some things are solved in new ways, like concurrency. 
• Lucee has/is an MVC framework from the ground up, which is a good thing for everybody, including developers that are looking to switch. 
• And, last but not least, Lucee can position itself as independent of Adobe and ColdFusion, while still being true to CFML.
  

There would be no need to change the CFML language (yet), but it would be a new direction. A nice compromise between some of the standpoints voiced here.

This whole thing would be a daunting task, certainly. A migration path would be necessary, etc. As I said, probably a bridge too far right now. But looking at the state of the CFML framework, I can't deny the feeling that it's holding CFML back. Maybe a drastic move like this is needed.

Thanks for reading this far.

Jeroen

[Adam Chapman]

@jeroen What a fascinating idea. I'm impressed by the Play framework,imagine that Play for Java, Scala and Lucee.

I'll be looking forward to hearing responses on this topic.

Adam (not THAT Adam) Chapman ;)