Comment by hellofunk | Hacker News Reader

Comment by hellofunk | Hacker News Reader

Parent Full thread

> Swift is widely marketed as a functional language

If that's true, those sources reporting that are wrong. Apple itself refers to it instead as a "protocol-oriented language" when it's not just saying "object-oriented".

Swift is definitely not a functional language in the way that it usually means, and Apple knows this, and any legit survey of languages wouldn't clump it together with much more functional languages. For example, this guy[0] knows what he is talking about.

> Where Swift shines it is in the integratiion with the underlying Objective C frameworks on the Mac.

>Swift is a good replacement for contexts in which Objective-C would be used.

Except when you try to do anything with OpenGL or a C-based API, like Core Audio. Swift is really lagging for "power programming" with these low-level APIs. It's great for beginners who use all the high-level frameworks (though "great" is a subjective term I don't really agree with for Swift), but a lot of people who really need to get stuff done on Apple's platform are not going whole-hog Swift.

>If you’re coming form Erlang/Haskell world you’ll think Swift is verbose and a bit of a mess but if you’re coming from Objective-C you’ll think “Swift is concise and elegant”

I got to be honest, I still find I prefer Objective-C, because, it's essentially C. I can use my C structs and interfaces with zero problem. But in Swift, all C primitives are translated into Swift-only stuff, even integers!

And don't get me started with trying to use a C++ library with Swift, something that's smooth with Objective-C. Which is ironic since Swift itself is written in C++.

[0] http://robnapier.net/swift-is-not-functional

What is a "Swift-only" integer? Swift integers are just integers. They interoperate with C just fine.

Interacting with C APIs in Swift is pretty much as convenient as using them from C or Objective-C. Which is to say, it's kind of inconvenient compared to using a good Swift API, but you don't gain a benefit from using C or Objective-C instead.

The major exceptions to this are the inability to take a pointer to something before it's initialized (for example to use a local variable for an out-parameter) and the inability to declare arrays on the stack. The former just requires some "= 0" or similar, and the latter can be worked around without much difficulty using a Swift Array or just using malloc and free, at the expense of a bit of performance.

There is also a problem where Swift translates fixed-length arrays to tuples (because Swift has no concept of fixed-length arrays) which can be inconvenient, but this rarely comes up.

Maybe you're just not familiar with the facilities Swift provides for interacting with C APIs and are doing things in a more difficult way than is necessary.

It's absolutely true for C++ interfaces, of course, but Swift doesn't even try and never advertises C++ interop. For that, you have no choice but to use C++ or Objective-C++. But for plain C APIs, Swift does a great job.

I've read a number of articles like this one regarding the Integer protocol in Swift and the many different int types:

http://blog.krzyzanowskim.com/2015/03/01/swift_madness_of_ge...

I guess everyone's mileage varies, but I find it a bit strange.

The only thing strange is that the author of the post seems to be trying to make Swift's integer handling sound unnecessarily complex.

> There are 11 Integer types that can be considered as Integers

Although he's including Bit which doesn't really count (it conforms to the appropriate protocols but from the doc comment you can see it's actually just intended as the index type for CollectionOfOne).

But having a bunch of different integer types shouldn't be surprising. Every integer type Swift has corresponds to an integer type in C, e.g. Int16 is int16_t, UInt64, is uint64_t, Int is long, etc.

As for the protocols, so what? It's a bad thing that most of the functionality of integers can be represented using a bunch of protocols? Clearly not. All the author is trying to do is make things sound complex.

> My goal here is to create generic function that will handle any integer value and make some operation on it. In this case I want to build function that get bytes and return integer value build with the given bytes array of bytes

So he wants to have a function that builds integer types all different sizes given an array of bytes, and wants to do it generically for any integer? Ok, take a pointer to your bytes, cast it to a pointer to integers of the right size, and you're done.

Oh wait.. he wants to do it without "raw memory", whatever that means? That's stupid. The rest of the article is nothing but a complicated exercise in trying to do things as hard as possible. His entire function can be written in pure Swift (without NSData) as

  func integerWithBytes<T: IntegerType>(bytes: [UInt8]) -> T? {
      guard bytes.count >= sizeof(T) else { return nil }
      return bytes.withUnsafeBufferPointer({ UnsafePointer<T>($0.baseAddress).memory })
  }

That's it. 100% pure Swift, and probably about as efficient as you can get.

What about stuff like this, these weird castings that pop up in Swift that you don't worry about in Objective-C when dealing with C APIs:

glBindBuffer(GLenum(GL_ARRAY_BUFFER), bufferIds[1])

glBufferData(GLenum(GL_ARRAY_BUFFER), sizeof(Float) * tcSize, tc, GLenum(GL_STATIC_DRAW))

That just looks silly to me.

This appears to be a peculiarity of the OpenGL headers - GL_ARRAY_BUFFER is just a #define:

    #define GL_ARRAY_BUFFER 0x8892

Instead of a proper constant. Therefore, Swift interprets it as an integer, which is fairly reasonable. GLEnum is:

    typedef uint32_t GLenum;

Which is not compatible with Int in Swift, thus the "cast".

If GL_ARRAY_BUFFER was:

    extern GLenum GL_ARRAY_BUFFER;

It would work as expected.

The lack of implicit integer conversions does dirty up the code a bit when using C APIs built around them, but I don't find it to be a particularly big deal.

Regarding the post in your other comment, none of that really has anything to do with C interop. C doesn't even have generics, so the whole thrust of the article (that it's hard to build a generic function that works on all integer types) doesn't apply.

Swift enums are considerably different from C/Obj-C enums so the cast is unavoidable. Specifically unlike C enums, Swift enums can be backed by non-integer types like Strings.

For numeric types that have a clear equivalence in C-land, Swift is seamless.

Actually, GLenum is not a C enum in the first place; it's just an integer typedef.

Interfaces which use the pattern:

  struct foo bar;
  foo_init(&bar);

Can be very annoying in swift, it does play nicely with CoreFoundation which does not use this pattern

As of Swift 1.something, C structs get imported with an empty initializer that sets everything to zero. So that pattern can be written in Swift as:

    var bar = foo()
    foo_init(&bar)

No worse than the C version, as long as the unnecessary initialization is not a performance problem (which it usually isn't).

In your provided reference, the first sentence Rob writes:

"Ever since Swift came out, I keep seeing weird comments that Swift is a functional programming language"

Swift is often promoted as being "functional":

http://www.raywenderlich.com/114456/introduction-functional-...

In fact, I've tagged many articles as functional in my Swift resources:

http://www.h4labs.com/dev/ios/swift.html?q=functional&age=10...

Want to buy a book on functional programming in Swift?

https://www.objc.io/books/functional-swift/

Note that the objc.io book is more about building functional idioms from scratch so you can use swift in a functional way, rather than actually leveraging a strong functional core of the language. The fact remains that Swift is just not a functional language and attempts to categorize it as such are unrealistic.

Swift is a multi-paradigm language. In that Ray Wenderlich article you linked, he writes "This tutorial focuses on just one of these methodologies, FP (Functional Programming)"

On a WWDC video named something along the lines of "Value types in Swift" they explained that Apple is trying to get try middle ground between protocol oriented and functional. Same thing with mutability and immutability. They aren't pure anything because both ways have their purposes.

People say a lot of things. Doesn't make them right.

I actually find working with C in Swift to be far more pleasant than using C directly. The blog post by our friends at Apple on the subject -https://developer.apple.com/swift/blog/?id=6 - gives a pretty good background.

Reply on news.ycombinator.com