A good approach such cases is to apply the criteria described in Iverson's Turing lecture <http://www.jsoftware.com/papers/tot.htm>, Chapter 1, Important Characteristics of Notation. e.g. can you easily prove a Python program correct?
On Sat, Dec 8, 2012 at 1:55 AM, June Kim (김창준) <junea...@gmail.com> wrote: > On Sat, Dec 8, 2012 at 1:35 PM, Don & Cathy Kelly <d...@shaw.ca> wrote: > > > Hey - I am approaching this as an engineer (and ex educator) rather than > > as a professional programmer. I have in the past used a variety of > > languages- first was MAD (1961 at U of Michigan-credit to the Ford > > Foundation which provided generous support) which was a superior Fortran > at > > the time, then various flavours of Fortran, Basic, Pascal (1 program), > C++ > > (got pissed off with it), APL - loved it, and now playing with J. The > > latter two put the problem first, the others put programming style (and > > much of the trivia which the "idiot counting on fingers box" can do > faster > > and better) ahead of the problem. So, using J, you get the problem solves > > while users of these other languages are still defining variables as > > floating, integer, and boolean in cases where the language can decide > > 'close enough'. Of these non J or non APL languages the old Turbo Basic > > was the easiest to use to solve a problem- it had the advantage of > getting > > a compiled program vs interpreted (speed gain over the APL equivalent at > > the time and compiled very quickly with good error checking.However, with > > the problem I had, it took several pages of code (including subroutines > but > > not line number GOTO's )vs an APL equivalent which took less than 1 page > of > > code (most of which was taken up by some unfortunately necessary loop > > control and necessary output formatting). > > > > In going back to a language such as Python- from my first impression- > > you'll may be frustrated by some of the clumsiness inherited from the > past > > non array oriented languages. Look at the power of a simple +/ vs the > > Python, Fortran, Basic, C approach? Try out the 1 o. o.0.1*i.10 > > equivalent in Python without writing a loop. > > > > > Maybe, it's not your main point, but in Python: > > >>> from math import * > >>> [sin(0.1*x*pi) for x in range(10)] > [0.0, 0.3090169943749474, 0.5877852522924731, 0.8090169943749475, > 0.951056516295 > 1535, 1.0, 0.9510565162951535, 0.8090169943749475, 0.5877852522924732, > 0.3090169 > 943749475] > > BTW, +/ in Python is sum : sum([1,10,5,7,9]) or even sum(i*3 for i in > range(10)) > > What is fascinating about Python is it has gradually learned many good > things from other great language, one of which is the list comprehension > used above. > > In addition to that, what Python and many other general dynamic languages > extend themselves is often via libraries. Due to their dynamic nature and > hence its malleability, they don't need to sacrifice the expressibility and > they can contract the expression to a succinct and natural form. (however, > not as succinct as J, as I think) For matrix manipulation, have a look at > numpy. > > > > At the end of this rant- I hope that engineers do not really want a 'one > > way to do it' approach- otherwise engineering becomes strictly by the > book > > which allows no room for innovation or improvement. > > APL and it's heir J give flexibility. I found this from this forum when > I > > had a problem which involved modifying the diagonal of a matrix- > > essentially adding a vector along the diagonal- conceptually it involved > an > > efficient way to get a unit matrix. I asked for help and learned that, in > > this case, J is like Heinz - about 47 ways exist- some good, some not so > > good, but all valid. Dealer's choice. > > > > Don Kelly > > > > P.S. you are a wee bit younger than I am- your taxing problem at age 68 > > is no worse than mine, in learning J, at 81. I do have two advantages in > > that I do have an APL background going back to the IBM 360 and IBM > > typewriters/terminals with an APL character ball and in that I am retired > > and am my own boss (i.e. my wife gives me a lot of slack).. > > > > > > > > > > > > On 07/12/2012 3:53 PM, Graham Parkhouse wrote: > > > >> Thank you for all your responses! My thoughts are: > >> > >> 1. Give up engineering and teach J in math classes in schools. This is > not > >> an opportunity open to me, I'm afraid Linda, for several reasons. I > think > >> I > >> will serve everybody best by focusing on my particular problem and > helping > >> my colleagues to understand the issues. > >> > >> 2. Bo, your advice is straight forward, and refusing to translate it is > >> open > >> to me. The job's been done, it's been used and it works. But there is a > >> reluctance on their part to want me to develop it further. They have > only > >> *suggested* I might translate it into Python. > >> > >> 3. The cost in my time to rewrite in Python would be immense, > educational, > >> taxing on a 68 year old, and could be very frustrating. I think I may > >> begin > >> without being paid just to get a glimpse of the scale of the task and to > >> weigh up Python v. J. If they really wanted it badly, hiring a good > Python > >> programmer to help me, as Raul suggested, would be well worthwhile, and > >> good > >> fun. > >> > >> 4. David and Boyko touch on the conundrum, which is J thinking v. > orthodox > >> (e.g. Python) thinking. My engineering colleagues are not interested in > >> this. They don't see this conundrum. They don't much like programming. > >> They > >> like being successful at engineering. Python looks friendly and J > doesn't. > >> Sure, this is a superficial view, but they are not interested in > >> programming > >> languages or major differences between them. Indeed, they don't believe > >> there are major differences between any of them. > >> > >> 5. So I have a mind to do more or less what Don Kelly suggests. > >> > >> a. Learn Python > >> > >> b. Make myself available for Python programming. None of them are > >> professional Python programmers, so I should be able to hold my own. > >> > >> c. Experience the difference between Python and J software from the > >> vantage point of being an effective programmer of both. > >> > >> d. Give them the benefit of my wisdom. Show them just how easy J is > >> to > >> write. My hope would be that one or two young engineers would get the > >> idea. > >> But, as you can probably tell, I'm being cautious about how well this > will > >> turn out. > >> > >> One final point. Don suggests showing different approaches in J. One of > >> the > >> boasts of Python is 'There should be one-- and preferably only one > >> --obvious > >> way to do it', and many engineers would like life to be like that, so > that > >> they can quickly get on and do it. > >> Regards > >> > >> Graham > >> > >> ------------------------------**------------------------------** > >> ---------- > >> For information about J forums see > http://www.jsoftware.com/**forums.htm<http://www.jsoftware.com/forums.htm> > >> > >> > > > ------------------------------**------------------------------**---------- > > For information about J forums see http://www.jsoftware.com/**forums.htm > <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
