> I recall seeing, somewhere on this mailing list, Roger > express efficiency of an algorithm as a function of the time it > takes run _and_ the time it takes to code.
You have confused me with Devon McCormick. One of the advantages of APL/J is that even if you are an assembly or C programmer, perhaps especially if you are an assembly or C programmer, it pays to first debug your algorithm in APL/J before coding in the more labor-intensive language. Dick Lathwell, one of the APL\360 implementers, credits this approach as the main reason for the high quality of the APL\360 implementation. ----- Original Message ----- From: [email protected] Date: Monday, October 12, 2009 15:31 Subject: Re: [Jchat] [Jprogramming] Limit limitation To: Chat forum <[email protected]> > There is site that does this. But I believe Rosetta Code is in a > different spirit. Optimizing code for performance is tricky. if > you dig deep enough its _always_ about knowing the way the cpu > works, regardless of what language you start with you will > always have to keep digging into the language the interpreter is > written in or how the compiler works or how the virtual machine > works. A good J programmer could implement an algorithm more > efficiently than a bad assembly programmer. But a good assembly > programmer will _always_ be able to implement the same algorithm > more effeciently than a J programmer. > > But J programmers don't care. It will take us a fraction of the > time to program it and be able to describe the code in high > level human or symbolic language better. And that's where there > is room for evangelism in Rosetta Code. We can say look how easy > this is to express if you are expressing it in the right > language. I recall seeing, somewhere on this mailing list, Roger > express efficiency of an algorithm as a function of the time it > takes run _and_ the time it takes to code. > > http://shootout.alioth.debian.org/ > > I admire the fact that they admit the benchmarks are flawed. For > some algorithms the leaders can change quite often, and it > depends heavily on the cpu. Basically because of what I > mentioned above. > > Optimizing code is a never ending story. Optimizing while also > making it easier to understand is the real trick. > > Sent via BlackBerry by AT&T > > -----Original Message----- > From: Matthew Brand <[email protected]> > Date: Mon, 12 Oct 2009 22:36:58 > To: Chat forum<[email protected]> > Subject: Re: [Jchat] [Jprogramming] Limit limitation > > WRT > evangelism. Would it be worthwhile to show a comparison of the > time to > execute the given C++ (or > Python) algorithm on a selected example and the time to execute > the given > algorithm in J? > > For example, > nth_root takes 300 times as long as %: on my computer. I wonder > how long they > take compared to the Python program? > > It would be good on the Rosetta code site > if there was a table of execution time comparisons for each > language on the > same machine. I would like to see J vs Python vs C++ in particular. > > I could not work out how to time a program in Python though, and > do not know > how accurate the Ts function from load > 'system\packages\misc\jforc.ijs' is. > I.e., I do not know enough about Python or Ts to fairly publish > a time > comparison, but think it would be useful. > > The question is, is J faster than Python when the best J > programmers write J > vs the best Python programmers writing Python? What about C++? > > > > 2009/10/12 Dan Bron <[email protected]> > > > I wrote: > > > To that end, I've created a page on RC to start that > dicussion:> > > http://rosettacode.org/wiki//HouseStyle . > > > > The link should've been > http://rosettacode.org/wiki/J/HouseStyle . > > > > -Dan ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
