5 ms·

Which is very sad, because there are hidden gems in GnuStep and Etoile in the form of Obj-C runtime and Language Kit Runtime respectively. It could have served

Which is very sad, because there are hidden gems in GnuStep and Etoile in the form of Obj-C runtime and Language Kit Runtime respectively. It could have served as a platform to develop and run dynamic languages, with support at OS level. But OSS community hardly paid attention to these llvm backed runtimes.

protomyth 8y ago
They only dropped Java after being validated that Mac developer community was fine with Objective-C. They dropped Java because it was obvious that Java couldn’t handle they dynamic nature of the Cocoa framework. It was a horrible fit.
- cmiles74 8y ago
  I put a couple applications together that worked with the Java bridge to get Java code updating a Cocoa UI and it felt kind of hacky even at the time.
- pjmlp 8y ago
  I bet that if the Mac OS developers had eschewed Objective-C, Apple would had fix all the ongoing issues with the Java bridge. Also we shouldn't forget that Java semantics and execution model are closer to Objective-C than C++, thanks to OpenSTEP project collaboration.
  - protomyth 8y ago
    > Apple would had fix all the ongoing issues with the Java bridge I really don't think they could have given the non-dynamic nature of Java. That part missing from Java's semantics and execution model is pretty critical and would only be added to the JVM much, much later. I have to agree with cmiles about the "hacky" nature of the bridge.
    - pjmlp 8y ago
      Dynamic loading, interfaces, bundles, reflection was already there in those Java versions. The only things I can recall not being there aren't that well supported by Swift as well, regarding dynamic patching classes, missing method handling, swizzling and such.
      - protomyth 8y ago
        Categories were missing and viewing all the challenges JRuby had to work through is a good start for the problems with trying to duplicate Objective-C functionality.
        pjmlp 8y ago
        Yes, I forgot about categories. Regarding JRuby, most of the issues were related to translating Ruby code into JVM semantics. Doing FFI to external Objective-C is a bit different.
  - zeveb 8y ago
    I really, sincerely doubt that even Apple with all its capital could fix all the issues with Java. At heart, it's just not a good language. You can get work done in it, slowly and painfully, paying a great deal of money to a great number of code monkeys. But it's an embarrassingly bad language.
    - pjmlp 8y ago
      That is a matter of opinion. I could never get over typing @ and [] everywhere and typing retain/release by hand. In fact my biggest contact with Objective-C was to port a particle simulation framework from NeXTSTEP into Windows and C++. Thankfully there is Swift now.
      - zeveb 8y ago
        Oh, I'm not going to take a position on Objective-C vice Java (I have some residual fondness for the former, from back in the 90s, but never really used it in anger) — only on the fact (well, in my opinion it's a fact) that Java is in bad taste.

protomyth 8y ago

They only dropped Java after being validated that Mac developer community was fine with Objective-C. They dropped Java because it was obvious that Java couldn’t handle they dynamic nature of the Cocoa framework. It was a horrible fit.

cmiles74 8y ago
I put a couple applications together that worked with the Java bridge to get Java code updating a Cocoa UI and it felt kind of hacky even at the time.
pjmlp 8y ago
I bet that if the Mac OS developers had eschewed Objective-C, Apple would had fix all the ongoing issues with the Java bridge. Also we shouldn't forget that Java semantics and execution model are closer to Objective-C than C++, thanks to OpenSTEP project collaboration.
- protomyth 8y ago
  > Apple would had fix all the ongoing issues with the Java bridge I really don't think they could have given the non-dynamic nature of Java. That part missing from Java's semantics and execution model is pretty critical and would only be added to the JVM much, much later. I have to agree with cmiles about the "hacky" nature of the bridge.
  - pjmlp 8y ago
    Dynamic loading, interfaces, bundles, reflection was already there in those Java versions. The only things I can recall not being there aren't that well supported by Swift as well, regarding dynamic patching classes, missing method handling, swizzling and such.
    - protomyth 8y ago
      Categories were missing and viewing all the challenges JRuby had to work through is a good start for the problems with trying to duplicate Objective-C functionality.
      - pjmlp 8y ago
        Yes, I forgot about categories. Regarding JRuby, most of the issues were related to translating Ruby code into JVM semantics. Doing FFI to external Objective-C is a bit different.
- zeveb 8y ago
  I really, sincerely doubt that even Apple with all its capital could fix all the issues with Java. At heart, it's just not a good language. You can get work done in it, slowly and painfully, paying a great deal of money to a great number of code monkeys. But it's an embarrassingly bad language.
  - pjmlp 8y ago
    That is a matter of opinion. I could never get over typing @ and [] everywhere and typing retain/release by hand. In fact my biggest contact with Objective-C was to port a particle simulation framework from NeXTSTEP into Windows and C++. Thankfully there is Swift now.
    - zeveb 8y ago
      Oh, I'm not going to take a position on Objective-C vice Java (I have some residual fondness for the former, from back in the 90s, but never really used it in anger) — only on the fact (well, in my opinion it's a fact) that Java is in bad taste.