4 ms·
I think what a new developer would try first isn't a particularly good yardstick for language design. But I also think that the removal of ++ causes some proble
by fauigerzigerk 11y ago
I think what a new developer would try first isn't a particularly good yardstick for language design. But I also think that the removal of ++ causes some problems.
For instance, now I have this code
mutating func next() -> Element? {
//...
pos += 1
return data[pos-1]
}
or alternatively
mutating func next() -> Element? {
//...
let e = data[pos]
pos += 1
return e
}
where previously I had
mutating func next() -> Element? {
//...
return data[pos++]
}
- chrisamanse 11y agoIMHO, ++ is not readable. A beginner would think that data[pos++] is the same as data[pos+1] when it's actually, data[pos]; pos = pos + 1;.
- fauigerzigerk 11y agoI don't care what beginners might think. I care about the mental load for professional developers. Beginners can learn.
- kartickv 11y agoA beginner should be made to learn something only if they get an advantage out of it in readability or type safety or performance or something else. I don't see that being the case for pre- and post-increment. If anything, I find: i += 1; String name = names[i]; more readable than String name = names[++i]; where I have to pause and remind myself of pre- and post- increment and which one is being used here and mentally translate the code into the above version. Imperative languages already have a way of specifying execution order: it's the order of statements in your file. Let's reuse that rather than making things more complex.
- felixgallo 11y agoIn your list of things that beginners must get an advantage out of, you left out functionality and brevity. Hope that helps.
- kartickv 11y agoI don't see a difference in functionality — both code snippets I gave do exactly the same thing. As for brevity, I think clarity is more important. We should optimise for the time it takes to read and understand the code (clarity), not just read (brevity). The best abstractions and programming language features are both brief and clear, like Python's list comprehensions. I find [name.uppercase() for name in names if name.startswith("a")] to be clearer than Java's List<String> uppercaseNames = new ArrayList<>(); for (String name: names) { if (name.startsWith("a")) uppercaseNames.add(name.toUpperCase()); } So, the best programming language features enhance both brevity and clarity. When that's not possible, I'll take slightly longer but clearer code over short but confusing one.
- danneu 11y agoI've seen ++i vs i++ cause so many bugs that whenever I see it, I stop to ponder if the author got it right. It's like in Javascript where I stop to check if the author intended for `if (x)` to take the false path if x is "" and 0. It's death by a thousand papercuts for my mental load.
- stevetrewick 11y agoIMHO ++ is trivially readable, but that's only because I happen to be familiar with C/C++'s pre/post increment idiom. An idiom which is well known for causing confusion and bugs, especially - as you say - for devs new to the language. For me the compelling argument for removing them is that they're a Cism and don't fit with the semantics of any of the other operators. Chris Lattner strongly agrees with you and explains his reasons here https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md https://github.com/apple/swift-evolution/blob/master/proposa...
- jayrhynas 11y agoFYI, a third option is mutating func next() -> Element? { //... defer { pos += 1 } return pos } Whether it's better is a matter of opinion
- stevetrewick 11y agoNice. That's a beautifully idiomatic implementation of the original intent of post increment, if nothing else.
- jayrhynas 11y agoI just realized there's a small typo in the above, it should be return data[pos]