3 ms·

I think the top-level take away here is not that Julia is a great language (although it is) and that they should use it for all the things (although that's not

I think the top-level take away here is not that Julia is a great language (although it is) and that they should use it for all the things (although that's not the worst idea), but that its design has hit on something that has made a major step forwards in terms of our ability to achieve code reuse. It is actually the case in Julia that you can take generic algorithms that were written by one person and custom types that were written by other people and just use them together efficiently and effectively. This majorly raises the table stakes for code reuse in programming languages. Language designers should not copy all the features of Julia, but they should at the very least understand why this works so well, and be able to accomplish this level of code reuse in future designs.

ViralBShah 7y ago
This visualization of dependencies among Julia packages in this twitter thread by cormullion shows it pretty well. https://twitter.com/_cormullion/status/1224640188518932483 https://twitter.com/_cormullion/status/1224640188518932483
pdexter 7y ago
Interesting. Can you give an example of generic algorithms plus custom types, in practice? Off the top of my head I thought that any dynamic language or static language with good genetics would have this property, but maybe there's something that Julia does differently.
- oxinabox 7y ago
  DiffEq on ForwardDiff Dual numbers to calculate sensitivity via forward mode AD. DiffEq on Tracker's TrackedArray to calculate sensitivity via reverse mode AD. Measurements.jl's numbers that track measurement error input any algorithm to compute the transformed measurement error after the algorithm is applied. NamedDims.jl + Flux.jl to give everything that PyTorch's awesome Named Tensors feature gives.
- ddragon 7y ago
  As an additional example, I really like the combination of unitful and diffeq [1]. But you're right that the core feature that allows this stuff is duck typing, but by itself it's not enough. Your notduck had to not only quack, but other animals have to look at it and act like it's a duck sometimes and like a notduck when you want it to do more than a duck. Multiple Dispatch (plus parametric subtyping) allows you to trivially define both notduck + A (notduck.+(A) in OOP languages) and A + notduck (extending A whatever A is) and it's really fast. That allows for the core Julia concept of specialization, easily customizing the particular behavior of any agent at any point to get both the common behavior right and the extended behavior. For static languages you can implement part of it with, for example, interfaces (you'll face the same restrictions if the language is single dispatch), but even if you can extend the interface freely for already existing objects, there must be an agreement between the multiple packages to comply to the same interfaces (and you might either end with tons of interfaces since there are tons of possible behaviors for each entity and purpose or giant interfaces to fit all). In Julia you can use specialization to surgically smooth the integration between two packages that had no knowledge of each other and didn't even decide to comply to any (informal) interface (which do exist in Julia, like the Julia Array and Tables.jl interfaces). [1] https://tutorials.juliadiffeq.org/html/type_handling/03-unitful.html https://tutorials.juliadiffeq.org/html/type_handling/03-unit...

ViralBShah 7y ago

This visualization of dependencies among Julia packages in this twitter thread by cormullion shows it pretty well. https://twitter.com/_cormullion/status/1224640188518932483 https://twitter.com/_cormullion/status/1224640188518932483

pdexter 7y ago

Interesting. Can you give an example of generic algorithms plus custom types, in practice? Off the top of my head I thought that any dynamic language or static language with good genetics would have this property, but maybe there's something that Julia does differently.

oxinabox 7y ago
DiffEq on ForwardDiff Dual numbers to calculate sensitivity via forward mode AD. DiffEq on Tracker's TrackedArray to calculate sensitivity via reverse mode AD. Measurements.jl's numbers that track measurement error input any algorithm to compute the transformed measurement error after the algorithm is applied. NamedDims.jl + Flux.jl to give everything that PyTorch's awesome Named Tensors feature gives.
ddragon 7y ago
As an additional example, I really like the combination of unitful and diffeq [1]. But you're right that the core feature that allows this stuff is duck typing, but by itself it's not enough. Your notduck had to not only quack, but other animals have to look at it and act like it's a duck sometimes and like a notduck when you want it to do more than a duck. Multiple Dispatch (plus parametric subtyping) allows you to trivially define both notduck + A (notduck.+(A) in OOP languages) and A + notduck (extending A whatever A is) and it's really fast. That allows for the core Julia concept of specialization, easily customizing the particular behavior of any agent at any point to get both the common behavior right and the extended behavior. For static languages you can implement part of it with, for example, interfaces (you'll face the same restrictions if the language is single dispatch), but even if you can extend the interface freely for already existing objects, there must be an agreement between the multiple packages to comply to the same interfaces (and you might either end with tons of interfaces since there are tons of possible behaviors for each entity and purpose or giant interfaces to fit all). In Julia you can use specialization to surgically smooth the integration between two packages that had no knowledge of each other and didn't even decide to comply to any (informal) interface (which do exist in Julia, like the Julia Array and Tables.jl interfaces). [1] https://tutorials.juliadiffeq.org/html/type_handling/03-unitful.html https://tutorials.juliadiffeq.org/html/type_handling/03-unit...