From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: "Douglas A. Gwyn" Message-ID: <3B0E6360.A295B3B@null.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20010524185028.F1E14199D5@mail.cse.psu.edu>, <20010525065834.K21254@cackle.proxima.alt.za> Subject: Re: [9fans] Limbo Tk FAQ? Date: Fri, 25 May 2001 14:16:14 +0000 Topicbox-Message-UUID: a84e046a-eac9-11e9-9e20-41e7f4b1d025 Lucio De Re wrote: > ... I find graphics programming far too tedious. > Is it all a matter of language idioms, then? I've been programming computer graphics since the 1960s. There have been *numerous* attempts to streamline use of graphics, e.g. a plotting subroutine that is given a user function and domain limits and then auto-scales and plots it without further user programming. Unfortunately, such attempts have usually imposed a particular model for how the specific use falls into an overall framework, and the overall frameworks change from time to time, invalidating the model and thus obsoleting the previous generic support ("graphics libraries"). Current commercial GUIs are, first of all, raster oriented, but more significantly, they tend to be "object oriented" in order to provide default characteristics (framework) which can be overridden as necessary in order to support specific application usage. Of course, at the lower levels there has to be some form of support for drawing rectangles, characters, etc. but if there is sufficient intermediate-level support the higher-level code doesn't have to worry about low-level operations. The down side is that if details really matter to you, such interfaces usually make it hard to force the details to come out the way you want; their assumption is that you will accept the default framework (Motif or whatever). Other approaches are feasible; two that I use on my home computer are S-Plus (commercial version of S, which has a freeware implementation called R) and Mathematica. These provide generic frameworks that are fairly easy to use and allow the user to work much more in the application "problem domain" (interactive data analysis or mathematics research, respectively) as opposed to graphics programming per se. If I had more spare time, I'd port R to Plan 9.