Is there a strong case that Julia is a more composable language?

General Usage
,
6

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

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

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

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.

8 Likes