Agreed. But once you get some macros (or categories) then Objective-C becomes a great language.

Is both elegant and very powerful as it is has the perfect balance between a static and a dynamic language.

Swift on the other had is a language where wonks decided to throw every silly feature they thought off to the point that is becoming more complex than even Scala.

I wished Swift was just a modernized Objective-C with a normal non bracket syntax and some extra facilities that it was missing.

It is such a wasted opportunity

> Swift on the other had is a language where wonks decided to throw every silly feature they thought off to the point that is becoming more complex than even Scala.

What features in particular do you think represent unjustified complexity?

Swift is not my favorite, but I wouldn’t consider it to be a “kitchen-sink” language, and it’s certainly less complicated than Scala.

"guard" is kind of useless but it's minor.

`guard` has its time and place, which is to refactor pyramids of doom away. The number of nested `if let` statements I've seen, and written, is upsetting.

Perl's "unless" syntax, or allowing "if"s at the end of a statement, also solve this and are more flexible.

I don't think they quite address the same thing. `guard` isn't just an `if` statement that looks for the negative of a Boolean; it also forces handing control flow out of scope in a consistent way — you cannot write a `guard` statement without also deciding how you'll exit the scope if the Boolean is false.

The developer not being made to do so, and just embedding conditions within conditions, is how the pyramids of doom are constructed to begin with.

Agreed, and that's kind of where Objective-S started:

https://blog.metaobject.com/2019/12/the-4-stages-of-objectiv...

Objective-C is powerful yes, but elegant? Not sure. It can do everything but I always felt like it was basically the opposite of elegant.

I would describe it as practical

I never felt like this was too terrible...

  NSString* result = [NSString stringWithFormat:@"%@ %@", @"Hello", @"World"];

I honestly can’t tell if the posts defending Objective C syntax are serious or not. Poe’s Law in action?

Compare with

  "Hello " + "world"

or if you hate operator overloading

  "{} {}".format("hello", "world")
  f"{foo} {bar}"

Your example is worse than stringWithFormat: for the same reason C++ iostreams are worse than format strings.

It's hard to control once you want anything more interesting than + and it's not localizable. Complaining that a function call's name is too long doesn't matter at all.

If you think that function name length doesn't matter you haven't written enough ObjC yet. It matters. Source code shouldn't read like Tolstoy.

ObjC itself is not responsible, it's NeXT and Apple's fault for perpetuating that abominable naming convention for much too long.

As for localisation, only a tiny fraction of strings in a software program are user visible. I don't think we should be designing language syntax around that edge case.

I'm sure I've written more than most other people currently alive.

ObjC is one of the most readable languages around. That's mostly because of the param:value syntax, which is much better than C-like syntax because you can see the parameter names. But the long method names aren't a problem once you have autocompletion. They also make it clearer what the best name for a method is - if you call something fmt() you start needing to make up equally clever short names for everything else, and it becomes less principled.

For algorithmic string building, I'm not sure how often you want + (aka appendString:), appendFormat: or componentsJoinedByString: are more flexible.

>if you call something fmt() you start needing to make up equally clever short names for everything else, and it becomes less principled.

Not necessary. There's a very sensible "huffmanization" principle created within Perl/Raku community which says that the need for a name/token to be overly descriptive is inversely proportional to frequency of its usage. So you can have short names and they still be human-parseable just because they are used often, and your brain used to register it. FWIW they will be easier human-parseable, because longer words take longer to read. With this approach one can has both fmt, and formatSomethingSomewhereSomeday

https://docs.raku.org/language/glossary#Huffmanize

I used to agree, but things like Jakt have an even better version:

https://github.com/SerenityOS/jakt

Notable differences:

1. param:value is used, but convention is param:value not the gratuitous Engrish verbingParamProposition:value ObjC inherited from Smalltalk.

2. param: is optional if the variable holding value in the calling function is named "param" at compile time. This pushes you to name your params "param" everywhere that makes sense.

Jakt's popularity is limited, obviously, but it's a compile-to-C++ language, so you could use it many places.

> convention is param:value not the gratuitous Engrish verbingParamProposition:value ObjC inherited from Smalltalk.

Smalltalk does not have this convention.

Actually, I'm glad its a method with a long-ish name. Operator-overloaded string concatenation makes something that can ruin your performance look innocent.

Also, I've never heard of any serious iOS/macOS dev complaining about this.

I can’t speak for other ObjC devs back when the iPhone SDK was released; but I remember just being so grateful that I had any tooling to develop for iOS that I was more than happy to overlook any ObjC weirdness/clunkiness.

ObjC is very simple (often confused with archaic), but also wildly complex. Once you wrap your head around the ObjC way of doing things, everything makes sense, is very consistent, and you could develop very effectively.

It's not an issue with autocompletion and Objective-C's verbose naming conventions tend to be more meaningful than those in J2EE, at least.

  NSString *foo = [@"foo" stringByAppendingString:@"bar"];

It's not that bad.

I must be missing something here.

  "foo" + "bar"

While this syntax is indeed popular in several languages it's deeply weird, it's like how English uses apostrophe S to do two very different things at the end of words.

The Add operation has a whole bunch of properties and this not only isn't most of them, it's arguably not any of them, the main argument for + as a string concatenate operator is "Well, people seem to like it". Which, I guess I/O streams doesn't even have that going for it, but it's a pretty terrible rationale.

Look, just grow string interpolate and write f"{foo}{bar}" or whatever as much as you like don't abuse unrelated operators.

Whatever you feel about operator overloading, it's way better than the Objective-C version, even the version floated by the defenders. String interpolation is even better, sure, but the + alternative isn't that bad. As you noted, natural language does the same kind of overloading and we seem to cope with it just fine.

It's more like compile-time concatening of literals like in C when doing

  const char *s = "foo" "bar";

I use:

  id foo = [@"foo" cat:@"bar"];

I have a category method added to NSString:

  - (id)cat:(id)arg { return [self stringByAppendingString:arg]; }

It’s been almost a decade since I did any ObjC, but I’m fairly certain that you want to use NSMutableString here :p

And, don’t forget to release your alloc’d objects (or use an auto release memory pool). There was no automatic memory management then!