Why not leave those operators for more "advanced" users?
I also contest "++" and "--" operators are seriously tripping up "beginners". In most programming books, it's taught a few chapters in...
I also contest "++" and "--" operators are seriously tripping up "beginners". In most programming books, it's taught a few chapters in...
They also make the tools that consume that language slightly more complex. It doesn't sound like much, but in aggregate it's the difference between writing a parser for Java vs. a parser for C++.
I remember the day I first saw a '++'. It was a rainy night, and I was inspecting a colleague's for loop, when suddenly a '++' operator appeared. I asked myself, "What in the holy bacon of Zeus is that?" So I looked it up in my book. My head almost exploded, and I asked myself if I should quit programming immediately. It was simply too complicated. After four months of agony and pain I finally recovered and started programming again. And yet... Sometimes, when it's raining outside, the memories come back. Programming... No, my life will never be the same again.
I don't see how this is a valid reason to remove the operators completely. Beginners will get it wrong sometimes, so we should remove it?
Beginning users are likely to make all kinds of errors, so the implication would be maybe we should remove the entire language...?
Not to mention, pre-decrement and post-decrement are not complicated concepts. There are many valid reasons to use both, although post-increment/decrement seems to be the more common use.
Swift does include them, but puts a screaming "Unsafe" in front of their type names so that it's clear that unless you really know what you're doing, you're probably doing something wrong.
There's no way to do that with a ++ operator, so it's being removed.
Most people would agree C lets the developer do a lot of terrible things (by design, since some of those terrible things are necessary for low level stuff, which C was targeted at).
Pointers are confusing for a lot of people. Which is why almost no modern language uses them. Comparing "++" with C pointers is not a valid argument.
Even so, I would never argue to remove pointers from C, since you can optionally not use them. If you don't need that language construct in your program, don't use it. But leave it for others who do want/need it.
Confusing C-isms like pointers are what Swift is trying to get away from. This is another case of that.
"We're making a new language, it isn't C, but will share some characteristics. Which should those be?" is the question being asked here.
The problem, Swift is unlikely to be a "beginner's language"... since it's predominantly (at least for now) an Apple language; used almost exclusively for making iOS apps.
To make an iOS app, you have to have an Apple Developer license, be paid up on fees, own a very expensive Mac, and pay Apple to put your app in the store.
None of which is something a beginner, just starting to learn programming, is likely to do.
> be paid up on fees
This isn't true anymore, FWIW. Also, OS X apps exist.
I mean, its predecessor allowed you to mutate your class hierarchy at runtime, and this was a thing that people commonly did!
"You can't do that" is a powerful tool for making code safer.
It's literally no different than having to remember what "+=" does... which is what's being proposed as the alternative.
> Reading is more important than writing
I would agree, but "x++" is not difficult to read. It's more concise than having to read "x += 1". Or worse, beginners will think it's clever to define constants for this so now you'll get "x += INCREMENT_VALUE", making you have to go lookup whatever "INCREMENT_VALUE" is, etc...
You already have to remember what "+=" does though. If they kept ++ you'd have to learn both.
"+=" is no better.
If you're going to campaign against "++", might as well go all the way back to BASIC days and only allow "x = x + 1"
Because "-" is part of the domain language (mathematics).
> The concept of incrementing or decrementing a value is trivial.
For a normal function (i.e. something that could be implemented as library functionality) then I agree with you. But for a language-level operator, it's a special case. It probably has its own precedence. It definitely complicates the metamodel.
> If you're going to campaign against "++", might as well go all the way back to BASIC days and only allow "x = x + 1"
I would. How many times do you need to add 1 to something anyway?
And by induction you can use this argument to allow any amount of bullshit in a language.
>"+=" is no better.
"+= x" saves you from "= long_variable_name + x" which is arguably less readable.
"++" saves you from ... "+= 1" which is already entirely clear, and I have no idea why anyone feels the need to shorten it.
Sure it's a relatively small complexity cost, but it's also an even more microscopic advantage.
long_variable_name = long_variable_name + 1
Autocompletion is a wonderful tool that every developer should use, if only to reduce the possibility of `long_variable_name = long_varable_name + 1` in their code.