Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Open Source Programming Apple

Why Apple Should Open-Source Swift -- But Won't 183

snydeq writes: Faster innovation, better security, new markets — the case for opening Swift might be more compelling than Apple will admit, writes Peter Wayner. "In recent years, creators of programming languages have gone out of their way to get their code running on as many different computers as possible. This has meant open-sourcing their tools and doing everything they could to evangelize their work. Apple has never followed the same path as everyone else. The best course may be to open up Swift to everyone, but that doesn't mean Apple will. Nor should we assume that giving us something for free is in Apple's or (gasp) our best interests. The question of open-sourcing a language like Swift is trickier than it looks."
This discussion has been archived. No new comments can be posted.

Why Apple Should Open-Source Swift -- But Won't

Comments Filter:
  • I disagree (Score:5, Insightful)

    by bazmail ( 764941 ) on Tuesday September 16, 2014 @02:49AM (#47915627)
    If Apple doesn't want the help of the OSS community then forget 'em.

    Why bother crying and begging them to allow you to strengthen their products? If you want to work on Swift then send your resume to Apple.
    • Or create a free reimplementation. I don't know if there's anything going on there but I know there have been talks about it in the GNUstep community.

    • If Apple doesn't want the help of the OSS community then forget 'em.

      There is this part of the open source community that is quite willing to help - but requests that for their help, you are effectively losing control over your own work. That's why Apple dropped gcc. I think they can live without you.

      • by sqlrob ( 173498 )

        And they went running to another Open Source compiler. Your point?

      • by tlhIngan ( 30335 )

        There is this part of the open source community that is quite willing to help - but requests that for their help, you are effectively losing control over your own work. That's why Apple dropped gcc. I think they can live without you.

        No, the reason Apple invested a ton of money and development effort in LLVM (it started around 10.4/10.5 when the first Clang/LLVM compiler was offered as an alternative to gcc) was GPLv3.

        Apple was paying very close attention to what the GPL was evolving into, decided they didn'

    • Apple has created a language. And you feel they are not helping the OSS community by giving it to them, right now? That's some sense of entitlement.
    • The real irony here is that, in the meantime, Microsoft has open sourced the entirety of C# and VB.NET compilers.

  • What for? (Score:4, Interesting)

    by joh ( 27088 ) on Tuesday September 16, 2014 @03:20AM (#47915709)

    There's no shortage of programming languages. Swift isn't anything special. It mostly has value for its integration with Apple's environment and this isn't Open Source either, so what would Swift being Open Source actually be good for? I really can't see why anyone would want to use Swift anywhere than on OS X or iOS when the real value isn't in the language anyway but in the frameworks and the integration with them.

    (And I'm not even saying that Apple's approach is better. It's a different approach and has its own advantages and disadvantages. But if you have a closed system using its advantages makes more sense than trying to square the circle.)

    • Re:What for? (Score:5, Interesting)

      by TheRaven64 ( 641858 ) on Tuesday September 16, 2014 @03:30AM (#47915739) Journal

      I maintain the GNUstep / Clang Objective-C stack. Most people who use it now do so in Android applications. A lot of popular apps have a core in Objective-C with the Foundation framework (sometimes they use GNUstep's on Android, more often they'll use one of the proprietary versions that includes code from libFoundation, GNUstep and Cocotron, but they almost all use clang and the GNUstep Objective-C runtime). Amusingly, there are actually more devices deployed with my Objective-C stack than Apple's. The advantage for developers is that their core logic is portable everywhere, but the GUIs can be in Objective-C with UIKit on iOS or Java on Android (or, commonly for games, GLES with a little tiny bit of platform-specific setup code). I suspect that one of the big reasons why the app situation on Windows Phone sucks is that you can't do this with a Windows port.

      It would be great for these people to have an open source Swift that integrated cleanly with open source Objective-C stacks. Let's not forget that that's exactly what Swift is: a higher-level language designed for dealing with Objective-C libraries (not specifically Apple libraries).

      Objective-C is a good language for mid-1990s development. Swift looks like a nice language for early 2000s development. Hopefully someone will come up with a good language for late 2010s development soon...

      • Interesting post! Could you point me towards a github or two of open source apps that are written like that ?

      • Re:What for? (Score:4, Interesting)

        by K. S. Kyosuke ( 729550 ) on Tuesday September 16, 2014 @06:13AM (#47916095)

        Hopefully someone will come up with a good language for late 2010s development soon...

        Well, there's always ClozureCL with its Objective-C bridge. :D

      • This is the best post I've seen on /. in five years. No further comment.

      • The advantage for developers is that their core logic is portable everywhere, but the GUIs can be in Objective-C with UIKit on iOS or Java on Android (or, commonly for games, GLES with a little tiny bit of platform-specific setup code).

        How is this an advantage to anyone who plans ahead? I suppose if you wrote your original application in Objective-C and weren't thinking about cross platform support, then fine. But if you're planning on supporting both platforms why don't you just go completely cross platform and use C? Objective-C sucks. Swift fixes a lot of its problems but the syntax is a bit odd to me. And I've been writing iOS applications for the last 3 years, it's not like I haven't used Obj-C at all.

        • by Kjella ( 173770 )

          How is this an advantage to anyone who plans ahead? I suppose if you wrote your original application in Objective-C and weren't thinking about cross platform support, then fine. But if you're planning on supporting both platforms why don't you just go completely cross platform and use C?

          Because C.

          • How is this an advantage to anyone who plans ahead? I suppose if you wrote your original application in Objective-C and weren't thinking about cross platform support, then fine. But if you're planning on supporting both platforms why don't you just go completely cross platform and use C?

            Because C.

            Obj-C isn't any better than C in my opinion. But, to each their own.

            • by dgatwood ( 11270 )

              Obj-C isn't any better than C in my opinion. But, to each their own.

              It is if you're doing any nontrivial amount of string manipulation.

              • Obj-C isn't any better than C in my opinion. But, to each their own.

                It is if you're doing any nontrivial amount of string manipulation.

                Well okay you do have me there. Strings are much easier to manipulate in obj-c.

      • by LoRdTAW ( 99712 )

        I am a bit curious. How is the objective-c compiled and ran on Dalvik? Are you doing: objective-c -> LLVM -> dalvik bytecode?

        Is the project you speak of Apportable?

        • How is the objective-c compiled and ran on Dalvik? Are you doing: objective-c -> LLVM -> dalvik bytecode?

          It isn't. It runs natively via the NDK.

    • by tlambert ( 566799 ) on Tuesday September 16, 2014 @07:56AM (#47916599)

      One thing Swift will address... There are currently 3 memory management models in use in Objective-C, and for some of those models, you don't get a retain count automatically (for example, this is the case for a number of collection objects when doing an insertion).

      Swift has the opportunity to rationalize this, which is not something you could do with the Objective-C libraries themselves, since doing so would change historical APIs and thus break old code.

      It wasn't really until Metrowerks basically became incompatible with the Intel switchover and the 64 bit support had to drop certain types of support from Finder due to 64 bit inode numbers, and while I happily would have made them new header files so that they would have continued to work with the UNIX Conformance work, where Ed Moy and I basically broke their local private copies of their header files, since Motorola sold off the Intel version of the Metrowerks C the week because Apple announced Intel, it was pretty much DOA at that point.

      So it basically took an Act Of God to get some people to get the hell off some of the old APIs we had been dooming and glooming about for half a decade.

      Swift is another opportunity for that type of intentional non-exposure obsolescence to clean up the crappy parts of the APIs and language bindings that haven't been cleaned up previously due to people hanging onto them with their cold, dead hands. Hopefully, they will advantage themselves of this opportunity.

  • by Anonymous Coward on Tuesday September 16, 2014 @03:53AM (#47915811)

    Many click-bait, shit posts come from snydeq and they all link to how-is-it-still-in-business-rag InfoWorld.

    I know Slashdot hasn't tried in years, but damn, there are interesting stories out there that can produce good discussion.

  • by SuperKendall ( 25149 ) on Tuesday September 16, 2014 @04:06AM (#47915837)

    Whoever wrote that article doesn't understand Swift well, or Apple for that matter:

    Swift is designed to support a world built bottom up in Objective-C. It's meant to play well with the bazillion lines of existing Objective-C, not supplant it.

    This is totally wrong. Apple could not be more clear that Swift is built to supplant Objective-C. It will take a while to re-write the frameworks but they are encouraging everyone now to write new stuff in Swift, and as rapidly as possible making the bridge over to the Objective-C frameworks as Swift friendly as possible.

    I think Apple will not open Swift at the moment because they want to have a small core group directing where the language goes, at least at first... and then it will open up more from there. But that also supports the notion that swift is not an auxiliary language, but the primary path going forward.

    • by disambiguated ( 1147551 ) on Tuesday September 16, 2014 @05:48AM (#47916019)
      You're both wrong/right. In order to supplant Objective-C, Swift would have to play well with the bazillion lines of Objective-C, and coexist with it for possibly a very long time. On the other hand, even if Apple "could not be more clear" that swift is built to supplant Objective-C, that doesn't mean it will succeed, and doesn't mean Apple won't change their mind. It's a gamble and they certainly know it. They keep that to themselves in order to encourage you to drink the cool-aid.

      See also: Microsoft and .NET
    • "We have no plans to do anything like that. Swift is a new option for developing on the platform. We have no plans to drop C, C++ or Objective-C. If youÃ(TM)re happy with them, please feel free to keep using them."

      https://lists.apple.com/archiv... [apple.com]

      "Swift is Apple's modern, type-safe language for Cocoa development But Objective-C remains a first-class citizen too"

      http://devstreaming.apple.com/... [apple.com]

      Seems like it's not meant to supplant but to live alongside it.
      • Go back to 2002 or so and s/Objective-C/Java. They're committed for the time being, but if they see people switching to Swift uniformly they'll dump Obj-C like a bad habit.

        • by dgatwood ( 11270 )

          They won't see people switching to Swift uniformly. There are trillions of lines of code written in Objective-C, and programmers already know it and are comfortable with it. There are no tools for migrating code from Objective-C to Swift, much less the hodgepodge of mixed C, Objective-C, and sometimes C++ that quite frequently occurs in real-world apps, so for the foreseeable future, you'd end up just adding Swift to your existing apps, which means you now have three or four languages mixed in one app ins

    • This is totally wrong. Apple could not be more clear that Swift is built to supplant Objective-C.

      Right now a problem with Objective-C is that it exists on top of C. For an experienced C or C++ programmer that's no problem. But for someone who is learning Objective-C as their first and only language, there are some very strange things going on. They are all quite logical if you know C or C++, but not at all if you don't.

      That's one thing that Swift gets rid of. There is nothing that is weird for historical reasons. (There are things that look weird to the C programmer though). Another thing that's gon

  • by Qbertino ( 265505 ) <moiraNO@SPAMmodparlor.com> on Tuesday September 16, 2014 @04:45AM (#47915907)

    What I respect about Apples Swift (not to be mistaken for the other PL Swift [swift-lang.org]) is that it/Apple doesn't claim Swift to be anything other than it actually is. An improvement on PLs already exisiting in Apples Ecosystem tailored *specifically* for developing in that ecosystem, catering to the preferences and addressing the pet peeves of their developer community. AFAICT with no downsides and measurable upsides if you intend to develop native iOS Apps exclusively.

    *This* all IMHO is a new lock-in PL done right - as far as you can do those right.
    contrary to all the lies, damn lies and hideous marketing bullshit that went into the .Net/C# mess.

    Apple did it right again in the way that they actually let the engineers take care of the language, the designers layout a nice free iBook on it and basically kept marketing out of it. ... Not that Apples marketing is really that bad.

    If I ever do native iOS development and embrace the golden cage, I might even look into it - the syntax does look less scary than that of the classic C family.

    My 2 cents.

    • My main issue is we are entering a post desktop world. (No the desktop isn't dyeing, but it isn't the center of our computing world)
      So we need the following.
      1. A platform to create moble apps.
      2. Being able to create these apps on different systems.

      It is actually very lame to have to have a Mac to build an iOS app. You really should be able to do it on at least the Big three OS Windows,Mac,Linux. Because we are not desktop centrist anymore and people will go around with different Desktops and OS's freely.

  • It took a vengeful God to confound the languages of man the first time around. This time around we have gone into do it ourselves mode as everyone who wants to either segment markets, is too lazy to improve an existing language, or just wants a monument to their ego creates a new language.

    Swift is little more than a potential attractive nuisance and it's hardly in Apple's (The great creator of attractive nuisances) to open source it. They want it to become as popular as possible without becoming universal.

    • by washort ( 6555 )
      Wow. You like Objective-C that much?
    • Other problems:

      1) The Swift compiler is buggy. A language with compiler bugs is painful to use.
      2) Locked in to a single platform.
      3) Apple has a habit of eliminating support for languages/tools on a whim.

      I would be very careful before dedicating resources to Swift.
      • Well doesn't Objective C lock a developer into a single platform? Where else are these iOS apps going to run without a recompile and platform dependencies?

        Is the Java based Android running apps on other platforms like iOS or Microsoft's?

        The Open Phone platform is either low performance apps with middleware, or a Unicorn parade. I do see that you should be careful of lockin -- but isn't everyone already locked in anyway?

        • Well doesn't Objective C lock a developer into a single platform?

          No, there's been an open source implementation of OpenStep (the real name of Cocoa) for decades. Some of the platform stuff is Apple specific, but that is true of Linux and OpenBSD as well. You can handle it the same way you handle any other platform incompatibility: encapsulate the incompatibility into as small a piece as possible.

          Believe it or not, you can actually compile Objective-C code for Android and run it. Of course, you will have to recompile it, but that's not an issue when you have the source

    • Your choice on iOS is javascript + HTML, Objective C, or using some third party like Unity. The iOS has been able to eke out an advantage over other phones for battery life and the ability to run large games ONLY BECAUSE they forced this "writing to hardware" with Objective C.

      Objective C is difficult and the other options are for low performance apps that are little more than cobbled web pages.

      The need for Swift is great, and I've been using it to jump back into programming; it is well thought out and strai

  • Half of it doesn't make sense and the rest is factually inaccurate. For instance, Apple won't open-source Swift because people don't want to buy cheap iPad clones? Huh? The foundation of Swift began in the open-source world? Nope.

    Any article like this that doesn't mention Apple are the primary driving force behind the open-source LLVM/Clang tools is missing a big part of the puzzle. Apple have a track record of working on this sort of stuff openly once it gets to production quality.

  • Yes, I am an Apple fanboy and use their stuff. But, I find that Apple is just as guilty as Microsoft in "embrace, extend, and close" They essentially did this with Darwin. Sure their are parts of Darwin that are open source but a lot of the add on stuff is closed up. I would think it would be advantageous for Apple to open Swift up.
  • Swift is a programming language. Anyone can write a different compiler for it. Open sourcing Apple's LLVM frontend would be nice, but is not required.
    If it's not open sourced and no one does a Swift implementation, we'll be exactly in the same situation as before. You had to write Java for Android and Objective C for iOS. Now you'll have to write Java for Android and Swift for iOS. I fail to see how that changes anything, except Swift being slightly less annoying thatn ObjC.

    90% of the article serves to show

    • You can write iOS and Android code in any language, as long as you port the runtime and package it with your application. On iOS HTML5 and JavaScript e.g is popular, but so is Qt and C++.

"How to make a million dollars: First, get a million dollars." -- Steve Martin

Working...