I prefer to keep the dynamism over unreadable fp "expressiveness" or safety that was not needed in the first place.

There's nothing stopping you from writing dynamic Swift code or functional programming in Objective-C.

Yes, but it’s not officially “condoned”, so it feels “out of place”. This is very individual, of course, but I don’t like bending the system to get patterns that are not “natively” supported.

In Swift, you cannot currently create classes in code, enhance and swizzle, implement proper proxies. You couldn’t even load a nib without the ObjC runtime. Not even reflection. It’s telling what their priorities were with that language. What good is the language when you cannot implement most of the system frameworks (Cocoa, Core Data, etc.) without nasty hacks?

> In Swift, you cannot currently create classes in code, enhance and swizzle, implement proper proxies

In pure Swift, that is. These are all possible if you reach into the Objective-C runtime, as I'm sure you know well. Overall, though, I do agree with you: I'm unsatisfied with the current reflection API in Swift and I really think that this is something that the core team should focus on some time.

Also I agree you can tell safety was the number one priority. However the positive is basically never getting runtime errors, except when interfacing with IB or obj-c even when people are programming in a hurry, which is nice for me.

> However the positive is basically never getting runtime errors

I don't quite think this is the "safety" that Swift aims for: rather, it prefers safety in the sense of failing fast and failing reliably if something goes wrong. Unwrapping nil and out of bounds array subscripting fall into this category of behavior.

"Never getting runtime errors" is as far fetched as it can be. Consider Xcode suggesting developers use force unwrap ("!"), that leads to many more crashes with unexperienced developers than the ObjC message to nil paradigm.

Subjectively, I have seen much more crashes in third-party software written in Swift than in ObjC (usually unwrapping or casting incorrectly), including in Apple's software. I cannot say if this is down to more inexperienced developers, less time allotted to experienced developers or a worse development model. I'd say a combination of the three.

I didn’t know it suggested force unwrapping, I always have a linter to prevent it except for IBOutlets etc.

This might also be because Swift is more likely to crash than fail silently at runtime.

I don’t see how this is possible, example?

Hmm...like making every arithmetic operation a potential crash site?

You’ve made some good points though I’ve found the reflection in swift since v2 to be sufficient for my day to day. I think the nib thing is a problem but in reverse, nibs needs to be swift so we can instantiate them with generics, this would be a game changer!

Without reflection, you cannot create a nib system (or any general purpose archiving solution). For Encodable, they used hacks that were tantamount to macros in C, but that requires compile-time knowledge of the class/struct structure. That's not how nibs work.

Or building a house with toothpaste. But this was more about what's more common/supported by the language/approved by the community rather than what's possible.

I’m surprised you downvoted this, we should be able to discuss pros / cons without downvoting people.

That in fact is all the things I don't like about Swift. I actually fine its way less expressive than Objective-C.

Yea, but you lose C++ interop, your binary will be inflated with those Swift proxy libs and your compilation times will increase 2-3-fold.

Those are actually temporary problems. Once ABI stability is implemented, those DLLs will not be needed. The compiler is obviously a WIP and will take years to become more mature and optimized. Likewise for C++ interop.

There are fundamental issues with Swift, but those are not them.

Compile times are not a temporary problem, they are fundamental. Yes, they can fix some of the more egregious specific problems, but the model they have chosen is inherently expensive to compile as it leans so much on the compiler.

And they no longer have Mr. Moore to bail them out by mere passage of time.

In fact, last I checked the compiler has actually gotten slower, overall, in recent versions.

Could you provide a documentation on the compiler model of Swift, and why it would be slower? How can that model be compared to clang's c++ compiler model?

The model for Swift is for the compiler to do a lot of work.

Doing a lot of work takes more time than doing less work.

There was an interview/article a while back that explained this for C++/D, I think it might have even been by Walter Bright himself, that explained this really well. Sadly, I can't find it right now.

In essence, C++ is predicated on the compiler being able to see through any abstractions you might have provided at compile time, in order to be able to optimize that away. That means you effectively lose separate compilation, because the compiler has to look at the implementation of dependencies, not just at their interfaces. Transitively.

So C++ is a lot slower to compile than C/Objective-C, and Swift is very similar, it just doubles down on that model. With this model it doesn't come as a surprise that compiling everything at once is often massively quicker than compiling single source files, the "whole module optimization without optimization" thing.

I also think there's at least some polynomial factor involved here, so as your projects get bigger, per-file compile times get significantly slower.

C and Objective-C really take separate compilation to heart, so you don't run into nearly the same problems (though: header files :-( ). Go is a more modern take on this, compile times are legendary.

In addition to that, Swift leans extremely heavily on the optimizer to get common constructs to execute in reasonable time, rather than 100x or more slower than you'd expect. That also costs. A lot. tcc doesn't really optimize much, it's a good example of how fast a C compile can go. (I clocked it at several hundred thousand lines of code per second or more, for comparison, numbers from a Swift project were 60 lines of code per second).

And last not least there's pretty wild forward/backward type inference, which will happily go exponential. For example, let's look at the following code:

   let a:[Int] = [1] + [2] + [3] + [4] + [5] + [6]

This actually used to fail with "expression too complex", nowadays it compiles in 26 seconds on my machine, and adding one more integer array gets it to fail again, after 59 seconds. Hmmm...

Thanks for the write up. There are massive benefits to having a simple language.

It’s gotten a decent but faster very recently for many cases, but still slow and throws weird false warnings sometimes.

I'm much more hopeful for ABI stability than C++ interoperatability. I think will take a long time before we'll be able to seamlessly work with C++ code as we do currently with say Objective-C or C.

Weren’t some steps taken to start working on preliminary support, or at least building blocks? I might be mistaken.

I've been mostly away from the Swift Forums for the last couple weeks, so if they've done something recently I probably missed it. Otherwise, though, AFAIK there's very few user-facing features that we can take advantage of right now. I do know that this is something that is on the roadmap, but so far the only changes related to this feature would be confined to the internals of the compiler, if at all. Here's a relatively recent thread by Doug Gregor where he outlines some of the challenges necessary to surmount if this feature is to ever land: https://forums.swift.org/t/c-objective-c-interop/9989

Yes, that's what I meant, some groundwork in the compiler internals. As I said, I could be misremembering.

That's an interesting thread, thanks!

Sure, by all means they should keep up the good work. I'll be happy to switch when it's ready. But until then, I'll stick to my trusty Objective-C for serious work.