A brief history of primary coding languages | Hacker News Reader

A brief history of primary coding languages

eclecticlight.co

31 pointsingve21 comments

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:

   MyObject * object = [MyObject new];

rather than:

   MyObject * object = new MyObject;

Hell, you can even stretch to using property dot-syntax in ObjC:

   MyObject *object = MyObject.new;

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

I’m glad to see someone else that loves objective-c as much as I do. It is delightful.

It’s a fantastic language and tools. I wish it had had more time to polish, expand, and potentially grow beyond mainly Mac and iOS before swift happened.

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;"

And also in all the ways to allocate and release memory.

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.

Hear hear! I love Objective-C and just think it's the best language. I will use ObjFW going forward (and GNUStep as a last resort) once (if?) Apple drops ObjC, but so far it's still going strong.

> ObjC added about two dozen keywords to C and was rejected by the masses for use of [] insteqd of ().

Syntax matters. It's like the lesson Lisp people just refuse to learn: It's the parens, stupid.

One of the complaints people reach for about Scheme is that it has too many implementations. JavaScript has many implementations too: Node, Deno, Bun, all the browser ones, ES5, ES6, TypeScript... hell, at $JOB we actually have code written for Rhino. But people will transpile and polyfill till the cows come home to get the latest features into their struggling IE6 SPA. Scheme, people just shrug their shoulders and give up. Why?

One reason probably is, it's the parens, stupid. The near monopoly advantage that JavaScript enjoys over the browser-application space (and hence, virtually all front-end development) is probably a major factor, but then what about the back end?

I love Objective-C too. It came the closest I've ever seen to writing Smalltalk in an environment where applications are expected to be native and snappy. I've written a video game in it... for Linux. But Apple realized that for many devs, especially those getting onboard iOS development, the brackets would be a sticking point. Hence Swift.

    a = foo.bar();
    if(!a.frobnitz()) { return nil; }

If your language doesn't look like that, you will have an uphill battle. All successful new programming languages look more or less like this now, with the possible exception of Python. But Python's significant indentation actually helps beginners, data people, and others who don't sprinkle semicolons and curly braces on their Wheaties every morning.

Also, FWIW I don't think GNUstep has switched to Swift yet either, may wish to consider giving that a go.

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.

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...

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…

Ugh, yes, I could not wrap my mind around QML either. I've dabbled in SwiftUI as a hobbyist and find it generally easy to use, though I do agree that the traditional Storyboard approach is easier to wrap my head around (also an amateur hobbyist there, with emphasis on amateur).

My experience is that iteration and development speed in SwiftUI is noticeably faster, but once your app reaches some level of stasis and maturity, the Storyboard approach is more robust and easier to manage and understand. I have some thoughts on why but we'll save that for another day.

My favorite UI framework as a developer is egui [0] with Dear ImGui [1] in second place.

Unfortunately, Dear ImGui is ugly as sin. egui is decent enough.

My understanding is that SwiftUI was Apple's direct response to React/Vue.

[0]: https://github.com/emilk/egui

[1]: https://github.com/ocornut/imgui

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.

> 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.

>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?

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.

>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.

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.

https://www.darlinghq.org/

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.

Only if you are talking about UCSD Pascal on the early Apple systems, which the article touches on.

AppToolbox exists and has required for all Mac systems since the classic model.

It was later on replaced by the C++ version when MPW was introduced, and all the plain C like functions, where actually C++ under the hood with extern "C".

Apple like Microsoft and IBM, all pretty much into OOP for userspace frameworks early on, where UNIX birthplace of C++, was still a C land for the most part, with exception of efforts at Sun and NeXT.

> Only if you are talking about UCSD Pascal on the early Apple systems

I'm not. If you aren't familiar, take a look at the original edition of Inside Macintosh, particularly the "summary" sections (e.g. page 213 of the PDF for QuickDraw):

https://vintageapple.org/inside_o/pdf/Inside_Macintosh_Volum...

Notice that all of the definitions are written as Pascal data types and function definitions.

> AppToolbox exists and has required for all Mac systems since the classic model.

The "Toolbox" was a general term for Apple's ROM and system routines. It did not refer to a specific programming language or development environment. (See page 21 of the PDF linked above for a definition.)

> It was later on replaced by the C++ version when MPW was introduced, and all the plain C like functions, where actually C++ under the hood with extern "C".

This is not accurate. Apple never "replaced" the Toolbox routines in classic Mac OS - they were called from C instead of Pascal as developers shifted to that language, but the routines all remained the same (often still using Pascal data types for types like strings, as I mentioned earlier). There was never any official C++ interface to the Toolbox.

I was referring to MacApp, as I often get those mixed together.

https://en.wikipedia.org/wiki/MacApp

Which was then rewritten into C++, after MPW introduction, while eventually most of the developer community migrated into PowerPlant from Metroweks.

https://en.wikipedia.org/wiki/PowerPlant

The code was rescued into Github, https://github.com/chrisballinger/powerplant

MacApp was never required for Mac OS development, though - it was an entirely optional "userspace" development framework which used the Toolbox just like any other MAc OS application.

Reply on news.ycombinator.com