[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] RE: [OT] Architectural renovation [was: funding free so
From: |
Barak Zalstein |
Subject: |
[Gnu-arch-users] RE: [OT] Architectural renovation [was: funding free software R&D] |
Date: |
Thu, 28 Aug 2003 12:04:37 +0300 |
(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/
- [Gnu-arch-users] RE: [OT] Architectural renovation [was: funding free software R&D],
Barak Zalstein <=