So they continue to pimp their new processor power in their phones (we have an A4 in this! That's right, A4, the chip we just invented! Oh wait, now we have the A5, now the A6, A7.) And then keep bogging it down with new features in iOS that really shouldn't make that much of a difference in performance, but grind old phones to a halt, and the difference is a wash comparing new iPhone +new iOS with old iPhone + old iOS?
Your premise that newer phones don't have features that make a difference is simply false.
No. If going in your direction both break and fallthrough statements should be required.
Nonsense. The following case statement marks the end of a case. There is no need for an extra break statement to mark the obvious and usual flow. Neither for the compiler nor the programmer.
There is no better readability.
In most cases there is both better readability and reduced code, because the number of times switch statements fall through is tiny compared with how often they break.
(Note also: a case with multiple switch values isn't really a fall-through, other than because of C's primitive Other languages such as Pascal allow a list of values, and even ranges per case block.)
And removing a comment hardly qualifies as one less line of code.:-)
Removing your comment because there is a fallthrough statement is not what I'm talking about. It's all those break statements that are no longer needed that are the line savings.
Sorry, but the problem is with the C language, not the compiler, let alone the IDE. That compilers and IDEs have band-aid solutions to stop yourself creating a common bug just proves what a bad language decision it was.
Idiot. That's fall through only because that's the only way C has to do multiple switch values for one case. The right way to do this is to have proper support for multiple values per case. Like for example Pascal. Do you know Pascal, newbie?
Apple was a great language for the 1980s, and still has many things that are better than C++. But we can do a lot better than either of those 30 years on.
case superset : { init superset specific stuff }/* fall through to base for common initialization */ case base : { init stuff common to base and superset } break;
It's not useful at all. The times you deliberately want to fall through are vastly outnumbered by the times you don't. So rather than have a keyword to stop fall-though it makes more sense to have one that causes fall-through.
Your code would be:
case superset :
{ init superset specific stuff }
fallthrough; case base :
{ init stuff common to base and superset }
The result is better readability. Less lines of code. And many fewer bugs. For exactly the same functionality and execution speed.
There is plenty wrong with C...but that is such a minor thing, and useful many times.
Case fall through by default is NEVER useful. The most common way it's used is for having multiple case labels for a single block of code. Which is better implemented as a list of case labels rather than fall-through. As seen in Pascal for example.
In the ugly approach of having one section of code in one case falling through to then execute the next case as well, that would better be done by packaging up the common code into a sperate function and calling it from both places. Or if you are absolutely determined, by having a keyword to cause the fall-through in those very rare cases where it could be done.
Having it as default behaviour is a candidate for the most obvious bad design in computer language history.
Likewise, one of the great things about C is it does not "defend" instead it assumes the programmer is not an idiot.
Like most assumptions, that's a bad one. Most security issues and many of the other bugs too are down to this bad assumption. All programmers make mistakes and programming languages that help stop them are better than those that don't.
The number of times a fall-through in a switch statement has been useful must be outweighted at least a thousand times by the number of bugs that behaviour has caused.
Support for any unicode glyphs as variable/function names. Down to emoticons.
Just because it's possible doesn't mean that people generally will. XML tag names allow pretty much any Unicode character that wouldn't cause a parsing error, or would be impossible to distinguish. But people don't generally use emoticons as tag names.
iOS 8 will not be available in the STILL ON SALE iPhone 4.
False. The iPhone 4 was discontinued September 10, 2013.
It's successor, the iPhone 4S was first on sale October 14, 2011. Everyone who bought an iPhone 4 after that date knew they were buying an older model which would reach it's end of support sooner than the current model.
Apple stop providing older iPhones with OS updates when they are no longer powerful enough to support current OS release. They got it wrong once, by providing one two many OS updates for the iPhone 3G. And were heavily criticised for it - including by you. You can't have it both ways.
By contrast most Android phones sold NEVER get an OS update.
For the latest HumbleBundle, they choose some games that were available on both PC and Android.
If instead you wanted to make a different list of games that are available on PC and iOS, you could easily do so.
Thus the games in the HumbleBundle say precisely nothing about cross-compatibility. It does say something about the business model of HumbleBundle though.
It's time for Apple to move on to a new language, as Objective-C bears the marks of having evolved over many years, and still suffers from many of the design snafus of C.
Yet whatever language they move to must be completely compatible with Objective-C, such that the existing libraries still work, and existing projects can simply add new classes in the new language and keep the existing stuff in Obj-C.
On top of that there are various design patterns that Apple uses and recommend, that are fully supported in the language.
Multi-year release schedules make for big changes but don't allow you to check back with your users that they are happy with the direction.
e.g. Windows Vista - 6 years. People hated it. Windows 7 - 2 years. Better than Vista. Windows 8 - 3 years. People hated it. Windows 8.1 - 1 year. Significant improvements on Windows 8.
Apple's most usual practice is to upgrade the processing power each year whilst keeping the price the same. Price changes usually come with different hardware form factors. And more often down than up.
No avenue of anti-science earns respect. Deniers of the earth being millions of years old. Deniers of man being a species of ape. Deniers of evolution. Deniers of tobacco being a carcinogen. Deniers of the moon landings.
When you put your politics, religion or paranoia ahead science, you deserve to be marginalised.
Oh you mean like in Netherlands... Or maybe you meant UK...
You're confusing cases for the design patent, with a case about the patents for elements of the UI.
the direction the industry headed in was inevitable.
There was nothing inevitable about the iPhone UI. Android changed from looking like a Blackberry to looking like an iPhone because of a change in the source of their design plagiarism, not inevitability due to increased hardware power. If Windows Phone had been the big success at the time, Android would be a copy of that instead.
What makes you imagine that one particular person, answering my message somehow defined the parameters of the thread. Was it a sock puppet of yours or something? At no stage was this thread limited to form factor. Now stop being a twat.
Slashdot Mirror
You should probably learn the English language before criticising other people's computer language use.
So they continue to pimp their new processor power in their phones (we have an A4 in this! That's right, A4, the chip we just invented! Oh wait, now we have the A5, now the A6, A7.) And then keep bogging it down with new features in iOS that really shouldn't make that much of a difference in performance, but grind old phones to a halt, and the difference is a wash comparing new iPhone +new iOS with old iPhone + old iOS?
Your premise that newer phones don't have features that make a difference is simply false.
No. If going in your direction both break and fallthrough statements should be required.
Nonsense. The following case statement marks the end of a case. There is no need for an extra break statement to mark the obvious and usual flow. Neither for the compiler nor the programmer.
There is no better readability.
In most cases there is both better readability and reduced code, because the number of times switch statements fall through is tiny compared with how often they break.
(Note also: a case with multiple switch values isn't really a fall-through, other than because of C's primitive Other languages such as Pascal allow a list of values, and even ranges per case block.)
And removing a comment hardly qualifies as one less line of code. :-)
Removing your comment because there is a fallthrough statement is not what I'm talking about. It's all those break statements that are no longer needed that are the line savings.
Sorry, but the problem is with the C language, not the compiler, let alone the IDE. That compilers and IDEs have band-aid solutions to stop yourself creating a common bug just proves what a bad language decision it was.
Idiot. That's fall through only because that's the only way C has to do multiple switch values for one case. The right way to do this is to have proper support for multiple values per case. Like for example Pascal. Do you know Pascal, newbie?
Fall-through by default is NEVER the best design.
Apple was a great language for the 1980s, and still has many things that are better than C++. But we can do a lot better than either of those 30 years on.
And it's way past time C went the way of COBOL.
Nothing affects developers as much as a new language. (Swift)
Yes you can use Bing!, more significantly you also have the choice to use DuckDuckGo, the search engine that doesn't track you.
case superset : /* fall through to base for common initialization */
{ init superset specific stuff }
case base :
{ init stuff common to base and superset }
break;
It's not useful at all. The times you deliberately want to fall through are vastly outnumbered by the times you don't. So rather than have a keyword to stop fall-though it makes more sense to have one that causes fall-through.
Your code would be:
case superset :
{ init superset specific stuff }
fallthrough;
case base :
{ init stuff common to base and superset }
The result is better readability. Less lines of code. And many fewer bugs. For exactly the same functionality and execution speed.
There is plenty wrong with C...but that is such a minor thing, and useful many times.
Case fall through by default is NEVER useful. The most common way it's used is for having multiple case labels for a single block of code. Which is better implemented as a list of case labels rather than fall-through. As seen in Pascal for example.
In the ugly approach of having one section of code in one case falling through to then execute the next case as well, that would better be done by packaging up the common code into a sperate function and calling it from both places. Or if you are absolutely determined, by having a keyword to cause the fall-through in those very rare cases where it could be done.
Having it as default behaviour is a candidate for the most obvious bad design in computer language history.
Likewise, one of the great things about C is it does not "defend" instead it assumes the programmer is not an idiot.
Like most assumptions, that's a bad one. Most security issues and many of the other bugs too are down to this bad assumption. All programmers make mistakes and programming languages that help stop them are better than those that don't.
The number of times a fall-through in a switch statement has been useful must be outweighted at least a thousand times by the number of bugs that behaviour has caused.
Who the hell references arguments with $1 and $2?
It's a shortcut for closures. If you don't like:
reversed = sort(names, { $0 > $1 } )
You can still write the full version:
reversed = sort(names, { (string1: String, string2: String) -> Bool in return string1 > string2 })
It's a developer conference. A new language as a first-class component of the platform is huge news.
Support for any unicode glyphs as variable/function names. Down to emoticons.
Just because it's possible doesn't mean that people generally will. XML tag names allow pretty much any Unicode character that wouldn't cause a parsing error, or would be impossible to distinguish. But people don't generally use emoticons as tag names.
Bullshit. There is plenty wrong with plain C. For example there is no defending fall-through by default between cases in switch statements.
iOS 8 will not be available in the STILL ON SALE iPhone 4.
False. The iPhone 4 was discontinued September 10, 2013.
It's successor, the iPhone 4S was first on sale October 14, 2011. Everyone who bought an iPhone 4 after that date knew they were buying an older model which would reach it's end of support sooner than the current model.
Apple stop providing older iPhones with OS updates when they are no longer powerful enough to support current OS release. They got it wrong once, by providing one two many OS updates for the iPhone 3G. And were heavily criticised for it - including by you. You can't have it both ways.
By contrast most Android phones sold NEVER get an OS update.
For the latest HumbleBundle, they choose some games that were available on both PC and Android.
If instead you wanted to make a different list of games that are available on PC and iOS, you could easily do so.
Thus the games in the HumbleBundle say precisely nothing about cross-compatibility. It does say something about the business model of HumbleBundle though.
It's time for Apple to move on to a new language, as Objective-C bears the marks of having evolved over many years, and still suffers from many of the design snafus of C.
Yet whatever language they move to must be completely compatible with Objective-C, such that the existing libraries still work, and existing projects can simply add new classes in the new language and keep the existing stuff in Obj-C.
On top of that there are various design patterns that Apple uses and recommend, that are fully supported in the language.
Multi-year release schedules make for big changes but don't allow you to check back with your users that they are happy with the direction.
e.g. Windows Vista - 6 years. People hated it.
Windows 7 - 2 years. Better than Vista.
Windows 8 - 3 years. People hated it.
Windows 8.1 - 1 year. Significant improvements on Windows 8.
tuppe666, I'm glad you took the time to watch the 2 hour video stream. You must really like Apple to spend that time on it.
Apple's most usual practice is to upgrade the processing power each year whilst keeping the price the same. Price changes usually come with different hardware form factors. And more often down than up.
No avenue of anti-science earns respect.
Deniers of the earth being millions of years old.
Deniers of man being a species of ape.
Deniers of evolution.
Deniers of tobacco being a carcinogen.
Deniers of the moon landings.
When you put your politics, religion or paranoia ahead science, you deserve to be marginalised.
There's no such beneficent entity as Mother Nature, keeping everything just so. Species go extinct often, because their environment changes.
Oh you mean like in Netherlands... Or maybe you meant UK...
You're confusing cases for the design patent, with a case about the patents for elements of the UI.
the direction the industry headed in was inevitable.
There was nothing inevitable about the iPhone UI. Android changed from looking like a Blackberry to looking like an iPhone because of a change in the source of their design plagiarism, not inevitability due to increased hardware power. If Windows Phone had been the big success at the time, Android would be a copy of that instead.
What makes you imagine that one particular person, answering my message somehow defined the parameters of the thread. Was it a sock puppet of yours or something? At no stage was this thread limited to form factor. Now stop being a twat.
It becomes expensive throwing shit at the wall to see what sticks.