Raul wrote: > Recognizing TCO -- this winds up being symbolic manipulation > of the code, and generally winds up with some obscure corner > cases which most people tolerate and other people get frustrated > with.
Yes, there are those who want performance predictable, even if that means predictably slow. Of course, J doesn't adopt this philosophy, as evidenced by its special code support [1]. This has its drawbacks; as you noted, special code is responsible for a number of bugs, and also sometimes results in the dilemma where one has to choose between the clearest expression of a verb, and one that takes advantage of special code. But personally, I'm glad to have that choice. -Dan PS: I had a professor once who built a time share system. The system could allocate more or fewer cycles to a given user. Of course, as more users signed on, the system would assign fewer cycles to each of them, but there was some minimum it wouldn't go below (I think this worked by refusing the next login, not sure). Anyway, if you signed in on a day or a time when no one else was using the system, lucky you! Your job finished in no time at all. My professor thought this was a wonder feature. But immediately he started getting complaints about it. People didn't know *when* their job would finish! They didn't know when they could schedule lunch or go out for beers. So the time share system was altered to always assume the worst case and assign everyone the minimum number of cycles, no matter what. And they stopped getting complaints. [1] Special code supported by J: http://www.jsoftware.com/help/dictionary/special.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
