Thanks Morten that is very helpful. My knowledge of J is not high enough to say whether or not J is deficient in these areas but from your response I take the key plus points in your opinion of APL over J are: 1. APL has a much larger commercial base. 2. APL has much better and more extensive interfacing to popular languages/file types/frameworks.
Incidentally, my reasons for learning J rather than APL (which I have never used) were: 1. The ascii 2. I thought that J was APL2.0 ( i.e. I thought it was an improved version of APL) 3. It is free and easy to install On Tue, May 26, 2009 at 8:52 PM, Morten Kromberg <[email protected]> wrote: > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
