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.
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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
