Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

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 ? : operator, but I'll survive (I hope you like wordy code); but take away my ++ and -- and coding becomes constant frustration that raises my stress level and will eventually lay me low.

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:Swift is always doing non compat updates (Score 4, Informative) 148

The ++ operator is not the same as += 1 operation. For example,

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

Whoa! At no point did I say "don't learn vi" or even "don't enjoy vi", certainly not "whine if you are stuck with vi" or "gouge the customer because they only provided vi." Rather, that vi (like emacs) is old and that, with a very few exceptions, every Unix distribution ships with alternative editors. Moreover, that the chances are very high that one of those editors uses emacs control sequences, at least to navigate about the document. Thus, the skill set you acquire learning emacs will serve you well using other tools. Heck, bash uses emacs sequences to navigate, kill and yank, and even search your command history.

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

If your new Unix does not have emacs but you want to use it, then Install it. Or use one of the many editors that use the same key-strokes (zile, mg, tm). Heck, even nano/pico use emacs key-strokes for most of their operation. Long and short, if you learn the fantastic editor, you can bring it with you or use one of the lesser-featured editors that probably are available that map to your skill-set. To take the argument that "don't use X because it isn't guaranteed to be everywhere you will be in the future" a bit farther, you shouldn't use Unix because your next assignment might have you using Windows -- Windows may not be as good, it is everywhere, so use that.

Comment Scroll bar (Score 1) 161

When is emacs going to get horizontal scroll bars? Now that M-g gives me goto-line (ok, M-g M-g - whatever), the lack of them there scroll bars is the only that keeps me using XEmacs.

Comment Re:To what degree? (Score 1) 260

I hope you are joking. Certainly there are fantastic people working on fantastic products that are GPL licensed. However, GPL is inappropriate for applications develpoed by vendors to be used by government. There are a multitude of open source licenses that would be more appropriate for this task (Apache, BSD, MIT, to name a few).

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:iPhone still looks wise comparatively (Score 1) 242

Actually, jailbreaking is a *nix term, originating from code that is able to break out of a BSD jail. It basically refers to code that is able to access files that is otherwise protected (operating system, file protections, encryption, etc.). Rooting on the other hand refers to the ability to execute code with root privileges. Both refer to privileged escalation, jailbreak generally refers to file access whereas root generally refers to process access. Both of these terms have changes over time (e.g., Sony has a "rootkit" in some CDs that only affected MS Windows).

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.

PlayStation (Games)

US Air Force Buying Another 2,200 PS3s 144

bleedingpegasus sends word that the US Air Force will be grabbing up 2,200 new PlayStation 3 consoles for research into supercomputing. They already have a cluster made from 336 of the old-style (non-Slim) consoles, which they've used for a variety of purposes, including "processing multiple radar images into higher resolution composite images (known as synthetic aperture radar image formation), high-def video processing, and 'neuromorphic computing.'" According to the Justification Review Document (DOC), "Once the hardware configuration is implemented, software code will be developed in-house for cluster implementation utilizing a Linux-based operating software."

Slashdot Top Deals

10 to the minus 6th power Movie = 1 Microfilm

Working...