A brief history of primary coding languages
16 comments
·July 19, 2025spacedcowboy
JKCalhoun
I'm sort of with you. But we must be old. All the "kids" that came on board Apple as I was heading out loved Swift.
I liked Swift up until some of the "kids" started using esoteric features of it that bent my mind. I know from experience that everything that looks odd at first will, one day, become second nature.
But as I say, perhaps like me, you're old. Because I'm just getting a little tired of waiting for my bent mind to straighten out.
It was amusing reading the article. MPW, THINK Pascal, THINK C, Objective-C, Swift ... yep, over the nearly 40 years of my career I have known them all.
"For I have known them all already, known them all:
Have known the evenings, mornings, afternoons,
I have measured out my life with coffee spoons;"
sumuyuda
You should check out Darling if you like Objective-C and Apple/macOS development. It is implementing a macOS translation layer on Linux. There is lots of work needed implementing Apple’s frameworks in Objective-C.
dlivingston
What a cool project. I looked through your repo and it's very well done. Your code is very pleasant to read [0]. I wish I had the background knowledge and bandwidth to help. What do you think of SwiftUI, by the way?
[0]: https://github.com/ThrudTheBarbarian/Azoth/blob/main/Azoth/C...
spacedcowboy
Why, thank you, fellow human :)
SwiftUI is probably awesome :), but I myself find the declarative style of programming to be harder to grok than the imperative style. This is probably just because I’m so used to imperative-style programming, and it’s probably (?) easier for those without huge experience in software engineering to understand. Personally, though, I find it’s a cognitive barrier, not an aide - I didn’t really prefer QML over the C++ Qt library either…
jcranmer
> It pretty much manages memory for you with ARC,
Objective-C added ARC relatively late, about 2010 or 2011 or so, and giving people a decade to stew with manual memory management isn't going to endear people to your language, especially when your competitors (C++, Java) have something, even if not great (the less said about std::auto_ptr, the better).
> ObjC added about two dozen keywords to C and was rejected by the masses for use of [] insteqd of (). Is it really massively different to type:
The square brackets are a vestige of Smalltalk, and it gives Objective-C a feeling of someone smashing Smalltalk into C and not really caring about the consequences. And it really doesn't help that Smalltalk itself had a pretty poor reputation by that point in time.
ofalkaed
>GNUstep
How functional is this? It looks great but does not seem to get much use, is that just a popularity contest thing or does it have issues? Since it can compile any C code (up to what standard?) Does that mean we can mostly use C libraries? Are there issues with interfacing the C libraries with objc objects? Any good linux directed resources for learning objc/GNUstep?
spacedcowboy
GNUstep is actually great, but it’s been around for a long time, and has some baggage because of that - which means you want the right (modern) setup, and not every Linux distribution provides the correct combination. You get Arc, you get blocks, you get everything that ObjC can offer (apart from very new or obscure Apple frameworks), and yes, it links with C/C++ just like it does on a Mac.
The full GNUstep provides a lot of functionality, so it depends on having a runtime installed - so it can load system frameworks for example. This means that installing a GNUstep app will install quite a lot of extra stuff into a “system” location, which could be seen as a disadvantage though.
ofalkaed
>depends on having a runtime installed
That is what I want. I am just a hobbyist and not much good so having most of that stuff decided for me is a feature. I was going to go with a smalltalk but C libraries being native is a big plus for me and there will not be much to learn since I somewhat know C.
krackers
More than just the language, with objc on mac you also get to take advantage of the surrounding stdlib. Toll-free bridging between CF and Cocoa, libdispatch which provides intuitive primitives for concurrency, etc. It's a shame that despite parts being open-sourced and GNUStep's efforts, there still isn't an easy way to get that "batteries included" experience.
danielvaughn
I did iOS work around 2015-2016 and I really enjoyed ObjC. Didn’t mind the unusual bracket syntax at all. Especially loved protocols - they just made sense to my brain.
kazinator
ObjC was rejected by the masses due to requiring a GNU compiler, whereas regular C had dozens of compilers.
C became popular outside of Unix because of compilers from Microsoft, Borland and a couple others for the IBM PC compatible machines running MS-DOS. (And note that they introduced C++ compilers also!)
Of you coded in Obj-C in the early 1990s (the window of opportunity for C derivatives to become popular), you would have been using expensive, niche hardware like a NeXT cube or Unix workstation.
If Obj-C had been made to work PCs in in the 1987-1990 time frame, and work well, it could have been a different story.
duskwuff
As I recall, the "official" language of early Mac development was Pascal - just normal Pascal, not any of the OOP extensions like Clascal or Object Pascal. All of the documentation in Inside Macintosh assumed you were using Pascal, and most Toolbox routines took Pascal strings (one byte length + up to 255 characters) as arguments. But none of it used any OOP features - it was all entirely procedural.
You can take ObjC from my cold, dead hands.
The cognitive burden of Swift is far too high for what it delivers, and it gets redesigned every year or two to be "different" than it was before, which makes finding example code online a challenge.
ObjC added about two dozen keywords to C and was rejected by the masses for use of [] insteqd of (). Is it really massively different to type:
rather than: Hell, you can even stretch to using property dot-syntax in ObjC: It pretty much manages memory for you with ARC, the only thing you have to look out for being instance-loops where A retains B and B also retains A. It has closures (blocks) as a basic language type, and it is a true superset of C (unlike C++) so any C program will compile with the ObjC compiler. It also integrates with C++ for that matter.Apple has invested too much in Swift for it to back down now, and I see some documentation is now Swift-only, not ObjC, so the writing is on the wall, but equally Apple has an enormous amount of internal code in ObjC, so it's going to be a long time before support goes away entirely.
And then, I'll just move to Linux. I've already written a basic implementation of a lot of the parts of Cocoa [1] with an SDL3 back-end, you even get GPU/compute shaders :) and although it's not ready for prime-time (the fit-and-finish needs some attention) it is the basis for me ultimately not needing to use Swift in future, a decade or so down the line, the bonus being that it'll work on anything - I have a proof-of-concept for it running on Windows, and GNUstep on Linux ought to make it easy to port there.
[1]: https://github.com/ThrudTheBarbarian/Azoth