So you know what Apple will do when they hit hard times? And you know this because...? Did they do this in the past when they were on the ropes? No? Then, what? Is it general cynicism or Apple-specific hatred?
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.
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?"
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.
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.
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.
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.
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.
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.
If your requirements are such that your "virtualized" machines can all run FreeBSD, then there is no reason not to leverage the jail system. It is robust, fast, and very secure. The current version of FreeBSD has added features to jail making it even more attractive (as well as simple to use and maintain). And since you are running FreeBSD, you have access to CARP, providing load-balancing and failover, as well as ZFS, the bee's knees of file systems.
Compare this with a vm solution (pick your favorite), where not only do you have to maintain multiple OS instances (one per VM) but also have to maintain the vm structure itself. I am not claiming that either of these tasks are that onerous, rather that they are tasks that are not required in the jail solution. And what do you get in return for these extra steps that you do not get with a jail? By all means, if there is something that a vm solution provides that cannot be done in a jail, then go for it; but dismissing jails out-of-hand doesn't serve anybody.
If all of your virtual machines can fun FreeBSD, the question really becomes, "why introduce levels of complexity when they are not required, impact performance, add security risks, and make the overall system more difficult to maintain?" The problem with a FreeBSD jail/carp/zfs solution isn't that it is inferior in any way; rather that, looking at OS popularity, FreeBSD is a distant third (forth really, but virtualizing Mac OS breaks licenses (and I don't really know where Solaris fits)) so FreeBSD is frequently not an option as it may not meet the requirements of the application. This may be mitigated with the Linux compatibility package and/or Wine; but you may want to run your Linux applications on a Linux machine (virual or otherwise), and likewise with your Windows apps.
It is important to note that Sun is selling a RAID-Z solution, which is far superior to a simple RAID-5. It offers data integrity, a uniform simple interface, and extra features (snapshots, cloning, etc.) that are not part of the RAID-5 specification. Plus, it doesn't have the RAID-5 write hole.
RAID-Z (as well as it's other flavors, e.g., RAID-Z2) is not just a way to arrange disks to be more reliable and/or provide better throughput, but is an advanced file system. This means that RAID-Z offers features like compression, privileges, quotas, etc. that are above and beyond the RAID-5 specification. This is a good thing or a bad thing, depending on your requirements (probably a good thing, 'though).
One of the advantages of having a ZFS-based RAID in this type of configuration is the ZFS file system is transaction-based and so performs better in a network configuration, where local caching of data can corrupt file systems without like features (see http://blogs.sun.com/roch/entry/nfs_and_zfs_a_fine).
RAID-Z will require more write I/O and CPU than a hardware-based RAID solution, but it is possible that Sun has create such hardware in their (quite expensive) solution. At the same time, if you are creating a dedicated network storage device rather than sharing the hardware with other activities, you'll never notice the extra overhead. And if you don't want to buy Sun's hardware, they have given the RAID software away, so you can build your own at no (additional) cost.
CDs and DVDs are photosensitive when creating the media. The media looses its ability to change over time, thus a blank CD or DVD will no longer be reliable for recording new data after a few years. However, once data has been burned on the disc, the previously photosensitive layer becomes stable and should last longer than the user who did the burning. In other words, blank discs go bad whereas burned discs remain fine and dandy.
Discs are susceptible to physical damage (scratches, etc.) whereas tape is susceptible to magnetic damage and wear-and-tear. Unlike SatanicPuppy, I have experienced loss of data on tapes, resulting in a non-insignificant cost to replace.
Also, examining the problem from the cost side, DVD media is currently roughly half the cost per byte of tapes and the DVD burners are orders of magnitude less expensive than tape drives. Granted, each disk holds orders of magnitude less data; still, finding the disc containing the required data and retrieving it will take less time than performing the same with a tape (although most of the tape access time requires minimal user interaction).
And if you don't mind spending the money, you can get a DVD jukebox for the roughly the same cost as a decent tape drive, providing the same storage capacity for less cost and using media which is universally readable by any computer made in the last five years (ignoring some silly mini-laptops).
But the truth is that, for the majority of users, a simple DVD backup solution is perfectly acceptable, leveraging their existing hardware to provide a long-term, reliable backup of their important data. Combine this with a RAID-Z (or RAID-Z2 for the paranoid) on drives that attempt to warn when sensing that their days are numbered (S.M.A.R.T., etc.) and the chance of loosing data is close to zero.
The FreeBSD handbook is a treasure trove of invaluable UNIX information. The majority of the content found therein is applicable to all *NIX operating systems. It is available, for free, in a variety of languages and formats.
Slashdot Mirror
So you know what Apple will do when they hit hard times? And you know this because...? Did they do this in the past when they were on the ropes? No? Then, what? Is it general cynicism or Apple-specific hatred?
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:
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.
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?"
Octave is an open-source Matlab, not Mathematica.
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.
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.
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.
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.
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.
There are many other open-source licenses besides GPL.
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.
You should check out They Might Be Giants' newest album "Here Comes Science" (a CD/DVD combo, available at Amazon for $13).
If your requirements are such that your "virtualized" machines can all run FreeBSD, then there is no reason not to leverage the jail system. It is robust, fast, and very secure. The current version of FreeBSD has added features to jail making it even more attractive (as well as simple to use and maintain). And since you are running FreeBSD, you have access to CARP, providing load-balancing and failover, as well as ZFS, the bee's knees of file systems.
Compare this with a vm solution (pick your favorite), where not only do you have to maintain multiple OS instances (one per VM) but also have to maintain the vm structure itself. I am not claiming that either of these tasks are that onerous, rather that they are tasks that are not required in the jail solution. And what do you get in return for these extra steps that you do not get with a jail? By all means, if there is something that a vm solution provides that cannot be done in a jail, then go for it; but dismissing jails out-of-hand doesn't serve anybody.
If all of your virtual machines can fun FreeBSD, the question really becomes, "why introduce levels of complexity when they are not required, impact performance, add security risks, and make the overall system more difficult to maintain?" The problem with a FreeBSD jail/carp/zfs solution isn't that it is inferior in any way; rather that, looking at OS popularity, FreeBSD is a distant third (forth really, but virtualizing Mac OS breaks licenses (and I don't really know where Solaris fits)) so FreeBSD is frequently not an option as it may not meet the requirements of the application. This may be mitigated with the Linux compatibility package and/or Wine; but you may want to run your Linux applications on a Linux machine (virual or otherwise), and likewise with your Windows apps.
RAID-Z (as well as it's other flavors, e.g., RAID-Z2) is not just a way to arrange disks to be more reliable and/or provide better throughput, but is an advanced file system. This means that RAID-Z offers features like compression, privileges, quotas, etc. that are above and beyond the RAID-5 specification. This is a good thing or a bad thing, depending on your requirements (probably a good thing, 'though).
One of the advantages of having a ZFS-based RAID in this type of configuration is the ZFS file system is transaction-based and so performs better in a network configuration, where local caching of data can corrupt file systems without like features (see http://blogs.sun.com/roch/entry/nfs_and_zfs_a_fine).
RAID-Z will require more write I/O and CPU than a hardware-based RAID solution, but it is possible that Sun has create such hardware in their (quite expensive) solution. At the same time, if you are creating a dedicated network storage device rather than sharing the hardware with other activities, you'll never notice the extra overhead. And if you don't want to buy Sun's hardware, they have given the RAID software away, so you can build your own at no (additional) cost.
Discs are susceptible to physical damage (scratches, etc.) whereas tape is susceptible to magnetic damage and wear-and-tear. Unlike SatanicPuppy, I have experienced loss of data on tapes, resulting in a non-insignificant cost to replace.
Also, examining the problem from the cost side, DVD media is currently roughly half the cost per byte of tapes and the DVD burners are orders of magnitude less expensive than tape drives. Granted, each disk holds orders of magnitude less data; still, finding the disc containing the required data and retrieving it will take less time than performing the same with a tape (although most of the tape access time requires minimal user interaction).
And if you don't mind spending the money, you can get a DVD jukebox for the roughly the same cost as a decent tape drive, providing the same storage capacity for less cost and using media which is universally readable by any computer made in the last five years (ignoring some silly mini-laptops).
But the truth is that, for the majority of users, a simple DVD backup solution is perfectly acceptable, leveraging their existing hardware to provide a long-term, reliable backup of their important data. Combine this with a RAID-Z (or RAID-Z2 for the paranoid) on drives that attempt to warn when sensing that their days are numbered (S.M.A.R.T., etc.) and the chance of loosing data is close to zero.
you can browse it online at:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/index.html
or download an English version from:
ftp://ftp.freebsd.org/pub/FreeBSD/doc/en/books/handbook
Other find manuals of relative interest to the Unix community can be found there, too.