RE: Opinions about the "Oneliners"
- To: mathgroup at smc.vnet.net
- Subject: [mg40349] RE: [mg40315] Opinions about the "Oneliners"
- From: David.Annetts at csiro.au
- Date: Wed, 2 Apr 2003 04:36:54 -0500 (EST)
- Sender: owner-wri-mathgroup at wolfram.com
Hi Olivier, > I don't know whether this topic has been discussed ever since before. > > I like those socalled "Oneliners" to solve this or that > problem. It shows > up, how elegant and effective the Mathematica language can be. Mathematica's language can be very effective in describing a problem. In part, this is due to it's functional nature, so that one can write a whole series of operations as a nested operation. In part, it's effectiveness is also due to a culture that writes functions in such a way that they are self documenting. For example, it is in general much easier to understand something like Fourier[data] than it is to understand fftd(data) which is that case with (say) old Fortran libraries or another system. > But to be honest: Isn't it a torture trying to understand the > "how does it work" of a oneliner written by some else? In my experience, you just strip back the oneliner, and apply it in sequence until you have the completed operation. So, for a oneliner of the form result = f1[f2[f3[data]]], it is often instructive to rewrite this as r2 = f3[data]; r1 = f2[r3]; result = f1[r1]; in order to see what is being done. This is essentially TreeForm, although I have never used this function per se. No matter the language, at some point, you're going to have to do this in order to understand what a bit of code does, especially if that code is useful. > Is it useful to use //TreeForm to visualize the inner structure of a > oneliner (where is the "inner beginning") > > The vast majority of oneliners presented here lack on > comments. Despite of > the wonderful constructs, is this good programming style? I think that is a completely different question -- my good style, can easily be another's unreadable gibberish;) I think it's good style to write code in such a way that it is easy to understand what is going on at a glance. For Mathematica, the style question is complicated by shorthand forms so that f /@ data requires one to remember what the sequence "/@" means (did we really mean /@ or //@ or @@). I'd suggest that writing Map[f, data] leads to greater understanding and code that is easier to maintain. The problem is that shorthand forms are very easy to use, especially with encroaching deadlines. Regards, Dave. ========================================== Dr. David Annetts EM Modelling Analyst CSIRO DEM Tel: +612 9490 5416 North Ryde Fax: +612 9490 5467 Australia David.Annetts at csiro.au ===========================================