GIMP 3.2 Will Aim To Be Out Within One Year Of GIMP 3.0

[Jumbotron]

It's called Krita

LOL...I'm embarrassed for you.

[caligula]

Thanks for that. I suspected that might be the case. In principle, if the binding exists, you can use a GUI toolkit from any language (Python is used (!)), so it is just down to ease-of-use/productivity, in which case, using an OO language with an toolkit written in an OO language probably has the least 'impedance'. There's also an academic debate that could be had over whether 'pure' OO is sufficient/ideal for programming a GUI, depending on what someone defines as 'pure' OO (I don't want to go there - I have no wish to participate in a religious war, but it is sometimes interesting to watch from afar).
No matter what, when someone describes something as 'crazy', there's usually something going on. People do apparently crazy things for reasons that appear good to them, so understanding why can sometimes lead to useful insights. Thanks for the reply.

Well, there are many issues when doing GUI in C:

- First, the data and control abstractions are quite poor. C is not a strongly typed language. Yes that's an issue. Almost all current languages are moving towards strong typing (e.g. type hints in Python and PHP, JS -> TS, Rust, C++, Java, Julia, etc.). The compilers do various kinds of checks and optimizations regarding the objects and classes in OOP languages. JIT compilers can even optimize virtual calls. The memory layout is pretty optimized - see how compact the objects are in forthcoming Java 24. Other keywords here are encapsulation, class invariants, pre and post conditions, virtual tables, traits and other forms of multiple inheritance, generic classes and variance of generic data types. C doesn't even support easily expressing basic function signatures. It's quite common to see void* pointers instead.

- GUI programming involves handling resources. C++'s RAII, Rust's ownership types (affine types) solve some issues. Higher level languages have things like autocloseables and garbage collectors. Somewhat related, GUI often involves threads and asynchronous programming. That's also very verbose and error prone in C. Unfortunately threads are problematic in many other languages as well, but people are slowly learning. Another huge issue is the memory model. People also benefit from higher level thread abstractions like thread pools, executors, etc. They all involve special rules that cannot be expressed in C. C simply isn't the right language for this unless it will be revised in the future version.

- There are also issues with OOP as a paradigm for defining GUIs. Sometimes people want expressive DSLs (e.g. QML), sometimes reactive programming, sometimes functional stuff. Sometimes even plain C is better at expressing stuff like tables than OOP languages. OOP doesn't provide any meaningful abstractions other than encapsulation. Most of the GUI abstractions are design patterns on top of objects. These can be expressed in other ways in other paradigms. Just take a look at Haskell school of expression, a book from 1999.

Yes, the only benefit of using C is that language bindings are doable, but I'm not sure if this is a useful goal. We could just use native high level GUI libraries instead.