It's not a punishment for a crime. And Google isn't uniquely affected, the law applies to all search engines.
You show an inability to see beyond the parochial legislation of the USA, assuming that their priorities are a human universal. They are not. I don't expect you to open your mind, so I won't be answering any more.
Swift has optionals, improved error flow control constructs, values and structs as full UDTs, interactive experimentation with playgrounds, tuples, native fully unicode strings (not just UTF16), no implicit fall throughs on switches, optionally named parameters, associated values on enums, guard statement for preconditions, optimisation as a design goal of the language, functional programming methods.
I don't know Go, but I bet it hasn't got all those.
If you are converting a double to an int, you need to think about whether you want to round down or round up, for both positive numbers and negative. A step to make the conversion explicit is good, even if you are doing the most common thing.
Consistency is also an issue where a project has multiple coders. Where a method takes a float, it fucking annoys me when some people have variously put 0, 0.0, or 0.0f.
solving problems that don't need a solution, like fucking optionals.
Doesn't need a solution? The fact that you don't know when you receive a pointer whether it's allowed to be nil? It's a huge problem. Always has been. A very common cause of bugs. A very common case of error handling that is not done when it should be or done when there is no need.
And Obj-C translating a method called on a nil pointer to no-op generally just hides problems.
(I'm an iOS Obj-C developer on one of the most popular apps on the store. We haven't started using Swift yet, but now 2.0 is out I'll be pushing for that.)
Why would Apple "fanboys" give a damn whether developers on other platforms use Swift. It doesn't affect us. It was the Linux heads here that were complaining that swift wasn't cross platform. Well now it is. Take it or leave it, it doesn't matter to us.
It's actually designed to be more performant than Objective-C. The clue is in the name. Unless you opt in, Swift doesn't do dynamic despatch. It's also designed from the start to be easy for the compiler to optimise.
Swift can be slower than Objective-C if a naive translation of Obj-C to Swift code is done. However, writing an algorithm using using the best available features of Swift will generally mean Swift is far faster.
Objective-C isn't fast enough for many system frameworks, which is why even modern ones are often written in C. But Swift should be fast enough.
I doubt it. There's rarely a good reason to re-write existing code. I think they'll start doing new libraries in swift. Maybe even new APIs in existing libraries. But I don't see them doing a whole rewrite of Cocoa.
Still early days. Swift is mature enough for developers that are new to iOS/OSX to use. As yet there's no a huge incentive for Objective-C developers to change, especially when working on existing projects. But the time will come when creating a new project, and Swift will seem like the natural choice.
Heck there's still old code written in Cobol that's still in use by some organisations, but you wouldn't argue that Cobol isn't on it's way out.
And yes, it's only a matter of time before Apple is writing new libraries in Swift. Swift is absolutely intended to replace system code as well as app code.
Well not entirely different. The Swift object model runs on top of the Objective-C runtime. For the most part Swift doesn't have to call down to that runtime unless you are interacting with Objective-C. But it will if you mark a property as dynamic, regardless of interaction with Objective-C.
Not really, because iOS has native 3D APIs. Unity is used by some of the developers that are multi-platform. But those developers who are iOS only, and there are many, are probably not using Unity.
Objective-C never took off elsewhere because C++ was pretty much an equivalent (lacking runtime introspection but making up for that by being a little faster).
Swift on the other hand has a lot of desirable features, that are not available elsewhere. I've listed some in a post under the last Swift story we had. So either some other language takes on these features, or at least some non-Apple programmers are going to be attracted to Swift.
Library support is easy, as Swift can adopt C based libraries. Either calling directly, or wrapped.
All you're doing is claiming that you are the ultimate arbiter of what the more important right is rather than the US itself. Likewise, you're not. It's just an idea that you were brought up to believe. Like some people have a religion drummed into them.
Too many sites are impossible to get to. Google isn't.
It's nothing to do with censoring opinions. This is a right to be forgotten.
A right.
Your concept of free speech, that you are implicitly defending, is just another right. It's not more important. It just happens to be one that the US considers a higher priority. The US isn't the arbiter of the universal scale of which right is more important. Though Americans's often implicitly assume this.
You have to understand that Free Speech is only the most important right of the US. It's not the most important right in the rest of the world, where there are other rights at play.
That doesn't make the rest of the world wrong. It just means that the US isn't the sole arbiter of rights and wrongs that it thinks it is.
It is treaty law. It applies across the EU. It's not enough to pull out of France or Spain individually. Companies that want to defy EU decisions have to pull out of the entire EU.
I'm aware that that not all Google requests from the EU will be served by EU data centres. But I was just making the point that the argument that Google is a US company and thus shouldn't be subject to EU law is far from so clear cut.
It's still worthwhile because when searching for someone's name, hardly anyone will use a proxy server. People who are not already aware of the information and the fact that it's been withdrawn won't even try to circumvent the filter.
What's it trying to accomplish? For example some people's lives are ruined by "revenge porn". Imagine that there was video of you having sex, or some other activity you aren;t proud of. And every time someone searched for your name that video was a top result.
But beyond that, in Europe we have the concept of rehabilitation of offenders. That once a criminal has done their prison sentence and a period of time after that has passed, then their punishment is spent. They should be given the opportunity to be rehabilitated. One crime - other than the most serious ones - shouldn't ruin a persons entire life forever.
And Google have the choice of complying, or of closing down their EU operations and not doing business in the EU. The latter would take a huge chunk out of their revenue.
Slashdot Mirror
This has all been played out before with Microsoft and leveraging the Windows monopoly for IE. Not complying is not an option.
Wrong, both Pascal and MATLAB are below it.
More significantly that other young contender, Ruby, is below it.
And yes of course I mean phone app developers. Some Mac developers, but mainly phone developers.
Of course not. There are now variations going out regularly, I'm talking about new code.
And...?
It's not a punishment for a crime. And Google isn't uniquely affected, the law applies to all search engines.
You show an inability to see beyond the parochial legislation of the USA, assuming that their priorities are a human universal. They are not. I don't expect you to open your mind, so I won't be answering any more.
Swift has optionals, improved error flow control constructs, values and structs as full UDTs, interactive experimentation with playgrounds, tuples, native fully unicode strings (not just UTF16), no implicit fall throughs on switches, optionally named parameters, associated values on enums, guard statement for preconditions, optimisation as a design goal of the language, functional programming methods.
I don't know Go, but I bet it hasn't got all those.
If you are converting a double to an int, you need to think about whether you want to round down or round up, for both positive numbers and negative. A step to make the conversion explicit is good, even if you are doing the most common thing.
Consistency is also an issue where a project has multiple coders. Where a method takes a float, it fucking annoys me when some people have variously put 0, 0.0, or 0.0f.
solving problems that don't need a solution, like fucking optionals.
Doesn't need a solution? The fact that you don't know when you receive a pointer whether it's allowed to be nil? It's a huge problem. Always has been. A very common cause of bugs. A very common case of error handling that is not done when it should be or done when there is no need.
And Obj-C translating a method called on a nil pointer to no-op generally just hides problems.
(I'm an iOS Obj-C developer on one of the most popular apps on the store. We haven't started using Swift yet, but now 2.0 is out I'll be pushing for that.)
Why would Apple "fanboys" give a damn whether developers on other platforms use Swift. It doesn't affect us. It was the Linux heads here that were complaining that swift wasn't cross platform. Well now it is. Take it or leave it, it doesn't matter to us.
It's actually designed to be more performant than Objective-C. The clue is in the name. Unless you opt in, Swift doesn't do dynamic despatch. It's also designed from the start to be easy for the compiler to optimise.
Swift can be slower than Objective-C if a naive translation of Obj-C to Swift code is done. However, writing an algorithm using using the best available features of Swift will generally mean Swift is far faster.
Objective-C isn't fast enough for many system frameworks, which is why even modern ones are often written in C. But Swift should be fast enough.
What are you talking about? Swift supports C libraries just as much as Objective-C supports C libraries.
Maybe, when Apple release Swift for Linux, you can actually have a play with it, and begin to know what the fuck you're talking about.
I doubt it. There's rarely a good reason to re-write existing code. I think they'll start doing new libraries in swift. Maybe even new APIs in existing libraries. But I don't see them doing a whole rewrite of Cocoa.
Still early days. Swift is mature enough for developers that are new to iOS/OSX to use. As yet there's no a huge incentive for Objective-C developers to change, especially when working on existing projects. But the time will come when creating a new project, and Swift will seem like the natural choice.
Being "on the way out" means new code.
Heck there's still old code written in Cobol that's still in use by some organisations, but you wouldn't argue that Cobol isn't on it's way out.
And yes, it's only a matter of time before Apple is writing new libraries in Swift. Swift is absolutely intended to replace system code as well as app code.
Well not entirely different. The Swift object model runs on top of the Objective-C runtime. For the most part Swift doesn't have to call down to that runtime unless you are interacting with Objective-C. But it will if you mark a property as dynamic, regardless of interaction with Objective-C.
But most of the time you're not doing that.
Not really, because iOS has native 3D APIs. Unity is used by some of the developers that are multi-platform. But those developers who are iOS only, and there are many, are probably not using Unity.
Objective-C never took off elsewhere because C++ was pretty much an equivalent (lacking runtime introspection but making up for that by being a little faster).
Swift on the other hand has a lot of desirable features, that are not available elsewhere. I've listed some in a post under the last Swift story we had. So either some other language takes on these features, or at least some non-Apple programmers are going to be attracted to Swift.
Library support is easy, as Swift can adopt C based libraries. Either calling directly, or wrapped.
All you're doing is claiming that you are the ultimate arbiter of what the more important right is rather than the US itself. Likewise, you're not. It's just an idea that you were brought up to believe. Like some people have a religion drummed into them.
Too many sites are impossible to get to. Google isn't.
It's nothing to do with censoring opinions. This is a right to be forgotten.
A right.
Your concept of free speech, that you are implicitly defending, is just another right. It's not more important. It just happens to be one that the US considers a higher priority. The US isn't the arbiter of the universal scale of which right is more important. Though Americans's often implicitly assume this.
You have to understand that Free Speech is only the most important right of the US. It's not the most important right in the rest of the world, where there are other rights at play.
That doesn't make the rest of the world wrong. It just means that the US isn't the sole arbiter of rights and wrongs that it thinks it is.
It is treaty law. It applies across the EU. It's not enough to pull out of France or Spain individually. Companies that want to defy EU decisions have to pull out of the entire EU.
I'm aware that that not all Google requests from the EU will be served by EU data centres. But I was just making the point that the argument that Google is a US company and thus shouldn't be subject to EU law is far from so clear cut.
It's still worthwhile because when searching for someone's name, hardly anyone will use a proxy server. People who are not already aware of the information and the fact that it's been withdrawn won't even try to circumvent the filter.
What's it trying to accomplish? For example some people's lives are ruined by "revenge porn". Imagine that there was video of you having sex, or some other activity you aren;t proud of. And every time someone searched for your name that video was a top result.
But beyond that, in Europe we have the concept of rehabilitation of offenders. That once a criminal has done their prison sentence and a period of time after that has passed, then their punishment is spent. They should be given the opportunity to be rehabilitated. One crime - other than the most serious ones - shouldn't ruin a persons entire life forever.
And Google have the choice of complying, or of closing down their EU operations and not doing business in the EU. The latter would take a huge chunk out of their revenue.
They'd have to pull out of the entire EU. EU HQ and all data centres. And they'd have to give up all their customers (advertisers) in the EU.
Since we're being racist here, my experience of greeks are that they are thieving cunts.
Google has got two choices. They can use geolocation to serve different content for Google.com in the EU than outside. This is technically trivial.
Or they can stop serving google.com at all within the EU. Meaning that French citizens have to go through the censored google.fr domain.