Slashdot Mirror


Apple Releases First Preview of Swift 3.0 (macrumors.com)

DaGoatSpanka quotes a report from MacRumors: Apple yesterday released the first preview build of Swift 3.0, a major update to Apple's open source Swift programming language. Swift 3.0's official release is expected to come in late 2016 after proposed changes are finalized. The Swift 3.0 preview can be downloaded from the official Swift website. There are versions of Swift 3.0 available for Xcode 7.2, Ubuntu 14.04, and Ubuntu 15.10. [Swift 3.0 is not source compatible with Swift 2.2 as it introduces source-breaking changes, but going forward, the goal is to make Swift 3.0 source compatible with future Swift language updates.] Swift 3.0 will likely be shown at Apple's upcoming Worldwide Developers Conference (WWDC).

227 comments

  1. what did they break this time by Anonymous Coward · · Score: 4, Funny

    Last release broke for loops, what was broken now? If statements??

    1. Re:what did they break this time by pushing-robot · · Score: 5, Informative

      No, function calls.

      https://www.hackingwithswift.c...

      Yes, it'll make code shorter and simpler, but renaming most library methods is still a kick in the teeth to developers.

      --
      How can I believe you when you tell me what I don't want to hear?
    2. Re: what did they break this time by hsmith · · Score: 2

      What a fucking disaster. I like swift a lot more than ObjC, but this shit is insane.

    3. Re:what did they break this time by Anonymous Coward · · Score: 0

      Banned more offensive words.

    4. Re:what did they break this time by Anonymous Coward · · Score: 0

      unary increments and decrements (aka "++" and "--")

    5. Re:what did they break this time by Beezlebub33 · · Score: 4, Insightful

      And enums, apparently.

      I understand having it consistent (which is their argument for the changes), but this just means that they they screwed it up in 1 and 2. Seriously, you change naming conventions from UpperCamelCase to lowerCamelCase? Now? That's the sort of decision that should be made (with reasons) when you are designing the language the first time; and then you have a group of really nitpicky, anal-retentive types go through the language to check for all the inconsistencies, and then you fix them, and then you release it. This whole thing screams amateur hour; yeah, I understand it a little more when python says 'oops, we messed up because there was a single guy who designed the language, and he didn't have a team behind him'. However, this is frigging Apple, and they have lots of people and money, and Swift was (I hope??) intended from pretty early on to be where people were going to go, so it should have been done right the first time or two.

      --
      The more people I meet, the better I like my dog.
    6. Re:what did they break this time by Anonymous Coward · · Score: 0

      What's wrong with breaking things? When a new language release doesn't break anything, like Java, everybody complains about wrong decisions made for keeping backwards compatibility. So this is the right thing to do, isn't it?

    7. Re:what did they break this time by pushing-robot · · Score: 5, Insightful

      Swift inherited this mess from Objective-C. The Swift team stuck with the old conventions for a while to make the transition easier, but now they want to shed the ugly bits and move forward. I'm not sure there's a better way they could have handled this, to be honest. Everything has tradeoffs.

      --
      How can I believe you when you tell me what I don't want to hear?
    8. Re:what did they break this time by Maury+Markowitz · · Score: 4, Informative

      Clearly all the people complaining don't actually use Swift for production code and/or just like to complain.

      I converted my antenna modelling project to 3.0 in about three minutes. Most of this was due to the new selector syntax, which I had to spend time looking up on Stackoverflow. The rest was trivial, and my code is cleaner and shorter than ever.

    9. Re:what did they break this time by 110010001000 · · Score: 0

      You don't know what production code is. Your personal projects are not production code.

    10. Re:what did they break this time by Anonymous Coward · · Score: 1

      If you are using a new language like Swift for production code you are an idiot.
      Professionals use mature languages for a reason, this isn't like moving from Python 2.7 to 3.0.

    11. Re:what did they break this time by angel'o'sphere · · Score: 1

      If the code is in production it is production code.
      Plain and simply.

      No idea why you want to piss every one on /. off all the time with your insults.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    12. Re: what did they break this time by Anonymous Coward · · Score: 0

      They should pretend it's not broken in 1 and 2, and leave it broken?

    13. Re:what did they break this time by Anonymous Coward · · Score: 0

      It seemed like an appropriate response to the bullshit comment actually.

    14. Re:what did they break this time by Anonymous Coward · · Score: 0

      In order to improve the experience, they removed support from last year's iphone model.

    15. Re: what did they break this time by hawkbug · · Score: 2

      I agree. Every damn time they update Xcode, I'm having to refactor code. This is bullshit.

    16. Re:what did they break this time by edxwelch · · Score: 1

      Yeah right, and Apple were forced to use Objective C against their wishes?

    17. Re:what did they break this time by rochrist · · Score: 1

      Given the way OS X came about, yeah, pretty much.

    18. Re:what did they break this time by jeremyp · · Score: 1

      Last release broke for loops,

      No it didn't, it deprecated C style for loops but they still compiled with a warning. It's this release that breaks them - but only the C style ones.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    19. Re:what did they break this time by Anonymous Coward · · Score: 0

      ... but now they want to shed the ugly bits and move forward. I'm not sure there's a better way they could have handled this, to be honest. Everything has tradeoffs.

      Wonder boy bullshit moves.
      Remove and change long defined and understood properties and behaviors, because junior thinks they are hard.

    20. Re:what did they break this time by Szeraax · · Score: 1

      I believe that with the aforementioned change, it should be called swift instead of Swift. Is that correct?

    21. Re:what did they break this time by Anonymous Coward · · Score: 0

      Oops! You appear to have an ad blocker enabled.

      The adverts on this site are small and unintrusive,
      but they help fund my work and without them I cannot
      give these tutorials away for free.

      If you do not want to view ads, please buy the
      e-book from https://gum.co/hws-book-pack – it
      includes every project as a downloadable,
      ad-free package.

      If you want to carry on reading here, you will
      need to disable your ad blocker then reload the
      page in order to see this source code.

      I'm sorry that I have to do this, but please
      understand that it costs me money to host these
      tutorials, so when you block my adverts I am literally
      paying for you to learn. That is simply not fair, and
      I hope you will add an exception to your ad blocker
      for this site.

      Questions? Comments? Tweet me: @twostraws

    22. Re:what did they break this time by shutdown+-p+now · · Score: 1

      Breaking things is fine when there's a good reason to break them. Changing your naming convention from PascalCase to camelCase is not a good reason.

  2. "source-breaking changes" by Anonymous Coward · · Score: 1

    Swift 3.0 is not source compatible with Swift 2.2 as it introduces source-breaking changes

    And thus, Swift will forever remain nothing more than a toy language for worthless apps.

    1. Re: "source-breaking changes" by Anonymous Coward · · Score: 1, Funny

      I believe they are following the Python model of gathering followers and then breaking their libraries on the 3.0 release.

    2. Re: "source-breaking changes" by dgatwood · · Score: 1

      No, they're one-upping Python and breaking source compatibility with every release. :-D

      They say that everything from 3.0 onwards should be source-compatible, but lots of folks were also saying that for 2.0, so... I'll start paying attention to Swift when there are no big source compatibility regressions for two major releases in a row.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

  3. The "new" trend - eternal Alpha... by Megol · · Score: 1, Insightful

    Make no mistake: this isn't Swift version 3 - it is the language Swift 3. I guess Swift 4 will not be (completely) backwards compatible either. Because the idea of a programming language evolving from a stable, thoroughly tested base specification is old - not fit for the Apple(TM) generation...

    1. Re:The "new" trend - eternal Alpha... by LifesABeach · · Score: 1

      I've got a question for the Swift people, "How OpenGL interfaceable?" Else, have a nice day.

    2. Re:The "new" trend - eternal Alpha... by pushing-robot · · Score: 2

      To be fair, the language just hit two years old today. Most languages were still in flux at that age.

      --
      How can I believe you when you tell me what I don't want to hear?
    3. Re:The "new" trend - eternal Alpha... by Anonymous Coward · · Score: 0

      Easily interfaces with C, obviously including OpenGL. Which you could have found out with one quick search.

    4. Re:The "new" trend - eternal Alpha... by Anonymous Coward · · Score: 0

      Apple has always done this with everything they do. They don't treat backwards-compatibility as ultra important like Microsoft does.

      Apple's philosophy is they want to move forward as quickly as possible, and the best way is to ignore the past. Don't keep old remnants around. Microsoft will keep backwards compatibility over their cold dead bodies. Even old bugs / side-effects that developers exploited in ingenious ways, they'll make sure those bugs / side-effects are still around in future versions.

      Also, Swift is still new. Apple promises from Swift 3 onwards, backwards-compatibility will be more in their thoughts.

    5. Re:The "new" trend - eternal Alpha... by macs4all · · Score: 1

      Make no mistake: this isn't Swift version 3 - it is the language Swift 3. I guess Swift 4 will not be (completely) backwards compatible either. Because the idea of a programming language evolving from a stable, thoroughly tested base specification is old - not fit for the Apple(TM) generation...

      You conveniently missed the part in TFS where Apple said they are going to try not to make sweeping syntactic changes from here on out.

    6. Re:The "new" trend - eternal Alpha... by StormReaver · · Score: 1

      Because the idea of a programming language evolving from a stable, thoroughly tested base specification is old....

      One of the many reasons I stay with Java is stability. Every single piece of Java code I have written since 1998 (when I first started writing Java code) still runs unmodified.

      Changing API's is the main reason I stopped programming with Qt. I don't want to have to rewrite all my software every few years. I just don't have the time for it.

    7. Re:The "new" trend - eternal Alpha... by Anonymous Coward · · Score: 0

      I'm not sure where you get this idea that Microsoft somehow values back-compat and Apple doesn't.

      I present to you, evidence:
      - Apple: 68k emulation in hardware in PPC architecture
      - Microsoft: Windows Vista's driver model
      - Apple: Carbon
      - Microsoft: VB.Net
      - Apple: Fat binaries
      - Microsoft: .Net 1.1, 2.0, and 4.0.

      I could go on, but this should illustrate the point quite well. Apple has many times supported backward compatibility for a transition period, and even for an extended period (my G3 could still run 68k binaries, nearly 6 years after the last 68k Mac rolled off the line). And Microsoft has frequently told developers that they needed to simply update their code and stop whining (and, honestly, they did try to make VB6->VB.Net play nice, but it turns out that VB6 devs are just too brick-stupid to "get it", as recently seen in the call to open source a 20 year old, unsupported, and clunky revision of a language that still sees modern releases).

    8. Re:The "new" trend - eternal Alpha... by macs4all · · Score: 1

      Apple has always done this with everything they do. They don't treat backwards-compatibility as ultra important like Microsoft does.

      No! instead! MS just obsoletes and renames entire technologies and APIs on a regular basis.

    9. Re:The "new" trend - eternal Alpha... by cant_get_a_good_nick · · Score: 3, Insightful

      Like C? Even C has broken backwards compatibility at times. C started out in the 70's, yet we still have C99. Oh wait, that didn't work, we have C11. 40 years later we're still changing it.

      C++ was once a superset of C. It is no longer, and some C code can not be compiled in C++ compilers.

      Java has methods that are deprecated.

      Swift is a pretty new language. It's also a bit of a new paradigm. You start with an idea of what you want in the language, most works, some doesn't, you try again. Some of this breaks backwards compatibility. Better to do this now, then 40 years later.

    10. Re:The "new" trend - eternal Alpha... by Anonymous Coward · · Score: 0

      This has nothing to do with Apple specifically. It's a noble experiment to try and develop a language specification and ecosystem on such a large scale. It's futile to believe that you will get it right with your first shot. And the enterprise is not helped by having to support legacy cruft. What Apple is doing here is extremely brave and I hope that it pans out (in the sense that not too many developers are disgruntled and use the language because it is worthwhile not just because of vendor-lockin). Not for Apple's sake but for the sake of language development as a whole. It is about time that we move forward and old ideas ripe for the plucking enter the mainstream.

    11. Re:The "new" trend - eternal Alpha... by CodeArtisan · · Score: 1

      Apple has always done this with everything they do. They don't treat backwards-compatibility as ultra important like Microsoft does.

      That's because they still write their major apps in Objective-C.

    12. Re: The "new" trend - eternal Alpha... by Anonymous Coward · · Score: 0

      Ugh, typing something other than flames.

    13. Re:The "new" trend - eternal Alpha... by serviscope_minor · · Score: 1

      C++ was once a superset of C. It is no longer, and some C code can not be compiled in C++ compilers

      It was never a strict superset since it introduced new keyword(s) (see what I did there?). The superset of C and C++ was most of C however. It still is.

      --
      SJW n. One who posts facts.
    14. Re:The "new" trend - eternal Alpha... by Anonymous Coward · · Score: 0

      Make no mistake: this isn't Swift version 3 - it is the language Swift 3. I guess Swift 4 will not be (completely) backwards compatible either. Because the idea of a programming language evolving from a stable, thoroughly tested base specification is old - not fit for the Apple(TM) generation...

      Specification...? So Perl, PHP, Python, Ruby etc. are now in the "Apple" generation?

    15. Re:The "new" trend - eternal Alpha... by Anonymous Coward · · Score: 0

      Because the idea of a programming language evolving from a stable, thoroughly tested base specification is old....

      One of the many reasons I stay with Java is stability. Every single piece of Java code I have written since 1998 (when I first started writing Java code) still runs unmodified.

      Changing API's is the main reason I stopped programming with Qt. I don't want to have to rewrite all my software every few years. I just don't have the time for it.

      FACT: Every new keyword added to a language breaks source compatibility.

      YOU didn't write a class called enum, good for you.

    16. Re: The "new" trend - eternal Alpha... by Anonymous Coward · · Score: 0

      PPC wasn't tabbed by Apple. It was in the best interest of Motorola to have 68K instructions handled in hardware.

      Did they help make the case? Sure.

    17. Re:The "new" trend - eternal Alpha... by Anonymous Coward · · Score: 0

      C++ was never a proper superset of C, ironically Obective-C was (and is).

      There is no clear example of the blind leading the bling than C++ actually; It is now obviously clear that Stroustrup did not actually understood Object Orientation, and orthogonality for that matter, when he designed C++. Yet it was chosen as the de-facto "OO language" in the 90s by people who did not understand Object Orientation either...

      It's ironic to see so many "object" oriented languages and systems that have to be re-designed and re-implemented from the ground up every other release. Highlights the designers lack of understanding of which they're trying to "design."

    18. Re: The "new" trend - eternal Alpha... by macs4all · · Score: 1

      PPC wasn't tabbed by Apple. It was in the best interest of Motorola to have 68K instructions handled in hardware.

      Did they help make the case? Sure.

      the 68k emulation wasn't in hardware. It was in Firmware.

      When the Segment Loader detected that the segment is 68k code, it would invoke a wickedly-cool JIT COMPLIER to TRANSLATE that block of code into PPC. Then it would continue on.

      The genius of the whole thing relied on a few things:

      1. Apple's JIT compiler was FAST and produced EXCELLENT PPC code, plus it was only translating a relatively small amount of code at a time.

      2. CPUs and entire systems were getting faster. This always helps...

      3. IIRC, the PPC architecture had massive numbers of Registers. This also helps.

      4. The PPC architecture is more cycle efficient in most cases than 68k. Again, this helps.

      And so, that system worked SO well that Apple was able to leave whole chunks of MacOS in 68k code until (I believe) MacOS 8.5, and most users never even noticed!

      But it still wasn't in Hardware.

    19. Re: The "new" trend - eternal Alpha... by LifesABeach · · Score: 1

      Flames look good when mixed with foundation-less hype.

    20. Re:The "new" trend - eternal Alpha... by tigersha · · Score: 1

      True. I wrote a raytracer in C++ back in 1995. A few weeks back I discovered the source on an old CDROM and typed 'make'. Funny idea that. I got more errors than anything I ever wrote. Id DID work quite well back then :(

      --
      The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
    21. Re:The "new" trend - eternal Alpha... by Megol · · Score: 1

      Yes?
      But I don't know what you mean specifically, are you maybe thinking that a specification have to be a certain document? Many projects, both open-source and closed ditto, have the code as the specification. It works but isn't ideal.
      Or maybe you think the fact that certain minor compatibility changes between versions is comparable to the Swift type of changes? That isn't true - FFS a normal loop construct written in valid Swift 1.0 isn't compatible with Swift 3.0 - just because it didn't fit the designers style. That languages depreciate some things that isn't reliable isn't near the same kind of change and is easily patched.
      The last idea from me is that you'd like to compare the Swift progress with the incompatible changes in e.g. Python 2.x and 3.x? If so we are comparing a language that breaks compatibility for every new release (for now) with a language that did one intentional incompatible change.

  4. Java? by Anonymous Coward · · Score: 0

    > Java is far superior

    Ugh. Swift must be pretty bad, then.

  5. Mozilla: drop Rust, adopt Swift! by Anonymous Coward · · Score: 0, Interesting

    Now that we're seeing some real progress with making Swift a cross-platform language, I think it's time for Mozilla to drop their Rust project.

    For those who don't know, Rust's home page describes it as "a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety." Well that sounds an awful lot like what Swift is!

    While Swift has already seen major adoption and use in the real world, we haven't seen that from Rust. There have been a handful of projects using Rust, but that's it. And the ones that have used it, including the Rust implementation itself and Mozilla's Servo browser engine, have not been very impressive so far.

    Despite lofty goals and a lot of hype, we haven't seen anything much of substance come out of Rust. Many have complained that it's an awkward language to use, even more than C++ is. Others have pointed out that C++14 and C++17 actually make much of Rust redundant. Yet others point out that Rust's safety guarantees are only as good as its implementation, which suffers from thousands of bugs despite much of it being written in Rust by the creators of Rust!

    There was recent discussion about Google adopting Swift for Android. IBM has also taken an interest in Swift. Instead of continued failure with Rust, which is essentially a proprietary language at this point even if it's developed in the open, Mozilla should really consider using Swift, too.

    It wouldn't just be better for Mozilla. It would be better for all developers. Swift is quickly becoming a universal language. The large number of developers proficient with Swift could contribute to Mozilla's code bases, rather than just a small handful of niche developers who know Rust.

    Swift is the future. It's where software development is heading. Mozilla can do the sensible thing by getting rid of Rust and moving to Swift early on, or they can continue to waste time and effort on Rust. I sure hope they make the sensible decision! A modern web browser written in Swift would be much more useful than a web browser written in Rust.

    1. Re:Mozilla: drop Rust, adopt Swift! by Anonymous Coward · · Score: 0

      Wow, how long ago did you suck apples dick? It must have been pretty recent! I bet you can still taste the jizz.

    2. Re:Mozilla: drop Rust, adopt Swift! by NotInHere · · Score: 2

      Well that sounds an awful lot like what Swift is!

      They both target into the same direction, but rust is a far more "safe" language than Swift is.

      While Swift has already seen major adoption and use in the real world, we haven't seen that from Rust.

      Quite on the contrary: https://www.rust-lang.org/frie...

      And that page only contains the corporate users of rust. There is a really big community of free time rust developers as well.

      Others have pointed out that C++14 and C++17 actually make much of Rust redundant.

      That might be partially right, but C++ has lots and lots of backwards compatibility to very old concepts. C++ relies on the C preprocessor, which is very limited, on doing macros. Thanks to this you don't have scoped macros for example. In rust the macro system is done much later in the process, so that you can declare a macro inside a function, and after the } closing brace the macro scope ends!

      There was recent discussion about Google adopting Swift for Android [slashdot.org]. IBM has also taken an interest in Swift [ibm.com].

      Using swift for android would make sense as both android and ios are similar platforms, you likely want to write stuff for them in one unified language.

      Swift is quickly becoming a universal language.

      Swift may have lots of adoption but it is far away from being an universal language. It is limited by its compatibility kludges towards ObjectiveC which makes it particularly interesting for iOS developers who already know ObjectiveC, but outside of this environment it is of low importance.

      The large number of developers proficient with Swift could contribute to Mozilla's code bases, rather than just a small handful of niche developers who know Rust.

      The number of developers who know swift may be larger than the number of developers who know rust. But how many only are interested in developing their ios app, and that's it?

      A modern web browser written in Swift would be much more useful than a web browser written in Rust.

      Swift only has reference counting, nothing more. In fact, only thread safe reference counting. This is a major performance problem, while in Rust you have the choice between all memory models C/C++ have.

    3. Re:Mozilla: drop Rust, adopt Swift! by Anonymous Coward · · Score: 1

      I think Rust is only "safer" in theory. In practice, I'm not convinced. The Rust implementation is buggy. I know, because I've experienced such bugs first hand. How can I trust something so buggy to enforce safety? At least Swift doesn't make over-the-top promises. (Compare the Rust web site's insistent claims of "Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety." to the Swift web site's far more plausible claims of "Swift makes it easy to write software that is incredibly fast and safe by design.")

      Personally, I don't trust the Rust community, either. Many of its participants seem to be high schoolers or perhaps in their first year or two of college. The Swift community, on the other hand, has many people with decades of industry experience and/or advanced academic degrees. Perhaps this is why I have seen nothing but courtesy and professionalism out of the Swift community members I've interacted with, while I've repeatedly seen immaturity out of Rust community members. The Rust community's worship of the Rust Code of Conduct is very peculiar, for example. It's like software development is secondary to "social justice" for many Rust users.

      That list of Rust users you gave isn't very convincing, either. Dropbox, and to a lesser extend Mozilla, are the only ones with any significance. A bunch of no-name startups using Rust means nothing. Meanwhile, we've seen major multinational corporations use Swift.

      Swift hits a sweet spot where it's usable for a wide range of low level and high level development, both commercial and open source, while still being a familiar and friendly language, with a great community. Rust, on the other hand, has so far only shown itself to be a painful language, mainly used for weekend projects that are thrown on GitHub and then abandoned, with a questionable community.

      Swift's future is looking brighter every day. Swift is clearly the way to go.

    4. Re:Mozilla: drop Rust, adopt Swift! by NotInHere · · Score: 1

      Swift is infected as well: https://swift.org/community/#c...

      The claws of the SJWs are sharp and they are drilled deep into the flesh of the software development industry.

      But that code of conduct usually only applies to the core project (like the compiler), and many libraries. If you "only" are an user you won't get harassed by any SJW.

    5. Re:Mozilla: drop Rust, adopt Swift! by macs4all · · Score: 1

      but rust is a far more "safe" language than Swift is.

      Rust has been infected with cancer of SJW's and a stupidly crazy code of conduct. All the good developers will leave soon, driven away by the anti-meritocracists.

      I'm no SJW; far from it. But Slashdot could do worse than to adopt at least some of those "Stupidly Crazy" Code of Conduct rules.

    6. Re:Mozilla: drop Rust, adopt Swift! by MobileTatsu-NJG · · Score: 2

      Today I learned that SJW means 'civility'.

      --

      "I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)

    7. Re:Mozilla: drop Rust, adopt Swift! by Anonymous Coward · · Score: 1

      I just looked at this "stupidly crazy" code of conduct. Can you point out the stupid and crazy parts for me? Because for the life of me, I fail to see how these points are all that controversial:

      We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic.

      Translation: "We believe in being cool to other people, and don't bully or pick on them like a bunch of twats." Seems reasonable.

      On IRC, please avoid using overtly sexual nicknames or other nicknames that might detract from a friendly, safe and welcoming environment for all.

      Translation: "Your choice of RapinUrButt as an IRC nick suggests you're a puerile buffoon. We'd like you to not behave that way." Seems reasonable.

      Please be kind and courteous. There’s no need to be mean or rude.

      Translation: "Don't be a dick." Seems reasonable.

      Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer.

      Translation: "Remember that design decisions come with tradeoffs, and don't be a jerk because somebody valued the trade-offs differently than you might have." Seems reasonable. If you disagree with a design decision, you can certainly debate the relative weights of the tradeoffs chosen, but there's no need to disrespect someone for making decisions differently than you might have.

      Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works.

      Translation: "Code talks, bullshit walks. If you have an idea, implement it, don't just carp on endlessly about how something sucks and should be fixed." Again - reasonable.

      We will exclude you from interaction if you insult, demean or harass anyone. That is not welcome behaviour. We interpret the term “harassment” as including the definition in the Citizen Code of Conduct; if you have any lack of clarity about what might be included in that concept, please read their definition. In particular, we don’t tolerate behavior that excludes people in socially marginalized groups.

      Translation: "If you're an asshole, you're not welcome here." Again, reasonable.

      Private harassment is also unacceptable. No matter who you are, if you feel you have been or are being harassed or made uncomfortable by a community member, please contact one of the channel ops or any of the Rust moderation team immediately. Whether you’re a regular contributor or a newcomer, we care about making this community a safe place for you and we’ve got your back.

      Translation: "If you're an asshole to other people in private channels, you're not welcome here." Guess what? Reasonable!

      Likewise any spamming, trolling, flaming, baiting or other attention-stealing behaviour is not welcome.

      Translation: "One last time, don't be an asshole." And guess what, that's reasonable too.

      I fail to see how you arrive at the conclusion that this code of conduct is controversial - have you actually read it?

    8. Re:Mozilla: drop Rust, adopt Swift! by Anonymous Coward · · Score: 0

      Rust's code of conduct is very vague and very subjective, and also very hypocritical and contradictory.

      Things like "overtly sexual nicknames" and "unstructured critique" and "attention-stealing behaviour" are nearly meaningless or undefinable, yet can be used by the Rust community to attack those they dislike, with these attacks somehow being deemed "acceptable" thanks to the code of conduct saying they're ok!

      They go on and on about providing "a friendly, safe and welcoming environment for all", yet their definition of "all", oddly enough, doesn't include everyone. If by "all" they actually meant everyone, then they would be tolerant and inclusive of those who they've deemed to be "intolerant". Yet they aren't. They show those people intolerance.

      The contradiction in Rust's code of conduct is even beyond belief sometimes. There's one paragraph that starts with "We will exclude you from interaction if ..." and at the end of that same paragraph it says "... we don’t tolerate behavior that excludes people ...". That's right, in the very same paragraph they state that excluding people is unacceptable, yet they promise that that's exactly what they'll do to you if they feel like it!

      That's why a lot of people see the Rust code of conduct as a weapon. It's not about building a friendly community. It's about giving the most influential members of the Rust community a way to control and exclude anyone they dislike, while putting up a feel-good facade of "tolerance" and "openness" and "safety" and "friendliness".

    9. Re:Mozilla: drop Rust, adopt Swift! by bondsbw · · Score: 1

      • We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic.
      • On IRC, please avoid using overtly sexual nicknames or other nicknames that might detract from a friendly, safe and welcoming environment for all.
      • Please be kind and courteous. There’s no need to be mean or rude.
      • Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer.
      • Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works.
      • We will exclude you from interaction if you insult, demean or harass anyone. That is not welcome behaviour. We interpret the term “harassment” as including the definition in the Citizen Code of Conduct; if you have any lack of clarity about what might be included in that concept, please read their definition. In particular, we don’t tolerate behavior that excludes people in socially marginalized groups.
      • Private harassment is also unacceptable. No matter who you are, if you feel you have been or are being harassed or made uncomfortable by a community member, please contact one of the channel ops or any of the Rust moderation team immediately. Whether you’re a regular contributor or a newcomer, we care about making this community a safe place for you and we’ve got your back.
      • Likewise any spamming, trolling, flaming, baiting or other attention-stealing behaviour is not welcome.

      If this is too burdensome for you, then perhaps you need to get off your phone and listen to the teacher, there may be a long division test tomorrow.

      I'm sure the adults won't mind waiting a few years until you claim your adulthood.

      --
      All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
    10. Re:Mozilla: drop Rust, adopt Swift! by rochrist · · Score: 1

      Very articulate, coward.

    11. Re:Mozilla: drop Rust, adopt Swift! by XxtraLarGe · · Score: 1

      Swift is infected as well: https://swift.org/community/#c...

      I'm about as anti-Social Justice Whiner as they come, but I don't really see anything to object to in the code of conduct posted above.

      --
      Taking guns away from the 99% gives the 1% 100% of the power.
    12. Re:Mozilla: drop Rust, adopt Swift! by rochrist · · Score: 1

      Ah yes. The 'your intolerance of my intolerance is intolerant' card.

    13. Re:Mozilla: drop Rust, adopt Swift! by Anonymous Coward · · Score: 0

      In fact the opposite seems to be happening. The good devs are the ones sticking around, and more of them are joining every day. I think it's time for people who shout that the sky is falling to stop and take stock of their situation in the spacetime continuum.

    14. Re:Mozilla: drop Rust, adopt Swift! by NotInHere · · Score: 1

      The Rust implementation is buggy. I know, because I've experienced such bugs first hand.

      Can you tell me about the bugs you experienced, and the projects you've tried to do with Rust? There is a troll on slashdot who uses this same argument, and that troll is a bit unfounded.

      while still being a familiar and friendly language

      The examples of swift I saw don't really seem friendly to me. But I can't judge Swift's friendliness as I haven't programmed with swift.

      Rust, on the other hand, has so far only shown itself to be a painful language

      I haven't coded much in Rust myself, but it didn't feel painful. Yes, there is a high entry barrier due to the many compiler checks, but its generally feeling not painful for me. idk, I'm a person of the type "there can't be enough compiler checks", so I am feeling quite well with the checks the Rust compiler does.

    15. Re:Mozilla: drop Rust, adopt Swift! by Anonymous Coward · · Score: 0

      I would encounter ICE crashes far too often when using the Rust compiler. I encountered bugs in the standard library, too. This happened while I was working on some simple weather modeling software. Sometimes the bugs would have already been reported, but it got to the point where I just gave up on Rust.

      Rust was not painful because of its strict compiler. I'm a long time user of Haskell, so a strict compiler does not bother me. I found Rust to be painful because of its bugs, its uninspiring syntax, its lacking standard library, its slow implementation, and the poor attitude prevalent throughout its community.

      The bugs really bothered me. Isn't Rust supposed to help avoid them? I've used a lot of compilers over the years, many of them immature and written in languages nowhere near as strict as Rust is, but I've never encountered as many bugs and problems with them as I did with Rust's implementation. If the people who are designing Rust can't use it to build reliable software, how are the rest of us mere mortals supposed to be able to use it effectively?!

    16. Re:Mozilla: drop Rust, adopt Swift! by DrXym · · Score: 1
      This is horseshit for several reasons.

      The primary one is that Rust and Swift serve different purposes. Swift is an application programming language primarily for mobile apps and Rust is a systems programming language primarily for services, IoT, drones and so on. Swift sacrifices performance for convenience. Rust sacrifices convenience for performance. They could be used in each other's place but not without bringing baggage with them. A simple example of that Rust tracks and enforces most lifetimes at compile time - it knows when you're not using an object any more and inserts code to delete it. But it will kick your ass if you don't do things exactly how it likes. Swift uses automatic reference counting which means object an additional runtime cost but it's more forgiving and easier to work with. On a more practical level Rust runs and works on Windows, Linux and Mac and has a burgeoning number of libraries and projects whereas Swift is mostly Mac with some token cross platform thrown out there but not much else yet.

      Secondly, for C++, I don't see that it can ever fix the basic problem that it is dangerous by default. It's easy to corrupt or leak memory. It could grow directives or classes which define lifetimes or ownership information but it doesn't solve the problem of bad / dangerous code that already exists or new code that ignores these directives. That isn't to say C++ is going away soon but someone writing something that needs to be safety critical, or scalable, or reliable might think twice about using it.

    17. Re:Mozilla: drop Rust, adopt Swift! by Anonymous Coward · · Score: 0

      Rust's code of conduct is very vague and very subjective, and also very hypocritical and contradictory.

      Vague, and subjective - sort of like how all human interactions work? Context is everything in communication. If you require a set of hard and fast rules for every interaction you have with people, then you should probably seek treatment for an autism-spectrum disorder. It may help you reduce your level of discomfort when dealing with neurotypicals.

      They go on and on about providing "a friendly, safe and welcoming environment for all", yet their definition of "all", oddly enough, doesn't include everyone.

      "Your intolerance of my use of the Stormfront thesaurus is SO intolerant! You claim to be tolerant, but won't allow me to be intolerant! That's not tolerant at all!"

      It's about giving the most influential members of the Rust community a way to control and exclude anyone they dislike, while putting up a feel-good facade of "tolerance" and "openness" and "safety" and "friendliness".

      Please explain to me why you feel you should be able to use "overtly sexual nicknames," "unstructured critique," and "attention-stealing behavior." These words have meanings, and it's quite clear if you're even remotely acquainted with a dictionary what the intent of these phrases is. And here's the trick: If you're not sure whether or not your chosen name of "BigDickSwinger" is going to cause issues... why not just ask a moderator? Or even better, if you're concerned that the name flirts with the borders of acceptable conduct, maybe you should just choose something less related to your motherfucking dick?

    18. Re:Mozilla: drop Rust, adopt Swift! by NotInHere · · Score: 1

      When did you do your project? Was it before Rust 1.0 came out in May 2015? I've done Rust only after that time, and it worked fine. Yes, Rust may be far from finished, but I only got an ICE only once.

    19. Re:Mozilla: drop Rust, adopt Swift! by Anonymous Coward · · Score: 0

      How about it's mere existence. Why does anyone feel entitled to tell others how they're expected to behave? Why does this have anything to do with a programming language?

  6. Re:No such thing as a trustworthy homosexual by Anonymous Coward · · Score: 0

    https://i.imgur.com/dUk9aen.jpg

    No such thing as a trustworthy spy.

    Dig a big big big mother fucking tomb.

  7. Re:Swift 2.0 by Anonymous Coward · · Score: 1

    That is the most ridiculous statement ever. Nothing that anyone has learned is obsolete. They removed extra verbosity from standard library function calls - Objective C was, by convention, excessively verbose in naming of methods, enums, classes, everything. Moving away from that legacy is not bad, and they are releasing a tool to automatically convert code. Nobody will be forced to rename everything in their own code. You're frankly coming across as a complete troll.

  8. Re:Swift 2.0 by 110010001000 · · Score: 3, Informative

    Really? So you are saying my PDP11 ML knowledge isn't obsolete? Thanks for the tip. It isn't trolling: it is a warning to avoid languages controlled by a single corporate entity. They can pull things from under you at their whim. Also, what a laugh: Swift 2.2 was released on MARCH 16, 2016!

  9. Re:Swift 2.0 by alvinrod · · Score: 2

    Apple developers are probably used to the abuse by this point considering that the Mac itself has undergone three architecture changes as they moved from the Motorola 68000 to IBM PowerPC and then to x86. I wouldn't be surprised if in another five years they've completed abandoned x86 and move to using their own ARM SoC designs for all of their products.

    They probably should have kept Swift behind closed doors while tinkering with it to make all of these changes. I realize that you need people using the language to discover ways of making it better, but Apple has loads of their own developers that could used started using the language and helping it evolve before releasing it to the public.

  10. Same happens for open source languages! by Anonymous Coward · · Score: 2, Interesting

    Your argument makes no sense.

    First of all, there's no such thing as "obsolete" knowledge when it comes to programming languages. This knowledge is very useful if you ever have to maintain code. And the newer knowledge typically builds upon the older knowledge.

    Additionally, programming languages developed by open source communities or working groups suffer from exactly the same problem. Yes, when moving to a new version of a programming language we as programmers need to learn new things! It doesn't matter if you're using Swift or Java or C++ or Perl or Ruby or Erlang or Haskell or Lua or JavaScript or whatever other language you want to consider. It doesn't matter who developed the new version of the language. A new version of anything typically implies some learning will be involved!

    It sounds to me like you want stagnation. Well, sorry son, but that doesn't fly when it comes to technology. Technology is always advancing. If you can't keep up, then you should drop out and find something else to do.

    1. Re:Same happens for open source languages! by 110010001000 · · Score: 4, Insightful

      C++ advances and still maintains backward compatibility. It does matter. If you learned C++ 10 years ago, that knowledge still applies today. Swift 2.2 was released in MARCH 16, 2016, and is already obsolete. Ridiculous.

    2. Re:Same happens for open source languages! by Anonymous Coward · · Score: 0

      Anyone using Swift knew this was going to happen.

    3. Re:Same happens for open source languages! by OzPeter · · Score: 4, Insightful

      C++ advances and still maintains backward compatibility. It does matter. If you learned C++ 10 years ago, that knowledge still applies today.

      There have been breaking changes in C++ in the past.

      Swift 2.2 was released in MARCH 16, 2016, and is already obsolete. Ridiculous.

      Hardly obsolete. No-one is saying you now can't still write Swift in 2.2 or even 1. Swift is not included in iOS and is instead bundled with the App that uses it. You just need to use the tooling version that supports your desired Swift version.

      --
      I am Slashdot. Are you Slashdot as well?
    4. Re:Same happens for open source languages! by NotInHere · · Score: 2

      Swift 2.2 *is* obsolete. All the libraries will have switched to swift 3 and in order to use the new versions of the libraries (which may have fixed bugs) you need to update your entire codebase to the new language.

      Generally though, you *can* do backwards incompatible changes for certain functionalities of your language, just make them in a way that compilation breaks. Nobody wants to debug a problem just because some standard library function changed the order of its arguments.

    5. Re:Same happens for open source languages! by 110010001000 · · Score: 0

      In 5 years Swift won't even be around. Apple will have moved on to something else. But enjoy chasing them around.

    6. Re: Same happens for open source languages! by Anonymous Coward · · Score: 0

      Man that was swift. Here today gone tomorrow.

    7. Re:Same happens for open source languages! by macs4all · · Score: 1

      In 5 years Swift won't even be around. Apple will have moved on to something else. But enjoy chasing them around.

      HOW long has it been since Apple moved from Pascal as the preferred language to Objective-C?

      Apple does NOT have a history of creating and abandoning Languages willy-nilly (Dylan notwithstanding).

    8. Re:Same happens for open source languages! by Dog-Cow · · Score: 1

      Apple adopted Objective-C in the late 1990s (first public release was with OS X in 2000). I don't think they'll drop Swift all that quickly.

    9. Re: Same happens for open source languages! by Bing+Tsher+E · · Score: 1

      Slackware95 included an Objective-C build environment as an optional part of their Dev set.

    10. Re:Same happens for open source languages! by Anonymous Coward · · Score: 0

      C++ advances and still maintains backward compatibility. It does matter. If you learned C++ 10 years ago, that knowledge still applies today.

      With the right compiler flags, MAYBE.

    11. Re:Same happens for open source languages! by HiThere · · Score: 1

      10 years ago, probably.
      20 years ago, maybe.

      But just because the language continues to work with the old code, don't presume that the libraries will.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    12. Re:Same happens for open source languages! by shutdown+-p+now · · Score: 2

      Yes, there are breaking changes in C++. In most cases, they go through two iterations of the standard - one to deprecate the old thing, another to remove or replace it. They also look at actual usage to see how safe they have to play - e.g. operator ++ for bools is still not removed, even though it has been deprecated since C++98.

      What this means is that, in practice, you can take almost any C++98 codebase, and compile it with a C++14 compiler with zero changes - your chances of actually running into any of those breaking changes is very slim. Even when you get errors, most of the time, it will be because a new keyword was added, and the old code used it as identifier - requiring a trivial and easily automated change.

    13. Re:Same happens for open source languages! by tigersha · · Score: 1

      Crap. I have C++ programs I wrote 10 years ago that does not even remotely come close to compiling today.

      Besides, the problem with C++ is that it always accumulates cruft, even when people know that something is badly designed. Apple has the balls to toss out old obsolete things. There was just as much uproar when they move away from ADB to USB for their keyboards.

      --
      The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
    14. Re:Same happens for open source languages! by sribe · · Score: 1

      Hardly obsolete. No-one is saying you now can't still write Swift in 2.2 or even 1.

      HAHAHAHA HOOOOH... obviously you don't have experience with the recent years' churn in Xcode vs OS vs SDK versions.

  11. Re:Swift 2.0 by OzPeter · · Score: 1, Troll

    Too bad if you put time into learning Swift 2.0. That knowledge is now obsolete. And when Swift 4.0 comes out, your Swift 3.0 knowledge will be obsolete. My advice to young programmers: avoid languages owned by corporations. They have time and money to waste. You don't.

    LOL I take it that you have never looked at C++, an ISO standardized language. Code written in C++98 and C++14 almost appear to be written in different languages.

    And actually one of the advantages of a corporate controlled language is you totally avoid the "Designed by committee approach" to things.

    --
    I am Slashdot. Are you Slashdot as well?
  12. Re:Swift 2.0 by 110010001000 · · Score: 2

    Actually C++ is a good example: C++ was released in 1985 and has multiple compilers available and that code still compiles in 2016. Swift 2.2 came out 3 MONTHS AGO. There is no advantage to a corporate controlled anything.

  13. Re:Swift 2.0 by OzPeter · · Score: 1

    And as I mentioned above there have been breaking changes in C++

    --
    I am Slashdot. Are you Slashdot as well?
  14. Re:Swift 2.0 by Anonymous Coward · · Score: 0

    However, that C++14 compiler will happily compile your C++98 legacy code. It doesn't break. You can keep writing in the old style and gradually modernise your stuff in-place if need be. Code written for Swift 2 will not compile with Swift 3.

  15. Re: Swift 2.0 by Anonymous Coward · · Score: 1

    I've seen plenty of code from pre-C++98 that doesn't compile on modern compilers, actually. The C++ language and implementations were making incompatible changes until standardization completed, and beyond (mostly because the standard was extremely difficult to implement correctly).

  16. Swift > Objective C by sproketboy · · Score: 2

    But that's not saying much...

    1. Re: Swift > Objective C by Anonymous Coward · · Score: 0

      Objective C is a superset of C.

      That statement says more than you think it does.

  17. Re:Swift 2.0 by angel'o'sphere · · Score: 1

    As obsolet as my knowlege in
    * Cobol
    * K&R C
    * Pascal
    * Java 1.1
    ???

    You seem not to work in the software industry.

    --
    Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  18. Re: Swift 2.0 by 110010001000 · · Score: 1

    Sure but C++98 was 18 YEARS ago. Swift 2.2 was released 4 MONTHS AGO. What a joke.

  19. Re:Swift 2.0 by 110010001000 · · Score: 1

    Cobol, K&R C, Pascal are not obsolete - just no longer widely used. However you are right about Java 1.1, another corporate product. You seem not to be able to grasp what I am talking about here. K&R C was released 40 YEARS AGO. Swift 2.2 was released 4 months ago. Moron!

  20. Apple's infinite loop road named for engineering by JoeyRox · · Score: 1, Insightful

    Because apparently their engineers lack the ability to think far enough ahead to design something that lasts longer than a single coding cycle.

  21. Re:Swift 2.0 by 110010001000 · · Score: 2

    C++ is 30+ years old. Swift 2.2 is 4 MONTHS old and is obsolete. I hope you see the difference here.

  22. Re:Swift 2.0 by CastrTroy · · Score: 2, Informative

    Swift is a good idea of how to do things wrong. But what about C#. It's made my Microsoft, who everybody loves to hate, yet C# and the .Net framework is probably one of the best development environments out there. They have a pretty good record of not breaking too many things with new releases. They also do pretty well adding new features that programmers want. I prefer it much more to other languages that aren't controlled by corporations such as PHP, Python, or C++..

    --

    Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
  23. Re:Swift 2.0 by Anonymous Coward · · Score: 0

    Not at all. The changes are slight. 95% of what you know still works, just a few things have changed.

    For example:
    (1) method call names.indexOf("Taylor") has changed to names.index(of: "Taylor")
    (2) "Taylor".containsString("ayl")
    "Taylor".contains("ayl")
    If you can't figure out these things, and think all your 2.0 knowledge is lost, I don't know what to say.

  24. Re:Swift 2.0 by goose-incarnated · · Score: 2

    Too bad if you put time into learning Swift 2.0. That knowledge is now obsolete. And when Swift 4.0 comes out, your Swift 3.0 knowledge will be obsolete. My advice to young programmers: avoid languages owned by corporations. They have time and money to waste. You don't.

    LOL I take it that you have never looked at C++, an ISO standardized language. Code written in C++98 and C++14 almost appear to be written in different languages.

    And actually one of the advantages of a corporate controlled language is you totally avoid the "Designed by committee approach" to things.

    You know, I sorta /broadly/ agree, but c'mon - you're comparing differences across 18 years for C++ to differences across 4 months for Swift. Why not compare C++11 and C++14?

    --
    I'm a minority race. Save your vitriol for white people.
  25. Re:Swift 2.0 by NotInHere · · Score: 1

    avoid languages owned by corporations

    So you suggest C++ is any better? One of the companies at the table which determines the future of C++ is Microsoft, and they want as much lock-in into their OS as possible. This has caused things like multi-threading not appear until 2011, and only on the pressure of other languages as C++. Coding cross platform programs that exceed the simple hello-world in C++ is entirely impossible except for very simple hello-world programs if you don't use libraries. In other languages this is true of course as well, but their std is much larger, and you are less reliant on libraries there. Microsoft does as much as it can to keep std as small as possible so that people get locked into windows.

    Also, as the compiler vendor gives you the std in C++, you are locked in into the std implementation of the vendor. This for example means that if you develop anything for consoles like sony, you essentially can't use std.

  26. No Windows version... by __aaclcg7560 · · Score: 2

    Seriously, Apple, where's the love?

    1. Re:No Windows version... by NotInHere · · Score: 2

      You might want to use rust instead, it has first class support for windows, linux and mac:

      https://github.com/rust-lang-n...

    2. Re:No Windows version... by Anonymous Coward · · Score: 0

      Too bad the syntax is braindead.

    3. Re:No Windows version... by Anonymous Coward · · Score: 0

      Agreed, Swift's syntax is pretty bad.

    4. Re:No Windows version... by Anonymous Coward · · Score: 0

      Or use a real language made for Windows like, C#...

    5. Re: No Windows version... by NotInHere · · Score: 1

      Its becoming webscale: http://www.arewewebyet.org/

  27. Re:Swift 2.0 by Anonymous Coward · · Score: 0

    Apple developers are probably used to the abuse by this point considering that the Mac itself has undergone three architecture changes as they moved from the Motorola 68000 to IBM PowerPC and then to x86. I wouldn't be surprised if in another five years they've completed abandoned x86 and move to using their own ARM SoC designs for all of their products.

    True, but relatively speaking, the change overs weren't completely horrific. The 68K and Mac OS 9 emulation stuck around for quite a while before being dropped. The "Universal apps" were also quite a clever use of NeXT's tech with multi-arch binaries.

    Certainly better than trying to move everyone fro x86 to Itanium, as Intel tried. At least during the various Apple transitions you could copy your existing binaries over to the new hardware without too much fuss.

    Not ideal, but certainly not an apocalyptic scenario.

  28. Re: Swift 2.0 by Anonymous Coward · · Score: 0

    And when C++ was as young as Swift, you had different compilers that were mutually incompatible. Your argument is backwards, as young languages tend to break backward compatibility a lot more.

  29. Re: Swift 2.0 by OzPeter · · Score: 1

    Sure but C++98 was 18 YEARS ago. Swift 2.2 was released 4 MONTHS AGO. What a joke.

    Is that you Donald?

    --
    I am Slashdot. Are you Slashdot as well?
  30. Re:Swift 2.0 by Altus · · Score: 1

    Yes, the newer language should be experiencing much more flux as it is developed. Which, by the way, is exactly what apple told developers to expect.

    --

    "In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson

  31. Re:Swift 2.0 by 110010001000 · · Score: 1

    Apple told developers that Swift 2.2 would be obsolete in 4 months? Wow, and people still used it? How stupid.

  32. Re: Swift 2.0 by 110010001000 · · Score: 1

    You are conflating compilers with language stability. The fact is that Apple could discontinue Swift tomorrow and you would by out of luck. Avoid corporate controlled languages.

  33. Re: Swift 2.0 by 110010001000 · · Score: 1

    I guess the fact that 18 years >> 4 months is lost on you. Oh well, enjoy Swift until Apple gets bored with it and discontinues it and replaces it with something "better".

  34. Re:Swift 2.0 by 110010001000 · · Score: 1

    Yes I am suggesting C++ is a lot better. What the fuck does Microsoft and cross platform have to do with anything?

  35. Re:Swift 2.0 by Anonymous Coward · · Score: 0

    Funny thing about K&R C, within a couple years function call and enum syntax was changed, among various other backward compatibility breaking ... i.e. in about the same timescale as changes being made to Swift. Swift 3 resembles resembles Swift 2 far more than early than the C used by early compilers resembled K&R. You seem to be assuming some sort of binary view of languages, that they are either 100% the same or not, when evolving languages tend to be very similar with a couple changes. The vast majority of Swift 3 is just like earlier versions, so nearly everything a programmer previously learned is still completely relevant today.

    If you freak out this much about library function name changes, you wouldn't have been able to handle the early years of C and C++ before libraries were standardized... or I guess after standardization where new standards incorporated new libraries from other projects with slight name changes...

  36. Re:Swift 2.0 by 110010001000 · · Score: 1

    You can "figure out" things and rewrite your codebase every four months or you can avoid language controlled by a single corporation that changes things at their whim. It is your career I guess.

  37. Re:Swift 2.0 by 110010001000 · · Score: 1

    But is is 2016 now. Why would you choose to go back to 1985 when standardized languages didn't exist? Insane. You can continue to chase Apple around if you want, but if you are a young programmer you are foolish to invest time in some corporations language that they can discontinue at any point.

  38. Re: Swift 2.0 by OzPeter · · Score: 1

    I guess the fact that 18 years >> 4 months is lost on you.

    Obviously you weren't around 18 years ago, otherwise you wouldn't be comparing Apples to Oranges. New languages in their infancy are always in a state of flux.

    Oh well, enjoy Swift until Apple gets bored with it and discontinues it and replaces it with something "better".

    What, things change? Say it ain't so.

    --
    I am Slashdot. Are you Slashdot as well?
  39. Re: Swift 2.0 by 110010001000 · · Score: 1

    I was around 18 years ago. That is my point: why would you use a language that is in flux and a single corporate entity can control or drop on their whim? And no: things don't have to change every 4 months. But go ahead and waste your time "learning" Swift, Rust, ObjC, etc if you want.

  40. Re:Swift 2.0 by Altus · · Score: 3, Informative

    Apple stated when Swift 1.0 was released that it was a work in progress and that there would be a flurry of updates coming and that, while they would maintain binary compatibility, they would not be able to maintain source compatibility as they changed and streamlined the language. Anyone using swift is well aware of this.

    --

    "In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson

  41. Re:Swift 2.0 by 110010001000 · · Score: 1

    And people still used it? How stupid. I guess Apple was smart not to use it for any of their projects.

  42. Re:Swift 2.0 by PmanAce · · Score: 1

    What company has time and money to rewrite code every four months?

    --
    Tired of my customary (Score:1)
  43. Re: Swift 2.0 by OzPeter · · Score: 1

    I was around 18 years ago. That is my point: why would you use a language that is in flux and a single corporate entity can control or drop on their whim?

    Oh please enlighten me then. What is this magical language that you would have me develop in?

    And no: things don't have to change every 4 months.

    As stated previously by me and several other people, Apple stated at the outset that Swift would go through syntactical changes until it settled down. But it appears that you think a language needs to spring from the bosom of its creator in a perfect yet fixed, state.

    But go ahead and waste your time "learning" Swift, Rust, ObjC, etc if you want.

    Knowledge is never wasted.

    --
    I am Slashdot. Are you Slashdot as well?
  44. Re:Swift 2.0 by NotInHere · · Score: 1

    Microsoft controls the MSVC compiler which is one of the C++ implementations, and this gives microsoft a seat at the table: https://isocpp.org/std/the-com...

    Only because C++ has multiple compiler vendors it does not mean that the vendors do not try to do evil stuff with the control they have over the compilers, and therefore over the users. The usual suspect here is always Microsoft.

    You may not be locked in into a particular compiler vendor, but as the std is very small you either use the unofficial extensions (and get locked in).

    You know generally I share your attitude that you have to distrust single companies (this attitude is really healty!), but in the case of c++ the development is really impaired thanks to each vendor trying to become market leader, they focus more at fighting each other than trying to improve the actual language.

  45. Apple is expected to be perfect on the first try? by Brannon · · Score: 2

    I'm not aware of any good programming language that never required any revision. So you are basically holding Apple to a standard that noone else has ever met before...

    But hey, if it makes you feel better about your own miserable life to complain on the internet...

  46. Re: Swift 2.0 by dave420 · · Score: 2

    I think the reason you are attracting such replies is that you appear to be completely ignoring the changes in computing since C++ came out. The two are clearly not comparable, as C++ was developed during a time where access to the internet was out of reach of most people. Where languages had to be incredibly stable simply because changes to them could not be disseminated to all affected parties very quickly. Where documentation was in printed books instead of digital. Where transpilers were a lot less effective as they are now. This is just scraping the surface - the differences between then and now are like night and day, yet you made absolutely no reference to them. I think if you accepted that what happened to a relatively low-level language back then might not be particularly relevant to a high-level language now (and maybe calmed down a tad) you might be having more of a discussion and less of an argument.

  47. Python is controlled by a single person. by Brannon · · Score: 1

    should the world stop using Python?

    And PDP11 ML isn't a programming language, dumbass.

    1. Re:Python is controlled by a single person. by angel'o'sphere · · Score: 1

      Erm, as much as I despcie your parent for his foul posts, you are wrong.
      Or your english is bad.

      www.ml1.org.uk/pdf/ml1apph.pdf

      Obviously he ment "ML" running on "PDP11".

      And yes, ML is a programming language.

      However I belive he ment this language: https://en.wikipedia.org/wiki/... and not that JCL described in the PDF above.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    2. Re:Python is controlled by a single person. by Brannon · · Score: 1

      He said PDP11 ML, which I assumed meant the PDP11 machine-language or macro-assembly language--otherwise what's the point of saying "PDP11"?

    3. Re:Python is controlled by a single person. by angel'o'sphere · · Score: 1

      He said: "So you are saying my PDP11 ML knowledge isn't obsolete?"

      And if you knew enough about programming languages(a) and had followed the thread(b) (which implied we are talking about programming languages) you either had known that ML is a programming language(a) or concluded(b) it. So you had saved yourself from a misplaced "dumb ass" :D

      But rest assured: no harm done, that guy is a moron and an idiot.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  48. Re: Swift 2.0 by Anonymous Coward · · Score: 0

    Code written by two different programmers in c++ looks like two different languages.

  49. Re:Swift 2.0 by gregmark · · Score: 2

    What corporations control Python?

  50. Re:Swift 2.0 by OzPeter · · Score: 1

    C# and the .Net framework is probably one of the best development environments out there.

    Add to that the quality of Visual Studio compare to other IDEs. Case in point Xcode can't refactor Swift.

    --
    I am Slashdot. Are you Slashdot as well?
  51. Why not compare C++85 with C++89? by Brannon · · Score: 1

    Some minor tweaks added in '89 (from wikipedia): multiple inheritance, abstract classes, static member functions, const member functions, and protected members.

    And even later still were added: templates, exceptions, namespaces, new casts, and a boolean type.

    C++ underwent way more fundamental changes in its first 10 years than Swift has undergone in its first 2...so maybe we should all just chill out a little bit.

    1. Re:Why not compare C++85 with C++89? by Anonymous Coward · · Score: 0

      But did C++89 break old code? There's a big difference between adding new language features, and changing them four months later.

    2. Re:Why not compare C++85 with C++89? by goose-incarnated · · Score: 2

      Some minor tweaks added in '89 (from wikipedia): multiple inheritance, abstract classes, static member functions, const member functions, and protected members.

      And even later still were added: templates, exceptions, namespaces, new casts, and a boolean type.

      C++ underwent way more fundamental changes in its first 10 years than Swift has undergone in its first 2...so maybe we should all just chill out a little bit.

      From what I remember of C++98 (the first C++ ANSI standard; I'm not sure where you got '89 from - perhaps you were thinking of C89 - the first ANSI C standard?), the committee used the standard to merely document the most popular behaviours of the most common compilers, hence by design the C++98 broke no existing code.

      And, as far as I can tell, the committee repeats this intention for each new standard - you can be almost guaranteed ("I've not heard of it happening") that a new C++ standard will not break existing code written to the previous standard.

      Personally, this feature of the C++ standards committee has always annoyed me - they take such great care to ensure they never break existing code that the end result is a language that is some bastardised unholy mess of its previous incarnations and whatever new fad is going around at the moment. Last I looked, there was what.... 3 different language constructs to iterate across a container?

      You can accuse C++ of a lot of things (and I frequently do), but saying that each new C++ standard breaks existing code is 100% inaccurate. They take great care not to do so.

      --
      I'm a minority race. Save your vitriol for white people.
  52. C++ has templates and lambdas by tepples · · Score: 1

    C++ relies on the C preprocessor, which is very limited, on doing macros.

    C++ has type-safe and/or scoped alternatives to a lot of things that used to need C macros.

    Thanks to this you don't have scoped macros for example.

    C++ has namespaced templates.

    In rust the macro system is done much later in the process, so that you can declare a macro inside a function, and after the } closing brace the macro scope ends!

    In modern C++, you can likewise declare a lambda inside a function (example). This could replace the C-inspired use of macros as ghetto inline functions.

    1. Re:C++ has templates and lambdas by NotInHere · · Score: 1

      C++ has namespaced templates.

      The template system in C++ is really not something the language creators can be proud of. If you write a templated class, why do you have to prepend the template name before each and every method?? And it gets even harder if you don't want to put the entire class implementation into the header, but a separate file.

      In Rust making templated structs/functions/traits is really easy, but you are a bit more limited. For example, you can't do a template on things different than scopes and types (like numbers). Maybe numbers in templates will get added once MIR is working.

    2. Re: C++ has templates and lambdas by Anonymous Coward · · Score: 0

      Templates were added to C++ before some of Rust's developers and users were probably even born! C++ was also among the first mainstream languages to support templates/generics. They were also added later on in C++'s development. So C++'s templates should be seen as successful and pioneering work that has been used extensively in practice.

    3. Re: C++ has templates and lambdas by NotInHere · · Score: 1

      They were also added later on in C++'s development.

      Well yeah this is one of the problems of C++. Rust is a very clean language because it was designed with lots of features in mind, while C++ was published, and then those features got added on top, for decades. You end up with a very messy end product. Yes, Rust will most likely meet this fate as well, but when its outdated you can simply switch over to a newer language that promises to be stable.

      This is what Rust is about for me: breaking backwards compatibility with C/C++ so that you have a clean base with all the newer concepts already integrated from day one. C was a great language, back when it was designed. Same goes for C++. But now compilers are more powerful and can do things that were unthinkable back when C/C++ was originally designed.

  53. Re:Swift 2.0 by Anonymous Coward · · Score: 0

    Every new language goes through major revisions early in its life which is the exact reason why only professionals write production code in mature languages.

    All that one has to do is look at the evolution in PHP and Ruby as examples.

  54. Re:Swift 2.0 by tepples · · Score: 1

    So you are saying my PDP11 ML knowledge isn't obsolete?

    Different people define "obsolete" in different ways. I might feel justified in calling my 6502 assembly language knowledge not obsolete because just last year I found work as lead programmer for a project using it.

    it is a warning to avoid languages controlled by a single corporate entity.

    Which non-retro ISA isn't controlled by one company or a small handful thereof? ARM is controlled by ARM Ltd., and x86-64 is controlled by the Intel/AMD cartel. This leaves what? An older version of MIPS that Loongson processor adopted?

  55. Apache License 2.0 by tepples · · Score: 2

    Apple could discontinue Swift tomorrow and you would by out of luck.

    Unless someone else takes up maintainership of a fork of Swift under the Apache License.

  56. Re: Swift 2.0 by Anonymous Coward · · Score: 0

    You can use std for PS4, with some minor caveats. Your point is unsupported.

  57. Re:waste of time by macs4all · · Score: 1

    None of their products work well. They're all hopelessly out of date. Why would anyone ever use Swift? Java is far superior.

    God DAMN!!!

    Some people will even bitch when somebody GIVES them something!!!

    Now go crawl back under your slime-encrusted rock and DIE MOTHERFUCKER DIE!!!!

    You are not worth wasting the planet's oxygen.

  58. Re:Swift 2.0 by Anonymous Coward · · Score: 0

    The same one that controls your reading skills.

  59. Where is the source tarball? by Bing+Tsher+E · · Score: 2

    Is anybody going to bite on a new proprietary language? Have we not learned anything from what Oracle has done with Java?

    1. Re:Where is the source tarball? by Anonymous Coward · · Score: 0

      Even better than a tarball, it's hosted on github: https://github.com/apple/swift

  60. Re: Swift 2.0 by Anonymous Coward · · Score: 0

    Mod this man up please. He Hit the nail on the head. A nail full of Rust, but he did it in a Swift manner, but now the nail looks like a C. I guess that's a ++

    Hehe sorry but mod him up. He is 100% correct.

  61. Re:Swift 2.0 by macs4all · · Score: 0

    Too bad if you put time into learning Swift 2.0. That knowledge is now obsolete. And when Swift 4.0 comes out, your Swift 3.0 knowledge will be obsolete. My advice to young programmers: avoid languages owned by corporations. They have time and money to waste. You don't.

    You must be some kind of piss-poor excuse for a developer if you can't handle a little bit of syntactic growing pains in a brand new language.

    My feeling is that you simply saw "Apple" and warmed up your flamethrower.

    You have never written a single byte of code in your life.

  62. Re: Swift 2.0 by Anonymous Coward · · Score: 0

    State of Flux. 3.0. Pick one.

  63. Re: Swift 2.0 by tepples · · Score: 2

    Perhaps a nicer way to express it might have been "As of right now, this language is too unstable for me to use in production. I'll let others be the guinea pigs until it matures."

  64. Re: Swift Objective C by Anonymous Coward · · Score: 0

    No, otherwise, the statement would've been that "Swift > C". No, the superiority of Swift is only in comparison to the things that Objective-C adds to the original C language. And pretty much everyone outside of the RDF agrees that Objective-C is a terrible language, while original C is not.

  65. Re:Swift 2.0 by macs4all · · Score: 1

    Different people define "obsolete" in different ways. I might feel justified in calling my 6502 assembly language knowledge not obsolete because just last year I found work as lead programmer for a project using it [3dcartstores.com].

    Hey! I read somewhere a few years ago that the 6502 is/was the most popular CPU core in application-specific ICs. Might not be true anymore, but you don't exactly need a 32 bit ARM for a LOT of things even now, and PICs are too pricey for a lot of applications.

    Plus, there isn't a more "accessible" ML than the 650x instruction set.

  66. Re:Swift 2.0 by tepples · · Score: 1

    What corporations control Python?

    I can think of two possibilities: Python Software Foundation Inc. and Dropbox, which employs Python BDFL Guido van Rossum.

  67. Re:Swift 2.0 by angel'o'sphere · · Score: 1

    So, I'm not able to maintain my Swift 2.2 code anymore just because Swift 3.0 or 4.0 is out?
    Strange, I had assumed my old Swift 2.2 compiler just runs as usually.

    What strange Computers are you working on that old Compilers suddenly stop working?

    Moron? Again so insulting ... you suffer from an ulkur or something?

    However you are right about Java 1.1, another corporate product.
    You missquote me. My Java 1.1 knowledge is still needed for maintaining legacy code, just as my rudimentary Cobol knowledge :D

    --
    Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  68. Re:Swift 2.0 by macs4all · · Score: 1

    Apple developers are probably used to the abuse by this point considering that the Mac itself has undergone three architecture changes as they moved from the Motorola 68000 to IBM PowerPC and then to x86. I wouldn't be surprised if in another five years they've completed abandoned x86 and move to using their own ARM SoC designs for all of their products.

    It's not abuse; it's evolution, and Apple, it's development community (assisted in no small measure by some VERY clever tools and APIs by Apple), and it's OSes have done a FANTASTIC job of making those transitions nearly painless for the average Mac user.

    Can you imagine the clusterfuck that would ensue if MS tried to do that with Windows? Hell, they couldn't even do a transition from 32 bit to 64 bit ON THE SAME CPU without a bunch of bullshit THAT AFFECTS THE USER (separate 32 and 64 bit OSes, APIs, Drivers, Apps, etc). WHAT a CLUSTER!!!

    To my knowledge, The only time that kind of BS affects a Mac user is with AU plugins. And there are "wrappers" that in most cases can handle even that without involving a recompile or redesign of the plugin.

  69. Re:Swift 2.0 by macs4all · · Score: 1

    True, but relatively speaking, the change overs weren't completely horrific. The 68K and Mac OS 9 emulation stuck around for quite a while before being dropped. The "Universal apps" were also quite a clever use of NeXT's tech with multi-arch binaries.

    I think you can STILL run Carbon Apps (as long as they are at least universal binary), even though Carbon has been deprecated for SEVERAL years now.

  70. Re:Swift 2.0 by macs4all · · Score: 1

    C++ is 30+ years old. Swift 2.2 is 4 MONTHS old and is obsolete. I hope you see the difference here.

    Yes, C++ is mature (God help it). Swift is still evolving.

  71. Re:Apple is expected to be perfect on the first tr by Anonymous Coward · · Score: 0

    Have other languages made the syntax incompatible on each version? This is just as stupid as if C++17 would replace "{" and "}" chars with "begin" and "end".

  72. Re:Swift 2.0 by Dog-Cow · · Score: 3, Informative

    Not everyone is a lazy shit. It takes about 5 minutes to update a moderately-sized code base from 2.2 to 3.0 syntax. Xcode provides a built-in tool to do it for you, and you just have to fix up the few cases it doesn't find on its own. It's really trivial for anyone who isn't a spoon-fed piece of dirt.

  73. Re: Swift 2.0 by Bing+Tsher+E · · Score: 1

    After they gave up being a hardware box vendor, NeXT was more cross platform than many people give them credit for. I have a NeXTStep Os installer CD set for HP's PA-RISC.

  74. Re:Swift 2.0 by Dog-Cow · · Score: 1

    Discontinue? They open-sourced the standard library, not to mention the compiler. If someone wants to use it, they can, no matter what Apple does with it.

  75. Re: Apple is expected to be perfect on the first t by Anonymous Coward · · Score: 0

    They can't do that, it would screw up my 'begin' and 'end' macros.

  76. Re:Swift 2.0 by Dog-Cow · · Score: 1

    If by "rewrite" you mean "spend 5 minutes using the built-in Xcode wizard", I guess just about the entire world. It's a shame you choose to be a degenerate shit.

  77. Re: Swift 2.0 by Bing+Tsher+E · · Score: 1

    One could argue that M6800 is a nicer arcitecture to code for, but 6800 is a dead architecture. M6809 is better than 6502, too, but another dead architecture.

  78. Why shift, rust or go when there is julia by Anonymous Coward · · Score: 0

    Julia is far better language than those 3 new commer.....

    1. Re:Why shift, rust or go when there is julia by __aaclcg7560 · · Score: 0

      Julia Childs was a great cook, but I wouldn't let her touch my code.

    2. Re:Why shift, rust or go when there is julia by shutdown+-p+now · · Score: 1

      Because Julia is a language focused on a very specific thing, and that very specific thing is not UI and other stuff that is common in a typical desktop or mobile app.

  79. Re: waste of time by Bing+Tsher+E · · Score: 1

    Microsoft gives us Windows 10.

    I want to try Swift on my NetBSD system. Where is the source tarball for this "free" language they're giving away?

  80. Re: Swift 2.0 by Bing+Tsher+E · · Score: 1

    So this language is so "open" that it's only usable within Xcode? It sounds like a small world propritary deal.

  81. Re: waste of time by Anonymous Coward · · Score: 0

    The main Swift repository, which contains the source code for the Swift compiler, standard library, and SourceKit.
    https://github.com/apple/swift.git

    Documents related to the continued evolution of Swift, including goals for upcoming releases proposals for changes to and extensions of Swift.
    https://github.com/apple/swift-evolution.git

  82. Re:Apple is expected to be perfect on the first tr by bondsbw · · Score: 1

    The set of things classified as a "revision" is obviously a superset of things classified as "breaking change". If you stay out of the "breaking change" category (e.g. only new syntax that did not previously compile) then it isn't a problem.

    Yes, there are plenty of language updates which do not break existing code. When they do, many language design teams strive to limit any breaking changes to concepts that are only used by a very small number of people, or bugs which result in undocumented behaviors that very few or no developers rely on.

    Then there's the case at hand, which sounds like nearly all existing code will break in some way. It's completely different.

    --
    All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
  83. Re:Swift 2.0 by OzPeter · · Score: 2

    So, I'm not able to maintain my Swift 2.2 code anymore just because Swift 3.0 or 4.0 is out?
    Strange, I had assumed my old Swift 2.2 compiler just runs as usually.

    Well Xcode 7 only came with a Swift 2 compiler, so you could not maintain Swift 1 code with that version. I assume that once Swift 3 is officially out that Xcode will pull a similar trick regarding Swift 2.x

    However Apple does supply migration tools that the "person" you are replying too is seeming to totally ignore.

    --
    I am Slashdot. Are you Slashdot as well?
  84. Re: Swift 2.0 by OzPeter · · Score: 2

    So this language is so "open" that it's only usable within Xcode? It sounds like a small world propritary deal.

    And 5 seconds on google finds Introduction to Open source Swift on Linux

    --
    I am Slashdot. Are you Slashdot as well?
  85. Re: Swift 2.0 by rochrist · · Score: 1

    Are you really as stupid as you make yourself out to be? Or merely a troll?

  86. Re: Swift 2.0 by rochrist · · Score: 1

    It's perfectly usable outside of XCode.

  87. Re:Apple is expected to be perfect on the first tr by __aaclcg7560 · · Score: 2

    Have other languages made the syntax incompatible on each version?

    Compatibility was broken between Python 2 and Python 3 to clean up the language. For example, print "Text" in Python 2 got replaced by print("Text") in Python 3.

  88. Re: Swift 2.0 by macs4all · · Score: 1

    One could argue that M6800 is a nicer arcitecture to code for, but 6800 is a dead architecture. M6809 is better than 6502, too, but another dead architecture.

    Wow! FINALLY something we can agree on, LOL!!! Mark this date on your calendar!!!

    I LOVE the 6809. It's more like a miniature 68k in some respects than a beefed-up 6800. I just wish it had caught on as a core for Mot.'s MCUs, rather than the pissant 6801 core they used in the 6805 and HC11 series.

    I have written tens and tens of thousands of lines of Assembly code for all of those cores, and even modified a popular Apple ][ 6502 assembler to cross-assemble 6809 (and later, even 8085) code.

    Good times, good times...

  89. Lots of choices. by fyngyrz · · Score: 3, Interesting

    I write applications (big ones) for OS X using c and c++. Targeting 10.6.8, my code still works fine under 10.11 today. It ports to Windows easily as well. Re Windows, targeting XP, it all works right up to the current version of Windows. XP broke the OS windowing metrics, otherwise my stuff would still work with Win98. :) Apple hasn't done anything quite that stupid. Well, yet. 10.6.8 is where 64-bit code began to work; and it's the last OS X that supports PPC (my HP calculator emulation, bunch of audio drivers, my old mame (which is actually fairly important to me, because some of those games are my code, and code from close friends in the day, and I want that stuff to work as long as possible), all kinds of stuff in Appleworks, etc., etc. So 10.6.8 is where I planted my flag, so to speak.

    Of course if you decide Swift or Objective C is your chosen coding mechanism, that's fine, but there's no externally imposed requirement that it must be your coding mechanism; at the worst, a few boilerplate intermediate layers based on basic OS APIs will do ya.

    Sometimes -- for instance, with Apple's OS file dialogs -- the stuff Apple supplies is either broken, feature-poor, or both. After being bitten over and over by that stupid file dialog, I spent an afternoon and wrote my own. Which works a damn sight better, and faster, and with less hangups than Apple's does. My users benefit a great deal from my unwillingness to let Apple screw them with the bug-infested trail of tears they leave behind them as they blunder onwards into their new and shinier future.

    Same thing for most (all?) of Apple and Microsoft's "new and shiny." For every new thing you decide you depend on in the OS, you're leaving users behind, and making your code more and more dependent upon Apple's latest whim.

    Which, again, you can do, absolutely -- but you don't have to.

    Almost every time I see some application that "requires" some fairly late version of an operating system, I think dark thoughts. There are few things, particularly things that are focused upon new features, where it is likely reasonable. But mostly... not. Mostly it's just thoughtless development where the user takes a back seat to... let's face it: "shiny."

    --
    I've fallen off your lawn, and I can't get up.
  90. Python != Python; now Swift != Swift. by fyngyrz · · Score: 2

    Python 3 is not Python specifically because it will not run Python 2 code. Python 3 isn't just a "little" different. It's a lot different. Which is fine. Although they should have called it something other than Python, frankly, because it confuses a lot of people that Python != Python. Justifiably so.

    Swift appears to be undergoing the exact same schism. The new Swift is not the old Swift; if it breaks your compliant code, it's a new language. If it breaks some undocumented crap, that's something else entirely. But when you write to spec, and the New/Shiny won't run it -- that's an entirely new language, regardless of what little, or lot, remains syntax compatible. Swift != Swift.

    Python's 2-series remains 100% viable; the source code is out there. Dunno about Swift; I code Python all the time, haven't bothered with Swift (nor am I ever likely to.)

    My insignificant little message to all language designers is this: Once you make a spec beyond beta, if you break the spec, you're developing an entirely new language, and you should REALLY change the damned name.

    --
    I've fallen off your lawn, and I can't get up.
    1. Re: Python != Python; now Swift != Swift. by Anonymous Coward · · Score: 0

      Have you ever actually used Python 2 and Python 3? I ask, because the differences are nowhere near as severe as you make it sound like they are. There is even the 2to3 utility that can help automatically convert most Python 2 code to Python 3. Many Python libraries support both versions with very minor changes, too.

    2. Re:Python != Python; now Swift != Swift. by iTrawl · · Score: 3, Insightful

      And Qt5 breaks code written for Qt4 which, in turn, breaks code written for Qt3. And Windows 10 breaks drivers written for Windows 8. And Linux 2.6 broke code written for Linux 2.4 which broke code written for Linux 2.2. And I'm pretty sure modern C broke code written for ye olde C.

      That's what major version numbers are for: to announce Major Breakage (or possibly even General Breakage) and his mighty army of doom.

      --
      "Everybody's naked underneath" -- The Doctor
    3. Re:Python != Python; now Swift != Swift. by DrXym · · Score: 1
      Python 3 isn't that different 2 at all. It certainly cleans up some quirks and makes the language more unicode friendly but it's still Python. Running a script can fix or highlight the majority of issues, most of which are trivial to fix or identify. And lots of software packages run on either 3 or 2 and there compatibility libraries too.

      But the reality is ALL Python libraries should be on 3 now and Python 2 should have been mothballed. I can understand how when 3.0 first appeared it might have made sense to run both codebases side by side until it stabilised. But 3.x has been stable and production ready for at least the last 5 years and 2.x should have been mothballed all the way back then - no backports, no bug fixes, no support. But it wasn't. And so the Python community wastes its time split between two codebases with the consequent confusion, uncertainty, complexity, bugs and mixed messages to the outside world that it sends out.

      The fact you call 2.x viable speaks for that. 3.x is viable and preferable but 2.x hangs around Python's neck like a millstone. The way the Python community conducted this transition (or didn't) should serve as a warning to other language maintainers - get the transition over with and get it over with as fast as possible or watch your language wallow.

    4. Re: Python != Python; now Swift != Swift. by fyngyrz · · Score: 1

      Have you ever actually used Python 2 and Python 3?

      Yes, I use both. 3 for new projects where broad compatibility is not an issue, and 2 for the legacy projects that are already in place in 2, tested and spec-complete. Differences like...

      o print "this is a print statement",
      o print("this is a print statement", end=" ")

      ...thoroughly break existing code. That's all it takes, although of course there is more like that. My assertion is that when a language breaks perfectly good, spec-compliant code, it's a new language.

      --
      I've fallen off your lawn, and I can't get up.
    5. Re:Python != Python; now Swift != Swift. by fyngyrz · · Score: 1

      That's what major version numbers are for: to announce Major Breakage (or possibly even General Breakage) and his mighty army of doom.

      I use major version numbers to indicate major additions of features and bugfixes. I use minor version numbers to announce one or two features that may or may not be significant, and bugfixes.

      You know what I use to announce major breakage? Nothing. Because I don't break my applications. If I provided it to you and said it would do X under some OS, then my goal thereafter always incorporates making sure it does X under that very OS.

      So clearly, there's more than one way to employ version numbers. :)

      One thing about features: If you want to add something that does (some previously available thing) in a new way, the idea that the old way has to be taken out or disabled isn't actually a requirement. The old way already worked. Just don't break it. Add the new thing, and allow the users to use it if they like.

      For instance, print in Python. print "foo" could have remained, and fprint("foo") could have been added. Viola, new functionality, language not broken. Or, up top in the Python script, something like # -*- USENEWPRINT -*- could have been the means, or # -*- USEALLNEW -*- or etc. (though I think it's pretty clear that print + fprint is the best strategy.) It's not like we're short on memory these days.

      ( fprint , of course, is just a placeholder name.)

      --
      I've fallen off your lawn, and I can't get up.
    6. Re:Python != Python; now Swift != Swift. by fyngyrz · · Score: 1

      Python 3 isn't that different 2 at all.

      Nonsense.

      --
      I've fallen off your lawn, and I can't get up.
    7. Re:Python != Python; now Swift != Swift. by DrXym · · Score: 1

      Explain please.

  91. Re:Swift 2.0 by dgatwood · · Score: 1

    Different people define "obsolete" in different ways. I might feel justified in calling my 6502 assembly language knowledge not obsolete because just last year I found work as lead programmer for a project using it [3dcartstores.com].

    LDA year ; offset from 1900
    CMP #115
    BGE 75

    Or something.

    --

    Check out my sci-fi/humor trilogy at PatriotsBooks.

  92. Re:Swift 2.0 by angel'o'sphere · · Score: 1

    I'm in so far lucky that I did not start using Swift yet.

    However I'm watching the evolution of the language as I'm very convinced that we need languages that are "less expressive" (see C++ / PERL etc.) but more readable and more comprehendible (which makes them easier to teach, too).

    Now remove "." and "(" and ")" ... and we are close to SmallTalk.

    Why Swift 3.0 is writing:
    someObject.method(arg:"is it", arg2:"really", arg3:"cool?");

    When you could write it:
    someObject method arg:"is it", arg2:"really", arg3:"cool?"

    Is a bit hard to grasp.

    Bottom line Apple should probably rather invent its own VM ... probably based on LLVM, and open it to any compiler/language that compiles to it.

    Reminds me that I wanted to start a blog about the future of programming as I see it.

    --
    Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  93. Re: Apple is expected to be perfect on the first t by Anonymous Coward · · Score: 0

    The other side of that coin is that C++ is absurdly complicated partially due to attempts to keep it backwards compatible.

  94. Re:Apple is expected to be perfect on the first tr by shutdown+-p+now · · Score: 2

    Right. And it took, what, 15 years for Python to accumulate enough cruft that they decided to do this kind of major breaking milestone?

    Here, we're talking about a language that isn't even 2 years old.

  95. Re: Swift 2.0 by shutdown+-p+now · · Score: 1

    Rust doesn't try to actively present itself as stable and production-ready, though.

  96. Re:Swift 2.0 by shutdown+-p+now · · Score: 1

    Your C++ experience seems to be very dated. These days, you can easily write very complicated C++ programs using solely the standard library and Boost.

    The standard library may be small, but why does it mean that you have to use "unofficial extensions"? You find and use third-party libraries, and your portability is only limited by them - and there is no shortage of portable libraries for practically any purpose for C++. Heck, Qt alone covers 99% of what you'd typically want to do.

  97. Re:Swift 2.0 by NotInHere · · Score: 1

    Well the fact that these third party libraries are doing so well is just a proof that the std library sucks badly. Not in a way you wouln't want to use it though -- its working really great in fact, just that it misses so many things. But the libraries are also not as polished as std is, and with them you are under "corporate" control again, something 110010001000 wanted to avoid, no?

  98. Re:Swift 2.0 by shutdown+-p+now · · Score: 1

    You're only under "corporate control" if the library you're using is 1) maintained entirely by a single corporate entity, and 2) is not open source.

    Boost, for example, is entirely open source and lacks any centralized control. Qt has a company behind it, but the source is LGPL, so you can always fork if you need to. And so on.

    Pragmatically speaking, unless you use OS APIs directly (like, say, Win32), it's very hard to lock yourself in with C++.

  99. Re:Swift 2.0 by NotInHere · · Score: 1

    Well swift and rust as well as java (I think the only three corporate controlled languages 110010001000 used as example) are all open source as well. Still they are under corporate control.

  100. Re:Swift 2.0 by macs4all · · Score: 1

    Different people define "obsolete" in different ways. I might feel justified in calling my 6502 assembly language knowledge not obsolete because just last year I found work as lead programmer for a project using it [3dcartstores.com].

    LDA year ; offset from 1900

    CMP #115

    BGE 75

    Or something.

    BGE was actually NOT a 6502 mnemonic. It was a 6809 instruction (and maybe 6800). But some 6502 assemblers had a BGE macro, IIRC. It translates to BCS (Branch on Carry Set).

  101. Re:Swift 2.0 by shutdown+-p+now · · Score: 1

    There is a big difference between the language, and the library. In any sane ecosystem (where things aren't deprecated and removed every six months), libraries keep working for a very long time - so it is viable to fork one and just use it. Having to fork the compiler and the rest of the toolchain (IDEs etc) is a lot more work.

  102. Re: Swift 2.0 by macs4all · · Score: 1

    You are conflating compilers with language stability. The fact is that Apple could discontinue Swift tomorrow and you would by out of luck. Avoid corporate controlled languages.

    FFS, what "Corporate Control"???

    Did you miss the part where Apple OPEN SOURCED Swift, and basically dumped the ENTIRE Project on GitHub???

    JEEZUS, you're stupid.

  103. Re:Swift 2.0 by macs4all · · Score: 1

    Apple told developers that Swift 2.2 would be obsolete in 4 months? Wow, and people still used it? How stupid.

    So, when some random FOSS project by some neckbeards releases a bunch of updates in short order they're "in active development"; bug when Apple does it, they're The Great Satan?!?

  104. Re: Swift 2.0 by macs4all · · Score: 1

    I guess the fact that 18 years >> 4 months is lost on you. Oh well, enjoy Swift until Apple gets bored with it and discontinues it and replaces it with something "better".

    Apple isn't Google. In oh, so many ways (thank Diety).

  105. Re:Swift 2.0 by macs4all · · Score: 1

    Yes I am suggesting C++ is a lot better. What the fuck does Microsoft and cross platform have to do with anything?

    A lot better than what? A kick in the teeth? Yeah, probably; but only just...

    C++ ain't all that. Actually it was INTENTIONALLY DESIGNED AS A PRANK. In fact, according to the Father of C++ Bjarne Stroustrup, the joke's on YOU...

    So, enjoy your PRANK of a Language, Suckas!!!!

  106. Ummm, no. C++ was nearly 20 years old by 1998. by Brannon · · Score: 1

    It started out as "C with classes" in 1979 and by 1985 there was a book called "The C++ Programming Language".

    There were lots of code-breaking changes between 1979 and 1985, it just wasn't a widely used language at the time.

    1. Re:Ummm, no. C++ was nearly 20 years old by 1998. by goose-incarnated · · Score: 1

      It started out as "C with classes" in 1979 and by 1985 there was a book called "The C++ Programming Language".

      There were lots of code-breaking changes between 1979 and 1985, it just wasn't a widely used language at the time.

      I know how it started out, but there wasn't a C++ standard (hence breaking changes between implementations) nor a reference implementation that serves as a standard.

      In this case, there is a reference implementation, which is breaking itself between versions. C++ never had a reference implementation or a standard at the time you were referring to.

      --
      I'm a minority race. Save your vitriol for white people.
  107. Re:Swift 2.0 by macs4all · · Score: 1

    Yes I am suggesting C++ is a lot better. What the fuck does Microsoft and cross platform have to do with anything?

    A lot better than what? A kick in the teeth? Yeah, probably; but only just... C++ ain't all that. Actually it was INTENTIONALLY DESIGNED AS A PRANK. In fact, according to the Father of C++ Bjarne Stroustrup, the joke's on YOU... So, enjoy your PRANK of a Language, Suckas!!!!

    Ok, so I'll "out" myself before anyone else does...

    The "IEEE" interview linked-to above is (well, duh!) a FAKE!

    Gas Music From Jupiter, INDEED!!!

    But according to the "horse's" website, HERE IS THE REAL INTERVIEW.

    Or is it...? (Sorry, couldn't resist)

  108. That's absurd. by Brannon · · Score: 1

    There were C++ implementations going all the way back to the early 1980s. Do you really think it was a programming language on paper only for 20 years?

    1. Re:That's absurd. by goose-incarnated · · Score: 1

      There were C++ implementations going all the way back to the early 1980s. Do you really think it was a programming language on paper only for 20 years?

      I didn't say it wasn't a programming language, I said it wasn't standardised. Of course, now that I think about it, I don't ever recall any vendor breaking existing code between releases pre-standardisation. With Swift there is only a single vendor, and that vendor breaks existing code between releases.

      --
      I'm a minority race. Save your vitriol for white people.
  109. Re:Swift 2.0 by tigersha · · Score: 1

    Yes, they still used it. Just like they still used 8086 assembler back in the day when they knew 16 bit and 32 bit was coming and just like they used Word v1 knowing that v2 would come soon.

    --
    The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
  110. Re:Swift 2.0 by tigersha · · Score: 1

    I had to upgrade a not-too-big codebase from Rails 2 to Rails 4 a few months ago. That was a looooot of work. Swift 2-3 is a joke. The moaners here will moan. Besides, this sort of stuff keep us in work!

    --
    The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
  111. Re:Swift 2.0 by tigersha · · Score: 1

    At least your PDP skills are not obsolete:

    http://www.vcfed.org/forum/sho...

    --
    The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
  112. Re:Swift 2.0 by tepples · · Score: 1

    But some 6502 assemblers had a BGE macro, IIRC. It translates to BCS (Branch on Carry Set).

    Furthermore, the datasheet for the WDC 65816 encouraged assemblers to include this macro.

  113. Re:Swift 2.0 by macs4all · · Score: 1

    But some 6502 assemblers had a BGE macro, IIRC. It translates to BCS (Branch on Carry Set).

    Furthermore, the datasheet for the WDC 65816 encouraged assemblers to include this macro.

    Interesting.

    I actually put the 8-bit-bus version of the WDC 65816 (can't remember the exact p/n (65802?)) in my Apple ][+, and, IIRC, defined macros in the Orca/M assembler (which I really didn't like) for it.

    I also have an AppleIIgs that I bought off eBay for some paltry sum. Don't those have '816s in them, too?

  114. Re:Swift 2.0 by tepples · · Score: 1

    Apple IIGS and Super Nintendo Entertainment System are probably the best-known consumer products with a 65816. The IIGS has a standalone '816; the Super NES has a Ricoh 5A22, which puts a licensed '816 core on the same die as a custom memory controller for the DMA functionality that kept pace with Sega's "Blast Processing".

  115. Re:Swift 2.0 by macs4all · · Score: 1

    Apple IIGS and Super Nintendo Entertainment System are probably the best-known consumer products with a 65816. The IIGS has a standalone '816; the Super NES has a Ricoh 5A22, which puts a licensed '816 core on the same die as a custom memory controller for the DMA functionality that kept pace with Sega's "Blast Processing".

    Oh yeah. I forgot about the Super NES having an '816, and I didn't know that Ricoh had done a CSIC with the '816 core. Fascinating!