Matthew Brand wrote:
> What are the benefits of choosing APL over J if you do not know either
> to begin with?
I can only speak for Dyalog APL, which has grown into something which is now
significantly different from the APLs that I suspect many people who moved from
APL to J are or were familiar with. And although I grew up on SHARP APL and
enjoyed Kens first steps in the direction of "Rationalized APL", which later
became J - and am thus comfortable with the roots of J (and have played with it
a bit) - I am not "fluent" in J, and in particular not with writing large
applications in J. So you'll have to take anything I say with a large grain of
salt.
Dyalog APL has a sound (and growing) commercial base - we get about 100
(mostly) professional developers coming to our annual conference and I would
estimate that the value of business where Dyalog APL is the primary technology
in excess of a billion USD a year (I haven't really done that calculation very
carefully, but just looking at the top few customers we quickly arrive at that
order of magnitude). So if you want to get hired as a programmer, there are APL
shops hiring young people to build up development teams and replace the first
generation of APLers who are now retiring.
Roger mentioned some of the things that J implements that APL is without; in
fact many of these are possible extensions to APL and I expect us to implement
some of them in the years to come. But the people who pay us money get to call
SOME of the shots, so (for example) we are likely to implement support for
Decimal Floating-Point (which there is probably not much of a case for in J)
before we do Rationals. And we will probably (but not DEFINITELY) stick to our
current feeling that forks and some of the more advanced compositions are "a
bridge too far" for us ("the language is clever enough already"). I'm sure some
of you will disagree violently with this - so I expect Dyalog and J to continue
to have distinct focus and separate - but overlapping - user communities. I'm
keen that we not only compete - but also co-operate; the idea of what I think
of as "functional infix array-oriented" notations needs lots of people to push
it and the we're only scratching the surface of the potential market at the
moment.
Because we are driven by "professional" users (9 of our 10 largest customers
are companies that develop and market software which embeds APL but often
involves many other software components), a huge part of the work that we do
goes into interfacing (but the core development team has recently grown from 4
to 9 people, so we are now able to do significant language work on both fronts
at the same time). Dyalog APL has rich GUI support allowing the use of all
Win32 widgets (and uses MainWin or WINE to deliver this under Linux and
Unixes). In addition to the Dyalog GUI objects, you can embed any ActiveX and
(from the next release which is now in "alpha" test) .NET components directly
in your native Dyalog GUI. The commercial users have also driven us to
implement support for secure sockets, a web service framework, and tight
integration with .NET so you can "trivially" turn your APL function into an OLE
Server, .NET assembly, WCF component, Web Service, etc. And soon maybe an
ODBC/JDBC/ADO/ADO.NET Data Source.
All the interfacing work, in particular that related to Microsoft.Net, has
driven us towards support for Object Oriented programming in APL. You can now
write "Classes" in APL using an object model inspired by C#, and expose them as
.NET assemblies. This has not just been done using "more quad-functions": The
core notation itself has gained significant power, as it evolved to support
(nested) arrays of objects. For Example:
XL←⎕NEW 'OleClient' (⊂'ClassName' 'Excel.Application')
cities←XL.Workbooks.Open ⊂'c:\temp\cities.xls'
cities.(⌷Sheets).UsedRange.(1 2↑Value2)
Germany 82.4 Denmark 5.4 United Kingdom 60.2
(Extracts the first 2 elements from each sheet in the workbook, giving a
3-element vector each containing a 1x2 matrix, which in this case happens to
contain the name of the country and the total population in millions).
The "dot" acts in a way which is similar to conventional object oriented
languages, but whenever (the evaluation of) one of the segments returns an
array, you essentially get an outer product and a nested result which matches
the structure of the arrays in the dotted expression. Or you can go for a
single number:
cities.Sheets[⊂'DK'].Range[⊂'B1'].Value2
5.4
cities.Sheets[⊂'DK'].Range[⊂'B1'].Value2←5.5
... Retrieve (and set) the cell in B1 in the sheet named 'DK'.
It is true that APL does have some inconsistencies that J was designed to
correct - but some would argue that it is SOME of these inconsistencies that
makes APL a bit easier to get started on. Tacit definitions, fork and other
compositions in particular make J more "powerful". For functional expressions
of mathematical solutions, J definitely packs more punch (but as an APL vendor,
we don't get a lot of people complaining that the language is not sufficiently
POWERFUL - that is not where the shoes are too small :-)).
Dyalog APL does have a functional extension that brings SOME (but certainly not
ALL) of what tacits give you, which you can read about here if you are
interested:
http://www.dyalog.com/help/html/introduction%20to%20dynamic%20functions.htm
These are the "dfns and dops" that Roger will mention as part of his talk at
BAPLA'09, see http://www.bapla09.com/conferenceProgram.html.
Our goal at Dyalog is to gradually introduce some of the most important
features that have made J cleaner (the Rank operator being the prime example -
and one which actually made it into SHARP APL before J saw the light of day),
and hope that the inconsistent equivalents (in this case, the so-called "axis
operator") will fade away over time. In the interim, we arguably get "more
inconsistent" because we have a number of different ways to do things, but
since we have the commercial user base (and like getting paid each month), we
don't have the luxury of starting ALL over again. Even if we write a new APL
system from scratch in order to deliver a "fully managed" interpreter for the
Microsoft.Net platform (which we are ramping up to do), we would need to take
upward compatibility into SOME consideration.
Our goal is to deliver a package which supports Functional, Array- and
Object-oriented programming, integrated in a way which makes it easy to mix and
match paradigms depending on your background, and the kind of problem you are
working on. It also has to be really easy to explain to Software Engineers how
APL components get integrated with their favourite toys (stuff built in Visual
Studio, etc).
I hope this helps a bit, and did not bore too many readers. Possibly, we should
take this discussion "off line" (unless other readers of JChat would like it to
remain here).
Regards,
Morten
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
