Link to examples of good and bad interface design
converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 7:||Line 7:|
|Line 50:||Line 50:|
|We touched briefly on the topic of interface design by examining an example of a well-designed interface, that of [Self:NYCJUG/WinDiff: "WinDiff"], contrasted against a poorly-designed one, that of [Self:NYCJUG/FileTouch: "FileTouch"].||We touched briefly on the topic of interface design by examining an example of a well-designed interface, that of [[[NYCJUG/WinDiff]]: "WinDiff"], contrasted against a poorly-designed one, that of [[[NYCJUG/FileTouch]]: "FileTouch"].|
|Line 55:||Line 55:|
"Porter Stemmer", J-like, Tao of J, conditional probability, readability, "Transitive Closure", interface design, algorithm development
Location::Heartland Brewery at 34th and 5th, NYC
Agenda for NYCJUG Meeting of 20080408
1. Beginner's regatta: Porter Stemmer j-ification: learning the Tao of J. 2. Show-and-tell: WSJ Numbers Guy probability quiz. 3. Advanced topics: J readability: what is it and how do we achive it? Examples of nterface design - good (Windiff) and bad (TouchFile) 4. Learning and teaching J: enhancing J wiki, lookups - "transitive closure": what the heck is it and how does it relate to anything practical?
Ken showed us what he's done on the Porter Stemmer and we commented on ways to make his code more J-like.
Some of the general suggestions were:
- 1) Apply functions to lots of data at a time, "even if it [a particular data item] doesn't deserve it". 2) Aim for readability and correctness first, efficiency later but often these will go together.
We discussed some of the questions on the quiz from the Wall Street Journal's "Numbers Guy".
We also talked a little about the article in the Communcations of the ACM: "Disk as the New RAM" (a discussion of which can be found here: http://glinden.blogspot.com/2008/03/talk-on-disk-as-new-ram.html), how this fits in with using multi-core architectures and is suitable for a coarse-grained parallelism that is suitable for J (but must be designed into the code - it's not automatic).
We discussed Fourier transforms and the possibility of using J with MonetDB (http://monetdb.cwi.nl/). MonetDB is a open-source database system for high-performance applications in data mining, OLAP, GIS, XML Query, text and multimedia retrieval.
We also raised the concept of "transitive closure", which has been much talked about on the J Forum recently, and how this relates to the practical problem of "word wrap" or "line breaking". The only example I was able to find on the web where these concepts are explicitly related was in an article on comp.lang.apl by Jim Weigang in one of his Zark APL Puzzler series: http://www.chilton.com/~jimw/wordwrap.html .
I stated my intention of refusing to learn exactly what "transitive closure" means, as a matter of principle.
However, the discussion of this led us to emphasize an important difference between J and many more conventional languages in that many of these other languages are "stream oriented". That is, they are optimized for scalar processing and often only need to track a few data items at a time whereas J often works better when we can see the entire array at once. This led to some questions about whether the finite automaton adverb in J ";:" helped address this short-coming; the consensus was that parsing-type problems are often not as well suited for an array language like J as they are for more stream-oriented languages like C and its brethren.
We touched briefly on the topic of interface design by examining an example of a well-designed interface, that of [NYCJUG/WinDiff: "WinDiff"], contrasted against a poorly-designed one, that of [NYCJUG/FileTouch: "FileTouch"].
Learning and teaching J
Scan of Meeting Notes