Alex, I feel your pain as well. This is one of the main reasons I was interested in your C# code for calling J. I studied it and produced a new strongly typed class that I use to embed J in C#. There are a number of really useful J programs running on my employers servers that are doing their job but are masked by a C# facade. Everyone seems happy with this arrangement.
Replacing J by pure C# is work. I am currently doing this for my Picture Database Manager. This is a system I use to slosh around tens of thousands of image files between three databases. The guts are all J and the facade is C#. I am slowly replacing the J code with C# mostly as a LINQ and WPF programming exercise. J and C# make a nice pair. You cannot use J methods very effectively in C# or C# in J. You have to solve the problem twice and the two viewpoints lead to a deeper grasp of underlying issues. Cheers On Wed, May 5, 2010 at 5:24 AM, Alex Rufon <[email protected]>wrote: > Thanks Raul (and to everyone else who replied). > > You're comment on socks color actually made my day. > > I guess I mishandled the situation a bit and overreacted on some arguments. > The code works, It's basically a scheduled tasks that reads files from a > directory, convert it to another format and save the new format in another > directory and delete the original file. I was a bit pissed since my wife > spent some time on the task ... > > I believe they are planning on re-coding again in C#. (Incidentally, I can > code in any of the programming languages here in the office but not in ABAP > ... the SAP scripting language). > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Raul Miller > Sent: Wednesday, May 05, 2010 4:55 PM > To: Chat forum > Subject: Re: [Jchat] Hurdles implementing J apps > > Of course you could use a C# wrapper instead of > a VB wrapper, then the application would be in C#. > > But that is just silly, and the important thing to do > here is to focus on: > > [1] Business Requirements (what really needs to > get done here). > > [2] Education (if this guy is objecting to things which > would still be issues when using DLLs or SQL or > any other such thing it is probably because he does > not know how to do his job). > > [3] Politics (basically, making sure that you stay > friends with the people responsible so that when > additional issues come up you are aware of them). > > If there is a need for C# interfaces to your code, you > need to understand those requirements and design > and implement appropriate interfaces. But that > work would be needed even if you originally > implemented in C#. Good design does not just > "happen" because you choose to code in C#. And, > in fact, if your original code was in C# this might be > even harder (except that you might need to have some > C# expertise to design good interfaces -- though for the > most part I think you can get away with using VB). > > Seriously, though, this kind of thing is like arguing > about the color of your socks. Yes, sometimes it > matters, but it is rarely important for the business. > > -- > Raul > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > -- John D. Baker [email protected] ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
