I said the same thing in an earlier topic, and one iFan responded by saying that ultrathin is proof of competence in engineering from Apple. Of course he did not understand when I said that a good engineer would have realized the problems that an ultrathin chassi would cause to the phone.
I used Slackware as desktop for a long time. Works, but the problem is that some applications are gaining ever increasing Ubuntu or Debian-centric dependencies. And so it is increasingly difficult to have a Slackware desktop that can keep up without ever larger hacks
I do not want to know the performance in SLI, I want to know the normal performance that the buyer would have a single card. And compared to the currently existing cards on the market.
Me too. Why I would allow advertising on my browser when all it does is try to lock the system using all the CPU time for stupid animations or videos, promotes highly questionable "products" such as the infamous "CleanMyPC", or plain and simply try to install hostile programs to take control of my computer?
It is because the legalese is deliberately made to be incomprehensible by anyone other than a lawyer. If you or I were able to understand what is written, then we would not need to pay lawyers.
"...Though I can't see how they're still allowed to teach chemistry"
Without it they have no way to make fertilizer bombs to spread the religious mumbo-jumbo of them. Seriously, we can not just surround them with barbed wire and shoot any of them that try to go out spreading this cancer for the rest of the world? where are the atomic bombs when you really need them?
"Elegance" is something very, very subjective. A "ultrathin" phone becomes more expensive because it is more difficult to be manufactured, becomes more fragile (poor resistance against bending, for example) and have higher operating restrictions (heat needs to go somewhere). Replacing all this in the name of a supposed elegance does not seem anything sensible for me.
"...why wouldn't they just make the case 1mm thicker instead of risking the lawsuits"
Who knows? We're talking about Apple here, so anything is possible. I personally would prefer a thicker device (and therefore higher capacity battery), I do not understand this obsession with "ultrathin" devices. But that said, note that the point of the article is actually Apple trying to hide what she considers a "problem" in her product, and this is not a behavior that is expected of a responsible company.
*clap clap clap* What a big moderation system failure we have here... "The Dumb Guy" (a freak from another topic, nothing with the "shutdown now") seens to have friends with infinite mod points. Well done./ well done. (sarcasm)
I understand, but part of the problem is not knowing for sure what kind of type Javascript will set for your variable. As example, the first time I saw this was one occasion where I had to get input from a user where it should be an integer, but the interpreter assumed it was a string and then the "+" operator made a concatenation instead of an addition (the other variable in the operation was an integer). That's why I consider the operation as non-deterministic, because you know that the "+" operator will do a concatenation for strings, but the interpreter may decide that your variables are integers (or vice versa).
Nice change? Uh... Dumb guy, you are the very first one that I have to give a full explanation and you still could not understand what I mean. You can stop swinging your virtual d*** and pay attention please? You claim to have knowledge of "super-genius" to come here for gratuitous offends a person that you do not have a clue who he is, and yet you're showing me the knowledge of a script kiddie:-(
Last time: I see is only you that do not know what is "deterministic". When you can't say what will be the result of an operation using the "+" because it is not possible to determine which will be the type of the variables involved (or values if you prefer which gives the same), then the result of the operation is non-deterministic. You simply have no way to tell for sure if the result will be a concatenation or addition without being sure if the variables involved are strings, integers, etc. This happens because Javascript can guess wrong the type used (or change it because of previous operations), after all it do not have strong-typed variables (or values if you like, but is the same in pratice).
The "ugly hack" is something simple as this:
var test = (unknow type input) + "";
to be sure the "test" will be recognized as a string. I call it "ugly" because in my humble opinion the correct way to do this would be:
String test = (unknow type input);
or better:
String test = function_to_convert_to_string((unknow type input));
but this will only works on a strong-typed language.
Footnote: I'm not going to answer any more because I have more important things to do than try to explain to you something you do not want to understand, Dumb guy... Think what you want about me, since the only thing that matters to me is that my several clients are very happy with my supposed "terrible job" and their systems work perfectly, even in situations they should not be able to function;-)
This is not funny, dumb guy. Learn how to read, or I need to use pictures? Well, I try again: I said the behavior of the "+" operator in Javascript is non-deterministic because you have no way to guarantee the type of the variables involved (string, integer, double, etc). The parser sometimes assumes the type correctly but sometimes not, and that is the problem when you use the operator, it needs to know the type of the variables involved in order to decide whether it will be a sum or a concatenation. And the best part is that what you thought set as a string can be transformed into integer and vice versa depending on the interpreter operations that you may have done previously or user inputs, so that depending on the user input your variable may turn in some type different from the expected and thereby generates an unexpected result when using the "+" operator (and therefore the hack to ensure that what should be a string remains a string so that the operation using the "+" return the expected result for a string).
In short, my problem with this is not "nonsense". Is simply the result of having a "+" operator for both concatenation and sum in a language without strong-typed variables. As an example Java does not have this problem because a string variable would always be a string, and so the operation with the "+" becomes deterministic. The problem is two-fold and you blindly read only half of it, super-genius...;-)
Wow... You are just like "The Clueless One" (another Slashdot "super-genius"). Sorry dumb guy, but I know how the "+" operator works, and I also knows that it is not a very good idea on a weak-typed language for reasons I already explained before and I will not repeat again. The ugly hack I mentioned earlier just makes sure that a given string variable will be interpreted as a string when I need it to be a string, just that. Something it would be completely unnecessary if the Javascript was strong-typed.
There IS a "way to say with certainty what the interpreter will do". You just haven't taken the few minutes required to find out how!
And I figured, dumb guy. But the fact that I have determined how to overcome this defect of the language does not make this anomalous behavior becomes "acceptable" as you seem to think. Fixable or not is still a behavior that the Javascript should not have.
You're dumber than I thought. If you were better at interpreting text and had dealt more with the case described, you would have understood what I mean by random is that there is no way to say with certainty what the interpreter will do since there's no telling for sure if he will treat the "+" operator as a sum of integers or a concatenation of strings. It's happened to me more than once, I thought I made it clear to the interpreter that a variable would be a string (for example: var some_variable = "1") and later I found out he decided to treat the variable as a integer anyway, and the only solution was to force the variable as string immediately before the desired operation using a ugly hack. while in Java if you use the "+" operator between a string and an integer you will always have a string as a result, regardless of the variables positions or operations that have been made with them previously.
Is because JavaScript seems to randomly decide whether it will return a "11" or "2", while in a strong-typed language the result is deterministic. On Java you knows that "A" is a string and "B" is a integer, so A + B will always returns a string "11". Whereas Javascript are not sure about the types used in A and B, so therefore is no way to be sure about what he is going to return.
I usually have a worse problem, which is when Javascript arbitrarily decides that my string variable is an integer or vice-versa. You create a string, but then you discovers - when trying to use a string function like split() - that Javascript decided to treat your string as a integer, making the split() fails without error messages.
Because variants are useful when you want to (or most common, you need to) make a generic function to handle some information where you have no way of knowing if the input parameter will be a string, integer, long, etc. Of course it is slower than dealing with a defined type, but is usually more convenient than trying to create a separate function for each possible entry type.
Is the same shit here in Brazil. 60% tax in all international purchases made by individuals under the guise of "protecting" a nonexistent national industry (nobody makes Intel i7 in Brazil as far as I know).
As long as is optional, is interesting to have it considering that the driver will not always be able to call for help in an emergency (And from the standpoint of first responders is also interesting that a car can automatically call for help when involved in an accident).
Slashdot Mirror
I said the same thing in an earlier topic, and one iFan responded by saying that ultrathin is proof of competence in engineering from Apple. Of course he did not understand when I said that a good engineer would have realized the problems that an ultrathin chassi would cause to the phone.
Here. What happens when your device is too thin (portuguese)
I used Slackware as desktop for a long time. Works, but the problem is that some applications are gaining ever increasing Ubuntu or Debian-centric dependencies. And so it is increasingly difficult to have a Slackware desktop that can keep up without ever larger hacks
I do not want to know the performance in SLI, I want to know the normal performance that the buyer would have a single card. And compared to the currently existing cards on the market.
Me too. Why I would allow advertising on my browser when all it does is try to lock the system using all the CPU time for stupid animations or videos, promotes highly questionable "products" such as the infamous "CleanMyPC", or plain and simply try to install hostile programs to take control of my computer?
Is the "legal basis" to the scam.
Is just another type of scam. Seems like the Nigerian prince finally became too obvious.
It is because the legalese is deliberately made to be incomprehensible by anyone other than a lawyer. If you or I were able to understand what is written, then we would not need to pay lawyers.
"...Though I can't see how they're still allowed to teach chemistry"
Without it they have no way to make fertilizer bombs to spread the religious mumbo-jumbo of them. Seriously, we can not just surround them with barbed wire and shoot any of them that try to go out spreading this cancer for the rest of the world? where are the atomic bombs when you really need them?
"Elegance" is something very, very subjective. A "ultrathin" phone becomes more expensive because it is more difficult to be manufactured, becomes more fragile (poor resistance against bending, for example) and have higher operating restrictions (heat needs to go somewhere). Replacing all this in the name of a supposed elegance does not seem anything sensible for me.
"...why wouldn't they just make the case 1mm thicker instead of risking the lawsuits"
Who knows? We're talking about Apple here, so anything is possible. I personally would prefer a thicker device (and therefore higher capacity battery), I do not understand this obsession with "ultrathin" devices. But that said, note that the point of the article is actually Apple trying to hide what she considers a "problem" in her product, and this is not a behavior that is expected of a responsible company.
*clap clap clap* What a big moderation system failure we have here... "The Dumb Guy" (a freak from another topic, nothing with the "shutdown now") seens to have friends with infinite mod points. Well done ./ well done. (sarcasm)
I understand, but part of the problem is not knowing for sure what kind of type Javascript will set for your variable. As example, the first time I saw this was one occasion where I had to get input from a user where it should be an integer, but the interpreter assumed it was a string and then the "+" operator made a concatenation instead of an addition (the other variable in the operation was an integer). That's why I consider the operation as non-deterministic, because you know that the "+" operator will do a concatenation for strings, but the interpreter may decide that your variables are integers (or vice versa).
Nice change? Uh... Dumb guy, you are the very first one that I have to give a full explanation and you still could not understand what I mean. You can stop swinging your virtual d*** and pay attention please? You claim to have knowledge of "super-genius" to come here for gratuitous offends a person that you do not have a clue who he is, and yet you're showing me the knowledge of a script kiddie :-(
;-)
Last time: I see is only you that do not know what is "deterministic". When you can't say what will be the result of an operation using the "+" because it is not possible to determine which will be the type of the variables involved (or values if you prefer which gives the same), then the result of the operation is non-deterministic. You simply have no way to tell for sure if the result will be a concatenation or addition without being sure if the variables involved are strings, integers, etc. This happens because Javascript can guess wrong the type used (or change it because of previous operations), after all it do not have strong-typed variables (or values if you like, but is the same in pratice).
The "ugly hack" is something simple as this:
var test = (unknow type input) + "";
to be sure the "test" will be recognized as a string. I call it "ugly" because in my humble opinion the correct way to do this would be:
String test = (unknow type input);
or better:
String test = function_to_convert_to_string((unknow type input));
but this will only works on a strong-typed language.
Footnote: I'm not going to answer any more because I have more important things to do than try to explain to you something you do not want to understand, Dumb guy... Think what you want about me, since the only thing that matters to me is that my several clients are very happy with my supposed "terrible job" and their systems work perfectly, even in situations they should not be able to function
This is not funny, dumb guy. Learn how to read, or I need to use pictures? Well, I try again: I said the behavior of the "+" operator in Javascript is non-deterministic because you have no way to guarantee the type of the variables involved (string, integer, double, etc). The parser sometimes assumes the type correctly but sometimes not, and that is the problem when you use the operator, it needs to know the type of the variables involved in order to decide whether it will be a sum or a concatenation. And the best part is that what you thought set as a string can be transformed into integer and vice versa depending on the interpreter operations that you may have done previously or user inputs, so that depending on the user input your variable may turn in some type different from the expected and thereby generates an unexpected result when using the "+" operator (and therefore the hack to ensure that what should be a string remains a string so that the operation using the "+" return the expected result for a string).
;-)
In short, my problem with this is not "nonsense". Is simply the result of having a "+" operator for both concatenation and sum in a language without strong-typed variables. As an example Java does not have this problem because a string variable would always be a string, and so the operation with the "+" becomes deterministic. The problem is two-fold and you blindly read only half of it, super-genius...
Wow... You are just like "The Clueless One" (another Slashdot "super-genius"). Sorry dumb guy, but I know how the "+" operator works, and I also knows that it is not a very good idea on a weak-typed language for reasons I already explained before and I will not repeat again. The ugly hack I mentioned earlier just makes sure that a given string variable will be interpreted as a string when I need it to be a string, just that. Something it would be completely unnecessary if the Javascript was strong-typed.
There IS a "way to say with certainty what the interpreter will do". You just haven't taken the few minutes required to find out how!
And I figured, dumb guy. But the fact that I have determined how to overcome this defect of the language does not make this anomalous behavior becomes "acceptable" as you seem to think. Fixable or not is still a behavior that the Javascript should not have.
You're dumber than I thought. If you were better at interpreting text and had dealt more with the case described, you would have understood what I mean by random is that there is no way to say with certainty what the interpreter will do since there's no telling for sure if he will treat the "+" operator as a sum of integers or a concatenation of strings. It's happened to me more than once, I thought I made it clear to the interpreter that a variable would be a string (for example: var some_variable = "1") and later I found out he decided to treat the variable as a integer anyway, and the only solution was to force the variable as string immediately before the desired operation using a ugly hack. while in Java if you use the "+" operator between a string and an integer you will always have a string as a result, regardless of the variables positions or operations that have been made with them previously.
Oh, sorry? The language behaves in a non-deterministic way and this is my fault? From what basement you are, clueless guy?
Is because JavaScript seems to randomly decide whether it will return a "11" or "2", while in a strong-typed language the result is deterministic. On Java you knows that "A" is a string and "B" is a integer, so A + B will always returns a string "11". Whereas Javascript are not sure about the types used in A and B, so therefore is no way to be sure about what he is going to return.
I usually have a worse problem, which is when Javascript arbitrarily decides that my string variable is an integer or vice-versa. You create a string, but then you discovers - when trying to use a string function like split() - that Javascript decided to treat your string as a integer, making the split() fails without error messages.
The difference is that the "+" operator in a strong-typed language works without causing nasty surprises for you.
Because variants are useful when you want to (or most common, you need to) make a generic function to handle some information where you have no way of knowing if the input parameter will be a string, integer, long, etc. Of course it is slower than dealing with a defined type, but is usually more convenient than trying to create a separate function for each possible entry type.
Is the same shit here in Brazil. 60% tax in all international purchases made by individuals under the guise of "protecting" a nonexistent national industry (nobody makes Intel i7 in Brazil as far as I know).
As long as is optional, is interesting to have it considering that the driver will not always be able to call for help in an emergency (And from the standpoint of first responders is also interesting that a car can automatically call for help when involved in an accident).