On Thu, Mar 19, 2009 at 18:55, Raul Miller <[email protected]> wrote:
> J is weak where the problem definition is bogged down with > lots of complexities, especially where those complexities are > largely irrelevant. > > These kinds of situations hit J from several different directions and > generally none of J's architecture is very helpful in addressing them. > You can wind up with a lot of code micro-managing these features, > and this code bulks up your program and can take considerable > time to execute. That's an interesting response. I'm still getting to grips with J, but my limited experience so far is indeed that J penalises arbitrariness and correspondingly rewards the opposite. As a language for implementing engineering calculations, that is an excellent quality. It exerts pressure towards clean, clear solutions, not only in terms of their expression in coding but also in the underlying conceptualisation of the problem. In languages where arbitrary complexities are not taxed, complexity tends to grow over time. In J, one is encouraged to make changes in a more considered way. This can seem costly (in time). For software that will be around for a while, one can write that off against savings on whole life costs. More importantly though, the resulting calculation will be more robust, dependable and understandable. Of course, to the average engineer, the _code_ may not be that understandable, but that is a different issue. Hamish -- Hamish Harvey Research Associate, School of Civil Engineering and Geosciences, Newcastle University ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
