I mostly agree with David Pirotte here. For a program, it is not always relevant what it is implemented in except if it is meant to go with several other programs (say it is part of a framework). Now, for an all new program, mentioning what it is implemented in in the name is a reasonable choice. Changing the name of a program to do it is a bit different circumstance.
However, there is a major catch in this situation. Christian Brunello mentioned in the first email, if I read it correctly, that there are plans and intentions to extend it beyond just fdisk. Then renaming to something like [something] diskutils makes a lot of sense. If it is just a bunch of programs we get back to the argument earlier about including guile in the name or not. However, if those plans for extension include libraries and/or packages for use by other 3rd party programs, then the implementation possibly matters a lot. If this is part of the plan, then Guile Diskutils is a fairly reasonable name in my opinion. I really hope this is in the plan, by the way. There are a lot of interesting things that could lead to. Freja Nordsiek On December 13, 2017 1:01:41 AM GMT+01:00, David Pirotte <da...@altosw.be> wrote: >Hi Christian, > >> >> IMHO the programming language/compiler a utility is written with >is an >> >> implementation detail that should not manifest itself in the >utility's >> >> name. In this case, I think "GNU Distutils" would be better. > >> > "GNU Diskutils" > >> > 1+ >> > David > >> I'm sorry but I do not agree. Guile is not an implementation detail >in >> this case. It means that the package is based on Guile. It's like >xterm >> (a terminal for x window), gnome-terminal (a terminal based on the >GNOME >> framework) and so on. > >It is, by definition, an implementation detail: whether your user know >(or not ) in >what language the tool is implemented won't make _any_ difference on >how they will >use it, neither will it change the output of their usage ... > >Besides, having Guile in the name may even be a 'blocker': 'out there' >most do still >fear scheme, in general, and Guile is no exception. They will >question, because of >prejudgment mostly, if it 'works well', why the hell is it not >implemented in php, >python, go, java ... in a 'real language' ... > >If it was a library for Guile, it would be different. As an example, >I'm the author >and maintainer of GNU Foliot, not GNU Guile-Foliot, because it is an >app (even >though users could extend it, but that is anther story...) ... users >(most users) >are not interested to know i what language it's been written , they >want to know if >is good, if it does the job, if it is well maintained ... > >My 2c, >Do as you wish of course, >David
