From ... From: Erik Naggum Subject: Re: application architecture for UI (Ex: Re: Is LISP dying?) Date: 1999/07/25 Message-ID: <3141913498252914@naggum.no>#1/1 X-Deja-AN: 505062630 References: <7m8bm7$dni$1@nnrp1.deja.com> <378ca7ff.66785883@asgard> <378e085d.156990400@asgard> <3141319774179171@naggum.no> <3141382367344215@naggum.no> <87u2qzmcp6.fsf@2xtreme.net> <87btd67v8s.fsf@orion.dent.isdn.cs.tu-berlin.de> <7n35dt$b9u$1@spitting-spider.aracnet.com> mail-copies-to: never Organization: Naggum Software; +47 8800 8879; http://www.naggum.no Newsgroups: comp.lang.lisp * joswig@lavielle.com (Rainer Joswig) | Let's cite the abstract from a paper (CACM Vol.34, No. 9 (Sept. 1991), | pp. 58-59 ) presented by Scott McKay: | | McKay presents CLIM, the Common LISP Interface Manager. Using CLIM, | programmers describe the user interface of an application in a | high-level language independent of any particular window substrate. The | programmers indicate their intent, and CLIM hides the details of how | the tasks are performed. CLIM provides a number of basic facilities, | including geometric modeling, affine transformations, text with | multiple fonts, and graphics. It has a presentation facility that | remembers not only the output to a stream, but also the underlying | application object it represents and the presentation type associated | with the output. It also has facilities for input, with a translator | that coerces objects of one presentation type into objects of another | type. Thus, since the objects and commands used in the interface are | built on objects and operations in the application, the user interface | becomes a by-product of the application rather than an artifact of | graphic design. you're missing the point, Rainer. at issue is not the coupling to the actual user interface code, like X windows or whatever. at issue is how much the application code needs to be prepared to produce a by-product. it appears to me that your anger at critics of CLIM is misplaced because you don't understand what they are criticizing and they think they criticize something that isn't wrong with CLIM. maybe this is because you don't see problem other people see and think CLIM has solved a serious problem that other people don't see. I don't know. but I have tried to get you, as an too ardent defender of CLIM, to answer some of my questions and issues, which, in particular, are to which degree CLIM offers means of abstraction that would be useful even without CLIM in the system. again, it appears to me, from what _you_ say, that it doesn't, meaning that CLIM is good provided that you accept a non-trivial amount of design methodology that doesn't work too well without CLIM support. could you calm down and try to answer such questions? I'll make a parallel: we all know that CORBA solves a whole bunch of problems in distributed processing, but if that means we have to buy into the CORBA philosophy first, it may not be possible to use CORBA if the philosophy doesn't fit the application model. in my view, CORBA is good _only_ if you accept that philosophy, and sucks if you don't. to those who don't recognize that there _is_ a "CORBA philosophy", this would be an attack on CORBA in areas where it does work and is valuable, because they automatically express every problem in terms of the philosphy. #:Erik -- suppose we blasted all politicians into space. would the SETI project find even one of them?