Now with boost optionals you're getting closer. That's intended for the same thing. Yet it's inferior in 2 ways:
1) It's an object not a value. So you create a boost optional on the heap, and have a pointer to it. If you have an array of 4, then you have an array of 4 pointers, with 4 objects on the heap, each of which has 2 values. Swift optionals are values in themselves. If you have an array of 4 of them, then the actual optionals are in the array. There's nothing external. This means that Swift is a hell of a lot faster dealing with optionals. The clue is in the name.
2) Because it's not part of the language it doesn't have a syntax to test and unbox in one. So you need more code.
The memory representation is largely irrelevant to the coding algorithms. It might be important if you're going to do some low-level optimization, but if you're doing low-level optimization where that sort of thing matters, you shouldn't be working in Go, Swift, or Objective-C.
There you go. Swift is intended for system software as well as apps. And as I told you earlier, it's designed to be easy for the compiler to optimise. This is a case in point. It's will be slower that C/C++ only if those languages are used in an unsafe way. If you use those languages with a library such as boost to give you safety, then Swift will probably be faster.
Attaching the word "pointer" vs. "optional" doesn't change the behavior one iota.
An optional is not a pointer. (Nor is it a reference). And that's not simply a matter of names. They are completely different things. Suppose you had an array of 4 optional integers, how do you imagine that is represented in memory?
I challenge you to find a code snippet using optionals in Swift that does not trivially translate to a similar number of lines in Go
Turing machines are equivalent. That doesn't mean language features are the same. They're not. You might solve a given problem in a similar number of lines in lisp, basic, forth and scheme. It doesn't mean the language features that you would use are the same.
And optionals don't have to be checked for nil when extracting their value? In what universe? While the language does allow a forced conversion without a check, that just means that the developer is dropping optional safety on the floor (this is perfectly reasonable in some cases).
So you ask in what universe, then you confirm that indeed you can.
This is no different from many other languages. There's just a slight difference in syntax.
Still wrong. Whilst you've clearly now read enough no to confirm what I said in the last post, you still don't understand how optionals are different from pointers and references.
Optionals are actual values which can be nil. Not pointers to values. Not references to values. Values. This doesn't exist in the languages you think it does. When you think it does, that's because you're not understanding what optionals are.
I don't know how many more ways there are to say this. Don't just skim the syntax, read the chapter.
As I said, I was bored with your lack of understanding of what optionals are last time.
But Swift has the same issue: you have to check an optional for nil before assigning an optional to a value.
Again, false.
I was programming professionally in C++ for years before I did any Obj-C. This is not my misunderstanding. It's that you don't understand what optionals are.
Your lack of understanding of what optionals are is now just getting boring. No, they aren't the equivalent of pointers and references. Go read up on Swift optionals.
I've been a professional programmer for 25 years, and learned what a fucking pointer was years before that. It's not me confused about pointers it's you confused about the concept of nil and what optionals are.
Nil is the concept of no value. It happens to be implemented for the pointer type in C like languages as a zero, but that's an implementation detail, not what a nil is. This is why in pretty much every language you use the keyword or value "nil" or "NULL" rather than the literal value 0 when using them.
Optionals is all about having a better implementation of the concept of nil. Any VALUE can have the ability to be nil. Not just pointers. And by not using an optional, you represent the fact that the value can't be nil.
If you don't see that this is a step forward, then that's your lack of understanding, not a lack of progress by Swift. Sorry, but that's the way it is.
And when interoperating with C/C++/Objective-C, Swift won't really protect you any better.
Wrong. The Obj-C language has been updated to markup APIs for which nil is a legal argument or result. And all of the Apple Obj-C APIs have been marked up as appropriate. Swift understands this and so you get/pass optionals when appropriate. So you get all the benefits of optionals when calling Obj-C libraries.
<quote>A pointer unable to contain nil doesn't make any sense.</quote>
NO. You really need to look at optionals. They are one of the best new features of Swift.
I can even show you how a pointer that is guaranteed not to be nil can be done in another language.
if (foo==nil) { return; } bar = foo;
In this scenario, bar is a pointer that is guaranteed not to be nil. From that point on you can do whatever you like with bar and you never again need to check it for nil. You are in no risk of dereferencing nil. Well Swift gives that within the language. Such that I could pass bar around to other methods, and they will always know that that value is not nil.
It's even more useful in formal APIs. In other languages, the documentation says whether a parameter or a result can be nil or not. In Swift, the code says that.
<quote>That would be like an integer unable to contain zero.</quote>
No, no, no. Zero is a value. Nil is the lack of a value. You're confused because most languages implement nil as a pointer with zero in it. But there is no connection between zero and nil.
<quote>but also runs the risk of making for very ugly codebases where multiple languages are used together.</quote>
Swift and C/Obj-C don't ever exist in the same files. Though they may exist in the same project, and call each other. So there's no ugliness. And having multiple languages plus various other types of source file are the norm for significant projects.
Yes. A pointer to int can be nil, and that is different from an integer holding a value of zero.
No, that's not at all what I asked. That's the same as C. Take a look at optionals in Swift. It's very clear from your lack of understanding of my questions that they offer something very useful that you haven't come across before.
"Throws" declarations are available in Java, and can be compiler-enforced.
OK, that's the declaration side. But there's no equivalent of the "try" keyword required before calling a method with can throw. The necessity for that keyword shows clearly what blocks of code you need to enclose in a catch, and which you do not.
No, Britain developed it's empire earlier than that. And for sure it was massive. But the the 20th century was the period of decline. For sure before the 20th century Britain was the most vicious empire. But the USA took that title over in the 20th century.
1) That's only one of the options then. Where's the pointer that cannot contain nil?
Also take an integer type. Does go differentiate between 0 and nil? If not it's not got any equivalent of optionals.
2) I don't know Java well, it's about 20 years since I did some as a student. But Swift marks the definition of any method that can return an error with the keyword "throws". Likewise when calling a method that can throw an error, you have to prefix the call with the keyword "try". They make methods that can fail obvious from both sides of the contract. It means that the programmers is always alerted to a potential error situation. I believe this is a significant improvement on Java exceptions.
5) Sure, preconditions are not a new idea. I first came across them in Eiffel, again 20 years ago. But most popular languages don't support them, except by utilising more general if statement or asserts. For Swift, guard ties in with optionals to automatically provide the guaranteed-not-to-be-nil pointer or value after the guard statement has rejected nil values. The programmer doesn't need to remember that they've excluded nils at the beginning of the method, the language has it modelled explicitly.
There's nothing specific about Swift that makes it "highly optimizable"
I'm afraid Chris Lattner knows better than you do. Every feature was designed with an eye to optimisation. Take for example the, shall we say novel, array behaviour that everyone was complaining about last year. The reason was they were designed to be highly optimisable. Well array behaviour has become more as one would expect now, but that original behaviour is an insight into the design for optimisation process.
I agree with you that it's mainly of interest to Apple developers. But you underestimate it when you imagine that there's not much new in there. Apple have not simply copied features from other languages. The developer of LLVM has taken the opportunity to write a language that's engineered to to compile to fast code, and to minimise common sources of bugs and security issues. And he and his team have considered these from first principles, not just copied.
It may be no more popular outside Apple platforms than Mono is. But who cares?
There's a single file in a project that lists all the C header files you want to use. They are then available to any Swift code. You don't have to do anything more.
As I said it doesn't satisfy ANY of the requirements.
The requirements are that it is able to call the Cocoa API, and that it is fast enough for systems programming - the latter being largely done by being designed from scratch to be highly optimisable.
And there's little resemblance to Java, beyond the certain commonality that all modern language syntax has. Take a chunk of code in the two languages and they look very different.
The whole apple-didn't-need-to-write-a-new-language argument is just ill-informed.
A burgeoning market I believe. Last I saw it was estimated $35m (all handsets included) in revenue. The total software market is estimated $400b. Swift can be #1 for developing iOS apps, but it is still insignificant against the overall software market which uses non-Apple languages.
Phones are the most common computing devices these days, and people buy more software for them. Albeit at cheaper prices.
My point is even if Swift gets to #1 for iOS apps, its marketshare will be so small that it may as well be statistical noise.
Then your point is stupid. The very least that's going to happen is it's going to replace Obj-C in the ratings, and that's currently number 5.
1) Pointers are not optionals. The whole point of optionals is they say which values can be null and which can't. For all types, including pointers.
2) Manual error code handling is available in any language and costs developer time, increases code size, and causes bugs. Swift 2 makes it clear which methods can fail with errors, both when defining and when calling a method, and then handles the error in a similar way to exceptions.
5) Guard is really simple, but it covers a particular bailing out if that programmers are doing all the time. It makes it explicit that this if is a precondition. And the fact that it always bails out of the current scope is guaranteed. It's going to get adopted by other languages for sure.
I won't argue that Go is also and interesting language. If I was coding for servers I'd certainly be looking at that. But for apps and system software Swift is looking very good to me. But yes, more for Apple use rather than other platforms.
It wasn't intended to be an argument. It was the answer to a question. Yes of course comparing languages intended for two different domains is pointless, but that's what was asked.
Lisp. Ha ha ha. If you think that's the answer, you don't know the question.
Slashdot Mirror
Are you on Facebook? If not, probably most of your family and friends are. Are they all exhibitionists?
Have you worked out yet why Facebook is successful and the open source Social Networks haven't been?
I repeat, do not treat a private service as a public square. That's a horrible idea.
He says on Dice's private service.
Now with boost optionals you're getting closer. That's intended for the same thing. Yet it's inferior in 2 ways:
1) It's an object not a value. So you create a boost optional on the heap, and have a pointer to it. If you have an array of 4, then you have an array of 4 pointers, with 4 objects on the heap, each of which has 2 values.
Swift optionals are values in themselves. If you have an array of 4 of them, then the actual optionals are in the array. There's nothing external.
This means that Swift is a hell of a lot faster dealing with optionals. The clue is in the name.
2) Because it's not part of the language it doesn't have a syntax to test and unbox in one. So you need more code.
The memory representation is largely irrelevant to the coding algorithms. It might be important if you're going to do some low-level optimization, but if you're doing low-level optimization where that sort of thing matters, you shouldn't be working in Go, Swift, or Objective-C.
There you go. Swift is intended for system software as well as apps. And as I told you earlier, it's designed to be easy for the compiler to optimise. This is a case in point. It's will be slower that C/C++ only if those languages are used in an unsafe way. If you use those languages with a library such as boost to give you safety, then Swift will probably be faster.
Attaching the word "pointer" vs. "optional" doesn't change the behavior one iota.
An optional is not a pointer. (Nor is it a reference). And that's not simply a matter of names. They are completely different things. Suppose you had an array of 4 optional integers, how do you imagine that is represented in memory?
I challenge you to find a code snippet using optionals in Swift that does not trivially translate to a similar number of lines in Go
Turing machines are equivalent. That doesn't mean language features are the same. They're not. You might solve a given problem in a similar number of lines in lisp, basic, forth and scheme. It doesn't mean the language features that you would use are the same.
And optionals don't have to be checked for nil when extracting their value? In what universe? While the language does allow a forced conversion without a check, that just means that the developer is dropping optional safety on the floor (this is perfectly reasonable in some cases).
So you ask in what universe, then you confirm that indeed you can.
This is no different from many other languages. There's just a slight difference in syntax.
Still wrong. Whilst you've clearly now read enough no to confirm what I said in the last post, you still don't understand how optionals are different from pointers and references.
Optionals are actual values which can be nil. Not pointers to values. Not references to values. Values. This doesn't exist in the languages you think it does. When you think it does, that's because you're not understanding what optionals are.
I don't know how many more ways there are to say this. Don't just skim the syntax, read the chapter.
As I said, I was bored with your lack of understanding of what optionals are last time.
But Swift has the same issue: you have to check an optional for nil before assigning an optional to a value.
Again, false.
I was programming professionally in C++ for years before I did any Obj-C. This is not my misunderstanding. It's that you don't understand what optionals are.
Your lack of understanding of what optionals are is now just getting boring. No, they aren't the equivalent of pointers and references. Go read up on Swift optionals.
I've been a professional programmer for 25 years, and learned what a fucking pointer was years before that. It's not me confused about pointers it's you confused about the concept of nil and what optionals are.
Nil is the concept of no value. It happens to be implemented for the pointer type in C like languages as a zero, but that's an implementation detail, not what a nil is. This is why in pretty much every language you use the keyword or value "nil" or "NULL" rather than the literal value 0 when using them.
Optionals is all about having a better implementation of the concept of nil. Any VALUE can have the ability to be nil. Not just pointers. And by not using an optional, you represent the fact that the value can't be nil.
If you don't see that this is a step forward, then that's your lack of understanding, not a lack of progress by Swift. Sorry, but that's the way it is.
And when interoperating with C/C++/Objective-C, Swift won't really protect you any better.
Wrong. The Obj-C language has been updated to markup APIs for which nil is a legal argument or result. And all of the Apple Obj-C APIs have been marked up as appropriate. Swift understands this and so you get/pass optionals when appropriate. So you get all the benefits of optionals when calling Obj-C libraries.
<quote>A pointer unable to contain nil doesn't make any sense.</quote>
NO. You really need to look at optionals. They are one of the best new features of Swift.
I can even show you how a pointer that is guaranteed not to be nil can be done in another language.
if (foo==nil) {
return;
}
bar = foo;
In this scenario, bar is a pointer that is guaranteed not to be nil. From that point on you can do whatever you like with bar and you never again need to check it for nil. You are in no risk of dereferencing nil. Well Swift gives that within the language. Such that I could pass bar around to other methods, and they will always know that that value is not nil.
It's even more useful in formal APIs. In other languages, the documentation says whether a parameter or a result can be nil or not. In Swift, the code says that.
<quote>That would be like an integer unable to contain zero.</quote>
No, no, no. Zero is a value. Nil is the lack of a value. You're confused because most languages implement nil as a pointer with zero in it. But there is no connection between zero and nil.
<quote>but also runs the risk of making for very ugly codebases where multiple languages are used together.</quote>
Swift and C/Obj-C don't ever exist in the same files. Though they may exist in the same project, and call each other. So there's no ugliness. And having multiple languages plus various other types of source file are the norm for significant projects.
Yes. A pointer to int can be nil, and that is different from an integer holding a value of zero.
No, that's not at all what I asked. That's the same as C. Take a look at optionals in Swift. It's very clear from your lack of understanding of my questions that they offer something very useful that you haven't come across before.
"Throws" declarations are available in Java, and can be compiler-enforced.
OK, that's the declaration side. But there's no equivalent of the "try" keyword required before calling a method with can throw. The necessity for that keyword shows clearly what blocks of code you need to enclose in a catch, and which you do not.
No, Britain developed it's empire earlier than that. And for sure it was massive. But the the 20th century was the period of decline. For sure before the 20th century Britain was the most vicious empire. But the USA took that title over in the 20th century.
1) That's only one of the options then. Where's the pointer that cannot contain nil?
Also take an integer type. Does go differentiate between 0 and nil? If not it's not got any equivalent of optionals.
2) I don't know Java well, it's about 20 years since I did some as a student. But Swift marks the definition of any method that can return an error with the keyword "throws". Likewise when calling a method that can throw an error, you have to prefix the call with the keyword "try". They make methods that can fail obvious from both sides of the contract. It means that the programmers is always alerted to a potential error situation. I believe this is a significant improvement on Java exceptions.
5) Sure, preconditions are not a new idea. I first came across them in Eiffel, again 20 years ago. But most popular languages don't support them, except by utilising more general if statement or asserts. For Swift, guard ties in with optionals to automatically provide the guaranteed-not-to-be-nil pointer or value after the guard statement has rejected nil values. The programmer doesn't need to remember that they've excluded nils at the beginning of the method, the language has it modelled explicitly.
There's nothing specific about Swift that makes it "highly optimizable"
I'm afraid Chris Lattner knows better than you do. Every feature was designed with an eye to optimisation. Take for example the, shall we say novel, array behaviour that everyone was complaining about last year. The reason was they were designed to be highly optimisable. Well array behaviour has become more as one would expect now, but that original behaviour is an insight into the design for optimisation process.
I agree with you that it's mainly of interest to Apple developers. But you underestimate it when you imagine that there's not much new in there. Apple have not simply copied features from other languages. The developer of LLVM has taken the opportunity to write a language that's engineered to to compile to fast code, and to minimise common sources of bugs and security issues. And he and his team have considered these from first principles, not just copied.
It may be no more popular outside Apple platforms than Mono is. But who cares?
C and Obj-C.
Not C++. C++ can exist in the same project, but you can't call C++ apis. You'd need to write some wrappers.
What?! The US is an enormous war monger! They have started more wars in the last century than any other country!
There's a single file in a project that lists all the C header files you want to use. They are then available to any Swift code. You don't have to do anything more.
As I said it doesn't satisfy ANY of the requirements.
The requirements are that it is able to call the Cocoa API, and that it is fast enough for systems programming - the latter being largely done by being designed from scratch to be highly optimisable.
And there's little resemblance to Java, beyond the certain commonality that all modern language syntax has. Take a chunk of code in the two languages and they look very different.
The whole apple-didn't-need-to-write-a-new-language argument is just ill-informed.
That's not a reason to do wholesale rewrites. Only to break out the profiler and do optimisations. Possibly rewriting very small parts.
No. C#Âis a Java like language. ANd it doesn't fulfill any of the requirements that defined Swift.
There's something wrong with your brain if you can't see that #5 *IS* a mainstream language.
A burgeoning market I believe. Last I saw it was estimated $35m (all handsets included) in revenue. The total software market is estimated $400b. Swift can be #1 for developing iOS apps, but it is still insignificant against the overall software market which uses non-Apple languages.
Phones are the most common computing devices these days, and people buy more software for them. Albeit at cheaper prices.
My point is even if Swift gets to #1 for iOS apps, its marketshare will be so small that it may as well be statistical noise.
Then your point is stupid. The very least that's going to happen is it's going to replace Obj-C in the ratings, and that's currently number 5.
The EU got exactly what demanded.
Whether that was a useful thing is a different question, and not relevant to the right to be forgotten.
What about reshaping the whole program on the heap while it's running, almost without limitations?
Sounds awful.
Look Lisp does not answer ANY of the problems Swift addresses. It's irrelevant.
It's also a tiny niche language even after 30 odd years. Swift is already far more popular after only a year.
1) Pointers are not optionals. The whole point of optionals is they say which values can be null and which can't. For all types, including pointers.
2) Manual error code handling is available in any language and costs developer time, increases code size, and causes bugs. Swift 2 makes it clear which methods can fail with errors, both when defining and when calling a method, and then handles the error in a similar way to exceptions.
5) Guard is really simple, but it covers a particular bailing out if that programmers are doing all the time. It makes it explicit that this if is a precondition. And the fact that it always bails out of the current scope is guaranteed. It's going to get adopted by other languages for sure.
I won't argue that Go is also and interesting language. If I was coding for servers I'd certainly be looking at that. But for apps and system software Swift is looking very good to me. But yes, more for Apple use rather than other platforms.
It's still cutting out all the developers that use the native APIs, and this is a useless comparison.
It wasn't intended to be an argument. It was the answer to a question. Yes of course comparing languages intended for two different domains is pointless, but that's what was asked.
Lisp. Ha ha ha. If you think that's the answer, you don't know the question.