[GRASS-dev] GRASS-TNG

[Radek Bartoň]

On Wednesday 21 of February 2007 18:05:51 Trevor Wiens wrote:
> Radek,
>
> Although right now I'm not actively developing GRASS, I would like to
> comment on this.
>
> Generally my impression of this concept is not positive. Over the years
> I've seen ambitious projects come and go and GRASS, warts and all,
> remains. Yes, the core architecture of GRASS is old and certain aspects
> need rewriting to be sure, but is it practical and thus intelligent to
> try to start from scratch?

I answer by another question. It is possible to rewrite core parts without 
affecting modules' code and without causing so much needs of refactoring and 
bugs so that starting partially from scratch will not take so much time?

> For example, on your site, you suggest that C++ be used because it is
> the standard for "modern" development. The reality is, if you want
> speed and memory efficiency, well coded plain C wins every time. If you
> want to do GUI development, then C or C++ is probably not necessary for
> most tasks, so some Python based solution is more appropriate. For core
> libraries plain C is likely the best choice. Choosing a tool because it
> is "modern" rather than because it is the best tool for the job, is not
> logical.

Now I see that I perhaps shouldn't write that note that "C++ is standard" that 
way. I was not ment as a argument against C but as a argument against Python 
as main development language (even if I'd like to do everything in Python). I 
decided for C++ for now because of that it provides balanced ratio between  
relatively good perfomance and mainly certain level of abstraction and thus 
fastest code aquisition. Secound reason was that certain people wanted that 
core parts will be in C++. Whole project is about discussion so If you don't 
agree just login to make rights to discussion forum and write up there your 
suggestions.

> Although there are issues with the raster library, the one issue I
> continually face is the cruftiness of vector library's memory
> management. Before he left the project Radim Blazek left a todo list of
> issues to be resolved in the vector library. If you are full of energy,
> IMHO it would be much more helpful to all users to take on that list and
> resolve the memory issues in the vector library, rather than diverting
> energy in pie in the sky dreams of a new GRASS.

Sometimes a dream can turn to reality and sometimes they can't. For me even if 
this project would end after year without any success it won't be a waste of 
time. I just want to try to "make my dream become true" and it's up to 
everyone if they consider that this project has a future and contribute to 
it.

> If you want to support parallel processing or time series it would be
> more appropriate to work on the redesign of the raster library with
> those features in mind rather than forking the already limited
> development resources of the project. Similarly, examination of the
> core vector library as to how it needs to be modified would be useful.

I tried that way when I was exploring my possibilities of contribution. I 
tried to look on NVIZ and implement colored vectors. After two day of hard 
work I gave it up. Not because I lack of patience or determination. I just 
consider that THIS is a waste of time.

> My primary issue with your approach is the likelihood of wasted effort
> ending up in the trash can, as I fully expect from projects like KerGIS.
>
> However, if you are independently wealthy and have a staff of
> developers waiting to work on this full time over the next year or two,
> then I would be supporting the initiative.
>
> Although there are issues with GRASS, this kind of effort is best kept
> within the GRASS community like Michael Barton's GUI development
> efforts, which have yielded real results quickly that are of direct
> benefit to GRASS users.

> I would also like to second Michael's comments about naming. If this is
> not part of the GRASS project, naming it GRASS is inappropriate.
>

I want to stay close to comunity as possible. If comunity consider that I'm 
not close enough, I'll change a name of project, but without comunity I'll be 
forced to change project's goal to make a real "fork" because without comunity 
my project would be nothing.

-- 
Bc. Radek Bartoň

Faculty of Information Technology
Brno University of Technology

E-mail: xbarto33 at stud.fit.vutbr.cz
Web: http://blackhex.no-ip.org
Jabber: blackhex at jabber.cz