Slashdot Mirror


Swift: Apple's Biggest Achievement For Coders

GordonShure.com writes: Despite its publicity and hype being rather quiet by Apple standards, the Swift programming language has attracted praise since its release last year. Swift is one of the few Apple products that represent a departure from the hardware-led Steve Jobs approach to the business. If this year's survey of coders by Stack Overflow is anything to go by, it looks as if the language might have potential to really shake things up in a landscape which has been little changed since the 1990s. Might the days of Apple programmers relying upon objective C be numbered?

337 comments

  1. One more in a crowded field by TWX · · Score: 5, Insightful

    How's Swift's cross-platform suitability?

    There are two Apple platforms, one popular Google platform, one less-popular Google platform, plus Microsoft's platform. Is Swift suitable for writing applications for all? If not, developers would be writing for a limited, albeit popular platform, but limited to a certain subset nonetheless.

    --
    Do not look into laser with remaining eye.
    1. Re:One more in a crowded field by Anonymous Coward · · Score: 2, Interesting

      No, and that's what Apple wants.

      Most developers will pick Apple over Android. Then you have to rewrite the code for Android. Apple will get first release on a lot of apps, just what they prefer.

    2. Re: One more in a crowded field by Anonymous Coward · · Score: 3, Informative

      Most developers? I don't know who you have been talking to or what you have been reading (maybe you work at Apple?), but the Android market share is much greater than the Apple market share. Plus it doesn't take much for a Java dev to turn his/her skills to Android, and C is the only language more popular than Java. In reality I doubt either platform will have issue finding developers.

    3. Re:One more in a crowded field by Lunix+Nutcase · · Score: 2
    4. Re:One more in a crowded field by MassacrE · · Score: 1

      Three apple platforms now: iOS, Mac OS X and watchOS.

      Swift has had a lot of up-front design decisions made to ease what will be a long transition from objective C - methods with named parameters to match Objective C rules, the ability to see if you have a single reference (a feature of reference counting) is a feature needed to optimize string and collection types, so use in a non-reference-counted system would be a pain. Also things like the error model are quite different.

      This would make it more difficult to compile to java/dalvik byte code or .Net CIL (java/dalvik being way harder). This does not preclude native compilation via the open-source compiler and bridging.

      While Apple audited their APIs to make sure their API bridging generator worked well and created nice APIs everywhere, and even added some language features to Objective C to fill in the gaps, a third party like Google or Microsoft would not have such 'guided' translation - they would need to design Swift-like APIs to expose.

      Its possible, but not close to free.

    5. Re: One more in a crowded field by ShanghaiBill · · Score: 3, Insightful

      the Android market share is much greater than the Apple market share.

      For phones, yes. For apps, no. The average iOS user buys far more apps than the average Android user.

    6. Re:One more in a crowded field by IamTheRealMike · · Score: 5, Interesting

      Is Swift suitable for writing applications for all? If not, developers would be writing for a limited, albeit popular platform, but limited to a certain subset nonetheless.

      No, it's Apple specific. However that's OK because there's a language which is much like Swift, except it runs on pretty much every device you might have.

      That language is new. It's called Kotlin, and it is from JetBrains, the makers of the highly popular IntelliJ series of IDEs (+ WebStorm, PHPStorm, RubyMine, PyCharm etc).

      Kotlin targets the JVM and JavaScript. It interops perfectly with Java. That means code written in it runs on Windows, Mac, Linux and Android. Additionally, via the RoboVM project, JVM bytecode can be compiled to native ARM iOS/OSX binaries. There is no JIT compiler. RoboVM provides bindings to all Objective-C APIs on iOS so you can build native UIs and access all the same functionality as a native app. Programs written this way are on the app store, so Apple is cool with the technique.

      Kotlin has a clean, concise syntax and many modern features that match those in Swift. For example it has nullability/optionality integrated with the type system. It has Markdown comments. It has extension functions. It has some support for pattern matching. It has named parameters. It has the ability to define "data classes" that have easy immutability, content equality, hashcodes, serialization etc all in a single line of code. It has type inference and compile-time inlined lambdas, so you can do high performance functional programming with it. It has features to support complex DSLs. It has a full IDE with many built in refactorings, online static analysis, and via the JVM it has high quality CPU/memory profilers and debugging support.

      In short, programming with Kotlin is much like programming with Swift, except you have better tools, an IDE at least as strong as Xcode and in my experience stronger, and you can write apps with it that are indistinguishable from native iOS and Android apps.

    7. Re:One more in a crowded field by Lunix+Nutcase · · Score: 1

      Microsoft has already announced an Objective-C toolchain for Windows that certain select groups have already been using.

      With Project Islandwood, iOS developers will be able to take their iOS apps and build them for Windows. Microsoft has developed an Objective C toolchain and middleware layer that provide the operating system APIs that iOS apps expect. A select group of third parties have been using the Islandwood tools already, with King's Candy Crush Saga for Windows Phone being one of the first apps built this way. King's developers had to change only a "few percent" of the code in order to fully port it to Windows Phone.

    8. Re: One more in a crowded field by Feral+Nerd · · Score: 5, Informative

      Most developers? I don't know who you have been talking to or what you have been reading (maybe you work at Apple?), but the Android market share is much greater than the Apple market share. Plus it doesn't take much for a Java dev to turn his/her skills to Android, and C is the only language more popular than Java. In reality I doubt either platform will have issue finding developers.

      He is talking about profit potential, not who's got his OS installed on the most devices. The implication is that iOS development is more profitable than Android development which is something that I have heard from more mobile developers than just him.

    9. Re:One more in a crowded field by IamTheRealMike · · Score: 1

      Oops, I forgot something important.

      There is a simple web based IDE that you can use to experiment and learn the language at try.kotlinlang.org. For me it seems there's a layout issue with Chrome right now, but it works fine in Safari.

    10. Re: One more in a crowded field by Anonymous Coward · · Score: 1

      You're missing the point. Market share doesn't matter: money does. Android has all the market share, and Apple makes all the money. Almost 90% of the money is in the Apple ecosystem, so THAT is where developers develop first. Android is an also-ran if they get around to it.

    11. Re:One more in a crowded field by Anonymous Coward · · Score: 0

      In a similar vein, another question is why didn't they just adopt the syntax from Ruby or another equivalent scripting language and call it a day?

      Seriously, after (finally) reading through the language spec last week, that one question kept popping up. It's so close (standard blocks/closures, class structure, optionals, yada yada) that the only answer seems to be NIH syndrome.

      Don't get me wrong, it's a nice language and any competent programmer can pick it up in a couple days (i.e. map it to a language they already know). I just kept expecting to have my socks knocked off but in the end it was just another syntax to digest.

      YMMV.

    12. Re: One more in a crowded field by unami · · Score: 4, Insightful

      whatever the reason may be, this still makes apple's platform more interesting for professional developers.

    13. Re: One more in a crowded field by Anonymous Coward · · Score: 0

      Android market share is much greater than the Apple market share.

      LOL - who cares? Apple is where the money is. IOS apps makes 85% more revenue than Android. If I'm making an app, I'm making it for iOS first, and then porting to Android. So if my app is in Swift, and Android doesn't support Swift, well, maybe it won't get a lot of the best apps any more.

      http://www.fiercedeveloper.com/story/app-annie-ios-apps-get-85-more-revenue-android/2014-04-21

    14. Re: One more in a crowded field by Anonymous Coward · · Score: 0

      Android has the greatest market share, but falls way behind Apple in money spent by users. Developers will follow the money.

    15. Re:One more in a crowded field by Anonymous Coward · · Score: 0

      How's Swift's cross-platform suitability?

      We'll see the results after Apple open sources it later this year.

      Apple is one of the main sponsors of the BSD-licensed LLVM/clang project.

    16. Re: One more in a crowded field by bradrum · · Score: 0

      Yes, this, in my experience, still holds. I have heard many nerds make a case that Android should be the choice to develop for first and foremost (or even as a total equal). But those that write the checks still want to develop for iOS first and foremost quite a bit of the time.

    17. Re: One more in a crowded field by Anonymous Coward · · Score: 0
    18. Re:One more in a crowded field by bradrum · · Score: 1

      Its interface with cross-platform libraries like OpenGL/CL/etc... might give a tip I would believe. I am working on an app that uses quite a bit of OpenGL for 3D animations. Swift has had a rough start with bindings to lower level code, but it appears to be getting a lot better with version 1.2. Also the rules for interacting with unsafe code are pretty straightforward, when they work as designed lol. The situation is getting better in my experience.

      The interface between Swift and Objective-C++, the lack thereof, is kind of concerning to me. And when you bring in Objective-C++ to wrap your C++11 code you forfeit the new module based headers which can be a pain.

      You also don't have a pre-processor in Swift currently but there are some facilities to interact with the compiler and tell it which code you need to interface with your system.

      The compiler works on ARM and x86 so thats a start. I would imagine that targeting JVM would not be hard?

    19. Re: One more in a crowded field by 0123456 · · Score: 0

      I don't buy Android apps because they all want to spy on me and sell advertising.

    20. Re:One more in a crowded field by gnasher719 · · Score: 2, Informative

      No, it's Apple specific. However that's OK because there's a language which is much like Swift, except it runs on pretty much every device you might have.

      Well, pretty much any device accept the odd iPhone here and there?

      Looks like they are trying to create a Swift clone. Excuse me, but I think I prefer the real thing. Which will quite soon run everywhere, unless Google throws its toys out of the pram. And which has the brains of LLVM behind it. And most importantly, which is in actual use. Maybe Swift will never be as good as Kotlin's claims, but Kotlin will never be as good as Swift.

    21. Re: One more in a crowded field by Anonymous Coward · · Score: 0

      And Apple apps don't spy on you?

      How can you prove they don't?

    22. Re: One more in a crowded field by savuporo · · Score: 1

      If you are a developer, market share shouldn't concern you too much, as it changes every month when something new comes to market. Installed base is what most people would go by.
      There are very few reliable means of collecting installed base stats, but a cross-platform SDK from an ISV who isnt affiliated with any of the platform providers, powering many popular games would probably be a good first stop

      --
      http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
    23. Re: One more in a crowded field by mfearby · · Score: 2

      We may not be able to prove that a particular app isn't spying on us, but I can state with a high degree of confidence that said app isn't installing spyware on my device!

    24. Re:One more in a crowded field by fluffernutter · · Score: 1

      Waaay easier to slap something together in Java and then do the iPhone app. So much easier to make adjustments in Java.

      --
      Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
    25. Re:One more in a crowded field by itsdapead · · Score: 4, Informative

      Is Swift suitable for writing applications for all? If not, developers would be writing for a limited, albeit popular platform, but limited to a certain subset nonetheless.

      Well, Apple just announced that they are planning to open-source Swift and will be also be releasing a Linux version of the compiler. So the language itself isn't going to be Apple-only for much longer.

      However, that only solves the language problem - the big divide between platforms is the totally different APIs that developers have to learn. Frankly, that's usually a bigger learning curve than picking up a new language.

      Mind you, you can say the same for most of the big languages - off the top of my head only Java (and maybe Javascript/HTML5) come with baked-in crossplatform APIs suitable for writing GUI applications.

      --
      In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
    26. Re: One more in a crowded field by fluffernutter · · Score: 1

      Only if they have a poor business plan. Making money on the app alone is a hard way to go.

      --
      Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
    27. Re:One more in a crowded field by mfearby · · Score: 2

      Exactly. I've grown tired of all these new languages that claim to be better than the real thing. You're far better of using "the real thing", and I've never liked IDEA as an IDE (mind you, I think XCode's code editor and workspace tabs suck, too, but I've learned to tolerate it).

    28. Re:One more in a crowded field by mfearby · · Score: 1

      I've never used Ruby and I'm sure most Apple people haven't, too. I would have preferred a c# syntax but as it is, Swift's syntax isn't that bad. It's a LOT better than Objective-C!!!

    29. Re: One more in a crowded field by Anonymous Coward · · Score: 0

      I don't know about that. Android developers make money, they just tend to have more creative ideas for monetisation.

    30. Re:One more in a crowded field by fbartho · · Score: 1

      Hahahahaha

      --
      Gravity Sucks
    31. Re: One more in a crowded field by 0123456 · · Score: 2, Informative

      And Apple apps don't spy on you?

      How can you prove they don't?

      Well, for a start, you can deny them permissions when they try to do something you don't expect. When the Happy Kitty Screen Saver wants to access your camera and contacts on an Android tablet, you can't. You already had to accept 'let this app do random crap' when you installed it, or you wouldn't have been allowed to install it.

      As far as I'm concerned, Android isn't much use for anything other than a mobile web browser until it gets proper per-app permission controls.

    32. Re:One more in a crowded field by Applehu+Akbar · · Score: 1

      "How's Swift's cross-platform suitability?"

      Apple just open-sourced Swift, in hopes that it will be ported to other platforms.

    33. Re:One more in a crowded field by jblues · · Score: 2

      You can currently write Android apps in Swift with Apportable. Although Apple doesn't blow a whistle about this, most of the low-down parts of the stack are open-source. Moving up, Apportable have implemented in-house versions of Foundation, UIKit and so forth.

      In the coming months, Apple will be releasing Swift for Linux, though its not clear whether that will include Foundation and UIKit. If not I can see the Apportable ones possibly being open-sourced in the future.

      --
      If it acquires resources on instantiation like a duck, then its a shared_ptr<Duck>
    34. Re: One more in a crowded field by Anonymous Coward · · Score: 0

      In your opinion, they should sell an app administration service or sell app logo t-shirts instead?

    35. Re: One more in a crowded field by Anonymous Coward · · Score: 1

      I'd rather pay $1 for a good app with no ads than have it free. Go shill your shit somewhere else

    36. Re: One more in a crowded field by Anonymous Coward · · Score: 0

      For phones, yes. For apps, no. The average iOS user buys far more apps than the average Android user.

      Is that actually an important metric? There are a LOT more Android users. Particularly outside the US.

    37. Re: One more in a crowded field by Anonymous Coward · · Score: 1

      Probably because almost every app on android wants control of your phone and access to your data. I know since switching to Android I only buy apps from trusted sources, that don't ask for every permission under the sun.

    38. Re: One more in a crowded field by Bogtha · · Score: 1

      The average iOS user buys far more apps than the average Android user.

      Is that actually an important metric?

      It is for people who want to sell apps.

      --
      Bogtha Bogtha Bogtha
    39. Re: One more in a crowded field by perpenso · · Score: 1

      ... the Android market share is much greater than the Apple market share ...

      And app revenue is 1/4 to 1/5 on Android compared to iOS. Its actually still more profitable on the iOS side due to its users spending more per app.

      Plus it doesn't take much for a Java dev to turn his/her skills to Android, and C is the only language more popular than Java. In reality I doubt either platform will have issue finding developers.

      And C/C++ is probably what the core of your app should be written in so its portable to iOS, Android, Linux, Mac OS X and MS Windows. Only the user interface code needs to use java, swift, or objective-c. And its often best to just rewrite the UI in the language of the API for each platform.

    40. Re:One more in a crowded field by grcumb · · Score: 0

      Oops, I forgot something important.

      There is a simple web based IDE that you can use....

      'A simple web-based IIiiheheheheh—Sorry. Aherm. A simple web-baHAHAHAHAHahaha!!! Phew! Sorry! Don't know what got into me. Let me try that again: A IDE, you say? And its... shchrmf web-ba...heheheh, I mean, uh web-bAHAHAHAHAHA!!!!

      *wipes tears away*

      Sorry. I honestly don't know what got into me... WHEW!! All righty then. Sorry, just let me catch my breath and...

      Now: A Simple. Web-based—mrfmmmmrfmmmffff—Web. Based....

      AAAAAAAHHHHHHHAHAHAHAHAHAHAHAHAHAHA!

      I'm sorry. A web-based IDE! HAHAHAHAHA!!!!! Hey Chuck, get in here. This guy has a simple web-basedAAHAHAHAHAHA!!! Sorry, just read that, yeah, there. HAHAHAHAHA!

      [Falls down. Dies laughing.]

      --
      Crumb's Corollary: Never bring a knife to a bun fight.
    41. Re: One more in a crowded field by angel'o'sphere · · Score: 1

      Or use Qt for the frontend.

      Honestly: it makes no sense at all to rewrite GUI code.

      50% or more of the code for an app is GUI ...

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    42. Re:One more in a crowded field by Chalnoth · · Score: 3, Insightful

      Just as with Objective-C, I doubt that hardly anybody else will make use of the language.

      The problem is it just doesn't have all that much to offer for projects that are already making use of other languages. It's got a few slick features, but it can't really stand out all that much and the library support is going to be very far behind more mature languages for a long time (if not forever).

    43. Re: One more in a crowded field by bigfinger76 · · Score: 2

      Wrong. The money is in the hardware; app developers don't get any of that.
      Quoting the article you linked:
      "The figures given here relate to profits generated by handset makers, not the services ecosystem and potential profits made by app publishers and others..."

    44. Re: One more in a crowded field by KGIII · · Score: 1

      Does this matter when Google outsells Apple by a large margin? Example, if the average Apple user spends $1 and the average Android user spends $0.5 and the Android outsells the Apple by a margin of 10:1 then which one makes more sense to develop for?

      --
      "So long and thanks for all the fish."
    45. Re: One more in a crowded field by KGIII · · Score: 1

      So you are converting to Android then?

      http://www.androidcentral.com/...

      --
      "So long and thanks for all the fish."
    46. Re:One more in a crowded field by Anonymous Coward · · Score: 0

      Just like they plan on open-sourcing Facetime?

    47. Re:One more in a crowded field by dbraden · · Score: 1

      I get what you're saying, and agree with you, but from what I can tell it's not trying to be an IDE, just a way to try out the language in a browser. With all of the examples, it's a good way to get a taste of what the language has to offer. Just my 2 cents.

    48. Re:One more in a crowded field by Anonymous Coward · · Score: 0

      Hello? Qt is a cross platform API - of course, you have to learn that most arcane and dead of languages: C++ to use it, but if your tiny pea brain can handle the arcanity, then one API can rule all platforms.

    49. Re: One more in a crowded field by Anonymous Coward · · Score: 0

      Don't confuse quantity (more android devices) with return on investment (how much money you get back) . There's a reason Apple is one of the most valuable companies in the world. They have a smaller market share but way more revenue, as do developers working on iOS platform.

    50. Re: One more in a crowded field by Anonymous Coward · · Score: 0

      Plus a lot of andriod phones don't run a lot of android apps. I know because I have phones from a certain market leading company that have problems running apps despite having a mid end hardware. I suspect it is due to the bloat ware that came installed.

    51. Re: One more in a crowded field by Anonymous Coward · · Score: 0

      The syntax of swift is very similar to scala. If you are seeing snippets of non UI codes, it can be difficult to distinguish the two.

    52. Re: One more in a crowded field by laird · · Score: 1, Insightful

      Most business models for apps are based on people using the apps. While Android leads in terms of unit sales, iOS leads (by a surprisingly large margin) in terms of app installs and usage. There are a lot of Android phones that are basically used as "feature phones" with the ability to browse the web and run apps ignored.

      So if what you care about is people installing and using your app, the numbers drive you to iOS.

    53. Re: One more in a crowded field by laird · · Score: 2

      QT gives you a "least common denominator" GUI everywhere. If your UX matters at all, you're better off writing a native GUI layer for iOS and Android, so your app doesn't suck compared to competitors.

    54. Re:One more in a crowded field by BasilBrush · · Score: 1

      Objective-C never took off elsewhere because C++ was pretty much an equivalent (lacking runtime introspection but making up for that by being a little faster).

      Swift on the other hand has a lot of desirable features, that are not available elsewhere. I've listed some in a post under the last Swift story we had. So either some other language takes on these features, or at least some non-Apple programmers are going to be attracted to Swift.

      Library support is easy, as Swift can adopt C based libraries. Either calling directly, or wrapped.

    55. Re:One more in a crowded field by omfgnosis · · Score: 1

      And then your app can have the desirable quality of feeling equally not-at-home on every platform.

    56. Re: One more in a crowded field by 0123456 · · Score: 1

      1. The odds of any of my Android devices getting an upgrade to that version are roughly zero.
      2. As I understand it, only apps written for the new OS will have real permission controls.

    57. Re: One more in a crowded field by BasilBrush · · Score: 1

      Not really, because iOS has native 3D APIs. Unity is used by some of the developers that are multi-platform. But those developers who are iOS only, and there are many, are probably not using Unity.

    58. Re:One more in a crowded field by DaphneDiane · · Score: 1

      Just like they plan on open-sourcing Facetime?

      Most likely, and if something similar to the patient issue with FaceTime crops up I wouldn't be surprised on a reversed course similar to what happened with FaceTime. That said I'm assuming that the hints that they wanted to open source the language at it's introduction combined with delay between then and the announcement of planning to open source meant they may have taken steps to avoid such issues this time.

    59. Re:One more in a crowded field by Anonymous Coward · · Score: 2, Informative

      Looks like they are trying to create a Swift clone. Excuse me, but I think I prefer the real thing. Which will quite soon run everywhere, unless Google throws its toys out of the pram. And which has the brains of LLVM behind it. And most importantly, which is in actual use. Maybe Swift will never be as good as Kotlin's claims, but Kotlin will never be as good as Swift.

      Kotlin has been released in 2011, so I don't think it tries to be a clone of Swift. It's more a "Java replacement", like Ceylon, Gosu or Fantom, which is not a bad idea when you have something like Oracle Corp which get to decide how to manage an open technology (Java...)

    60. Re: One more in a crowded field by tlhIngan · · Score: 0

      I'd rather pay $1 for a good app with no ads than have it free. Go shill your shit somewhere else

      And therein lies the problem.

      It turns out iOS users don't mind paying for apps, but Android unfortunately through its early part in life pretty much only encouraged free apps - paid apps were second class citizens (they never showed up if users couldn't pay for it, and the early days of Google Wallet meant everyone outside the US. We had an Android app that we developed, but could not buy, which was hilarious when the CEO mentioned we could expensive it).

      The business model for iOS is to develop a good app on iOS and just charge for it - if it's a good app, people will pay for it. There are plenty of games on iOS that cost $5 or more.

      On Android, however, people won't pay for apps, so your only real way of making money is to make it free and make it up in ads.

    61. Re: One more in a crowded field by Anonymous Coward · · Score: 0

      You're assuming that the average Android user spends even as much as half as an iOS user. It could well be a 10:1 ratio.

      I've never bought any apps for my Android devices. Ever. And I have a reasonable number of apps. There's a lot of free out there. Well, ad-supported, but same difference, aside from the annoyance.

    62. Re:One more in a crowded field by grcumb · · Score: 1

      I get what you're saying, and agree with you, but from what I can tell it's not trying to be an IDE, just a way to try out the language in a browser.

      I know. I was just having a lark. :-)

      --
      Crumb's Corollary: Never bring a knife to a bun fight.
    63. Re: One more in a crowded field by perpenso · · Score: 1

      Apologies, I hits the submit button prematurely. Please read my response to my other post, its the full response, the first was a work in progress.

    64. Re: One more in a crowded field by Anonymous Coward · · Score: 0

      Actually, Kotlin has been publically under development for several years before the name "Swift" was ever mentioned outside of Apple. If anything, Swift copied Kotlin rather than vice versa. Please check your facts before making claims like this!

    65. Re:One more in a crowded field by Man+On+Pink+Corner · · Score: 1

      Looks sharp. They need to hire a Marketing Dork to come up with a name that either means something to someone besides Mrs. Kotlin, or is otherwise snappy and memorable. Otherwise, it's going to be hard to gather any mindshare.

    66. Re:One more in a crowded field by Anonymous Coward · · Score: 0

      There are two Apple platforms, one popular Google platform, one less-popular Google platform, plus Microsoft's platform. Is Swift suitable for writing applications for all? If not, developers would be writing for a limited, albeit popular platform, but limited to a certain subset nonetheless.

      They're releasing it as open-source later this year, with support for iOS, OS X, and Linux. Microsoft is working on a Swift compiler as well, so you will be able to write Windows programs with it at some point. The only platform that may get left out is Android.

    67. Re:One more in a crowded field by euroq · · Score: 1

      First of all, I'm a developer.

      So, I work for a company who wants the product on all platforms... we dev on all platforms, and we even outsourced a windows app (ha!). But anyways, it's true. It's way faster to iterate in Android than it is in iOS. So our features come out on Android first.

      I can hear everyone saying "get better iOS developers!" Well, maybe. But I don't think so. The devs are pretty much equally capable on both sides. Maybe Swift will change things, but the reality is is that Android development is faster than iOS development, and there's no internet chatter that will change the reality of what we're experiencing. Maybe Swift will change that, and if that's the case, cool. But right now, it's faster to iterate on Android hands down, and I believe (obviously an opinion here, however an educated opinion), the reason is Java is faster to develop in than Objective-C.

      --
      Just because the U.S. is a republic does not mean it is not a democracy. Democracy/republic are not mutually exclusive.
    68. Re:One more in a crowded field by Chalnoth · · Score: 1

      Eh. As near as I can tell, Swift is very similar to Go, except without the channels but with a more traditional generics system. I have yet to see anything particularly different about it except for a few slick string manipulation operations. But those really aren't of that much value.

    69. Re:One more in a crowded field by Anonymous Coward · · Score: 0

      > Looks like they are trying to create a Swift clone. Excuse me, but I think I prefer the real thing.

      So you use C# then? you know, given that Swift is basically just a C# clone.

      I mean sure, it has a few syntax differences, but most of the "new" ideas in Swift and their implementations are copied directly from C#.

    70. Re:One more in a crowded field by Xest · · Score: 1

      "Swift on the other hand has a lot of desirable features, that are not available elsewhere."

      I'm intrigued, can you post some examples?

    71. Re:One more in a crowded field by BasilBrush · · Score: 1

      Swift has optionals, improved error flow control constructs, values and structs as full UDTs, interactive experimentation with playgrounds, tuples, native fully unicode strings (not just UTF16), no implicit fall throughs on switches, optionally named parameters, associated values on enums, guard statement for preconditions, optimisation as a design goal of the language, functional programming methods.

      I don't know Go, but I bet it hasn't got all those.

    72. Re: One more in a crowded field by SpaghettiPattern · · Score: 3, Interesting

      ... and C is the only language more popular than Java...

      Nitpicking here. I started with C nearly 3 decades ago, I switched to Java but I'd be able to pick up C again in a very short time. Large parts of large/huge systems I design in C structures as they provide a nice abstraction of the underlying hardware. No matter how much I like C, it's no longer number 1 when considering the number of programmers involved. It's "too technical" for application programmers. Considering that financial programmers push the numbers and that they are moving from COBOL to Java, I see Java as the COBOL of the future. The upshot is that Java is good enough to do almost anything and much more elegant than COBOL.

      --

      I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
    73. Re: One more in a crowded field by fluffernutter · · Score: 1

      This is why, ultimately, people aren't making much money on apps in general. Because they think they can just depend on the Apple model to protect their investment, when Apple really only cares on making money for themselves.

      --
      Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
    74. Re: One more in a crowded field by Anonymous Coward · · Score: 0

      As a software company owner with apps deployed on all platforms I can say with objective certainty that you're full of shit.

      We make 3x more from Android than from iOS, and the customers are less finicky, whiny cunts too.

    75. Re:One more in a crowded field by DrXym · · Score: 1

      Most developers will pick Apple over Android. Then you have to rewrite the code for Android. Apple will get first release on a lot of apps, just what they prefer.

      Most developers will pick neither, if neither offers the functionality they need to deliver cross platform applications.

    76. Re:One more in a crowded field by K.+S.+Kyosuke · · Score: 1

      Go is a replacement of C for servers. So quite obviously some of the things aren't going to be there, since it's generally somewhat more conservative. More so as it's geared towards people writing their own language processing tools for heavy lifting in really large projects (admittedly, probably not something for the average phone app developer) which gets obviously easier if the language is simpler. That could make it a pretty good choice especially if you want to share code between a server and a client AND you're already settled on using it on the server side. Anyway, a laundry list of features ("half-features" for some of those you named to boot) is hardly an argument. If I want the ultimate rich ultra-flexible language, I already know where to find it.

      --
      Ezekiel 23:20
    77. Re: One more in a crowded field by DrXym · · Score: 1
      Cyanogenmod lets you control app permissions, e.g. to deny or be asked for access by apps that want to send an SMS, get location etc.

      Personally I think vanilla Android's upfront permissions model is a disaster though and it's not reasonable to expect people to install custom firmware to fix it. That said, Google do police their store, and can remote kill them, and they could (if they so wished) minimize harm by downranking apps that ask for too many permissions. Probably the biggest risk to users if they get their apps from a warez site where they are basically asking for trouble.

    78. Re: One more in a crowded field by LWATCDR · · Score: 1

      For now.
      But even that is changing. Now if we can just drop the stupid Freemium model and let me buy apps.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    79. Re:One more in a crowded field by LWATCDR · · Score: 1

      No libraries and worse no Windows version.
      Talk about a safe way to open source something. It will never be used. The Linux community often balks at c++! No library bindings so it is useless for application development. Now if you want to write bindings or write a replacement for ls you are all set.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    80. Re: One more in a crowded field by DrXym · · Score: 1

      It's still an important comparison. And most games are written over middleware for various reasons - Cross platform is just one of them, but others would include time to market, tools, learning curve, code quality etc. Even if iOS is the only target, it still makes sense to use middleware of some kind and Unity happens to be very popular middleware.

    81. Re: One more in a crowded field by iluvcapra · · Score: 1

      A LOT of Apple people use Ruby and Apple developed/supported an OSS build system for native Ruby apps only a few years ago.

      I think they finally went with something different because (1) the various Ruby byte code/compiler options have never been able to deliver, (2) they may have wanted something with a static type system and no GC by default, and (3) Lattner initiated Swift because he wanted to write it, and he wrote it as an exercise at maintaing Obj-C compatibility, and it was the right tool at the right time.

      --
      Don't blame me, I voted for Baltar.
    82. Re: One more in a crowded field by iluvcapra · · Score: 1

      Isn't it up to the library developers to publish bindings?

      --
      Don't blame me, I voted for Baltar.
    83. Re:One more in a crowded field by Anonymous Coward · · Score: 0

      agreed. I had to email myself the name of the project so I would not forget it.

    84. Re: One more in a crowded field by Anonymous Coward · · Score: 0

      The market share may be greater, but the number of people who actually use their phone, and generate revenue for app developers is much higher on iOS. Even for ad-funded apps, the revenue generated is much higher, because a greater proportion of iOS users actually use the apps, and hence see the ads.

    85. Re: One more in a crowded field by Anonymous Coward · · Score: 0

      Given that Apple alone is 48% of the entire US phone market, and most people are targeting at best the west, and at worst the US with their apps, yes, even a 1:2 ratio would be enough for this to matter. In reality, the ratio is more like $1:$4.

    86. Re: One more in a crowded field by master_kaos · · Score: 3, Insightful

      And I have the exact opposite experience. We have 8x the usage on iOS vs android, and android users complain a lot more (some legit, some just outrageous requests)

    87. Re: One more in a crowded field by Anonymous Coward · · Score: 0

      Except it's not. The reality is that actually at the moment, iOS is gaining market share, and revenue share from Android, not the reverse.

    88. Re: One more in a crowded field by the_B0fh · · Score: 3, Insightful

      That's why the top 10 flashlight apps in the Android App Store all need access to networking, your SMS, mailbox, contacts, etc. "creative ideas for monetization" indeed.

    89. Re: One more in a crowded field by the_B0fh · · Score: 2

      Gee. One registered user, and one anonymous coward, each with direct opposite experiences.

      Who can I believe, who can I believe...

    90. Re: One more in a crowded field by LWATCDR · · Score: 1

      Yes and no. If you only include a basic "standard" library you are pretty much going to make the language useless. If your "standard" library includes things like widgets then it is a lot more likely to be useful.
      Java had Swing which will not perfect worked as a cross platform gui.
      For Swift on linux the best bet would probably be QT bindings so you can have a cross platform SDK.
      Will QT make the effort to port to Swift?
      Who knows.
      Swift is not likely to flourish on systems besides IOS and OS/X who should do what really does not matter. Now if Apple had ported Cocca to the Linux and Windows you would have had something really interesting.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    91. Re: One more in a crowded field by the_B0fh · · Score: 1

      What about VMS, you damned insensitive clod!

    92. Re: One more in a crowded field by iluvcapra · · Score: 1

      Can you characterize exactly what you think makes iOS slower to iterate? I've been doing comparisons lately.

      --
      Don't blame me, I voted for Baltar.
    93. Re:One more in a crowded field by Anonymous Coward · · Score: 0

      from what i can see so far ZERO. it's only current use is for ios/osx which most of us still don't give a shit about.

      this is essentially a vapid piece probably prodded by apple or a fantard to advertise swift and it's nebulous values.

      time will tell, but frankly i'm of the opinion that it will utterly languish outside of the apple niche.

    94. Re: One more in a crowded field by Anonymous Coward · · Score: 0

      that's surprising that that still holds true given how locked down ios is. i fully expected that by now that the vast majority of ios users were the ignorant unwashed masses. i.e. it's very difficult to change default apps while on android it's trivially easy.

      i buy a fair number of apps that i install and use. usually paid to get rid of the ads, although on android i could cheat to a degree. the apps also tend to be technical in nature, helping me with projects, etc. although i have also purchased a fair number of games.

    95. Re:One more in a crowded field by BasilBrush · · Score: 1

      It wasn't intended to be an argument. It was the answer to a question. Yes of course comparing languages intended for two different domains is pointless, but that's what was asked.

      Lisp. Ha ha ha. If you think that's the answer, you don't know the question.

    96. Re: One more in a crowded field by BasilBrush · · Score: 1

      It's still cutting out all the developers that use the native APIs, and this is a useless comparison.

    97. Re:One more in a crowded field by Chalnoth · · Score: 1

      Go offers most of these, or has very similar functionality. Many are also in common with other languages.

      As for Go, the differences from what you listed above are:

      1. Go implements optional types using pointers (and, as with most languages, implements pointers in a much safer way than C).

      2. Go's error handling is just as explicit, but does require you explicitly return the error (Go natively supports multiple return values). I'm not sure whether this is good or bad.

      3. Go doesn't have tuples explicitly, but the ability to have multiple return values makes them less necessary. It's also possible to define structs inline (It's a little verbose, as you have to specify the type, but it's not too bad).

      4. Named parameters are one nice thing that Go lacks.

      5. Guard is just syntactical sugar around an if statement. It's nice, I guess, in that it helps to enforce better programming practices, but it's not anything particularly interesting.

      6. Swift isn't a particularly fast language, except perhaps compared with Objective-C, which has some truly horrible performance characteristics in places.

      They are different languages, with their own benefits and drawbacks, but I just don't see anything here that Swift offers that is all that special (and yes, Go has a playground as well).

      Go's big differentiator, for instance, is its support of channels. Channels offer a paradigm for multithreaded processing that is quite different from what other languages offer. Most languages, for example, make use of mutexes to keep concurrent processes safe. Go, on the other hand, implements multithreading as communication: if thread A writes to a channel, and thread B reads from it, thread B will wait until thread A has its value ready. This is the main feature that makes Go so useful for server applications.

      Some also appreciate the language's simplicity (the main design philosophy of Go was to make the base language as small as possible while supporting all of the main programming paradigms). One result of this decision is that generic programming can be extremely verbose (you can use interfaces to allow a function to accept anything that implements that interface, and there's a reflection API that lets you do different things with different types passed...it's rather clunky, but functional). Overall, this makes programming in the language rather weird.

      Pretty much the only thing that sets Swift apart is the fact that Apple is pushing the language. It does appear to be quite a bit better than Objective-C (which has some truly horrific functionality, such as no type safety for containers and runtime errors for invalid message calls). But I really doubt it will make all that much headway into projects which aren't targeting Apple products. It's good, but I doubt many teams will see a reason to switch.

    98. Re: One more in a crowded field by angel'o'sphere · · Score: 1

      That is nonsense.

      QT looks more or less completely native on all platforms where I ever have seen it.

      no idea why people repeat myth that not even where true for the very first Qt incarnations.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    99. Re:One more in a crowded field by K.+S.+Kyosuke · · Score: 1

      You started with a laundry list, I didn't. When it comes to that, CL is hard to beat. "Playgrounds"? What about reshaping the whole program on the heap while it's running, almost without limitations? Including persistent object databases if you have those (one might argue that without the ability to do that, transparently integrated object databases are quite difficult to pull off). You can implement any kind of workspaces or scratchpads or playgrounds (or what's the nom du jour for that ancient feature, dating back to Smalltalk-80, if I'm not mistaken) based on this solid foundation. But not the other way around. Many people don't need any of that, though. Certainly it's not the focus for the above mentioned server use of Go.

      --
      Ezekiel 23:20
    100. Re: One more in a crowded field by Wovel · · Score: 1

      Yeah but you just made that up and your just an Android user that has never worked for a development company of any kind...

    101. Re: One more in a crowded field by Wovel · · Score: 1

      I wish i had notice I was responding to an AC before I did. I will contemplate which to believe with you.

    102. Re:One more in a crowded field by slashdotwannabe · · Score: 1

      I don't know what you know that I don't in your attempt to speak for "most developers", but let me tell you how my consultancy will approach multi-platform apps: Xamarin. We won't develop a multi-platform app three times; we'll develop it once and then tweak for platform specifics.

      In this case, assuming that you are correct in calling Apple's strategy, the result will NOT be a first-release on iOS, and it will also NOT be the adoption of Swift. Even without a leveraging technology such as Xamarin, unless a company is so small as to not have the resources to develop all platform versions simultaneously, they would develop simultaneously, as the cost of the marketing program will often dwarf the development budget, and management will want to recoup the investment and drive the widest possible market share.

      The days of building a wall around your platform are coming to an end. It might take another 20 years, but it is inevitable IMO. At that point, the company that does cross-platform the most seamlessly will win the mindshare of developers and the market share of businesses that care about cross-platform, leaving those who insist on walling off their garden to play to those who do not care about cross-platform and niche markets -- something that Apple probably does not want to go back to.

      --
      This comment is my opinion and does not represent an official position of Donald Trump or others I do not work for
    103. Re: One more in a crowded field by macs4all · · Score: 1

      That's because Apple is all about money and buying and money and Apple sheeple do not understand Free Software.

      No, you have that backwards: Fandroids don't understand that writing software is an occupation that sometimes merits compensation.

    104. Re:One more in a crowded field by CauseBy · · Score: 1

      "Most developers will pick Apple over Android"

      Um....

    105. Re: One more in a crowded field by macs4all · · Score: 1

      This is why, ultimately, people aren't making much money on apps in general. Because they think they can just depend on the Apple model to protect their investment, when Apple really only cares on making money for themselves.

      That's why they've made Developers 30 Billion (that's with a "B") Dollars on App Store Apps, and FREELY hosted FREE Apps, too.

      Now, let's contrast that with the Google Play Store...

    106. Re: One more in a crowded field by macs4all · · Score: 1

      Gee. One registered user, and one anonymous coward, each with direct opposite experiences.

      Who can I believe, who can I believe...

      Exactly.

    107. Re: One more in a crowded field by macs4all · · Score: 1

      Probably because almost every app on android wants control of your phone and access to your data. I know since switching to Android I only buy apps from trusted sources, that don't ask for every permission under the sun.

      So, the real question is: Why did you switch (assuming you switched from Apple)? If so, by your own admission, you just switched from an App Store where, with very few exceptions, everything is exactly what it says it is, to Android, where almost nothing is what it says it is.

      Good job, good job...

    108. Re:One more in a crowded field by BasilBrush · · Score: 1

      1) Pointers are not optionals. The whole point of optionals is they say which values can be null and which can't. For all types, including pointers.

      2) Manual error code handling is available in any language and costs developer time, increases code size, and causes bugs. Swift 2 makes it clear which methods can fail with errors, both when defining and when calling a method, and then handles the error in a similar way to exceptions.

      5) Guard is really simple, but it covers a particular bailing out if that programmers are doing all the time. It makes it explicit that this if is a precondition. And the fact that it always bails out of the current scope is guaranteed. It's going to get adopted by other languages for sure.

      I won't argue that Go is also and interesting language. If I was coding for servers I'd certainly be looking at that. But for apps and system software Swift is looking very good to me. But yes, more for Apple use rather than other platforms.

    109. Re: One more in a crowded field by macs4all · · Score: 1

      Probably the biggest risk to users if they get their apps from a warez site where they are basically asking for trouble.

      And yet, if you ask in these pages, all you get is praise that that so-called "freedom".

      Look I'm all for "Freedom" when it matters, like in Free Speech, and Right To Arm Bears; but in the case of Mobile Apps, the substantial risks just don't seem to justify the necessary added vigilance, for the .000005% of additional Apps, period.

    110. Re:One more in a crowded field by BasilBrush · · Score: 1

      What about reshaping the whole program on the heap while it's running, almost without limitations?

      Sounds awful.

      Look Lisp does not answer ANY of the problems Swift addresses. It's irrelevant.

      It's also a tiny niche language even after 30 odd years. Swift is already far more popular after only a year.

    111. Re: One more in a crowded field by Anonymous Coward · · Score: 0

      Honestly: it makes no sense at all to rewrite GUI code.

      ... said the guy who sold applications that looked equally shitty and disappointed users equally on all platforms it ran on.

    112. Re: One more in a crowded field by macs4all · · Score: 1

      Installed base is what most people would go by.

      Yeah, but "Installed base" also tends to count phones that are sitting in the trash, or in a desk drawer, etc.

      And I assure you, there are a lot more Android phones that have gone by the wayside than Apple phones.

    113. Re:One more in a crowded field by Cammi · · Score: 0

      Not according to it's website. All it has is a code editor/debugger. No IDE. That copy and paste + fantasy is pretty impressive, however.

    114. Re: One more in a crowded field by shutdown+-p+now · · Score: 2

      This is more or less true for desktop platforms. But for mobile, the design you're expected to adhere to on different platform is sufficiently different (and not just in the way buttons look, but general layout and flow) that an app like that really sticks out like a sore thumb.

    115. Re:One more in a crowded field by shutdown+-p+now · · Score: 1

      It is the supreme irony of our times that the best tool to write a portable mobile application is .NET (well, Mono, but ...).

    116. Re:One more in a crowded field by shutdown+-p+now · · Score: 1

      So, basically, mostly like C#, but with reference counting instead of GC.

      The library issue is going to be the main sticking point, though.

    117. Re: One more in a crowded field by DrXym · · Score: 1

      And yet, if you ask in these pages, all you get is praise that that so-called "freedom".

      Yes because freedom is a good thing. I'm sure if I was locked up in a walled compound all day that my chances of being hit by a bus would be greatly diminished. It does not mean that I should be denied to leave my compound if I so wish, even if it's generally a nice place.

      There are lots of extremely good reasons someone may wish to install an APK which is not listed on Google's store - enterprise or in-house apps, rival stores such as Amazon's, vertical applications, open source apps, apps that violate Google store policies for whatever reason (emulators. etc.) and so on.

      If someone is stupid enough to frequent a warez site to avoid paying a few euros for a game then they get what they deserve. Should we take away everyone else's freedom for that?

    118. Re: One more in a crowded field by DrXym · · Score: 1

      It's not a useless comparison because most games wouldn't use native APIs for the reasons I said. Writing code against raw OpenGL ES is a horribly, horribly painful experience. Maybe a few learners or indies might hit the raw APIs (I've done it myself), but it's not for the faint hearted and it's a problem already solved by various open and closed solutions. Go through the top free / paid game list on the Apple / Android store and there are very few exclusive to one platform because they are all written with middleware of one kind or another.

    119. Re: One more in a crowded field by macs4all · · Score: 1

      And yet, if you ask in these pages, all you get is praise that that so-called "freedom".

      Yes because freedom is a good thing. I'm sure if I was locked up in a walled compound all day that my chances of being hit by a bus would be greatly diminished. It does not mean that I should be denied to leave my compound if I so wish, even if it's generally a nice place.

      Despite the old FOSS adage the "software wants to be free", it isn't really the same as with humans or animals. So, that's simply a non-sequitur. Next!

      There are lots of extremely good reasons someone may wish to install an APK which is not listed on Google's store - enterprise or in-house apps,

      Apple's distribution model allows for distribution to up to 100 devices, and Apple has programs to allow bigger organizations to distribute in-house apps to more devices than that, without involving the App Store or it's Approval Process. Next!

      rival stores such as Amazon's, vertical applications, open source apps, apps that violate Google store policies for whatever reason (emulators. etc.) and so on.

      IOW, that .0000005% of apps I was talking about...

      I'm not sure what you mean by Vertical Applications; there are a ZILLION Vertical Apps in the App Store. As far as Open Source Apps, I don't think Apple has any restrictions on you offering the Source to your App through another website. They are only interested in assuring that the Apps in the App Store are SAFE. Next!

      If someone is stupid enough to frequent a warez site to avoid paying a few euros for a game then they get what they deserve. Should we take away everyone else's freedom for that?

      In this case, I answer with a qualified "Yeah, it seems so."

      Beyond the "Good Idea" reasons, I think that Apple (wisely, as shown by the rampant malware that is Android Apps, even some of those in Google Play), figured that the whole market would fall on its face, and Apple would be reviled, if the iPhone and the App Store became nothing more than a corporate distributor of malware.

      Think about it. Yes, the Police are a pain in the ass when you just wanted to get to work in time; but they're sure handy when someone robs your house...

    120. Re: One more in a crowded field by savuporo · · Score: 1

      Unity stats counts active working devices out there. They cannot count phones in trash bin or desk drawer.

      --
      http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
    121. Re:One more in a crowded field by iluvcapra · · Score: 1

      Guard is just syntactical sugar around an if statement. It's nice, I guess, in that it helps to enforce better programming practices, but it's not anything particularly interesting.

      Well... the main difference between a `guard` and an `if` is the former can bind names in the enclosing scope, and crucially, fail upon failure to bind, which is a thing in Swift. This is a somewhat peculiar behavior. It's meant to eliminate the standard Cocoa/Foundation habit of putting a bunch of parameter assertions as the beginning of the function and to handle these in a regular way that the compiler can make assumptions about. "Not particularly interesting" stuff has a way of being boring to the programmer but is conversely fascinating to the compiler.

      Go, on the other hand, implements multithreading as communication: if thread A writes to a channel, and thread B reads from it, thread B will wait until thread A has its value ready. This is the main feature that makes Go so useful for server applications.

      If you know Erlang, Go is Not Particularly Interesting. "Pretty much the only thing" that sets it apart is Google is pushing the language.

      --
      Don't blame me, I voted for Baltar.
    122. Re:One more in a crowded field by BasilBrush · · Score: 1

      No. C#Âis a Java like language. ANd it doesn't fulfill any of the requirements that defined Swift.

    123. Re:One more in a crowded field by shutdown+-p+now · · Score: 1

      C# may be a "Java like language", but so is Swift (and virtually any other modern language that happens to use C'ish syntax and is statically typed). Given the specific list of language features that you gave earlier, C# has most of those, in many cases with quite similar syntax to boot. You could bring up the fact that it's a VM language, to which my answer would be .NET Native. In terms of low-level constructs, C# also has e.g. raw pointers, unions and stack allocated memory.

      So the only major difference that I can see is the memory model - tracing GC vs reference counting. Everything else is relatively minor.

    124. Re:One more in a crowded field by BasilBrush · · Score: 1

      As I said it doesn't satisfy ANY of the requirements.

      The requirements are that it is able to call the Cocoa API, and that it is fast enough for systems programming - the latter being largely done by being designed from scratch to be highly optimisable.

      And there's little resemblance to Java, beyond the certain commonality that all modern language syntax has. Take a chunk of code in the two languages and they look very different.

      The whole apple-didn't-need-to-write-a-new-language argument is just ill-informed.

    125. Re:One more in a crowded field by shutdown+-p+now · · Score: 1

      The requirements are that it is able to call the Cocoa API

      Those are the requirements that only matter for people who code against the Cocoa API (i.e. those who develop for Apple platforms). This thread is about cross-platform use of Swift, i.e. on Linux and/or Windows, where this is not any kind of inherent advantage for the lack of Cocoa (and even if it were there, it would have to compete against the corresponding standard libraries of other language/framework combos).

      and that it is fast enough for systems programming - the latter being largely done by being designed from scratch to be highly optimisable

      There's nothing specific about Swift that makes it "highly optimizable", unless you compare it to Obj-C (which, again, is not the subject of this thread). An AOT C# compiler, like .NET Native or Xamarin, can optimize just as well, with the only real difference being GC vs refcounting (which can go either way depending on your allocation patterns).

      And there's little resemblance to Java, beyond the certain commonality that all modern language syntax has.

      Not all modern language syntax. All modern C-like language syntax. And if you're making this argument, then it applies equally to C#. I'll grant you that C# is slightly closer to Java, because it started its life as basically a Java clone with Delphi-like keywords, but that was 15 years ago. Things have changed a lot since then. Today, idiomatic C# is replete with lambdas and sequence comprehensions, for example, something that is very rarely seen in Java even though they finally have that feature now.

      The whole apple-didn't-need-to-write-a-new-language argument is just ill-informed.

      I'm not making that point. Indeed, I have always said that Apple is in a desperate need of a new, modern language to replace the horribly aged Obj-C - for its ecosystem. The question is, what, if anything, Swift has to offer outside of that ecosystem, that is not already offered by something else that is just as, or more, popular.

      And the answer to that question is: a few minor features, but nothing particularly interesting or groundbreaking. Which shouldn't be a surprise, because Swift is clearly an amalgamation of successful features that have been seen in other popular OOP languages with C-style syntax in the past decade or so. There's nothing wrong with it: it's a perfectly rational and pragmatic approach to the problem, and I commend Apple for going that route instead of reinventing the wheel. It makes it that much easier to master the language, coming from another mainstream platform.

      But please don't make the impression that there's some considerable innovation going on here. Obj-C developers are easily impressed, but the rest of us have seen all this stuff before.

    126. Re: One more in a crowded field by Anonymous Coward · · Score: 0

      Anonymous anecdotal evidence Vs Psuedonymous anecdotal evidence...unless you're already biased one way does one really have any more credibility than the other?

    127. Re: One more in a crowded field by exomondo · · Score: 1

      No, you have that backwards: Fandroids don't understand that writing software is an occupation that sometimes merits compensation.

      I wouldn't say that is all (or even the majority) of Android users but somewhat along your line of thinking if Free Software is so innovative and is also free of charge (by virtue of having no restrictions on distribution) and free of advertising (since it is free software one can just remove the advertising) then why is it not more popular and better?

      Given the FOSS mantra I would have thought Android would be the perfect opportunity for Free Software to really shine and out-innovate the proprietary competition. The FOSS ideology has certainly been given every opportunity and advantage yet even with the encumbrances of payment and/or advertising we still see proprietary applications winning out.

    128. Re: One more in a crowded field by exomondo · · Score: 1

      Yes because freedom is a good thing.

      And you have it, you're free to use Android if you wish.

      I'm sure if I was locked up in a walled compound all day that my chances of being hit by a bus would be greatly diminished. It does not mean that I should be denied to leave my compound if I so wish, even if it's generally a nice place.

      You're not locked up, it's a smartphone operating system not fucking North Korea. But to entertain your analogy if you want to go on a holiday to your secure compound, free to return home whenever you wish then by all means do that. And if you prefer to make that secure compound your home and instead holiday in the less secure environment you can do that too.

      Should we take away everyone else's freedom for that?

      That's an overly dramatic and incorrect assertion, nobody is taking away anything.

    129. Re: One more in a crowded field by exomondo · · Score: 1

      Not really, because iOS has native 3D APIs.

      All the major platforms have native 3D APIs, but - like iOS's - these are just drawing APIs. There's a lot more to game engines (Unity, UE and the like) than just drawing. OpenGL, Metal, Direct3D are not comparable to Unity, UE, etc...

    130. Re: One more in a crowded field by Anonymous Coward · · Score: 0

      Not really, because iOS has native 3D APIs.

      It isnt a "3D API", it is just an API for accessing the GPU for drawing to the screen and Unity, being a game engine, uses those APIs just like it uses the native graphics APIs on Android or on Windows or on PS4 or whatever. Very strange that you try to dismiss the usage of Unity on the basis of the existence of a graphics API (which every platform has). Nobody is looking at any platform's graphics API as an alternative to a game engine.

      You do understand that every common personal computing platform has a graphics API dont you?

    131. Re:One more in a crowded field by BasilBrush · · Score: 1

      There's nothing specific about Swift that makes it "highly optimizable"

      I'm afraid Chris Lattner knows better than you do. Every feature was designed with an eye to optimisation. Take for example the, shall we say novel, array behaviour that everyone was complaining about last year. The reason was they were designed to be highly optimisable. Well array behaviour has become more as one would expect now, but that original behaviour is an insight into the design for optimisation process.

      I agree with you that it's mainly of interest to Apple developers. But you underestimate it when you imagine that there's not much new in there. Apple have not simply copied features from other languages. The developer of LLVM has taken the opportunity to write a language that's engineered to to compile to fast code, and to minimise common sources of bugs and security issues. And he and his team have considered these from first principles, not just copied.

      It may be no more popular outside Apple platforms than Mono is. But who cares?

    132. Re: One more in a crowded field by DrXym · · Score: 1

      Despite the old FOSS adage the "software wants to be free", it isn't really the same as with humans or animals. So, that's simply a non-sequitur. Next!

      It is not a non sequitur because it is self evident from the people who jail break their phones, install firmware and all the rest.

      Apple's distribution model allows for distribution to up to 100 devices, and Apple has programs to allow bigger organizations to distribute in-house apps to more devices than that, without involving the App Store or it's Approval Process. Next!

      Ooh 100 devices. Wow that's a huge enterprise! And even if it were IOW, that .0000005% of apps I was talking about...

      No. Amazon's store is very popular as are many other app stores / downloaders. e.g. Humble Bundle sells games for android and distributes them through its own software.

      I'm not sure what you mean by Vertical Applications; there are a ZILLION Vertical Apps in the App Store.

      Maybe you look up what a vertical application is then. They are very specialised applications, may cost a lot of money to make, may cost a lot of money to buy, might have specialised revenue streams which don't work within the rules of the app store and the vendor (and customers) might strongly resent Apple / Google stealing a 30% cut of everything.

      As far as Open Source Apps, I don't think Apple has any restrictions on you offering the Source to your App through another website. They are only interested in assuring that the Apps in the App Store are SAFE. Next!

      Don't be ridiculous. Lots of open source apps are prevented from listing on Apple's stores. Anything related to shells, scripting, su, compilation, proxies / filters, emulation, file transfer stands little chance. Even Google has some limitations and would probably respond to takedown notices whether fair or no. But that isn't a worry since there are stores such as F-droid where open source apps are available from. Frankly your excuses are pathetic. The reality is that being able to install APKs from external sources is a strong benefit of android and many people legitimately use it. Freedom doesn't mean common sense, but it not should be taken away because some people lack common sense.

    133. Re: One more in a crowded field by DrXym · · Score: 1

      Ooh 100 devices. Wow that's a huge enterprise! And even if it were IOW, that .0000005% of apps I was talking about...

      /. mangled my response at a greater than symbol, so again...

      Ooh 100 devices. Wow that's a huge enterprise! And even if it were greater than 100, it's still a huge intrusion and hassle. My own company writes a safety checklist app for industrial plants and factories. The amount of extra bullshit required to make that app (which is written in cordova) work on Apple thanks to provisioning, submission, approval + dedicated development hardware is a significant waste of time and money.

    134. Re:One more in a crowded field by jbolden · · Score: 1

      How's Swift's cross-platform suitability?

      Bad likely to advance to mediocre. GNUStep is working on supporting Swift binding (http://heronsperch.blogspot.com/2015/06/swift-20-going-open-source-great-news.html) Once that works Swift code will run via. GNUStep in other environments. Which means that Swift code could be ported without a rewrite but it still won't feel native to other platforms.

      That being said lots of non-cross platform languages are popular. Look at the .NET family.

    135. Re: One more in a crowded field by jbolden · · Score: 1

      That is simply not true that no one is making money. Apple has crossed the $25BN Now Paid To iOS Devs. And an even bigger market exists for apps to support websites and vertical applications. The people not making money are app developers who write fairly generic applications and thus have lots of competition and then don't make them meaningfully better than the competition. There is a flood of generic apps and the value there is 0.

    136. Re: One more in a crowded field by jbolden · · Score: 1

      The problem is the average spend difference is much greater than 2::1. If you are counting all Android i.e. 3rd world Android and verticals it wouldn't shock me if the difference is spend is closer to 50::1. If you limit this just to the top billion (i.e. richest billion phone users) Android is 60/40 with iOS probably selling 2::1 not counting vertical applications. Count vertical apps and you are around 5::1. The remaining 3 billion or so buy far less than the 600m Android users in the top billion and so add little.

    137. Re: One more in a crowded field by jbolden · · Score: 1

      FOSS is shinning on mobile. Virtually every cloud that is being used to support those apps is 95% FOSS or more. Many of the frameworks are FOSS. The mobile operating systems themselves are about 80% FOSS.

      Non technical end user tweaking is an area where FOSS still gets its butt kicked.

    138. Re: One more in a crowded field by jbolden · · Score: 1

      iOS apps don't have unneeded access and need to function well if semi-needed access is denied. It is a vastly more secure ecosystem.

    139. Re: One more in a crowded field by jbolden · · Score: 1

      For enterprise Apple sells (well below cost) the server components for iOS. Companies can setup their own applications stores and distribute applications through those with no 30% going to Apple. The 100 limit the GP mentioned applies to individual devices. If the devices register as belonging to X company X company can distribute applications through their infrastructure to all of them. Apple governs their app store. They make it easy to setup up alternatives.

    140. Re:One more in a crowded field by Chalnoth · · Score: 1

      1) There's really not much difference between optionals and Go's pointers. Variables in Go cannot be uninitialized. They have to contain a valid value, and the default value is the "zero" for the type. But a pointer can point to nil (which is the zero value for pointers). Curiously, Go also allows chaining of nil pointers, but the function specifies the behavior if the container is nil. The two implementations seem to be almost identical.

      2) It depends. There's an argument to be had either way, and I don't really know what the right answer is. But the multiple return values make manual error handling in Go far less cumbersome than it is in C or C++. That said, if exceptions are your thing, Java is very good with those, and also shares nearly all of Swift's functionality.

      5) I doubt it. It's something that can be handled by libraries just as easily, such as with the Preconditions class in Guava.

    141. Re:One more in a crowded field by Chalnoth · · Score: 1

      Erlang is a really different language. Almost purely functional, and with no object types (though some claim that its process-oriented system is effectively object-oriented). The two are similar in message passing, but there are a lot of differences. In particular, Erlang really isn't a c-family language at all, while Go is (along with Java, Swift, C#, and others).

    142. Re: One more in a crowded field by gmiller123456 · · Score: 1

      The 100 app limit is for developers not enrolled in the enterprise program. The only limit for enterprise apps is the you all have to work for the same company. Better, but still total BS.

    143. Re: One more in a crowded field by the_B0fh · · Score: 1

      You mean, someone I may contact to obtain more evidence to verify their claims, versus someone I cannot contact?

      Let me think about it for a moment.

    144. Re: One more in a crowded field by Anonymous Coward · · Score: 0

      You didn't read your second, did you?

    145. Re:One more in a crowded field by BasilBrush · · Score: 1

      1) That's only one of the options then. Where's the pointer that cannot contain nil?

      Also take an integer type. Does go differentiate between 0 and nil? If not it's not got any equivalent of optionals.

      2) I don't know Java well, it's about 20 years since I did some as a student. But Swift marks the definition of any method that can return an error with the keyword "throws". Likewise when calling a method that can throw an error, you have to prefix the call with the keyword "try". They make methods that can fail obvious from both sides of the contract. It means that the programmers is always alerted to a potential error situation. I believe this is a significant improvement on Java exceptions.

      5) Sure, preconditions are not a new idea. I first came across them in Eiffel, again 20 years ago. But most popular languages don't support them, except by utilising more general if statement or asserts. For Swift, guard ties in with optionals to automatically provide the guaranteed-not-to-be-nil pointer or value after the guard statement has rejected nil values. The programmer doesn't need to remember that they've excluded nils at the beginning of the method, the language has it modelled explicitly.

    146. Re: One more in a crowded field by exomondo · · Score: 1

      I meant more the ideology - as in the 4 freedoms - FOSS bits are certainly being used to create a lot of non-free systems and services.

    147. Re: One more in a crowded field by euroq · · Score: 1

      My observations:

      1. Overall, UI+Navigation takes longer. There's more manual lifting to write non-standard page elements. Writing margins and locations directly in code instead of by layout managers, etc.
      2. Crashes are harder to track down. This is probably true for ANY environment that's C-based.

      Swift will probably close the gap, especially for #2.

      --
      Just because the U.S. is a republic does not mean it is not a democracy. Democracy/republic are not mutually exclusive.
    148. Re: One more in a crowded field by euroq · · Score: 1

      Oh I forgot the main point: garbage collected vs. non-garbage collected environments/languages tend to always have faster development times.

      --
      Just because the U.S. is a republic does not mean it is not a democracy. Democracy/republic are not mutually exclusive.
    149. Re:One more in a crowded field by Chalnoth · · Score: 1

      Yes. A pointer to int can be nil, and that is different from an integer holding a value of zero.

      "Throws" declarations are available in Java, and can be compiler-enforced. They have two classes of exceptions: checked and unchecked exceptions. Unchecked exceptions (runtime exceptions) are expected to be for unrecoverable errors. They can be caught, but usually aren't (note: there is some disagreement among Java developers about whether or not to use uncaught exceptions). Exceptions that are expected to be thrown during normal operation must be caught or you get a compile error (may be disabled with some compiler options, but I'm not certain....my company always leaves that check enabled). Whether or not an exception must be part of a throws statement and/or caught is determined by the Exception's type.

    150. Re:One more in a crowded field by BasilBrush · · Score: 1

      Yes. A pointer to int can be nil, and that is different from an integer holding a value of zero.

      No, that's not at all what I asked. That's the same as C. Take a look at optionals in Swift. It's very clear from your lack of understanding of my questions that they offer something very useful that you haven't come across before.

      "Throws" declarations are available in Java, and can be compiler-enforced.

      OK, that's the declaration side. But there's no equivalent of the "try" keyword required before calling a method with can throw. The necessity for that keyword shows clearly what blocks of code you need to enclose in a catch, and which you do not.

    151. Re:One more in a crowded field by Chalnoth · · Score: 1

      A pointer unable to contain nil doesn't make any sense. That would be like an integer unable to contain zero. If you want something that must be assigned a value, then let it be a value parameter and be done with it. The only real difference here is that Swift uses value assignment for optionals.

      It sounds like what you're trying to describe is Swift's concept of immutable pointers, which cannot be nil unless initialized to nil. This concept is unnecessary in a language like Go which doesn't directly interoperate with C.

      Come to think of it, that may be the one thing that does make Swift stand out: it can interoperate with C, C++, and Objective-C. That feature is kinda neat, I suppose, but is also a liability. It does mean people can avoid using SWIG, but also runs the risk of making for very ugly codebases where multiple languages are used together.

    152. Re:One more in a crowded field by BasilBrush · · Score: 1

      <quote>A pointer unable to contain nil doesn't make any sense.</quote>

      NO.  You really need to look at optionals. They are one of the best new features of Swift.

      I can even show you how a pointer that is guaranteed not to be nil can be done in another language.

      if (foo==nil) {
          return;
      }
      bar = foo;

      In this scenario, bar is a pointer that is guaranteed not to be nil. From that point on you can do whatever you like with bar and you never again need to check it for nil. You are in no risk of dereferencing nil. Well Swift gives that within the language. Such that I could pass bar around to other methods, and they will always know that that value is not nil.

      It's even more useful in formal APIs. In other languages, the documentation says whether a parameter or a result can be nil or not. In Swift, the code says that.

      <quote>That would be like an integer unable to contain zero.</quote>

      No, no, no. Zero is a value. Nil is the lack of a value. You're confused because most languages implement nil as a pointer with zero in it. But there is no connection between zero and nil.

      <quote>but also runs the risk of making for very ugly codebases where multiple languages are used together.</quote>

      Swift and C/Obj-C don't ever exist in the same files.  Though they may exist in the same project, and call each other. So there's no ugliness. And having multiple languages plus various other types of source file are the norm for significant projects.

    153. Re:One more in a crowded field by tigersha · · Score: 1

      Give Oracle a break.

      When Java was run as a totally open source thing by Sun it did not generate enough revenue and Sun, well, died. Went bankrupt. sold all their assets. Fired all their staff. Companies still need revenue and Sun's model did not work.

      I am sure Oracle is not going to keep running Java the same way after that happened.

      --
      The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
    154. Re: One more in a crowded field by jbolden · · Score: 1

      Then under that interpretation mobile has proven what is mostly true elsewhere. Guys who run servers like the 4 freedoms and take advantage of them, developers take advantage of them while end user applications mostly consist of a mixture of unfree code with free under layers. Which means that the 4 freedoms are valuable freedoms for computer professionals and mostly worthless for everyone else.

    155. Re:One more in a crowded field by Chalnoth · · Score: 1

      Except other languages do have the ability to ensure that a value exists. These are generally called values or references. Java is an exception here, as all object variables are references, and references in Java can contain null (even there there are annotations and static analysis that makes these safe, if a bit less convenient). But in C, C++, Go, and most other languages, value types or references cannot contain null/nil.*

      As near as I can tell, however, the only pointers available in Swift are UnsafePointer and variants thereof. These seem to be simple wrappers around C-style pointers, and can always contain nil. The base Swift language doesn't appear to have any pointer types at all (with optionals taking the place of pointers in the language).

      And yes, nil is the zero value for a pointer. A pointer's value is the location of another value, with nil indicating that it points to no value. You seem to be confusing pointers with the values they point to.

      * Provided the reference is initialized from a value type in C++. Pointers in C++ carry their lack of safety forward regardless. And when interoperating with C/C++/Objective-C, Swift won't really protect you any better.

    156. Re:One more in a crowded field by BasilBrush · · Score: 1

      Your lack of understanding of what optionals are is now just getting boring. No, they aren't the equivalent of pointers and references. Go read up on Swift optionals.

      I've been a professional programmer for 25 years, and learned what a fucking pointer was years before that. It's not me confused about pointers it's you confused about the concept of nil and what optionals are.

      Nil is the concept of no value. It happens to be implemented for the pointer type in C like languages as a zero, but that's an implementation detail, not what a nil is. This is why in pretty much every language you use the keyword or value "nil" or "NULL" rather than the literal value 0 when using them.

      Optionals is all about having a better implementation of the concept of nil. Any VALUE can have the ability to be nil. Not just pointers. And by not using an optional, you represent the fact that the value can't be nil.

      If you don't see that this is a step forward, then that's your lack of understanding, not a lack of progress by Swift. Sorry, but that's the way it is.

      And when interoperating with C/C++/Objective-C, Swift won't really protect you any better.

      Wrong. The Obj-C language has been updated to markup APIs for which nil is a legal argument or result. And all of the Apple Obj-C APIs have been marked up as appropriate. Swift understands this and so you get/pass optionals when appropriate. So you get all the benefits of optionals when calling Obj-C libraries.

    157. Re: One more in a crowded field by exomondo · · Score: 1

      Yep I would agree with that. I saw mobile as an opportunity to really create that free software ideal that RMS has been pontificating about for the past 30 years where it is the end user that gets those 4 freedoms. Ultimately FOSS has succeeded more in Torvalds' interpretation where the freedom is more on the developer side where so long as they contribute code back they can lock down the user product - ala Tivoization - as much as they want. The latter has been immensely successful where the former has failed pretty much everywhere.

    158. Re: One more in a crowded field by jbolden · · Score: 1

      True for consumer. But I think server is a counter example. In RMS's world end users are consumers of some technology and producers of others. They are technologically interested. My getting a sink diagram does nothing for me since I still would rather just pay a plumber.

      So for example RMS AFAIK has never once written about all the exciting stuff going on with open source networking in the last decade+. But it is a wonderful example of where his vision has been achieved. At this point the standard has become that networking technologies are implemented and start maturing in the open source community as open code running on open operating systems supporting mostly open source applications. And only after are those components reimplemented in semi-closed, semi-hardware (RMS has never been as concerned about software implemented in hardware because it isn't IP in the same way) solutions for ultra high performance.

      So anyway. I think we agree on the fact. But I think RMS achieved far more success than he originally intended for the community he was interested in. Free Software dominates the technical community and the software they use and manage. Consumers don't care about the 4 freedoms and there ...

      What's going to be the interesting battle over the next 20 years is the Internet of Things. How open is the software running on all sorts of devices that don't have traditional computer interfaces? So far the tendency is towards more openness than has previously existed as Free Software / Open Source is becoming the standard for devices.

    159. Re: One more in a crowded field by exomondo · · Score: 1

      Consumers don't care about the 4 freedoms and there ...

      I pretty much agree with what you're saying but I think with regard to RMS' vision this is the part that won't be achieved, he thinks they should care about the 4 freedoms and that they should not use SaaS or other "cloud services" and that they should insist on running only free programs on their computers.

      I agree his work has been hugely successful, just not in the way he originally intended it to be. I also think that's a good thing.

    160. Re:One more in a crowded field by Chalnoth · · Score: 1

      From the way you're talking about optionals, it sounds to me like you've been programming in Objective-C for a long time, and haven't looked very much at other languages any time recently.

      Aside from invoking undefined behavior, in C++ a function with any signature below can never be passed an unallocated object:

      void my_function(MyClass a);
      void my_function(MyClass& a);
      void my_function(const MyClass& a);

      In Go, a function with this signature cannot ever be passed an unallocated object:

      func myFunc(a MyStruct) {
      ...
      }

      The only danger here comes when you try to dereference a pointer to get the value which is passed to one of these functions: you have to check that pointer for nil/null first. But Swift has the same issue: you have to check an optional for nil before assigning an optional to a value.

      You also seem to be confused by my calling "nil" "the zero value for a pointer". For Go, this does not mean a literal zero ("nil" is a special value in Go, not an integer like NULL in C). The "zero value" in Go is the default value of any variable. If you create an object of pointer type and don't assign it anything, it will be set to "nil". For a string, the zero value is the empty string. For a struct, the zero value has all members of the struct set to their zero values.

      I think the reason you think these are so special is because in Objective-C and Swift, whether an object is passed by value or reference depends upon the type of the object. In C++ or Go, you always pass by value, pointer, or reference explicitly (though there are no references in Go). This is the only real difference between Swift optionals and Go pointers: in Swift, whether or not a function can modify the passed parameter depends upon the parameter's type. In Go, it's determined by whether or not the variable is a pointer.

    161. Re:One more in a crowded field by BasilBrush · · Score: 1

      As I said, I was bored with your lack of understanding of what optionals are last time.

      But Swift has the same issue: you have to check an optional for nil before assigning an optional to a value.

      Again, false.

      I was programming professionally in C++ for years before I did any Obj-C. This is not my misunderstanding. It's that you don't understand what optionals are.

    162. Re:One more in a crowded field by Chalnoth · · Score: 1

      Then why do you keep claiming that the optional system of Swift allows a user to be certain that a value exists, and that this is somehow special?

      And optionals don't have to be checked for nil when extracting their value? In what universe? While the language does allow a forced conversion without a check, that just means that the developer is dropping optional safety on the floor (this is perfectly reasonable in some cases). This is no different from many other languages. There's just a slight difference in syntax.

    163. Re:One more in a crowded field by BasilBrush · · Score: 1

      And optionals don't have to be checked for nil when extracting their value? In what universe? While the language does allow a forced conversion without a check, that just means that the developer is dropping optional safety on the floor (this is perfectly reasonable in some cases).

      So you ask in what universe, then you confirm that indeed you can.

      This is no different from many other languages. There's just a slight difference in syntax.

      Still wrong. Whilst you've clearly now read enough no to confirm what I said in the last post, you still don't understand how optionals are different from pointers and references.

      Optionals are actual values which can be nil. Not pointers to values. Not references to values. Values. This doesn't exist in the languages you think it does. When you think it does, that's because you're not understanding what optionals are.

      I don't know how many more ways there are to say this. Don't just skim the syntax, read the chapter.

    164. Re:One more in a crowded field by Chalnoth · · Score: 1

      Attaching the word "pointer" vs. "optional" doesn't change the behavior one iota. There are only two differences in terms of the programming interface between Swift's optionals and Go's pointers:

      1. Syntax. But all of the same operations are permitted.
      2. How they are passed to functions (by reference or by value).

      I challenge you to find a code snippet using optionals in Swift that does not trivially translate to a similar number of lines in Go with all of the same guarantees, aside from whether or not a function can mutate the passed variable (because that is orthogonal to whether or not the object is optional, and a different issue entirely).

      In languages like C and C++, of course, there are other differences (e.g. pointers are numbers that point to actual memory addresses, and the value is not guaranteed to exist at the destination). This is not anything new. It's just a slightly different syntax (and similar to boost::optional in C++).

    165. Re:One more in a crowded field by BasilBrush · · Score: 1

      Attaching the word "pointer" vs. "optional" doesn't change the behavior one iota.

      An optional is not a pointer. (Nor is it a reference). And that's not simply a matter of names. They are completely different things. Suppose you had an array of 4 optional integers, how do you imagine that is represented in memory?

      I challenge you to find a code snippet using optionals in Swift that does not trivially translate to a similar number of lines in Go

      Turing machines are equivalent. That doesn't mean language features are the same. They're not. You might solve a given problem in a similar number of lines in lisp, basic, forth and scheme. It doesn't mean the language features that you would use are the same.

    166. Re:One more in a crowded field by Chalnoth · · Score: 1

      An optional is not a pointer. (Nor is it a reference). And that's not simply a matter of names. They are completely different things. Suppose you had an array of 4 optional integers, how do you imagine that is represented in memory?

      The memory representation is largely irrelevant to the coding algorithms. It might be important if you're going to do some low-level optimization, but if you're doing low-level optimization where that sort of thing matters, you shouldn't be working in Go, Swift, or Objective-C.

      Turing machines are equivalent. That doesn't mean language features are the same. They're not. You might solve a given problem in a similar number of lines in lisp, basic, forth and scheme. It doesn't mean the language features that you would use are the same.

      That's why I specified, "similar number of lines and with the same guarantees." The benefits of optional are entirely about the sorts of things that the compiler enforces for you when you use the type. I'm saying that Swift is neither special nor unique here, and that other languages have the same kind of functionality. In C++, you can get the same functionality with boost::optional (which will probably eventually be part of the standard library). With Go, their pointers can act almost exactly like Swift's optionals.

      And if you're going to argue performance, Swift may be better than Objective-C, but it's probably not going to be better than Java or Go, and is certainly much slower than C/C++.

    167. Re:One more in a crowded field by BasilBrush · · Score: 1

      Now with boost optionals you're getting closer. That's intended for the same thing. Yet it's inferior in 2 ways:

      1) It's an object not a value. So you create a boost optional on the heap, and have a pointer to it. If you have an array of 4, then you have an array of 4 pointers, with 4 objects on the heap, each of which has 2 values.
      Swift optionals are values in themselves. If you have an array of 4 of them, then the actual optionals are in the array. There's nothing external.
      This means that Swift is a hell of a lot faster dealing with optionals. The clue is in the name.

      2) Because it's not part of the language it doesn't have a syntax to test and unbox in one. So you need more code.

      The memory representation is largely irrelevant to the coding algorithms. It might be important if you're going to do some low-level optimization, but if you're doing low-level optimization where that sort of thing matters, you shouldn't be working in Go, Swift, or Objective-C.

      There you go. Swift is intended for system software as well as apps. And as I told you earlier, it's designed to be easy for the compiler to optimise. This is a case in point. It's will be slower that C/C++ only if those languages are used in an unsafe way. If you use those languages with a library such as boost to give you safety, then Swift will probably be faster.

    168. Re:One more in a crowded field by Chalnoth · · Score: 1

      You can store objects (not pointers) in arrays in C++ just fine (aside from storing objects which include arrays such as strings, it is common for all of the value data to reside in the array). But this is usually an irrelevant implementation detail. 99% of the time it won't make any noticeable difference at all to performance. And when it does make a difference, you can optimize that section of code as needed. This makes no difference whatsoever as to how most algorithms are translated to code.

      And no, C/C++ are almost always going to be faster. In part this is because when you run into a performance bottleneck, the optimization possibilities are much more diverse. In part it's because many of the safety guarantees are enforced at compile time rather than run time. In part it's because C++ developers are rarely going to make use all of the same guarantees in their code, precisely for performance reasons. Unit tests and good programming practices can usually avoid the pitfalls that come with avoiding those checks.

      Of course, you can simply write your performance-critical bits of code in C or C++ within a Swift application, though for other languages SWIG works pretty well for that.

    169. Re:One more in a crowded field by Anonymous Coward · · Score: 0

      > You can store objects (not pointers) in arrays in C++ just fine

      Huh? I'm a bit rusty on my C++, so I may have missed a new feature addition, but aren't all objects stored as blocks of memory and assigned to pointers?

      I know you can declare arrays of structs, but I've never heard of an array of actual objects (unless you're using an Array object, which is probably storing pointers internally anyway).

  2. Quiet schmiet, frosty already by Hognoxious · · Score: 5, Funny

    Despite its publicity and hype being rather quiet by Apple standards

    I haven't seen it mentioned on CNN or the BBC, but there's about a dozen stories about it per day on a former tech new website.

    In fact, it's pushed 3D printers off the number one spot.

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    1. Re: Quiet schmiet, frosty already by Anonymous Coward · · Score: 0

      which is great because we need to rid ourselves from the c language and all the crime it spawned.

      opm hacked, bundestag hacked, kadpetsky hacked, white hous hacked who has not been hacked ?

      burn all copies of c compilers and rediscover the philosophy of pascal, ada and the like. type systems go a long way to provide micro level sofyware fault isolation.

      a single c bug typically opens the entire kernel though.

      little coincidence bell labs was a major nsa contractor. now join the dots.

    2. Re: Quiet schmiet, frosty already by phantomfive · · Score: 1

      which is great because we need to rid ourselves from the c language and all the crime it spawned.

      Swift isn't a replacement for C.

      --
      "First they came for the slanderers and i said nothing."
    3. Re: Quiet schmiet, frosty already by Teckla · · Score: 1

      Swift isn't a replacement for C.

      The OP said:

      which is great because we need to rid ourselves from the c language and all the crime it spawned.

      "The crime it spawned" presumably includes C++ and Objective-C, and Swift is certainly meant to replace Objective-C.

      Programming is, slowly but surely, maturing. The value of static typing over dynamic typing, strong typing over weak typing, safe memory programming languages over unsafe memory programming language, etc. is becoming undeniable.

      Good riddance to C, and all the crime it spawned. :-)

    4. Re: Quiet schmiet, frosty already by phantomfive · · Score: 2

      The value of static typing over dynamic typing, strong typing over weak typing, safe memory programming languages over unsafe memory programming language, etc. is becoming undeniable.

      Now you are dreaming.......have you looked at Javascript?

      --
      "First they came for the slanderers and i said nothing."
    5. Re: Quiet schmiet, frosty already by Teckla · · Score: 1

      Now you are dreaming.......have you looked at Javascript?

      Yes, it's terrible. Its popularity is merely a historical accident.

    6. Re: Quiet schmiet, frosty already by phantomfive · · Score: 1

      That's the kind of things ideologues have said about languages they didn't like for half a century. You are fitting into the pattern.

      --
      "First they came for the slanderers and i said nothing."
    7. Re: Quiet schmiet, frosty already by euroq · · Score: 1

      He's right, though. From a language purist perspective, Javascript is an awful language. The fact that 009 entered into a textbox doesn't translate into the number 9 is a historical flaw that is purely a language failure. Just because it's popular doesn't make it good. And that's the argument that's going on here.

      --
      Just because the U.S. is a republic does not mean it is not a democracy. Democracy/republic are not mutually exclusive.
    8. Re: Quiet schmiet, frosty already by phantomfive · · Score: 1

      Just because it's popular doesn't make it good.

      That kind of cuts to the core of his primary argument, wouldn't you say? The argument being, "Programming is, slowly but surely, maturing [because of language features]."

      --
      "First they came for the slanderers and i said nothing."
    9. Re: Quiet schmiet, frosty already by K.+S.+Kyosuke · · Score: 1

      It's shitty to write in directly, but a reasonable back end for compilers, though. Even more so with the future tail call elimination.

      --
      Ezekiel 23:20
    10. Re: Quiet schmiet, frosty already by Teckla · · Score: 1

      That's the kind of things ideologues have said about languages they didn't like for half a century. You are fitting into the pattern.

      Okay, I admit to a bit of hyperbole above. :-)

      However, JavaScript was never really meant for the kinds of applications it's now used for. Brendan E. and Netscape expected JavaScript to be used for light scripting in web pages, not for full blown browser applications. Java was supposed to be the solution for "real" browser applications. Many of the design decisions in JavaScript were made with this in mind.

      That being said, I don't think JavaScript is useless or hopeless. It has taken some positive evolutionary steps, and I hope it continues to do so. I still think, for the things it's used for, it's inferior to languages that have static typing and strong typing, but it's obviously still useful.

      Regarding C, C++, and Objective-C, I think they made good sense, once upon a time. I used to love C, and spent over 20 years programming it professionally, and even longer personally. I'm no stranger to the problems in the C family of languages, and was a "cross platform expert" in C for a good long while, and became intimately familiar with many of its problems.

      But the C family of languages make less and less sense for an expanding domain of applications. There's simply too much undefined and implementation defined behavior, not to mention the lack of memory safety. Even simple signed arithmetic -- a + b -- can invoke undefined behavior, unless you're very careful. There's just too much to worry about.

      That's not to say I think C, C++, and Objective-C are worthless. They have their application domains, it's just that those application domains have been shrinking, and continue to shrink.

      Most code should be written in a memory safe language with no undefined behavior, preferably with static typing and strong typing. When necessary, dropping down into a C family language makes sense, where memory layout, size, performance, etc. are crucial.

    11. Re: Quiet schmiet, frosty already by Anonymous Coward · · Score: 0

      From a language purist perspective, Javascript is an awful language. The fact that 009 entered into a textbox doesn't translate into the number 9 is a historical flaw that is purely a language failure.

      No, that is a DOM/browser failure. Automatic type conversions are dangerous in any language. It's best to make them explicit.

    12. Re: Quiet schmiet, frosty already by phantomfive · · Score: 1

      Most code should be written in a memory safe language with no undefined behavior, preferably with static typing and strong typing.

      Let's talk about this. First of all, every language has undefined behavior, unless you mean ML, which is fully defined. That's part of the reason the NICTA team proved that the assembly output from the compiler matched the specification. You might have a point there, but you'll need to say it more clearly.

      Secondly, I'm not sure which aspect of 'memory safety' you're referring to. If you mean memory leaks, then a higher level language won't save you. I've fixed more memory leaks in Javascript and Java over the last year than in C. In one case, the guy was calling into JNI and spent a month looking for a memory leak in the C portion. I hooked it up to a Java profiler and found the memory leak in a day. "Memory safety" only lulls you into a false sense of security.

      Static and strong typing....I'd be interested in hearing why you chose this......there are plenty of people who disagree. I mentioned Javascript as the most popular, but of course Python is rising in popularity as well, especially as a replacement for PHP. Alan Kay considers dynamic typing (runtime type binding) to be vastly superior. Alan Kay is not some foolish programmer addicted to low-level stuff, and he knows what he's talking about.

      --
      "First they came for the slanderers and i said nothing."
    13. Re: Quiet schmiet, frosty already by Teckla · · Score: 1

      Let's talk about this. First of all, every language has undefined behavior, unless you mean ML, which is fully defined. That's part of the reason the NICTA team proved that the assembly output from the compiler matched the specification. You might have a point there, but you'll need to say it more clearly.

      Okay, let me rephrase: the less undefined behavior in a programming language specification, the better. Programming is already a complex task -- having to worry about the hundreds of undefined behaviors in the C family of languages is a nontrivial burden.

      Secondly, I'm not sure which aspect of 'memory safety' you're referring to. If you mean memory leaks, then a higher level language won't save you. I've fixed more memory leaks in Javascript and Java over the last year than in C. In one case, the guy was calling into JNI and spent a month looking for a memory leak in the C portion. I hooked it up to a Java profiler and found the memory leak in a day. "Memory safety" only lulls you into a false sense of security.

      I'm referring to things like running off the end of an array and incorrectly set pointers resulting in damaged program state. This can be very hard to debug because often the system keeps running, and where you see the error can be far, far removed from the bad code that damaged program state in the first place.

      Static and strong typing....I'd be interested in hearing why you chose this......there are plenty of people who disagree. I mentioned Javascript as the most popular, but of course Python is rising in popularity as well, especially as a replacement for PHP. Alan Kay considers dynamic typing (runtime type binding) to be vastly superior. Alan Kay is not some foolish programmer addicted to low-level stuff, and he knows what he's talking about.

      Static typing because the compiler will error instead of errors at runtime.

      Strong typing so that hidden promotions don't result in unexpected behavior -- the programmer will be more likely to stop for a moment and think about it.

      In my experience, dynamically typed programming languages like Python don't scale (to large teams) or refactor well, and there's the ever present danger of runtime type failures.

    14. Re: Quiet schmiet, frosty already by shutdown+-p+now · · Score: 1

      A reasonable backend for compilers is something that is sufficiently low-level that you can implement most high-level language constructs with minimal overhead. Like, say LLVM, or even MSIL.

      JS, in contrast, is a very shitty backend. The only reason why anyone is seriously doing something in this direction at all is because 1) JS is all that you get in the browser, and 2) JS itself sucks, so there's a desire for a better language.

    15. Re: Quiet schmiet, frosty already by shutdown+-p+now · · Score: 1

      It's worth noting that Python is strongly typed - more so, in fact, than Java (which lets you add an int and a string with a transparent but non-obvious conversion - that doesn't work in Python!).

    16. Re: Quiet schmiet, frosty already by phantomfive · · Score: 1

      In Java, you know what the type will be at compile time (at least, you know what type it will be cast to). Python uses duck-typing, and even classes can be changed at runtime.

      --
      "First they came for the slanderers and i said nothing."
    17. Re: Quiet schmiet, frosty already by shutdown+-p+now · · Score: 1

      That is a different aspect of it - dynamic vs static typing. Yes, Python is dynamically typed. I was just pointing out that it is also strongly typed, which is something that most people are confused about, as many (most?) dynamically typed languages are also weakly typed - notably, JS and PHP (which you've used as the other example).

    18. Re: Quiet schmiet, frosty already by phantomfive · · Score: 1

      I'm referring to things like running off the end of an array and incorrectly set pointers resulting in damaged program state. This can be very hard to debug because often the system keeps running, and where you see the error can be far, far removed from the bad code that damaged program state in the first place.

      They used to be hard to debug, but they aren't very common. When was the last time you actually ran off the end of an array? With tools like Valgrind, they are simple to find.

      Also, have you actually programmed in C lately? Dealing with undefined behavior isn't much of a problem anymore.....the place you will have a problem is with libraries working on one system but not on another.

      In my experience, dynamically typed programming languages like Python don't scale (to large teams) or refactor well, and there's the ever present danger of runtime type failures.

      I'm not the one to defend this, because I more-or-less agree with you here; but people who do large scale projects in Python do it by having unit tests across the program that check to make sure the runtime type failures don't happen.

      The purpose, of course, is that dynamic typing gives you more flexibility, that allows your code to scale better. So whatever.

      --
      "First they came for the slanderers and i said nothing."
    19. Re: Quiet schmiet, frosty already by phantomfive · · Score: 1

      I don't think duck-typing can really count as 'strongly typed.' However, I do admit the definition of "strongly typed" and "weakly typed" are very poorly defined, and some Pythonistas do consider their language strongly typed because it doesn't do implicit type conversion.

      I don't think those people make much sense though......because duck typing is basically implicit type conversion everywhere.

      --
      "First they came for the slanderers and i said nothing."
    20. Re: Quiet schmiet, frosty already by shutdown+-p+now · · Score: 1

      Duck typing is not implicit type conversion - it's structural typing. And there are statically typed languages which use structural typing, even though they're rare. The canonical example is OCaml, which uses structural typing for its object system. For example, suppose you define a function like this:

      let foo x = x#y

      The # syntax is the same as dot-notation in Simula family, basically. Note that there are no type annotations anywhere. However, this is strongly typed as follows:

      val foo : <x : 'a -> 'b; .. > -> 'b

      What this says is that we've got a function that takes an object that has a method named "x" that takes a single parameter of unspecified type 'a, and returns a value of some other unspecified type 'b (maybe the same, maybe not). That function then also returns a value of that same type 'b.

      You can, in fact, call this function with an object of any class that has a method that is matching these constraints, and 'a and 'b will be appropriately inferred. But in all those cases, all the types will be checked at compile time - because the type is actually there, it can be checked against at every call site. And the <...> notation can be used explicitly to describe object types anywhere, so you don't really have to rely on type inference here (though as I understand, the main reason why they went for structural typing is because it plays well with type inference).

      Another example, which is a bit less clear-cut is TypeScript. It's less clear-cut because typing there is optional and opt-in, but if you do fully opt-in, it's static and strong - but still structural.

      So basically duck typing is yet another axis that can be used to describe a type system: structural vs nominal - and is orthogonal to the static/dynamic and weak/strong axes.

      I agree that the weak/strong is one of the least well defined axes, though. But given the existence of the other two, I don't see how it can be anything other than how types of values (as opposed to types of bound identifiers) are treated. And that's basically whether values are typed at all (to remind, there are languages that only have a single type that's interpreted depending on the context - e.g. Rexx or Tcl), and if they are, then how often that type is actually taken into account rather than being implicitly overriden by the context, as in PHP's arithmetic addition and string concat operators, or C's array decay.

    21. Re: Quiet schmiet, frosty already by shutdown+-p+now · · Score: 1

      Sorry, I forgot to actually add an argument to that method call. It should have rather been something like this:

      let foo x z = x#y z

      And then the type of foo is:

      val foo: <x: 'a -> 'b; ..> -> 'a -> 'b

    22. Re: Quiet schmiet, frosty already by phantomfive · · Score: 1

      One definition of "strongly typed" is: ""strong type system" is one in which there is no possibility of an unchecked runtime type error."

      --
      "First they came for the slanderers and i said nothing."
    23. Re: Quiet schmiet, frosty already by shutdown+-p+now · · Score: 1

      This basically defines "strong" as "100% static". Feels like a waste of a term :)

    24. Re: Quiet schmiet, frosty already by phantomfive · · Score: 1

      Pretty much, define it however you want. Someone said "an argument about the world is interesting. An argument about a word is not." Can't find the origin of that quote right now.....

      But as long as you're clear on how you define it, we can have fine conversations (still makes me laugh to call Python strongly typed, though).

      --
      "First they came for the slanderers and i said nothing."
    25. Re: Quiet schmiet, frosty already by euroq · · Score: 1

      Can you explain? Automatic type conversions are a feature of a language not a browser.

      --
      Just because the U.S. is a republic does not mean it is not a democracy. Democracy/republic are not mutually exclusive.
    26. Re: Quiet schmiet, frosty already by Anonymous Coward · · Score: 0

      Text boxes are not a JavaScript feature.

    27. Re: Quiet schmiet, frosty already by euroq · · Score: 1

      The conversion of the text "009" to a value of something other than 9 is a language feature and has nothing to do with text boxes.

      --
      Just because the U.S. is a republic does not mean it is not a democracy. Democracy/republic are not mutually exclusive.
    28. Re: Quiet schmiet, frosty already by Anonymous Coward · · Score: 0

      Then why did you use it as an example?

      And why do you think JavaScript should automatically convert a text input of "009" to an integer? Having built-in assumptions like that is bad; making it easy for the programmer to dictate the proper conversion is good, and JavaScript does that just fine.

    29. Re: Quiet schmiet, frosty already by euroq · · Score: 1

      It was just an example off the top of my head that has nothing to do with text boxes. Forget the fucking browser; in JavaScript, the string "009" when implicitly cast to a number does not turn into the integer 9. That's stupid.

      --
      Just because the U.S. is a republic does not mean it is not a democracy. Democracy/republic are not mutually exclusive.
    30. Re: Quiet schmiet, frosty already by Anonymous Coward · · Score: 0

      Like I said, automatic type conversions are dangerous and should be avoided.

      Given a text string "009," how do you know it represents a decimal number?
      How do you represent an octal number as a string, and convert that implicitly to an integer?

      Hidden assumptions are worse than quirky formatting rules when it comes to casting.

  3. Yes, but it will be a while. by jcr · · Score: 1

    Obj-C is on the way out. I say this as one who has used it since 1989. I'd guess that we're about a year away from the point where the majority new code at Apple is written in Swift.

    -jcr

    --
    The only title of honor that a tyrant can grant is "Enemy of the State."
    1. Re:Yes, but it will be a while. by Anonymous Coward · · Score: 1

      Except that Swift itself is entirely reliant on the Objective-C runtime. So, no, it's not going anywhere anytime soon.

    2. Re:Yes, but it will be a while. by Lunix+Nutcase · · Score: 5, Informative

      Obj-C is on the way out.

      Uhh, no. So much of the system libraries on both OS X and iOS are written in Objective-C and they aren't going anywhere. Also, all the new APIs of iOS 9 and OS X 10.11 are still written in both C and Objective-C with Swift bridge headers. Basically, it's the opposite of what you claim.

      I'd guess that we're about a year away from the point where the majority new code at Apple is written in Swift.

      Maybe at the application level, but not for system libraries.

    3. Re:Yes, but it will be a while. by Anonymous Coward · · Score: 0

      That is like saying Elixir is going to replace Erlang.

    4. Re:Yes, but it will be a while. by Schnapple · · Score: 1

      So much of the system libraries on both OS X and iOS are written in Objective-C and they aren't going anywhere.

      Maybe at the application level, but not for system libraries.

      So for a long time people at Apple will keep using the giant codebase they're familiar with but app developers, Apple and otherwise, will use Swift going forward. For the Universe minus Apple's OS developers, the statement is true.

    5. Re:Yes, but it will be a while. by Lunix+Nutcase · · Score: 1

      Yes, they will keep using the very language that is being claimed to be "on the way out". Sort of like how Microsoft never stopped using C or C++ for system libraries and APIs even after .NET came out.

    6. Re:Yes, but it will be a while. by Anonymous Coward · · Score: 0

      Your point is moronic.

      Statement: "[Private] Developers will be using Swift!"
      You: "NO THEY WON'T SYSTEM LIBRARIES ARE IN OBJ-C HAHAHA FUCK YOU LOL NOOB"
      Statement: "... Err, so private developers will be using Swift"
      You: "YES SO THEY'LL BE USING OBJ-C HAHAHAHAHAHAHA FUCKTARD"

      Tit.

    7. Re:Yes, but it will be a while. by phantomfive · · Score: 1

      Maybe. I still prefer Objective-C.

      --
      "First they came for the slanderers and i said nothing."
    8. Re:Yes, but it will be a while. by Anonymous Coward · · Score: 0

      Except that Swift itself is entirely reliant on the Objective-C runtime. So, no, it's not going anywhere anytime soon.

      Latin hasn't gone anywhere... but it's a dead language.

      Nearly everything uses C/C++/Objective-C runtimes, but those languages are on the verge of extinction in many segments of the market.

    9. Re:Yes, but it will be a while. by jcr · · Score: 1

      all the new APIs of iOS 9 and OS X 10.11 are still written in both C and Objective-C with Swift bridge headers.

      You're not taking into account the ease with which Obj-C classes can be extended in Swift, with the new Swift code remaining available to Obj-C.

      -jcr

      --
      The only title of honor that a tyrant can grant is "Enemy of the State."
    10. Re:Yes, but it will be a while. by jblues · · Score: 2

      Nearly everything?

      Aren't most things currently running in "managed" (with a Virtual Machine, and garbage collection) environment these days? Swift is interesting, in that, like Objective-C it uses Automatic Reference Counting (ARC) for memory management, along with a syntax that is appealing to younger developers. ARC gives almost all of the benefits of garbage collection, at the same time as being compiled in, so it doesn't require CPU clicks at run-time. For mobile this (which is where everything is going) this gives superior performance and battery life. I'd say we're moving in this direction, not away.

      --
      If it acquires resources on instantiation like a duck, then its a shared_ptr<Duck>
    11. Re:Yes, but it will be a while. by jblues · · Score: 1

      I'm new to this thread, but I must admit I'm also having a difficult time following your point. Could you try rephrasing it?

      --
      If it acquires resources on instantiation like a duck, then its a shared_ptr<Duck>
    12. Re:Yes, but it will be a while. by jeremyp · · Score: 1

      No it isn't. The Swift runtime is entirely different to the Objective-C runtime. However, if you want to write a usable app with a GUI, you do need to use the Cocoa libraries which are mostly written in Objective-C.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    13. Re:Yes, but it will be a while. by Anonymous Coward · · Score: 0

      lol. Look man, I work at Apple. If there's any code developed in swift [1], that would be a complete surprise to me. I mean, you might as well predict that Microsoft will develop everything in Visual Basic (6 or .Net, depending on the century).

      [1] token WWDC app doesn't count

    14. Re:Yes, but it will be a while. by slashdice · · Score: 0

      well, she might stop sucking dick for crack and start sucking dick for meth.

      --
      Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
    15. Re:Yes, but it will be a while. by Chalnoth · · Score: 1

      There's a fairly good chance that Apple is going to push to have their OS transitioned over to Swift.

    16. Re:Yes, but it will be a while. by BasilBrush · · Score: 1

      Well not entirely different. The Swift object model runs on top of the Objective-C runtime. For the most part Swift doesn't have to call down to that runtime unless you are interacting with Objective-C. But it will if you mark a property as dynamic, regardless of interaction with Objective-C.

      But most of the time you're not doing that.

    17. Re:Yes, but it will be a while. by BasilBrush · · Score: 1

      Being "on the way out" means new code.

      Heck there's still old code written in Cobol that's still in use by some organisations, but you wouldn't argue that Cobol isn't on it's way out.

      And yes, it's only a matter of time before Apple is writing new libraries in Swift. Swift is absolutely intended to replace system code as well as app code.

    18. Re:Yes, but it will be a while. by BasilBrush · · Score: 1

      Still early days. Swift is mature enough for developers that are new to iOS/OSX to use. As yet there's no a huge incentive for Objective-C developers to change, especially when working on existing projects. But the time will come when creating a new project, and Swift will seem like the natural choice.

    19. Re:Yes, but it will be a while. by BasilBrush · · Score: 1

      I doubt it. There's rarely a good reason to re-write existing code. I think they'll start doing new libraries in swift. Maybe even new APIs in existing libraries. But I don't see them doing a whole rewrite of Cocoa.

    20. Re:Yes, but it will be a while. by phantomfive · · Score: 1

      I would be really interested on what Apple developers are using internally.

      --
      "First they came for the slanderers and i said nothing."
    21. Re:Yes, but it will be a while. by robi5 · · Score: 1

      In a humorous way, GP anon makes the valid point that, ObjC can become marginalised over time if Swift gains followers in the general population, despite the fact that iOS / OS X system libraries will continue to exist, or be created in ObjC. For there are a _lot_ more people working on 'apps' than there are people making ObjC or C++ libraries that work under the hood, beneath opaque APIs (typically Apple employees, for libraries like Core Animation, Metal etc.). From the application developer's viewpoint, it usually doesn't matter if the system library beneath an API is implemented in C, assembly, Swift, Fortran etc. as he just calls the API functions from within, e.g., Swift. The GP, mind you, doesn't make the point that Swift will prevail over ObjC among app developers, just challenges the notion that the use through an API of an opaque library written in language X makes you a user of language X, or in some way make you count toward the use of language X.

    22. Re:Yes, but it will be a while. by Anonymous Coward · · Score: 0

      Baby Jesus Buttplugs

    23. Re:Yes, but it will be a while. by Schnapple · · Score: 1

      Yeah it's more likely that whatever replaces Cocoa (if that ever happens) will be all in Swift.

      Sort of like how even if everything you see in Windows is written in .NET, Windows under it is still mostly C/C++.

    24. Re:Yes, but it will be a while. by Anonymous Coward · · Score: 0

      There's an even closer analogy in Microsoft land. When WinRT appeared, you were supposed to write apps that use it in JS, C#, VB or C++. For the latter, a bunch of language extensions collectively referred to as C++/CX were introduced, which are actually not all that dissimilar to what Swift offers (basically, a single-inheritance object model with introspection and reference counting), except that it's an actual superset of C++ instead of a brand new language. There's also a pure C++ library called WRL that lets you avoid the extensions, but then you have to deal with HRESULT error codes, composition-based inheritance etc directly. This is supposed to be very low-level, and C++/CX is the recommended approach.

      The funny part is that all the system WinRT libraries are written in C++ using WRL, largely because C++/CX was simply not implemented back when the work on WinRT began. Consequently, most new code is also WRL-based, because it is based on that old code.

    25. Re:Yes, but it will be a while. by jcr · · Score: 1

      Look man, I work at Apple. If there's any code developed in swift [1], that would be a complete surprise to me.

      I've worked there too (three times), and I stay in touch with my former colleagues, particularly those in DevTools and Cocoa frameworks. If you're not hearing about Swift work, then you're in the wrong group.

      -jcr

      --
      The only title of honor that a tyrant can grant is "Enemy of the State."
    26. Re:Yes, but it will be a while. by jcr · · Score: 1

      There's rarely a good reason to re-write existing code.

      There are plenty of good reasons to do so, particularly when that existing code is less efficient than it could be and it's running in a resource-constrained device like a phone or an iPad.

      -jcr

      --
      The only title of honor that a tyrant can grant is "Enemy of the State."
    27. Re:Yes, but it will be a while. by BasilBrush · · Score: 1

      That's not a reason to do wholesale rewrites. Only to break out the profiler and do optimisations. Possibly rewriting very small parts.

    28. Re:Yes, but it will be a while. by jcr · · Score: 1

      I'm still more comfortable with Obj-C than Swift, but I'm using Swift exclusively from here on out.

      -jcr

      --
      The only title of honor that a tyrant can grant is "Enemy of the State."
  4. This survey is championed everywhere... by Anonymous Coward · · Score: 0, Insightful

    I keep seeing this survey and there's so much weird shit in it, I gotta think something is very wrong with the results.

    1. Re:This survey is championed everywhere... by GuB-42 · · Score: 1

      It's not that weired. It is a "most loved" survey.
      All these languages look very cool on paper and it's probably very fun toying with them. However, it doesn't say much about what is it like to do actual development where the language must serve the project and not the opposite.

  5. No by mikes.song · · Score: 1

    Swift, if anything, is the new VB.

    1. Re:No by Anonymous Coward · · Score: 2, Informative

      And VB was a hugely popular language for writing business apps and one of Microsoft's best selling products.

    2. Re: No by spongman · · Score: 2

      No, objective-c is apple's VB - a shitty language that everyone was more-or-less forced to use long ago if they wanted to use their platform (cocoa/office).

      I'd say swift is more like apple's C# - a modern language that everyone (including mocrosoft) wishes every VB/objc developer would switch to. Asap.

    3. Re: No by mikes.song · · Score: 1

      You have lots of misconceptions.

    4. Re:No by gweihir · · Score: 1

      And Business apps is where you routinely find the dumbest coders, the slowest and most unreliable code and the worst coding practices and mistakes. In fact, making coding easier is probably the number one factor why so much code sucks.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  6. Only if overlooking hypercard by Anonymous Coward · · Score: 0

    What is a "coder" anyway? These days it's someone adding gratuitous javascript to shoddy html and convoluted css through crappy php and many, many layers of entirely superfluous back-end magic. Because cloud, baby. The "app" scene isn't much better, reinventing the bad reinventions even worse.

  7. That survey is problematic... by antiperimetaparalogo · · Score: 4, Informative

    If this year's survey of coders by Stack Overflow is anything to go by, it looks as if the language might have potential to really shake things up in a landscape which has been little changed since the 1990s

    "Most Loved"

    • Swift 77.6%
    • C++11 75.6%
    • Rust 73.8%
    • Go 72.5%
    • Clojure 71.0%
    • Scala 70.6%
    • F# 70.1%
    • Haskell 69.5%
    • C# 67.2%
    • Python 66.6%

    "Most Wanted"

    • Android 17.7%
    • Javascript 15.4%
    • Python 14.8%
    • Node.js 14.6%
    • AngularJS 13.2%
    • Java 10.5%
    • iOS 9.4%
    • Arduino / Raspberry Pi 8.5%
    • Swift 8.5%
    • C# 8.0%
    --
    Antisthenes: "Wisdom begins by examining the words/names." - excuse my English, i am (slightly...) better with my Greek!
    1. Re:That survey is problematic... by Rockoon · · Score: 1

      Swift 77.6%
      C++11 75.6%
      Rust 73.8%
      Go 72.5%
      Clojure 71.0%
      Scala 70.6%

      Swift, 6.6% more loved than Clojure, and a full 7% more loved than Scala.

      Yep, sure sounds like a selling point.

      --
      "His name was James Damore."
    2. Re:That survey is problematic... by Anonymous Coward · · Score: 0

      Considering Java is 10.5%, what the fuck is the "Android" programming language?

    3. Re:That survey is problematic... by Anonymous Coward · · Score: 0

      Technically "dex" bytecode up until 5.0 then 'art's new' bytecode (not sure of name, which is why AC post, b/c I 'should' know this... I help teach a MOOC on the topic...)

      after M the compiler/toolchain goes right from java source to bytecode, completely skipping (other than possibly internally) .class files

      This is probably to help GOOG/Android fight against Oracle lawsuits saying 'look we don't even use .class files we just like their pretty syntax, which is a 'language' which you can't copyright.... yadda yadda yadda...

      Also Android also supports 100% native code c/some c++ (not that most people would even bother doing that) ... Also.... Its a distinct 'subset' which separating out the Android flavor of java syntax from 'Java proper' makes a lot of sense, if you want to add them together go ahead, but if they were already lumped together with no indication how much of each... the #s would be less useful.

    4. Re:That survey is problematic... by antiperimetaparalogo · · Score: 1

      Basically... Java!

      --
      Antisthenes: "Wisdom begins by examining the words/names." - excuse my English, i am (slightly...) better with my Greek!
    5. Re:That survey is problematic... by antiperimetaparalogo · · Score: 1

      I like surveys, but (ab)using some "problematic survey(s)" as selling point is not only problematic but also dishonest.

      --
      Antisthenes: "Wisdom begins by examining the words/names." - excuse my English, i am (slightly...) better with my Greek!
  8. Apple's Biggest Achievement For *iOS/OS X* Coders by Lumpio- · · Score: 1, Flamebait

    Not exactly big unless you only care about iOS/OS X. I don't see a future for Swift outside that niche.

  9. It's there by SuperKendall · · Score: 1

    Swift was mentioned on CNN here

    It was also mentioned on BBC here...

    I've seen mentions of it all over, on a lot of non-tech web-sites. That has been kind of amazing.

    Coding is starting to matter more, especially as black hats affect more and more people - so people are starting to care about it more generally, even if they don't really understand details yet.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:It's there by Hognoxious · · Score: 1

      Given that I was referring to TV channels, it ought to be obvious that I meant on the fucking television.

      If you'd bothered to read the articles rather than posting the first thing you found on poogle you'd see it had one passing reference in each article.

      Hardly taking the world by storm, is it?

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  10. Objective-C is now legacy - but not quite dead by CraigCruden · · Score: 2

    Swift in its first year has become the preferred language for developing on the Apple platform. Objective-C is being "improved" but only as a bridge to support interoperability with improvements that are being incorporated into Swift.

    There is a lot of Objective-C code that will have to be maintained, and over time it will be replaced with Swift code... but it won't disappear overnight. In a year all new development is likely to be done in Swift, while Objective-C is just maintained.

    Eventually -- in many years time as Objective-C code is revisited it will be phased out.... but it will be a very long time-frame.

    If you are starting development on a new application - you would have to be very short-sighted to pick Objective-C as a starting point.

    1. Re:Objective-C is now legacy - but not quite dead by Lunix+Nutcase · · Score: 1

      Objective-C is hardly "legacy" considering most, if not all, of the new system libraries and APIa in both iOS 9 and OS X 10.11 are written in Objective-C. Not a single system library or service is written in Swift.

    2. Re:Objective-C is now legacy - but not quite dead by CraigCruden · · Score: 1

      That will change over time. The code for the APIs (new or not) have been under development for a while - some of it ported from one platform to another, some of it built using other APIs...... as such developing new APIs on a system in flux before or during the first year would be a little risky. As all new application development (including bundled) applications - the majority of the application code itself will be swift based. At that point the only reason to continue to build new APIs (i.e. totally new code - not reworked or ported code) is if it provides some benefit - performance or not. As both Swift and Objective-C are new built on the LLVM, and as Swift matures and they invest money in optimization.... it leaves no reason to continue building in Objective-C other than legacy or legacy dependant reasons.

    3. Re:Objective-C is now legacy - but not quite dead by Anonymous Coward · · Score: 1

      The problem is that people like yourself were claiming this exact same thing about .NET when it came to Windows claiming that C and C++ were "legacy" and all new API development was only going to be for .NET. And yet, even more than a decade later all the system libraries and services on Windows are written in C and C++ not .NET. There's no reason to believe that Apple will be any different. Objective-C and C are going to be what all system level frameworks and services will be written in for many more decades.

    4. Re:Objective-C is now legacy - but not quite dead by Lunix+Nutcase · · Score: 1

      That will change over time.

      No, it won't. Unless you're going to claim that Apple is going to stop supporting C development on their systems. Because the only way to support C in this supposed future where system frameworks will be written in Swift is that Objective-C will still need to be around.

    5. Re:Objective-C is now legacy - but not quite dead by CraigCruden · · Score: 2

      The difference is that .NET was developed and designed as an applications language with little regard to systems programming -- where the market .NET was aimed at was not replacing the language that was used for systems programming but providing an applications framework (more as a reaction to java than anything else).

      Swift was designed from the ground up to be as performant as Objective-C and as a replacement language for the language that they actually write the APIs in. In essence Swift is a systems language as much as it is an applications language. Swift is designed to be AS performant as objective-c, which means their is little benefit to move forward with a less productive language.

      The difference is that up until only recently there has been very very little new / competitive options in the systems languages area.

    6. Re:Objective-C is now legacy - but not quite dead by CraigCruden · · Score: 1

      This mixing of C and Objective-C for the sake of making a point is ridiculous.

      Objective-C IS NOT C. Darwin the operating system kernel underneath the UI is written in C, C++..... not Objective-C.

      The UI APIs and Objective-C are what we are talking about... So no, Objective-C to continue being used going forward is not in the same league.

    7. Re:Objective-C is now legacy - but not quite dead by Bogtha · · Score: 1

      Because the only way to support C in this supposed future where system frameworks will be written in Swift is that Objective-C will still need to be around.

      That's not true. While it's possible to use Objective-C frameworks from C, in practice, nobody does this. People writing C for Apple platforms don't usually call out to Objective-C from C, they call into their C from Objective-C. Entirely replacing Objective-C with Swift won't change this - you can call into C from Swift just as you can call into C from Objective-C.

      Now I think if there is ever a situation where Apple would drop support for Objective-C, I do think it's likely that they would drop support for C at the same time, but it's not because writing C for Apple platforms requires the presence of Objective-C.

      --
      Bogtha Bogtha Bogtha
    8. Re:Objective-C is now legacy - but not quite dead by BasilBrush · · Score: 1

      What are you talking about? Swift supports C libraries just as much as Objective-C supports C libraries.

      Maybe, when Apple release Swift for Linux, you can actually have a play with it, and begin to know what the fuck you're talking about.

    9. Re: Objective-C is now legacy - but not quite dead by spongman · · Score: 1

      Rubbish. .NET was designed as an application development environment to replace VB/Java and COM+, not C++.

    10. Re:Objective-C is now legacy - but not quite dead by BasilBrush · · Score: 1

      It's actually designed to be more performant than Objective-C. The clue is in the name. Unless you opt in, Swift doesn't do dynamic despatch. It's also designed from the start to be easy for the compiler to optimise.

      Swift can be slower than Objective-C if a naive translation of Obj-C to Swift code is done. However, writing an algorithm using using the best available features of Swift will generally mean Swift is far faster.

      Objective-C isn't fast enough for many system frameworks, which is why even modern ones are often written in C. But Swift should be fast enough.

    11. Re:Objective-C is now legacy - but not quite dead by shutdown+-p+now · · Score: 1

      With Obj-C, you can just #include a header for any random C library, and it just works. Does the same work with Swift? Or do you need to manually write external declarations for all the functions and structs that you use?

    12. Re:Objective-C is now legacy - but not quite dead by BasilBrush · · Score: 1

      There's a single file in a project that lists all the C header files you want to use. They are then available to any Swift code. You don't have to do anything more.

    13. Re:Objective-C is now legacy - but not quite dead by shutdown+-p+now · · Score: 1

      Ah - now that is a very worthwhile feature that I'd kill to have in C#.

      Is this C-only, or can it also handle C++?

    14. Re:Objective-C is now legacy - but not quite dead by BasilBrush · · Score: 1

      C and Obj-C.

      Not C++. C++ can exist in the same project, but you can't call C++ apis. You'd need to write some wrappers.

  11. Goodbye Objective-C by MouseTheLuckyDog · · Score: 1

    It's clear that Apple wants to replace Obj-C with Swift. So eventually it's going to happen. Since the Obj-C tools will not be maintained.

    Will Swift make inroads outside the Appleverse. Some but nowhere near as much as Apple and it's fanboys are hoping.

    1. Re:Goodbye Objective-C by Anonymous Coward · · Score: 0

      It's clear that Apple wants to replace Obj-C with Swift. So eventually it's going to happen. Since the Obj-C tools will not be maintained.

      Maybe at the application level, but Objective-C and C are still what all the system libraries and APIs are and will be written in with a Swift bridge header.

    2. Re: Goodbye Objective-C by Anonymous Coward · · Score: 0

      just wait for china and russia creating memory safe kernels ala burroughs.

      they did once and they will do again. they are also fed up with the cyber war antics.

    3. Re:Goodbye Objective-C by bradrum · · Score: 1

      C yes. But does it really matter when Swift provides a clear way to interact with lower level C APIs? C++ is a problem though, because you currently have to use Objective-C++ to make the bridge. A good example of this is the Core Audio/OpenGL helper/utility code. Most of that is written in C++. You will need to have Objective-C to make the bridge to that very helpful code. And I imagine this is a very common situation with the relationship between low level C apis and C++ utilities written to make writing for he C APIs less labor intensive. Maybe that situation will change as code is ported from C++ to Swift..

    4. Re:Goodbye Objective-C by gnasher719 · · Score: 1

      Objective-C cannot interact with Objective-C++ header files. You always needed a header file that is plain Objective-C, with the implementation being Objective-C++. And Swift looks only at the headers.

    5. Re:Goodbye Objective-C by gnasher719 · · Score: 1

      Will Swift make inroads outside the Appleverse. Some but nowhere near as much as Apple and it's fanboys are hoping.

      Why that needless attempt at an insult? Especially when it's obvious that you haven't thought this through. You also spelled "fanboi" wrong.

    6. Re:Goodbye Objective-C by Dutch+Gun · · Score: 1

      People keep on about Apple dropping support for Objective-C, which seem ridiculous to me. A huge number of OS X's existing APIs are Objective-C based. And if nothing else, these are likely to remain for the next decade or two simply to maintain compatibility with today's apps, nearly ALL of whom are written in Objective-C. There are also a number of APIs Apple relies on that are C based as well, which requires either C/C++ or Objective-C to interface with. You seriously think Apple is going to replace OpenGL, OpenAL, and ALL their Objective-C based APIs as well? For what benefit? So they can drop support for a language that only requires a bit of maintenance work here and there, but otherwise is working just fine right now?

      What's with people's obsession of killing off Objective-C just because there's a new language available for use? It makes zero sense to me. Do people think that Apple is somehow incapable of (gasp) supporting TWO languages for their platforms? And what about support for C or C++? Lots of that code still floating around as well.

      No... Objective-C will very likely be supported for decades to come. Sure, the language will stagnate while Swift moves forward, and at some point it will be used purely for legacy purposes or to bridge Swift and C-based APIs like OpenGL, but the support will still be there.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    7. Re:Goodbye Objective-C by BasilBrush · · Score: 0

      Why would Apple "fanboys" give a damn whether developers on other platforms use Swift. It doesn't affect us. It was the Linux heads here that were complaining that swift wasn't cross platform. Well now it is. Take it or leave it, it doesn't matter to us.

    8. Re:Goodbye Objective-C by goose-incarnated · · Score: 1

      Why would Apple "fanboys" give a damn whether developers on other platforms use Swift. It doesn't affect us. It was the Linux heads here that were complaining that swift wasn't cross platform. Well now it is. Take it or leave it, it doesn't matter to us.

      Objective-C was also available to the rest of the world outside Apple. They left it. Now Apple is (presumably) leaving it too.

      --
      I'm a minority race. Save your vitriol for white people.
    9. Re:Goodbye Objective-C by MacDork · · Score: 1

      Since the Obj-C tools will not be maintained.

      This. Got a large codebase in Obj-C? You'll be hung out to dry. Remember WebObjects? Of course you don't.

    10. Re:Goodbye Objective-C by BasilBrush · · Score: 1

      And...?

  12. Not at all by Anonymous Coward · · Score: 0

    Biggest achievement is clearly Dylan. Too bad it doesn't run on the Newton, though.

  13. kill cyber war domain by Anonymous Coward · · Score: 0

    rust and swift are a powerful antidote to the dangerous DRECK from bell labs.

    one can even isolate driver bugs when using a memory safe language for an os kernel.

    the russians already work on this, lets see how long the americans continue to excrement on themselves with kernels done in c.

  14. gotta eat and pay rent by Anonymous Coward · · Score: 0

    and profit's not a bad thing.

    Sure, writing in Erlang and Haskell are interesting, but you're not going to have hundreds of thousands of people paying the rent with that. Apple device apps will allow you to keep body and soul together.

  15. Re:Comparison. by Anonymous Coward · · Score: 0

    > Objective-C really sucks. It is old (pre-dating C++)

    Objective-C doesn't pre-date C++.

    Stroustrup started his work before Cox & Love, and published his language first.

  16. Swift is (shortly) everywhere, including Linux by SuperKendall · · Score: 3, Informative

    In the keynote they announced Swift being open source later this year, including releasing versions for Linux...

    Having done over a decade of backend work in the past, I think it would make a pretty good server language also. It's all about the libraries and frameworks that support what you are trying to do.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  17. Frustrating type conversions by Anonymous Coward · · Score: 1

    The most irritating thing with Swift is its requirement that you explicitly convert numeric types. Trust me, when I assign a double to an int, I know I lose the mantissa. You really don't have to confirm that with me or make me type more to do it. Someone wrote a really nice library to fix that, and then Apple broke it by removing some features from Swift.

    1. Re:Frustrating type conversions by 0123456 · · Score: 5, Interesting

      That would probably have prevented the annoying bug I ran into a few years ago where someone copied a 64-bit time_t to a 32-bit int, did some arithmetic, and then copied it back to a 64-bit time_t, requiring us to update firmware at all customer sites to fix it. If they had to explicitly convert, they'd almost certainly have realized they were doing something wrong.

      That bug alone probably cost us more money than the time required for programmers to always explicitly convert types.

    2. Re:Frustrating type conversions by jeremyp · · Score: 2

      Trust me, when I assign a double to an int, I know I lose the mantissa. .

      Since it's actually the exponent you lose (and maybe also some or all of the mantissa depending on what the value of the exponent was), I really think you need to start using a language that gently reminds you that converting from a double to an int is not necessarily a trivial exercise.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    3. Re:Frustrating type conversions by BasilBrush · · Score: 1

      If you are converting a double to an int, you need to think about whether you want to round down or round up, for both positive numbers and negative. A step to make the conversion explicit is good, even if you are doing the most common thing.

      Consistency is also an issue where a project has multiple coders. Where a method takes a float, it fucking annoys me when some people have variously put 0, 0.0, or 0.0f.

    4. Re:Frustrating type conversions by Anonymous Coward · · Score: 0

      Virtually all modern compilers will warn you about implicit integer demotion with the relevant warning settings. This raises the question, as to why exactly do you feel that the problem is with the language, when you had all the tools necessary to detect it?

      Have we learned nothing form Java? Forcing programmers to be overly verbose doesn't improve code quality, bad programmers will write bad code regardless of the language.

    5. Re:Frustrating type conversions by goose-incarnated · · Score: 1

      That would probably have prevented the annoying bug I ran into a few years ago where someone copied a 64-bit time_t to a 32-bit int, did some arithmetic, and then copied it back to a 64-bit time_t, requiring us to update firmware at all customer sites to fix it. If they had to explicitly convert, they'd almost certainly have realized they were doing something wrong.

      That bug alone probably cost us more money than the time required for programmers to always explicitly convert types.

      Your programmers might not be very smart if they either a) didn't turn on the warnings or b) ignored the warnings. In both those cases a language won't help - you'd still have bugs due to ignoring the warnings.

      --
      I'm a minority race. Save your vitriol for white people.
    6. Re:Frustrating type conversions by 0123456 · · Score: 1

      Your programmers might not be very smart if they either a) didn't turn on the warnings or b) ignored the warnings. In both those cases a language won't help - you'd still have bugs due to ignoring the warnings.

      That's why you need a compiler ERROR, like the one the OP was complaining about.

  18. Meh by tylersoze · · Score: 2

    I don't know, most long time iOS developers I know, including myself, aren't really jumping all over themselves to adopt Swift. I mean the writing is on the wall obviously, and Apple will eventually drop Objective-C down the road, so we'll have to eventually adopt it. That's the attitude I'm seeing among people I know. Personally I don't particularly like it that much and it seems to be solving problems that don't need a solution, like fucking optionals. That said, there are features of the language I like but I wish they had just continued to develop and refine Obj-C, honestly just getting rid of the bracket syntax and adding some of the features from Swift would satisfy me. Apple characterizing Swift as "Obj-C without the C" couldn't be more wrong. It's more like "C++ without the C" or "Obj-C without the Small Talk"

    Most of the talk about Swift seems to be coming from people that aren't iOS developers and don't really have any idea what they're talking about.

    1. Re:Meh by BasilBrush · · Score: 1

      solving problems that don't need a solution, like fucking optionals.

      Doesn't need a solution? The fact that you don't know when you receive a pointer whether it's allowed to be nil? It's a huge problem. Always has been. A very common cause of bugs. A very common case of error handling that is not done when it should be or done when there is no need.

      And Obj-C translating a method called on a nil pointer to no-op generally just hides problems.

      (I'm an iOS Obj-C developer on one of the most popular apps on the store. We haven't started using Swift yet, but now 2.0 is out I'll be pushing for that.)

    2. Re:Meh by goose-incarnated · · Score: 1

      (I'm an iOS Obj-C developer on one of the most popular apps on the store. We haven't started using Swift yet, but now 2.0 is out I'll be pushing for that.)

      That doesn't sound like a very wise business decision - are you planning to rewrite the (current popular) app?

      --
      I'm a minority race. Save your vitriol for white people.
    3. Re:Meh by BasilBrush · · Score: 1

      Of course not. There are now variations going out regularly, I'm talking about new code.

    4. Re:Meh by goose-incarnated · · Score: 1

      Of course not. There are now variations going out regularly, I'm talking about new code.

      Well good luck :-) I'm sure that I'm not the only one who's waiting to see how well this language fares in extended real-world usage. Be sure to publicise your successes.

      --
      I'm a minority race. Save your vitriol for white people.
  19. Okay, poll... by Chris+Mattern · · Score: 2, Insightful

    How much did Apple pay for this article?

    1. Re:Okay, poll... by Anonymous Coward · · Score: 0

      It doesn't really matter, because Swift is an Apple-ecosystem language, which has needed a new language for a long time. If you've been eating dust for a decade, of course you'll love it when your master throws you a fresh bone.

  20. Re:how do personal ads for people into incest work by Anonymous Coward · · Score: 1

    heh, good one.

  21. Swift's compatibility is largely irrelevant by perpenso · · Score: 1

    How's Swift's cross-platform suitability?

    Well its now available for Linux and it has been open sourced.

    But more importantly its compatibility is largely irrelevant. Keep the UI and core code separate. The core of an app/game should usually be written in C/C++ for compatibility. Its not all that difficult to keep core code in C/C++ compatible for iOS, Android, Mac OS X, Linux, and MS Windows. Been there done that plenty of times. And its often best to just go with the language that is native for the platform with respect to the UI code.

  22. What methods "see if you have a single reference" by SuperKendall · · Score: 1

    the ability to see if you have a single reference (a feature of reference counting) is a feature needed to optimize string and collection types

    What is that? Are you referring to weak variables where the reference goes to nil when the underlying object does? Garbage Collection systems have such references also (Java for one).

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  23. Re:What methods "see if you have a single referenc by Anonymous Coward · · Score: 0

    lol swift. lol java. lol objective c.

    Qt FTW. c/C++ all the way, windows, linux and OS X for many things.

    I haven't coded in objective c or used Apple's *abysmal* cripped UI maker in years. I don't plan to start, either. No call for it at all.

  24. Hypercard anyone? by PDX · · Score: 1

    I'm still waiting for the return of hypercard from Apple. There are knock offs out there.
    http://hypercard.org/

  25. "Shake things up?" by msobkow · · Score: 1

    Swift may "shake things up" in the Apple world, but to other platforms, it's just another language among many. The fact that Apple has focused almost exclusively on Objective-C means it's a major change for their developers, but no other platform has ever had such a single-language focus and won't be affected anywhere near as much.

    I realize that to Apple fanbois, Apple and it's platforms are the world, but to the rest of us, they're just one of many fish in the IT sea.

    --
    I do not fail; I succeed at finding out what does not work.
  26. One-size-fits-all, a way to sabotage your app by perpenso · · Score: 1

    Or use Qt for the frontend.

    Honestly: it makes no sense at all to rewrite GUI code.

    50% or more of the code for an app is GUI ...

    No, it absolutely make sense to use the native api of a platform to create the user interface. Otherwise you app does not look or behave as expected and that has been shown to be harmful to an app's success. So if its an internal enterprise app that people will be told to use, fine, take that shortcut. However if your app's success depends on being embraced by the public absolutely beware of these one-size-fits-all solutions. Your app must look native, it must look current, it must support all the built-in shortcuts, etc.

    1. Re:One-size-fits-all, a way to sabotage your app by perpenso · · Score: 1

      Or use Qt for the frontend. Honestly: it makes no sense at all to rewrite GUI code.

      No, it absolutely makes sense to use the native api of a platform to create the user interface. Otherwise your app does not look or behave as expected and that has been shown to be harmful to an app's success. So if its an internal enterprise app that people will be told to use, fine, take that shortcut. However if your app's success depends on being embraced by the public absolutely beware of these one-size-fits-all least-common-denominator solutions. Your app must look native, it must look current, it must support all the built-in shortcuts, etc.

      50% or more of the code for an app is GUI ...

      That must be a fairly trivial app. Or your design and implementation is wrong. Lets use a scientific/statistical/business/hex/bill/tip calculator app that I wrote as an example. All the math is naturally in the core. So is an api that the user interface will call. This api basically includes a function for each button possible press.

      The platforms specific side of the code does nothing more than call the appropriate button press C api function (ex button_1() button_plus() button_2() button_equals()). The core code does all the real work. I can re-use the core on Android or on a desktop OS. I even build this core code against a Linux console front end. Two actually, one for a scripted regression test that simulates user button presses and another that generates random values and operations for fuzzing. Note that these tests are not using a special api, they are using the exact same api that the user interface code is using. Things like that are important.

    2. Re:One-size-fits-all, a way to sabotage your app by angel'o'sphere · · Score: 1

      Well, you seem not even able to use a cross platform library correctly.

      Then you come with a trivial example for GUI/core interaction. Using a "pocket calculator" is extremely brain dead as it has nothing which a GUI on it. The calculator would look and feel exactly the same with ANSI Text "GUI"s calling a bunch of buttons and a single text field a GUI is joke at best and idiotic at worse.

      I suggest to port a CAD or CASE application or at least a simple drawing application from Windows to a Mac, and then do the same with QT. Nothing to port in the later case, and nothing to notice any difference from your manual port before. Only the most keen eyes might spot a different pixel somewhere when you use a special GUI element to show case a portability issue.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    3. Re:One-size-fits-all, a way to sabotage your app by perpenso · · Score: 1

      Well, you seem not even able to use a cross platform library correctly.

      You mean working around the library and writing native code for platforms specific functionality?

      Even for functionality that is common compromises sometimes have to be made and it does effect apps. I've ran more than one QT based app on a Windows box where my first impression was "why does this look like something from a Linux desktop?". For some apps that is OK, for others it is not.

      Basically shortcuts involve tradeoffs, tradeoff have both upsides and downsides. And in the world of apps where word-of-mouth and first impressions are *everything* those downsides can be significant.

      Then you come with a trivial example for GUI/core interaction. Using a "pocket calculator" is extremely brain dead as it has nothing which a GUI on it. The calculator would look and feel exactly the same with ANSI Text "GUI"s calling a bunch of buttons and a single text field a GUI is joke at best and idiotic at worse.

      Simple examples often convey an idea more simply. The fact remains that in this core c/c++ code links to an iOS GUI, an Android GUI, and Linux console apps for regression testing and fuzzing. From the core code's perspective it has no idea whether a human user is driving it from a GUI or it is being driven from a script and is running on a headless Linux box in the closet for automated testing.

      Plus this simple example also illustrates that even for a simple app if your UI code is more than half the program you may be doing something terribly wrong.

      I suggest to port a CAD or CASE application or at least a simple drawing application from Windows to a Mac ...

      Actually I once led a team doing chemical diagraming and molecular modeling and visualization software. We used the same technique of minimizing the UI code and creating a c/c++ api representing primitive user interactions. Mouse up/down/move, button up/down, keyboard key up/down, etc. This again allowed scripting from a Linux console app. For example the selection of a chemical bond drawing tool followed by a series of mouse down/move/up actions that create a carbon ring. Such automation is very helpful to testing. It also allows the code to be easily run on various hardware targets. The core code, the actual functionality behind diagram and molecular model creation based on user actions, could be tested and debugged in parallel to the development of a GUI for a new platform.

      ... and then do the same with QT. Nothing to port in the later case, and nothing to notice any difference from your manual port before. Only the most keen eyes might spot a different pixel somewhere when you use a special GUI element to show case a portability issue.

      Actually when going between iOS and Android it does not take a keen eye. There is often a user expectation of platform specific functionality. Least common denominator designs often suffer in user evaluations. Its a fact of life for apps that depend on word of mouth and first impressions rather than a marketing department selling to corporate clients.

    4. Re:One-size-fits-all, a way to sabotage your app by macs4all · · Score: 1

      I suggest to port a CAD or CASE application or at least a simple drawing application from Windows to a Mac, and then do the same with QT. Nothing to port in the later case, and nothing to notice any difference from your manual port before. Only the most keen eyes might spot a different pixel somewhere when you use a special GUI element to show case a portability issue.

      Bzzzt, WRONG! Thanks for playing!

      I spoke at length (over email) with the then-Developer for EaglePCB (he unfortunately finally sold-out...), about his experiences with porting his CAD/CAE PCB layout, schematic capture, and simulation-suite to OS X.

      He paid for the then-pretty-damned-expensive Qt development licensing. IIRC, spent over a year trying to rewrite his PCB layout application (which had some tricky layering stuff to do) in Qt, and finally gave up, electing to START OVER using OS X-native drawing APIs (Quartz?).

      He said it was a nightmare in Qt to try an do the things he was needing to do in his PCB layout app, and was basically kind of feeling ripped-off by whoever it was that owned Qt at the time (around 2003 or so).

    5. Re:One-size-fits-all, a way to sabotage your app by angel'o'sphere · · Score: 1

      Sorry, you are simply wrong regarding Qt.

      And obviously everyone with the minimalst experience in software engineering is separating the UI from the "core" in the same way as you suggest.

      Nevertheless half of a real GUI heavy application is GUI code. No idea how you come to the idea that your chemical bonding app uses significantly less than 50% in the GUI.

      Your idea that portable GUI code is not possible is minimum 35 years outdated.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    6. Re:One-size-fits-all, a way to sabotage your app by angel'o'sphere · · Score: 1

      Then he should have asked me.

      I ported a CAD environment to Qt in about 3 months (from zApp).

      There is nothing particular difficult to do that unless the original code is already idiotic.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    7. Re:One-size-fits-all, a way to sabotage your app by macs4all · · Score: 1

      Then he should have asked me.

      I ported a CAD environment to Qt in about 3 months (from zApp).

      There is nothing particular difficult to do that unless the original code is already idiotic.

      He had some sophisticated visual layering that he was very particular about. As I said, this was a PC Board Layout package, and so not "hidden line".

      Not all "CAD" is the same.

    8. Re:One-size-fits-all, a way to sabotage your app by Anonymous Coward · · Score: 0

      I spoke at length (over email) with the then-Developer for EaglePCB (he unfortunately finally sold-out...), about his experiences with porting his CAD/CAE PCB layout, schematic capture, and simulation-suite to OS X.

      This experience sounds highly dubious but I'll give you the benefit of the doubt: What specifically were some of the technical problems that could not be overcome with Qt but could be done with Quartz? I know you have said "sophisticated visual layering" but what exactly was the insurmountable problem?

    9. Re:One-size-fits-all, a way to sabotage your app by perpenso · · Score: 1

      Nevertheless half of a real GUI heavy application is GUI code. No idea how you come to the idea that your chemical bonding app uses significantly less than 50% in the GUI.

      Perhaps I am not being clear. When I am referring to GUI code I am referring to the platform specific GUI API (iOS, Android, Mac OS, Windows, etc). Actually I am referring to all the platforms specific code be it graphical or not. I am contrasting that with portable c/c++ code that implements functionality. This functionality includes graphics, interpreting user events, translating this into desired actions in the program, etc. The platform specific code generally takes the platform specific events, coordinate systems, etc and converts that to internal normalized portable counterparts that the core code uses. The core code is doing "event" and "graphics" work. The handling of platform specific events and translating to the internal events is a minor portion of the overall work. A minor portion to replicate per platform.

      My line for GUI code is the platform specific API, not what code deals with events or graphics. Perhaps I would have been clearer if I had said that if 50% of your code is platform specific you are doing it wrong.

      Where some people get the wrong impression is when an app is written with only one target in mind. For example MS Windows. In such cases it is common to see much core functionality implemented directly in the code interfacing with the Windows API. Similar story if something like QT is being used. What appears to be GUI code gets bloated with core functionality.

      Your idea that portable GUI code is not possible is minimum 35 years outdated.

      You are confused, no one said it is not possible. What is being said is that it puts a modern app at a competitive disadvantage in the market. In particular the modern app market where first impressions and word of mouth is critical. An absolutely native look and feel is essential today, as is the expected platform specific functionality. Things have changed radically with the move to iOS and Android. And the desktop specific app stores are helping to replicate such consumer expectations for Windows and Mac desktop apps.

    10. Re:One-size-fits-all, a way to sabotage your app by macs4all · · Score: 1

      I spoke at length (over email) with the then-Developer for EaglePCB (he unfortunately finally sold-out...), about his experiences with porting his CAD/CAE PCB layout, schematic capture, and simulation-suite to OS X.

      This experience sounds highly dubious but I'll give you the benefit of the doubt: What specifically were some of the technical problems that could not be overcome with Qt but could be done with Quartz? I know you have said "sophisticated visual layering" but what exactly was the insurmountable problem?

      No, it really happened, back in 2003-4 timeframe (which is also why I can't remember every detail, sorry!)

      All I can remember was that it was along the lines of having trouble with displaying multiple transparent layers (PCB Layout, remember?), and having it "look right" when stuff on one layer overlapped stuff on another layer(s).

      If it helps, he HAD previously done an OS X port of his software that ran under X11 on OSX (see history here), and so had access to whatever that graphics environment! as realized on a Mac.

      I was doing embedded development at that time, and so only had a "user-level" knowledge of what the issues were; but that's about as much detail as I can get my brain to disgorge, after about 12 years...

    11. Re:One-size-fits-all, a way to sabotage your app by Anonymous Coward · · Score: 0

      All I can remember was that it was along the lines of having trouble with displaying multiple transparent layers (PCB Layout, remember?), and having it "look right" when stuff on one layer overlapped stuff on another layer(s).

      That certainly sounds like an error on the part of the developer since even back then you always had access to the underlying fixed function blend functions in OpenGL to control this exact behavior regardless of whether you were using Qt or Quartz. But by 2003/2004 we had even had programmable graphics for years where you do this explicitly yourself, the toolkit is completely disinter-mediated. So either the problem you have described was not the problem he had or if it was then it means that without a doubt he was doing it incorrectly.

      Point is anecdotal evidence about somebody you knew who had a problem you don't remember that seems to run contrary to the actual details of implementation is not particularly convincing.

    12. Re:One-size-fits-all, a way to sabotage your app by angel'o'sphere · · Score: 1

      Sorry, my CAD software also supports layers :D

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    13. Re:One-size-fits-all, a way to sabotage your app by angel'o'sphere · · Score: 1

      What is being said is that it puts a modern app at a competitive disadvantage in the market.
      And Qt on iOS gives you that. You don't notice any difference. Hence your argument is simply wrong.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    14. Re:One-size-fits-all, a way to sabotage your app by perpenso · · Score: 1

      What is being said is that it puts a modern app at a competitive disadvantage in the market. And Qt on iOS gives you that. You don't notice any difference. Hence your argument is simply wrong.

      Numerous users of QT based apps say otherwise. Even when QT is using native widgets instead of emulating them.

      Plus there is the whole issue of platform specific functionality and features that QT does not support.

    15. Re:One-size-fits-all, a way to sabotage your app by angel'o'sphere · · Score: 1

      Well,

      if you believe that ... your problem.

      I happy code for Qt and happy use Qt based apps.

      I never heard about a complaint.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    16. Re:One-size-fits-all, a way to sabotage your app by perpenso · · Score: 1

      The author of the app would rarely hear a complaint. They may see a download of a free app. What they wouldn't see is the uninstall or lack of use of the app and the competitor's app that gets downloaded as an alternative.

      Who would hear about an app that didn't look or feel "right", or that lacked expected platform specific functionality? That would be friends, coworkers, classmates, etc. Rarely the author. As I said, its word of mouth that makes or breaks apps.

  27. Unchanged? by Wdomburg · · Score: 1

    "a landscape which has been little changed since the 1990s."

    What? Did the author miss the birth and ascent of C# and subsequent waning popularity of C++? A little something called Go, which just broke into the top 20 languages in the RedMonk index. The crawl from obscurity of Objective C after the release of MacOS X, and later iOS? The evolution of Javascript from a way to make rollover buttons to an application and backend platform? The collapse of perl and the rise of Python and Perl? The emergence of functional languages like Scala, Erlang and Haskell as viable platforms? The growth of R for statistical analysis? Lua for extension? New data query languages like SPARQL, Gremlin and CQL?

    As usual, Apple is not the pioneer here. They are treading a path broken by many others.

    1. Re: Unchanged? by Anonymous Coward · · Score: 0

      apple and mozilla are blasting a path out of the snake pit of cyberspace.

      while all others feel well with the snakes. stop fudding.

    2. Re: Unchanged? by Anonymous Coward · · Score: 0

      apple and mozilla are blasting a path out of the snake pit of cyberspace.

      while all others feel well with the snakes cultivated by bell labs. stop fudding.

    3. Re: Unchanged? by Wdomburg · · Score: 1

      You make a compelling argument. For what, I have no idea.

    4. Re:Unchanged? by Anonymous Coward · · Score: 0

      The collapse of perl and the rise of Python and Perl?

      So, perl got an uppercase "P" ?

      At least, C is still where it was in the 1990s.

  28. A better PL, a good Swift Book for free, ... by Qbertino · · Score: 1

    A better PL, a Swift Book for free, a working pipeline with free (beer) tools ready to roll from day one and no-bullshit support for all the things the predecessor (Obj-C) supported.

    That's all it takes to bring a new PL front and center for more than 1 week.
    Apple knows how to build user experiences and that includes developers on their machines. ...

    Now if only every software technology would take care of things the way Apple does and not promise things their toolkit can't hold for longer than a download and a first tryout.

    --
    We suffer more in our imagination than in reality. - Seneca
  29. Looked at it. Dismissed it. by bytesex · · Score: 1

    A new language without support for regex literals is worthless to even consider.

    --
    Religion is what happens when nature strikes and groupthink goes wrong.
    1. Re:Looked at it. Dismissed it. by shutdown+-p+now · · Score: 1

      If you're using regex often enough that you need syntactic sugar for them (and the language in question has raw string literals to avoid unnecessary escaping), then you're the problem.

    2. Re:Looked at it. Dismissed it. by iluvcapra · · Score: 1

      You can actually add Regex literals to Swift at compile time with a type extension and a type annotation.

      --
      Don't blame me, I voted for Baltar.
    3. Re:Looked at it. Dismissed it. by shutdown+-p+now · · Score: 1

      So far as I can see, it's not quite the same - it basically lets you define arbitrary implicit conversions, but it doesn't make the literal itself a regex (so you can't call methods directly on it, say).

  30. Re:What methods "see if you have a single referenc by Anonymous Coward · · Score: 0

    And the result is that you produce garbage on all platforms. Sorry, but the cross platform toolkits get you nothing more than a moderately broken lowest common denominator as your user experience.

  31. Re:It's the faggot equation by macs4all · · Score: 1

    Absence of children = more disposable income.

    If that's a weak attempt at an "Apple == Gay" joke, just remember that over 60% of Gay men have biological children, and if you factor in adoptive kids, it's likely in the 80%+ world these days.

    So stick that knobby-stick up your ass and twist.

  32. Re:What methods "see if you have a single referenc by Anonymous Coward · · Score: 0

    Have you got a couple of actual shipping comparisons? not suggesting they're written by you but it should be easy for you to find some if the difference in experience is so obvious.