A Day At The Beach...

[Dick Bowman]

Apologies that this isn't coming as thick and fast as predicted, but...

Topic E - Is APL "different"?

Looking at applications and development environments we might conclude that there are some aspects where APL is distanced from the IT norm, including...

Applications which are nimble in the sense that requirements change quickly and the code must follow.
Development groups which are smaller, with less specialisation within the group.
Developers more oriented toward the application world than the computing world.
Less "distance" between developers and users.

The question of Topic E is whether these (and others?) are significant and suggest that the tools of the mainstream are not necessarily directly/productively useable in APL development.

[Dick Bowman]

Topic F - Binding, is it Compulsory?

The good thing about Binding (some might say "a" good thing) is that it makes magical things happen - that we can achieve data changes without executing a single line of APL code.

The bad thing - to my simple mind - is that Binding takes away that explicit cause-effect relationship intrinsic to APL and which is so essential when chasing down errors.

The other bad thing is that - especially on the XAML side - the syntax to achieve binding might most kindly be described as rococo-gothic.

The ugly thing about Binding - especially if we want to use Syncfusion's controls is that there's no consistency; some controls work without Binding, others make it compulsory.

So - seeking the simple life, my sense is that we need to use Binding but we're going to have to do something about syntax and terminology. I'm thinking along the lines of hiding it under something (yet to be invented) called "association" (or something like that).

[Dick Bowman]

And, as a finalish warmup and what I hope will be the essence of Friday's discussion...

Topic G - EzWPF

Which I think is something Claus Madsen has already achieved.

Taking the "80% of the gains for 20% of the price" line (although this might understate) the question is whether we can make some tools to hide away a lot of WPF (and .NET) complexity and offer simple ways to build GUI interface/interaction. In some ways this echoes what Dyalog themselves did years ago when the built the APL/W GUI on top of whatever it was on top of. It also has echoes of tools I built myself on top of APL/W Native (mumbled about this at Dyalog 2008).

A few suggestions/outlines/proposals...

No XAML - at least not visible to the "normal" programmer/user.
Hide ⎕USING.
A tree view of the GUI (as shown by XML Notepad 2007) could obviate the need for a visual designer.
Hide the technicalities of Binding, saying nothing more than "this data belongs to this data" and vice-versa.
Probably ought to be a set of Dyalog Class scripts/definitions.
Need to be extensible, so that the base Classes can be adapted for more complex requirements (failing that - a smooth transition to full-fat WPF controls)
Define a starter set of essential controls.
Open source (in APL) so that people can extend without penalty

That's it for now - hopefully Friday will see me taking notes of all incoming reactions and suggestions.

[MikeHughes]

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.

[Phil Last]

Love

rewriting the wheel

I don't think Dick was suggesting to ignore XAML and data binding, just to hide them as much as possible so that people like me can use the hammer without having to fit a different handle on it each time.

[PGilbert]

Personnaly I think that Dyalog should provide a small cover function or example for the main functions of Syncfusion. Speaking from experience, it is not easy all the time to get started with the Syncfusion libraries, but once you know what need to be done its quite easy. I would not mind to share what I have done with Syncfusion so far, one suggestion would be to have a way to share our code with other APLers (have a repository ? forum ? APL Wiki ?).

My preference would be something on the forum, I still have not manage the APLWiki.

[Dick Bowman]

Good to see you paying attention there, Phil.

Pierre - I am working towards the idea of some sort of repository - it's one of the things I'd like to see coming out of Friday's discussions, problem I have with using the forum for that purpose is that I've seen too many examples on other forums where what you "need to know" is obscured by too much historical back-and-forth (with associated red herrings, misunderstandings and so on). Which is why I put up the (now in limbo as I change web hosting and reorganise) apldapldoo.info Syncfusion pages. But I do not want to be "the custodian" or even any sort of gatekeeper.

[PGilbert]

Dick if nobody wants to be custodian, than I would support the idea to have some sort of repository in Dyalog forum but with a sub forum for each of the important controls of Syncfusion. That way the controls information will not be in a endless forum where you can't find anything.

[MikeBa]

I am assuming XBAP is now a dead duck, presumably largely due to security concerns. Without XBAP, WPF/XAML/Syncfusion applications have a smaller potential audience.

Given Microsoft's ambitions for "One Windows", will Dyalog's future deployment of WPF (or other Microsoft presentation tools) allow Dyalog APLers to reach all Windows platforms via the MS Windows App Store?

[Morten|Dyalog]

Dyalog intends to provide mechanisms for building applications that can be distributed via the Android, Microsoft, and perhaps even Apple "App Stores". Android is easiest to comply with and I would expect to see an Android version next up after Mac OSX.

While the equivalent of WPF on WinRT *is* a target, we will probably give priority to provding a mechanism for delivering applications with a UI defined using HTML5/JS using MiServer (or other mechanisms). The advantage of this approach is that it allows a single UI definition to work on all the target platforms (Windows, Linux, Mac OSX, Android, WinRT, iOS as well as actual Web Servers).

WPF allows richer user experiences on the Windows Desktop, and this is where we see the value of WPF/XAML and the related Syncfusion library. After all, this is still where most Dyalog APL applications reside. In the longer term, we do hope to extend the capability to WinRT as well, but it isn't at the top of the to do list.