Earlier quoted context omitted.
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.
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 a…
JuliaLang: The Ingredients for a Composable Programming Language
161–170 of 228 posts
Re: JuliaLang: The Ingredients for a Composable Programming Language
#162Earlier quoted context omitted.
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…
> 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. You can add methods or computed properties, but that's about it. That's only one axis of flexibility, and it's really only syntactic sugar for writing and calling your own functions. You can't add any other kinds of features, unless they chose to use protocols…
> You can add methods or computed properties, but that's about it. That's only one axis of flexibility, and it's really only syntactic sugar for writing and calling your own functions. You can't add any other kinds of features, unless they chose to use protocols in their interfaces -- which they usually didn't.
I don't fully agree with this. I can add an extension implementing a protocol. That allows me to use classes I did not create in some kind of new subsystem I have just made, which requires objects adhering to a particular interface.
For instance I can take a library X somebody else made in Swift and made my own serialization library Y. Then I can add a serialization protocol to all classes in X. I can then have object graphs consisting of X objects which can now be serialized by my serialization library Y. This is beyond just adding syntax sugar for function calls. You are dispatching on the object type.
> For example, that page gives the example of adding precision to numbers in Julia. I'm not sure how you could do something analogous in Swift, short of writing your own numeric tower from scratch.
Yes this is the limitation of Swift which I have tried to articulate elsewhere in this discussion. In Julia I can make a subtype of AbstractArray or Number and this type can be used in all sorts of existing Julia libraries. That possibility does not exist Swift and I am uncertain if it ever can be made to exist.
If a Swift function took an abstract number type as argument, then the value I believe would have to be boxed. I don't see how an AOT compiler could avoid boxing. I mean inside a library perhaps, but across library/framework boundaries I don't see how you could avoid it.
Unless Swift is fundamentally redesigned as a language, I don't think it can ever match Julia in numerical computing and composability. Although I find it far easier to work with than C++ with respect to composability. My language preference is probably Julia, Go and then Swift. Go is somewhat primitive but it is kind of fun to work with. I like that they dialed back the static typing a bit. Swift feels a bit too Nazi at times.
Re: JuliaLang: The Ingredients for a Composable Programming Language
#163Earlier quoted context omitted.
Python replaced Perl in many niches, because Python was better suited to general tasks. For string processing, it wasn't as convenient, but there were so many other things where it was clearly a better choice. And being able to use a single "good enough" language for everything is itself a major convenience. Julia is the opposite - it's better than Python in one particular narrow niche, and cannot replace it broadly.…
"Julia is the opposite - it's better than Python in one particular narrow niche, and cannot replace it broadly. So it has to offer enough to justify going from one language to two." How so? Julia is a fine general purpose language. I'd go so far as to say it's more appropriate than Python for a wide class of problems!
In many ways, Julia is a better python than python, if only for the lack of the (quite insane in the 2000s) program structure by text formatting. That is a misfeature.
Julia is fast out of the box. You don't need Julia + some-other-language to get performance. You can use your GPUs fairly trivially from within the language (though this is implemented as FFI, it still has an idiomatic feel to it).
As for the previous comments on Perl, I am reminded of Mark Twain's famous retort. Rumors of its demise are greatly exaggerated.
Re: JuliaLang: The Ingredients for a Composable Programming Language
#164Composable? Julia and composable?!? They decided on sequence range [1...N], instead of [0...N) like Python. Try to compose that.
Depends on what you work on. When doing more computer science like stuff, such as computing memory offsets etc, then 0-based indexing is practical. But for numerical work 1-based indexing is usually easier to work with. Mathematical texts are already using 1-based indexing and hence that is what people are used to when thinking about math. I work with both and I never found this a big problem. This is on par with com…
Whatever I'm doing this is wrong. Simple example - I have Python sequence [0...N) to process. If members are independent, I could split it with easy in Python and do it in parallel: [0...N) -> [0...M) + [M...N) for any M between 0 and N. Basically, Python sequences/ranges/etc are monoids in many cases. Simplest composition rule - monoid, with unit element and associative composition. In Julia it really looks ugly, you have to make some effort to do it right.
For me, Julia people don't get range/sequence composition right, so ...
Re: JuliaLang: The Ingredients for a Composable Programming Language
#165Composable? Julia and composable?!? They decided on sequence range [1...N], instead of [0...N) like Python. Try to compose that.
What does that have to do with anything?
Simple example - I have Python sequence [0...N) to process. If members are independent, I could split it with easy in Python and do it in parallel: [0...N) -> [0...M) + [M...N) for any M between 0 and N. Basically, Python sequences/ranges/etc are monoids in many cases. Simplest composition rule - monoid, with unit element and associative composition. In Julia it really looks ugly, you have to make some effort to do it right.
For me, Julia people don't get range/sequence composition right, so ...
Re: JuliaLang: The Ingredients for a Composable Programming Language
#166Composable? Julia and composable?!? They decided on sequence range [1...N], instead of [0...N) like Python. Try to compose that.
It's pretty easy, you use an OffsetArray. Because Julia is composable the shape of the array and the values in it are orthogonal while reaming performant (as discussed by the article). As demonstrated by OffsetArray how one access an array is also orthogonal to those other factors, while remaining performant (it's a zero runtime cost abstraction).
Why I have to make special efforts to make simple things? Simple example - I have Python sequence [0...N) to process. If members are independent, I could split it with easy in Python and do it in parallel: [0...N) -> [0...M) + [M...N) for any M between 0 and N. Basically, Python sequences/ranges/etc are monoids in many cases. Simplest composition rule - monoid, with unit element and associative composition. In Julia it really looks ugly, you have to make some effort to do it right.
For me, Julia people don't get range/sequence composition right, simple thing, basic thing, thus ...
Re: JuliaLang: The Ingredients for a Composable Programming Language
#167Earlier quoted context omitted.
It can’t be used for compile time correctness checking? i.e Julia isn’t a statically typed language.
Presumably this means that no one has implemented a suitable static type checker or its type annotations don't provide sufficient information for a static type checker to work in principle?
The problem is more the former (nobody has gotten around to it yet), but also a bit of the opposite of the latter, i.e. the type system is so rich, type-checking may be undecidable in too many contexts.
Julia's parametric types are incredibly rich. You can look up 'dependant types' which are similar in the static world and see the sorts of hoops static language designers jump through to have dependant types and still be able to reliably prove theorems.
Re: JuliaLang: The Ingredients for a Composable Programming Language
#168Earlier quoted context omitted.
Python will still be around, but how popular it'll be is an open question. For example, Pascal or Perl were huge in their prime, and while they continue to stick around, the torch has been passed on.
Sure, but if Julia relegates Python to a niche and Rust does the same thing to C, they're still the same kind of approach to programming, and not some high level, mostly automated thing. They don't fundamentally change how people program.
When you write idiomatic Julia ... not C in a Julia syntax, but actually leverage the native power of Julia, yeah, you write code differently.
Re: JuliaLang: The Ingredients for a Composable Programming Language
#169Julia is great. It’s significantly simpler than Python while also being much more expressive. It’s too bad the typing is only for dispatch, but hopefully someone will write a typechecker someday. I’ve found it surprisingly refreshing to not have to think about classes and just add functions on objects wherever I want. Some languages solve this with monkey patching (which is bad), others like Scala with an extension c…
> It’s too bad the typing is only for dispatch, but hopefully someone will write a typechecker someday I was under the impression that if you write a function that takes very specific sub-types as its parameters, and then try to call it with invalid parameters (that is, values that cannot be converted to the right type via the promotion rules) that Julia will complain about this?
[deleted]
Re: JuliaLang: The Ingredients for a Composable Programming Language
#170Composable? Julia and composable?!? They decided on sequence range [1...N], instead of [0...N) like Python. Try to compose that.
If subtracting 1 when needed is too much work then you have more serious problems that the choice of programming language.