Re: Clang/LLVM migration roadmap

[Daniel Boyd]

Riccardo,

Thanks for the response. I agree there is certainly a distinction between the 
user types and I, as a developer myself, was referring to #2. However, I 
disagree that catering to each group is equally important at this juncture for 
two reasons: 

1) GNUstep doesn’t currently have enough quality apps to attract user #1. That 
is not to say, of course, that it has none, but I think it would be 
uncontroversial to say that it could benefit from having more—a lot more. 

2) GNUstep’s utility comes not only from its general purpose end-user apps, but 
also from its facility as a framework for people writing narrow-purpose, highly 
customized apps. This is what I use GNUstep for primarily. My apps will only 
ever be used by a small number of people in my company because they are highly 
specialized to address a specific process or function unique to us. Indeed, 
going back to the early 90’s, this has always been a strength of the 
NEXTStep/OpenStep/GNUstep/Cocoa framework.

For these two reasons, I believe it is more
important for GNUstep to focus on attracting developers. And if you attract 
more developers—particularly developers writing quality, general purpose 
apps—that will, in turn, attract more end users. 

Lastly, to your point about people having freedom to choose which tools they 
want to use, I don’t disagree at all. This is FOSS and freedom is what makes 
FOSS great. However, in the long run, if we want users of any kind to be able 
to choose GNUstep at all, we need to grow the project now and that means 
attracting more developers, in my humble opinion. 

Cheers,
Daniel

Sent from my iPhone

> On Feb 14, 2022, at 12:12 AM, Riccardo Mottola <riccardo.mottola@libero.it> 
> wrote:
> 
> Hi Daniel,
> 
> I think unvoluntary you made a very important point, I don't know by being 
> aware of it or not.
> 
> 
>> If you’re looking to recruit more GNUStep users, I just don’t think you 
>> can do that without ARC, @[], @{}, etc. There are plenty of ObjC developers 
>> out there right now who are potential future GNUSteppers. And as you recruit 
>> people, I think “you have to use ObjC instead of Swift” is a much easier 
>> pitch than “you have to do manual memory management and type out 
>> objectAtIndex: every time you want to get an object from an array”
> 
> You used the term "user" and that's wonderful because it made me think about 
> it. I agree and always thought we need more users.
> 
> But what is a user? I can think at least of two types.
> 
> 1) User of GNUstep libraries because user of GNUstep applications. This kind 
> of person doesn't care about runtimes and memory management, he just installs 
> applications by some means and uses them. He cares about stability, speed, 
> easy of installation. That's the most common user, he consumes GNUstep... 
> like a user of GIMP not knowing it is based on GTK. Or the Mac being based on 
> Cocoa, etc.
> 2) User of GNUstep because he writes GNUstep applications, for work, 
> pleasure; in a mix of existing apps or not. That person may care what kind of 
> language and runtime he needs, but still he doesn't care what GNUstep core 
> (and other applications he perhaps uses, like GWorkspace, ProjectCenter or 
> GORM) is written in. He only needs to be able to use ARC, properties (or not, 
> if he chooses not to). So he needs Clang and libobjc2 as for now if he needs 
> ARC. The only thing he needs to worry is that the core libraries need to be 
> compiled with ARC support and that. ARC can be turned on for module and not 
> another, David teaches us
> 
> Only a contributor to GNUstep itself needs to worry about what language it is 
> written and what code rules it has.
> 
> Of course, every user kind of 1) and 2) may become a contributor; but I deem 
> it prefectly acceptable to give him freedom to code whatever he wants, but 
> for GNUstep "tiself" additional restrictions can be applied.
> 
> I always did know these disctinctions, but it makes me see this discussion 
> with a new mindset -à and take the hype and urgency out of it.
> 
> Still, libobjc2 can benefit a better support, integration, ease of install, 
> platform support. But the urge of migration gets relative.
> 
> Riccardo
> 
> -- 
> Proudly sent with GNUMail on GNUstep on FreeBSD/x86-64
>