Re: [9fans] Re: Building GCC

[tlaronde@polynum.com]

On Thu, Jan 24, 2008 at 09:41:02AM +0000, pavlovetsky@gmail.com wrote:
> [...] Lets drop web browser and KDE
> for a while and say this: there are cool, interactive scientific
> visualisation tools I would like to use along with fossil+venti
> infrastructure and Plan 9 tools and I would like to see them
> integrated with each other really well. As I said, it is absolutely
> impossible to reinvent everything again, so the question is how to
> integrate the already existing applications for UNIX and Plan 9. I
> vote for emulation.

I beg to differ. And  I will take a real, named example: Public domain
CERL G.R.A.S.S. (GIS software), transformed in GPL G.R.A.S.S., and,
since 2004, KerGIS, with the core under a BSD like license.

This is a huge beast. The original CERL version did not compile anymore
(it was dropped in 1992). It had a new Motif interface that was more
than 7 MBytes of code---did not compile; was a mess I did even not tried
to fix.

When the software was running, what it does was terrific. Altogether,
the ``conservative'' approach you express has led to GPL GRASS. More and
more, since the code base is huge and since the original worked, and
since it is not admissible to reinvent the wheel, but too difficult to
maintain, they drop part of the system, ``externalize'' parts, relying 
on third parties software.

The motto is: precious but too huge to maintain, so let change the 
minimum and drop what is not understood anymore.

My motto is: reorganize and redevelop it so that it is maintenable
(french origin: able to be held in hand).

On the one hand, the bazaar: so-called tens or hundreds of people
belonging to a ``community'' (really a handful of people really working;
many more discussing).
On the other hand, a single person: myself.

The result is that redoing, thinking about what makes sense and in
particular the split between terminals and CPUs (more and more today,
since a real, heavy computing system is a specialized beast, out of
reach of small entities, unless they can share it, i.e. buy some "shared
time" on some remote computing center), I have remade a lot of things
(not finished yet).

The last in time result is the split between computing and accessing,
with the generation of a 2D interface to _represent_ data and commands
(push a button instead of typing line code) independent of computing,
allowing to use KerGIS not only on Unix, but on any other type of system
(my goal is to allow KerGIS to run natively on Plan 9 or derived systems
or any other system with a C compiler with the minimum of system
dependent stuff).

So KerGIS is now _less code_ than CERL GRASS or GPL GRASS, but with more
features than the original, more than GPL GRASS 5.x (comparison is more
difficult with 6.x that I don't know), more maintainability, more future
potential.

And for the example of the Motif interface, that was
everything melt in CERL GRASS, and just a backend in KerGIS for the GiG
(Graphical interface Generation) numbers are:


CERL GRASS (in Kbytes):

7470	cerl/src/xgrass


KerGIS (in Kbytes):

316	kergis/bin2/monitor

being under KerGIS 4 CWEB files (Donald E. Knuth and Silvio Levy
litterate programming, C for code and TeX for explanations), that is a
great part of documentation: the library, handling geometrical elements
(representations in graphic coordinates and keeping identity of
individual elements---redrawing, changing color etc is local to the
terminal since the informations are kept), a X11 low level back-end, 
a Motif implementation of the toolkit for GiG, and GiG.

One has not to reinvent the wheel if it is a wheel: the best simple
thing. But if this is a wheel, it can be ported easily to other system.

If portability is difficult, this is because what ``works'', nolens 
volens, is not a wheel. This is time to engineer the thing to invent a 
wheel doing the stuff.
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C