Syntax idea: `like` instead of `similar`

rand(like!(M)) would read better than the current rand(similar(M))

It wins by 3 letters and 2 syllables.

EDIT: (thanks
EDIT: how about shape? I think that’s better than either similar or like (see post #10).

1 Like

You probably mean rand!(like(M)).

It’s also closer to ones and zeros which are arguably its cousin.

Just curious: why you find it closer?

Length. like, size, ones, zeros are all similar in length and tend to be used for similar things. The word similar doesn’t seem to fit in. (This whole response is a mouthful).

Couldn’t this just be a method of copy, maybe with a keyword argument to say to copy only the structure, not the entries?

What problem are we trying to solve here?


My original suggestion was simply to replace similar with like, as it is a better choice of keyword:

  • shorter to write – 4 chars not 7
  • shorter to (sub)vocalize – 1 syllable not 3
  • reads better – x like y as opposed to x similar TO y, i.e. TO is required to make decent English, x similar y grates.

So it’s not really “solving a problem” per se. Unless the problem is “How to go about constructing the most elegant possible language?” in which case I think it is a minute step in the right direction.

I’m not saying it’s enough to act on it, but I do like it. But as @dpsanders noted, it would probably be most clear to just have it as a variant of copy.

Then how about shape if we are just trying to copy the structure?


… that actually makes linguistic sense. i.e. You could understand that without prior Julia knowledge, whereas both like and similar are both misleading.

i.e. rand!(like(M)) may make sense, but like(M) on its own doesn’t make sense. Because the thing it returns isn’t like M, it is the shape of M.

1 Like

rand(size(M)) currently works just fine for this; it’ll default to Float64 elements but you can easily specify the element type you want with rand(T, size(M)).

The biggest critique of similar also applies to the name like — it doesn’t really specify what parts of the “structure” are important and precisely in what regard it should be similar to the original array. At least some elements need to be mutable for the returned thing to be useful, but do all of them need to be? What type should be returned if the original array type doesn’t support the given shape? You’re really asking the original array to guess what data structure will be most efficient or most useful in the subsequent operations… which of course it cannot know.

Honestly, I don’t think similar is all that useful when you’re writing non-library code. It’s typically simpler, more readable, and more efficient (in terms of the subsequent complexity) to just be explicit and ask for Array{T}(sz) or use construct like rand(size(M)) above.


No it doesn’t work for this. That will create an Array with that size. Not every AbstractArray is an Array.