We don't really know what it's status will be until it's out of beta and properly released. It's possible they will open source it under the BSD license like LLVM and Clang. Which will mean others can fork it under another name.
But the more important issue is probably the standards that define the language. And Apple certainly won't be delegating those to a standards body. They will want to be able to make changes as and when they decide, not suggest them and then wait years for approval.
Strange to compare it with COBOL. Cobol is particularly verbose, and stresses defining everything exactly up front. Whereas Swift is concise, and always tries to avoid the need to explicitly state things where they are already fixed by context. Of which this sort line is a great example.
Any language can be abused to create unreadable code. For C they even have the Obfuscated C contest. It's part of a programmer's job to make his code readable and beautiful. And the examples of Swift suggest that's easy for that language.
Try to enforce readability on a computer language and you end up with something like Applescript. Which is not much use for heavyweight programming.
On of the things about the iBook format is that page/line numbers depend on what size the window is. So I can't confirm the error you think there is, without a quote of the actual code.
Your opinion that it will fizzle in a year is misguided. Whilst Apple will still be supporting Objective-C for many years to come, Swift is pretty obviously their preferred development language going forward. So third party Apple developers will certainly use it for new applications once it's out of beta.
can you guess what the following function returns?
<
A syntax error. Of course with 2 parameters, it returns whether one parameter is less than another like in any other language.
My guess is that you are making a reference to it's use in a closure for sort, from the manual. Which if you give the full line, you have to admit is the one of the clearest and concise and beautiful instructions to sort a collection in any language!
The zealous ARMists are mostly those people who bought AMD during the speed-wars of the 90's. Intel won, and they can't stand that.
You're projecting, big time. These are completely different groups of people. They just happen to be 2 groups of people that you, as an Intel fan, dislike.
I like ARM, and as far as I'm concerned there's nothing to choose between Intel and AMD. It's the x86 instruction set that I dislike. And the power inefficiency.
No-one who hasn't learned assembler for at least a couple of processor architectures would understand it.
I too have a deep dislike of X86 that dates back to approaching it as my third processor architecture after 6502 and 68000 and hating X86 for it's inelegance. I've learned a couple more since than and nothing has shifted that initial distaste for X86. Even though it doesn't matter anymore as few people, and certainly not me, programs CPUs in assembler any more.
I'm lots older than that, and I don't remember any such complaints. Because originally the ARM chip was made only for the Acorn Archimedes. Which sold to people who certainly didn't want a PC clone. Later it started to be used as the CPU in PDAs, printers and mobile phones. None of which would have benefited at the time from Intel compatibility.
Issues with ARM not being x86 compatible are a recent thing.
Maybe there were complaints in the hobbyist Linux-everywhere crowd before there was an ARM port of Linux?
No language is perfect, C does have many problems and Swift has some very poor design too. Like the immutability of arrays when actually they aren't immutable, you can still change them. And the reference/copy behavior of arrays where assignment takes a reference but an add/remove operation implicitly makes a copy.
Those two don't seem to be examples, they seem to be the only 2 genuine criticisms. From the point of pure orthoganality, they are not quite right. Presumably they are done that way as a pragmatic thing for performance. The language is has only been public for a few days, so this kind of thing will become clearer. Maybe it'll even change before full release - until XCode 6 is released, it's still beta.
But they don't rank against the common defects of C.
I rather like new modern languages. I similarly defended Python (for being easy, quick and fun to use) and Go (for it's concurrency support). Python caught on despite not meeting all of Strouptrups conditions, and Go didn't.
Also, unlike many here, I find the limitations and bad design of C annoying.
So it's hardly surprising I speak in favour of a new language that is meant to improve the very programming platform on which I work, which has one of it's goals as removing all the common design defects of C.
Anything I don't like? The use of the keyword "in" for closures, and the "if let" construct both seem awkward. But they are the kind of idioms that will become second nature regardless.
Also, I think I prefer the elegant way of handling nil in the runtime versus spreading ?'s all over my code
The problem is with C like languages you always have to check for nil, because there's never a language guarantee that a value can't be nil. With swift you make the choice. A value (any value, not just pointers) either may have nils or it may not. So if you define it as one that may not you never need to check it.
As to when you are using nils
if (ptr) { }
is significantly more heavyweight than using ? on a value.
Your complaint comes down to fear of something different but better.
The GnuTLS category of bug is impossible in Swift. Everything is bounds checked. And your concerns about string interpolation happening at run time are incorrect.
What you raise are actually strengths of Swift, not problems.
You asked me why I found it so compelling. I gave you a list of all the improvements I noticed, together with a smaller list of the ones I found most compelling. Not sure what more you're after.
I absolutely agree we need to confirm speed with benchmarks. But until then I'm happy with the working assumption that it is - it's creating much the same intermediate code for the same compiler, but the language provides more guarantees, such as when a nil is possible and when it's not. And more guarantees means more optimisations are possible. That safety that you accept is there doesn't just mean less bugs, it can mean more speed.
Neither does Obj-C. Hasn't provided a hurdle to app development yet.
C++ has exceptions, and because you are allowed to mix C, C++ and Obj-C in the same source, some misguided people have mixed exceptions in with Obj-C code. But they are C++ or Java people doing it out of ignorance, rather than being the right thing to do in Obj-C.
It will replace the aging language of Obj-C, that has all the disdvantages of C, and plenty more on top. Allowing for greater safety and more power. Most of the common security bugs cannot happen in Swift. e.g. Neither the recent bug in Apple SSL nor in GnuTLS could happen in Swift code. Nor could any of the buffer overrun bugs.
* Who would it solve problems for?
Everyone who currently develops iOS or OSX apps in Obj-C. Both internally at Apple and third parties.
* What dramatically new could be provided (compared to every existing language)?
Many features of other modern languages, but retaining interoperability with existing Obj-C software, libraries and memory model.
* Could the new language be effectively deployed (n a world with many well-supported languages)?
Absolutely. Every iOS and OSX developer will have it as it comes with new version of the official IDE.
* Would designing a new language simply be a pleasant distraction from the hard work of helping people build better real-world tools and systems?
It came from Chris Lattner who was lead developer on LLVM and Clang. He's not simply kicking his heels for lack of work on other tools and systems to help developers.
What makes you call it a scripting language? It's not interpreted, and it's primary use isn't to control other programs, nor to be embedded in other programs.
It's a full featured compiled language, useful for anything that C, C++, Obj-C or Java would be used for.
Slashdot Mirror
Yes. Once you realize that the language doesn't matter, the programmers matter, then you have reached wisdom. Every language is crappy.
They both matter. You're much more able to construct a readable program with Python than Perl. With Objective-C than C++. With C than assembler.
Let works rationally with other standard library values, so it seems more likely the issue is with the implementation of arrays.
We don't really know what it's status will be until it's out of beta and properly released. It's possible they will open source it under the BSD license like LLVM and Clang. Which will mean others can fork it under another name.
But the more important issue is probably the standards that define the language. And Apple certainly won't be delegating those to a standards body. They will want to be able to make changes as and when they decide, not suggest them and then wait years for approval.
Strange to compare it with COBOL. Cobol is particularly verbose, and stresses defining everything exactly up front. Whereas Swift is concise, and always tries to avoid the need to explicitly state things where they are already fixed by context. Of which this sort line is a great example.
Any language can be abused to create unreadable code. For C they even have the Obfuscated C contest. It's part of a programmer's job to make his code readable and beautiful. And the examples of Swift suggest that's easy for that language.
Try to enforce readability on a computer language and you end up with something like Applescript. Which is not much use for heavyweight programming.
On of the things about the iBook format is that page/line numbers depend on what size the window is. So I can't confirm the error you think there is, without a quote of the actual code.
Your opinion that it will fizzle in a year is misguided. Whilst Apple will still be supporting Objective-C for many years to come, Swift is pretty obviously their preferred development language going forward. So third party Apple developers will certainly use it for new applications once it's out of beta.
can you guess what the following function returns?
<
A syntax error. Of course with 2 parameters, it returns whether one parameter is less than another like in any other language.
My guess is that you are making a reference to it's use in a closure for sort, from the manual. Which if you give the full line, you have to admit is the one of the clearest and concise and beautiful instructions to sort a collection in any language!
sorted = sort(names, <)
Arrays are part of the standard library, not the language.
Swift is in Beta.
Apple isn't promising source code compatibility during the beta phase.
So the peculiarities of array mutability may well be fixed before a real v1.0 release.
Apple's "Swift" isn't an acronym. You can tell because it's not capitalised.
Similarly there were tools to remove the unwanted architecture code from Universal Binaries during the PowerPC to x86 transition.
The zealous ARMists are mostly those people who bought AMD during the speed-wars of the 90's. Intel won, and they can't stand that.
You're projecting, big time. These are completely different groups of people. They just happen to be 2 groups of people that you, as an Intel fan, dislike.
I like ARM, and as far as I'm concerned there's nothing to choose between Intel and AMD. It's the x86 instruction set that I dislike. And the power inefficiency.
No-one who hasn't learned assembler for at least a couple of processor architectures would understand it.
I too have a deep dislike of X86 that dates back to approaching it as my third processor architecture after 6502 and 68000 and hating X86 for it's inelegance. I've learned a couple more since than and nothing has shifted that initial distaste for X86. Even though it doesn't matter anymore as few people, and certainly not me, programs CPUs in assembler any more.
Are you (and were you) a Mac user?
I'm lots older than that, and I don't remember any such complaints. Because originally the ARM chip was made only for the Acorn Archimedes. Which sold to people who certainly didn't want a PC clone. Later it started to be used as the CPU in PDAs, printers and mobile phones. None of which would have benefited at the time from Intel compatibility.
Issues with ARM not being x86 compatible are a recent thing.
Maybe there were complaints in the hobbyist Linux-everywhere crowd before there was an ARM port of Linux?
It's allowing the same thing, whilst making it clear that the programmer has considered the possibility that the pointer/reference might be nil.
No language is perfect, C does have many problems and Swift has some very poor design too. Like the immutability of arrays when actually they aren't immutable, you can still change them. And the reference/copy behavior of arrays where assignment takes a reference but an add/remove operation implicitly makes a copy.
Those two don't seem to be examples, they seem to be the only 2 genuine criticisms. From the point of pure orthoganality, they are not quite right. Presumably they are done that way as a pragmatic thing for performance. The language is has only been public for a few days, so this kind of thing will become clearer. Maybe it'll even change before full release - until XCode 6 is released, it's still beta.
But they don't rank against the common defects of C.
I rather like new modern languages. I similarly defended Python (for being easy, quick and fun to use) and Go (for it's concurrency support). Python caught on despite not meeting all of Strouptrups conditions, and Go didn't.
Also, unlike many here, I find the limitations and bad design of C annoying.
So it's hardly surprising I speak in favour of a new language that is meant to improve the very programming platform on which I work, which has one of it's goals as removing all the common design defects of C.
Anything I don't like? The use of the keyword "in" for closures, and the "if let" construct both seem awkward. But they are the kind of idioms that will become second nature regardless.
Also, I think I prefer the elegant way of handling nil in the runtime versus spreading ?'s all over my code
The problem is with C like languages you always have to check for nil, because there's never a language guarantee that a value can't be nil. With swift you make the choice. A value (any value, not just pointers) either may have nils or it may not. So if you define it as one that may not you never need to check it.
As to when you are using nils
if (ptr) {
}
is significantly more heavyweight than using ? on a value.
Your complaint comes down to fear of something different but better.
The GnuTLS category of bug is impossible in Swift. Everything is bounds checked. And your concerns about string interpolation happening at run time are incorrect.
What you raise are actually strengths of Swift, not problems.
It doesn't happen at run time. It happens at compile time. This code:
let foo = 2
var s2 = "a is \(" + "foo" + ")"
fails to compile with the error: Unexpected '"' character in string interpolation.
It's simply a very much nicer and less buggy syntax for sprintf.
You asked me why I found it so compelling. I gave you a list of all the improvements I noticed, together with a smaller list of the ones I found most compelling. Not sure what more you're after.
I absolutely agree we need to confirm speed with benchmarks. But until then I'm happy with the working assumption that it is - it's creating much the same intermediate code for the same compiler, but the language provides more guarantees, such as when a nil is possible and when it's not. And more guarantees means more optimisations are possible. That safety that you accept is there doesn't just mean less bugs, it can mean more speed.
The language doesn't have exceptions.
Neither does Obj-C. Hasn't provided a hurdle to app development yet.
C++ has exceptions, and because you are allowed to mix C, C++ and Obj-C in the same source, some misguided people have mixed exceptions in with Obj-C code. But they are C++ or Java people doing it out of ignorance, rather than being the right thing to do in Obj-C.
If language developers want to have a name that they can keep for themselves, they should invent one, not find a common word from the dictionary.
Or are we suddenly supposed to have sympathy for Microsoft wanting to adopt the word Windows as their own property.
Cisco wasn't currently selling any product using the name iPhone, and falsified some photos to make it seem like they were.
* What problem would the new language solve?
It will replace the aging language of Obj-C, that has all the disdvantages of C, and plenty more on top. Allowing for greater safety and more power. Most of the common security bugs cannot happen in Swift. e.g. Neither the recent bug in Apple SSL nor in GnuTLS could happen in Swift code. Nor could any of the buffer overrun bugs.
* Who would it solve problems for?
Everyone who currently develops iOS or OSX apps in Obj-C. Both internally at Apple and third parties.
* What dramatically new could be provided (compared to every existing language)?
Many features of other modern languages, but retaining interoperability with existing Obj-C software, libraries and memory model.
* Could the new language be effectively deployed (n a world with many well-supported languages)?
Absolutely. Every iOS and OSX developer will have it as it comes with new version of the official IDE.
* Would designing a new language simply be a pleasant distraction from the hard work of helping people build better real-world tools and systems?
It came from Chris Lattner who was lead developer on LLVM and Clang. He's not simply kicking his heels for lack of work on other tools and systems to help developers.
What makes you call it a scripting language? It's not interpreted, and it's primary use isn't to control other programs, nor to be embedded in other programs.
It's a full featured compiled language, useful for anything that C, C++, Obj-C or Java would be used for.