It's possible that *you* really did pay for your phone. Most people, don't.
In fact, I did. I'm happy to buy a phone full price and dodge a contract.
They sign two-year agreements and get several hundred dollars off + rebates
This is subsidized. The user still pays for the phone, they just pay for it over the life of their contract (and often beyond if they don't renew their contract by getting a new phone right at the end).
Nothing in life is free - someone always pays for everything, and if you're buying from a commercial entity, then it's you who's paying for it no matter what it says in the advertisement.
I'm pretty sure that there are many XBox 360, PS3 or Wii owners here. You buy the device knowing that it is locked down, can only play vendor authorised software and has a limited vendor determined feature set.
People accept that, so why is a phone any different?
Because game consoles are single-purpose devices (I know you can do more with them than just play games, but they are sold as a game console, and the other things are perks). Heck, the class of device even has a name which suggests this. They also do a pretty decent job of covering the traditional use cases with very few gaps. Additionally for consumers, this lock-down actually provides a pretty compelling function - namely making it much harder for a wide range of traditional multi-player cheats to be effective. But even with all of this in place, there is still a homebrew culture surrounding each of these platforms.
Traditional cell phones are single purpose devices too, about which people rarely complain about lock-down etc.
But when you get into smartphone territory, now you're starting to create a general purpose device. Sure, it's a phone, but that becomes only one (often minor) aspect of its function (for example, I probably spend 10-20x as much time using my smartphone for non-phone purposes as I do using it as a phone, and I'd guess something similar is true for the majority of smartphone owners). The expectation changes such that the only limits you expect from a platform like this are what the market can find a niche for and what the hardware is physically capable of.
An adjustment of mindset is required.
I couldn't agree more. It's time for phone manufacturers to stop thinking they own the hardware I paid for.
I have a hard time buying that it's supposed to be camouflaged. It barely looks anything like a normal iPhone other than the fact that it has an Apple logo on the back. Slapping the logo on doesn't make very good camouflage, instead it probably would make that phone stick out (there are so many phone models out there that people wouldn't really notice one more making the scene).
Plus with as many phone cases as there are out there, the best camouflage (assuming you're trying to protect against someone noticing the iPhone UI on a non-iPhone looking body) would be a case, even if it was poorly fitting.
I think Apple just wants people to keep talking about them - they've had several months where the dominant discussion on every technology site has been Apple. They are trying to build up steam for the iPhone 4 release; get speculation started. Have enough that doesn't add up about this story to get energetic discussion going, while enough that does add up to get people to really wonder.
It's camouflaged but still has an Apple logo on the back? I agree with some others - this strikes me as more of a marketing stunt than an accidental leak. Letting it run for long enough to verify that it's of legitimate origin, then remotely disabling it isn't inconsistent with this.
Though what I don't get is... this new design is ugly. Maybe it is just an easy access case used while the product is still being engineered (eg, trying several antenna configurations inside the case, etc). But if that's the direction design is going, I'm glad I got a phone in the generation when they didn't look like a cardboard box.
Aside from number of files being a terrible predictor of code complexity (splitting into multiple files often decreases the intuitive complexity), this is still a really tiny number of files to be complaining about.
I was one of two lead authors on a relatively small open source project for a few years. As a result of our role, we were the gatekeepers on what community-provided patches we'd incorporate into the core. As our community built up steam, this task became daunting. We would get 30-40 submissions per week, some of them small, and some of them huge. Some of them were simple things like typo fixes, while others were attempts to reinvent major subsystems.
We tried hard to give all the patches a fair shake. Some of these developers were very green, and we tried to explain why we'd reject their patch, while also trying to be encouraging. Some of these developers were very experienced (and indeed I learned a lot in this role just from people fixing my stupidity again and again), but some of these experienced guys really wanted to fundamentally change something which would have far-reaching consequences (it's all well and good to invent a replacement subsystem, but someone has to do the tedious work of going and modifing all the existing code to utilize the new subsystem and so forth).
The volume was overwhelming. Neither my co-author nor I had any time left to write code of our own. We were always either reviewing patches, tweaking patches, or communicating with the community. For a project that began as scratching the itch of a need for creative outlet, eventually it stopped being that for either one of us.
We tried to get the community to help out where we could. There were a few developers out there who we trusted to do some of the review, but neither my partner nor I ever successfully found anyone else who we felt had the skill to trust their final decision who also was willing to take on that work. Plus there was only one other person who had an install of the software on a similar scale to my partner and I, so even our best community developers simply failed to identify performance bottlenecks (for them the neck was wide enough, for us we would have crashed and burned).
There was a certain temptation to try to raise the barrier to entry just to discourage the green developers, who took by far the most of our time. We tried not to succumb to this, but as our systems grew more complex, the number of useful patches compared to fundamentally broken patches decreased. There were also a lot more just-because-I-can patches submitted, and our finding was that the greenest developers were the most ready and willing to aggressively defend their patch. Senior guys were a lot less personally invested in the success of their code (anyone who's worked on big projects knows sometimes you're going to write something that's never used, and stops taking it personally when that happens or they burn out).
My co-author and I both ended up burning out on this project around the same time. The reason we had both gotten into this project had been lost a long time ago. In retrospect, I wish I had taken a harder and stronger approach to dealing particularly with the green developers. Although being leading, gentle, and kind with the newbies was fantastic for them, it was terrible for us. Because we were so welcoming to first-time contributors, we ended up with a lot more chaff than wheat, and too-often these first-time contributors were one-time contributors (so it's not like we typically built out our community by helping them).
In the end: not every contribution is valuable. Some just plain suck. Some are a decent idea but the contributor just came up with the idea and left the gruntwork undone. Some would destroy performance, some would fundamentally break something, and some are themselves fundamentally broken. I think we needed a more darwinian environment - either you produce quality thought out and complete code and take it on yourself to figure out what that means, or we kick you to the curb. If you want to contribute, you'd better actually want to contribute, not have spent an afternoon dabbling then move on.
A debit card where you transfer money into that account just before each transaction has a similar effect if your bank doesn't offer one-time cards.
Personally I have a credit union (I know not everyone is eligible to join one). When a similar thing happened to me as happened to OP, my CU refunded the missing funds the same day I filed the police report (over a certain dollar value a police report is required to file a dispute), which also happens to be the day I found out about it. I found out about it because my CU called me about suspicious activity. This was not credit card fraud prevention services (who honestly has no real motivation to really provide much in the way of fraud prevention - they get their cut either way). The transactions had already completed, once they posted to my CU, the CU is who called - specifically Linda, a kind teller who knows my name and can pull up my account even though I only see her a couple of times per year.
In the time the funds were missing, one payment did incur overdraft. My CU's overdraft is nicer than a normal bank's overdraft too - it's a line of credit, and there is no charge for dipping into that LOC, there is just an interest charge for any remaining balance 30 days later (basically if my checking account runs dry, my debit card turns into a normal credit card). Linda told me that it's possible there were other transactions working their way through (even though my card was now canceled, it can take up to 24 hours for some charges to post to the account - particularly if they are foreign in origin), and assured me that any true overdrafts (the sorts which with a charge) which might occur as a result would have their fees reversed.
So like I said, I know not everyone has a credit union as an option. But when your bank is actually watching out for your interests, there are better options out there without even needing to invent something new.
As you point out, different model Android phones have different strengths. Interestingly, users for whom specific features are important can locate a handset which has strengths in that area. Don't like OLED, fine, buy a LCD model. Don't like on-screen keyboards, get one with a physical. Want a high resolution, buy one with that.
The point is that with Android, it's about customer choice, and less about sole-manufacturer choice.
Also, the four points you highlight: Screen Size, Screen Type, Screen Resolution, and Camera Quality are all four better on the Nexus One than on the iPhone (within the bounds of objective measurability). Of course you're right, some people prefer the washed out colors and higher battery consumption that comes with LCD. But then some people prefer vinyl audio to digital, and some people even prefer MP3 to a lossless format. People like what they learned to like, and even ostensibly objective differences can still be subjectively rejected.
Having used an iPhone 3G for 2 years, then upgraded to Nexus One last month, I can say without reservation that this upgrade was money well spent. I kept my iPhone so I could use it like an iPod Touch and use the apps I'd already bought for it as well as use it to listen to music. It makes kind of an ugly paperweight over on under that pile of papers where it's currently been untouched for weeks.
I have a Nexus One also, which I upgraded to from my iPhone 3G. This is hands down a better phone than my iPhone was in a variety of ways.
Like anything, there are some downsides. For example, some people don't like the pixel configuration, which I only know because I read about it - Within a minute of using this device, personally I felt the screen was better than the iPhone's.
Its weaknesses come from a weaker app market (though this is rapidly closing the gap, and honestly most people wouldn't notice unless they were searching out a specific title), and weaker third party hardware support (fewer custom accessories since there are so many different handsets which run this OS). The car dock from Google is fantastic though, and makes this phone a better GPS than my dedicated GPS device by a pretty wide margin.
You're seeing different projects on the same source code. Each project has compile and build settings for the target platform. It's no different from having different makefiles for each target platform of a C++ project. In the IDE you can even have all the target platforms do delta compiles or even full compiles at the same time as each other.
I haven't seen this code, but I know from first hand experience that you're unlikely to need to find a bunch of #IFDEF's all over the code (like you'll find in a x-plat project of almost any other stripe). It's a single runtime that will compile to a variety of platforms without a lot of hoop jumping.
Having a 2.1 device: yes you're right. Plus it'll give you directions on how to get there, a phone link so you can call ahead, a list of reviews and a star rating, a street view of what that location looks like, and the directions it uses to route you there will route you around traffic jams in real time.
A cube entering FlatLand at (45,45,45) degrees of rotation would appear at first as a dot, then grow into a triangle. Then the corners of the triangle would split into line segments which would grow while the original segments shrink until it becomes a triangle again, and eventually a dot and nothing.
Interestingly at no point would it possess four sides, so to a flatlander, it would be very hard to conceptualize that this is a construct made up of squares (a concept they would understand).
An existing open source implementation does not mean that the codec is free of patent issues. Indeed, the legality of open source implementations like ffmpeg's and VLC's are dubious at best - in fact it is believed that the open source license of these projects is incompatible with providing an h.264 implementation:
Conversely, shipping a product in the U.S. which includes (though not necessarily implements) a GPL H.264 decoder/encoder requires that the copyright terms of the GPL license be upheld, otherwise conveying the codec would be in violation of the software license of the implementation. http://en.wikipedia.org/wiki/H.264#Patents_and_GNU_Free_Software_licenses
Fair enough. These things aren't necessary for OOP. But however they are how many modern languages provide OOP functionality. Class methods are object passing. And you're right, certainly late dynamic binding is not required for OOP. But when there are many developers with their hands in the pot, it's much easier to locate the true source of a problem when it happens with compile time binding enforcement.
Some developers talk about "duck typing" (if it walks like a duck and swims like a duck, it's a duck). But when you give me a goose, it can walk like a duck and swim like a duck, but it's not a duck. When I try to do some duck-only thing (or worse yet, I try to do some thing which ducks and geese both can do, but it means different things for each), mysterious problems appear that are very difficult to debug.
ActionScript 3 actually takes a pretty nice middle of the road. It likes to encourage you for static typing whenever it can. But you always have the option to revert to dynamic binding when and where you deem it necessary (or even just especially convenient). So you get the best of both worlds: static typing when this makes sense, dynamic when that makes sense. What makes sense is up to you and your team to determine.
Uhm? Flash works in precisely the same way - it transfers platform-independent data to the client and then it generates platform-dependent native code at runtime. If JIT compilation is not an actual compilation process, then - by your very definition - AS isn't a compiled language.
You're describing the difference between compiling source and executing bytecode. Bytecode execution is not compilation. Sure bytecode may not be one-to-one for machine instructions, but I doubt many people would call executing a Java JAR file "compiling" it.
This is all a pretty pedantic point mostly surrounding nomenclature though. The point is that the work is front loaded and the client is saved from having to do that work, the author has the confidence of knowing it's always done the same way (because he did it - no concern about an overly eager optimizing compiler changing the meaning of a particularly complex bit of code), and bytecode is less verbose than sourcecode (so less data to transfer). The downside of course is that if there's some platform which would benefit from a different compiler (perhaps a compiler designed specifically to take advantage of many cores), it doesn't have that option.
And no, not everyone would agree,
Fair enough on this point too - no universal statement is true (yes, that is recursively ironic). I can say I have been involved in large scale systems both of dynamic and static types. I find it much easier to get up and running in a static system because I always know what the available interface is for a given object. In a dynamic system when maintaining existing code, you always have to worry that someone is passing several different types of object to a method with incompatible interfaces (but which have so far managed to remain compatible either by chance or by force). You can't just start calling a new method on that object unless you go and look up every instance where this parent method is called, and are absolutely sure you know what the object types going into it are. Much better to have the compiler do this work than you having to do it yourself.
I don't know what you mean about consistency, haven't seen a problem there.
Ignoring the wide variety of differences HTML4 has between different browsers (ever see ACID test results?), which video codec is supported in all modern HTML5 browsers (video being one of the only things HTML5 has really put much work into so far)?
Not only is this no where near the penetration rates of HTML5, it's only true for those HTML4 features which exist in the venn intersection of all features between IE8 + IE7 + IE6 + Firefox + Chrome + Safari + Opera (source).
but it could eventually encompass all of it (or, gasp- exceed Flash functionality)
I welcome that day - please don't get me wrong. I'm just saying it's too early to sound the death knell.
will do so in all HTML5 browsers
Do you really think that's true? How has that worked out for HTML4 so far? Major differences between browsers and browser versions. Some of these browsers in their most modern form still can't pass CSS ACID tests.
Flash offers ubiquity and consistency that has so far simply not existed in the HTML arena, and HTML5 has not offered any sort of standards verification. If HTML5 wants to do that, it should create a set of ACID tests for HTML5 features, and any browser which wishes to claim HTML5 compatibility needs to score 100% on them.
They manage to make new versions of Photoshop compelling even though they're not depending on new downstream technology. Newer Flash IDE's have some pretty compelling functionality that have nothing to do with the features found in newer versions of Flash Player (indeed, they can publish for older versions of Flash Player).
If Adobe did shift their IDE's to output HTML5 content, I would fully expect them to continue to introduce compelling new features each release by taking the things developers find annoying in the current version, and making them easier in the newer version.
For example, I've seen some product demos where they're doing a pretty impressive job lately of bridging the gap between designer and developer. The designer can take their Photoshop / Illustrator files and use them as the source to create widgets (without diving into a lot of image slicing and whatnot). They then export rich controls that the developer can just snap up and bind data to. The designer gets to be exactly as anal as they want about the layout, and the developer is saved the frustration of a designer who's calling him out about a control that appears 1 pixel to the left of where they wanted it.
Some companies run certain key systems without Flash installed (but which still need Internet / web access). For such systems, the surface area is getting decidedly larger since you can no longer disable this multimedia-exclusive function even though it's not needed.
The fact is that for a long time, most people are going to have both HTML5 and Flash, so surface area will only increase across the board. So this is not really a selling point for HTML5 as at best the surface area is the same but it may be larger at times.
Don't be fooled, Apple is not doing this thing you suggest.
Apple is using that as an excuse to produce App Store lock-in. HTML5 is not a competitor to Flash yet. Give it 5 years and maybe. Apple is using the gap while HTML5 comes up to speed to keep people from being able to play games or run apps on their iPhone / iPad unless they paid Apple for the privilege of doing so first.
That has very little to do with OOP, save for reflection, which is a pretty natural requirement.
I'm not trying to be snide here, but perhaps you should read up on OOP core concepts and features which include classes, inheritence, abstraction, encapsulation, polymorphism, and decoupling. In fact, reflection is the only one of those which does not directly contribute to OOP design principles (exactly the opposite as you suggest).
These days, JavaScript is usually compiled to native code. And guess what: Adobe's AS engine and Mozilla's TraceMonkey JavaScript engine share the same JIT core.
Yes, but this compilation is JIT as you point out. JIT is not the same thing as a compiled language. Part of the point is that you can do this work once and save all your users the overhead of doing it. You can also send them bytecode instead of much more verbose source code (making less data to transfer). It also leaves less chance of difference between clients since the client is responsible for less of the work overall.
That's an interesting feature, but it's neither a bug nor an ultimate selling point.
Anyone who has worked in a particularly large codebase (1000+kloc) would not agree.
No, ActionScript has a lot of high order OOP principles (interfaces, inheritance, classes, packages, abstract types, method and property visibility controls, language reflection, and so forth), is a compiled language, and has the option to be strongly typed throughout.
ActionScript 1.0 was a pretty similar language to JavaScript. AS 2.0 introduced a lot of OOP principles, and AS 3.0 brings it pretty close to the same level as Java.
Apple should be worried. They've proven to me that they can't be trusted to wield as much market power as they've earned recently, because denying a third party technology is a decision which belongs to the owner of the device, not the maker of the device. In recent years, I'd become an Apple convert, and now I no longer consider anything bearing that logo when making purchasing decisions.
Definitely, there's a whole realm of rich applications for which HTML5 can only just barely begin to dream.
But beyond this, even in the arena of video (which as you point out, seems to be the only corner of the Flash world the doomsayers want to talk about), HTML5 lacks ubiquity and consistency. There isn't even one single codec which is supported by every browser that implements HTML5 (Mozilla won't support H.264 for patent reasons), and even if there were, it still lacks functions which have existed in Flash for what seems like eons, such as dynamic bitrates (connection quality goes down, the amount of data sent to you goes down to compensate), and real-time seeking (ever want to skip around in a long video before the whole thing has loaded?).
Plus it's still missing camera and microphone controls.
Let's not forget that ActionScript is a much stronger language than JavaScript, and that things you write in Flash work in all browsers on all OS's if they work on your desktop, while JavaScript and interacting with the browser's DOM to this day is widely different in each browser, and sometimes even different in the same browser on different OS's. So the testing surface area in Flash is n (where n is the complexity of the application), while it's n*bv*o for HTML5 (where bv is the set of browsers and browser versions you want to support, and o is the set of OS's you want to support).
I've said it before, and I'll say it again. HTML5 is moving in the right direction. But it's a long, long distance from seriously competing with Flash except ideologically. It will be five years before it's a serious competitor, and only if the backers of HTML5 all start pulling in the same direction (today they're pulling in different directions on things as simple as what codec video should use).
Slashdot Mirror
In fact, I did. I'm happy to buy a phone full price and dodge a contract.
This is subsidized. The user still pays for the phone, they just pay for it over the life of their contract (and often beyond if they don't renew their contract by getting a new phone right at the end).
Nothing in life is free - someone always pays for everything, and if you're buying from a commercial entity, then it's you who's paying for it no matter what it says in the advertisement.
Because game consoles are single-purpose devices (I know you can do more with them than just play games, but they are sold as a game console, and the other things are perks). Heck, the class of device even has a name which suggests this. They also do a pretty decent job of covering the traditional use cases with very few gaps. Additionally for consumers, this lock-down actually provides a pretty compelling function - namely making it much harder for a wide range of traditional multi-player cheats to be effective. But even with all of this in place, there is still a homebrew culture surrounding each of these platforms.
Traditional cell phones are single purpose devices too, about which people rarely complain about lock-down etc.
But when you get into smartphone territory, now you're starting to create a general purpose device. Sure, it's a phone, but that becomes only one (often minor) aspect of its function (for example, I probably spend 10-20x as much time using my smartphone for non-phone purposes as I do using it as a phone, and I'd guess something similar is true for the majority of smartphone owners). The expectation changes such that the only limits you expect from a platform like this are what the market can find a niche for and what the hardware is physically capable of.
I couldn't agree more. It's time for phone manufacturers to stop thinking they own the hardware I paid for.
I have a hard time buying that it's supposed to be camouflaged. It barely looks anything like a normal iPhone other than the fact that it has an Apple logo on the back. Slapping the logo on doesn't make very good camouflage, instead it probably would make that phone stick out (there are so many phone models out there that people wouldn't really notice one more making the scene).
Plus with as many phone cases as there are out there, the best camouflage (assuming you're trying to protect against someone noticing the iPhone UI on a non-iPhone looking body) would be a case, even if it was poorly fitting.
I think Apple just wants people to keep talking about them - they've had several months where the dominant discussion on every technology site has been Apple. They are trying to build up steam for the iPhone 4 release; get speculation started. Have enough that doesn't add up about this story to get energetic discussion going, while enough that does add up to get people to really wonder.
It's camouflaged but still has an Apple logo on the back? I agree with some others - this strikes me as more of a marketing stunt than an accidental leak. Letting it run for long enough to verify that it's of legitimate origin, then remotely disabling it isn't inconsistent with this.
Though what I don't get is... this new design is ugly. Maybe it is just an easy access case used while the product is still being engineered (eg, trying several antenna configurations inside the case, etc). But if that's the direction design is going, I'm glad I got a phone in the generation when they didn't look like a cardboard box.
160 source files is a lot to you?
Aside from number of files being a terrible predictor of code complexity (splitting into multiple files often decreases the intuitive complexity), this is still a really tiny number of files to be complaining about.
I was one of two lead authors on a relatively small open source project for a few years. As a result of our role, we were the gatekeepers on what community-provided patches we'd incorporate into the core. As our community built up steam, this task became daunting. We would get 30-40 submissions per week, some of them small, and some of them huge. Some of them were simple things like typo fixes, while others were attempts to reinvent major subsystems.
We tried hard to give all the patches a fair shake. Some of these developers were very green, and we tried to explain why we'd reject their patch, while also trying to be encouraging. Some of these developers were very experienced (and indeed I learned a lot in this role just from people fixing my stupidity again and again), but some of these experienced guys really wanted to fundamentally change something which would have far-reaching consequences (it's all well and good to invent a replacement subsystem, but someone has to do the tedious work of going and modifing all the existing code to utilize the new subsystem and so forth).
The volume was overwhelming. Neither my co-author nor I had any time left to write code of our own. We were always either reviewing patches, tweaking patches, or communicating with the community. For a project that began as scratching the itch of a need for creative outlet, eventually it stopped being that for either one of us.
We tried to get the community to help out where we could. There were a few developers out there who we trusted to do some of the review, but neither my partner nor I ever successfully found anyone else who we felt had the skill to trust their final decision who also was willing to take on that work. Plus there was only one other person who had an install of the software on a similar scale to my partner and I, so even our best community developers simply failed to identify performance bottlenecks (for them the neck was wide enough, for us we would have crashed and burned).
There was a certain temptation to try to raise the barrier to entry just to discourage the green developers, who took by far the most of our time. We tried not to succumb to this, but as our systems grew more complex, the number of useful patches compared to fundamentally broken patches decreased. There were also a lot more just-because-I-can patches submitted, and our finding was that the greenest developers were the most ready and willing to aggressively defend their patch. Senior guys were a lot less personally invested in the success of their code (anyone who's worked on big projects knows sometimes you're going to write something that's never used, and stops taking it personally when that happens or they burn out).
My co-author and I both ended up burning out on this project around the same time. The reason we had both gotten into this project had been lost a long time ago. In retrospect, I wish I had taken a harder and stronger approach to dealing particularly with the green developers. Although being leading, gentle, and kind with the newbies was fantastic for them, it was terrible for us. Because we were so welcoming to first-time contributors, we ended up with a lot more chaff than wheat, and too-often these first-time contributors were one-time contributors (so it's not like we typically built out our community by helping them).
In the end: not every contribution is valuable. Some just plain suck. Some are a decent idea but the contributor just came up with the idea and left the gruntwork undone. Some would destroy performance, some would fundamentally break something, and some are themselves fundamentally broken. I think we needed a more darwinian environment - either you produce quality thought out and complete code and take it on yourself to figure out what that means, or we kick you to the curb. If you want to contribute, you'd better actually want to contribute, not have spent an afternoon dabbling then move on.
A debit card where you transfer money into that account just before each transaction has a similar effect if your bank doesn't offer one-time cards.
Personally I have a credit union (I know not everyone is eligible to join one). When a similar thing happened to me as happened to OP, my CU refunded the missing funds the same day I filed the police report (over a certain dollar value a police report is required to file a dispute), which also happens to be the day I found out about it. I found out about it because my CU called me about suspicious activity. This was not credit card fraud prevention services (who honestly has no real motivation to really provide much in the way of fraud prevention - they get their cut either way). The transactions had already completed, once they posted to my CU, the CU is who called - specifically Linda, a kind teller who knows my name and can pull up my account even though I only see her a couple of times per year.
In the time the funds were missing, one payment did incur overdraft. My CU's overdraft is nicer than a normal bank's overdraft too - it's a line of credit, and there is no charge for dipping into that LOC, there is just an interest charge for any remaining balance 30 days later (basically if my checking account runs dry, my debit card turns into a normal credit card). Linda told me that it's possible there were other transactions working their way through (even though my card was now canceled, it can take up to 24 hours for some charges to post to the account - particularly if they are foreign in origin), and assured me that any true overdrafts (the sorts which with a charge) which might occur as a result would have their fees reversed.
So like I said, I know not everyone has a credit union as an option. But when your bank is actually watching out for your interests, there are better options out there without even needing to invent something new.
As you point out, different model Android phones have different strengths. Interestingly, users for whom specific features are important can locate a handset which has strengths in that area. Don't like OLED, fine, buy a LCD model. Don't like on-screen keyboards, get one with a physical. Want a high resolution, buy one with that.
The point is that with Android, it's about customer choice, and less about sole-manufacturer choice.
Also, the four points you highlight: Screen Size, Screen Type, Screen Resolution, and Camera Quality are all four better on the Nexus One than on the iPhone (within the bounds of objective measurability). Of course you're right, some people prefer the washed out colors and higher battery consumption that comes with LCD. But then some people prefer vinyl audio to digital, and some people even prefer MP3 to a lossless format. People like what they learned to like, and even ostensibly objective differences can still be subjectively rejected.
Having used an iPhone 3G for 2 years, then upgraded to Nexus One last month, I can say without reservation that this upgrade was money well spent. I kept my iPhone so I could use it like an iPod Touch and use the apps I'd already bought for it as well as use it to listen to music. It makes kind of an ugly paperweight over on under that pile of papers where it's currently been untouched for weeks.
I have a Nexus One also, which I upgraded to from my iPhone 3G. This is hands down a better phone than my iPhone was in a variety of ways.
Like anything, there are some downsides. For example, some people don't like the pixel configuration, which I only know because I read about it - Within a minute of using this device, personally I felt the screen was better than the iPhone's.
Its weaknesses come from a weaker app market (though this is rapidly closing the gap, and honestly most people wouldn't notice unless they were searching out a specific title), and weaker third party hardware support (fewer custom accessories since there are so many different handsets which run this OS). The car dock from Google is fantastic though, and makes this phone a better GPS than my dedicated GPS device by a pretty wide margin.
You're seeing different projects on the same source code. Each project has compile and build settings for the target platform. It's no different from having different makefiles for each target platform of a C++ project. In the IDE you can even have all the target platforms do delta compiles or even full compiles at the same time as each other.
I haven't seen this code, but I know from first hand experience that you're unlikely to need to find a bunch of #IFDEF's all over the code (like you'll find in a x-plat project of almost any other stripe). It's a single runtime that will compile to a variety of platforms without a lot of hoop jumping.
Having a 2.1 device: yes you're right. Plus it'll give you directions on how to get there, a phone link so you can call ahead, a list of reviews and a star rating, a street view of what that location looks like, and the directions it uses to route you there will route you around traffic jams in real time.
A cube entering FlatLand at (45,45,45) degrees of rotation would appear at first as a dot, then grow into a triangle. Then the corners of the triangle would split into line segments which would grow while the original segments shrink until it becomes a triangle again, and eventually a dot and nothing.
Interestingly at no point would it possess four sides, so to a flatlander, it would be very hard to conceptualize that this is a construct made up of squares (a concept they would understand).
No, I think it comes from sales in the store. Sure, there are free games in the store. But most of them are trialware for the paid version.
An existing open source implementation does not mean that the codec is free of patent issues. Indeed, the legality of open source implementations like ffmpeg's and VLC's are dubious at best - in fact it is believed that the open source license of these projects is incompatible with providing an h.264 implementation:
Actually Flash is an open standard: http://www.adobe.com/devnet/swf/
It just so happens that the only company to provide a complete implementation of it is Adobe. They also provide the only meaningful development tools.
Fair enough. These things aren't necessary for OOP. But however they are how many modern languages provide OOP functionality. Class methods are object passing. And you're right, certainly late dynamic binding is not required for OOP. But when there are many developers with their hands in the pot, it's much easier to locate the true source of a problem when it happens with compile time binding enforcement.
Some developers talk about "duck typing" (if it walks like a duck and swims like a duck, it's a duck). But when you give me a goose, it can walk like a duck and swim like a duck, but it's not a duck. When I try to do some duck-only thing (or worse yet, I try to do some thing which ducks and geese both can do, but it means different things for each), mysterious problems appear that are very difficult to debug.
ActionScript 3 actually takes a pretty nice middle of the road. It likes to encourage you for static typing whenever it can. But you always have the option to revert to dynamic binding when and where you deem it necessary (or even just especially convenient). So you get the best of both worlds: static typing when this makes sense, dynamic when that makes sense. What makes sense is up to you and your team to determine.
You're describing the difference between compiling source and executing bytecode. Bytecode execution is not compilation. Sure bytecode may not be one-to-one for machine instructions, but I doubt many people would call executing a Java JAR file "compiling" it.
This is all a pretty pedantic point mostly surrounding nomenclature though. The point is that the work is front loaded and the client is saved from having to do that work, the author has the confidence of knowing it's always done the same way (because he did it - no concern about an overly eager optimizing compiler changing the meaning of a particularly complex bit of code), and bytecode is less verbose than sourcecode (so less data to transfer). The downside of course is that if there's some platform which would benefit from a different compiler (perhaps a compiler designed specifically to take advantage of many cores), it doesn't have that option.
Fair enough on this point too - no universal statement is true (yes, that is recursively ironic). I can say I have been involved in large scale systems both of dynamic and static types. I find it much easier to get up and running in a static system because I always know what the available interface is for a given object. In a dynamic system when maintaining existing code, you always have to worry that someone is passing several different types of object to a method with incompatible interfaces (but which have so far managed to remain compatible either by chance or by force). You can't just start calling a new method on that object unless you go and look up every instance where this parent method is called, and are absolutely sure you know what the object types going into it are. Much better to have the compiler do this work than you having to do it yourself.
Ignoring the wide variety of differences HTML4 has between different browsers (ever see ACID test results?), which video codec is supported in all modern HTML5 browsers (video being one of the only things HTML5 has really put much work into so far)?
So they work in 99% of browsers (source).
Not only is this no where near the penetration rates of HTML5, it's only true for those HTML4 features which exist in the venn intersection of all features between IE8 + IE7 + IE6 + Firefox + Chrome + Safari + Opera (source).
I welcome that day - please don't get me wrong. I'm just saying it's too early to sound the death knell.
Do you really think that's true? How has that worked out for HTML4 so far? Major differences between browsers and browser versions. Some of these browsers in their most modern form still can't pass CSS ACID tests.
Flash offers ubiquity and consistency that has so far simply not existed in the HTML arena, and HTML5 has not offered any sort of standards verification. If HTML5 wants to do that, it should create a set of ACID tests for HTML5 features, and any browser which wishes to claim HTML5 compatibility needs to score 100% on them.
They manage to make new versions of Photoshop compelling even though they're not depending on new downstream technology. Newer Flash IDE's have some pretty compelling functionality that have nothing to do with the features found in newer versions of Flash Player (indeed, they can publish for older versions of Flash Player).
If Adobe did shift their IDE's to output HTML5 content, I would fully expect them to continue to introduce compelling new features each release by taking the things developers find annoying in the current version, and making them easier in the newer version.
For example, I've seen some product demos where they're doing a pretty impressive job lately of bridging the gap between designer and developer. The designer can take their Photoshop / Illustrator files and use them as the source to create widgets (without diving into a lot of image slicing and whatnot). They then export rich controls that the developer can just snap up and bind data to. The designer gets to be exactly as anal as they want about the layout, and the developer is saved the frustration of a designer who's calling him out about a control that appears 1 pixel to the left of where they wanted it.
Some companies run certain key systems without Flash installed (but which still need Internet / web access). For such systems, the surface area is getting decidedly larger since you can no longer disable this multimedia-exclusive function even though it's not needed.
The fact is that for a long time, most people are going to have both HTML5 and Flash, so surface area will only increase across the board. So this is not really a selling point for HTML5 as at best the surface area is the same but it may be larger at times.
Don't be fooled, Apple is not doing this thing you suggest.
Apple is using that as an excuse to produce App Store lock-in. HTML5 is not a competitor to Flash yet. Give it 5 years and maybe. Apple is using the gap while HTML5 comes up to speed to keep people from being able to play games or run apps on their iPhone / iPad unless they paid Apple for the privilege of doing so first.
I'm not trying to be snide here, but perhaps you should read up on OOP core concepts and features which include classes, inheritence, abstraction, encapsulation, polymorphism, and decoupling. In fact, reflection is the only one of those which does not directly contribute to OOP design principles (exactly the opposite as you suggest).
Yes, but this compilation is JIT as you point out. JIT is not the same thing as a compiled language. Part of the point is that you can do this work once and save all your users the overhead of doing it. You can also send them bytecode instead of much more verbose source code (making less data to transfer). It also leaves less chance of difference between clients since the client is responsible for less of the work overall.
Anyone who has worked in a particularly large codebase (1000+kloc) would not agree.
No, ActionScript has a lot of high order OOP principles (interfaces, inheritance, classes, packages, abstract types, method and property visibility controls, language reflection, and so forth), is a compiled language, and has the option to be strongly typed throughout.
ActionScript 1.0 was a pretty similar language to JavaScript. AS 2.0 introduced a lot of OOP principles, and AS 3.0 brings it pretty close to the same level as Java.
Apple should be worried. They've proven to me that they can't be trusted to wield as much market power as they've earned recently, because denying a third party technology is a decision which belongs to the owner of the device, not the maker of the device. In recent years, I'd become an Apple convert, and now I no longer consider anything bearing that logo when making purchasing decisions.
Definitely, there's a whole realm of rich applications for which HTML5 can only just barely begin to dream.
But beyond this, even in the arena of video (which as you point out, seems to be the only corner of the Flash world the doomsayers want to talk about), HTML5 lacks ubiquity and consistency. There isn't even one single codec which is supported by every browser that implements HTML5 (Mozilla won't support H.264 for patent reasons), and even if there were, it still lacks functions which have existed in Flash for what seems like eons, such as dynamic bitrates (connection quality goes down, the amount of data sent to you goes down to compensate), and real-time seeking (ever want to skip around in a long video before the whole thing has loaded?).
Plus it's still missing camera and microphone controls.
Let's not forget that ActionScript is a much stronger language than JavaScript, and that things you write in Flash work in all browsers on all OS's if they work on your desktop, while JavaScript and interacting with the browser's DOM to this day is widely different in each browser, and sometimes even different in the same browser on different OS's. So the testing surface area in Flash is n (where n is the complexity of the application), while it's n*bv*o for HTML5 (where bv is the set of browsers and browser versions you want to support, and o is the set of OS's you want to support).
I've said it before, and I'll say it again. HTML5 is moving in the right direction. But it's a long, long distance from seriously competing with Flash except ideologically. It will be five years before it's a serious competitor, and only if the backers of HTML5 all start pulling in the same direction (today they're pulling in different directions on things as simple as what codec video should use).