Hacker News Reader

Comment by ardit33 | Hacker News Reader

I agree with the author.

"So now contrast that to Swift. First of all: Which question did it desire to answer? Think about it. There is no one clean answer."

I feel that Swift is more just like a language designed to be a syntax swap of objective-c, making few things better, yet some other ones worse.

Sure, it might be more welcoming to people used to java/javascript type of language syntax, but overall I think it is two step backwards on language design and functionality.

To folks that are proficient with Objective-C,

1) How do you like working in Swift?

2) Are you more productive (for medium or large projects)?

3) Do you enjoy it more?

In my part (if you are already very proficient with Objective-C), those answers are Nos. If you are new to iOS though, Swift is easier to get started.

https://www.hackingwithswift.com/articles/27/why-many-develo...

View on HN

I started developing in Objective-C back in the early 2000s on macOS (as a kid), worked at a big company on some macOS software, then worked on a million-line iOS Objective-C project at another big company for many years.

After I left, I picked up Swift. I use it for all of my personal iOS projects. I don't disagree that there are flaws in the language, but they definitely aren't the ones the author pointed out.

> Adding compile time static dispatch, and making dynamic dispatch and message passing a second class citizen and introspection a non-feature.

I can't express how happy I am that an object is exactly what it tells me it is at compile time. The number of nuanced bugs that have bit me over the years, my lord. Let alone explaining this stuff to a new coworker? Dynamic dispatch / message passing / introspection are huge bug sources. If you can't rely on the compiler to tell you what something is, what can you rely on?! This alone dropped bugs an order of magnitude.

> Define the convenience and elegance of nil-message passing only as a source of problems.

Nil messaging is nothing but a source of problems. Can confirm.

> Classify the implicit optionality of objects purely as a source of bugs.

Implicit optionality was a massive design failure in C. Those days are behind us, it's time to move on.

(1) I love working in Swift. It opens up all sorts of great design patterns -- lightweight view model structs, enums with associated values, easy to manage protocols. Readability is dramatically better. No more copy-paste between header and source. No more dealing with unintelligible types, first-class generics, etc.

(2) Productivity boosts come from less boilerplate, less repetition, less typing, better design patterns being within reach. Static typing eliminates many classes of common bugs. No automatic nils is huge. I can't remember the last time my app crashed in something other than an Objective-C component or framework.

(3) Yes, I do.

I programmed mainly in Objective-C from ~2000 (Rhapsody beta) and resisted even learning Swift until Apple finally confirmed they were definitely going to open-source it. So about a decade of objc.

1.) I love working in Swift. It would not occur to me to start a new project in Objective-C. The only reason I could see myself writing more objc code in this life would be to make a quick fix on some old project. (Incidentally, this is the exact same kind of B-completely-replaces-A-for-me language experience I had with JavaScript→TypeScript. Can't think of another.)

2.) Swift confers upon me a quantum-leap kind of productivity increase -- the kind of "programmer time" optimization the Ruby guys used to talk about over Java. The core language is great. Swift enums concisely solve lots of problems that are easy-but-annoying in Objective-C. Protocol extensions are an absolute godsend and I hate the feeling (when programming in something else) of seeing how a protocol extension would solve the problem at hand, but not having them.

Incidentally, I remember vividly when there was talk of adding "concrete protocols" to Objective-C 2.0. (They let you do a similar thing; adopt a protocol to gain a bunch of implementation behavior, not just declare that you support an interface). I was really, really excited about that, too. But the rumor didn't pan out and concrete protocols were never added.

3.) Yep, love it. I changed jobs in 2016 and don't even do much Apple platform development anymore; I am mainly using Swift on Linux.

My comments apply to current Swift, so right now that means 4.2. As you go back in time to older versions, I liked it less. In the first year doing Swift, there were still times I enjoyed Objective-C more, but not anymore.

Aww, it's kind of sad when I think about it; after all those years, Objective-C is now dead to me, like NewtonScript...

> Incidentally, this is the exact same kind of B-completely-replaces-A-for-me language experience I had with JavaScript→TypeScript. Can't think of another.

I had my own instance of that with Java -> Kotlin — and this is on the backend. I can’t imagine how that transition feels like on Android

> Swift enums concisely solve lots of problems that are easy-but-annoying in Objective-C.

Curious as to what those might be, can you shed some light?

I was also puzzled by the emphasis on enums in Swift, as they are a language feature I rarely if ever use in Objective-C, not because I want to and they are inadequate, but because I generally don't see much of a need for them.

Swift enums are effectively discrimated unions, which are really, really different from C (and thus, Obj-C) enums.

For example, in Swift, you can have an enum which says its values holds exactly one of:

A) several specific semantically meaningful strings B) some other object C) several objects

In Obj-c, you would probably express this as a single object, and write a bunch of error prone logic to handle which of these states you’re in, possibly missing an important last minute addition in one of your methods for walking over all the possible state.

Thanks!

In any OO language, I’d write different classes for cases A B and C that share a common message protocol (wether formal or informal) and use them uniformly/polymorphically.

1) I've been doing Cocoa development for 13 years, and I absolutely love Swift. I've switched to it for all my own projects (at least the ones where I would previously have used Objective-C), and I'm never looking back.

2) For medium projects: absolutely. For large projects: I haven't had the pleasure yet, but the truth is that Swift encourages a much better approach to modularity, and if you're working in a large project as a monolith, you're probably doing something wrong.

3) Hands down, yes.

I spent 20 years writing in object oriented C, the last three in objective C. When Swift was announced I started my next project in it, and never switched back. That’s saying a lot giving how rough Swift 1.0 was, I couldn’t even release till Swift 1.2.

The entire language is designed to make the most costly part of development, quality, so much easier. That’s been it’s main purpose and theme since day one. And it’s not just optionals.

Today some code wouldn’t compile because I forgot a switch case. I remembered when I didn’t have to worry about stuff like that, Objective C would let me compile and defer till weeks later finding the obscure bug it caused in a painful multihour debugging session.

> 20 years writing in object oriented C

C++?

Think/Lightspeed C for much of it, using their object Oriented extensions.

So essentially C++?

"Version 3 and subsequent versions were essentially a subset of C++ and supported basic object oriented programming concepts such as single inheritance as well as extensions to the C standard that conformed more closely to the requirements of Mac OS programming. After version 6, the OOP facilities were expanded to a full C++ implementation, and the product was rebranded Symantec C++ for versions 7 and 8, now under development by different authors"

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

Nah, never developed using C++, always stuck to the original object oriented subset.

...which was "essentially a subset of C++".

Not really, C++ is a huge monster compared to the original ThinkC object oriented extensions. Beyond single inheritance, it was just a much simpler language. It's like saying C is a subset of C++, because it is.

To folks that are proficient with Objective-C, 1) How do you like working in Swift? 2) Are you more productive (for medium or large projects)? 3) Do you enjoy it more? In my part (if you are already very proficient with Objective-C), those answers are Nos.

It’s not about making the people who are already familiar with Objective C. It’s about the next generation of developers who find Objective C obtuse.

The current iOS developers can stay with Objective C for the foreseeable future. Microsoft had to drag developers from C/C++ and Vb6 to .Net. Apple has to do something similar.

I also agree with the author.

I think Swift solves the problem of jailbreaking. If iOS were written entirely in Swift, there would be no jailbreak tweaks, because there is no method swizzling.

I see Swift as an evolution of C++, similar to Java and C#. Plenty of people can program in Objective-C, but not many people actually understand it IMO. I think an expert Objective-C programmer can be more productive than an expert Swift programmer. But Swift is better for large teams of average, interchangeable programmers.

I think those who say that are more productive in Swift were simply not very productive in Objective-C. People who are productive in Objective-C will despise having to work with another layer of abstraction that provides no benefit for them (it prevents bugs that they never created in the first place).

I work with Swift on a daily basis, both on iOS as well as server-side. I absolutely love it. Historically, I've written a lot of Java, primarily for large enterprise apps. For a few years I took over enterprise iOS development and decided to use Swift for all new projects. I don't regret it for a second! Swift forces you to really think about your code. I can't count the number of times in other languages where developers fail to address null values. With Swift, you're forced to think about what you'll do if the value is null (unless you explicitly side to say, "Ehhh screw it!" and unwrap your values without checking.) It makes it easier to write "safe" code.

Recently, I've begun re-writing some of my personal server-side projects from Java EE to Swift. While the new frameworks (Perfect, Vapor, Kitura, etc.) are good, there are still some areas where they are lacking. Cryptography, for example. There's a real lack of good crypto libraries for Swift that deploy on Linux. I'd LOVE to see the equivalent of the JCE (Java Cryptography Extensions) in Swift. Right now, most of them are just weak wrappers around OpenSSL. But, from a performance and resource perspective, Swift is GREAT compared to Java. Faster, and much less resource overhead.

Coming from ObjC, I love the death of PDP-11-age one-pass-compiler C-isms like header files. I also love the inference and strictness of types/mutability in Swift, and error-checking from optionals and exceptions.

These are all things that could have just been added to ObjC through language and IDE updates, but they ended up in Swift, and so there I go.

As an experienced ObjC programmer, Swift allows me to expose the foundation of my code far more rapidly, and in a much more stable form. It forces me to answer critical questions about my software that I would often postpone indefinitely in ObjC. It makes refactoring feel much more safe.

I like plonking down some quick ObjC, but my Swift programs feel much, much more correct.

(Of course, when dealing with C APIs, Swift is downright nauseating.)

Swift took a well-developed language, looked hard at what was lacking/worked-around/deprecated/old/annoying, and rebuilt the language from scratch to get it right/modern this time.

Would we could do this with other languages.

That well-developed language that they tried to improve on was C++, not Objective-C.

Apple doesn't agree with you.

"Swift is a successor to both the C and Objective-C languages."

-- https://developer.apple.com/swift/

Reply on news.ycombinator.com