Thank you for this information, Björn. There are several steps needed and first of all break the task into > smaller tasks. > > The first thing to note is that most operations can be done in several > different ways and if you have a problem because one operation is > taking long then you have to look at alternatives. >
This is one thing I like about J: it seems to make it straightforward to break a large task into smaller ones, and there are often many alternative "idioms" which can be used to perform the same task. > > So everyone involved with the project need to adjust to the task at > hand and learn it in steps. > I should clarify that I'm simply studying J by myself now - hoping eventually to find a commercial application where I can use it. > > J can handle a huge number of data so that is not a problem and it can > handle a lot of connections. > This is encouraging to hear. I'd be curious if anyone also has some specific experience with using a J server handling a lot of connections. I don't think I'd plan on using J for a public-facing web-server - but it would be interesting to hear if people have been using any sort of J server in-house, and how it performs when handling multiple connections. I sometimes hear about thread-based versus process-based approaches for handling multiple connections, and I'd be interested in hearing anyone's opinions about how either of these approaches might work with a server written in J. I do not think J will be a problem but the learning curve of the > people involved should be considered. > In this case, I only have my own learning curve to worry about :-) I understand that J has not been very widely adopted, for whatever reasons - but after looking at many languages, I keep coming back to languages like J because they seem to make the process of programming much more enjoyable. I think my life might be rather dreary if I had to work in C++ or Java or even C# or Scala all day long. So I'm considering devoting a good-sized chunk of time to really learning J. I studied K for a few months a while back, so I'm already starting to get a good grasp of concepts like loopless programming and adverbs. And while J might not be as strong as K in terms of raw number-crunching ability, it seems to come close, and J602's ability to include OCX controls gives me hope that J could be used to create decent (if not spectacular) GUIs. I'm hearing from other people on this thread (for example, Alex Rufon) that J might not be very good at transaction-oriented or record-based processing, and I'm still trying to find out whether that's an inherent, insurmountable lack in J, or whether capabilities for concurrent multi-user transaction-oriented / records-based processing and editing could be added to J simply by implementing some of the existing concurrency solutions out there (such as Firebird's multi-version concurrency control, or the more advance and generalized Paxos algorithms). > > Once everyone is up to speed I do not see any problem you should not > be able to do what you want. > Thanks for your helpful encouragement! - Scott ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
