71–80 of 249 posts
Earlier quoted context omitted.
>Why does '+' (and friends) get this special form, but not my functions? Your functions can get that (and other) special form. You need to use a language where you can define your own operators. Have you looked at C++, C#, Haskell, or LISP?
Huh. C++? You can overload operators, but define your own? I must have missed something.
Removing ++ et al: ok, they have their problems. But retaining x += 1? That one has always annoyed me. Why does '+' (and friends) get this special form, but not my functions? Just because they're built-in. They are useful; no argument there. Largely because 'x' can be a complex reference, and you don't have to type it twice (and the compiler doesn't have to figure out that its the same expression twice). E.g. x=x+1 i…
Another way to express this is, I'd like a language keyword for "left hand side of assignment". Then for x=x+1 I could say x = + 1; It could then get arbitrarily complex. E.g. x = ( + 1) / atan( ) - ; and no matter how complex 'x' was in practice, the compiler (and the code reader) could keep track of what was happening.
y = (x + 1) / atan(x) - x;
x = y; // If you're in a loop and updating some value
Earlier quoted context omitted.
"These operators increase the burden to learn Swift as a first programming language" It looks like they may be trying to make it easier for current tweens that would have otherwise learned PHP. Don't see the value in this. These operators are terse, well known, and are implemented in a wide array of languages.
Well known for old timers. But some folks have an actual issue understanding them. For those of us that are comfortable; fine, no issue. But they are a little strange; the order of operations in a complex expression can be hard to tease out for novices. Are they worth it?
This half-reeks of something that a professional/advanced user thinks trips up beginners without actually tripping up beginners. Or they have an anecdotal sample size of n < 10 and decided since it confused 1 person that 10% of people get confused.
Removing ++ et al: ok, they have their problems. But retaining x += 1? That one has always annoyed me. Why does '+' (and friends) get this special form, but not my functions? Just because they're built-in. They are useful; no argument there. Largely because 'x' can be a complex reference, and you don't have to type it twice (and the compiler doesn't have to figure out that its the same expression twice). E.g. x=x+1 i…
>Why does '+' (and friends) get this special form, but not my functions? Your functions can get that (and other) special form. You need to use a language where you can define your own operators. Have you looked at C++, C#, Haskell, or LISP?
AFAIK, Lisp doesn't have syntactically-distinct operators at all just functions which may have names similar to operators used in other languages, and C# and C++ don't seem to support custom operators at all. [0]
OTOH, Perl 6 has robust support for custom operators.
[0] except that C++ has apparently been hacked to create custom operators with some limitations via macros [1]
[1] http://www.codeproject.com/Articles/31783/Custom-User-Define...
> Their expressive advantage is minimal - x++ is not much shorter than x += 1 Personal opinion, but I definitely miss '++' every time I'm doing '+=' in Python.
I think I'd argue with the "not much shorter" because it's less typing to perform a `++` versus `+=1`; I hold shift, I type the = key, obtaining the +, then I have to pause typing long enough to release the shift key, type the = key again, and now my other hand has to get involved and type a 1. And that's without the spaces.
Slow, and my fingers have to jump completely over the keyboard.
What is far more annoying, and should be banned, are `these` (I have to press shift+' twice to get one `, otherwise I end up with á' instead of `a`), and {}[], as they are on AltGr+7/8/9/0
I strongly disagree with this. Being able to do a very simple task like increment or decrement a number inline is useful and reduces clutter and I've always found the idea that the operator complicates things ridiculous. The way they work has always been obvious to me since I first learned to program in PHP as a tween.
"These operators increase the burden to learn Swift as a first programming language" It looks like they may be trying to make it easier for current tweens that would have otherwise learned PHP. Don't see the value in this. These operators are terse, well known, and are implemented in a wide array of languages.
Go’s compromise here is that these operators are statements, not expressions. There is no return value. This makes it semantically identical to i += 1. It keeps some sugar while removing some classes of gotcha.
Just having `i += 1` would seem more in line with Go's professed Simplicity philosophy. When both `++i` and `i += 1` mean the same thing, you might as well drop one of them. `++i` (and/or I guess `i++`) is barely syntactic sugar.
main.go:6:2: should replace i += 1 with i++
I strongly disagree with this. Being able to do a very simple task like increment or decrement a number inline is useful and reduces clutter and I've always found the idea that the operator complicates things ridiculous. The way they work has always been obvious to me since I first learned to program in PHP as a tween.
++ is a rare situation since the introduction of foreach. For example in the JVM checking for null would deserve an operator.
maybeNull?.getContent()?.toString()
This would improve my coding sooo much.
Currently I use Optional.fromNullable(maybeNull).orElse(new DummyObjectThatReturnsNullOnAllMethodCalls).getContent(), and then repeat the process.
Earlier quoted context omitted.
Another way to express this is, I'd like a language keyword for "left hand side of assignment". Then for x=x+1 I could say x = + 1; It could then get arbitrarily complex. E.g. x = ( + 1) / atan( ) - ; and no matter how complex 'x' was in practice, the compiler (and the code reader) could keep track of what was happening.
Is there a significant benefit to this over using a new name for the result? y = (x + 1) / atan(x) - x; x = y; // If you're in a loop and updating some value If would hope/imagine that a compiler could reduce the two to the same code - and I don't think it reads any worse. Is there a downside beyond the extra line of code?
X &x = { complex reference expression for x }
y = (x + 1) / atan(x) - x;
Why was this decision made?