🚀 go-pugleaf

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...