A Programming Language
Commentary on Practical Programming in Dyalog APL
Celebrating 10 years of Namespaces, 1994-2004


Friday, October 29, 2004  

NOW THAT NAMESPACES have been around for over 10 years, I thought I'd clean up my workspace a bit, and decided to write a function to locate possible flotsam and jetsam. I wanted to locate every namespace whose display name did not correspond with its []NL name. This would identify essentially any refs, as opposed to "real" namespaces.

I started with Scholes' indispensable dfn refs, I contemplated tweaking it to get back []NL 9 names rather than, or in addition to the refs, but it appeared it would take many hours of study just to understand how it worked!

Here is my solution, using refs, rather than trying to tweak it:

nsflotsam„{©
¸„refs #© Refs
r„¸© ...
d„•¨r© Display Names
c„r.(''½½ŒNL 9)© Count of names in each
r c d„(c¬0)°/¨r c d© ....
an„(†,/r.(‡ŒNL 9))~¨' '© all short names
ar„†,/r.(–¨‡ŒNL 9)© All refs
fn„(c/d),¨'.',¨an© Full Names
(fn»¨•¨ar)šfn,[0.5]ar© Flotsam
}


It seems to take a bit more work than it should. Have I missed a more direct solution?

posted by Paul | 6:53 AM
(2) comments

Friday, May 21, 2004  

MAKING USE OF IDIOM RECOGNITION. Over on the J list, Stephano "Wildheart" Lanzavechia posted an interesting link to a programming problem.

The APL solution to the problem is simply to reshape, transpose, and ravel the data, but it probably won't win awards for time and space.

A similar problem arises when reading data from a RecordSet in ADO. In this case, each item in the above problem is a vector rather than a scalar, and the data is pre-partitioned. With an ADO RecordSet, we read a block of records using the GetRows method. The result is a matrix with one column per record, and one row per field. The usual technique is to read a series of blocks, both for efficiency purposes, and because with ADO, you don't really know how many records are in the RecordSet until you read through them and check for End Of File.

Thus, the end result of reading a RecordSet is a vector of matrices VM, one matrix for each block read. To assemble all of the data and eliminate the blocking (nesting)we can catenate the matrices side-by-side and then convert the resulting single matrix to a vector of vectors, one item per field:

‡†,/VM

This is slow. A faster approach:

†,¨/‡¨VM

If we look a bit a closer, we can make use of two recognized idioms, join:

{,/¾}

and nested vector transpose:

{‡³œ¾}

and write the expression as:

†¨,/¨‡³œ‡¨VM

It's a bit longer, but it's a lot faster!

posted by Paul | 4:37 PM
(0) comments

Wednesday, March 10, 2004  

THE NEXT NY-DAUG meeting will be held Tuesday, March 16th, (this coming Week!) at the Michelangelo Hotel, 51st Street and 7th Avenue.

We are interrupting our regularly scheduled programming to bring you MARKET DAY, an APL special presentation produced and directed by Brooke Allen from Maple Securities. Over the last month, Brooke has been in the process of hiring an entry level APL programmer, and he is bursting with interesting ideas and observations about markets, the hiring process, and APL. A quick overview of the meeting agenda.

2:30 PM Assembly and registration
3:00 PM Topics of interest to APL programmers
4:00 PM Topics of interest to all labor market participants on both sides
5:00 PM Topics of interest to everyone interested in all markets
A market simulation game will be available for play by participants.
6:00 PM Introduction of recently minted APL entry level programmers
6:30 PM Open free-form discussion and mingling
7:30 PM Drawing for a door prize: Dell Axim Wireless PDA/Dyalog APL

Note the 3PM time slot, which corresponds to the regular starting time of NY-DAUG meetings, and will begin topics of most interest to APL programmers. Everyone is of course welcome and encouraged to stay through for rest of the program. For full detailsof the program, send an email to: march16@mapleusa.com for an autoreply.

Hope to see you there.

posted by Paul | 4:52 AM
(1) comments

Monday, March 01, 2004  

NEW VECTOR WEB SITE. Check out the re-designed Vector site. I really like it.

posted by Paul | 5:15 AM
(0) comments

Saturday, January 17, 2004  

STANDING ROOM ONLY at the January NY-DAUG meeting. It helped that we had a much smaller room at the Michelangelo than what we had been using at the Millenium! Over 20 people attended. The presentations went well, if I may say so myself. My paper on namespace programming kicked off a lively discussion, and Steve Mansour's paper on Arithmetic Boundary Checking was really neat. Steve demonstrated a family of very practical dynamic functions and operators that would make a great addition to Scholes' dfns workspace. Finally, Brooke Allen spoke about his company's novel plans for finding (creating actually) an APL programmer. You can find out more about it from Brooke's posting on the Yahoo Dyalog discussion board. We ran out of time and I did not deliver my paper on Splitters, which I will hold over for the next meeting.

I think we will keep our meetings at the Michelangelo. They have a slightly larger room that we can use, and I liked the "boardroom" atmosphere.

Next meeting is scheduled for Tuesday, March 16th.

posted by Paul | 8:30 AM
(0) comments

Wednesday, January 07, 2004  

NEW LOCATION for next weeks NY-DAUG Meeting. We have moved the location of next Tuesday's meeting up a few few blocks to the Michelangelo Hotel, at 51st Street and 7th Avenue.

posted by Paul | 3:46 PM
(0) comments

Monday, December 29, 2003  

TOP 10 ENHANCEMENTS I would like to see. I have added a top 10 list over on the side bar (scroll down). Due to either a lack of imagination on my part, or the possibility that the Dyalog interpreter is now really good, I only have 3 items on it.

posted by Paul | 3:05 PM
(0) comments

Sunday, December 07, 2003  

M. Eric Johnson, director of Tuck's Glassmeyer/McNamee Center for Digital Strategies at the Tuck School of Business, Dartmouth College, on programming in the New York Times,emphasiss added:

It's all about innovation and productivity. As long as we maintain those two engines, we'll continue to have a very high standard of living. Out in the Bay Area there are plenty of folks who would love to create a little bit of protectionism around their I.T. jobs, but we are far better off letting a lot of those jobs go. Low-skill jobs like coding are moving offshore and what's left in their place are more advanced project management jobs.

Hee, hee!

posted by Paul | 2:40 PM
(1) comments

Monday, December 01, 2003  

AS 2004 APPROACHES, it occurs to me that namespaces will soon be 10 years old! Unbelievable!

posted by Paul | 2:21 PM
(0) comments

Thursday, November 27, 2003  

GARY BERGQUIST publishes his final version of the ZARK APL TUTOR NEWS (not online, as far as I can tell), and gives up on APL conferences:

In this, the final issue of the Zark APL Tutor News, I have a confession to make. I no longer enjoy attending APL conferences. Don't get me wrong. I love the subject matter, and I savor the company and conversation with APL enthusiasts. It's fun to talk about APL.

But conferences tend to dwell on the details. I often feel like a botanist admiring the trees and overlooking the forest. With APL, that's a crime. As lovely as the trees may be, the true wonder lies in the forest.


That's too bad, because Bergquist is the best APL speaker I have ever heard. In fact, he's one of the best speakers, period, I've ever heard. I think Bergquist would have enjoyed the Dyalog 2003 Conference this past September, as many of the presentations were entrepreneurial forests, rather than technical trees. Maybe we can get him to attend in 2004.

In the final issue, Berquist goes on to discuss what he calls 1-to-1 problem solving with APL: "It is possible to request a solution from the computer with the same mental energy you need to describe the solution to another human being."

I would one-up him and say that APL gives you the ability to do much better than 1-to-1 in many cases. It is very hard or even impossible for users to even articulate a solution or even the problem. In these cases, the programmer codes at bit, lets the user play around, and then the user is able to articulate a bit more of what he wants. Then you program a bit more, and go back to user, and so on and so on. No specs necessary. Maybe this is XP, but regardless, the productivity of APL is very important to the process.

Bergquist's concept of the importance of working towards 1-to-1 solutions is similar to a conclusion I have come to while examing the process GUI design. As programmers, our primary task is recognizing patterns in our code, and then extracting, abstracting and encapsulating these patterns into functions and objects. This occurs during the natural course of events of programming an industry-specific application. We write code, and then rewrite and re-factor it. The more we do this, the more tools begin to separate themselves from the application code, and the more productive we become. If a programmer is not doing this, he can hardly be said to be programming. This is what separates programmers from a tradesman. A programmer is simultaneous an inventor, architect, engineer and a tradesman. We cannot separate our task as programmers into its component parts without losing the very essence of programming. Increasing productivity depends on the seamless integration of tool building and actual application development.

If you are not constantly working towards 1-to-1 solutions, you are not really programming.

Berquist conludes with:

If you step back from the APL trees and allow yourself to see the forest, you'll realize there is a yellow brick road running through it. The road is glistening with gold and is available to all inhabitants of the APL forest who have the willingness to travel it .

Amen to that.

posted by Paul | 6:37 AM
(0) comments  

THE NY-DAUG BLOG (www.nydaug.blogspot.com) is being retired. It does not make much sense to maintain an entire blog just to note upcoming meetings of the group. And a rarely updated blog is a sad and pathetic thing. I have added a section to this blog (look top right) to keep track of NY-DAUG meetings.

posted by Paul | 6:12 AM
(0) comments

Wednesday, August 20, 2003  

HMM, how about displaying functions as GIF files?




posted by Paul | 8:11 AM
(0) comments

Monday, August 18, 2003  

ONE THING I LIKE ABOUT OOP is that it seems to make documentation easier to write. It doesn't change the way I document a specific function, but it drastically changes the way I document a related set of functions and variables, that is to say, an object or class. Of course "changes" does not really do the difference justice: previously I simply would not document how and why a programmer should use a set of functions.

Once I have organized my functions as an object, then I simply write a short description of the object's purpose, then list its properties, events, and methods, and finally write some notes on how to use it.

For example, here is a find-and-replace object I just wrote:


Purpose
Find and replace text in arbitrarily complex data structures including namespaces and nested arrays, with or without GUI.

Properties
Data, Find, Replace, DeepCopy, Caption, Info, Hits

Events
{none}

Methods
Run, Show, Count

Notes
The Data property is any array or namespace, of arbitrary structure and depth. It is usually set when creating a new FindAndReplace object by providing it as the right argument:

A„FindAndReplace.New NS

The Find property specifies the text to find. The Replace property specifies the replacement text.

The Count method returns the number of replacements that will be made. The Run method performs the actual replacement on the Data property. The Hits property is read-only, and specifies the number the number of replacements made.

If the Data property is a namespace, then the Run method finds and replaces text in each simple character vector in each variable in each namespace under Data, including Data itself. If the Data property is an array, then the Run method finds and replaces text in each simple character vector found in Data.

The DeepCopy property is either 1 or 0, and specifies whether or not a deep copy of the Data property should be made before replacement. DeepCopy defaults to 1, and is only relevant if the Data property is a namespace. If Data is an array, then by definition a deep copy is made.

The Show method displays a modal dialog box for specifying the Find and Replace properties. If OK is pressed, the Run method is executed. If Cancel is pressed, no action is taken. The Caption property specifies the caption of the dialog box, and the Info property specifies arbitrary text on the dialog box.


Now maybe any programming structure at all helps with documentation, or maybe I'm just getting older, but OOP seems to me to make thinking about and writing the documentation a lot easier.



posted by Paul | 5:40 AM
(0) comments

Friday, June 27, 2003  

VARIABLE INHERITANCE. Blogger is driving me crazy. I am getting a different interface on every different machine I use, and now it is annoyed with the APL font. Anyway, there are number of ways to implement inheritance for variables. Here is a way that maintains the ability to directly reference a variable with dot syntax (rather than calling a Get method), using reduction in a way I stole from John Scholes' "up" functon in the dfns namespace. Here is the technique, embedded in the function that creates an new instance of a class:

New„{© Create an instance
s„¸.ŒNS''© Child of base
s.(_Base _Class)„¸© ¸„…¸.This ? s.base „… s.##
s._This„s© Ref to self
s„¸._Inherit s© Or just Inherit (no ¸?)
d„+/ŒSI¹›'New'© Depth
r„{–¯4‡¾}¨²d†ŒXSI© Stack refs (Drop .New)
s„{¸._Init ¾}/r,s© Apply _Init from top down.
s ¸._Create ¾© Apply _Create from Base Class
}


_Init is a function that just initializes variables in its namespace argument.

Basically we run all versions of _Init all the way up the class hierarchy (actually, all the way down the hierarchy - note the reverse of []XSI ), in a cumulative way, building up all the vars from each class, with classes lower down the taking precedence.

posted by Paul | 4:56 PM
(0) comments

Thursday, June 26, 2003  

I've posted another instalment at the project web log.

It includes a link to a function which I've been working on today with my business user, who is neither programmer nor actuary. In the post you will see that she makes the remarkable claim that she finds this (D-fn infested) APL code clearer than the Excel workbook we analysed.

posted by Stephen Taylor | 7:09 PM
(0) comments

Wednesday, June 25, 2003  

OOP AND APL. A good book on OOP for the APL programmer is David A. Taylor's Object Technology, A Managers Guide. It is only 200 short pages, and there is no code in it. With namespaces and refs in your head, the APL code jumps out from between the lines as you read.

Even this simple book, however, can make things a bit more complicated than they are in Dyalog APL. For example:

The ability of different objects to respond to the same message in different ways is called polymorphism, a Greek (and geek) term meaning "many forms". The term can be intimidating, and polymorhism is often considered an advanced concept in object technolgy. But the basic idea couldn't be simpler: Each object can have a unique response to the same message.

For me, the term "message" confuses things a bit. Here is how I think about it. In DAPL we can write:


x.f„{¸}
y.f„{¾}


In other words, different functions (messages, methods) with the same name can reside in different namespaces (objects).

Now, as I write this, I guess the term "message" could be useful: Sending a message to an object = Invoking a functon in a namespace. I think for APLers, 'calling a function" is more natural than "sending a message."



posted by Paul | 8:06 AM
(0) comments

Tuesday, June 24, 2003  

I've been getting some remarkable results in applying and adapting some XP practices to my current APL project.

I'd already noted how I'd been able to adapt XP's pair programming to collapse the analyse - code - test cycle. In essence the customer and I have a conversation. In this conversation, she shows me a calculation example, and I encode it as a test case. She then tells me what the code has to do, and I write the code. We then run the test and use the interpreter to step through and analyse any discrepancies. This dramatically shortens the whole communication, coding and feedback cycle.

I've recently seen that my non-programming customer is reading the code to follow what's going on. Today she correctly challenged whether a particular line of code did what we'd agreed it should. We are communicating through the code, as XP says programmers should do.

In my project web log tonight, I describe some of the coding and working practices that support this. In my next post I'll review the effects on our communication, and on the code quality.

posted by Stephen Taylor | 4:17 PM
(0) comments

Monday, May 26, 2003  

ONE GREAT THING ABOUT dynamic functions is localization by assignment; no more long headers. Traditional functions, though, have a lot of things we don't always want to give up. Here is a dynamic operator that effectively localizes all assignments:

ets„{© execute ¸¸ in temp space
s„ŒNS''© Space
f„¸¸© Function
fn„s.ŒFX ŒCR'f'© Instantiate
¸(s–fn)¾© Execute
}


There is no end to the use of namespaces.

UPDATE: I posted this operator on the dfns list, where Yh Giangi Quario hinted at a better solution and both Phil Last and Ray Cannon independently hit the nail right on the head:

ets„{© execute ¸¸ in temp space
f„¸¸© Function
¸(ŒNS'f').f ¾© Instantiate and execute
}

posted by Paul | 7:44 PM
(0) comments

Thursday, May 15, 2003  

THE BRITISH SCHOOL OF USER INTERFACE. How is it possible that Dyalog APL could arise out of this tradition?

posted by Paul | 10:07 AM
(0) comments

Monday, April 28, 2003  

THE HUNDRED-YEAR LANGUAGE. Over on the J forum, Michael Manti points out an interesting article Succintness is Power on Paul Graham's web site. I had not heard of Graham before. His latest article is The Hundred-Year Language where he notes:

At the other extreme, I think you might be able to design the core language today. In fact, some might argue that it was already mostly designed in 1958.

He apparently is in to Lisp, but is this a reference to APL?

UPDATE: Graham has just posted another great article, Hackers and Painters. I'm adding his site to my blog roll.

posted by Paul | 8:04 AM
(0) comments

Monday, April 21, 2003  

DEPARTMENT OF UNDERSTATEMENT

It's just a flesh wound --- The Black Knight

Programming with threads requires care. --- The Dyalog APL Language Reference.

posted by Paul | 11:12 AM
(0) comments

Sunday, April 13, 2003  

NEW APL USER GROUP. I am attempting to form a New York Dyalog APL User Group

posted by Paul | 2:13 PM
(0) comments

Thursday, April 10, 2003  

TODAY IS THE 20TH ANNIVERSARY OF DYALOG APL. Congratulations to all the folks at Dyadic for the unequaled effort and success at consistency and innovation.

posted by Paul | 4:47 PM
(0) comments

Monday, April 07, 2003  

KILL TWO BIRDS WITH ONE STONE. When creating a Wizard, you can use a Group object to both draw the line at the bottom of the form and act as the container for the child objects on the page. Simply set the position property of the group to (0,0), and with the correct size, the top, left, and right sides disappear off the page:







I vaguely remember the reason to build your own Wizard, and it has something to do with never use a PropertySheet object!

posted by Paul | 7:03 PM
(0) comments  

DYADIC Systems Limited is now Dyalog Limited (as far as APLers are concerned), and the web site is now www.dyalog.com. Adjust your book marks accordingly.

posted by Paul | 6:15 PM
(0) comments

Thursday, March 27, 2003  

"BY RELIEVING THE BRAIN of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and, in effect, increases the mental power of the race."

"It is a profoundly erroneous truism, repeated by all copy books and by eminent people when they are making speeches, that we should cultivate the habit of thinking of what we are doing. The precise opposite is the case. Civilization advances by extending the number of important operations which we can perform without thinking about them."


Alfred North Whitehead (1861-1947)

posted by Paul | 3:32 PM
(0) comments  

WELCOME contributing APL blogger Stephen Taylor from across the pond.









posted by Paul | 2:32 PM
(0) comments

Tuesday, March 25, 2003  

A WIZARD OF WIZARDS. Consider the following problem. Business users need to accomplish various complex tasks. Lets call each complex task a procedure. There will be a lot of procedures for any individual customer installation, and they will need to vary slightly or greatly for other customers. Each procedure can involve a lot of data entry, choices, database operations, etc.

Each procedure may be broken down into an ordered series of unit tasks. Determining what these unit tasks should be requires a good grasp of the overall problem and much trial and error. We want the fewest number of unit tasks that can be combined to create the most procedures and solve the most problems.

We can generalize and say that there are N unit tasks that may be combined in any order and in any number to create an infinite number of procedures. Practically, of course, many units tasks will tend to follow only certain other units tasks.

Each unit task is an object or class, with properties, events, and methods, that is completely independent of all of the other unit tasks. This lets us conduct unit tests on the unit tasks.

The visual representation of the procedure is a wizard, and each page of the wizard represents a unit task. Thus, each class has a GUI associated with it.

Now, as I write this, it occurs to me that the Wizard itself should possibly be an object, and each page should be a child object. I am certainly struggling with the design. Lucking, it is fairly easy to rearrange stuff at the top level, so this can be done later, but not too much later. The really time consuming problem is programming the functionality of the unit tasks, and it is critical some of this gets done now. Complicating matters is the fact that :

1) Back and Next buttons must operate properly, saving states where appropriate. (one []DQ, or multiple []DQ's?)
2) Each page may have settings that depend on user input from preceding pages
3) A wizard must be easily defined by a simple script either by programmers or business analysts (no labels, or explicit branching)
4) We need to allow for different paths through the wizard based on user choices and selections.

One thing is for certain: creating and managing the GUI of the wizard and all of its pages would be inconceivable without FunctionForm. And the whole project would be inconceivable without namespace, refs and dot syntax.

posted by Paul | 11:17 AM
(0) comments

Thursday, March 20, 2003  

A NEW WIKI. I never heard of a Wiki until Adrian Smith posted the link to a new Vector/APL Wiki on the dfns list.

posted by Paul | 2:28 PM
(0) comments  

FUNCTIONS IN UNNAMED SPACES. Say you have instantiated a function foo in an unnamed space. Assume foo calls utility function #.U.goo, and #.U.goo needs to examine how it was called by looking up the state indicator and getting the actual line of code that calls it, using []XSI,[]LC, and []CR. In this case #.U.goo fails because you don’t have a ref to the unnamed space and there is no way to create one. True? This is just one of the hazards of stuffing functions in unnamed spaces, and why I prefer passing unnamed spaces to functions that are in a fixed, permanent space.

Another problem arises with dfns. If the dfn is in the space, we cannot (cleanly) use it to establish or change global variables in the space. If instead we pass the space to the dfn we can do this quite nicely:

{¾.SomeProperty„1}

I must be giving up something by doing it this way, probably some nice oop stuff.

posted by Paul | 2:02 PM
(0) comments

Monday, March 10, 2003  

APL HEADED FOR OBLIVION? When Vector, the premier journal of APL, prints a 14-page article the sole purpose of which appears to be unequivocally declaring APL “headed for oblivion,” it is worth a moment to consider the argument. This should not go unanswered. Until I have the time to pen a more positive response on the bright future of APL, along side K and J, what follows is an off-the-cuff fisking of David Ness’s article. This should not be taken as an attack on J or K, both of which I have deep respect for. (Full disclosure: I have a significant investment in APL and K). Ness’s words are in italics, my comments follow.

In what follows we’ll use J/K when the arguments apply equally to either. Most of the time, and for the purpose of being used as an APL follow-on, either would serve our purpose well.

It never becomes clear what exactly what Mr. Ness’s purpose is. Commercial development? Interactive, ad-hoc programming? Home entertainment?

J/K represent reasonable alternatives to APL. While it is slightly unfair to treat them together, I have found them a productive alternative. And for the purposes of this discussion treating them together simplifies discussion.

It is positively unfair to compare the latest versions of J and K to 20 year old APL interpreters. It greatly simplifies discussion to willfully ignore one-half of the topic.

Since finding J/K I haven’t given much serious thought to the capabilities of current APLs, although I have continued to follow comp.lang.apl, so I am reasonably certain that nothing has happened that would cause me to investigate it seriously again.

It is reasonable to ask, then, why is Ness writing this article? Some of the things that have happened while Mr. Ness has been lurking on comp.lang.apl are namespaces, GUI, multithreading, COM, dynamic functions, IDE, TCP/IP, dot syntax, refs, reference arrays, and .NET. Apparently, not one of these things is of interest to Mr. Ness. Not that there’s anything wrong with that. It’s a big world out there and Mr. Ness cannot be expected to be interested in everything.

However, my work load is quite typical of what a reasonable number of people who do some analysis and write a wide range of reports that often involve some quantification.

His website says he is a retired professor, but let’s grant him this statement. Ness’s work appears to be ad-hoc analysis and report writing. He is clearly not concerned with producing corporate applications or shrink-wrapped software. He is not concerned with producing a product or satisfying customers. Again, nothing inherently wrong with this, but it would be nice if the unsuspecting entrepreneur, googling around the web for an array language to build his business on, was informed of this a little more directly.

Lessons learned from Knuth (and others) and which may be a deeply ingrained part of an MIT undergraduate education, suggest that is usually a good idea to keep a sharp eye out for what the ‘smart guys’ are doing.

This may be true, but it takes a certain amount of pomposity to put it in print. And if all the smart guys are doing J and K, the implication is that the not-so-smart guys are the only ones still doing APL, which I don’t think is true.

APL never seemed, to me at least, to represent the flow of control very comfortably. While I understand that now there may be much better representations for this in modern APLs, I never cared much for right arrows or line numbers…..

A 1975 Mercedes does not have antilock brakes, airbags or cup holders. A 2003 BMW does. Therefore BMW is better than Mercedes. Good argument.

The J ‘normal’ fee is pegged at $100/year. K pricing is generally free for the ‘evaluation’ version, something perfectly adequate for most personal use. … In summary, for my purposes J and K don’t cost anything, and I have been unable to justify (to myself) paying for any upgrades to my (now) ancient APL.

Either Mr. Ness is violating his license agreements, or he uses J and K only for personal study and entertainment, in which case his advise on what programming environment to use should be taken with a mountain of salt. If his “long consulting experience” is relevant, it is hard to see how.

J is a fairly conventional programming language in many normal respects…

Does the J community think this is true?

Both J and K are efficacious.

And APL isn’t?

Even if you go in the bookstore with the largest collection of computer books, you are unlikely to see any books on any of the languages discussed here.

Wrong. If you go to a large bookstore, with absolute certainty you will see no books on J or K, and with some small but positive probability you will see APL2 at a Glance by Ray Polivka. I’m nitpicking here, but Ness deserves it.

J/K has on-line documentation that is far superior, for me at least, to any APL documentation I have ever encountered.

But Ness hasn’t encountered any “on-line” APL documentation because he hasn’t looked at an APL interpreter in ages. Is this an empty array joke?

I far prefer J/K’s documentation to that of any APL I know.

That would be knew, as in the past tense.

There is a whole additional class of other considerations, namely tasks which we wouldn’t have tackled in APL, but which prove to be quite feasible in J/K….K is particularly rich in database functionality.

Wrong. K has no database functionality. You can implement some really rich database functionality in K, which is what Kdb is about. If you understand what an inverted database is, you could probably implement the same functionality in J or APL, but perhaps it would not be as fast.

J and K both allow the easy management of TCP/IP message stacks and make the transmission and reception of messages across the Internet quite an easy thing.

Wrong, to the extent he clearly implies APL does not allow this. Dyalog APL does this as well if not better than K and J, and in fact offers multithreading too, which neither J or K do.

K offers some truly incredible facilities for deploying operating code.

Wrong again. K offers no special facilities for “deploying operating code.”

Huh, that’s it? Database, Net Connection and Deployment (deployment?) are the new problems that J and K are good at solving and APL isn’t? What about GUI, what about Web Services? What about interacting with Microsoft Windows and Office suite? What about PDA’s and cell phones?

I would unhesitatingly point new users towards either J or K rather than APL.

I would suggest that Mr. Ness hesitate just for a moment and consider if the potential user has any interest in GUI, integrating with Microsoft apps, producing a shrink wrapped product or making a living.

I am unclear about whether J and K are truly languages of the future. What I am clear about, however, is that they are both enormously useful and effective languages – well worth the amount of energy that I had to invest in order to use them.

That would make J and K worth just about three weeks, which is the combined time it took Mr. Ness to learn them.

And one of the lessons I have learned from years of experience in this area is that it’s very hard to profit by second guessing the smart guys.

Experience in, exactly, what area? A paid consultant who dabbles in ad-hoc programming and cheats on his license fees? Or a retired academic with absolutely no concern for real-world commercial issues?

posted by Paul | 6:02 AM
(1) comments

Thursday, March 06, 2003  

QUOTELESS NIRVANA. Jim Goff suggests a nifty improvement to the syntax of FunctionForm. For example, to create a button on a form we used to write:


b„f AddButton 'Help' '&Help'


In this case, b is a ref to the button named Help on the form f. This proved awkward because the programmer must come up with two names, the actual name of the button and a localized ref to the button that exists just within the dfn.

We can now write:


Help„f AddButton '&Help'


where the function AddButton has the smarts, by looking up the state indicator, to determine that it should create a button named Help. Thus, the name of the object to be created is now an implicit argument.

It may well be asked why we don't eliminate the left argument altogether and write:

f.Help„AddButton '&Help'


I think there are a couple of reasons for this. First, this method leads to long paths when creating deeply nested objects, while the current method has a very natural way of implementing depth, with a minimum of fuss. More importantly, the form f is a ref, and from within AddButton we cannot look up the stack and determine what it is really is, they same way we look up the stack for the string 'Help' to the left of the assignment arrow. In other words, the parent of the object is always a ref, and this must be passed explicitly to the AddButton function, while the name is just a string, and may be passed explicitly or determined implicitly by hook and crook.

posted by Paul | 5:36 PM
(0) comments

Wednesday, March 05, 2003  

WEB SURFING. Came across an interesting site today called Joel on Software, a blog with many full length articles of interest. Go to the Complete Archives and browse a bit. I really liked Good Software Takes 10 Years, Get Used To It, and there is lots more.

UPDATE: I have been reading 'till my eyes got blurry. Really good stuff here, too many insightful nuggets to quote. I'm adding a permanent link.

posted by Paul | 3:21 PM
(0) comments

Tuesday, March 04, 2003  

DAVID NESS unequivocally declares APL "headed for oblivion" in the latest issue of Vector. It seems it has something to do with how smart Roger Hui and Arthur Whitney are:

And one of the lessons that I have learned from years of experience in this area is that it's very hard to make a profit by second guessing the smart guys.

I have no doubt that Whitney and Hui are two very sharp tacks, but unless Ness is referring to psychic profit, it is hard to see how J and K lead down the road to riches, as opposed to, say, following Bill Gates and Visual Basic. Who's second guessing whom? Maybe the really smart people bought Oracle and Microsoft stock in the 1980's and then retired.

posted by Paul | 5:55 AM
(0) comments  

STEPHEN TAYLOR launches a new blog on APL and Extreme Programming. I've added a permanent link over on the right.

posted by Paul | 5:31 AM
(0) comments
NY-DAUG
Links
Code
Enhancements
Books
Archives