wmb@SUN.COM (Mitch Bradley) (12/28/89)
> A standard *program interface* to the windowing system can be devised > just as easily as a standard program interface to, say, files. In *principle* this is true, but in practice it is not even close to true. Window systems are several orders of magnitude more complicated than file systems, and the differences between different window systems are profound, whereas the differences between different file systems are comparatively trivial. You can learn all you need to know about Unix files by reading about 5 pages of documentation. Ditto for DOS files or CP/M files or whatever. The Macintosh window system is documented by HUNDREDS of pages of text; ditto for GEM, etc. The imaging models for various window systems are drastically different (pixel-based vs. spline/stencil/ink, automatic clipping vs. programmer-controlled clipping, different font models, gadget interaction managed by the programmer vs. by the OS, automatic vs. non-automatic mouse cursor clipping, etc). The input distribution models are drastically different. At an even more profound level, the distinction between server-based and client-based window systems affects the way applications are coded. It would be possible to build an abstract interface that would fit on top of any system, but that abstract interface would probably be so big, baroque, and slow that nobody would use it. I designed and implemented my portable file system interface on top of 2 different underlying file systems on 2 different CPUs in a matter of weeks, when I was still a novice Forth programmer. It took me months to produce a satisfactory high level interface to just one window system (GEM), working with a better Forth development environment, and with 5 years of Forth experience under my belt. Some of this high level interface that I developed might be useable on other window systems, but I believe that it would take a whole lot more work in addition, and the portability compromises would probably make the performance suffer. Mitch
peter@ficc.uu.net (Peter da Silva) (12/28/89)
In article <8912280627.AA03786@jade.berkeley.edu> Forth Interest Group International List <FIGI-L%SCFVM.bitnet@jade.berkeley.edu> writes: > In *principle* this is true, but in practice it is not even close to true. That depends on what sort of subset you want to stick with. At the bottom, a simple single terminal-emulator window is easy. The next stage up is multiple terminal-emulator windows. Then you can add menus... they can be implemented by just providing a list of labels and some sort of token to come in on the emulator windows. Then you can add tektronix-style graphics. Then how about gadgets or buttons? I really do think you can go a long way with this model without making anything that'll break on a Mac or under Gem or Microsoft Windows or X or Intuition. > You can learn all you need to know about Unix files by reading about 5 > pages of documentation. Ditto for DOS files or CP/M files or whatever. Well, the Macintosh file system, with its resource forks, are much more complex. And how about VMS or IBM's VM? Then there's the sorts of things that Univac put in OS/8, where a single file name canb represent up to 4 seperate files, depending on how they're opened. FORTH block files are a simplifying assumption in this mess. What sort of simplifying assumptions do you need for windows? > The imaging models for various window systems are > drastically different (pixel-based vs. spline/stencil/ink, automatic > clipping vs. programmer-controlled clipping, different font models, > gadget interaction managed by the programmer vs. by the OS, automatic > vs. non-automatic mouse cursor clipping, etc). Much of that can be hidden by the interface, just as Forth block files hide the differences between CP/M, UNIX, OS/9, DOS, etcetera. You don't WANT to know what files look like on some of the systems I've used. > It would be possible to build an abstract interface that would fit on top > of any system, but that abstract interface would probably be so big, > baroque, and slow that nobody would use it. Perhaps. I suspect not. People still run Nethack in Xterm windows, Amiga console windows, and so on... Start with the easy stuff. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
stever@tree.uucp (Steve Rudek) (01/04/90)
In article <58XB.4KX.ggpc2@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > In article <8912280627.AA03786@jade.berkeley.edu> Forth Interest Group International List <FIGI-L%SCFVM.bitnet@jade.berkeley.edu> writes: ... > > The imaging models for various window systems are > > drastically different (pixel-based vs. spline/stencil/ink, automatic > > clipping vs. programmer-controlled clipping, different font models, > > gadget interaction managed by the programmer vs. by the OS, automatic > > vs. non-automatic mouse cursor clipping, etc). > > Much of that can be hidden by the interface, just as Forth block files hide > the differences between CP/M, UNIX, OS/9, DOS, etcetera. You don't WANT to > know what files look like on some of the systems I've used. > > > It would be possible to build an abstract interface that would fit on top > > of any system, but that abstract interface would probably be so big, > > baroque, and slow that nobody would use it. > > Perhaps. I suspect not. People still run Nethack in Xterm windows, Amiga > console windows, and so on... > > Start with the easy stuff. Yeah, Peter! It would be interesting to see a personality profile of the average Forth programmer as compared to, say, the average C programmer. I wonder if Forth programmers have a greater than average tendency to never get anything completed because they are too caught up in fine tuning the innards for "optimum performance." I got a D in 6th grade woodshop because I fell into that trap. The very first "project" was to square a board using a hand plane and a carpenter's square. I worked diligently on my board but could never get it "perfect". At one point I took my board to the teacher and asked if it was "good enough for an A." He said, "What do you think? Turn it in and find out." Well, it wasn't quite square so I kept at it. When the board was wittled down to 1 inch by 1 inch I asked the teacher for a new board and started over. While other students turned in their "less than perfect" boards and moved on to other projects I kept planing away. I wasn't completely stupid. After a while it became a challenge of me against the damned board and the grade had nothing to do with it. Anyway, getting back to the topic of windows and other "standards", I have a hypothesis that the Forth community's inability to develop any significant standards on such elementary items as strings, floating point, files and windows is because Forth programmers are getting to caught up in "perfectionism." I quoted George Patton in a previous posting in order to try and make the point that EVEN A HALF-ASSED STANDARD IS BETTER THAN NO STANDARD. It would be better to have a less than "optimally flexible" string package than no string package. It would be better to have a slower than optimal floating point package than no floating point package. It would be better to have a text based windowing standard a la "curses" than no windowing standard. Jeepers, folks! Isn't this Forth we're talking about?? So what if the code you get from FIG doesn't address 100% of the windows gizmos you have available under the Macintosh standard interface? Use the package to implement the basics and then design your own words to handle the entensions. So what if the package isn't "optimally fast"? Get it up and running and then rewrite the underlying primatives! You think it's better to design everything COMPLETELY from scratch? Didn't Kernighan and Plaugher say something like "first make it work before you worry about making it better"? -------- I've resolved to become "a kinder, gentler" Forth critic in this new year. -- {pacbell!sactoh0! OR ucdavis!csusac!}tree!stever
marc@noe.UUCP (Marc de Groot) (01/07/90)
In article <1990Jan4.022642.29732@tree.uucp> stever@tree.uucp (Steve Rudek) writes: >It would be interesting to see a personality profile of the average Forth >programmer... Wil Baden, in a speech at one of the national Forth conventions, asserted that many Forth programmers are first-born males. An informal vote (by a show of hands) seemed to bear this out. Any comments? -- Marc de Groot (KG6KF) |"...few people know what to do with a computer. Noe Systems, San Francisco | They decide that running an operating system UUCP: uunet!hoptoad!noe!marc | is a substitute for doing productive work." Internet: marc@kg6kf.AMPR.ORG | -Chuck Moore