For my projects, I usually do a 2 pass review for my j codes. Since my projects usually use C# or VB.NET as the front-end, I usually built the "visible" J verbs first with nothing in them. These public interfaces doesn't change. They are just basically dumb wrapper functions in J which has a corresponding C#/VB.NET class methods/properties.
I would then code for the actual J scripts and I normally just code tacitly if it is convenient ... otherwise it's a normal function. When the system past the prototype stage and all the interfaces/functionalities have been approved, I would do my second pass as the "optimization" stage. One recent example is my code for getting the decimal value of a floating point number. decimal=: monad define y -<. y ) Later on, I replaced this with the one suggested by Ric which goes: decimal=: 1&| After a while, I realized that I have built a large library of generic tacit verbs (most undocumented) which is used in almost all of my projects. :) -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Henry Rich Sent: Friday, May 15, 2009 9:59 AM To: Programming forum Subject: Re: [Jprogramming] What to say about J to APLers As Tracy suggests, tacit programming is not an either/or thing. When you write excess =: (] - <./) y instead of excess =: y - <./ y you are using tacit programming. Whenever you use verb trains and conjunctions as part of explicit programs, you are using tacit features. There is no reason to go all the way to full tacit programming. I built my very first J application (a system for handling texture maps for flight simulation) entirely using tacit code. It was about 100 lines long. It was magnificent; it worked perfectly; it was absolutely unmaintainable. The problem was that changes to the system required changes to interfaces, and I didn't have a way in tacit code to make that easy. Not to mention that moving functionality from one verb to another was always a huge mental effort. Jose Quintana has made a living writing big tacit systems, but it's not for me. Maybe he could tell us what tools he uses to make it practical. My policy now is, I write tacit code for things that aren't going to change. These are programs with well-defined interfaces that can be used as tools to write other programs. For everything else, I use explicit definition. Learning tacit definition for big projects is a good idea. I don't regret the time I spent on that first project. It's good, not because it makes for good code, but because it makes you a better J programmer. It's a mental discipline that will help you think about programs better. Henry Rich Tracy Harms wrote: > Hi, Graham, > > You wrote: > >> So scripts are an important >> departure from the APL workspace, which APLers should be interested in. > > I agree that this would be a good thing for Devon to have on his agenda. > >> Tacit definition is so intriguing I cannot leave it alone. The trouble is, >> with my background, I would be much more productive if I never used it. But >> I want to become adept at it. I realise there is a world there of concise >> expression that I want to embrace. > > I also find tacit programming very attractive. I suspect you'll not > find that your productivity continues to suffer from using it. > Recently I broke out a verb, frame, to help make it easier to read. > Mind you, this verb is on the clumsy side as J code goes, so I'm not > advising that you emulate my work. Here I just want to note that my > current compositional technique now involves interleaving explicit and > tacit J. The advantages of verb trains are great, and so are the > conveniences of explicit constructions. I find it rewarding to work > flexibly with both in the same definition. If you want to see what > that looks like, it's here: > > http://www.jsoftware.com/jwiki/TracyHarms/BowlingScore > > Henry's (all tacit) alternative is also there. (It's much nicer.) > > I'm convinced that at the high end of skill both tacit and explicit > forms are readily used, and freely conjoined, according to their > respective strengths. > > It's definitely possible to get a lot of the advantages of tacit by > applying it at a small scale while writing mainly explicit > definitions. > > Tracy > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
