Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!mailrus!umich!umeecs!anon From: anon@zip.eecs.umich.edu (Omar S. Juma) Newsgroups: comp.windows.x Subject: Re: To UIL or not to UIL? Message-ID: <1240@zip.eecs.umich.edu> Date: 19 Jan 90 09:53:11 GMT References: <11658.632634712@hplnpm> Reply-To: anon@eecs.umich.edu (Omar S. Juma) Organization: University of Michigan EECS Dept., Ann Arbor, MI Lines: 121 In article <11658.632634712@hplnpm> mayer%hplnpm@HPLABS.HPL.HP.COM (Niels P. Mayer) writes: [Heavily edited] > > ...rumor... ...UIL... > ...didn't meet HP's quality... > ...poop... > ...UIL SUCKS... ...silly... >...buggy... ...inelegant... > ...doesn't make life... ...easier... >...completely nonstandard... > I absolutely agree. I've only had 4 years of serious software experience, and UIL is the ***worst*** language/compiler combination I have ever seen. Nothing, not even working with punch cards, has left me with a more bitter taste in my mouth. If UIL were a car, not even the Russians would want to manufacture it. If UIL were a--but, wait a minute, let's be objective for a minute: * The UIL compiler does not invoke cpp before it starts its journey. Yo, DEC!!! Even xrdb uses cpp. There are several advantages to using cpp. Hey, guys, ever heard of macros? Huh? What's that you say? You wanted to create your own macro facility? Oh, I see, in the next version. When's that? Huh? Next year? Oh. But what do we do in the meantime? Huh? Did you say "copy and paste"? Isn't that kind of inelegant? I tried that. It bloated the simplest UIL files to thousands of lines. What? Yeah, thousands, not hundreds. Made them difficult to edit. Huh? Split the files, you said? I dunno, that's kind of old-fashioned, rather stupid. Say what? I can run the file through cpp first? Yeah, I tried that, in fact, since I had no intention of wading through huge UIL files; it gave me vertigo. Huh? You want to know how that worked, you say? Well, I ran into this problem, see. After I did a few nice macros and got ready and all, I ran the UIL compiler. I got this strange error message. It told me that maximum line length was 132 characters. Huh? Well, see, some of my macros were rather long, like 140 characters, see, and I couldn't make them less than 132 short of compressing all the whitespace out of the macro and turning it into one huge token. Huh? You never thought anyone would ever write macros bigger than 132 characters? Oh, well, I did. [Quiz of the decade: Where did DEC come up with 132? What, is it 128 and a bit?] * Defective error reporting. What do I mean by defective? Like, it's almost impossible to figure out what the UIL compiler means when it complains about something. Like, if you forget a semicolon someplace, the compiler pukes into its own food, eats it back again, and pukes it out again, and just gets totally ill, dude. * Documentation. Huh? Did someone say documentation? * Language design. Whoever designed UIL must have been heavily involved in BASIC and FORTRAN, because that's as sophisticated as it ever gets. The language is extremely simple-minded. No conditional processing. No interface actions. No anything. All UIL offers is a substitute to writing out almost the exact same stuff in a C program. Yes, I know that writing it in C would be even more time-consuming, but there I have access to powerful macros and procedural mechanisms, not to mention conditional processing, that can make life easier. Any intelligence in the interface must be performed in the program anyway; you can't delegate any actions to the UIL portion, as Niels says. Which brings me to wonder why OSF never gave Open Dialogue any serious consideration (please, don't tell me about "demonstration technology"). If not the entire Open Dialogue system, then at least the language, which was several generations ahead of UIL. My personal impression is that DEC shoved UIL down OSF's throat as its "contribution", though in effect all it's done is cause people to waste inordinate amounts of time and effort creating workarounds. * Scale. You really cannot write a serious application using UIL and its compiler. The mechanism simply cannot handle the sheer volume of text required to describe the interface. You need an intermediate agent, and OSF just didn't think it was necessary to supply one. I would have settled for preinvoking cpp, but even that is not enough. * Elegance. If you try to develop an application using creation callbacks and the other standard mechanisms supplied by OSF, you will end up with a horrendous piece of noodle code on your hands. UIL lends itself very well to kludgy solutions; I tried hard to extricate myself from all this mess, but it was not possible unless I adopted several coding and pre-compilation standards. In essence, I've spent the better part of two months fighting the UIL mechanism, trying to create a logical framework around which I can develop several large applications, and I'm getting close to completely throwing in the towel and starting from scratch with WINTERP. I've looked everywhere, and all I see is square pegs that have been shoved and squeezed into round holes. You can't go very far with such a setup. * Extensibility. Are you kidding me? Extend UIL? I'd rather go gene splicing than try to tack on more crud to UIL. DEC has supplied what can be generously called as an embryonic extension mechanism. It's badly documented, and from what I've seen by wading through the code, they never really thought anyone would want to extend it. Like, dude, there's everything you'll ever need there anyway, so why bother? I'm really sorry to be saying all of this, but UIL is not a solution. Unfortunately, unless OSF is willing to break with tradition and supply a completely different mechanism for the next release of Motif, we are stuck with UIL for quite a while. Which means we will all waste more time and energy coming up with solutions. Here's some alternatives: * Create a wrapper around UIL. Bury it under a ton of macros, processing languages, prepackaged C code. Then it may be possible to develop an interactive interface editor that uses these mechanisms. This is what I'm currently trying to do, but as I said, I'm thinking of giving it up. * Get the format for UID files and develop your own UIL language and compiler. This is fairly time-intensive, but offers the chance to start from zero and build the system correctly. * Use WINTERP. I'm just not sure about this now, but it's starting to make more and more sense. * Use LISP entirely. Don't even bother with C, C++, Pascal, FORTRAN, or anything similar. Start with LISP. Develop everything in LISP. This seems to be the most intuitive alternative, but it requires ***a lot*** of work. And it's not entirely portable, at least not yet. I could go on... anon@eecs.umich.edu ...anon...