The biggest "project" I have been involved with is of course the J interpreter. The coding is in C but the ideas and problems are not limited to C or J, I believe. The biggest (and best) design decisions made early on were the following:
- The basic object to be manipulated is the array - Many functions take array argument(s) and return array results - (C specific) When there is an error, a function returns 0 (the 0 pointer) You may think these ideas are obvious, but they were not so obvious in 1989 when the first lines of the J interpreter were written. I have not seen the source code for other APL interpreters but I understand that those written prior to 1989 were not anything like this. You can also see the germs of these ideas in the "Incunabulum" essay (the Arthur Whitney "one page thing"). http://www.jsoftware.com/jwiki/Essays/Incunabulum The Incunabulum code was previously posted to the comp.lang.apl newsgroup: http://groups.google.ca/group/comp.lang.apl/browse_thread/thread/9db5605c96eecc10/18900fc821b49246?lnk=st&q=comp.lang.apl+%22V1(iota)%22&rnum=1#18900fc821b49246 >From the discussion you can see that some of the most important ideas and lessons from the code were completely missed by even expert C programmers. ----- Original Message ----- From: Ewart Shaw <[EMAIL PROTECTED]> Date: Monday, September 11, 2006 5:29 am Subject: [Jprogramming] Developing large projects > Hello again all. > > I've been working away on a (large, complex) software package, > and have a question on programming style. This stems from > a recent post I made to comp.lang.apl about niladic functions: > > > ========== (original query) ========== > > > I used the APL niladic function to generate > >tutorials in several versions of APL. When J > >came out I was planning to do the same, but > >was unable to do so because J does not support > >niladic functions. > > ============ (my response) =========== > > You can write a monadic function fun say that ignores its argument, > and call it in J with > fun'' > > I mainly use niladic functions to return globals, for example > setpc=: 3 : 'PENCOL=: y' NB. usually more complex than this! > getpc=: 3 : 'PENCOL' NB. again may be more complex > NB. e.g. return 0 0 0 if PENCOL undefined > ... > p=. getpc'' NB. pen colour > ... > > As a side-effect of the "idiom" fun'' it's then easy for me > to check when I may be using globals, just by searching for '' . > This technique makes development less error-prone, at least for me > - for example, if (when?) I decide to change PENCOL to be a stack. > > ========== (further response) ========== > > Someone (Markus Triska) then replied saying that > "Passing PENCOL to all functions using it is even less error-prone" > > ========== (end of extracts) ========== > > > My experience has been different from Markus's: I know if a > particular function needs access to PENCOL, but keeping track of > "all functions using it" would be a nightmare, particularly in the > development stage (& I expect the development stage to last forever). > I've also found my approach useful whether or not I'm using J's > object-oriented features. > > Has anyone any comments? How do other people avoid being strangled > by spaghetti code? (I'm talking several hundred k of .ijs scripts) > > Regards, Ewart > > ------------------------------------------------------------------- > --- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
