5 ms·

This is a wonderful bit of history, really grateful to have it. I remember reading an interview with Steve Jobs in Wired magazine in the 90s where he talked abo

by gdubs 6y ago

This is a wonderful bit of history, really grateful to have it. I remember reading an interview with Steve Jobs in Wired magazine in the 90s where he talked about the future being all about Objects – "The Next Insanely Great Thing" [1]. I built my career on top of Objective-C. These days I really enjoy Swift, but I still have a space in my heart for the dynamic beauty of Objective-C. 1: https://www.wired.com/1996/02/jobs-2/ https://www.wired.com/1996/02/jobs-2/

jrochkind1 6y ago
Ruby is probably one of the current languages most like ObjC in it's bones, at least in certain dimensions, due to them both being so influenced by smalltalk. But ruby isn't necessarily doing great as far as market share either. :(
- gdubs 6y ago
  It's been a while since I've used it, but before I made native apps I had a little web development business going, and used Ruby on Rails extensively. I couldn't articulate the similarities at the time with ObjC, but looking back I'm sure it had a lot to do with my comfort working in Ruby. And, I credit that web work I did in Ruby with my becoming a better programmer. Being able to drop in to low-level C for real-time applications (audio, in my case) was a great aspect of ObjC. Though there were plenty of times I wished I could program in ObjC in the real-time threads. There were many debates on the Core Audio forums about whether ObjC was safe in real-time threads. Most of Core Audio was developed by C++ programmers, and their default was to avoid ObjC out of a fear that a surprise lock or memory allocation would glitch out the audio. There was, however, at least one NeXT veteran on the forums who felt this was nonsense, and recalled writing device drivers in ObjC.
  - mpweiher 6y ago
    > one NeXT veteran on the forums who felt this was nonsense, and recalled writing device drivers in ObjC So did I. https://www.nextop.de/NeXTstep_3.3_Developer_Documentation/OperatingSystem/Part3_DriverKit/Concepts/1_Overview/Overview.htmld/ https://www.nextop.de/NeXTstep_3.3_Developer_Documentation/O... It was quite lovely, and I later heard from Apple kernel devs that moving to C++ from Objective-C was one of their biggest regrets.
    - pjmlp 6y ago
      Apparently they did not regret enough, because DriverKit was the opportunity to reboot that decision, and it was decided to still be C++ only.
  - PaulDavisThe1st 6y ago
    It isn't a "fear" - it's avoidance of demonstrated behavior. You cannot use any GC-based language if you want to guarantee an upper bound on latency. You cannot use any language that uses global or even large-scope locks if you want to guarantee an upper bound on latency. It has nothing to do with "writing device drivers" - there are plenty of device drivers for which latency is not anything like the issue that it is for audio.
    - 1over137 6y ago
      >You cannot use any GC-based language if you want to guarantee an upper bound on latency ObjC wasn't then and isn't now an GC-based language.
      - jolux 6y ago
        Ignoring the problem with calling something a “GC-based” language, Objective-C is most typically used with ARC these days, which is definitely GC.
        deleted 6y ago
        [deleted]
        snuxoll 6y ago
        Reference counting is still not garbage collection. ARC causes the compiler to implicitly insert calls to retain and release, that’s it. Everything is still 100% deterministic at runtime.
        jolux 6y ago
        It’s not tracing GC, but it’s well-known as a garbage collection algorithm: https://en.wikipedia.org/wiki/Reference_counting#Garbage_collection https://en.wikipedia.org/wiki/Reference_counting#Garbage_col...
        PaulDavisThe1st 6y ago
        It's not deterministic because you don't know the timing relationship between threads which may drop references. The only sense in which it is deterministic is that "when the reference count reaches zero, the object will be destroyed". That's a long way from the determinism of manual/explicit memory management. It gets even worse if there are per-thread pools in use, though to be fair, this is mostly an application design issue rather than a language one.
- ksec 6y ago
  Well Objective-C wasn't doing well before iPhone. Then the smartphone revolution started and you are all forced to use it. Ruby also never had much if any cooperate backing. MRI / CRuby is still by and large improved by people in their free time. It wasn't until the past 2 may be 3 years did Github and Shopify had some interest in the Ruby Runtime.
  - pjmlp 6y ago
    In US, because plenty of us were already using J2ME, Brew and Symbian C++ before iPhone happened.
pixelrevision 6y ago
Swift is great but is starting to suffer from feature bloat. I really loved the simplicity of objective-c. If you can get past the syntax you find a very thin wrapper on top of c that lets you do really fun things. I don’t think I’ve ever seen another language where people followed the same patterns so consistently either.
- justinmeiners 6y ago
  > where people followed the same patterns so consistently so true. This is one ecosystem where you could actually just include another persons code as if it was yours, and get a great understanding of how to use it from a header.
- carlosrg 6y ago
  All modern languages tend to suffer from feature bloat - there's this obsession of covering every single edge use case, every possible paradigm. C#, Swift, Rust, Python, even C++, all are in this competition dynamic where they want to natively support everything the others do. It's very tiring to keep up, and it's a quick way to end up with a buggy unmaintainable mess of a language.

by gdubs 6y ago

jrochkind1 6y ago

Ruby is probably one of the current languages most like ObjC in it's bones, at least in certain dimensions, due to them both being so influenced by smalltalk. But ruby isn't necessarily doing great as far as market share either. :(

gdubs 6y ago
It's been a while since I've used it, but before I made native apps I had a little web development business going, and used Ruby on Rails extensively. I couldn't articulate the similarities at the time with ObjC, but looking back I'm sure it had a lot to do with my comfort working in Ruby. And, I credit that web work I did in Ruby with my becoming a better programmer. Being able to drop in to low-level C for real-time applications (audio, in my case) was a great aspect of ObjC. Though there were plenty of times I wished I could program in ObjC in the real-time threads. There were many debates on the Core Audio forums about whether ObjC was safe in real-time threads. Most of Core Audio was developed by C++ programmers, and their default was to avoid ObjC out of a fear that a surprise lock or memory allocation would glitch out the audio. There was, however, at least one NeXT veteran on the forums who felt this was nonsense, and recalled writing device drivers in ObjC.
- mpweiher 6y ago
  > one NeXT veteran on the forums who felt this was nonsense, and recalled writing device drivers in ObjC So did I. https://www.nextop.de/NeXTstep_3.3_Developer_Documentation/OperatingSystem/Part3_DriverKit/Concepts/1_Overview/Overview.htmld/ https://www.nextop.de/NeXTstep_3.3_Developer_Documentation/O... It was quite lovely, and I later heard from Apple kernel devs that moving to C++ from Objective-C was one of their biggest regrets.
  - pjmlp 6y ago
    Apparently they did not regret enough, because DriverKit was the opportunity to reboot that decision, and it was decided to still be C++ only.
- PaulDavisThe1st 6y ago
  It isn't a "fear" - it's avoidance of demonstrated behavior. You cannot use any GC-based language if you want to guarantee an upper bound on latency. You cannot use any language that uses global or even large-scope locks if you want to guarantee an upper bound on latency. It has nothing to do with "writing device drivers" - there are plenty of device drivers for which latency is not anything like the issue that it is for audio.
  - 1over137 6y ago
    >You cannot use any GC-based language if you want to guarantee an upper bound on latency ObjC wasn't then and isn't now an GC-based language.
    - jolux 6y ago
      Ignoring the problem with calling something a “GC-based” language, Objective-C is most typically used with ARC these days, which is definitely GC.
      - deleted 6y ago
        [deleted]
      - snuxoll 6y ago
        Reference counting is still not garbage collection. ARC causes the compiler to implicitly insert calls to retain and release, that’s it. Everything is still 100% deterministic at runtime.
        jolux 6y ago
        It’s not tracing GC, but it’s well-known as a garbage collection algorithm: https://en.wikipedia.org/wiki/Reference_counting#Garbage_collection https://en.wikipedia.org/wiki/Reference_counting#Garbage_col...
        PaulDavisThe1st 6y ago
        It's not deterministic because you don't know the timing relationship between threads which may drop references. The only sense in which it is deterministic is that "when the reference count reaches zero, the object will be destroyed". That's a long way from the determinism of manual/explicit memory management. It gets even worse if there are per-thread pools in use, though to be fair, this is mostly an application design issue rather than a language one.
ksec 6y ago
Well Objective-C wasn't doing well before iPhone. Then the smartphone revolution started and you are all forced to use it. Ruby also never had much if any cooperate backing. MRI / CRuby is still by and large improved by people in their free time. It wasn't until the past 2 may be 3 years did Github and Shopify had some interest in the Ruby Runtime.
- pjmlp 6y ago
  In US, because plenty of us were already using J2ME, Brew and Symbian C++ before iPhone happened.

pixelrevision 6y ago

Swift is great but is starting to suffer from feature bloat. I really loved the simplicity of objective-c. If you can get past the syntax you find a very thin wrapper on top of c that lets you do really fun things. I don’t think I’ve ever seen another language where people followed the same patterns so consistently either.

justinmeiners 6y ago
> where people followed the same patterns so consistently so true. This is one ecosystem where you could actually just include another persons code as if it was yours, and get a great understanding of how to use it from a header.
carlosrg 6y ago
All modern languages tend to suffer from feature bloat - there's this obsession of covering every single edge use case, every possible paradigm. C#, Swift, Rust, Python, even C++, all are in this competition dynamic where they want to natively support everything the others do. It's very tiring to keep up, and it's a quick way to end up with a buggy unmaintainable mess of a language.