joel@DECWRL.DEC.COM (01/23/88)
As the one who gave the X toolkit its object-oriented flavor, I understand and sympathize with the trepidations expressed by S. Chu and K. Kimbrough. Yes, it is all done by convention; no, C doesn't help a bit. As I stated at my talk, I wouldn't choose C as the first choice for any programming task. The lack of type-checking causes me to waste large amounts of time when I actually try to debug my C code, and waste even more time if I have to change a parameter list. (Don't even mention lint, or I start foaming at the mouth.) But there are certain unavoidable facts of life to be considered. I referred to C as "the MacDonalds of programming languages." While I wouldn't want to eat (oops, use) it everyday, it is available in every UNIX installation, those installation generally have reasonable debugger support, and lots of people know how to program in it. I can't say the same about C++, nor Objective C. And anyone who used the early C++ releases knows how hard it was to debug the output of the preprocessor, so I'm not happy about that suggestion. I find programming anything in C painful. I find programming widgets using the toolkit slightly more painful than normal, because lint can't tell you that you assigned the wrong procedure to a class record, or that you are calling a class procedure with the wrong parameters. But note I said only "slightly more painful" and not "an order of magnitude more painful." I would rather have written the toolkit in Modula-2 if given the choice, even though the lack of initializers would have made writing class records a gross annoyance. Better, I would rather have first designed a strongly-typed object-oriented programming language, then written the toolkit in that. I would rather have used C++ than C. But we didn't consider any of those as viable options then, nor do we consider them so now. All of Athena software goes out "free," and is written in C to make it as widely usable as possible. The toolkit is no exception. - Joel McCormack (joel@decwrl.dec.com)
bzs@bu-cs.UUCP (01/23/88)
From: joel@DECWRL.DEC.COM >As the one who gave the X toolkit its object-oriented flavor, I understand and >sympathize with the trepidations expressed by S. Chu and K. Kimbrough. Yes, >it is all done by convention; no, C doesn't help a bit. As I stated at my >talk, I wouldn't choose C as the first choice for any programming task. The >lack of type-checking causes me to waste large amounts of time when I actually >try to debug my C code, and waste even more time if I have to change a >parameter list. (Don't even mention lint, or I start foaming at the mouth.) >But there are certain unavoidable facts of life to be considered. ... >I find programming anything in C painful... Not a flame, but I find this deeply disturbing. Perhaps this is why a person like myself who doesn't bat an eye at coding most anything in C took one look at the toolkit and just said "Gak! Who designed this?!" I suppose this will be followed up with the now familiar "you're lucky you got anything" response... -Barry Shein, Boston University
rich@oxtrap.UUCP (K. Richard Magill) (01/28/88)
In article <8801230105.AA28529@gilroy.dec.com> joel@DECWRL.DEC.COM writes: >I would rather have written the toolkit in Modula-2 if given the choice, even >though the lack of initializers would have made writing class records a gross >annoyance. Better, I would rather have first designed a strongly-typed >object-oriented programming language, then written the toolkit in that. I >would rather have used C++ than C. FLAMISH PART: (constructive part next paragraph) I won't argue your philosophy because I can understand it. On the other hand I'm not usually willing to pay the overhead of a more stongly typed language. When I am, I'd rather use a special purpose language, (eg, sh, sql, or even uwmrc :-). Which brings me to... CONSTRUCTIVE PART: I don't like Xtk. I don't fault the decisions made in its design. A few years ago I wrote a forms/screen/curses-replacement package that looked like a little brother to Xtk. My only regret was that I wasn't given the chance to write a yacc-ish interface for it. My first (constructive) thought when reading the Xtk doc was that a typical application progammer can't deal with Xtk. He should never see it. If Xtk were hidden under a 4gl/yacc-ish preprocessor, (output in C), it could really be the tool it was intended to be. RAMBLE ON PART: I don't have the time to write it, (I'd rather spend my evenings porting X to my 3b1), but I would like to see it happen, and am willing to help work on a specification and/or design. xoxorich.
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (01/30/88)
Date: Thu, 28 Jan 88 00:41 EST
From: K. Richard Magill <pyramid!fmsrl7!metavax!oxtrap!rich@decwrl.dec.com>
My first (constructive) thought when reading the Xtk doc was that a
typical application progammer can't deal with Xtk. He should never
see it.
Certainly many people believe that. Those attending the X Conference
heard about some UI editors and languages being done on top of Xtk.rtc@masscomp.UUCP (Richard Carling) (02/03/88)
In article <2654@oxtrap.UUCP> rich@oxtrap.UUCP (K. Richard Magill) writes: > >My first (constructive) thought when reading the Xtk doc was that a >typical application progammer can't deal with Xtk. He should never >see it. You are RIGHT!!!! > If Xtk were hidden under a 4gl/yacc-ish preprocessor, (output >in C), it could really be the tool it was intended to be. > Your still a few years behind the times. Let me make a few comments: Many people are working on futher tools to make the Xtoolkit viable. Forget yacc-ish preprocessors, try Interactive User Interface Development Editors. Why write UI code when you can design your complete user interface interactively, so that it is fun and allows quick prototyping. The Application Level Documentation will not be out until the Feb (R2?) Tape release is out. This will have the type of documentation most individuals would find useful. The Intrinsics documentation is for those of us writing new widgets to compliment the functionality provided by the initial widgets in the toolkit, and for us to evaluate the intrinsics that DEC so kindly provided, to make sure we don't feel they screwed up or left something important out. That level needs to stablize, so that is were the focus has been. Then we can concentrate on higher level layers, it all takes a little time. Many companies will be providing public domain contributions to the XToolkit to make it easier on everyone else. These will be higher level layers as well as new widgets and even interactive widget editors. I addressed many of these issues in my talk at the X Conference. We are trying to work togeather with other companies to make the XToolkit platform very useable and very user friendly. But it doesn't happen overnight. Richard Carling, Pickling and Embellishing Widgets, some enhancements to stop the grips. -------------