Dyalog Forums

I am becoming more than a little frustrated with this .NET stuff and I wonder whether we need to find a way to focus our energies. Much as I admire the abilities of the folks who are providing answers to ad-hoc questions, I don't think this is the long-term answer.

Bit of personal background - I started with APL may years ago because I found that the computing tools I was using were getting in the way of formulating the solutions I wanted (things like making sure that I had Real*8 numbers in Fortran, endless type conversions in PL/1, making memory allocations, putting semicolons on the end of some lines of code and not others - you get the picture). APL was a breath of fresh air because it simplified data down to numbers and characters, put them together into multidimensional arrays, had a simple consistent order-of-execution rule - things only got better when stuff like nested arrays arrived. In short, I could get back to thinking about the real-life situations I was analysing and modelling. APL had an appeal for the non-programmer, somebody could put together a workable solution without having to hire programming "experts".

But now we're seeing things like .NET taking over from what once were subroutine libraries, and WPF for building user interfaces - we don't have many comprehensive guides to how to bolt it all together, and we're often thrown in the direction of documentation written by people who are versed in a world which is alien to us, my favourite incomprehensibility of the month so far - Binding binding = new Binding();.

We - those of us here - are committed. APL is what we do.

I don't think we are likely to see many "professional software developers" beating paths to our doors any time soon.

But lets put ourselves in the shoes of the economist/statistician/engineer who has a pile of data and an idea - wants to write some code to either solve the problems or make something to sell as a packaged solution. Could use APL - it's good for making sense of large volumes of data, but the inbuilts are a bit restricting. So, how to make use of all the other stuff that's on most computers these days (presumably having purple ellipsoidal buttons makes software more attractive)? It's still laborious to "create solutions" in VB, but there's a whole raft of infrastructure - it's written all in the same lingo, so everything fits together. If our hero wants to write APL he (or she) is going to have to translate all of this stuff - it's doubly laborious.

Now I'm sure that (given time) this stuff will get tamed (but by then there's going to be a whole new raft of other stuff). But I don't think we're going to tame it with one-off questions and answers. People like Bjorn Helgason on comp.lang.apl are reminding us that APL needs books, tutorials, libraries, everything.

Exhortation is one thing, doing is another. We all have our own goals and limitations. I don't think it's either fair or reasonable to expect that all of the answers are going to come from the vendors. Is the forum (and the APL Wiki enough), or do we need to create ourselves some specific projects to put the tools people need (and have come to expect in other specialities) in place?

Rant over.

I can relate to Dick easily, and I am happy that the vendors give us access to .Net but we need something more after that. What more ? I think for the vendors they are waiting to see for what we use .Net and after that they can react to our needs, for the APL programmers we have to share the tools that we develop and when we find a good piece of information on .Net share it also within the community (and find what we like in .Net also).

Personnally I could use a 'repository' of .Net information for APLers maintained by the APLers, I suppose the Wiki is the place for that. I could use a page by WPF controls (button, dataGrid, etc) that show the link of good articles on the subject and also some code.

Eric Lescasse has given some courses on using Visual Studio with Windows Form during the last APL2000 conference with a great success http://www.lescasse.com . He prepared is own teaching material. This looked like a good idea to me except that he was teaching Windows Form instead of WPF (I must say that jumping right to WPF when you have no knownledge of .Net is a little bit too hard).

Pierre Gilbert

PGilbert wrote:I think for the vendors they are waiting to see for what we use .Net and after that they can react to our needs.

This is exactly right. We have been removing "glitches" and adding features to work around the discontinuities where the APL and .NET paradigms "collide". I am sure there are a few left - no doubt WPF will uncover some more as you start playing with it in larger numbers.

Unfortunately Dyalog is not currently able to provide a huge amount of guidance, as we are not in the business of writing applications. It *is* our intention to write a significant quantity of code samples in 2011, which we will post to the increasingly valuable APL Wiki. However, we need the community to step up and share techniques and push us to add the necessary features - if you leave it all to us it will take significantly longer.

We are grateful to Ross, Michael, Kai, Dick and others who are sharing what they have learned and complaining about the things that are still tricky - please keep it up!

Morten|Dyalog wrote:[... deleted ...]

Unfortunately Dyalog is not currently able to provide a huge amount of guidance, as we are not in the business of writing applications.[... deleted ...]

Appreciated, but Dyalog are perhaps closer to the technicalities of how things like .NET operate than those of us who actually are in the business of writing applications (trying to figure out how business works).

Spinoff topic A - Struggling through Nathan's WPF4 book (publishers should chop off the fingers of writers who need to end every sentence with a shriek, in my opinion) and it becomes clear that in the VB/C# world applications are put together with several cooperating files of which an important element is a "resources" file. Would be good to get some pointers about what equivalent structuring should/could be from an APL perspective - data binding seems important, but I can't translate what I'm seeing into APL (maybe that's because I have a lot of other hurdles to clamber over as well - one thing at a time).

Spinoff topic B - I think it's helpful if we all try to leave something concrete behind us. Personally I see forum posts as rather throwaway and don't much care for all piling into Wikis (look at how Wikipedia is ruining the image of APL). I like to write my own stuff in my own place. There are a couple of tutorials (Dyalog Primer http://88.97.16.226/apl/APL/Primer/Contents.html, which is a couple of years old - aim to give a quick taste-and-try tour of Dyalog, and my work-in-progress WPF self-tutorial http://88.97.16.226/apl/APL/Tutorials/WPF/WPF.html). I offer these as seeds to inspire people to write their own - if you don't like them then deal with them like I deal with beetroot (can't change it into chocolate icecream, so I ignore it). I'd like to see dozens, if not hundreds of little APL monographs all over the Web - think it would send out a message that we're thriving.

Paradoxically, the promise of platforms like .Net is that APL vendors are supposed not to need to do much more work because the expertise is all in the public domain, and you can buy books to read about it. Of course, it doesn't quite work that way because of a number of issues, including:

1) APL has different syntax, so you can't use all the C# sample code directly.
2) Glitches in the boundary between APL and .Net: Even when we have a managed code interpreter, there will be oddities in places: .Net just doesn't understand that APL also wants to be able to consider a Boolean to be a "one-bit integer".
3) Few APLers get a big kick out of mastering new libraries, they would rather be dividing numbers into each other.

Some of us will have to forge ahead, build tool layers, and teach others via WiKi articles and other forms of materials posted to the web. I'm happy to be able to announce that Michael Hughes has agreed to help prepare and run a workshop on "Windows Presentation Foundation and APL" at APL2010 in Berlin (we do not yet know the exact day on which it will be presented). The plan will be for everyone who attends to leave the workshop with a working application, and many tips and tricks from a person who has been on extensive expeditions into WPF. A free non-commercial license for Dyalog APL (v12.1, with luck also a “beta” of v13.0) will be available to anyone who needs one in order to follow the workshop. We’ll try to record the session, with luck we’ll also be able to have one of them new-fangled video presentations on WPF+APL (and if things work out, try to turn the material into a “booklet” after the workshop)

We would be happy to receive suggestions for topics / areas of confusion / that you would like to see the workshop cover. Please post suggestions to this forum or write privately to Michael. If you have code that you would like to present at the workshop, we're interested to hear about that too.

I appreciate this Forum for the opportunity to share our .Net experiences with Dyalog and get an insight to Dyalog's direction.

Dyalog deserves strong credit for the current level of .Net interface
in spite of difficulties cited by Morten arising from 1) syntax differences with C# and 2) boundary glitches.

.Net objects corresponding to APL scalars for numbers and text come to APL nicely.
.Net objects representing classes and objects are very reasonably accessible and constructed from APL.
.Net collections are also classes and there are some unifying themes of .Net Interfaces for understanding and use.
The Dyalog .Net interface accommodates accessing many .Net collections in a very APL fashion.
You can also stick APL values and APL defined class objects into these .Net collections.
By developing the Dyalog .Net interface to accommodate some of the .Net interface themes for .Net collections,
Dyalog can almost automatically extend APL fashion access to a variety of .Net collections used for databases
and other areas such as LINQ (Language Independent Query.)

Dyalog APL's name space extensions for objects extends to arrays and collections of objects allowing access
of multiple properties and or methods for whole collections or selected subsets.
I tried VisualAPL, wanting to like it for its .Net (C#) affinity,
but found that I missed Dyalog APL name space extensions too much.

Happy to hear that Dyalog is sharing in the WPF quest.
WPF was difficult for me because Microsoft put so much effort into documenting the XAML side and designer oriented tools.
Eventually did some WPF from the programming side in Dyalog APL
and have been intending to learn from forum, etc. how to use XAML.