The amount of engineering rigor that has gone into sqlite over the years boggles the mind. It's a project that has been held up as a sterling example of successful software development many times, rightfully so. I especially like this part of their license, from the top of sqlite3.h
"The author disclaims copyright to this source code. In place of
a legal notice, here is a blessing:
May you do good and not evil.
May you find forgiveness for yourself and forgive others.
May you share freely, never taking more than you give."
This is kind of saddening to see, but it is a crime that virtually every programmer has committed at one point or another in their careers. Let's be honest - in some cases it can be quite fun to do. The underlying problem is the ego, and the corresponding lack of objectivity that results.
From reading someone else's code - even glancing at it in some cases - one can infer a great many things. For example, if the indentation on some code is totally borked, most programmers will immediately be extremely doubtful about whether that code contains any interesting or useful ideas (though of course this is not always the case, counterexample being intentionally obfuscated code). In some cases, they will simply refuse to continue attempting to understand the code and dismiss it as useless. A similar thing can happen at the semantic level when the programmer detects a mismatch between the language/framework being used and the problem space; this dissonance is likely what is irking all of the people who are so childishly ridiculing your replace utility.
Sometimes when you're looking over someone else's code you spot some perceived inconsistencies/flaws/bugs. The crucially important part is what you do next. If you choose the route of publicly shaming them to stroke your own ego, then you have not only hurt yourself by appearing childish, insecure and unsociable, but you have also hurt their feelings. It's important to remain objective in these situations, and take the self out of the equation. If you HAVE to indulge yourself by tearing the code apart in a humorous manner then at least keep it between with your friends!
As I alluded before, I would guess that the reason people where poking fun at it was probably because there exist a lot of other utilities which have the same functionality and are readily available on most any system. Personally, I thought your code was interesting, and I thank you for choosing to make it public :).
Still: how many currently deployed devices running iOS are you going to be QAing that application on? Two, maybe Three? How many versions of iOS are you going to be seeing on those devices? One or two most likely, iPhone users tend to upgrade with their software with much more conformity and faster. Compare that to Androids upwards of fifteen (and growing) widespread devices, and a heinous amount of API levels in the wild. That's one of the more objective factors which make Android easier.
Also, you can say that the API level differences don't matter because they are hidden by compatibility libraries like The Support Package, but the truth is that those are just the newer APIs re-implemented against the old interfaces. You pay for that extra abstraction with wasted cycles and bloat, and it's an ugly solution. Even still, those libraries aren't perfect: there have been subtle bugs or incompatibilities introduced by their use which are notoriously hard to find. Finally, even if the newer APIs are present on the device, The Support Library will still be used (last I checked, though I think they are working on this).
Less objectively, it's a matter of preference. Some people just prefer objective C to a JVM compilable language.
Having done corporate grade mobile work, there's no question of which platform is easier to develop for. On Android, not only do you have to simultaneously target in some cases four or five different API levels, you also have to hit several combinations of screen dimensions and resolutions. The documentation for Android is also lacking in comparison to the iOS docs. The android SDK, though comprehensive and generally very high quality, suffers from the same complexity problems arising from issues related to fragmentation.
Remember though, most of the developers who are doing work that actually matters on mobile aren't doing it because they want do, they're doing it because a corporate strategist thought it would be profitable use of their time.
Although that's true in principle it's a little idealized: HTML5 development on mobile is still a little half baked and impractical. You only have to look at Facebook's massive abandonment (at least temporarily) of that platform in favor of the native API.
The whole point of the article is that while there are more paying customers in the iOS world NOW, it's unlikely that the situation will continue to be true given the current trends.
<[email protected]>: host
microsoft-com.mail.protection.outlook.com[207.46.100.11] said: 550 5.7.1
Service unavailable; Client host [66.175.217.21] blocked using Blocklist 1;
To request removal from this list please forward this message to
[email protected] (in reply to RCPT TO command)
Did you use the makefile to build it? I'm thinking that those specific compile and link flags are key to the triggering condition.
I've gotten it to crash at least three or four times on several windows 7 boxes of wildly differing configurations. No confirmed trials on a windows eight box, the bug may have been fixed there.
I haven't exactly pinpointed the cause of the problem, I just noted that that call was the last point in my code to get executed before the system was hosed.
Also, the code is complete: check the tarball listed at the end of the page.
agreed. I was surprised at the number of responses to the contrary. this 'idea' is nothing new, nothing innovative, and has been proven to be a terrible approach by history time and time again.
well why doesn't he explain how we safely present a system API to arbitrary code?
the whole point of the browser is to provide a method for cross platform ui, abstracting the display of an application from the underlying OS. if you were to want to support more than one operating system you'd have to recompile your binaries against all the system APIs that you wanted to support, sysV, winnt, darwin, etc...
and if you were to present an abstraction which would transparently handle the system API difference then you're looking at a JVM, which has been painfully demonstrated to be extremely hard to prevent escalations for, time and time again.
"The author disclaims copyright to this source code. In place of a legal notice, here is a blessing: May you do good and not evil. May you find forgiveness for yourself and forgive others. May you share freely, never taking more than you give."