TAG Meeting Agenda January 13th 2016 8pm UTC

language tag
1

The next scheduled TAG Meeting is January 13th 2016 @ 8pm UTC.

Agenda items

2

Lucee Technical Advisory Group (TAG)

Meeting 6

Date/Time: 13th January 2016 @ 20:00 UCT
In Attendance: Brad Wood, Simon Hooker, Dominic Watson, Kai Koenig, Mark Drew, Sean Corfield, Micha Offner, Igal Sapir
Absent: Luis Majano

Summary of votes taken in this meeting
Full details of the discussions surrounding these tickets can be found in the minutes below

  • LDEV-662 Add shorthand to output expression in tags without cfoutput- Approved ( 9 - 0 )
  • LDEV-663 Add Lucee language (dialect) version in SERVER struct- Approved ( 9 - 0 )

Meeting minutes

  • Approve meeting minutes from last meeting
  • Lucee dialect discussion
    • Discussions around LDEV-107 and LDEV-662 resulted in an unplanned discussion about the Lucee dialect
    • Raised from question relating to LDEV-107, are we focusing on just Lucee language or also the CFML layer?
      • Can be taken on a case by case basis.
      • How many incompatibilities do you want to add that are then not backwards-compatible with ACF
      • Original intention was to allow Lucee to be compatible with ACF, but not guaranteeing ACF could run Lucee CFML.
    • If we are not adding to CFML then why does the TAG exist?
    • Do we really want a seperate dialect? Why have 2? The second dialect allows major innovations that may break CFML.
      • Focusing on innovating in Lucee only will reduce competition with Adobe in turn putting less pressure on them to innovate
      • Lucee language can be a distraction from existing development
      • Lucee language could be ruled out if it fails to gain traction, but what happens to new features? Do they get moved into the CFML dialect or do they get abandoned?
      • New language potentially helps to attract new developers
    • Is it our job to put Adobe into a position where they need to innovate?
      • Not a direct objective, but it could be seen as a positive side effect
      • Aim to improve CFML as a language
    • TAG should publish an opinion, albeit probably a mixed one
      • Action Each TAG member to write up a paragraph stating their position to take to the LAS board
    • Incompatibilities could be documented along with reasons for the deviation from ACF
    • Third party libraries may rely on expected defaults, so having the lucee dialect allowed development that doesn’t then affect third party libraries.
      • Adding more settings to toggle incompatible settings not the best way to go about it but a new language not necessarily the solution
    • Many of the TAG moved from ACF to Lucee and now their CFMl will not run on ACF due to reliance on Lucee features, so why not continue adding new features in the same way?
      • Configuration files can be used to configure
      • Third party addons could have configuration files that detail the settings they need comparable to package.json ( node ) / box.json ( forgebox )
      • The situation being addressed is where some code needs ACF-compatible settings but the user prefers some other settings
      • Can a folder have specific settings?
      • Sounds similar to how Application.cfc can operate
    • If the prevailing opinion is that most users are more likely to move to Node or another language, why are we bothering?
  • Review enhancement tickets
    • A selection of existing proposals and enhancements were selected for review during this TAG meeting. Not all selected tickets were able to be discussed within the time allowed.
    • LDEV-662 Add shorthand to output expression in tags without cfoutput
      • Vote taken
        • [ 9 votes ] Add LDEV-662 to backlog
        • [ 0 votes ] Reject LDEV-662
        • 0 abstentions
    • LDEV-663 Add Lucee language (dialect) version in SERVER struct
      • Vote taken
        • [ 9 votes ] Add LDEV-663 to backlog
        • [ 0 votes ] Reject LDEV-663
        • 0 abstentions
  • Date of next meeting 27th January 2016, 20:00 UTC
3

As usual my votes, even though some would say that they’d be obvious given the overall results:

LDEV-662 Add shorthand to output expression in tags without cfoutput - yes
LDEV-663 Add Lucee language (dialect) version in SERVER struct - yes

4

I think it’s pretty clear the whole .lucee thing is not yet fully-realised even conceptually, let alone being at the stage of implementation.

Personally I think you should scrub the idea completely, But at the very least scrub it right back to the drawing board (and out of the v5.0 product) until you work out what it is.

I can understand wanting to innovate based on where CFML has done ground-work, and also to fill in those infuriating gaps that CFML could have done better but simply hasn’t for one reason or another.

But that in itself is not the starting point for a new language. And what’s a “dialect” (as it’s come to be known) in this context? I think the earliest reference to using that word might well have been my own (I stand to be corrected on that), and I wasn’t being kind at the time. It was used in the context of “piss; or get off the pot”. What’s there at the moment isn’t a “dialect” of CFML. It’s just an ill-thought-out mess. Sorry.

What the concept of .lucee is, though, is the starting point for a discussion. And that discussion has not been had (I saw the beginning of it with IRIS, but even that wasn’t framed the right way). There should be no code representing a .lucee implementation yet. This is demonstrated by the half-formed implementation that currently languishes with zero interest in Lucee 5. It also demonstrates that the people making the decisions to start implementing .lucee in the form that it currently is should not be the decision-makers in how it should be implemented.

All that said, I think Lucee development ought to focus on the CFML engine. CFML as defined by Adobe, but implemented in a more rigorous, faster, more expedient fashion. That’s where the strengths of the LAS dev team lie, and where they excel.

5

I’ll quote myself from an (at this stage) non-public discussion on this board:

One of the reasons why I was really excited about the LuceeLang idea was that we finally would be able to abandon the terrible, terrible, terrible concept of all those Admin switches and toggles that switch on and off various compatibility or speed features as the users/developers just wanted for their server. It might not occur to everyone right away how bad those switches are.
…
To me, the out-of-control variety of Admin toggles for language and compiler behaviour is my most-hated thing in Lucee - and was in Railo before, too.

I still stand to that. I think Lucee’s way of dealing with toggles and switches and nobs and this and that is terrible and should not be continued. LuceeLang would have been a great way out of that. There are other ways to improve on that, for sure, but I can’t see LAS moving away from the “we want the product to be configurable as detailed as possible” approach at all. Sure, some administrative configuration is necessary, but I’d be interested to see another modern web platform where server admins can configure themselves mad when it comes to language (compilation) behaviour.

This fits well with the “piss; or get off the pot” context @adam_cameron mentioned above. What does Lucee want to be, if there was no LuceeLang?

And why can’t we then just say:

“Let’s not give a shit about ACF(ML) and truly innovate and move CFML away from compatibility”.

If people want to get the benefits of running Lucee, there then will be a migration cost/project involved on their end, but why trying to stay compatible at all? Just some food for thought.

6

An interesting idea. At its simplest Lucee 4.x could be seen as a version to maintain for CFML compatibility and security fixes, while 5.x could then be taken as a platform to extend into a better CFML as long as there is a clear deprecation → upgrade path ( similar to can be seen with, for example, the Ember update path which involves a lot of fixing up deprecations )

7

Lucee as a language is the only way I see of getting new developers to look at Lucee the server. I currently work for a large CF shop in the corporate space. They decided to start all new development in .NET. As a CF programmer I have the option of learning .Net or finding a new job. This is the 2nd time I have experienced this in the last few years. People are moving away from ColdFusion and the vast majority of ColdFusion developers still don’t know that Lucee exist.

Fighting against the ColdFusion is dead mentality is a waste of time. That ship has sailed.

If you position Lucee as a new language that has the easy of use of CFML without its baggage has a chance of success. Who would signup to be a Pascal programmer but people are programming in Delphi. Lucee the language rids the Lucee platform from the ColdFusion is dead baggage.

Lucee the language should

  • only included the cfscript version of Lucee CFML.

  • should turn on the switches that make sense for the platform

  • allow for new innovation that does not run on the CFML side of things.

I could say more but a decision needs to be made of the future of Lucee the language. I think the idea has a future but it needs a plan and a the backing of the group.

8

If LAS had pushed that hard right from day one, I would agree with you. I think the divide – the distance from CFML – needed to be there from day one. By this point, anyone investigating Lucee is going to trip over CFML on the website and the mailing list and the Slack channels. It’s going to be really obvious that Lucee is not much more than a rebranding of CFML. It’s too late to separate the languages now – we’re almost a year away from the Lucee launch and the Lucee Language is no further forward than it was then, yet the CFML dialect has had all sorts of enhancements and marketing / discussion. The ship has sailed. I think it’s clear that no one’s heart was really in it back then and what I’m seeing elsewhere here from LAS indicates that no one’s heart is in it today either. A missed opportunity.