Thank you, Raul. I guess the best way to find out would be to sit down and write a small database application with a GUI using J - similar to the way I hear some people use J to write "one-off" GUI apps.
I'm not trying to achieve maximum efficiency at this point. While one of J's strengths is its efficient batch-oriented array-processing, I think another one of J's strengths is its interpreted nature. I never really could figure out how to manipulate the Windows API to create forms and controls, and there also seems to be a lot of overhead involved in accessing the Windows API in a statically typed language - both in VB and in .NET or Java. Really I'd be satisfied if I could just write some medium-sized standalone database applications using a J process for each front-end client GUI (just on Windows for now, using wd in J602) plus a separate J process on the server for the database back-end. <Stefan Scott Alexander > wrote: > > - Does J's column-oriented approach make it prohibitively inefficient to > > have say several users simultaneously trying to add or edit rows in the > same > > table from separate workstations? > > It might. > > > - Would J be simply inefficient in such a case - or could it also lead to > > actual record contention errors - say problems generating unique ids for > > each rows, or problems trying to simultaneously write multiple records to > > the same table? > > The problem is efficiency, not locking. In essence everything is always > locked. And, if you want efficiency, you should "batch up" user requests > and process as many as you can in one go. > > That said, J is essentially implemented as a single thread in a single > process. If you want concurrency, you need to implement multiple > J programs. > > FYI, > > -- > 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
