3 ms·
But it doesn't matter. If the language is unreadable, even if every syntactic decision followed by necessity alone from a set of first principles, it wouldn't p
by edflsafoiewq 7y ago
But it doesn't matter. If the language is unreadable, even if every syntactic decision followed by necessity alone from a set of first principles, it wouldn't prove the language was readable. It would only prove the selected principles necessitate an unreadable language.
Compare [x for x, y in v] to v.iter().map(|&(x,y)| x).collect::<Vec<_>>(). There is a good reason for every bit of ugliness, but that does not change the fact that it is ugly.
- saghm 7y agoI agree that the snippet you gave is ugly, but I also think that it's not really the most straightforward way to right it. Any time the type that you're collecting into isn't inferred, you're free to define a binding and just type annotate it. Also, the lambda you gave is not defined in the straightforward way I think most people would define it. Putting those together, you get something like this: ``` let vec: Vec<_> = v.iter().map(|pair| pair.0).collect(); ``` I don't think that's really _that_ ugly. Yes, the pithy Python example you gave is simpler, but by the same token, the assembly you would write to achieve this makes the Rust look really simple. If you're going to try to write efficient code in a systems language like Rust, you're going to need to express things more precisely than you would in a scripting language like Python.
- sgift 7y agoReadability is very often nothing else but habit - code which looks like code you've seen often enough looks well. Case in point: The first example is just gibberish to me and I needed the second one to decipher it. Also, I would write the second example different: let r: Vec<_> = v.iter().map(|(x,_)| x).collect(); In my opinion that's superior in readability to both of your examples, but probably also only because I'm used to it.
- deleted 7y ago[deleted]
- edflsafoiewq 7y agoYour r has a different type.