Yes we did actually. We also looked at Mathematica and I actually called up Kx Systems. My boss made his money in APL and always ... always ... always express his ideas in APL notation (much to everyone's consternation, hehehehe). Still, at the end of the day he decided to stick with J and put it where it really matters ... at the application server. The best seat in the house, between the web server and the database server. ;)
Hmmm. Around three to four years ago, just before the release of J601 ... we started the redesign of our supply-chain integration systems and we started moving modules out of the application server into the client machines. This also meant that we started moving some J workload into the client machines. You know what, it was way better than have it sitting on the app server: 1. Easier debugging. Can you imagine trying to put a dbstopme'' in the app server and stepping through code then suddenly, another request comes in for the same code. It was a nightmare and I normally had to send an email to everyone asking them not to use the system during a certain time. 2. Computations are done on the client, freeing up more resources from the app server. Taking advantage of the more powerful client machines. 3. Faster response time since the result doesn’t have to come down the internet. Of course there's a downside ... the data has to be brought down but we do that anyway ... teeheee. 4. Smaller deployment. Just deploy J.EXE, J.DLL and your IJS file. I normally make a wrapper C# class and put the J scripts in there too. :P Still, that's 3 files. On the server, I normally install the whole J system. With the new xcopy .NET deployment ... it's really easy. Sometimes I wish I can demo our Production Planning systems to you guys. I'm a bit happy with it because it really showed the power of J. Ok, here is how it looked, visualize a Gantt chart where the chart represents a factory. The columns in the chart are the dates (you can zoom in and out from hours to years) and the rows are the production lines. Each production line has a capacity, work schedule, efficiency, learning curves and other properties. Each bar in the Gantt chart represents an operation like cutting, sewing, washing, etc. Each lines has specializations and you can even force a line to do a task not really suited for it but you'll get really bad efficiency. It also incorporates lead time between procurement and a lot variables that makes Industrial Engineers really happy. So why am I so proud of it? Well, the first version was created using VB.Net using GDI+. The problem with this is that when production planners were playing with the chart like drag and dropping the bars (operations) between production lines and dates ... it was taking VB forever to adjust the affected lines. So after version 1, I got dragged in (pun intended) and what we did was gut the business logic from VB and moved them to J. So now, VB will only do the following, (1) get data from SQL server, (2) draw the Gantt chart from the data returned by J and (3) save the data back to SQL server. ALL of the computations were done in J and everything is snappy. Drag a bar somewhere would give an almost instantaneous redraw of the Production Plan (with correct results and predecessors and followers of course). [NOTE: I have to say that I have seen Chris Burke do a very similar thing in pure J with GDI. How cool is that?] For me, what made the system go as fast as it did is the implementation of the in-memory inverted database in J. This concept actually made all the difference. I had to admit though that what I did was a bit clunky. Actually, when Chris and Oleg released JDB, I tried moving my system to it and I did. Unfortunately, there are some dependencies now in the JDB system the stops it from being distributed as a stand-alone IJS file. Other than that, I would have moved my production system to JDB since it's the standard (and by Chris and Oleg ... hehehehe) Yaiks ... I've written too much again ... :-SS -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of bill lam Sent: Friday, May 29, 2009 1:22 PM To: [email protected] Subject: Re: [Jchat] No More APL Did you consider switching to dyalog since your team love dotnet. I'm afraid Jsoftware does not yet show enthusiasm in dotnet. On Wed, 27 May 2009, Alex Rufon wrote: > This has always been how I fixed J objects in my head. Just replace the dot > with two underscores. :P > > It would have been "nice" to get the dots but I'm happy with what is > currently implemented. > > In my day job, were content in letting J do the heavy lifting ... like this > afternoon, the team has been discussing on a clever way of doing vertical MRP > and everyone (including me of course) in the meeting are Microsoft peons. > Suffice to say, when discussing the details, it was understood by everyone > that the actual computation is to be written in J (by me) and everything else > (API, classes, interfaces, GUI, database, etc) were to be written in > C#/vb.net/ASPX/T-SQL/ABAP and the .NET framework. Hahaha. The general design > on the whiteboard actually have a box which says "Compute MRP (J/Alex)" and > everything else is just how to get the data to and from that box. :D > > As I've always said, I'm an Economics grad and my first programming language > is actually COBOL with CICS ... I've only know APL when it was demo'ed to me > for less than 15 minutes in 1998 (I think) and was introduced to J by year > 2000. > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of bill lam > Sent: Wednesday, May 27, 2009 6:19 PM > To: [email protected] > Subject: Re: [Jchat] No More APL > > On Tue, 26 May 2009, Morten Kromberg wrote: > > The "dot" acts in a way which is similar to conventional object > > oriented languages, but whenever (the evaluation of) one of the > > segments returns an array, you essentially get an outer product and > > a nested result which matches the structure of the arrays in the > > dotted expression. Or you can go for a single number: > > > > cities.Sheets[⊂'DK'].Range[⊂'B1'].Value2 5.4 > > cities.Sheets[⊂'DK'].Range[⊂'B1'].Value2←5.5 > > > > ... Retrieve (and set) the cell in B1 in the sheet named 'DK'. > > I guess this is idispatch popularised by visual basic. Similar could > be done in J without using the dot syntax, such as, > > get__cities ('Sheets' ; 'DK') ; ('Range' ; 'B1' ) ; 'Value2' > 5.5 set__cities ('Sheets' ; 'DK') ; ('Range' ; 'B1' ) ; 'Value2' > > however no one yet willing to paid money for it. Cannot drink it. ;-) > > -- > regards, > ==================================================== > GPG key 1024D/4434BAB3 2008-08-24 > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 > 唐詩096 宋之問 題大庾嶺北驛 > 陽月南飛雁 傳聞至此回 我行殊未已 何日復歸來 > 江靜潮初落 林昏瘴不開 明朝望鄉處 應見隴頭梅 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm -- regards, ==================================================== GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 唐詩243 權德輿 玉臺體 昨夜裙帶解 今朝蟢子飛 鉛華不可棄 莫是藁砧歸 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
