If Google did what you asked and required all words passed to the search box be included in the page, then it wouldn't give sensible results for queries like, "Who was that green ogre in a Disney movie?". If you're not getting the search results you want, try using natural language to provide more context.
What is the context of this search? Why are you searching for alpha.beta? If you provide the context in the search query, it's much more likely to work. It's often best these days to word the query as a question.
How could this possibly be implemented? How would you define "broader" or "narrower"? If I'm doing a search for "black cat", what would a broad search look like? A narrow search?
That doesn't work either, because is the result +infinity or -infinity? In mathematics, this divide may be doable in some situations as a limit, but the limit as x -> 0 of 1/x is different depending upon whether it's approaching zero from the negative side or the positive side. And the computer has no notion of limits in this context, it makes no sense to resolve a number divided by zero to anything at all. And, of course, as others have mentioned there's also the problem with 0/0.
There is simply no way to have a consistent arithmetic system while still allowing divide by zero, of any number. If you tried to actually implement this in general, and had a significant number of divides by zero, you'd quickly find that your results were becoming corrupted by the divides.
Then why do you keep claiming that the optional system of Swift allows a user to be certain that a value exists, and that this is somehow special?
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). This is no different from many other languages. There's just a slight difference in syntax.
From the way you're talking about optionals, it sounds to me like you've been programming in Objective-C for a long time, and haven't looked very much at other languages any time recently.
Aside from invoking undefined behavior, in C++ a function with any signature below can never be passed an unallocated object:
In Go, a function with this signature cannot ever be passed an unallocated object:
func myFunc(a MyStruct) { ...
}
The only danger here comes when you try to dereference a pointer to get the value which is passed to one of these functions: you have to check that pointer for nil/null first. But Swift has the same issue: you have to check an optional for nil before assigning an optional to a value.
You also seem to be confused by my calling "nil" "the zero value for a pointer". For Go, this does not mean a literal zero ("nil" is a special value in Go, not an integer like NULL in C). The "zero value" in Go is the default value of any variable. If you create an object of pointer type and don't assign it anything, it will be set to "nil". For a string, the zero value is the empty string. For a struct, the zero value has all members of the struct set to their zero values.
I think the reason you think these are so special is because in Objective-C and Swift, whether an object is passed by value or reference depends upon the type of the object. In C++ or Go, you always pass by value, pointer, or reference explicitly (though there are no references in Go). This is the only real difference between Swift optionals and Go pointers: in Swift, whether or not a function can modify the passed parameter depends upon the parameter's type. In Go, it's determined by whether or not the variable is a pointer.
Small addendum: another option is to use a complete sentence. Google has been working pretty hard on natural language processing, and does a fairly good job of understanding sentences. I imagine other search engines have made similar strides.
Oh, it's definitely still possible. See here for example.
Beyond just the special operators, one of the key things to recognize is that today Google's search engine understands the context of words. If Google has misunderstood and thinks you're talking about a different definition of "Apple", then add a keyword that is only relevant to what you are searching for (e.g. "apple fruit" will generally only include mentions of the fruit, not the company).
If you don't think the ad results are relevant to you, or dislike the idea of ads, ignore them. They are clearly marked (you should be able to do a search for "Toyota" to see what ad results look like). The ads don't impact the other search results.
Pretty sure Google is very much aware that if they don't return relevant results, users will go somewhere else to do their searches. Simply not annoying users is not enough: if Bing or some other search engine gets a reputation for returning better results, people will switch.
Google (and all other search engines) try their best to return the results the user has asked for. It's never going to be perfect at doing this, if only because people use the same phrases in different ways from time to time. If Google (or the search engine of your choice) is returning results that aren't what you want, then your best option is to make the query more specific. Either add relevant keywords, search for a phrase instead of individual words (using quotes), or exclude some other keywords (in Google, prepend - to the beginning of the word you want to exclude...other search engines are probably similar).
Also, if Google is returning crappy results for some query or other, feel free to send feedback (link is at the bottom of the page). I'm sure other search engines have similar functionality.
The quotes tell Google to search for the entire phrase instead of each word individually. If the phrase is too specific, it won't find anything, so often with error messages it's a good idea to trim out some of the more specific things.
Except other languages do have the ability to ensure that a value exists. These are generally called values or references. Java is an exception here, as all object variables are references, and references in Java can contain null (even there there are annotations and static analysis that makes these safe, if a bit less convenient). But in C, C++, Go, and most other languages, value types or references cannot contain null/nil.*
As near as I can tell, however, the only pointers available in Swift are UnsafePointer and variants thereof. These seem to be simple wrappers around C-style pointers, and can always contain nil. The base Swift language doesn't appear to have any pointer types at all (with optionals taking the place of pointers in the language).
And yes, nil is the zero value for a pointer. A pointer's value is the location of another value, with nil indicating that it points to no value. You seem to be confusing pointers with the values they point to.
* Provided the reference is initialized from a value type in C++. Pointers in C++ carry their lack of safety forward regardless. And when interoperating with C/C++/Objective-C, Swift won't really protect you any better.
A pointer unable to contain nil doesn't make any sense. That would be like an integer unable to contain zero. If you want something that must be assigned a value, then let it be a value parameter and be done with it. The only real difference here is that Swift uses value assignment for optionals.
It sounds like what you're trying to describe is Swift's concept of immutable pointers, which cannot be nil unless initialized to nil. This concept is unnecessary in a language like Go which doesn't directly interoperate with C.
Come to think of it, that may be the one thing that does make Swift stand out: it can interoperate with C, C++, and Objective-C. That feature is kinda neat, I suppose, but is also a liability. It does mean people can avoid using SWIG, but also runs the risk of making for very ugly codebases where multiple languages are used together.
Yes. A pointer to int can be nil, and that is different from an integer holding a value of zero.
"Throws" declarations are available in Java, and can be compiler-enforced. They have two classes of exceptions: checked and unchecked exceptions. Unchecked exceptions (runtime exceptions) are expected to be for unrecoverable errors. They can be caught, but usually aren't (note: there is some disagreement among Java developers about whether or not to use uncaught exceptions). Exceptions that are expected to be thrown during normal operation must be caught or you get a compile error (may be disabled with some compiler options, but I'm not certain....my company always leaves that check enabled). Whether or not an exception must be part of a throws statement and/or caught is determined by the Exception's type.
Erlang is a really different language. Almost purely functional, and with no object types (though some claim that its process-oriented system is effectively object-oriented). The two are similar in message passing, but there are a lot of differences. In particular, Erlang really isn't a c-family language at all, while Go is (along with Java, Swift, C#, and others).
1) There's really not much difference between optionals and Go's pointers. Variables in Go cannot be uninitialized. They have to contain a valid value, and the default value is the "zero" for the type. But a pointer can point to nil (which is the zero value for pointers). Curiously, Go also allows chaining of nil pointers, but the function specifies the behavior if the container is nil. The two implementations seem to be almost identical.
2) It depends. There's an argument to be had either way, and I don't really know what the right answer is. But the multiple return values make manual error handling in Go far less cumbersome than it is in C or C++. That said, if exceptions are your thing, Java is very good with those, and also shares nearly all of Swift's functionality.
5) I doubt it. It's something that can be handled by libraries just as easily, such as with the Preconditions class in Guava.
Go offers most of these, or has very similar functionality. Many are also in common with other languages.
As for Go, the differences from what you listed above are:
1. Go implements optional types using pointers (and, as with most languages, implements pointers in a much safer way than C).
2. Go's error handling is just as explicit, but does require you explicitly return the error (Go natively supports multiple return values). I'm not sure whether this is good or bad.
3. Go doesn't have tuples explicitly, but the ability to have multiple return values makes them less necessary. It's also possible to define structs inline (It's a little verbose, as you have to specify the type, but it's not too bad).
4. Named parameters are one nice thing that Go lacks.
5. Guard is just syntactical sugar around an if statement. It's nice, I guess, in that it helps to enforce better programming practices, but it's not anything particularly interesting.
6. Swift isn't a particularly fast language, except perhaps compared with Objective-C, which has some truly horrible performance characteristics in places.
They are different languages, with their own benefits and drawbacks, but I just don't see anything here that Swift offers that is all that special (and yes, Go has a playground as well).
Go's big differentiator, for instance, is its support of channels. Channels offer a paradigm for multithreaded processing that is quite different from what other languages offer. Most languages, for example, make use of mutexes to keep concurrent processes safe. Go, on the other hand, implements multithreading as communication: if thread A writes to a channel, and thread B reads from it, thread B will wait until thread A has its value ready. This is the main feature that makes Go so useful for server applications.
Some also appreciate the language's simplicity (the main design philosophy of Go was to make the base language as small as possible while supporting all of the main programming paradigms). One result of this decision is that generic programming can be extremely verbose (you can use interfaces to allow a function to accept anything that implements that interface, and there's a reflection API that lets you do different things with different types passed...it's rather clunky, but functional). Overall, this makes programming in the language rather weird.
Pretty much the only thing that sets Swift apart is the fact that Apple is pushing the language. It does appear to be quite a bit better than Objective-C (which has some truly horrific functionality, such as no type safety for containers and runtime errors for invalid message calls). But I really doubt it will make all that much headway into projects which aren't targeting Apple products. It's good, but I doubt many teams will see a reason to switch.
Eh. As near as I can tell, Swift is very similar to Go, except without the channels but with a more traditional generics system. I have yet to see anything particularly different about it except for a few slick string manipulation operations. But those really aren't of that much value.
Just as with Objective-C, I doubt that hardly anybody else will make use of the language.
The problem is it just doesn't have all that much to offer for projects that are already making use of other languages. It's got a few slick features, but it can't really stand out all that much and the library support is going to be very far behind more mature languages for a long time (if not forever).
I was actually pretty impressed at how close it came to creating sensible cards, and pretty funny when it made small errors that made the cards absurd (such as the card with, "At the beginning of each player's upkeep, sacrifice a white Zombie creature").
Getting a computer to generate understandable language is an extremely difficult problem, and all neural networks have an issue with long-tail errors (that is, a small fraction of the results are always ridiculously inaccurate, no matter how good your neural net is). Getting a computer to generate meaningful language is an order of magnitude more difficult than that.
It looks like this only applies to older versions of the Ask toolbar. According to the link in the post, "The latest version of this application is not detected by our objective criteria, and is not considered unwanted software."
I do hope that their "objective criteria" will help to keep the Ask toolbar from being quite as annoying as it was, however.
It's not the language nearly as much as it's more general software development skills such as algorithms, data structures, algorithmic complexity, and design patterns. It's really easy to transition between languages and shore up your own holes in knowledge by keeping links to reference resources (or books).
The general practice of knowing how to translate an idea into a workable piece of code is far, far more important. The individual language is just the medium through which you're working. Different languages have somewhat different toolboxes (with a lot of overlap), but overall the general concepts are the same. Focus on the software design fundamentals. You can pick up a new computer language within a few weeks whenever you need to.
And there are things we can do to replace fossil fuels that will make most peoples' lives better due to the lower environmental damage of nearly every other energy source (whether or not you include CO2 emissions as "environmental damage").
And in deciding that there "was enough wrong with how climate research is currently conducted," did you actually ever speak to an actual climate scientist? Did you ever learn how they do their work? I doubt it. I bet you've just read a bunch of bullshit misinformation repeated from conservative think tanks.
Here's a hint: if you want to learn about science, listen to scientists. Not political hacks.
Slashdot Mirror
If Google did what you asked and required all words passed to the search box be included in the page, then it wouldn't give sensible results for queries like, "Who was that green ogre in a Disney movie?". If you're not getting the search results you want, try using natural language to provide more context.
What is the context of this search? Why are you searching for alpha.beta? If you provide the context in the search query, it's much more likely to work. It's often best these days to word the query as a question.
How could this possibly be implemented? How would you define "broader" or "narrower"? If I'm doing a search for "black cat", what would a broad search look like? A narrow search?
You can also click the little globe button to the right of "search tools" to get unpersonalized results.
That doesn't work either, because is the result +infinity or -infinity? In mathematics, this divide may be doable in some situations as a limit, but the limit as x -> 0 of 1/x is different depending upon whether it's approaching zero from the negative side or the positive side. And the computer has no notion of limits in this context, it makes no sense to resolve a number divided by zero to anything at all. And, of course, as others have mentioned there's also the problem with 0/0.
There is simply no way to have a consistent arithmetic system while still allowing divide by zero, of any number. If you tried to actually implement this in general, and had a significant number of divides by zero, you'd quickly find that your results were becoming corrupted by the divides.
Then why do you keep claiming that the optional system of Swift allows a user to be certain that a value exists, and that this is somehow special?
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). This is no different from many other languages. There's just a slight difference in syntax.
From the way you're talking about optionals, it sounds to me like you've been programming in Objective-C for a long time, and haven't looked very much at other languages any time recently.
Aside from invoking undefined behavior, in C++ a function with any signature below can never be passed an unallocated object:
void my_function(MyClass a);
void my_function(MyClass& a);
void my_function(const MyClass& a);
In Go, a function with this signature cannot ever be passed an unallocated object:
func myFunc(a MyStruct) {
...
}
The only danger here comes when you try to dereference a pointer to get the value which is passed to one of these functions: you have to check that pointer for nil/null first. But Swift has the same issue: you have to check an optional for nil before assigning an optional to a value.
You also seem to be confused by my calling "nil" "the zero value for a pointer". For Go, this does not mean a literal zero ("nil" is a special value in Go, not an integer like NULL in C). The "zero value" in Go is the default value of any variable. If you create an object of pointer type and don't assign it anything, it will be set to "nil". For a string, the zero value is the empty string. For a struct, the zero value has all members of the struct set to their zero values.
I think the reason you think these are so special is because in Objective-C and Swift, whether an object is passed by value or reference depends upon the type of the object. In C++ or Go, you always pass by value, pointer, or reference explicitly (though there are no references in Go). This is the only real difference between Swift optionals and Go pointers: in Swift, whether or not a function can modify the passed parameter depends upon the parameter's type. In Go, it's determined by whether or not the variable is a pointer.
Small addendum: another option is to use a complete sentence. Google has been working pretty hard on natural language processing, and does a fairly good job of understanding sentences. I imagine other search engines have made similar strides.
Oh, it's definitely still possible. See here for example.
Beyond just the special operators, one of the key things to recognize is that today Google's search engine understands the context of words. If Google has misunderstood and thinks you're talking about a different definition of "Apple", then add a keyword that is only relevant to what you are searching for (e.g. "apple fruit" will generally only include mentions of the fruit, not the company).
If you don't think the ad results are relevant to you, or dislike the idea of ads, ignore them. They are clearly marked (you should be able to do a search for "Toyota" to see what ad results look like). The ads don't impact the other search results.
Pretty sure Google is very much aware that if they don't return relevant results, users will go somewhere else to do their searches. Simply not annoying users is not enough: if Bing or some other search engine gets a reputation for returning better results, people will switch.
Google (and all other search engines) try their best to return the results the user has asked for. It's never going to be perfect at doing this, if only because people use the same phrases in different ways from time to time. If Google (or the search engine of your choice) is returning results that aren't what you want, then your best option is to make the query more specific. Either add relevant keywords, search for a phrase instead of individual words (using quotes), or exclude some other keywords (in Google, prepend - to the beginning of the word you want to exclude...other search engines are probably similar).
Also, if Google is returning crappy results for some query or other, feel free to send feedback (link is at the bottom of the page). I'm sure other search engines have similar functionality.
The quotes tell Google to search for the entire phrase instead of each word individually. If the phrase is too specific, it won't find anything, so often with error messages it's a good idea to trim out some of the more specific things.
Except other languages do have the ability to ensure that a value exists. These are generally called values or references. Java is an exception here, as all object variables are references, and references in Java can contain null (even there there are annotations and static analysis that makes these safe, if a bit less convenient). But in C, C++, Go, and most other languages, value types or references cannot contain null/nil.*
As near as I can tell, however, the only pointers available in Swift are UnsafePointer and variants thereof. These seem to be simple wrappers around C-style pointers, and can always contain nil. The base Swift language doesn't appear to have any pointer types at all (with optionals taking the place of pointers in the language).
And yes, nil is the zero value for a pointer. A pointer's value is the location of another value, with nil indicating that it points to no value. You seem to be confusing pointers with the values they point to.
* Provided the reference is initialized from a value type in C++. Pointers in C++ carry their lack of safety forward regardless. And when interoperating with C/C++/Objective-C, Swift won't really protect you any better.
A pointer unable to contain nil doesn't make any sense. That would be like an integer unable to contain zero. If you want something that must be assigned a value, then let it be a value parameter and be done with it. The only real difference here is that Swift uses value assignment for optionals.
It sounds like what you're trying to describe is Swift's concept of immutable pointers, which cannot be nil unless initialized to nil. This concept is unnecessary in a language like Go which doesn't directly interoperate with C.
Come to think of it, that may be the one thing that does make Swift stand out: it can interoperate with C, C++, and Objective-C. That feature is kinda neat, I suppose, but is also a liability. It does mean people can avoid using SWIG, but also runs the risk of making for very ugly codebases where multiple languages are used together.
Yes. A pointer to int can be nil, and that is different from an integer holding a value of zero.
"Throws" declarations are available in Java, and can be compiler-enforced. They have two classes of exceptions: checked and unchecked exceptions. Unchecked exceptions (runtime exceptions) are expected to be for unrecoverable errors. They can be caught, but usually aren't (note: there is some disagreement among Java developers about whether or not to use uncaught exceptions). Exceptions that are expected to be thrown during normal operation must be caught or you get a compile error (may be disabled with some compiler options, but I'm not certain....my company always leaves that check enabled). Whether or not an exception must be part of a throws statement and/or caught is determined by the Exception's type.
Erlang is a really different language. Almost purely functional, and with no object types (though some claim that its process-oriented system is effectively object-oriented). The two are similar in message passing, but there are a lot of differences. In particular, Erlang really isn't a c-family language at all, while Go is (along with Java, Swift, C#, and others).
1) There's really not much difference between optionals and Go's pointers. Variables in Go cannot be uninitialized. They have to contain a valid value, and the default value is the "zero" for the type. But a pointer can point to nil (which is the zero value for pointers). Curiously, Go also allows chaining of nil pointers, but the function specifies the behavior if the container is nil. The two implementations seem to be almost identical.
2) It depends. There's an argument to be had either way, and I don't really know what the right answer is. But the multiple return values make manual error handling in Go far less cumbersome than it is in C or C++. That said, if exceptions are your thing, Java is very good with those, and also shares nearly all of Swift's functionality.
5) I doubt it. It's something that can be handled by libraries just as easily, such as with the Preconditions class in Guava.
Go offers most of these, or has very similar functionality. Many are also in common with other languages.
As for Go, the differences from what you listed above are:
1. Go implements optional types using pointers (and, as with most languages, implements pointers in a much safer way than C).
2. Go's error handling is just as explicit, but does require you explicitly return the error (Go natively supports multiple return values). I'm not sure whether this is good or bad.
3. Go doesn't have tuples explicitly, but the ability to have multiple return values makes them less necessary. It's also possible to define structs inline (It's a little verbose, as you have to specify the type, but it's not too bad).
4. Named parameters are one nice thing that Go lacks.
5. Guard is just syntactical sugar around an if statement. It's nice, I guess, in that it helps to enforce better programming practices, but it's not anything particularly interesting.
6. Swift isn't a particularly fast language, except perhaps compared with Objective-C, which has some truly horrible performance characteristics in places.
They are different languages, with their own benefits and drawbacks, but I just don't see anything here that Swift offers that is all that special (and yes, Go has a playground as well).
Go's big differentiator, for instance, is its support of channels. Channels offer a paradigm for multithreaded processing that is quite different from what other languages offer. Most languages, for example, make use of mutexes to keep concurrent processes safe. Go, on the other hand, implements multithreading as communication: if thread A writes to a channel, and thread B reads from it, thread B will wait until thread A has its value ready. This is the main feature that makes Go so useful for server applications.
Some also appreciate the language's simplicity (the main design philosophy of Go was to make the base language as small as possible while supporting all of the main programming paradigms). One result of this decision is that generic programming can be extremely verbose (you can use interfaces to allow a function to accept anything that implements that interface, and there's a reflection API that lets you do different things with different types passed...it's rather clunky, but functional). Overall, this makes programming in the language rather weird.
Pretty much the only thing that sets Swift apart is the fact that Apple is pushing the language. It does appear to be quite a bit better than Objective-C (which has some truly horrific functionality, such as no type safety for containers and runtime errors for invalid message calls). But I really doubt it will make all that much headway into projects which aren't targeting Apple products. It's good, but I doubt many teams will see a reason to switch.
Eh. As near as I can tell, Swift is very similar to Go, except without the channels but with a more traditional generics system. I have yet to see anything particularly different about it except for a few slick string manipulation operations. But those really aren't of that much value.
There's a fairly good chance that Apple is going to push to have their OS transitioned over to Swift.
Just as with Objective-C, I doubt that hardly anybody else will make use of the language.
The problem is it just doesn't have all that much to offer for projects that are already making use of other languages. It's got a few slick features, but it can't really stand out all that much and the library support is going to be very far behind more mature languages for a long time (if not forever).
I was actually pretty impressed at how close it came to creating sensible cards, and pretty funny when it made small errors that made the cards absurd (such as the card with, "At the beginning of each player's upkeep, sacrifice a white Zombie creature").
Getting a computer to generate understandable language is an extremely difficult problem, and all neural networks have an issue with long-tail errors (that is, a small fraction of the results are always ridiculously inaccurate, no matter how good your neural net is). Getting a computer to generate meaningful language is an order of magnitude more difficult than that.
It looks like this only applies to older versions of the Ask toolbar. According to the link in the post, "The latest version of this application is not detected by our objective criteria, and is not considered unwanted software."
I do hope that their "objective criteria" will help to keep the Ask toolbar from being quite as annoying as it was, however.
It's not the language nearly as much as it's more general software development skills such as algorithms, data structures, algorithmic complexity, and design patterns. It's really easy to transition between languages and shore up your own holes in knowledge by keeping links to reference resources (or books).
The general practice of knowing how to translate an idea into a workable piece of code is far, far more important. The individual language is just the medium through which you're working. Different languages have somewhat different toolboxes (with a lot of overlap), but overall the general concepts are the same. Focus on the software design fundamentals. You can pick up a new computer language within a few weeks whenever you need to.
And there are things we can do to replace fossil fuels that will make most peoples' lives better due to the lower environmental damage of nearly every other energy source (whether or not you include CO2 emissions as "environmental damage").
And in deciding that there "was enough wrong with how climate research is currently conducted," did you actually ever speak to an actual climate scientist? Did you ever learn how they do their work? I doubt it. I bet you've just read a bunch of bullshit misinformation repeated from conservative think tanks.
Here's a hint: if you want to learn about science, listen to scientists. Not political hacks.