5 ms·

How so? You probably don't understand the context of mid-90s free and open software. Nothing is free, nothing open, relevant business models do not yet exist.

How so? You probably don't understand the context of mid-90s free and open software. Nothing is free, nothing open, relevant business models do not yet exist. Few things that are open barely work: linux takes hours to compile-tweak-recompile, all the tools are half-baked and semi-broken. You had to fix most things yourself. Anyways, the only tools that do work reliably and have no license issues are coming from FSF: Emacs, gcc, unix utils, etc. Note that objC was not free, and the free version sucked most of the time. GCC did have world-class support for C though. C was and still is a good choice for a core portable cross-language library. But UIs are probably the only programming context where OOP fits well. So people came with Gobject. It all makes total sense, and that's why the whole thing survives to this very day.

pavlov 4y ago
> “C was and still is a good choice for a core portable cross-language library. But UIs are probably the only programming context where OOP fits well. So people came with Gobject.” That’s my exact criticism: they came up with GObject instead of using the C-based solution that already existed, had open source compiler support, and was actively developed by Apple. The GTK community made a huge mistake in trying to turn GIMP’s poor design into a generic GUI framework rather than collaborating with GNUstep on creating a next-generation framework.
- pjmlp 4y ago
  Apple would never collaborated with GNUStep, first of all, when GNUStep started NeXT was still around. Secondly, Steve Jobs wasn't an happy fellow about the whole story regarding GCC request to get back the frontend changes into upstream. Gtk OOP is actually a clone of Motif OOP, which Gtk was cloning in first place.
  - pavlov 4y ago
    They wouldn’t have needed Apple’s collaboration to build a new UI framework on Obj-C, just like nobody needed SCO’s permission to build Linux. GTK’s two original sins were 1) cloning Motif in the first place, 2) doubling down on that design instead of throwing away GIMP as the prototype that it was. They’ve been forever reliving the 1990s due to these bad choices.
    - vkazanov 4y ago
      Yet here they are, alive and kicking, while objc is gone, motif gone, etc. Long live gnome, long live gimp, long live gtk!
      - pavlov 4y ago
        If you’re happy with this also-ran forever-4th-place-in-everything outcome, good for you. Long live the king of the desert island. It could have been a lot more though.
      - torstenvl 4y ago
        Gone? There are several orders of magnitude more users of Obj-C software than there are users of Gnome.
  - mananaysiempre 4y ago
    > Gtk OOP is actually a clone of Motif OOP And it has the characteristic GNU Lisp-envy-in-C (gnu_lisp_envy_in_c ()) flavour. And the GNU Network Object Model Environment (GNOME) developers were (with Bonobo et al.) copying COM, if anything. How did that even happen?
    - pjmlp 4y ago
      Miguel de Icaza has always been a fan from Microsoft technologies, that is how Bonobo happened.
    - kazinator 4y ago
      All ways of doing OOP in C will tend to resemble each other, if they are reasonably easy to use for a C programmer, without heaps of macros or code generation. Anyway, COM is based on Microsoft RPC which is an implementation of DCE/RPC with extensions. https://en.wikipedia.org/wiki/Microsoft_RPC https://en.wikipedia.org/wiki/Microsoft_RPC
      - mananaysiempre 4y ago
        I don’t know. I mean, even classic Win32 has around two and a half object systems: windows+messages, standard COM, and IDispatch{,Ex}; and they are all rather different. (IDispatch and IDispatchEx, while a bit different from each other, are also neither particularly easy to use from C nor particularly good at their original purpose[1], so I’m counting them as half a system.) Then there is Objective-C... OK, I don’t know that it’s that usable without a preprocessor, but there are Piumarta’s id[2] and Finch’s cobj[3], which are reasonably different from either of the Win32 systems. (I don’t know to which degree DCE is relevant to COM in this comparison, given that in the intraprocess case all it inherits from there is the IDL and the non-exposed wire format when marshalling between apartments. Technically RPCRT4.DLL does contain obvious counterparts of DCE functions, but I haven’t yet found any Microsoft documentation suggesting you actually use those for anything.) [1] https://ericlippert.com/2003/09/16/why-do-the-script-engines-not-cache-dispatch-identifiers/ https://ericlippert.com/2003/09/16/why-do-the-script-engines... [2] https://piumarta.com/software/id-objmodel/ https://piumarta.com/software/id-objmodel/ [3] https://dotat.at/@/2007-04-16-awash-in-a-c-of-objects.html https://dotat.at/@/2007-04-16-awash-in-a-c-of-objects.html
- vkazanov 4y ago
  1st, you're ignoring the fact that this c-based solution was not well-supported back then. 2nd, objective c is dead now. It was not a good long-term solution. 3rd, everybody and their cat knew C, while objc was a niche back then. How is that a good choice for anything non-mac?!
  - Dylan16807 4y ago
    > 2nd, objective c is dead now. It was not a good long-term solution. How much is GObject used outside of GTK? Isn't that a hundred times deader? The current number of Objective C users is not directly relevant to this comparison. The comparison pavlov made is to a hypothetical situation where GTK (or whatever you call it) was based on Objective C. If that had happened, GTK's object model would be much less 'dead'. In that hypothetical world, it would still be sad to see Apple leave, but that world would have far more Objective C users than the current world has GObject users.
- scythe 4y ago
  But see also what happened with Qt and its license issues. That didn't happen with Objective-C, but nobody could predict the future at the time. There are some advantages to controlling your stack. Also, pointing at GIMP's UI seems a little exaggerated, when the primary difficulty was keeping track of all the floating windows. GIMP seemed to have been designed in anticipation of a major advancement in window managers (not just tiling, but size-aware) that never materialized (the irregular packing problem is NP-Hard). Other Gtk apps never had this problem, and GIMP eventually switched to panes, thankfully.

pavlov 4y ago

> “C was and still is a good choice for a core portable cross-language library. But UIs are probably the only programming context where OOP fits well. So people came with Gobject.” That’s my exact criticism: they came up with GObject instead of using the C-based solution that already existed, had open source compiler support, and was actively developed by Apple. The GTK community made a huge mistake in trying to turn GIMP’s poor design into a generic GUI framework rather than collaborating with GNUstep on creating a next-generation framework.

pjmlp 4y ago
Apple would never collaborated with GNUStep, first of all, when GNUStep started NeXT was still around. Secondly, Steve Jobs wasn't an happy fellow about the whole story regarding GCC request to get back the frontend changes into upstream. Gtk OOP is actually a clone of Motif OOP, which Gtk was cloning in first place.
- pavlov 4y ago
  They wouldn’t have needed Apple’s collaboration to build a new UI framework on Obj-C, just like nobody needed SCO’s permission to build Linux. GTK’s two original sins were 1) cloning Motif in the first place, 2) doubling down on that design instead of throwing away GIMP as the prototype that it was. They’ve been forever reliving the 1990s due to these bad choices.
  - vkazanov 4y ago
    Yet here they are, alive and kicking, while objc is gone, motif gone, etc. Long live gnome, long live gimp, long live gtk!
    - pavlov 4y ago
      If you’re happy with this also-ran forever-4th-place-in-everything outcome, good for you. Long live the king of the desert island. It could have been a lot more though.
    - torstenvl 4y ago
      Gone? There are several orders of magnitude more users of Obj-C software than there are users of Gnome.
- mananaysiempre 4y ago
  > Gtk OOP is actually a clone of Motif OOP And it has the characteristic GNU Lisp-envy-in-C (gnu_lisp_envy_in_c ()) flavour. And the GNU Network Object Model Environment (GNOME) developers were (with Bonobo et al.) copying COM, if anything. How did that even happen?
  - pjmlp 4y ago
    Miguel de Icaza has always been a fan from Microsoft technologies, that is how Bonobo happened.
  - kazinator 4y ago
    All ways of doing OOP in C will tend to resemble each other, if they are reasonably easy to use for a C programmer, without heaps of macros or code generation. Anyway, COM is based on Microsoft RPC which is an implementation of DCE/RPC with extensions. https://en.wikipedia.org/wiki/Microsoft_RPC https://en.wikipedia.org/wiki/Microsoft_RPC
    - mananaysiempre 4y ago
      I don’t know. I mean, even classic Win32 has around two and a half object systems: windows+messages, standard COM, and IDispatch{,Ex}; and they are all rather different. (IDispatch and IDispatchEx, while a bit different from each other, are also neither particularly easy to use from C nor particularly good at their original purpose[1], so I’m counting them as half a system.) Then there is Objective-C... OK, I don’t know that it’s that usable without a preprocessor, but there are Piumarta’s id[2] and Finch’s cobj[3], which are reasonably different from either of the Win32 systems. (I don’t know to which degree DCE is relevant to COM in this comparison, given that in the intraprocess case all it inherits from there is the IDL and the non-exposed wire format when marshalling between apartments. Technically RPCRT4.DLL does contain obvious counterparts of DCE functions, but I haven’t yet found any Microsoft documentation suggesting you actually use those for anything.) [1] https://ericlippert.com/2003/09/16/why-do-the-script-engines-not-cache-dispatch-identifiers/ https://ericlippert.com/2003/09/16/why-do-the-script-engines... [2] https://piumarta.com/software/id-objmodel/ https://piumarta.com/software/id-objmodel/ [3] https://dotat.at/@/2007-04-16-awash-in-a-c-of-objects.html https://dotat.at/@/2007-04-16-awash-in-a-c-of-objects.html
vkazanov 4y ago
1st, you're ignoring the fact that this c-based solution was not well-supported back then. 2nd, objective c is dead now. It was not a good long-term solution. 3rd, everybody and their cat knew C, while objc was a niche back then. How is that a good choice for anything non-mac?!
- Dylan16807 4y ago
  > 2nd, objective c is dead now. It was not a good long-term solution. How much is GObject used outside of GTK? Isn't that a hundred times deader? The current number of Objective C users is not directly relevant to this comparison. The comparison pavlov made is to a hypothetical situation where GTK (or whatever you call it) was based on Objective C. If that had happened, GTK's object model would be much less 'dead'. In that hypothetical world, it would still be sad to see Apple leave, but that world would have far more Objective C users than the current world has GObject users.
scythe 4y ago
But see also what happened with Qt and its license issues. That didn't happen with Objective-C, but nobody could predict the future at the time. There are some advantages to controlling your stack. Also, pointing at GIMP's UI seems a little exaggerated, when the primary difficulty was keeping track of all the floating windows. GIMP seemed to have been designed in anticipation of a major advancement in window managers (not just tiling, but size-aware) that never materialized (the irregular packing problem is NP-Hard). Other Gtk apps never had this problem, and GIMP eventually switched to panes, thankfully.