7 ms·

Anyone know how this compares to swift and its protocols etc?

by byt143 7y ago

eigenspace 7y ago
Julian interfaces are less formal than swift protocols. We use sub-typing and/or traits together with multiple dispatch to define generic pluggable interfaces. There’s a lot of discussion around making a more formal protocol-like system but so far what we have works surprisingly well, so we’re not in a huge hurry to implement something and want to slowly explore the design space.
- byt143 7y ago
  Sure, but I'm more looking for something from the swift side of whether Swift can do the same sort of composable generic programming.
  - eigenspace 7y ago
    Ah I see, I assumed you were already knowledgable about Swift. Cant help there, I only have a passing familiarity with it.
  - socialdemocrat 7y ago
    To some degree it can, but there are a number of problems with using Swift for this: (1) Swift does not support multiple dispatch. That limits the way you can glue together unrelated libraries. (2) Swift does not use abstract type hierarchies very much. E.g. in Julia one frequently define functions to use arguments of type Number, AbstractArray, AbstractString etc. This means it is easy for somebody in the future and define an array that works on a GPU or which is statically allocated and all existing functions operating on arrays work just fine. I can invent a whole new number type and make it a subtype of Number and all my existing algorithms operating on numbers work just fine. One example of this would be Dual Numbers, which allow automatic differentiation. This was fairly easy to accomplish in Julia, but has been a major undertaking on Swift, which I don't think is done yet. I think they actually have to change the whole compiler. For Julia this is just a library thing. (3) Swift function and method syntax is a pain to work with. For purely object oriented code it is very nice to read with parameter names. But once you get into functional programming and composition I find that it just creates a mess. I have to fiddle way too much with my Swift code to get function composition working as I desire. With Julia it is straightforward. I would say composition is easier when everything is just based on the same function syntax.
    - byt143 7y ago
      That makes sense. Swift is also way too complex and syntatically noisy imo. I like that Julia has a smaller set of very powerful abstractions. Though isn't point (2) just a convention thing? Protocols can refine other protocols. So in S4TF there's a layer protocol and an RNN protocol which extends that, IIRC.
      - socialdemocrat 7y ago
        I don't think so, I may be wrong, but I am quite sure you would get a significant performance penalty in Swift if you used protocols all over the place. For instance if `func foo(bar: Number)` in Swift would give bad performance I believe as the number object would have to be boxed. Julia can work with abstract types in a lot of instance without getting any performance penalty due to how the Julia type system works and Just in Time compilation. I don't quite see how a statically typed AOT compiled language could achieve the same.
        byt143 7y ago
        Perhaps this helps? https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md https://github.com/apple/swift-evolution/blob/master/proposa... and this https://twitter.com/jckarter/status/1202260205074968578 https://twitter.com/jckarter/status/1202260205074968578
        socialdemocrat 7y ago
        Must confess I am a bit too tired to parse that text effectively at the moment, but I don't think that is a solution. It is basically a solution to deal with generics across libraries. In C++ this is a big problem right. Templates cannot really be put in libraries. You put them in header files. So if you put generics in a library and link it, how are you going to know what to specialize and what not to specialize? That is the problem it seems to be they are solving here. But this is still a compile time issue they are solving. What I am talking about is an issue that happens at runtime. If I call a function f(x, y, z) and don't know the exact types of x, y, z at compile time, then Swift has no way of generating an efficient implementation of f. Julia OTOH due to its support for multiple dispatch CAN create an efficient implementation of f(x, y, z) for all possible types of x, y and z. Actually on further reflection I cannot see any way an AOT compiler can solve this problem. Say you got this definition: f(x: Number, y: Number, z: Number) A Swift library could in theory compile all sorts of concrete variations of this function for concrete number types. However there is no way it can provide all number types. The user could provide new subtypes of Number not known when the library containing f was created. I was a big Swift fan before and did not like JITs but Julia really convinced me how absolutely amazing Just in Time compilation is, especially combined with a dynamic language. You can just do so much crazy stuff that you have no way of achieving in a sane way in a statically type ahead of time compiled language.
socialdemocrat 7y ago
I am a big fan of Julia, but Swift is perhaps the only statically typed object-oriented language (apart from Objective-C) which I have found offers some similarity in flexibility to Swift's way of dealing with types. With the ability in Swift of adding extensions to conforming to a particular protocol to a class, you gain some of the same flexibility in Swift as in Julia. It means you can take an existing class which was not designed in particular for some kind of abstraction and add conformance to an abstraction (protocol) you later added. That is kind of what Julia gives you, with the ability to easily add functions dispatching on an existing type. Say you got a `Polygon` and `Circle` type in Swift and Julia which you want to add serialization to without either one having been designed for it originally. In Swift I would define a `Serializable` protocol with a `serialize` method taking an `IO` object to serialize to. Then I would extend `Polygon` and `Circle` to implement this protocol. In Julia I would simply add two functions: serialize(io::IO, poly::Polygon) serialize(io::IO, circle::Circle) The challenge in Julia is that I might want to define that only objects of type `Shape` can be serialized, but if `Polygon` and `Circle` was not already defined as subtypes of `Shape` I cannot do anything about that without changing source code. Swift has an advantage in his case. My only alternative in Swift would be to create a Union type of all tye types I want to be serializable.
- byt143 7y ago
  Thanks. I mean in julia you can use traits for that, but it's not built in (yet). Though there's no speed penalty, as you probably know. So this is about extending types, but it sounds like swift is strictly "better" then, since it's also statically checked? Or is there something that multiple dispatch gives that substantively better? I'm trying to get a feel for if the Swift for Tensorflow project will afford the same kind of composability, while keeping static type checking, modules etc (assuming they work out cross module code specialization, which I think is happening).
  - e12e 7y ago
    Does swift have macros? Looks like there's some work in bolting type checking on to Julia (small surprise, as we've seen that with eg: python and ruby as well). I'd hazard it's easier to bolt on typechecking than a proper macro system.

Anyone know how this compares to swift and its protocols etc?

by byt143 7y ago

Anyone know how this compares to swift and its protocols etc?

Julian interfaces are less formal than swift protocols. We use sub-typing and/or traits together with multiple dispatch to define generic pluggable interfaces. There’s a lot of discussion around making a more formal protocol-like system but so far what we have works surprisingly well, so we’re not in a huge hurry to implement something and want to slowly explore the design space.

byt143 7y ago
Sure, but I'm more looking for something from the swift side of whether Swift can do the same sort of composable generic programming.
- eigenspace 7y ago
  Ah I see, I assumed you were already knowledgable about Swift. Cant help there, I only have a passing familiarity with it.
- socialdemocrat 7y ago
  To some degree it can, but there are a number of problems with using Swift for this: (1) Swift does not support multiple dispatch. That limits the way you can glue together unrelated libraries. (2) Swift does not use abstract type hierarchies very much. E.g. in Julia one frequently define functions to use arguments of type Number, AbstractArray, AbstractString etc. This means it is easy for somebody in the future and define an array that works on a GPU or which is statically allocated and all existing functions operating on arrays work just fine. I can invent a whole new number type and make it a subtype of Number and all my existing algorithms operating on numbers work just fine. One example of this would be Dual Numbers, which allow automatic differentiation. This was fairly easy to accomplish in Julia, but has been a major undertaking on Swift, which I don't think is done yet. I think they actually have to change the whole compiler. For Julia this is just a library thing. (3) Swift function and method syntax is a pain to work with. For purely object oriented code it is very nice to read with parameter names. But once you get into functional programming and composition I find that it just creates a mess. I have to fiddle way too much with my Swift code to get function composition working as I desire. With Julia it is straightforward. I would say composition is easier when everything is just based on the same function syntax.
  - byt143 7y ago
    That makes sense. Swift is also way too complex and syntatically noisy imo. I like that Julia has a smaller set of very powerful abstractions. Though isn't point (2) just a convention thing? Protocols can refine other protocols. So in S4TF there's a layer protocol and an RNN protocol which extends that, IIRC.
    - socialdemocrat 7y ago
      I don't think so, I may be wrong, but I am quite sure you would get a significant performance penalty in Swift if you used protocols all over the place. For instance if `func foo(bar: Number)` in Swift would give bad performance I believe as the number object would have to be boxed. Julia can work with abstract types in a lot of instance without getting any performance penalty due to how the Julia type system works and Just in Time compilation. I don't quite see how a statically typed AOT compiled language could achieve the same.
      - byt143 7y ago
        Perhaps this helps? https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md https://github.com/apple/swift-evolution/blob/master/proposa... and this https://twitter.com/jckarter/status/1202260205074968578 https://twitter.com/jckarter/status/1202260205074968578
        socialdemocrat 7y ago
        Must confess I am a bit too tired to parse that text effectively at the moment, but I don't think that is a solution. It is basically a solution to deal with generics across libraries. In C++ this is a big problem right. Templates cannot really be put in libraries. You put them in header files. So if you put generics in a library and link it, how are you going to know what to specialize and what not to specialize? That is the problem it seems to be they are solving here. But this is still a compile time issue they are solving. What I am talking about is an issue that happens at runtime. If I call a function f(x, y, z) and don't know the exact types of x, y, z at compile time, then Swift has no way of generating an efficient implementation of f. Julia OTOH due to its support for multiple dispatch CAN create an efficient implementation of f(x, y, z) for all possible types of x, y and z. Actually on further reflection I cannot see any way an AOT compiler can solve this problem. Say you got this definition: f(x: Number, y: Number, z: Number) A Swift library could in theory compile all sorts of concrete variations of this function for concrete number types. However there is no way it can provide all number types. The user could provide new subtypes of Number not known when the library containing f was created. I was a big Swift fan before and did not like JITs but Julia really convinced me how absolutely amazing Just in Time compilation is, especially combined with a dynamic language. You can just do so much crazy stuff that you have no way of achieving in a sane way in a statically type ahead of time compiled language.

socialdemocrat 7y ago

I am a big fan of Julia, but Swift is perhaps the only statically typed object-oriented language (apart from Objective-C) which I have found offers some similarity in flexibility to Swift's way of dealing with types. With the ability in Swift of adding extensions to conforming to a particular protocol to a class, you gain some of the same flexibility in Swift as in Julia. It means you can take an existing class which was not designed in particular for some kind of abstraction and add conformance to an abstraction (protocol) you later added. That is kind of what Julia gives you, with the ability to easily add functions dispatching on an existing type. Say you got a `Polygon` and `Circle` type in Swift and Julia which you want to add serialization to without either one having been designed for it originally. In Swift I would define a `Serializable` protocol with a `serialize` method taking an `IO` object to serialize to. Then I would extend `Polygon` and `Circle` to implement this protocol. In Julia I would simply add two functions: serialize(io::IO, poly::Polygon) serialize(io::IO, circle::Circle) The challenge in Julia is that I might want to define that only objects of type `Shape` can be serialized, but if `Polygon` and `Circle` was not already defined as subtypes of `Shape` I cannot do anything about that without changing source code. Swift has an advantage in his case. My only alternative in Swift would be to create a Union type of all tye types I want to be serializable.

byt143 7y ago
Thanks. I mean in julia you can use traits for that, but it's not built in (yet). Though there's no speed penalty, as you probably know. So this is about extending types, but it sounds like swift is strictly "better" then, since it's also statically checked? Or is there something that multiple dispatch gives that substantively better? I'm trying to get a feel for if the Swift for Tensorflow project will afford the same kind of composability, while keeping static type checking, modules etc (assuming they work out cross module code specialization, which I think is happening).
- e12e 7y ago
  Does swift have macros? Looks like there's some work in bolting type checking on to Julia (small surprise, as we've seen that with eg: python and ruby as well). I'd hazard it's easier to bolt on typechecking than a proper macro system.