I can't figure out why GNUstep has languished so. Given how many ObjC developers there are out there, and given how nice it would be to target for multi-platform apps, it feels like the sort of thing that should have gotten good pretty quickly in a world of resurgent Apple.

...and this is the moment that you realize there aren't so many Obj-C developers out there as much as there are that many iOS developers out there, all being forced to use one particular language.

Edit: For the record, I am a fan of Obj-C, not an iOS developer, and would love to see more movement on GNUStep. I just need the time...

Really, I think there are plenty of ObjC fans, but ObjC developers can be divided into two groups:

1. Those who use it unwillingly, and happily use some other environment when not targeting Apple platforms.

2. Those who are big Apple fans and don't see the point of targeting non-Apple platforms in the first place.

I'm sure there are exceptions, but not enough for GNUStep to get traction.

IIR, GNUStep has always been a stepchild on Linux, with KDE and Gnome sucking up all the air in the room. The developers are great fans and all, but they are few and far between.

By the time iOS rolled around, GNUStep and Obj-C on Linux seemed completely dead and, with no pressing need to write software for a handheld on one platform and a desktop on another, it's stayed that way.

GNUStep missed the opportunity to cash in on more people working in Obj-C.

To me, GNUStep has always been a cool project but cripplingly behind. It's always moved at a glacial pace, even in comparison to Apple's glacial framework development pace. I think your excellent blog posts over time are evidence enough for this - it's always been behind with like Quartz and stuff, and nowadays it has just been slipping further and further. I think its stagnation also got wrapped up in that whole "freedom" wankery after iOS came out.

Very few things can be cleanly divided into two groups.

Group 3: Those who use it because they like the language itself and would happily target non-Apple platforms if it was a tenable solution.

I tried writing an Objective-C application intended for server-side deployment, but finding a Foundation library that worked was infuriating. The ones that compiled were not feature complete, and the ones that promised more were not maintained.

It really is a lot easier to write Objective-C code than C++ if you have access to all that Foundation and the associated frameworks provide, but getting it to compile for your target system is not exactly easy. Many of those components simply do not exist outside of OS X.

I'm not even concerned about GUI bindings, as I imagine those would be really awkward.

I feel ya. I've occasionally thought about server-side Obj-C, but usually dismiss it because I enjoy Python and Ruby so much. However, there are several ideas I'd like to build out for cross-platform desktop apps (for developers), and I really wish I could use Obj-C because I just flat-out enjoy programming with that language.

I've not encountered any substantial number of people who fit that description.

You just did.

Beyond that, encountering a 'substantial number' of them is irrelevant. I've not personally encountered a substantial number of people who like programming in Perl, but it is not inconceivable that such people exist.

This is why I finished my comment with this sentence:

"I'm sure there are exceptions, but not enough for GNUStep to get traction."

When we're talking about why GNUStep never took off, "substantial number" is highly relevant.

True. But that same sentiment can be communicated without trying to corral developers into two arbitrary groups. There are plenty of other reasons, in addition to the lack of a substantial number of Objective-C (not just iOS) developers. One of the reasons, I think, is a distinct lack of notability for GNUStep.

Anyway, this is a pretty silly line of disagreement. :)

But that's exactly what I've observed: nearly all ObjC developers fit into one of those two categories, and that's why roughly nobody wants to bother with GNUStep. I suppose I could have made some different point instead, but I'm generally going to make points about the stuff I've seen.

Perhaps the reason those ObjC fans of the language itself seem to be smaller in number by your metric is that there are other reasons for avoiding GNUStep--namely, that it's GNU. If you've grown up with OSX etc., then you're more likely to be BSD type person (thinking primarily from a licensing perspective here), and the FSF's push viral "software freedom" is a big turn-off.

Another excellent reason. I concur.

Category #1 doesn't really qualify as a "fan" by any definition I know, unless you similarly talk about people maintaining legacy web sites because there's money in it as "PHP fans".

And if category #2 really has total overlap with "ObjC fans" then I think you have a mistaken correlation in your statistics. You're measuring Apple developers, not people particularly enthused with Objective C as a language.

I think I agree with what the poster upthread was hinting at: ObjC is a fine language, but when compared to other more modern tools in the same space (C++, Java, C#, D, Go, maybe Haskell, etc...) it really doesn't have much to recommend it. People who tend to be language "fans" have more glittery toys to attract them.

"ObjC is a fine language, but when compared to other more modern tools in the same space (C++, Java, C#, D, Go, maybe Haskell, etc...) it really doesn't have much to recommend it."

Much simpler than C++. Much more dynamic than any of the languages you mention. Can use straight C anyplace you need performance, with no FFI. Finally has some decent syntax for JSON types (NSDictionary/Array/Number), which some of those languages have and some don't. Performant collection classes.

http://ridiculousfish.com/blog/posts/array.html

Block syntax (Java famously lacks, those other languages have some equivalent).

An outstanding UI library, unfortunately tied to Apple devices.

I think Objective-C has stood up brilliantly to the test of time. The potential for Ruby-like flexibility with C-like performance, it's not an accident the software behind Apple's rise to the most valuable company in the world (for a time), was written in Objective-C.

IMO the ability to transparently call into C is ObjC's only redeeming feature and pretty much the only reason I use it. You can get the performance and dynamism elsewhere (at the least, you can go for a different language built on the same runtime, like Nu), but you can't get the C elsewhere. The fact that ObjC is built on C is simultaneously the best and worst thing about it, as nearly all of the language's problems stem from that as well.

I disagree about it being there when Apple rose to power, though. I think it was an accident, like so many other accidents of history. NeXT provided Apple with a solid base for the future, but IMO they could have done it decently well with Be instead. The most important thing they got from Next was Steve Jobs. ObjC just happened to be in the right place at the right time to be chosen as the GUI programming language by NeXT, and NeXT just happened to be in the right place at the right time to leverage their technology into a takeover of Apple under the leadership of a guy who was ready to change the world.

In the alternate universe where Apple bought Be, Apple is dead because most programmers aren't smart enough to write GUI apps for Be's asynchronous model. They find it bad enough in Javascript's callback hell world- But doing that asynchronous Node.JS style stuff in C is a non-starter.

In the alternate universe where Apple bought Be, nobody can take advantage of most of the existing C libraries, because they were written expecting to be used in a synchronous programming model.

I don't think this would have worked. As cool as Be is, and as much as, fundamentally, it is a better operating system in most ways than NeXT. Be does things 'The Right Way'. But sadly, Worse is Better. You have to optimise for the programmers you have. not the ones you wish you had. Be was ahead of its time, and it's still ahead of its time.

Obj-C has the significant advantage of being a fairly thin layer over plain C so it's lightweight and easy to port. This means you can bootstrap it on a new platform pretty easily, write in a fairly high level language for most of your application code, and transparently drop down into C for performance.

Had it not been for mobile I think Obj-C would have quietly died out but it happens to embody a pretty good set of compromises for small, resource constrained devices. Recent developments like ARC and blocks make it a lot more pleasant to use now than it was even a few years ago.

Well, I think you know a lot more about this topic than me, but I would like to ask a follow up question.

Do you think Apple could have iterated as rapidly on iOS GUI applications, while keeping performance fast and resource usage low, if everything was written in C++? Java? C#? Objective C seems to hit a sweet spot for experimenting with innovative new UI concepts in a constrained hardware environment.

I think C++ would have done fine with a suitable toolkit, which presumably they would have built based on the stuff from Be, in my alternate history where Apple bought Be instead of NeXT but somehow still got Steve Jobs. Given the choice, I'd rather do a GUI framework in C++ than Objective-C, but I don't think it's that big of an advantage, at least if you can restrict yourself to a sane subset of C++.

Java... harder to say. I would say that no, Apple could not have done as good a job using Java as the basis of iOS, because Apple doesn't seem to be very good at the things needed to make a language like Java run fast. Perhaps if they had contracted out the right bits to Sun rather than pulling a Google and building their own VM, it could have worked OK.

I think that Objective-C is a pretty good language when you take into account the context of running on a UNIX system with lots of pre-built C libraries around, because of the ease of talking to C. Perhaps even the best choice, in that limited context. But I don't think much of Apple's rise can be attributed to that choice of language, even if it did end up being a decent one.

> I think C++ would have done fine with a suitable toolkit, which presumably they would have built based on the stuff from Be

BeOS, while a nice operating system, was notoriously difficult to program for, largely due to the use of an asynchronous API.

> because Apple doesn't seem to be very good at the things needed to make a language like Java run fast. Perhaps if they had contracted out the right bits to Sun rather than pulling a Google and building their own VM, it could have worked OK.

The "Apple" JVM pretty much is a licensed Sun JVM with extra bits. It's also of comparable speed to the Sun JVM; the performance gap between Apple Java 1.6 and Sun/Oracle Java 1.7 on a mac is comparable to that between Sun/Oracle 1.6 and 1.7 on Linux.

> But I don't think much of Apple's rise can be attributed to that choice of language, even if it did end up being a decent one.

Certainly not entirely. However, one advantage that iOS did have early on was that it wasn't totally horrible to write for, which had been a traditional affliction of smartphone OSes. Possibly they'd have come up with a decent C++ API, of course, but then again possibly they'd have come up with something like the Symbian API.

> Perhaps if they had contracted out the right bits to Sun

Or bought Sun, incorporated Solaris into Darwin. They had the cash.

I still dream of an alternative universe, where Apple kept Dylan alive through the lean years, Jobs came back and based OS X and the iPhone on it.

We were this close to having iPhone being a LispOS.

The apple software is not written in obj-c 'cause it gained traction by developers preference, it is written in obj-c 'cause Steve Jobs, after returning to apple post NeXT experience and buyback, imposed that as the only apple officially supported language.

Actually, C++ and Java had full support from Apple for GUI programming for a decade after the return of Steve.

C++ and Java were first-class languages in MacOS until quite recently; while the intent was always there to deprecate the C++ API (Carbon), the Java Cocoa bridge was dropped more due to lack of interest a couple of versions ago.

"I think there are plenty of ObjC fans, /but/ ObjC /developers/..."

Note the emphasis.

I'd love to target non-Apple platforms, but if I don't have the time to work on improving GNUStep. I suspect there are others in this camp. Until GNUStep catches up I'm fine with targeting OS X only if I need to write a native GUI application.

All Objective-C programmers I know are really iOS programmers trying to make a quick buck. Most of these people either aren't aware of GNUstep, or wouldn't care since they have OS X.

GNUstep is old. It predates the revival of Apple and the return of Steve Jobs. In the late '90s the Linux community declared war on Microsoft and decided the best way to destroy them would be to make a clone of Windows. Hence the focus on KDE and GNOME. Meanwhile, less attention was given to projects like Window Maker and GNUstep. IMO, the Linux community bet on the wrong horse. But then again, who the hell was using ObjC other than NeXT? No one, that's who. We may as well be talking about Tcl/Tk or Motif at that point. NeXT/GNUstep/ObjC were all seen as an obsolete curiosity. Kinda like Amiga was. So unfortunately, GNUstep never really gained momentum.

I must say, Window Maker was my preferred desktop up until 2006 or so. Before that, it was AfterStep. So yeah, I might be a bit bitter over the whole situation.

IMHO, WindowMaker only shares the enthusiasm of NeXTStep, and is not a project depending upon GNUStep. Actually WindowMaker was implemented in C, rather than ObjC, if my memory is accurate.

My outside read of the project is that it began losing steam long before iOS brought a large number of new ObjC developers. It was initially riding on the buzz around NeXT, which generated a lot of excitement around what the future of desktop computing might be (sort of parallel to the buzz around BeOS). And they got some ecosystem help; it was initially an implementation of the circa-1994 OpenStep specification. But NeXT enthusiasm waned through the latter part of the '90s.

I remember trying it around the same time as I tried Enlightenment 16, around 2001 or 2002, and at the time the user and development community felt quite small, much less active than E's.

I did some work on GNUStep, but it was painful. The development environment isn't very friendly and there isn't very good IDE support. Also, most of the documentation I saw was for Apple's stuff with very little for GNUStep.

I was eventually able to gain access to a Mac to be able to develop, and it made things much more easier.

Using Qt as a Cocoa stand-in sounds complicated. Since Darling already uses its own loader and syscall hooking to provide compatibility for the program, why not do the same for a framework like Cocoa?

Same type of deal as in Wine, copyright-type stuff.

there is hope that the decision in Oracle vs Google[0] on API's not being copyrightable might change that

[0] http://en.wikipedia.org/wiki/Oracle_v._Google

I think zw meant that the Cocoa binaries can't be distributed with Darling. That's not a major problem for users that have a copy of OS X. Darling can allow users to supply their own.

The potential issue you refer to would also prevent implementing the Cocoa API with Qt.

Reminds me of Win32 emulation layer for OS/2 which had Quake 2 as target application :)

The given reason for that is that it is a popular game that has no native version (so no one will ask why he is porting Midnight Commander) and it does not use much OS X API. It uses OpenGL, OpenAL, IOKit (for finding input devices), AppKit (creating window), CGL (for configuring OpenGL) and CoreVideo (for running main loop).

That was Odin32, right? I remember looking forward to that, and hoping that it would be better than the win32s extensions for 3.11 (plus the .dll whack-a-mole that entailed), but in the end I just switched from OS/2 to XP.