Hacker News new | past | comments | ask | show | jobs | submit login

GIMP development started in 1995. The GNU Objective C frontend (the one that has stayed in use) started in 1993.

I would hardly consider the GIMP developers (who became the early developers of GTK) to be rash in their option not to adopt a language that had only been available for a couple of years in the open source world.

And all these years later, at a time when Apple has essentially abandoned Objective C, GTK and Glib continue to provide bindings for dozens of languages to create cross-platform GUI applications, and even if many of us don't agree with the direction(s) it has taken, GTK itself has continued to evolve, whereas UI libraries that came with Objective C have become frozen in time.

So in short, not really a tragedy at all.




Apple has not abandoned Objective C. It still has first class support on all their platforms, and the vast majority of their OS frameworks and applications are developed in ObjC. Swift is growing as an internal tool, but it’s nowhere near even 50% of the 1st party code on a mac or iphone.

Improvements have slowed on ObjC, as Apple’s focus switched to swift - ObjC 2.0 in 2014 was the last major change.


Also the most popular iOS third-party apps are all Obj-C[++].

The C++ interop is very important for companies like Meta. They have no incentive to rewrite anything in Swift.

If you look at minutes spent by end users on the iOS platform, I’m guessing it’s at least 95% inside Obj-C apps today.


Which is exactly why Apple showed the following at WWDC 2022, just to make it clear that the time for Objective-C is done.

https://developer.apple.com/videos/play/wwdc2022/102/

> The Objective-C language, AppKit & UIKit frameworks, and Interface Builder have empowered generations of developers. These technologies were built for each other, and will continue to serve us well for a long time to come, but over time new abstractions become necessary. For a while now, you've seen us hard at work defining the next generation of integrated language, frameworks, and tools: Swift, SwiftUI, and Xcode Previews.

> Tight integration in a development platform like this requires that all three pieces be designed and evolved together, both driving and driven by one another. Swift result builders were inspired by SwiftUI's compositional structure. SwiftUI's declarative views were enabled by Swift value types. And Xcode Previews was specifically designed for, and enabled by, both. Now, the result is the best development platform that we have ever built. And this year, Swift, SwiftUI, and Xcode all have fantastic updates that take this vision further, and make it even easier for you to build great apps for all of our platforms. And it all starts with Swift.


Nah. I’ll believe it when I see it.

Only when Apple comes out with a flagship app written in Swift (I would require SwiftUI too, but I don’t want to be that cruel…) will I entertain the idea that ObjC can be replaced. If they were eating their own dogfood internally, they should be aware that it is nowhere near ready for AAA app development.


watchOS comes to mind.

On Ventura several systems apps have been rewritten, including the preferences panel.


Those are not exactly the flagship apps I was talking about.


A complete platform used by millions of people, and apparently has saved several lives as per this week's announcement, doesn't count as flagship, got it.


It's like saying Tizen is flagship because it's used in millions of Samsung TVs.


> I would hardly consider the GIMP developers (who became the early developers of GTK) to be rash in their option not to adopt a language that had only been available for a couple of years in the open source world.

I think you misunderstood the criticism. They didn't say GIMP used the wrong model when it started, they said the greater community was wrong for copying GIMP later on.

> And all these years later, at a time when Apple has essentially abandoned Objective C, GTK and Glib continue to provide bindings for dozens of languages to create cross-platform GUI applications, and even if many of us don't agree with the direction(s) it has taken, GTK itself has continued to evolve, whereas UI libraries that came with Objective C have become frozen in time.

The suggestion is that Objective C should have been used instead of GObject. That doesn't mean having to use any particular libraries. And the same work to bind and evolve could have been poured into any reasonably solid library.


They did not copy GIMP, they literally extracted the widget code out of GIMP (and with it the object model) and made it into an independent toolkit. At the time there was no decent free toolkit at all, people were trying to reimplement Motif (Lesstif) or Qt (Harmony) but GIMP's was the first free software toolkit for X11.

Then over time it was extended beyond widgets, and the tooling around it grew to focus on exporting introspection information for language bindings.


My guess is that you can't point to a single example of a library written in ObjC that has any other language bindings, and if you can, it is barely used by anyone. The GTK community always made the idea of language bindings a central part of their development ethos.


> GIMP development started in 1995. The GNU Objective C frontend (the one that has stayed in use) started in 1993. I would hardly consider the GIMP developers (who became the early developers of GTK) to be rash in their option not to adopt a language that had only been available for a couple of years in the open source world.

Early in 1997, Guillaume Laurent and I spent some time looking into Objective C as a possible language for the "next version" of the Rosegarden sequencer on Unix/X11. At the time Rosegarden was a C application[1] using Athena widgets with my own little styling library, and we were sure there must be better options and were prepared to rewrite the UI entirely if we had to.

We ended up ruling it out for a few reasons, which I've just looked up in old email archives. I had some trouble getting the then-new gcc Objective C runtime working across Unix systems (we didn't only target Linux) and feared that we wouldn't be able to give our code to someone else and have them compile it easily. We couldn't find a working graphical toolkit: we thought GNUstep wasn't ready and also that it was probably going to be overkill. Other possibilities like NSXKit[2] weren't there either. Guillaume experimented with writing a toolkit himself but quickly ran into various obstacles that I don't have a record of.

(What is striking in hindsight is how hard it was to find reliable information to help us make a decision like this. There was documentation, and there were opinions, but there was very little of the form "we used this for our project and here's how it worked" that you would begin to see after blogging had become commonplace. We worked mostly on supposition and projection - install something, see if we could get it to build at all, spend a couple of hours with it and make guesses based on that, as well as on external info such as how much we knew about the developers that worked on it.)

So we switched to C++ instead. Considered Qt, argued about it, looked at LessTif, then GTK, then contributed a bit to gtkmm, then after a couple of years of nominally using gtkmm and getting nothing done, we switched to Qt after all and were happy. Happy-ish.

Even for people who really liked Objective C in 1997, it was pretty hard to make a case for. Maybe an open source company with staff and capital could have, but they barely existed.

[1] https://all-day-breakfast.com/cannam/x11-rosegarden/rosegard...

[2] http://www.hardcoreprocessing.com/home/anoq/Programming/GNUS...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: