Andreas, On Sat, May 17, 2025 at 1:04 PM Andreas Fink <[email protected]> wrote:
> if I can throw in my view: > > Personally I prefer developer.gnustep.org vs www.gnustep.org/devloper. > However this is merely a question of taste and is not important at all to > me. > What is much more important is that documentation is sound and up to date. > Nice looking yes, how looking: easy and simple. > Apple has pretty good developer documentation and you find the stuff you > need usually very quickly. > A good reference is vital for the newcomer who thinks of maybe using > GNUStep. It's also a sign of matureness. So that part can greatly change > the view on GNUStep from the outside. > I completely agree on the importance of modern documentation practices. It's essential that we create a system that not only is user-friendly but also remains up-to-date as our development practices evolve. Currently we use autogsdoc to generate the documentation. What is sorely needed is a better CSS framework to make the documentation better. Additionally the documentation should be searchable. With solid documentation, we can provide newcomers with the resources they need to feel confident in using GNUstep. This will help foster a more welcoming environment for developers who may be interested in contributing. Overall, adopting modern practices will definitely help in keeping GNUStep relevant and attractive for both current and future developers. > On the point of supporting Swift: > > I personally don't like Swift because it has a totally different syntax, > and it's not intermixable with C or C++. This is in my eyes one of the > evolutionary advantages Objective C has. Originally I wrote everything in C > and then memory management of Objective C helped solving so many issues > that I started to love Objective C and now 95% of my code is pure objective > C. However some old code is still in C and probably will forever. The > transition from C to Objective C was very smooth and incrememental over > many years. As busy developer I would not have been able to move from > Objective C to Swift in the same timeframe as it would have meant rewriting > a lot of code or write a hell of a lot of glue code. In a project which has > half a million lines of code this adds to a lot of work hours.Gradually > improvement is what a developer does all day long. So throwing everything > away and starting from scratch is something you can do as a hobby or on > very small projects. If it gets bigger, this doesn't scale. Even Apple has > built Swift environment on top of the existing Objective C environment and > many libraries stay in Objective C, even if it's just for backwards > compatibility. > The project aims to extend the Swift compiler to target the GNUstep ecosystem by enabling compatibility with the libobjc2 Objective-C runtime. This involves adapting the Swift runtime's Objective-C interoperability layer to recognize and operate with libobjc2, which differs from Apple's proprietary Objective-C runtime used on Darwin platforms. I have been looking into doing this, but it starts with getting the swift compiler building which is no small task. > The Swift language has a few nice advantages though so I can understand > the wish to support Swift. > Not too relevant for me but for others surely. For someone learning a > language for the first time, backwards compatibility is not important so he > wont see the need to have C code inside his normal Swift. > That said, there are masses of new joung developers out there who learned > Swift and used to use the foundation classes because they wrote Mac or iOS > apps. They can not use GNUStep at all. But such folks could contribute in > newer swift stuff out there. And of course use the foundation GNUStep has > built. So supporting Swift is a win-win. > > And that brings me to the next step. If we talk about Swift as an option > for the future, we also talk about developers who write code TODAY on MacOS > and iOS etc. And these folks use automatic reference counting day in and > day out. The legacy runtime thus has to go away because the implementation > in the distros are all based on gcc and the old runtime, you can not write > modern code with it. Thats an absolute showstopper for people who look into > GNUStep code right now. They will argue that GNUStep has been frozen to the > old standards no longer relevant. Pure legacy. > Possibly true. And I believe supporting swift would then would make things even worse as > its even further away. We have to modernize GNUStep to keep up with the > current tools. That doesn't mean we need to implement everything Apple has > added in the last 20 years, but at least a fundamental subset so 95% of > Apps could be ported without any major issues. And in my eyes ARC must > absolutely be supported in the default installations. Expecting a newcomer > to first recompile GNUStep (which has quite a few pitfalls if you do it for > the first time) can easily discurage new developers. > ARC is already supported in GNUstep when using clang. I am confused > It doesn't mean GNUStep code itself must use ARC but the default runtime > must become libobjc2 so ARC is supported for all the projects who need it > (which is 95% of todays modern projects I believe). If not, GNUStep will > end up in the Legacy corner forever. Thats in my eyes also a key issue to > keep GNUStep attractive for old and new developers. And because gcc's lack > of support for the Objc language, this means moving everthing to clang as a > consequence. > > Documentation: > > Personally, I'm willing to do some efforts to (re-)write documentation > once its clear where this is heading. > The Apple automatic documentation production using DocC ( > https://www.swift.org/documentation/docc/) sounded very neat for that in > my eyes but I have no clue if this could be easily be applied into GNUStep. > But that approach would bind the code to the documentation and would > tremendously help to keep the documentation up to date. > We would need to get DocC, which is written in Swift, working on Linux and GNUstep in the first place. > In any case, let's keep the discussion productive and objective. > > Andreas Fink > Yours, GC -- Gregory Casamento GNUstep Lead Developer / Black Lotus, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com https://www.patreon.com/bePatron?u=352392 - Become a Patron https://www.openhub.net/languages/objective_c https://www.gofundme.com/f/cacao-linux-a-gnustep-reference-implementation
