# Is there a strong case that Julia is a more composable language?
**URL:** https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554
**Category:** General Usage
**Tags:** question, python
**Created:** [August 24, 2024, 10:26am UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554 "2024-08-24T10:26:33Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@alex-s-gardner](https://discourse.julialang.org/u/alex-s-gardner)
#### Post date: [August 24, 2024, 10:26am UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554/1 "2024-08-24T10:26:33Z")
Is there a strong argument for why Julia inherently provides a more composable eco system relative to python and other major science ML languages? Wanting to know for grant application to support development (by others).
---
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [August 24, 2024, 11:06am UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554/2 "2024-08-24T11:06:13Z")
Multiple dispatch:
> **[The Unreasonable Effectiveness of Multiple Dispatch | Stefan Karpinski |...](https://www.youtube.com/live/kc9HwsxE1OY?si=2xLaVMo9SiN9gyn0)**
>
> If you're familiar with Julia and its ecosystem, you may have noticed something lovely but a bit puzzling: there seems to be an unusually large amount of cod...
---
### Author:  [@kevbonham](https://discourse.julialang.org/u/kevbonham)
#### Post date: [August 24, 2024, 1:12pm UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554/3 "2024-08-24T13:12:27Z")
Stefan should really write that up as a manuscript - while the talk is incredibly clear, I fear a YouTube link is not likely to have the sort of credibility we’d want to cite in grant applications.
---
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [August 24, 2024, 1:25pm UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554/4 "2024-08-24T13:25:39Z")
There are bunch of papers already:
> **[Stefan Karpinski](https://scholar.google.com/citations?user=dgNqguIAAAAJ&hl=en)**
>
> New York University - Cited by 7,859 - programming languages - numerical computing - data science - linear algebra - computer networks
---
### Author:  [@kevbonham](https://discourse.julialang.org/u/kevbonham)
#### Post date: [August 24, 2024, 1:49pm UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554/5 "2024-08-24T13:49:56Z")
> [@lmiq](#):
>
> There are bunch of papers already
None that make this point about multiple dispatch being the source of interoperability between packages. The array operators one comes closest, but it’s focused more on performance.
I think a slightly more formal write up of the talk, maybe with some more modern examples - could even use the same name - would be useful.
---
### Author:  [@Satvik](https://discourse.julialang.org/u/Satvik)
#### Post date: [August 24, 2024, 5:16pm UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554/6 "2024-08-24T17:16:49Z")
Another big reason is that almost everything in Julia is built around the native `Array` type. In Python all the big ecosystems use their own, incompatible version of arrays, with duplicate versions of methods like `.std()`
For example, you might think you could write a function like
```julia
def sharpe(s):
return s.mean()/s.std()
```
in Python and have it work the same on pandas series, numpy ndarrays, and pytorch tensors. But you can’t, because numpy uses 0 degrees of freedom by default, while the others use 0, so you’ll get different results.
What if you try to explicitly pass degrees of freedom, like
```julia
def sharpe(s):
return s.mean()/s.std(ddof=1)
```
Now this works for pandas and numpy, but fails for pytorch, because it expects an `unbiased` argument instead of `ddof`. In order to actually get a version that does the same thing with each type of array, you need to write something like
```julia
def standardized_std(data, ddof):
if isinstance(data, torch.Tensor):
return data.std(unbiased == 1)
else:
return data.std(ddof=ddof)
```
Which is pretty clunky!
Meanwhile in Julia, almost every implementation of `std` you’ll see just looks at an underlying array and calls `std` from `Statistics`, giving you the same functionality and interface by default.
---
### Author:  [@jar1](https://discourse.julialang.org/u/jar1)
#### Post date: [August 24, 2024, 5:35pm UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554/7 "2024-08-24T17:35:23Z")
> [@kevbonham](#):
>
> could even use the same name
The point of the namesake “[unreasonable effectiveness of mathematics in the natural sciences](https://www.maths.ed.ac.uk/~v1ranick/papers/wigner.pdf)” is that there isn’t a reason why math is so effective — it just is:
> fundamentally, we do not know why our theories work so well
But the point of the Julia talk is explaining precisely the reason why multiple dispatch is effective. So the title could be improved imo.
---
### Author:  [@goretkin](https://discourse.julialang.org/u/goretkin)
#### Post date: [August 24, 2024, 6:41pm UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554/8 "2024-08-24T18:41:39Z")
I like this example demonstrating python’s built-in complex type being only over float, leading to an inability to express complex rational numbers in the stdlib: [Is Julia's way of OOP superior to C++/Python? Why Julia doesn't use class-based OOP? - #92 by goretkin](https://discourse.julialang.org/t/is-julias-way-of-oop-superior-to-c-python-why-julia-doesnt-use-class-based-oop/52058/92)
---
### Author:  [@alex-s-gardner](https://discourse.julialang.org/u/alex-s-gardner)
#### Post date: [August 24, 2024, 9:58pm UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554/9 "2024-08-24T21:58:25Z")
To be more specific, I’m looking for citable, peer reviewed material (maybe grey literature if that’s all that exists).
For a compelling proposal it isn’t wise to spend pages laying out an argument for why julia is more composable without strong citable support… an argument that could easily be viewed as personal opinion to a reviewer. Nearly everyone that uses Julia for more than a year is an evangelical… including me.
Does anyone know of more neutral authors that asses strengths of different languages and conclude that Julia’s unique design provides the benefits claimed by its authors?
---
### Author:  [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [August 24, 2024, 11:45pm UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554/10 "2024-08-24T23:45:17Z")
I can’t find any, and it’s not surprising because Julia’s composability isn’t spectacular. Different packages working together through APIs is not a novel concept, and the easing by a language’s particular features is readily apparent.
Python alone is also very composable via duck-typing. The obstacles in such glue languages comes with the 2-language problem:
1. if 2 core packages implement their own versions of a data structure, especially in 2 different languages, then their dependents can easily be separated into 2 incompatible groups. That’s not necessarily the case because people can agree on a Python-level API for Python code to work with either package; the Julia ecosystem has this pattern in abstract interfaces.
2. The composability is entirely in the glue language, and you can’t compile the underlying code in separate packages together at runtime, especially if they’re in separate languages. You can build another package that mixes them how you need, rewrap it in Python, and import that, but it’s obvious that working in one compiled language is smoother, especially JIT-compiled ones in interactive shells.
Since you can accomplish composability in different languages with their own perks and drawbacks, there’s not much incentive to academically nitpick. Julia didn’t invent something unlike any other language, it just collected and eased many convenient features for interactive workflows. For example, you can do limited argument dispatch in Python in various contexts if someone tries hard enough; NumPy uses NEP 18 to allow its API to use non-NumPy arrays, some of Python’s infix operators implement double dispatch in underlying dunder methods. Other reasons for language choice can easily outweigh how composability works.
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [August 25, 2024, 5:08am UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554/11 "2024-08-25T05:08:31Z")
> [@Benny](#):
>
> The obstacles in such glue languages comes with the 2-language problem:
This is — itself — a reason for Julia’s composability. Every Turing complete language can implement _any_ features from any other language… except performance.
I think that having user defined structs and functions as capable and performant as language “builtins” is a big part of the composability story. Multiple dispatch helps but I wouldn’t dismiss performance. As Jeff says, [“performance is actually special”](https://discourse.julialang.org/t/julia-vs-r-vs-python/4997/90).
---
### Author:  [@Barget](https://discourse.julialang.org/u/Barget)
#### Post date: [August 25, 2024, 10:09pm UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554/12 "2024-08-25T22:09:56Z")
Given that the premise of the OP is to show that Julia is _more_ composable, I wouldn’t linger too much on the “invention” part.
Instead, quantitatively speaking it’s definitely more composable (e.g. matrix operations can be readily done with any custom `<:Number` type, which is not the case for numpy, if I recall correctly).
I’m afraid that what one needs to do to address the OP would be to roll up their sleeves, and curate all the provided links. Quite time-consuming, though…
---
### Author:  [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [August 26, 2024, 9:44am UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554/13 "2024-08-26T09:44:44Z")
> [@Barget](#):
>
> e.g. matrix operations can be readily done with any custom `<:Number` type, which is not the case for numpy, if I recall correctly
Kind of. It started from wrapping an optimized BLAS library, which can’t be JIT compiled with custom types, but it is possible to implement more generic methods, see the example in [NumPy 1.17.0 Release Notes — Support of object arrays in `matmul`](https://numpy.org/doc/stable/release/1.17.0-notes.html#support-of-object-arrays-in-matmul). The same thing happens when Julia wraps a statically compiled library ([BigFloat FFT in Julia - Stack Overflow](https://stackoverflow.com/questions/48408395/bigfloat-fft-in-julia)).
> [@Barget](#):
>
> show that Julia is _more_ composable, I wouldn’t linger too much on the “invention” part.
That’s kind of the spirit of inherent advantages. Composability exists in many languages with different perks and drawbacks, so if we throw out opinion, we must talk about something novel. You are right that it’s nitpicking because opinions are what really matter. Composability is good? Performance of user-defined structs is good? Those are opinions based on our needs. If we’re programming a microcontroller with 64 bytes of RAM, a garbage collector and a JIT compiler being necessary to support language features is suddenly a needless drawback to constantly work around.
The nice part about this actually being a matter of opinion is we’re only dealing with a context that Julia is basically designed for: scientific computing and machine learning, Python being an explicitly named competitor. That bolsters the point that it’s not realistic to expect a neutral academic outsider to assess languages with such a context in mind. A Julia enthusiast with strong experience in ML and Python is actually the perfect person for demonstrating how composability is more practical in Julia and in a way that matters for ML development, not just broad strokes and toy examples.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [August 30, 2024, 11:47am UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554/14 "2024-08-30T11:47:17Z")
> [@Satvik](#):
>
> Another big reason is that almost everything in Julia is built around the native `Array` type.
I have totally different impression: I think that whenever arrays are involved, idiomatic Julia code tries very hard to stick to the `AbstractArray` interface, and provides special casing (eg for `Array`) as optimizations when applicable.
In other words, most generic Julia methods that take `Array`s will be perfectly happy with `UnitRange`s or whatever.
That said, I would shy away from statements like
> [@alex-s-gardner](#):
>
> Julia inherently provides a more composable eco system relative to python and other major science ML languages
Not because I don’t think it is true, but because it is hard to quantify or measure. Most people who like Julia have just tried it and it worked for them. (Yes, I understand that you want something for the application, but if writing it in Julia vs Python is the only selling point, I am not sure that is a strong argument).
---
### Author:  [@Datseris](https://discourse.julialang.org/u/Datseris)
#### Post date: [September 16, 2024, 8:42am UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554/15 "2024-09-16T08:42:07Z")
it really is unfortunate that there is no formal write up of this information. Whenever I tell someone of Julia’s composability, I cite Stefan’s talk or Frames’ blogpost [JuliaLang: The Ingredients for a Composable Programming Language](https://www.oxinabox.net/2020/02/09/whycompositionaljulia.html) . I don’t mind that both are outdated, but I am sure that the reviewers of my proposals/papers would mind that neither of these are in a “formal academic standard” (whatever this means, I am really fed up with this aspect of academia).
---
### Author:  [@greatpet](https://discourse.julialang.org/u/greatpet)
#### Post date: [September 16, 2024, 10:28am UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554/16 "2024-09-16T10:28:13Z")
You can always compose manually, in any language, by converting your data format / type into what is accepted by someone else’s package that you’d like to utilize. But you can compose without the extra conversion efforts when multiple Julia packages adopt the same abstract interfaces such as `AbstractArray`. Multiple dispatch makes this smoother, since the abstract supertypes of multiple arguments are used to control the dispatch. Ultimately, it’s about composability in an ergonomic boilerplate-free fashion, not about whether composition can be achieved at all in the language.
---
### Author:  [@jules](https://discourse.julialang.org/u/jules)
#### Post date: [September 16, 2024, 11:36am UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554/17 "2024-09-16T11:36:24Z")
> [@greatpet](#):
>
> Ultimately, it’s about composability in an ergonomic boilerplate-free fashion, not about whether composition can be achieved at all in the language.
I guess to take this further, it’s not just about whether composition is possible, or whether it’s subjectively convenient - it’s about whether users of Julia actually do compose their software significantly more than users of other languages. That would be interesting to analyze, although I’m not sure what one would measure exactly.
---
### Author:  [@kapple](https://discourse.julialang.org/u/kapple)
#### Post date: [September 17, 2024, 3:55am UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554/18 "2024-09-17T03:55:11Z")
> [@alex-s-gardner](#):
>
> Does anyone know of more neutral authors that asses strengths of different languages and conclude that Julia’s unique design provides the benefits claimed by its authors?
By coincidence of name, Julia Belyakova.
---
### Author:  [@kevbonham](https://discourse.julialang.org/u/kevbonham)
#### Post date: [September 19, 2024, 2:14am UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554/19 "2024-09-19T02:14:41Z")
> [@jules](#):
>
> That would be interesting to analyze, although I’m not sure what one would measure exactly.
Something about dependencies maybe? Perhaps we could reason about what the graph of package dependencies would look like if there’s zero composition.
Probably my biologist mind, but I’m kinda thinking of it like a philogenetic tree, where composition is interbreeding. If there’s no composition, the graph looks like a dendrogram, but if there is, there’s more cross branching.
Or something, I haven’t thought this through.
---
### Author:  [@tianyi\_zhang](https://discourse.julialang.org/u/tianyi_zhang)
#### Post date: [September 23, 2024, 2:56am UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554/20 "2024-09-23T02:56:26Z")
Could you kindly point to the specific paper? This is an interesting topic.
[Next page](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554.md?page=2)