Kenny Tilton wrote: > Again, I get the feeling Clim either predated CLOS or failed to > understand it.
Could give you concrete examples of places where CLIM doesn't use CLOS properly?
> With first Strandh himself and now Mastenbrook freely admitting > that Clim is a bitch to learn, I guess this much has been settled. > What remanins unclear is why they do not see this as a Bad Sign.
Spoken like a true Schemer ;-)
In my experience most interesting and 'deep' subjects (e.g. music, mathematics, foreign languages, Common Lisp programming) are a bitch to learn. I don't see that as a bad sign.
>> Nonsense. Sometimes commercial enterprises do theoretically >> interesting stuff, and can talk for an hour about that without ever >> "pitching". In fact, the only sales pitch I heard in three days was >> for open source, some yobbo pretending that McClim was a hot >> technology, in a desperate attempt to suck more developers into a lost >> cause. mastenbrook was gracious enough to admit that Clim's design was >> so godforsaken that getting it to do anything useful required months >> of study, but aside from that I have seen less preposterous >> performances from actors in infomercials. "Isn't this great?" "Can you >> believe how cool this is?" "Just look at this astonishing trick!". Not >> one line of code, or any indication of how long he slaved over his >> demo. Just trivial stupid pet tricks accompanied by "Can you believe >> it?".
>> To tell you the truth, I think he faked all those screen shots and >> that McClim does not actually exist. How sad.
> Oh, Hi Kenny. I looked for you specifically in the audience at the start > of the presentation and you were not there. > Did you sneak in later? I > don't remember seeing you at the end either.
"If you plan to enter text which our system might consider to be obscene, check here to certify that you are old enough to hear the resulting output." -- Bell Labs text-to-speech interactive Web page
>> Again, I get the feeling Clim either predated CLOS or failed to >> understand it.
> Could give you concrete examples of places where CLIM doesn't use > CLOS properly?
No, this is based on reading things like "presentation types make XXX easy", and the way I use CLOS to handle XXX. Also, casual scans of the CLIM doc and seeing opaque DEFWHATEVER forms that one has to internalize over what seems to be a significant learning curve. I have created stuff like that before realizing that if I just stuck to CLOS anyone could figure out how to subclass or specialize methods to tweak behavior.
>> With first Strandh himself and now Mastenbrook freely admitting >> that Clim is a bitch to learn, I guess this much has been settled. >> What remanins unclear is why they do not see this as a Bad Sign.
> Spoken like a true Schemer ;-)
Aside: I think a CW is taking hold. The first thing a Schemer does is rejoice over the tiny spec. The second thing they do is assemble their own personal Common Lisp.
> In my experience most interesting and 'deep' subjects (e.g. music, > mathematics, foreign languages, Common Lisp programming) are a > bitch to learn. I don't see that as a bad sign.
That fails to address whether or not the difficulty is implicit in the content being learned. Clim makes interfaces harder to build than necessary. Whatever productivity levels Climmers eventually reach could be had much more easily.
"If you plan to enter text which our system might consider to be obscene, check here to certify that you are old enough to hear the resulting output." -- Bell Labs text-to-speech interactive Web page
> No, this is based on reading things like "presentation types make > XXX easy", and the way I use CLOS to handle XXX. Also, casual scans > of the CLIM doc and seeing opaque DEFWHATEVER forms that one has to > internalize over what seems to be a significant learning curve.
Apart from the lack of tutorials, I don't think that CLIM's learning curve is worse than that of any other GUI library of a comparable power.
(No, I never tried Cello. I'll take a look when Cello's design and documentation becomes half as stable, reliable and understandable as CLIM's. Just let me know when that happens.)
> Aside: I think a CW is taking hold.
Sorry, I have no idea what a CW is and Google doesn't help.
> Clim makes interfaces harder to build than necessary. Whatever > productivity levels Climmers eventually reach could be had much > more easily.
OK, those are more interesting claims than the claim that CLIM is bad because it's difficult to learn. I would still be very interested in any evidence (even anecdotical) you can give to back up these claims.
On Sat, 25 Jun 2005 21:13:02 +0200, <alemm...@xs4all.nl> wrote:
> (No, I never tried Cello. I'll take a look when Cello's design and > documentation becomes half as stable, reliable and understandable > as CLIM's. Just let me know when that happens.)
It already has. I've seen demos of both, but this is an apples and oranges type of comparison, so pointing out that Cello has useful abilities now doesn't mean much in the context of CLIM. The people behind CLIM are not focused on 'useability for the novice' at the moment (and probably never will be).
-- The LOOP construct is really neat, it's got a lot of knobs to turn! Don't push the yellow one on the bottom.
Kenny Tilton <ktil...@nyc.rr.com> writes: > Christophe Rhodes wrote: >> even if they have, I'm happy to hold out and >> say that it is simply different, such that previous experience of >> other paradigms does not necessarily transfer across.
> My sense is that the problem is not any paradigm shift, rather it is > the awkwardness of programming the thing. As Strandh said:
> "The "problem" with CLIM is that its > layered approach allows a sophisticated programmer to intervene at > lots of points in the way CLIM works internally. While this feature > is invaluable to sophisticated programmers, it is confusing to > beginners."
Disregarding the fact that what you quote doesn't match your summary of it, maybe this simply means that we don't yet know how to teach it? Not even in my wildest dreams do I expect someone to absorb CLIM's many layers in one sitting -- but I think that those who therefore say that it's impossible to get started and do useful stuff (and sometimes stuff that is hard to do elsewhere) are overstretching.
I will happily admit that there are things I don't know how to do with CLIM: "ordinary" application layout with callbacks attached to buttons is one of them. I don't believe that it's particularly hard, or even terribly different from the facilities offered in other languages; it's simply not what I do. (Also, you should take care not to turn either of those sentences into a quote supporting your position: in no way am I a CLIM expert -- but I'm learning, slowly, and am managing to get the job done).
> Cells presents the developer with a paradigm shift. The only thing > hard about learning Cells is making that shift. Even I tended for > years to slip out of declarativethink when writing new code, and I > developed Cells. But no user has ever indicated they could not figure > out how to program with Cells, despite the absence of documentation.
I have to admire the way you make a tautology sound like an endorsement. :-)
> The "increase in power" argument, btw, fails if, as I suspect, the > difficulty of learning Clim is an artifact of bad design, and not an > ineluctable part of interface programming.
What if it's neither: but simply a failure to teach it right?
Maybe a good analogy to the didactic materials available for CLIM would be that we have the equivalent of AMOP available, and nothing else but a few design documents and examples involving generic functions returning "Hello, World". I think this is a good analogy of what exists to teach CLIM at the moment, and it's not really surprising that, in the absence of a structured way of understanding things, people run against quite foreign concepts when they've hardly crossed the threshold.
Nevertheless, as it would have been a shame to throw CLOS out simply because people were introduced to metaclasses before they were introduced to classes, so it may (I make no absolute claim: I admit my ignorance) be a shame to throw CLIM out because of the absence of teaching materials for it.
Arthur Lemmens wrote: > Sorry, I have no idea what a CW is and Google doesn't help.
conventional wisdom.
>> Clim makes interfaces harder to build than necessary. Whatever >> productivity levels Climmers eventually reach could be had much >> more easily.
> OK, those are more interesting claims than the claim that CLIM is bad > because it's difficult to learn. I would still be very interested in > any evidence (even anecdotical) you can give to back up these claims.
Unlike most Lispniks, I do little else /but/ GUI work, from Apple II in Integer Basic and even assembler to early Macs with C and native widgets to a pre-windows DOS GUI to Think C's godawful TCL (which I actually punted on because even its fans admitted it took a year to learn) to Smalltalk to Lisp with MCLs OS9 gui wrappers to AllegroCL and Common Graphics. Also rolling my own on win32 (didn't like CG) and OpenGL (Cello) and I have at least ported Cells-GTK to UFFI if not develop under it. So what can I say? Most GUIs are programmer friendly, allow easy attainment of easy stuff and fancier stuff with reasonably more effort. The Think C GUI library being a good counterexample, and its author went on to CodeWarrior where I heard he tried to do better, so looks like there is no argument there that the thing was a wreck. Again, even its fans said it was a bear to learn.
"If you plan to enter text which our system might consider to be obscene, check here to certify that you are old enough to hear the resulting output." -- Bell Labs text-to-speech interactive Web page
On Sat, 25 Jun 2005 21:20:12 +0100, <cs...@cam.ac.uk> wrote:
> What if it's neither: but simply a failure to teach it right?
Then perhaps the project is at the point that some time spent on "teaching it" will bring the additional developers that they desire. If the developers cannot separate out the important trees in the McCLIM forest as tutorial guideposts, no one can.
-- The LOOP construct is really neat, it's got a lot of knobs to turn! Don't push the yellow one on the bottom.
>> I have no problem with commercial software, I'm not a RMS-worshipping >> communist,
> ObFlame: > How about a return to free market capitalism in software: i.e. the > removal of the copyright (and sometimes patent) monopoly interference > in the software market. If you are a free market capitalism supporter, > you SHOULD have a problem with current copyright- and patent-supported > "commercial software" (note that Free-as-in-freedom i.e. Libre software > can be and has been profitable commercially, too). If microsoft were > competing in a real free market without the crutches of copyright and > patent law to prop them up, I doubt there'd be the problem with them we > have today.
> So if you actually talk to Libre software supporters, while they tend to > range almost right across the economic and political spectrum, an awful > lot of them are european-liberal/american-libertarian, not communists, > taking the "Without copyright the GPL would be unenforceable. It would > also be unnecessary." line.
> (while I'm not particularly communist myself, it is also important to > note that communist is not necessarily such a dirty word outside the > USA anyway).
I don't know what this has to do with the topic, but thanks, I'll be sure to remember that!
-- I kill a communist for fun, but for a green card, I gonna carve him up real nice - Tony Montana
Kenny Tilton <ktil...@nyc.rr.com> writes: > But no user has ever indicated they could not figure out how to > program with Cells, despite the absence of documentation.
Well, me, and I've casually listened to cell-speak since the days where it was called semaphors and Kenny Tilton was still aiming at enlightment :) -- Now K.Tilton is going to Killton me.
More concretely, I did not groked the concept of "be". To be or become, that is the question.
More precisely, I think I understand the abstract requirement, as it's nothing new and seen in many places, e.g. the separation between constructing parts of pipeline, clunging it together and finally have something flow through the pipes, but the spare explanations in what doesn't want to call itself cells documentation confuse me more than help.
Regards, and enjoy life, Jorg Hohle Telekom/T-Systems Technology Center
