Item — HN Reader

There are degrees of static typing. Swift tries to get close to Haskell, but without the full set of tools to do so without losing things along the way. This is sort of the worst of both worlds.

In the meantime Strongtalk already demonstrated that you can write a fairly rich optional type system to reap the compile time benefits of static typing while retaining the runtime power of message passing. I think that would have been more fruitful.

2 comments

Yes, there are degrees of static typing (hence, some people unfortunately disregard great type systems because they are only familiar with Java's cumbersome one).

The thing is, as soon as you realize that unit testing (of the kind proposed by 3+4=7) alone is not enough, or even adequate, and that you must use more advanced tools, and that more advanced tools can and should be automated whenever possible... you will probably start considering the possibility that static typing was a good idea after all. Especially if you were considering using type annotations in your dynamically typed language because you needed to extra info in order to use more advanced testing tools.

Static typing is an incredibly useful automated verification that the compiler performs for you, freeing you to write more interesting tests. It won't catch all mistakes, but no-one is arguing that any single technique will. The argument is about the relative merits of "unit testing alone is enough" vs "testing + automated testing with type checking is way better".

Since we're talking about Swift generics here, you have to realize that the point is not whether generics / static typing can be useful, but if the type of generics and static typing as enforced by Swift is good enough.

The problem here is that Swift has incomplete generics. In several aspects they are significantly worse than even Java's(!)

Together with its brand static typing and type inference that doesn't always work, you are really working against the compiler to get things to work. Not because you get the types wrong, but because you have to work around the incompleteness of the generics implementation!

Swift is not Haskell and should not be mistaken for it. The problem with Swift's generics is one of incompleteness, inconsistencies and problematic trade-offs to maintain ObjC compatibility.

Why do you say it is the worst of all worlds? To me it is a very good compromise and about as good a situation as you can get while maintaining C/Objective-C compatibility. Don't forget there are performance benefits to being less dynamic (not using runtime message passing) and you can opt in to that runtime mode if you want by making classes @objc.

Well, in practice the broken generics stop large amounts of reasonable uses of generics, the lack of co/contravariance force you into hideous workarounds everywhere.

As for the promised runtime performance improvements they have yet to surface and worse: the language is still plagued by extremely uneven performance, even for optimized builds. I could go on at great length citing issues that will be hard to fix within the next year or so. Unfortunately. This is what my fairly hard won (15k loc of Swift code) experience with the language has revealed so far.

I can honestly say I really wish you were right.

I haven't done that volume but I have written a few thousand lines including this branch of a GCD wrapper library which uses generics to allow return values to be passed between the closures running on the different threads in a typesafe way: https://github.com/josephlord/Async.legacy/blob/argumentsAnd...

It was a nightmare getting it all building right (generic methods on generic classes took me a bit of time to sort out) but I think it works well now.

As for performance noting the amount of Swift you've done (and your activity on the DevForums) I expect you know all this but I've done quite a bit on speeding someone else's code up. There are certainly plenty of ways to accidentally slow down code:

Summary of the optimisations taking someone's project from 10fps to about 1500. http://blog.human-friendly.com/swift-optimisation-number-ios...

Presentation on how to make Swift go fast: http://blog.human-friendly.com/london-swift-presentation-swi...

I regard Swift's inconsistent runtime performance and over-reliance on compiler optimizations as a major problem with the current state of the language.

It does not help that some slowdowns are due to bugs, and some due to questionable implementation details that require knowledge of how the runtime operates.

Of course, knowing about the runtime is necessary for all micro-optimization regardless of language, but Swift currently requires it almost all of the time.

The difference between Swift and ObjC/C is glaringly obvious.

Your GCD wrapper examples use only the simplest form of generics, with no constraints at all. Magnify the problems you had to get this to work by x10.000 and you get how easy it is to do anything complex with Swift's generics. It's a maze of missing features and bugs.

I think it's very understandable that Owens got fed up with it.