I will be attending on Friday but I just thought I'd mention a few things before Friday.

It is all very well being APL centric but the world has many more non APL developers than APL developers by a massive margin so things like GUIs can move and change very fast. We should consider what APL does best and use APL and then rather than rewriting the wheel we should try and use non APL stuff for what it doesn't do as well without a lot of effort on the part of the interpreter builders.

Historically we have used non APL GUI systems through Shared variables GDDM (126) TSO forms (I forget but around 100), plus others. The only major "APL" ones written are []WI from APL2000 - a thin cover on the VB GUI and the []WC one from Dyalog.
All of these systems (including the GDDM and TSO components) consume a lot of resource from their respective companies to maintain and to keep them current with whats already out there in the big wide world.

I think we probably have 3 choices -
1) continue to use increasingly legacy looking GUI systems, ([]WC/[]WI)
2) tie up the limited resources of the interpreter writers on non APL stuff so they can cover the GUI and waiting patiently until they can catch up with each innovation to the detriment of real APL interpreter work
3) Invest time in learning new technology, requesting some APL features where we really can't get the non APL solution to work

I have chosen 3)because I want to use, multiple platforms using native GUI as much as possible, since I think it looks better. I want to write applications that people see and don't immediately think they are old before they try them. First impressions count, more so these days than when I started out. We may decry that but it doesn't change the truth of the statement. I want new features like Rank and Key and trains and ... and of course performance in preference to enhanced []WC. But that is a personal choice, others have to make their own choices.

Dick asks about wanting to do it all in APL or should we use Xaml and Data Binding. It comes down to whether you want to be fixed to one platform or whether you want to be flexible and future proof yourself as much as you can.

Data Binding doesn't only do "clever" things but it also separates your logic from your GUI - HTML5/JavaScript in MiServer should support Data Binding soon (The HTML5/JavaScript bit does already) so you could have one APL system driving several GUIs using Data Binding.

Xaml is now supported on IOS and Android by a company called Xamarin - so code and data binding written using this mechanism becomes more portable and we are now waiting for an Android or IOS APL interpreters or possibly a way to utilize the output from Xamarin on these platforms. I want Dyalog to concentrate on this rather than spending the large amount of time necessary to write GUI apps.

Data Binding helps in testing your application - you can test one side of the data binding (data only) against your application without the vagaries of the actions of a GUI. Then you can test each of the GUIs against known data outputs.

I think the future whether we like it or not is either (or both)
1) Servers providing generic GUIs to HTML5/JavaScript in browsers wherever that browser sits
2) Applications running natively on various platforms served by Xaml to give a native look and feel or HTML5/JavaScript to give a generic look and feel.

Both methods can support Data Binding.

I firmly believe that APL is steering a very good path through all the GUI possibilities and with Data Binding and Xaml it is possible to leave all the doors open for the future. I don't want Dyalog or others to be slowed down in their excellent work because I won't learn a non APL GUI system.

Anyway I've said my tup'pence worth I will listen to the rest of the conversation with interest.