Comment 23 vs. 24 (Score 1) 74
Comment Re:While I think it's true (Score 1) 185
Comment Re:Increment and decrement (Score 1) 339
Well, my question was not "why were they removed?", but "what can I do to get them back?". And they were removed -- they were there!
I have seen the link (back when it was just a proposal), and I cannot find a compelling removal reason in the list of disadvantages. Let's cover each in turn:
- 1. new users. Add one or subtract one is difficult? I think not. Plus, removing a great feature because it may be difficult for some users to learn is weak — might as well ban regular expressions all together.
- 2. minimal expressive difference. I could not disagree more. Not only am I saving keystrokes when typing, but it takes me significantly less time to undertand the meaning of x++ than x += 1 when I come across them in code. Again, increment and decrement are concepts apart from full-up addition, and having dedicated operators increases the overall exressiveness of the language.
- 3. Swift isn't c. This is a truly spurious reason. Neither is Perl, Python, Go, Ruby, JavaScript, Matlab, Mathematica, etc. And yet Swift still has the bitwise operators from c, so this disadvantage can be little more than list padding.
- 4. Swift has features that replace many of the typical uses of ++ and --. This is true, as far as it goes. However, increment are decrement are used in significantly more instances than as a loop counter.
- 5. ++ and -- are hard to read and encourage "tricky" code. I believe this is conflating two concerns: confusing and makes for "tricky" code. Well, I cannot disagree with the first more; I assert that the semantics of ++ and -- are well understood and their appearance saves significant time when parsing by the maintainer. As for "tricky" coders — well, they'll screw you no matter what you do (you can write FORTRAN code in any language — or see http://www.mindprod.com/jgloss/unmain.html). Basically, don't hobble the language in anticipation of "misuse".
- 6. the result of ++ and -- are difficult to predict, even with well defined operator precedence. I don't buy it. But again, there will be jerks that write difficult to understand code. If they really scare you, then follow one of the presented alternatives and remove the pre versions or post versions, but not both! Or, even better, have Xcode flag their convoluted use (or generate a compiler warning for those who don't use/have Xcode).
- 7. not every data type can use them. Spurious. What about %, ~, |, ^, &, <<, >>, &+, &-, or unary - and +?. Not to mention the logical operators (|| and &&), which had typically supported types removed! Moreover, increment and decrement are useful to add to a class (more so than, say, bitwise or).
The above list seems seems so negative, I know. What is missing is the positives that increment and decrement provide; I tried to express that before. Sure, I'd love to have the ?
Comment Increment and decrement (Score 1) 339
My biggest surprise with Swift was the removal of the pre and post increment and decrement (++ and --) in Swift 3. These are well defined and commonly used operators — heck, the name of one of the most popular languages is a word-play on the post-increment operator. In fact, you'd be hard-pressed to find another modern language out there that does not have them.
My real issue is that they are part of the coding part of my brain — when I want to increment, I automatically type "++". Sure, Xcode will offer to "fix" it for me; but that means that Xcode knows what I mean!
At the center of my issue is there is meaning beyond "add one" or "subtract one" in those operators: increment is a concept that, yes, when applied to a number, is equivalent to adding one to that number; but when the developer (e.g., me) sees the increment operator, there is immediate communication of what is transpiring without having to (visually — again, it's the developer to whom I am referring) parse an equation, then further determine if it is really an arithmetic operation or an increment. For instance, I don't think a language called "c += 1" would have caught on.
The problem of conflating incrementing and decrementing with addition and subtraction becomes even worse when considering operator overloading. For example, if I am creating a class where it is meaningful to increment or decrement but not to support full-blown addition or subtraction, without ++ and --, I am stuck with implementing addition and subtraction methods that throw runtime exceptions when given values other than 1.
You may counter that everybody can easily get along without them. Well, if you did, I would respond that, no, I am running into this all of the time and it drives me a bit nuts (ok, a bit more nuts).
Basically, the solution to encountering these handy, meaningful, and otherwise universally available operators should not be "stop using them" — especially when Swift used to have them!
So, I guess my question is not "why were they removed?", but rather "what can I do to get them re-added?"
Comment Re:Mathematica is pay to play only (Score 2) 241
Comment Re:Swift is always doing non compat updates (Score 4, Informative) 148
var a = 3
let b = a++ * 3
Now, I expect this type of code is the justification Apple is using to remove the operator; although there is no ambiguity, the line which sets b also sets a.
I argue that prefix and postfix ++ and -- should have remained in Swift. Not only are they well defined, but they are a standard operator in almost all new languages and therefore convey their meaning to the application developer significantly better than += 1 or -= 1 ever could.
For example, when reading code, ++i requires significantly less reading and parsing by the developer than i += 1 to convey the same idea.
Comment Re:Which editor? (Score 1) 161
Thus, when someone asks "I learned emacs and now I find myself on a computer that has no emacs," I respond, "install it or use an editor that is similar." This seems (to me, at least) more help than "you were foolish to learn an editor that is not installed on every unix; go learn vi."
When I visit a customer, I bring a disc containing distributions of lots of tools, including editors. You do not need extra privileges to compile and run these tools (well most of them, anyway -- certainly not a text editor!) and it solves the issue of not knowing which flavor of Unix you will be facing. Additionally, it reflects that you, in fact, know what you are doing. At least in my experience.
By all means embrace vi (or vim or viper or whatever). It has been used to build fantastic things. But you ought not object to others using some other editor. I suspect you'll have a difficult time having fun with that attitude.
Comment Re:Which editor? (Score 2) 161
Comment Scroll bar (Score 1) 161
Comment Re:To what degree? (Score 1) 260
It seems you have some kind of axe to grind, and that's fine. But to claim that products such as Clang/LLVM, FreeBSD, Eclipse, FireFox, Perl, Tomcat, etc. somehow do not matter because they do not meet your requirement that they are not GNU (and thus aren't truly free because you can take their source code and do with it what you like, or that derrived works don't enforce a license, or they don't hace a wildebeast mascot... I don't actually know why you think non-GNU = trivial) sounds uninformed, glib, or narrow-minded, at least to my ears.
Comment Re:To what degree? (Score 1) 260
There are many other open-source licenses besides GPL.
Comment Re:iPhone still looks wise comparatively (Score 1) 242
However, I think it is fair to say that in today's world, a jailbreak is something that is done intentionally by the owner of a device to gain access to features that are otherwise denied, whereas rooting is done by nefarious n'er-do-wells with evil intent. Oh yeah, and Sony.
Comment Here Comes Science (Score 2, Informative) 368