Dyalog Forums

Agreement!! Surely not. You disappoint me. :-) Let me try again.

To answer your points. Sorry about tone but I think WPF offers so many more possibilities of using APL as we love to use APL but making it look as good and as professional as any other product to the outside world. When I like something I get carried away with enthusiasm. (On reflection I take back the sorry)

Give it time and you will see the wow as you play with it. Ctls and []svo were also a slog until the utilities were written.

There is so much, that at the moment it all appears to be no more than a nasty addon to APL - .Net, ADO.Net, ASP.Net, WPF but call them AP110 (was that the VM AP), AP 111/123/sql one, xxx and AP 126 and nobody would bat an eyebrow.

All dyalog have done (I say all! - I think its remarkable) is to write an interface that behaves like the AP processors did in the past. They havent written WPF, they havent written ADO.Net but what they have done is the same as with APs - they have given us access to these technologies. By keeping the interface up to date - they stay at the leading edge of these technologies along with the Visual C# and others. It is you and I that have to catch up not the language.

This is where Dyalog with its limited resources should work and position itself. Develop and improve the core APL language while providing access to the new technologies that larger companies can produce and refine. They should not be reinventing/maintaining a GUI nor a database system. Perhaps where the data handling is inefficient they can provide an APL friendly access like the ibeams 2010 and 2011 - which I think still needs a row read as well as a row update. (in case Morten is reading)

They should strive to run on all the popular platforms - that is where the APL# development comes in. Anyone wanting to do client work with Web pages (ASP.Net) or WPF type GUI work in a browser has to learn Javascript (spit) or AJAX or similar - even C# wont do it yet. If they get it right then we will end up with a common language spanning all worlds. Linux, Unix, Windows and Browsers - thats no mean feat.

I find a combination of video and book very useful :-)

I think my beef is almost entirely with Nicrosoft - who seem to be throwing ever-more-complicated stuff at us. An unimpressive experience it'll take me a while to shake off was when I reacted to the goadings of someone saying something along the lines of "ODBC is so old-fashioned, you should use something modern like ADO.NET". So I took one of my SQAPL-based applications and re-engineered it with ADO.NET, to find it running about 5-10 times slower (simple database tasks). I get the same sense of turgidity with form-loading via WPF/XAML. I wonder - with my persecution complex - whether Microsoft (and other large corporations) are generating this complexity with the aim of making life difficult for the smaller fry.

Personally I'm looking for small and snappy - something that impressed me about K when I briefly looked at it some years ago. It cut to the core of grabbing data very quickly and presenting it through a stripped-down user interface - no frills, but I could write the code fast and have it run fast. I don't really want my applications to carry a huge burden just so I can put a button onto a form.

I'm also wondering where we ought to stand regarding platforms like smartphones (APL in your pocket) and Apple (which people tell me is growing significantly faster than the Microsoft-centric world).

Just feeling suspicious that in a few years WPF is going to go the way of all of its predecessors, and wary of putting my time into learning how to use it if the world has already moved on.

Thats a personal choice of course.

K and its Gui support a completely different market to APL and its Guis. Thats why they use K and we use APL.
If you want that then use K.

It comes down to what you want to do. If you want fast low level gui then go with K. If you want to use APL and a GUI that will go out of date and your users wont care - stick with APL/W. If you want to keep a modern feel to your interface, add new features like ribbons but still with the slickness of APL behind then learn WPF. The xaml is purely optional and is designed to be compiled (which APL doesnt support) so it is naturally slower with APL. However there are certain things still best done with xaml - but this doesnt have to be stored on file or be static.

As far as I can see - you make your choice and whichever choice you make you try and adapt your utilities so you minimise the work for the transistion to the next generaration in case you were wrong. AP126 was superceded by the DOS graphics which were superceded by Win32, then WinForms and now WPF. I agree WinForms was a digression and probably not worth learning but that was the transition. Things you learnt with WinForms are still applicable to WPF so arent completely useless. Things always move forward, things are never static. You can stick with your black and white tv, move to colour, HD or now to 3D I gather. No one is forcing you unless your users (or you) like and want the new gadgetry.

If your application is sitting alongside other Windows products on the same desktop - in my opinion its between saying use this interface which is different so it will take you extra time to learn how to use it and you will make more mistakes because you are used to the other tools you have but it calculates quicker or here is a fast application with a front end just like all the others you use so you can be comfortable with it from the start.

There are many new ideas introduced with WPF. The rendering concept is completely different - it allows any control to contain any other control which introduces freedom into the design, almost recursion.:-) The grid layout with its spanned columns and rows etc allows for automatic resizing and positioning, you could build a screen by recursing an APL nested array - allowing the grid to calculate the positions of each control based on their depth and arrangement. It feels a more APL approach - a more general approach than the Guis before it.

I'm afraid you have to learn these things before you are in a position to either accept or reject them. Unlike ADO.Net perhaps I certainly think WPF is well worth the learning. You can always return to APL/W if you dont like it.