[Gnu-arch-users] RE: [OT] Architectural renovation [was: funding free software R&D]

[Barak Zalstein]

(I'm experimenting top-posting as it seems to be an "industry standard" in most 
of the world, and since
this is already [OT], I guess no harm is done).

You mention Visual Basic as an example of non-robust internal architecture yet 
the 
suggested alternative is at least 3 years later.
VB might be non-ethical to some developers, I don't know. 
But it integrates nicely with lookout express and other non-emacs environment 
features and time-to-market
is fast enough.
VB might be terrible for future upgrades, but when using an application for a 
specific task, you only want one button
to do one thing.
The last time I encountered a (GNU) Emacs GUI I was puzzled by the fact that 
the left mouse button is not working, but 
the middle mouse button is doing just fine, which is already non-intuitive and 
incompatible with the rest of the environment (Note that a fresh install never 
comes with a default .emacs file).
This is similar to a point I tried to make earlier: most computer users don't 
have a GNU or a Linux background and thus have no reason to look at CVS, arch, 
keepbitter, or whatever.
http://twiki.iwethey.org/twiki/bin/view/Main/FreeSoftwarePrimer implies that a 
"slightly inferior, but good enough competitor" has better chances than a more 
elegant solution, while the emphasis is on the "get it working now" rather than 
"get it perfect later" (my interpretation, cut and paste out of context).

Barak
> 
> "Stephen J. Turnbull" <address@hidden> writes:
> 
> > >>>>> "Tom" == Tom Lord <address@hidden> writes:
> > 
> >     Tom> I think it's because there's not much demand for software
> >     Tom> development and, consequently, tools that help 
> make software
> >     Tom> development _better_ are anthema.
> > 
> >     >> There's plenty of demand for software development.  
> On the one
> >     >> side, there are the big proprietary firms and the inhouse IT
> >     >> organizations.  But for them a few hundred seats of Rational
> >     >> license is a non-issue.
> > 
> >     Tom> I suppose "plenty" is your weasel-word there.  Have you
> >     Tom> _seen_ the unemployment figures?  The revenue figures?  I
> >     Tom> wouldn't expect you to but I suppose you also 
> aren't thinking
> >     Tom> about the big cultural changes, _not_ limited to but
> >     Tom> certainly acute in silicon valley where, not all that long
> >     Tom> ago, employers were fostering new software projects as fast
> >     Tom> as they could get them.
> > 
> > Don't be thil-ly.  I'm an economist, remember?  I have seen the
> > figures.  The bubble broke, that's all.
> > 
> > For technical (ie, cashflow) reasons, this means that a lot of the
> > demand is not "effective", thus unemployment.  I know many 
> _employed_
> > software people who are screaming under the burden they bear,
> > supporting obsolete software abandoned by the vendor, and I know a
> > few "IT executives" (not in the software development industry, but
> > ass't VP IT, that kind of thing) who are _all_ well aware 
> of what they
> > are being forced to do to their companies by the cash crunch.  There
> > is latent demand, it will express itself.
> > 
> > The pain that the currently unemployed feel is not 
> correlated with the
> > long term issues of investment that you're talking about.  
> The problem
> > for investment is cash flow (which will fix itself, and in 
> the process
> > a reasonable fraction of the unemployment) and poor allocation
> > decisions by management (which is what we should discuss 
> how to fix).
> > 
> > If you want to talk about how to employ more programmers, 
> that's fine,
> > but I thought we were talking about restructuring the way 
> the industry
> > works.  In My Somewhat Informed And Becoming More Expert As 
> Time Goes
> > On Opinion, there is enough demand to support the needed 
> restructuring
> > concurrently with the application-level development.
> > 
> > What needs to be done is to take those CTOs and MIS VPs and 
> show them
> > there's a better architecture.  Look, these guys were 
> impressed by the
> > cottage industry that sprang up around Visual Basic.  OK, later they
> > learned better, that GUI/RAD and robust internal 
> architecture are not
> > the same thing.  But Lucid? long buried; BeOpen.com ditto.  
> [lx]?emacs
> > doesn't impress these guys (although there are at least 
> three 4-letter
> > investment houses suspected of running proprietary variants 
> of XEmacs).
> > But zope.com (which escapes the BeOpen.com debacle, please 
> note) seems
> > to be weathering the storm.  So there's some evidence that 
> they can be
> > educated.  :-)
> > 
> > Now, you're claiming that radical improvements over current best
> > practice should be possible.  I believe you, your intuition is good,
> > but I can't explain it.  We've got to explain in the kinds of terms
> > that Eric Raymond did, or nobody is going to listen.  Raymond got
> > attention from the big houses; even if you don't like his message,
> > you've got to respect his sales ability.  Telling the truth may be a
> > little less effective, but style really counts here.
> > 
> >     Tom> Same old, same old.  Some software architectures 
> give hackers
> >     Tom> more inspiration to participate and generate value than
> >     Tom> others.
> > 
> > Tell me more.  I don't see it.  XEmacs _today_ has the "Emacs
> > architecture," supports internal graphics, embedded toolkit widgets,
> > sound, and we're working on smell :), supports DSOs, 
> supports drug and
> > drip.  It provides a reasonably robust and simple to 
> maintain package
> > manager.  We move another submodule out of C and into Lisp every few
> > weeks.  The architecture is there.  It needs some of the 
> burls hacked
> > off and sanded down (not to mention polished up).
> > 
> > Where are the hackers?  More at GNU Emacs (which of the 
> above has only
> > the internal graphics support, and a dedicated GNU-camp third-party
> > maintainer tells me it still sucks) than at XEmacs, and GNU Emacs is
> > way understaffed for its role IMO.  Evolution probably has 
> as many as
> > the Emacs projects combined, at least guesstimating from 
> list traffic.
> > 
> > I'm not discounting your _intuition_; I respect that 
> highly.  But the
> > _words you say_ make me think "XEmacs" (ok, ok, to a guy 
> with a hammer
> > everything looks like a thumb, or whatever), and I just 
> don't see the
> > interest.  So something else is needed.
> > 
> > Even once we've got that "something else", there's another hurdle.
> > That is the belief that integrated architectures enhance 
> market power
> > (Microsoft taught us that).  So we _also_ need a business model that
> > turns that on its head, somehow.
> > 
> >     Tom> Yes, it will take a lot of work to make a new one 
> with enough
> >     Tom> performance and eye-candy, and graphics features to have
> >     Tom> impact
> > 
> > Starting from today's XEmacs, three man-years.  The features you
> > mention are there, and performance is not a problem on today's 512MB
> > RAM, 1 GHz machines.  But calendar time?  A decade, unless 
> "management"
> > pushes really hard in that direction.  So tell me why I should push!
> > 
> > The dedicated hackers are not personally interested in going in that
> > direction.  They already have their hacking platform.  
> Casual hackers
> > would rather work in C# (or SWIG private libraries and call that an
> > API) than harangue us to make existing features more 
> accessible.  But
> > without casual hacker input[1], the core developers can't prioritize
> > which features to make accessible, and typically thus don't work on
> > accessibility at all.  The users want their eye-candy 
> ready-to-eat and
> > individually wrapped, which the dedicated hackers actually resist
> > working on.
> > 
> > Python, Perl, Ruby are feasible, even superior, alternatives for
> > non-text-intensive applications.  I've never much liked 
> Perl or Ruby,
> > so I can't give examples for them.  But Python-libglade 
> allows hacking
> > up reasonably good-looking GUI quickly.  People I know say 
> you have to
> > wrap your brain into a Klein bottle to hack Zope (just like 
> Lisp), but
> > once _you're_ properly twisted, hacking _Zope_ is straightforward.
> > Mailman, for all its OOTB design issues, is eminently hackable.
> > 
> > But it seems like C-level hacking of GTK and the OS kernel and stuff
> > is where dick-length gets measured.  Up to Mutt, OK, there 
> was sh (but
> > mh ain't bad at all) and Perl (my recent close encounters 
> of the third
> > kind have all been in /var/lib/dpkg/info, and my skin 
> crawls... :) and
> > Scheme (which I think is elegant but scrambles some 
> people's brains).
> > 
> > And although it has nothing to do with calibration of secondary
> > gender-specific characteristics, even you turned to C to reimplement
> > Arch.  Why not Python, or XEmacs Lisp (yes, we would very likely
> > swallow a Lisp binding that linked to libarch as an 
> option)?  Or Guile
> > or systas scheme or scsh or clisp or Perl or Ruby?  
> Something deep is
> > going on here.
> > 
> > 
> > Footnotes: 
> > [1]  Jamie Zawinski and David Kastrup deserve kudos here.
> > 
> > -- 
> > Institute of Policy and Planning Sciences     
http://turnbull.sk.tsukuba.ac.jp
> University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
>                Ask not how you can "do" free software business;
>               ask what your business can "do for" free software.
> 
> 
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnu-arch-users
> 
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/