if I can throw in my view: Personally I prefer developer.gnustep.org <http://developer.gnustep.org/> vs www.gnustep.org/devloper <http://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.
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 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. 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. 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. In any case, let's keep the discussion productive and objective. Andreas Fink
