guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: language translator help


From: Thien-Thi Nguyen
Subject: Re: language translator help
Date: Wed, 15 May 2002 16:13:38 -0700

   From: Marius Vollmer <address@hidden>
   Date: 15 May 2002 22:49:06 +0200

   Please don't do this in the context of 1.4 releases.  We have the 1.7
   series for experiments like that.  Please keep the 1.4 releases
   (if you feel that you must divert resources to them) as bug fixing
   releases.

who uses libguilereadline independent of using libguile?  who uses
libqthreads independent of using libguile?  moving these things inside
is a bugfix; the user experience is not changed incompatibly.  overall
maintenance is eased.  (all 1.4.x releases aim for this -- sorry, i was
not clear about that goal.)

   On the specific point of what exactly a Guile extension or plugin is,
   where to install it, how to link to it, etc, I remain convinced that
   Guile itself should continue to treat its extensions as standard
   operating system shared libraries, using libtool as the interface to
   the operating system.

of course you do (because you don't take user feedback into account on
this issue perhaps), and because of this, no third party can produce
guile plug-ins cleanly w/o major hassle, and over time fewer and fewer
third parties take the trouble.  big lose.

even more telling is distributors (who have well-articulated criteria
for evaluating how packages can be good neighbors) refusing to upgrade.
mega lose (for end users of apps that may benefit from newer guile
versions had not the newer version been rejected).

   Experimentation can occur outside of Guile.  Packages that need to go
   beyond the simplistic shared library view of the core Guile and want
   to impose additional rules on the use of their shared libraries can do
   so to a very large degree without needing any cooperation from Guile
   itself.

you don't get it.  packages WANT cooperation from guile (otherwise guile
is seen as un-cooperative and a PITA to work with -- duh!).  i can harp
on this more, but because you don't take user feedback into account on
this issue, what's the point?

   Negative.  I don't have the feeling that we are dangerously
   incompatible in the 1.6 series.  What do others think?  It would be
   bad to switch strategies at this point, even if you have a point.

if you can articulate your strategy in the first place, that would be a
good start for discussion.  if you can record this, that would be best.

   What is wrong with Guile's current approach other than that you don't
   like it?

guile has a bunch of people working on it for their own ego fulfillment
(self-included), w/ varying levels of organization and maturity.  this
is not to like or dislike but to understand and work through.

   What?  The split is there so that people can choose not to be
   bothered with developers chit chat.  You don't need a license to
   subscribe to guile-devel.  It's a tool of organization, you process
   junkie, not of dividing and conquering people.

it's a tool of insulation, and fosters this kind of dialogue:

 developer-1: hey, what do you think of BRAINDEAD-IDEA?
 developer-2: THOUGHTLESS-AFFIRMATION.
 user-1: i don't understand.
 developer-1 and developer-2: don't worry, we are the experts;
                              you'll love it, really!

 [6mo later]
 developer-1: well, we have to start over again.
 developer-2: THOUGHTLESS-AFFIRMATION.
 user-2: hey, that breaks my code.
 developer-1 and developer-2: you're a user, go away!

all guile users are programmers; if you can't see how guile developers
have something in common w/ guile users (and structure the dialogue to
be beneficial to everyone by exploiting pooled experience), that's not
good process, and doesn't earn respect from process junkies.

thi



reply via email to

[Prev in Thread] Current Thread [Next in Thread]