23 ms·

While half of the things you checked in that copy-paste are wrong, let me take the bait and say why it will work: - it's not just an arbitrary language, it's t

While half of the things you checked in that copy-paste are wrong, let me take the bait and say why it will work: - it's not just an arbitrary language, it's the new officially sanctioned programming interface for Apple's gigantic, wildly profitable ecosystem - it's much more concise than Objective-C - it's faster than Objective-C - it's safer than Objective-C - it has more features than Objective-C - ...yet it's fully compatible with Objective-C and C code running alongside in the same app. And last, but not least, if you know how Apple works, you know that somewhere in the range of WWDC 2016-2018, Craig Federighi will be on stage, showing a pie chart and saying "Over 92% of developers have ported their apps to Swift, so screw the other 8%, we're discontinuing Objective-C". Moving fast and constant change is the name of the game at Apple.

cratermoon 12y ago
There's no real objective measure for either 'conciseness' or 'safety', in general terms. Whether or not it's faster in the real world is yet to be seen, and creeping featuritis has never been the hallmark of a great programming language. It makes good press release and marketing speak, but those assertions are a long way from making the OP 'wrong'.
- mantrax5 12y ago
  So you take a language with null pointers, unsafe pointer access, possibility of array and buffer overflows (C and Objective-C). And then you take another where you have no null pointers, no direct pointer access, and no possibility for array and buffer overflows (Swift). And you say "nah, I look at these two, and I can't objectively tell which is safer"? Are you fuckin' kidding me? Regarding speed, it's been proven faster by benchmarks, and by the fact the very reason Swift doesn't mix C types and Objective-C types is so the compiler can better reason and optimize the resulting code.
  - Pacabel 12y ago
    I think you're putting words into his mouth, and perhaps intentionally misrepresenting what he wrote. Swift was announced just a few hours ago. While we can make assumptions about its safety based on its feature set, or we can assume that the very vague performance details Apple provided are valid in a real-world setting, none of this has really been tested or verified independently yet. What cratermoon wrote is perfectly legitimate. Let's try Swift out in the real world, perhaps for a year or two. Let's get some real data. Then let's analyze that actual data, rather than engaging in unsubstantiated speculation, or trusting some vague performance graphs shown in a conference presentation.
    - mantrax5 12y ago
      I'm not misrepresenting what he wrote, I'm directly responding to it. While you may not be aware with recent language development and modern LLVM-based languages in general, to me and many others what was announced at WWDC today wasn't just a set of buzzwords and marketing speak. Anyone who has been into language design and watched the keynote today can make a pretty good guess about the properties of Swift. There's a book with hundreds of pages of examples and description of the language semantics on iBooks right now. I've been reading it before I posted. I've been playing with the beta Xcode as well. Swift is not revolutionary in terms of its feature set. But what makes it quite interesting is the fact this is now an official language for Apple app development, and it's quite a bit ahead of Objective-C in... yes. Safety, performance and conciseness. Fact.
      - Pacabel 12y ago
        I'd prefer to see how it fares in the real world before jumping to such conclusions like you seem to be so willing to do. You may not have been around to experience it first-hand, but we heard a lot of claims made back in the 1990s about how Java and the JVM would increase security and safety. The arguments made then even overlap with some of those being made in this case! The lack of direct pointer access and manipulation, automated memory management and better bounds checking are some examples of the arguments used then and now. Yet if you work with computers at all, I'm sure you'd know that many of those claims did not materialize. Flaws have been found in the various implementations of Java and its VM, and these have affected its security and safety in very serious and significant ways, many times over. Perhaps things are different in the case of Swift. But we won't be able to say for sure until later on, once it has undergone some significant real-world use.
- gtrak 12y ago
  There are objective measures. There aren't necessarily 'absolute' ones. Lisp is relatively more concise than C or Java for the same tasks. Java is relatively safer than C for the same tasks.
  - cratermoon 12y ago
    How objective can something be if the criteria vary depending on the comparison?
    - gtrak 12y ago
      I'm not sure what you mean. Lines of code is an objective measure. How meaningful that might actually be, well, that's subjective.
m_mueller 12y ago
How is Swift safer than Obj-C? I'm not sarcastic or anything by the way, I just don't understand yet the foundation behind that statement.
- orkoden 12y ago
  It does not have features that often lead to bugs. E.g. the switch statement does not allow fall through and enforces a default case.
  - m_mueller 12y ago
    The lack of fall through makes me a bit sad since I think that it's a very powerful programming construct and it usually only hurts people new to the concept - but of course one can live without it.
    - mantrax5 12y ago
      Three things. First of all, while you can't do this: case val: case val: case val: ... You can do this in Swift, which does the same thing: case val, val, val: ... Second, you can fall through in Swift, but you need to ask for it: case val: ... fallthrough case val: ... So don't be sad. And third... Seriously now, it's a "very powerful programming concept"? I bet 9 times out of 10 you use this very powerful programming concept in other languages, you did it by accident, not because you needed its pawa.
      - m_mueller 12y ago
        Thanks for the clarification on how to use it in Swift - like this it's indeed the perfect solution by enforcing it to be explicit. Having multiple cases rolled into one is also a very nice option. The snark wasn't really called for though. No, I don't 'use' it by accident, that would in most cases just become a bug. I use it when it makes code more concise rather than having nested ifs. Consider for example ACL rules where you set different privileges by default according to an access level.
oldguysrule 12y ago
1) So was Java for a bit. It sucked. Developers ignored it. 2) UIApplication.sharedApplication.delegate vs UIApplication.sharedApplication().delegate - nope. It isn’t more concise. It appears to be a wee bit more verbose. 3) Some benchmarks on the web are saying otherwise. It adds extra bridging and ARC for numbers. I don’t see how it can be faster and even if it is - nobody cares about speed. If I need to beat it, I can drop to C, IMP cache, and kick Swifts sorry little ass. 4) Safer - like the TSA says flying without nail clipp ers is safer? It doesn’t solve any problems I actually have. I think my last type error was in 2005 - took about a minute and a half to find it. I routinely work in dynamically typed languages and avoid static typed languages like the plague they are. I’m not opposed to type annotations when they help, but these just look like cargo cultism - like a lot Swift’s silly “features”. 5) It has less features where it counts - basically a less capable object model, weaker meta model, and more budensome interaction with C code than Objective C and a number of useful Objective C features have been walled off. I have Objective C code that cannot be written in Swift. 6) Except for that kind of dynamic stuff like performSelector: afterDelay: withArguments: and that pesky NSInvocation that isn’t available. There are better projects around than this pile of crap. I will not be porting anything. Quite a lot of code I have can’t be ported. Java killed WebObjects. Lets not let Swift kill Cocoa.

cratermoon 12y ago

There's no real objective measure for either 'conciseness' or 'safety', in general terms. Whether or not it's faster in the real world is yet to be seen, and creeping featuritis has never been the hallmark of a great programming language. It makes good press release and marketing speak, but those assertions are a long way from making the OP 'wrong'.

mantrax5 12y ago
So you take a language with null pointers, unsafe pointer access, possibility of array and buffer overflows (C and Objective-C). And then you take another where you have no null pointers, no direct pointer access, and no possibility for array and buffer overflows (Swift). And you say "nah, I look at these two, and I can't objectively tell which is safer"? Are you fuckin' kidding me? Regarding speed, it's been proven faster by benchmarks, and by the fact the very reason Swift doesn't mix C types and Objective-C types is so the compiler can better reason and optimize the resulting code.
- Pacabel 12y ago
  I think you're putting words into his mouth, and perhaps intentionally misrepresenting what he wrote. Swift was announced just a few hours ago. While we can make assumptions about its safety based on its feature set, or we can assume that the very vague performance details Apple provided are valid in a real-world setting, none of this has really been tested or verified independently yet. What cratermoon wrote is perfectly legitimate. Let's try Swift out in the real world, perhaps for a year or two. Let's get some real data. Then let's analyze that actual data, rather than engaging in unsubstantiated speculation, or trusting some vague performance graphs shown in a conference presentation.
  - mantrax5 12y ago
    I'm not misrepresenting what he wrote, I'm directly responding to it. While you may not be aware with recent language development and modern LLVM-based languages in general, to me and many others what was announced at WWDC today wasn't just a set of buzzwords and marketing speak. Anyone who has been into language design and watched the keynote today can make a pretty good guess about the properties of Swift. There's a book with hundreds of pages of examples and description of the language semantics on iBooks right now. I've been reading it before I posted. I've been playing with the beta Xcode as well. Swift is not revolutionary in terms of its feature set. But what makes it quite interesting is the fact this is now an official language for Apple app development, and it's quite a bit ahead of Objective-C in... yes. Safety, performance and conciseness. Fact.
    - Pacabel 12y ago
      I'd prefer to see how it fares in the real world before jumping to such conclusions like you seem to be so willing to do. You may not have been around to experience it first-hand, but we heard a lot of claims made back in the 1990s about how Java and the JVM would increase security and safety. The arguments made then even overlap with some of those being made in this case! The lack of direct pointer access and manipulation, automated memory management and better bounds checking are some examples of the arguments used then and now. Yet if you work with computers at all, I'm sure you'd know that many of those claims did not materialize. Flaws have been found in the various implementations of Java and its VM, and these have affected its security and safety in very serious and significant ways, many times over. Perhaps things are different in the case of Swift. But we won't be able to say for sure until later on, once it has undergone some significant real-world use.
gtrak 12y ago
There are objective measures. There aren't necessarily 'absolute' ones. Lisp is relatively more concise than C or Java for the same tasks. Java is relatively safer than C for the same tasks.
- cratermoon 12y ago
  How objective can something be if the criteria vary depending on the comparison?
  - gtrak 12y ago
    I'm not sure what you mean. Lines of code is an objective measure. How meaningful that might actually be, well, that's subjective.

m_mueller 12y ago

How is Swift safer than Obj-C? I'm not sarcastic or anything by the way, I just don't understand yet the foundation behind that statement.

orkoden 12y ago
It does not have features that often lead to bugs. E.g. the switch statement does not allow fall through and enforces a default case.
- m_mueller 12y ago
  The lack of fall through makes me a bit sad since I think that it's a very powerful programming construct and it usually only hurts people new to the concept - but of course one can live without it.
  - mantrax5 12y ago
    Three things. First of all, while you can't do this: case val: case val: case val: ... You can do this in Swift, which does the same thing: case val, val, val: ... Second, you can fall through in Swift, but you need to ask for it: case val: ... fallthrough case val: ... So don't be sad. And third... Seriously now, it's a "very powerful programming concept"? I bet 9 times out of 10 you use this very powerful programming concept in other languages, you did it by accident, not because you needed its pawa.
    - m_mueller 12y ago
      Thanks for the clarification on how to use it in Swift - like this it's indeed the perfect solution by enforcing it to be explicit. Having multiple cases rolled into one is also a very nice option. The snark wasn't really called for though. No, I don't 'use' it by accident, that would in most cases just become a bug. I use it when it makes code more concise rather than having nested ifs. Consider for example ACL rules where you set different privileges by default according to an access level.

oldguysrule 12y ago

1) So was Java for a bit. It sucked. Developers ignored it. 2) UIApplication.sharedApplication.delegate vs UIApplication.sharedApplication().delegate - nope. It isn’t more concise. It appears to be a wee bit more verbose. 3) Some benchmarks on the web are saying otherwise. It adds extra bridging and ARC for numbers. I don’t see how it can be faster and even if it is - nobody cares about speed. If I need to beat it, I can drop to C, IMP cache, and kick Swifts sorry little ass. 4) Safer - like the TSA says flying without nail clipp ers is safer? It doesn’t solve any problems I actually have. I think my last type error was in 2005 - took about a minute and a half to find it. I routinely work in dynamically typed languages and avoid static typed languages like the plague they are. I’m not opposed to type annotations when they help, but these just look like cargo cultism - like a lot Swift’s silly “features”. 5) It has less features where it counts - basically a less capable object model, weaker meta model, and more budensome interaction with C code than Objective C and a number of useful Objective C features have been walled off. I have Objective C code that cannot be written in Swift. 6) Except for that kind of dynamic stuff like performSelector: afterDelay: withArguments: and that pesky NSInvocation that isn’t available. There are better projects around than this pile of crap. I will not be porting anything. Quite a lot of code I have can’t be ported. Java killed WebObjects. Lets not let Swift kill Cocoa.