Slashdot Mirror


Objective-C Use Falls Hard, Apple's Swift On the Rise (dice.com)

Nerval's Lobster writes: When Apple rolled out Swift last summer, it expected its new programming language to eventually replace Objective-C, which developers have used for years to build iOS and Mac OS X apps. Thanks to Apple's huge developer ecosystem (and equally massive footprint in the world of consumer devices), Swift quickly became one of the most buzzed-about programming languages, as cited by sites such as Stack Overflow. And now, according to new data from TIOBE Software, which keeps a regularly updated index of popular programming languages, Swift might be seriously cannibalizing Objective-C. On TIOBE's latest index, Objective-C is ranked fourteenth among programming languages, a considerable drop from its third-place spot in October 2014. Swift managed to climb from nineteenth to fifteenth during the same period. "Soon after Apple announced to switch from Objective-C to Swift, Objective-C went into free fall," read TIOBE's text accompanying the data. "This month Objective-C dropped out of the TIOBE index top 10." How soon until Swift eclipses Objective-C entirely?

161 comments

  1. Pretty quickly by SuperKendall · · Score: 5, Interesting

    Apple has done great job of interoperability with Objective-C, making it pretty easy to write new code or port small portions of an existing program...

    They've even gone so far as to add improvements to Objective-C which are nice, but whose primary reason for existing is that Objective-C code is even easier (and better typed) when accessed from Swift.

    At this point there's no reason not to do anything new in Objective-C, and port what you can when it makes sense.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:Pretty quickly by Darinbob · · Score: 5, Interesting

      Objective-C though seemed relegated to a very tiny number of systems. Not as tiny as C# of course. Overall a lot of things start feeling like the 1970s all over again, with each major player having their own language, so choice of favorite language coincides with choice of favorite system. I much prefer cross-system languages.

    2. Re:Pretty quickly by Anonymous Coward · · Score: 0

      Yes, so forget about Objective C. Learn this new language Swift. And when you are comfortable with that, throw it all away and learn this new proprietary language we are developing now.

    3. Re:Pretty quickly by SuperKendall · · Score: 5, Informative

      Well, Swift should be cross-platform pretty shortly since they are releasing it as open source (including standard libraries) in a month or two.

      Objective-C was more cross-platform than you might think, people have used it for server development in the past. Even now it's used for both really popular desktop and mobile apps, which a decent range.

      --
      "There is more worth loving than we have strength to love." - Brian Jay Stanley
    4. Re:Pretty quickly by phantomfive · · Score: 1

      At this point there's no reason not to do anything new in Objective-C, and port what you can when it makes sense.

      I really am not sure what you meant by that sentence.

      --
      "First they came for the slanderers and i said nothing."
    5. Re:Pretty quickly by Anonymous Coward · · Score: 0

      Objective-C though seemed relegated to a very tiny number of systems. Not as tiny as C# of course.

      That's a good troll you've got there. It'd be a shame if something happened to it... (Like this showing that Obj-C is available for approximately 8% of desktop systems, while C# is available for approximately... let's see... all of them. *cough*Mono*cough* The same would hold true for mobile devices, and for similar reasons. *cough*Xamarin*cough*)

      Nice try, though.

    6. Re:Pretty quickly by MightyMartian · · Score: 2, Insightful

      Except Mono sucks.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    7. Re:Pretty quickly by Darinbob · · Score: 3, Insightful

      These are open source of course (Objective-C is a part of GCC too). But practically speaking it will stick to being an Apple specific tool.

    8. Re:Pretty quickly by ottothecow · · Score: 1
      I much prefer cross-system languages.

      You can't even write Swift cross-system. Even though you may be writing an app for a phone, you are forced to do your dev work on a Mac (unless you want to resort to stupid solutions like renting a machine that you can remote desktop in just to write code).

      --
      Bottles.
    9. Re:Pretty quickly by phantomfive · · Score: 2

      Objective-C comes free with GCC, so it basically runs on everything.

      Availability doesn't seem to matter....they're both mainly used on a small subset of devices, for a small subset of projects.

      --
      "First they came for the slanderers and i said nothing."
    10. Re:Pretty quickly by jcr · · Score: 4, Funny

      Yeah, can't really avoid that when you set out to emulate a Microsoft product...

      -jcr

      --
      The only title of honor that a tyrant can grant is "Enemy of the State."
    11. Re: Pretty quickly by Anonymous Coward · · Score: 0

      That is incorrect. I suggest you check out Silver from RemObjects. It is a cross platform implementation of Swift and they also provide an IDE.

    12. Re:Pretty quickly by mattack2 · · Score: 1

      You can't even write Swift cross-system. Even though you may be writing an app for a phone, you are forced to do your dev work on a Mac

      Since a Mac != a phone, you are BY DEFINITION already writing Swift cross-system.

    13. Re:Pretty quickly by shoor · · Score: 1

      At this point there's no reason not to do anything new in Objective-C, and port what you can when it makes sense.

      I really am not sure what you meant by that sentence.

      Me neither. If you removed the word 'not', it would make sense, and maybe it's what the OP meant to write, but he or she got a little careless with the editing (can happen to anybody). But that's just a guess on my part.

      --
      In theory, theory and practice are the same; in practice they're different. (Yogi Berra & A. Einstein)
    14. Re:Pretty quickly by SuperKendall · · Score: 1

      After some thought I realized should have put "Swift" in where I put "Objective-C", hopefully that clarifies things. When I read it I just read it as Swift since that is what I meant...

      --
      "There is more worth loving than we have strength to love." - Brian Jay Stanley
    15. Re:Pretty quickly by phantomfive · · Score: 1

      Cool thx

      --
      "First they came for the slanderers and i said nothing."
    16. Re:Pretty quickly by Anonymous Coward · · Score: 0

      I got into Objective C because of swarm agent based modelling running on Windows/cygwin.

    17. Re:Pretty quickly by Anonymous Coward · · Score: 0

      Except the Arduino.

    18. Re:Pretty quickly by Anonymous Coward · · Score: 0

      You probably haven't used Mono in a very long time, if ever.

    19. Re:Pretty quickly by Pieroxy · · Score: 1

      There is still a swarm of NotImplementedException going around. Most of C# is running, at a much slower speed than .Net4.5, but there are still APIs that are just not there or terribly buggy.

      Try running IIS in Mono, and we'll talk again.

    20. Re: Pretty quickly by jhoger · · Score: 1

      Why would you run IIS on Mono?

    21. Re:Pretty quickly by Anonymous Coward · · Score: 0, Flamebait

      And Microsoft has already released a bridging product (called Bridge for iOS, no less.)

      As for OBJC, is theoretically better than C++, at least as far as how objects are represented. OBJC probably would have supplanted C++ had MacOS X replaced MacOS in 1995 instead of 2001. C++ never standardized until 1998, despite being used since 1983. That tells you quite a lot about how hard it is to learn and use. OBJC also appeared in 1983, having some inspiration from Smalltalk (and that wasn't the only thing inspired by Smalltalk, the Sierra game SCI (Sierra Creative interpreter) circa 1988 ALSO was inspired by Smalltalk.)

      Swift takes this to a more logical conclusion and removes some of the harder to understand material from what would otherwise still be OBJC.

      In comparison C# (eg C++++) is more of a watered down C++ and accomplishes some similar things Swift does with OBJC.

      So it's possible to compile C# or Swift into native code, not relying on a CLR or VM. And as long as no virtualmachine-like runtime is required on the operating system (ugh... geez the amount of runtimes on Windows) that means a software item can be packaged up and run on any operating system. The underlying GUI system is obviously not going to be the same on all operating systems.

    22. Re:Pretty quickly by DrXym · · Score: 2

      Except Mono sucks.

      The main reason Mono sucks is not the effort put into it, but the thought it was a good idea in the first place. While .NET is theoretically portable most real world .NET applications make assumptions about the platform they're running on, e.g. using MS SQL server adapters, or calling some native DLL or another, or Windows.Forms, or ASP.NET. So lots of .NET software simply will never run on Mono and even that which can might require significant changes - it's not write once, run anywhere or anywhere close to that. And of course Microsoft can lead the platform wherever they like and have demonstrated that all too often.

      That said, Mono has proven itself useful in one niche - the Unity toolkit uses the mono runtime as its scripting framework. It succeeds here because Unity is its own closed little world with its own APIs so it doesn't have to care about supporting some random assembly or esoteric feature.

    23. Re:Pretty quickly by angel'o'sphere · · Score: 1

      There are third parties offering cross platt form Swift compilers: http://www.remobjects.com/ (no idea why their name is so wiered and why they are so hard t googl, oops might ebcause I used bing by accident)

      The stuff they offer is quite interesting.

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

      Yeah, c# is available on virtually every platform out there. You can make your fibonacci number program run on a great variety of hardware.

      However, when you want to make something useful, you have to restrict your platform to a single one.

    25. Re:Pretty quickly by AmiMoJo · · Score: 1

      C# is available on the vast majority of "desktop" operating systems, i.e. Windows. Okay, there is Mono, but C#'s real strength is in the vast number of .NET libraries and frameworks available, many of which are Windows only or not supported on Linux.

      While programmers like cross-platform languages, users hate them. They want native apps that look and act the same as other native apps on their platform of choice. Java was one of the worst examples of this, with Java apps using their own custom GUIs and being extremely slow for many years. GUI frameworks have got better now, just in time for mobile to come along and cause another rift between native desktop/mouse/keyboard and mobile/touch.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    26. Re:Pretty quickly by jittles · · Score: 1

      Apple has done great job of interoperability with Objective-C, making it pretty easy to write new code or port small portions of an existing program...

      They've even gone so far as to add improvements to Objective-C which are nice, but whose primary reason for existing is that Objective-C code is even easier (and better typed) when accessed from Swift.

      At this point there's no reason not to do anything new in Objective-C, and port what you can when it makes sense.

      My company does a lot of contracting work for other companies. So far the only client that has even asked us about Swift is Apple. It seems that Apple wants us to do everything in Swift now and everyone else prefers we stick to Objective-C. I can tell you the reason that I don't want to switch to Swift is that I think the syntax is horrific. My eyes want to bleed every time I look at something in Swift. I'll be honest, though, I don't really like Objective-C syntax either.

    27. Re:Pretty quickly by mrchaotica · · Score: 1

      It's too bad, really; I like C# as a language but I wish the APIs weren't so Microsoft-centric.

      --

      "[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz

    28. Re:Pretty quickly by Wovel · · Score: 1

      I don't think you can name a desktop or server system objective-c is not available for, so your point is what exactly? You seem to think Xcode is the only OBJ-C compiler. You would be wrong...

    29. Re:Pretty quickly by Wovel · · Score: 1

      That makes more sense, but is still wrong since there are already Swift implementations on other platforms. It is not as ubiquitous as Objective C, but it has not been around too long..

    30. Re:Pretty quickly by Anonymous Coward · · Score: 0

      It is good for porting XNA apps over to the Win10 platform with very little work. LibGDX is a good alternate to XNA for Android/iOS or Win32 development. They work pretty much the same. Sprite batches, update and draw functions, etc.

    31. Re:Pretty quickly by Anonymous Coward · · Score: 0

      yes it's the native calling that fscked everything up as almost all but the most trivial .net(we'll catch them all) made use of that facility which wasn't supported at all by mono for a long time.

      toss in all the proprietary interfaces, mainly gui and some others, that were largely ignored by mono just made the situation worse for programs that utilized gui.

      to me looking at the table it looks more like a decline in usage of what are realistically apple centric languages, ios/osx.

    32. Re:Pretty quickly by Xabraxas · · Score: 1

      Mono's intention was never to be a conduit for running Microsoft apps. People trash Mono all the time because they don't understand that it is simply an open source implementation of the C# language with it's own hooks into GNOME, etc. There are some compatibility layers present but the project isn't centered around making MS apps work. It's about using the C# language in a Linux environment.

      --
      Time makes more converts than reason
    33. Re:Pretty quickly by luis_a_espinal · · Score: 1

      I much prefer cross-system languages.

      You can't even write Swift cross-system. Even though you may be writing an app for a phone, you are forced to do your dev work on a Mac (unless you want to resort to stupid solutions like renting a machine that you can remote desktop in just to write code).

      What you call a "stupid" solution is actually a pretty good alternative to buying a Mac when you want to do part-time iOS development.

    34. Re:Pretty quickly by Anonymous Coward · · Score: 0

      Objective-C though seemed relegated to a very tiny number of systems. Not as tiny as C# of course.

      What are you smoking?

    35. Re:Pretty quickly by maccodemonkey · · Score: 1

      At this point there's no reason not to do anything new in Objective-C, and port what you can when it makes sense.

      Swift doesn't support interop with C++ code. Swift should not be used in third party closed source libraries due to linker conflicts (even according to Apple.)

      We're not at the point where everything should be Swift yet.

    36. Re:Pretty quickly by Anonymous Coward · · Score: 0

      why would I use it if there is scala already ?

    37. Re:Pretty quickly by Anonymous Coward · · Score: 0

      No, actually there is a lot of reason to avoid swift.. XCode is much more mature and stable with ObjC code and Swift still gives you compiler errors like "expression too complex" for something a fourth grader could figure out in ten minutes. It also frequently complains not just about things like adding doubles to integers, which is arguably a worthwhile error, I've seen it say it doesn't know how to add two doubles. Or two integers. Seriously. Once it's finished, Swift will be a great language. But the compiler needs work.

      Also refactoring doesn't work yet. That needs to be fixed.

  2. Huh? by grub · · Score: 5, Funny


    I just finished a Flash animation course at ITT. Am I too late to the game?

    --
    Trolling is a art,
    1. Re:Huh? by Anonymous Coward · · Score: 0

      I just finished a Flash animation course at ITT. Am I too late to the game?

      ITT Bombay or ITT Madras ?

    2. Re:Huh? by Austerity+Empowers · · Score: 2

      ITT Slashdot.

      He literally finished his course In This Thread.

    3. Re:Huh? by Kjella · · Score: 1

      Yeah that is so last decade, you should look into Silverlight.

      --
      Live today, because you never know what tomorrow brings
    4. Re:Huh? by 140Mandak262Jamuna · · Score: 1

      Come on guys, For computer science, it is Kanpur and it has always been Kanpur.

      --
      sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
    5. Re:Huh? by fyngyrz · · Score: 1

      African, or European?

      --
      I've fallen off your lawn, and I can't get up.
    6. Re:Huh? by darkain · · Score: 1

      "Animation" ...

      A couple hours later, a new flash exploit is publicized (see ./ homepage)

    7. Re:Huh? by Anonymous Coward · · Score: 0

      Bomay, Madras, Shitpur? Yep, the indians are very excellent. If only we were talking about call centers where they talk lousy english... are you sure you are in the right thread? Honestly?

    8. Re:Huh? by Lisias · · Score: 1

      I just finished a Flash animation course at ITT. Am I too late to the game?

      Barrichello? It's you?

      --
      Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
  3. Which is better? by Locke2005 · · Score: 3, Interesting

    I'm not an iOS programmer, which generates more efficient executables?

    --
    I've abandoned my search for truth; now I'm just looking for some useful delusions.
    1. Re:Which is better? by Anonymous Coward · · Score: 0

      In general, Swift. It's not a one way street, but that's mostly because the compiler has not had as long to bake. The language in theory can optimise things much more heavily than obj-c, since it has much more static knowledge.

    2. Re:Which is better? by Anonymous Coward · · Score: 0

      Anyway, I don't get why Swift is even important. What is wrong with Objective-C that it needs to be replaced?

      Progress on a round planet that's why!

    3. Re:Which is better? by Anonymous Coward · · Score: 0

      So, you've never had to debug a null pointer dereference then? Wouldn't you love it if the compiler could prove they never happen (or point them out to you when they do)?

      There's just one small sample of what Swift does that obj-c doesn't.

      For reference though - Swift code is faster than obj-c code thanks to the lack of dynamic dispatch.

    4. Re:Which is better? by Anonymous Coward · · Score: 0

      That and because Apple's versions of Objective-C already emitted much of the same runtime instrumentation, such as NULL pointer checking and garbage collection. It's not like Objective-C had the performance of unadorned C code. All that instrumentation has its costs.

      But with Swift Apple can claw back some of that cost because the typing is more strict. Also, AFAIU Swift uses a pure reference counting GC, whereas in Objective-C it's mark & sweep. Reference counting is faster than mark & sweep.**

      ** Please, don't bother citing the IBM research article showing that they have equivalent costs. If you actually read the paper you'd know the reference counting algorithm they're analyzing _includes_ a global mark & sweep phase in order to catch cyclical references. AFAIU Swift is pure reference counting--faster (fewer ops, better locality) but it means cyclical references can leak memory.

    5. Re:Which is better? by HiThere · · Score: 1

      But does their reference counting break circular lists? I know it can be done, but doing so increases the cost. (And circular lists can maintain multiple pointers to each element, so you really need to check that there are no external references to the clump. And if you do that you're already almost doing a garbage collector.)

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    6. Re:Which is better? by Anonymous Coward · · Score: 0

      I like swift.
      But null pointer dereferences is tracked/proofed with the static analyser for objective-c.

    7. Re: Which is better? by Anonymous Coward · · Score: 0

      This is off base.. Objective-C on Apple platforms is reference counted. It's not a function of the language, as much as it's a function of Apple's base class. (NSObject.)

      Again, on Apple's platforms, Objective-C had a very brief encounter with true Garbage Collection. It was janky, caused performance problems and didn't interact well with many system APIs. Almost no one used it and it was deprecated after about 2 years. The main reason was a better solution was found: Automatic reference counting.

      The compiler analyzes your code and figures out when you should retain and release objects. It then transparently injects the retains and releases into your code when you compile. It's not perfect (you have to manually acknowledge or break cyclical references), but it's a vast improvement over garbage collectors.

      Swift builds on this, but it's still relying on the system framework's base class to implement the retain and release.

    8. Re:Which is better? by Anonymous Coward · · Score: 0

      No, it doesn't. That was pointed out in the asterisked section.

      Swift has weak references for breaking cycles, and sometimes you will need to manually break cycles. But that's why it's so much faster than a mark & sweep collector, not to mention has less latency. (Worse cast latency can be just as bad, but it's encountered less often.) And the places where you get cycles are typically very few--most often in caches.

      It's not much of a burden to fix them, especially with debuggers like Valgrind--anything not deallocated at program exit is probably a leak. I usually code in C on the server side, and I always make sure all of my code cleans up after itself, even global data, because it makes finding leaks so much easier.

      OTOH, _copying_ garbage collectors have the benefit that they can avoid memory fragmentation. Without object copying all general purpose memory allocators can fragment. OTOH, this can be mitigated. And on mobile platforms apps are built to be able to serialize and deserialize their state across different processes, allowing memory fragmentation to be reset.

    9. Re:Which is better? by Dog-Cow · · Score: 1

      The GC has been deprecated for Objective-C for years, and it will be removed in the next version of OS X. The iOS runtime never had it.

      Basically, you are completely ignorant.

    10. Re:Which is better? by Dog-Cow · · Score: 2

      There are zero Objective-C apps written today that use the garbage collector. ARC has been part of ObjC for years, and on iOS, the GC was never available. You've been trolled. Or the Anon Shitface is an ignorant asshole. Either way, your question is meaningless.

    11. Re:Which is better? by Dog-Cow · · Score: 1

      Debugging null pointer dereferences are ridiculously easy in Objective-C. Have you ever written any code that wasn't in BASIC?

    12. Re:Which is better? by Anonymous Coward · · Score: 0

      Most likely Objective-C since it is a valid superset of C and C is one of the go to languages for efficient code. Swift builds on the non C parts of Objective-C, this means reference counting and runtime method dispatch all over the place. The performance hit however should be low enough that you wont care about it most of the time.

    13. Re:Which is better? by jeremyp · · Score: 1

      Objective-C's garbage collection is the same as that in Swift.

      There is also a properly garbage collected memory model, but that is deprecated and will not be supported at all on the next version of OS X.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    14. Re:Which is better? by jeremyp · · Score: 2

      Swift.

      By default Swift objects do not have dynamic dispatch, so method invocations do not have to do the lookup that Objective-C does. However, if you are interacting heavily with Cocoa or Foundation which any UI application has to do, you lose that advantage. There's still some advantage because Swift's optimisation is better than with Clang.

      I wrote a 6502 emulation in C and Objective-C once in which all the performance critical stuff was done in pure C. My port into Swift ran at about a third of the speed which is pretty good I think considering all the safety checking that Swift does that C does not do. A pure Objective-C version would not get close.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    15. Re:Which is better? by Anonymous Coward · · Score: 0

      The language in theory can optimise things much more heavily than X

      I love it when people say that. It means that X will always remain faster but people have nearly indestructible faith in the abilities of the grey-bearded compiler writers.

    16. Re:Which is better? by Dog-Cow · · Score: 1

      How could you possibly have any performance-critical code running a 6502 emulator on modern hardware?

    17. Re:Which is better? by flargleblarg · · Score: 1

      On mobile, everything is performance-critical these days.
      Think wattage, energy, battery, etc.

  4. How soon? by SensitiveMale · · Score: 4, Funny

    "How soon until Swift eclipses Objective-C entirely?"

    I'm guessing swiftly.

    1. Re:How soon? by Anonymous Coward · · Score: 0

      I think this is where I'm supposed to say "I see what you did there".

    2. Re:How soon? by __aaclcg7560 · · Score: 1

      I see what you did there.

      FTFY

    3. Re:How soon? by Anonymous Coward · · Score: 0

      We'll C.

    4. Re:How soon? by fyngyrz · · Score: 4, Funny

      I'm guessing swiftly.

      I don't think you're being objective about this.

      --
      I've fallen off your lawn, and I can't get up.
    5. Re:How soon? by Anonymous Coward · · Score: 0

      I think he or she is - you just don't C it!

  5. Dice spam by grimmjeeper · · Score: 5, Insightful

    Ah, yes. Dice "insights" stating the obvious long after everyone else figured it out.

    1. Re:Dice spam by Virtucon · · Score: 1

      gotta shift them resumes. "We have Swift openings now!"

      --
      Harrison's Postulate - "For every action there is an equal and opposite criticism"
    2. Re:Dice spam by Anonymous Coward · · Score: 1

      But you've got to have at least five years experience of using it.

    3. Re:Dice spam by fyngyrz · · Score: 2

      Sorry, five years experience required.

      --
      I've fallen off your lawn, and I can't get up.
    4. Re: Dice spam by Anonymous Coward · · Score: 0

      H1B candidates have 10 years experience already. It says so on the resume.

    5. Re: Dice spam by fyngyrz · · Score: 1

      Doesn't apply if you have a green card anyway. Or if you just graduated college or are looking for an internship.

      --
      I've fallen off your lawn, and I can't get up.
  6. Objective - Steve is passe by Anonymous Coward · · Score: 1

    sad

  7. How soon until something new eclipses Swift? by Anonymous Coward · · Score: 0

    I want to know. Because I don't want jump ship on COBOL until I know Swift has some staying power!

  8. but does it compile linux? by Anonymous Coward · · Score: 0

    seriously, what compilers run this shit?

    1. Re:but does it compile linux? by frnic · · Score: 1

      Apple is releasing Swift to open source, and is going to provide the language to Linux, so only windows will need to be ported off the open source code.

    2. Re:but does it compile linux? by fyngyrz · · Score: 1

      LLVM :)

      --
      I've fallen off your lawn, and I can't get up.
  9. That was Swift... by __aaclcg7560 · · Score: 1

    But you sill need five years of experience to get called in for a job interview.

  10. Consider all efficiencies by SuperKendall · · Score: 5, Interesting

    At this point the executables are about the same speed between Objective-C and Swift. In reality since anything even remotely heavy you'd be doing will probably use some library or frameworks like Accelerate it hardly matters.

    What does matter though is programmer efficiency, and Swift is pretty useful there. It eliminates a lot of boilerplate or repetitive code, which makes for cleaner looking code all around that is easier to maintain and understand what you were trying to do later.

    Lots of Swift educational materials have done a good job of keeping up with Swift but be aware it's still changing - make sure anything you look into covers at least Swift2.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:Consider all efficiencies by Anonymous Coward · · Score: 0

      I've been really interested in trying Swift, and got a book from the library on it.

      Unfortunately I never got far because Xcode is so GODAWFUL freakin' slow on my machine, a 3-year-old MacBook Pro and I couldn't stand the wait times for compiling... sometimes even waiting for Xcode to redraw its freakin' interface. Bleh. :-P

    2. Re:Consider all efficiencies by Anonymous Coward · · Score: 0

      You will, however, spend a *lot* of time wrapping and unwrapping optional types, which is extremely tedious and pointless.

      Enough already, I wish Apple would just buy MS and use C#. It's mature, it's fast, and the tools are excellent. Say what you want about MS, C# is simply better than Swift.

    3. Re:Consider all efficiencies by Anonymous Coward · · Score: 0

      Obviously a troll. I still have a 3 year-old Macbook Pro, and I do not share you problems. My main gripes with XCode are monitor space, better use it coupled to a big monitor instead on the LCD. On the LCD the letters often can be small.

    4. Re:Consider all efficiencies by Anonymous Coward · · Score: 0

      I wish I were trolling. I'd like to know what you're doing differently, because it's positively painful from where I'm sitting.

    5. Re: Consider all efficiencies by Anonymous Coward · · Score: 0

      Same here, 3 year old MacBook Pro, i7, 16gb ram. Xcode runs and compiles real nice.

    6. Re:Consider all efficiencies by Anonymous Coward · · Score: 0

      Fuck off — you're full of shit. Even a 4-year-old MBA can run Xcode quite well. Compile times for a small program are nearly instant. Larger programs, they're incrementally compiled.

  11. eating Crow by Anonymous Coward · · Score: 1

    as much as I hate to admit it,

    Congrats Apple, Good job..

  12. Apple wins by sanf780 · · Score: 1

    Whichever is more popular, they are mostly to write software for iOS. Apple is the clear winner.

  13. More of an issue about how bad Objective-C is by BenJeremy · · Score: 1, Interesting

    ...than about how good Swift is. Swift is an improvement over Objective-C, but that isn't saying much, and quick adoption also says more about developers fears that Apple will deprecate Objective-C from new iterations of its X-Code and force everybody to use Swift moving forward to new Apple Operating Systems.

    The world didn't need more languages. Developers write millions of lines of code for open-source libraries in multi-platform languages, and Apple and Google get into a dick-waving contest with these languages that add little, if anything, to their corner of the programming world.

    I'm not sure what the right answer is, but it won't be found in a niche language whose sole purpose is to support one company's ecosystem and lock in developers to their platforms.

    1. Re:More of an issue about how bad Objective-C is by Anonymous Coward · · Score: 5, Informative

      You realise that Apple already announced that the Swift compiler is going to be ported to linux and made open source, right?

    2. Re:More of an issue about how bad Objective-C is by Anonymous Coward · · Score: 0

      Actually, the world needs more languages.

      And more so, the world needs to know more about those that exist and those that could exist to fill a use-case that most languages are terrible at. (these usually crop up in specialist fields, or newer fields like AI, mechatronics and so on)

      One thing we need LESS of is catch-all languages.
      Look at C++, that's one hell of a disaster. I don't think I have ever known anyone to like that language if they have been using it over a year.
      It is such a stupidly huge inconsistent mess. It is Windows if it was a programming language.
      What can be done in it can be done in C considerably easier and with less overall code and occasionally even overhead. Objects are easy enough to make in C if you need them. C++ is just 10 kinds of a mess.
      But it is still around, it is still used, because people stick to one corner of it and dare not wander to the deep dark forest and inevitably get lost.

      Languages very specifically tailored for a job are not a Bad Thing, they are a requirement if you actually want to get things done instead of wasting time trying to force a square through a circle.

    3. Re:More of an issue about how bad Objective-C is by Kjella · · Score: 4, Insightful

      I'm not sure what the right answer is, but it won't be found in a niche language whose sole purpose is to support one company's ecosystem and lock in developers to their platforms.

      It's less niche than at least two dozen programming languages /. has hyped as the best thing since sliced bread. Sometimes I feel this place has become a bunch of grumpy old farts who think C and POSIX was the pinnacle of computer science and everything since has just been poorly reinventing the wheel. Or that programming should be for real men who could hand code it in assembly and that high level languages is just another attempt to recreate COBOL or Visual Basic. There's not a whole lot of money in creating programming languages, just ask Sun. And if you don't have widespread adoption, you're never getting off the ground. That's why the OSS community is still trying to create UI apps using 1980s tech, sure Qt is a decent band aid and GTK.... well it's a band aid, but the base language is way behind Java, C# and Swift. Not in what you can theoretically do, but in terms of how easy it is to do it.

      Besides, Microsoft is open sourcing .NET Core, Apple has promised to open source Swift within the end of the year, Java has of course been open a while with the OpenJDK so it seems like the days of the base language being closed source is coming to an end. Of course they all do it with their own platform in mind, but desktop Linux could use a few allies. Yes, GNOME and KDE has been at it for a very long time but have they managed to get any market share? Once a percent of nerds, nobody else.

      --
      Live today, because you never know what tomorrow brings
    4. Re:More of an issue about how bad Objective-C is by metamatic · · Score: 3, Funny

      Let me know when I can actually download and build a Swift compiler on something other than OS X, and I'll take a look at the language. Until then I'm not interested. And I'm a Mac user.

      (On an unrelated note, who the fuck thought it was a good idea to use the Exit icon to indicate logging in to Slashdot?)

      --
      GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
    5. Re:More of an issue about how bad Objective-C is by Chalnoth · · Score: 1

      Pretty much. Swift seems to be a good language, but largely unremarkable. I doubt it would have much of a chance of significant adoption if Objective-C wasn't so terrible.

    6. Re: More of an issue about how bad Objective-C is by Anonymous Coward · · Score: 0

      C and POSIX are more widespread (your criteria) than any of those other languages or toolkits you mention, combined even.

      One useful aspect of Swift is it's straight-forward integration with C.

      The reason Gtk never took off is because cross-platform GUI frameworks were always going to lose. QT is amazing but usage pales in comparison to native toolkits on OS X, Windows, iOS, Android, etc.

      All the more reason C and POSIX matter. Write the core algorithms and components in C and, if possible POSIX, and it'll work everywhere. You'll have to reimplement the GUI components anyhow.

    7. Re:More of an issue about how bad Objective-C is by Anonymous Coward · · Score: 0

      who the fuck thought it was a good idea to use the Exit icon to indicate logging in to Slashdot?

      They do not exactly *think*.

      They have 24 eyes, can move with intention and at surprising speed, and have something resembling a brain.

    8. Re:More of an issue about how bad Objective-C is by Anonymous Coward · · Score: 0

      Except that Objective-C actually isn't terrible at all. You might not like it, but that doesn't make it a bad language. It's actually a very good language.

  14. what a sec by iggymanz · · Score: 4, Interesting

    objective c plummets but swift only crawls up a couple notches but is still way down the list. sounds more like a lot of Apple device developers fled to something else for a living

    1. Re:what a sec by phantomfive · · Score: 3, Insightful

      Keep that in mind when you consider how accurate the Tiobe index is.

      --
      "First they came for the slanderers and i said nothing."
    2. Re:what a sec by Nahor · · Score: 3, Funny

      More than that, looking at the graph, the trend for most of languages is down. So it looks like developers are fleeing to something else than programming.

    3. Re:what a sec by Anonymous Coward · · Score: 0

      Big Issue, sir?

    4. Re:what a sec by Anonymous Coward · · Score: 0

      Yup. The methodology is fundamentally flawed if their goal is to figure out who is using a language. The vast majority of searches related to programming languages are not about the language themselves, but rather about particular APIs available in that language. And for Swift and Objective-C, you're going to have a hard time weeding out the differences, because the classes have the same names, the methods are basically the same except for a single colon (which Google is likely to strip/ignore), etc.

      By measuring language-specific searches, what the Tiobe index actually ends up measuring is the number of new developers learning a language for the first time. It isn't really a surprise that new developers are favoring Swift, because it is shiny and new.

  15. Sift is nice, but not great by Anonymous Coward · · Score: 1, Informative

    I've been using swift for a while now, overall the language is nice and is easier than objective-c.

    But, there are issues.

    * You still have to know ObjectiveC. Similar to other systems, like JavaScript. You can learn other languages that compile to Javascript all you want, but you should still learn JavaScript.
    * Swift gets lost. You ask Swift to call func1, it calls func2. The fix is to do a Clean and recompile.
    * Debugger gets lost and reverts to assembly -- as if ObjectiveC wasn't bad enough
    * Error handling is still Janky as shit! You can't catch exceptions on functionality that isn't marked to throw exceptions (compiler error), so if one does come about you are 'effed and app crashes.
    * Generics are not really implemented. At least not in a way that you would expect if you came from...I don't know, any other language on earth.

  16. The thing about statistics by Anonymous Coward · · Score: 0

    These statistics are gathered from various search engines, probably looking for various keywords as well as the language name.

    The hits may be situations vacant - empty desks with no one working there.
    The hits may be questions about the language - from people who don't know the language.
    The hits may be advertising courses or books - for people who don't know the language.

    I don't know how they can gauge 'popularity' from measuring people who don't know the language and don't work at it.

  17. Not proprietary by SuperKendall · · Score: 1

    Swift is shortly to be released as open source, including the standard library (fixing something that kept GnuStep behind).

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:Not proprietary by Anonymous Coward · · Score: 0

      Well, until that has happened I take that as a politicians promise.

    2. Re:Not proprietary by Anonymous Coward · · Score: 2, Insightful

      Anything that is produced solely by a corporation is proprietary, no matter if it is open source or not. Apple controls swift, just like Google controls Android and Microsoft controls C# and Sun controls Java.

    3. Re:Not proprietary by phantomfive · · Score: 4, Funny

      Sun controls Java.

      Hi there, Mr van Winkle!

      --
      "First they came for the slanderers and i said nothing."
    4. Re:Not proprietary by aaaaaaargh! · · Score: 1

      Cool, so it's gonna be like Dylan!!

  18. Netcraft confirms Objective-C is dying by JustAnotherOldGuy · · Score: 1

    It is now official. Netcraft has confirmed: Objective-C is dying

            One more crippling bombshell hit the already beleaguered Objective-C community when IDC confirmed that Objective-C market share has dropped yet again, now down to less than a fraction of 1 percent of all developers. Coming on the heels of a recent Netcraft survey which plainly states that Objective-C has lost more market share, this news serves to reinforce what we've known all along. Objective-C is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Trendy Code Languages comprehensive networking test.

            You don't need to be the Amazing Kreskin to predict Objective-C's future. The hand writing is on the wall: Objective-C faces a bleak future. In fact there won't be any future at all for Objective-C because Objective-C is dying. Things are looking very bad for Objective-C. As many of us are already aware, Objective-C continues to lose market share. Red ink flows like a river of blood.

            Objective-C++++ is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time Objective-C developers Joe Whathisname Hubbard and Mike Theotherguy only serve to underscore the point more clearly. There can no longer be any doubt: Objective-C is dying.

            Let's keep to the facts and look at the numbers.

            Due to the troubles of Cupertino, abysmal sales and so on, Objective-C went out of business and was taken over by Apple who sell another troubled OS. Now Objective-C is dead, its corpse turned over to yet another charnel house.

            All major surveys show that Objective-C has steadily declined in market share. Objective-C is very sick and its long term survival prospects are very dim. If Objective-C is to survive at all it will be among dilettante code dabblers. Objective-C continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, Objective-C is dead.

    --
    Just cruising through this digital world at 33 1/3 rpm...
  19. Learn Objective C? by Anonymous Coward · · Score: 0

    I have had "learn objective C" on my todo list for years, but my priorities pushed it into the future. Now I wonder if it would be a good idea to skip it completely (it most likely is). I always found the object syntax weird and confusing, which is a real motivation killer.

    I did use it a bit at some point where I compiled/linked C, C++ and objective C into a single binary. That works quite well except that C++ objects aren't compatible with objective C objects. I wonder if Swift would be equally easy to combine with C/C++. It would be required if people are to write an OSX native GUI and link it together with code also used on other platforms.

  20. No, it really is about Swift being a good language by SuperKendall · · Score: 4, Informative

    Objective-C was actually a very good language. Having used a lot of other languages heavily, including Java and C++ and C and Scheme and Lisp, Objective-C had a lot of great things going for it - it was verbose but once you got used to it that was nice, and the standard libraries for it were very powerful.

    Swift itself is I think a really great overall language. It's pragmatic in all kinds of ways that tries to help the programmer, letting you forgo a lot of syntactical cruft. It also offers a nice array of modern programing concepts including functional programming - but does not force you to use them, so you can decide what level of functional and object oriented programing is the right mix for you - or heck, just write only functions and use it like a much nicer C variant.

    The great thing is also, that with Apple heavily backing it you don't have to worry if it's worth picking up unlike lots of other nice, but small and not widely used languages.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  21. Not surprising by danbob999 · · Score: 1

    Objective-C was a single-platform language, with a single vendor and a single compiler*. Now that the only vendor switch to something else, developers move along. Nobody ever wanted to develop in Objective-C. People developed in Objective-C because it was the language of iOS.

    *Yes, I know, GCC also supports Objective-C and 2 Linux users used it in their basement

    1. Re: Not surprising by Anonymous Coward · · Score: 0

      Bullshit. You can use ObjC with Cygwin and GNUstep on Windows, too.

    2. Re: Not surprising by Anonymous Coward · · Score: 0

      . You can use ObjC with Cygwin and GNUstep on Windows, too.

      I tried to use it on Linux once and immediately ran into a 15 year old bug. I cannot believe that the Windows port of the Linux runtime of Objective-C is any more feature complete or usable.

  22. consider garbage collection is garbage by Anonymous Coward · · Score: 4, Funny

    Let me know when they catch up with c.

    Oh, wait. They never will. Because garbage collection. There's nothing so ultimately fabulous as the executable deciding to take a nice vacation in the middle of something you didn't want it to.

    So never mind.

    1. Re:consider garbage collection is garbage by jcr · · Score: 2

      When you don't know what you're talking about, it's best to stay anonymous.

      Apple's ARC memory management doesn't stop and run collection sweeps. This isn't an early 1980s LISP we're talking about.

      -jcr

      --
      The only title of honor that a tyrant can grant is "Enemy of the State."
    2. Re:consider garbage collection is garbage by Anonymous Coward · · Score: 1

      True. But there are still cases where you can get high latency. The worst case latency for ARC is still as bad a mark&sweep GC. For example, add a few thousand objects to a table and then release the table; the program will iterate over all those thousands of objects, decrementing the reference counts and possibly releasing those resources.

      Ironically this is one area where modern mark&sweep algorithms can be better, especially if the table was temporary or short-lived. And in C you can often use object stacks/bump allocators for this stuff. (Which is one reason to roll-your-own data structures in C rather than use libraries--you can optimize all the properties of the data structure for _your_ particular case. If using many third party libraries sounds like a good deal, then C and probably C++ are probably the wrong languages for the particular task.)

      But generally I would agree it's not really that big of a deal. As a general matter ARC provides much better latency. Heck, anybody who has used both an iPhone and an Android phone knows that. ARC is a good balance between automated GC and manual GC. The marginal benefit of automated GC with cycle detection is small, but the marginal cost is _huge_.

    3. Re:consider garbage collection is garbage by abies · · Score: 2

      For example, add a few thousand objects to a table and then release the table; the program will iterate over all those thousands of objects, decrementing the reference counts and possibly releasing those resources.

      And how this differs from C++? Not talking about reference counting, as it depends on what kind of pointers you are using, but about having cascading destruction happening if you get rid of high level container?

    4. Re:consider garbage collection is garbage by angel'o'sphere · · Score: 1

      Like being interrupted by an other process? Probably swapped out to disk?

      And most important: Swift is not a GC language/platform, a mistake imho.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    5. Re:consider garbage collection is garbage by jeremyp · · Score: 1

      And in C you can often use object stacks/bump allocators for this stuff. (Which is one reason to roll-your-own data structures in C rather than use libraries--you can optimize all the properties of the data structure for _your_ particular case.

      Yes, how did that work out for the openssl guys?

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    6. Re:consider garbage collection is garbage by jeremyp · · Score: 1

      The Apple implementation of Swift isn't garbage collected. Once it's made open source, there is no reason why somebody else can't create a GC version.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    7. Re:consider garbage collection is garbage by aaaaaaargh! · · Score: 1

      This isn't an early 1980s LISP we're talking about.

      Unfortunately, because early 1980s LISP systems were much more evolved than what Apple has ever come up with. :(

    8. Re:consider garbage collection is garbage by Anonymous Coward · · Score: 0

      Obviously in C++ you juts don't deallocate the memory thereby solving all the problems.

    9. Re:consider garbage collection is garbage by Anonymous Coward · · Score: 0

      I know you are joking, but you know, in Swift you can use more structs where in Objective-C you could only use classes, and in fact, Apple's WWDC videos tell developers to try structs as much as they can since then you avoid falling into several shared memory pitfalls (so when do I use a retain property vs a copy one?) and structs can be allocated on the stack which reduces GC pressure.

      Also you can call down to C and manage your memory yourself if you so need. I mean, people are writing Java games for Android and they get around the GC using low level allocation through JNI or preallocating huge arrays of objects with boolean used/unused properties

      Still, for a modern language without GC I would use Nim (http://nim-lang.org) with the --gc=none switch. I was able to translate a lot of C code to Nim, making it object oriented in the process and cleaner, plus proper imperative meta programming.

  23. null pointers, lol. Script kiddie detected! by Anonymous Coward · · Score: 0

    Well, you know, if you wrote your code at a higher level than "ignorant code monkey" you wouldn't be worrying about null pointers, because real programmers always check pointers before they use them, not to mention bounds checking and a whole bunch of other stuff you probably never ran into when you wrote that java for your web page...

    1. Re:null pointers, lol. Script kiddie detected! by Anonymous Coward · · Score: 1

      Good code shouldn't be checking for NULL pointers much at all, especially if your code follows good hygiene. I code mostly in C, but try to religiously follow RAII pattern by C++ religiously. If you follow an RAII pattern, there should be few if any execution paths where a NULL pointer could be dereferenced. (Note to C++ people: RAII is so much more than automated destructors on function exit. That's like the least interesting aspect of the pattern. It's just as powerful in C as in C++.)

      Ever wonder why free() accepts a NULL pointer? I can't say for sure, but it sure makes bailing out of a constructor function because of an OOM or other intermediate error infinitely easier to code. All of my destructor functions always accept a NULL pointer, and it's pretty much the only place I need to check for a NULL pointer.

      Another trick to avoid NULL pointers that is occasionally useful is to use a singleton in-place of NULL. That way it can be accessed freely.

      Plus, conditionals are pipeline killers. The fewer conditionals in your code, the better. It's perhaps not a coincidence that well-designed code will tend to minimize conditionals by minimizing the number of possible program states.

      Using unsigned integers where possible is another example. You don't need to check for underflow, just overflow.

      And well-thought-out algorithms might not even need to check for overflow at all. Garbage-in is garbage-out. As long as use of the value doesn't cause trouble elsewhere in the program (like an out-of-bounds array index), I don't see why a program should report an error rather than return the garbage value to the caller.

      Along the same lines, I rarely if ever do input sanitizing. It's usually stupid. A bad PHP programmer, for example, will use htmlentities to escape a string, then pass it to system or popen. A smart programmer will use fork+exec directly, bypassing the shell completely, making htmlentities or other sanity checking completely unnecessary. Sanity checking is usually just a form of blacklisting, anyhow, which is not exactly the best way to write correct and secure software.

    2. Re:null pointers, lol. Script kiddie detected! by Anonymous Coward · · Score: 0

      I rarely if ever do input sanitizing. It's usually stupid.

      Jesus Christ, I hope we are never on a team together.
      It's incredibly foolish of you not to sanitize your inputs.

  24. Re:No, it really is about Swift being a good langu by fox1324 · · Score: 1

    This is the correct response. Swift is good because it makes it easy for the programmer to provide lots of type information to the compiler. Obj-C was/is also good, and has picked up all of these recent improvements, just with more verbosity.

  25. Re:cross-system languages by hackwrench · · Score: 1

    http://www.qb64.net/ can write programs for Windows, Linux, Mac, and to some extent Android, but that got added last.

  26. Re:No, it really is about Swift being a good langu by Chalnoth · · Score: 1

    The great thing is also, that with Apple heavily backing it you don't have to worry if it's worth picking up unlike lots of other nice, but small and not widely used languages.

    Unless you end up working for a project whose target platform is anything but Apple. Your chances of encountering Swift on a program targeting any other platform is close to nil.

  27. MOV'n on up! by SouLShadow · · Score: 1

    I think we're all missing the most important revelation from the index: ASSEMBLY language is currently more popular than Objective-C, Swift, and Visual Basic. Currently ranked 12th over-all, up from 31st this time last year
       

    1. Re:MOV'n on up! by phantomfive · · Score: 1

      That's.....kind of weird. I'm not sure what to think of that.

      --
      "First they came for the slanderers and i said nothing."
    2. Re:MOV'n on up! by Anonymous Coward · · Score: 0

      It's happening. The machines are rising. They only understand 0s and 1s so you better get up to speed to serve your masters.

    3. Re:MOV'n on up! by thoromyr · · Score: 1

      which just demonstrates how useful this "popularity" index is. Or is not...

  28. Re:No, it really is about Swift being a good langu by Anonymous Coward · · Score: 0

    Unless you end up working for a project whose target platform is anything but Apple. Your chances of encountering Swift on a program targeting any other platform is close to nil.

    Time will tell if this is still true in a few years. I kind of agree that it doesn't look like a first choice for linux projects, but it still looks like a better choice than java and people use java today. I think the main issues will be library support/availability as well as the impact from "anti Apple crusades".

    Maybe Apple's goal is to make Swift perfect for linux on linux friendly conditions (open source, free usage and all that). Linux developer can then develop stuff for linux using Swift and Apple gains nothing, yet supports them and encourage them to do so. The trick would then be that the software is likely really easy to port to OSX while they would require a rewrite to be ported to windows. In other words: Swift could be used to kill "pick windows because all software has a windows port".

    Alternatively Swift might be available for windows at some point (don't know the license), in which case I can't quite figure out what Apple is trying to do. Maybe it's as simple as trying to make programmers familiar with the language used for iOS devices or maybe they really just think they made a great tool they want to share with everybody. I do think they have a plan they benefit from, but you never know for sure. Google released a bunch of open source free software as well, seemingly without gaining anything from it.

  29. Congrats for the useless comment by Anonymous Coward · · Score: 0

    "You can use ObjC with Cygwin and GNUstep on Windows"

    Yeah, I bet that happens.

  30. Cannnibalizing Objective-C by CanadianMacFan · · Score: 1

    Of course Swift is cannibalizing Objective-C. Apple intended it to.

    1. Re:Cannnibalizing Objective-C by Barlo_Mung_42 · · Score: 1

      Obi-c fell 11, swift went up 4.
      There's more than cannibalization going on here.

    2. Re:Cannnibalizing Objective-C by Anonymous Coward · · Score: 0, Funny

      Apple fragmented its ecosystem. It will stay in history as its dumb move of the '10s

      Because Apple have probably 100 of millions of objc loc, so hurting the ecosystem that provides the developers that maintain your own codebase is rarely seen as a bright move. Quality of software Apple products is already falling down, showing a rotting codebase+weak maintenance. Of course, with android beeing fragmented with uncertain java future, microsoft being schizo with winrt, win32, c#, managed langs and native, it may not matter that much, but they killed one of their key advantage, an unified platform.

    3. Re:Cannnibalizing Objective-C by LifesABeach · · Score: 1

      Objective-C loosely followed C, OK, I could work with it. Swift is still obviously maturing. Is Apple menopausal?

    4. Re:Cannnibalizing Objective-C by flargleblarg · · Score: 1

      Obj-C fell 11, swift went up 4.

      It's not actually relevant how many ranking indexes it fell by. You can't go by that. What's relevant is the percentages.

      Objective-C went from 10.294% to 1.419%.
      Swift went from 1.054% to 1.277%.
      Combined, they went from 11.349% to 2.696%.

      Clearly, the method of calculating percentages is highly flawed, as iOS and OS X development has not dropped as much as we are (mis)led to believe here.

  31. Languages driven by platform, and money? by Anonymous Coward · · Score: 0

    It looks like, if a language is not horrible, its adoption will be determined by primarily how big its paying customer base is.

  32. Using Stack Overflow as a measure by Anonymous Coward · · Score: 0

    of a language's popularity could give you a bad reading. If somebody every happened to create a really good language, devs shouldn't need to spend all day on SO trying to figure out how to use. They'd just be using it.

    Maybe that explains why Obj-c fell and Swift didn't move up very far. Stack Overflow usage shouldn't be mandatory for a language to be popular...assuming the language is any good.

  33. Re:No, it really is about Swift being a good langu by clickety6 · · Score: 1

    The great thing is also, that with Apple heavily backing it you don't have to worry if it's worth picking up

    Didn't you say the same about Objective-C a few years ago? ;)

    --
    ----------------------------------- My Other Sig Is Hilarious -----------------------------------
  34. Really by Anonymous Coward · · Score: 0

    Hey Apple, learn from MS biggest mistake! Performance, Performance, Performance...

  35. ASP.NET 5 by Anonymous Coward · · Score: 0

    ASP.NET 5 is almost done and is cross-platform to Windows, Linux, and OSX.

  36. Bottom Line by LifesABeach · · Score: 1

    ignoring try/catch/finally? So Apple thinks there are no unknowns during development? How simplistic.

    1. Re:Bottom Line by Anonymous Coward · · Score: 0

      There is a try/catch/finally mechanism for catching errors.

      https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/ErrorHandling.html

  37. TIOBE Index? Honestly? by kafka0 · · Score: 1

    Even though it's pretty clear that Swift is indeed replacing Objective-C which was its, err, objective), who still gives any credit to the infamous TIOBE index?

  38. Re: No, it really is about Swift being a good lang by Anonymous Coward · · Score: 0

    Obj-C has been around a decent amount of time. And there is no depreciation date that I am aware of. Truthfully I don't see a reason to get rid of it. I also see it being used in the foreseeable future.

  39. That's a big drop. Is the app-dev gold rush over? by fatalbert1 · · Score: 1

    It is possible that app development is slowing down. The gold rush is over. Objective-C has dropped 8.6% and Swift climbs a meagre 0.5%. Additionally there is a resurgence of hybrid app development solutions like Xamarin (which uses C#) and PhoneGap/Ionic (javascript). These two factors combined account for some of the 8% overall drop.

    Overall though, I have never trusted the Tiobe index. Perl is still in the top 10? Ok. No. On any measure. Compared to the clear activity of Python vs Perl (10x) on Stackoverflow, it is very clearly wrong. As a former Perl/CPAN contributor it is sad to browse CPAN. It is akin to walking through the once mighty mines of moria. Astonishingly detailed and yet for the most part abandoned.

  40. Swift over python by Anonymous Coward · · Score: 0

    I'm excited about the potential of Swift. It looks like what Python should have been, if only the designer's dogmatic choices had been more reasonable.

  41. Compiler needs a lot of work by cerberusss · · Score: 1

    For the last four projects, we've been using Swift exclusively. I really like it. The syntax feels modern to me (subjective, I agree).

    The compiler however still needs a lot of work. I feel it's quite slow. It's somewhat better where it won't recompile related files when you make one change. But I was used to the Objective-C compiler. That thing _flies_. On a MacBook Air, three years old, I am able to work on pretty big Objective-C projects.

    For Swift, that's simply not an option. Especially if you use mogenerator and Core Data (for those not in the know, it's a object layer on top of an SQLite database, and mogenerator generates two class files for every table), our last project ran into about 200 class files. Compiling took minutes.

    Things have gotten better. Especially if you're able to put parts of your projects in modules, it's really much better. But still I feel the Swift compiler requires a speedy quad core CPU. If you can afford it, get whatever top of the line quad core Apple offers.

    --
    8 of 13 people found this answer helpful. Did you?
  42. Re:No, it really is about Swift being a good langu by flargleblarg · · Score: 1

    Objective-C is actually a very good language.

    FTFY