This kind of problem makes it clear to me that application developers need to understand and be responsible for the full stack of software that they ship, including bundled C libraries. One can't just use a high-level cross-platform runtimes like Mono/.NET and ignore everything underneath, because when the shit hits the fan, the app developer has to fix it, not pass the blame and wait for someone else to handle it.
(For the same reason, I think it's better to rent dedicated servers than to use virtual machines or whatever-as-a-service. And colocation might be better still, if one can afford the up-front expense.)
What isn't clear to me is whether we should still use a high-level runtime like Mono/.NET, for mobile apps in particular, even though we have to be responsible for lower layers. On the one hand, very few developers would want to mess with manual memory management and C-style error handling when writing business logic, database access routines, or UI code. On the other, if we have to grasp the whole stack anyway, then we can more easily do that if there's less of it. On iOS, cross-platform C code plus iOS-specific Objective-C code is less complex than cross-platform C code plus P/Invoke glue for the former plus cross-platform C# code plus UI code in C# (which will be foreign to iOS developers not familiar with Xamarin) plus glue between Mono and ObjC. Similar logic applies to Android (although there will always be JNI glue between native code and Java) and even Windows Phone (as of 8.1, which supports WinRT and native code using that). So, for a more comprehensible software stack since we have to be responsible for the whole thing anyway, should we just give up on higher-level languages and runtimes, acknowledge that we're ultimately dealing with C machines, and stick to C or maybe C++ for cross-platform code? Would that be putting too much emphasis on hypothetical debuggability, and not enough on other things like developer productivity and approachability to less-than-expert developers?
Part of me agrees with you and wants to rant about it at length.
It is invariably true that developers who understand the full stack get along better. They know what's going on "under the hood". When they click a checkbox in the Visual Studio properties dialog, they understand what will happen at the MSBuild level, and how that translates to a difference in the command line invocation of the compiler, and what the compiler does differently because of that, and what it means in terms of interaction with the OS. It would drive them nuts to not understand this. So much so that they're probably only using Visual Studio instead of vim/cygwin/bash because somebody is forcing them to. :-)
OTOH, lots of developers let their tooling or platform do things for them that they don't understand. Those developers often struggle, especially during the latter stages of shipping a product. (I just wanted to not learn SQL! How was I supposed to know that NHibernate is so slow?!?)
But it is also true that expecting all developers to understand everything from their ORM down to the x86 microcode is neither realistic nor efficient. It's just not gonna happen.
There's a lot of difference between knowing SQL (the 2nd example) and knowing what will happen at the MSBuild level.
I know the former but not the latter :) and while it probably will help me get better, I haven't really needed to know in depth what goes on behind the scenes yet (at the MSBuild level), and hasn't bit me in the ass :) , and I've shipped quite a lot of code. To use your terms, it's an abstraction that doesn't leak :) .
OTOH I've never met an ORM where SQL knowledge wasn't necessary (now that's a leaky abstraction if there was one).
I think knowledge of the full stack is required to get better, but I also believe in applying Pareto and studying the bits that will yield the bigger results :) .
I'm not 100% a developer anymore (I'm in an amorphous transition that really worries me between development, support, operations and management) so YMMV.
Edit: for app development, I think I'm on the OPs side, in that you currently need to know the full stack (for apps in particular). This doesn't mean it won't change in the near future.
But I don't endorse his other opinion - I think you have to do a cost-benefit analysis before using dedicated servers. Past a certain point, certainly, do use them, but 80% of the software out there doesn't need them. I know the one I'm currently developing doesn't (unless it scales beyond my expectations :) which would be a nice problem to have).
I think the answer to your conundrum is that the (business) users get what they are asking for. If you were using Hibernate/whathaveyou you are pretending you don't have a problem.
So much of this mess is caused by dumb decisions from people who don't understand what 'constraint' means - welcome to 2014, where business suits run the show, and technology is just plain broken as a result. Not that anything has really changed, the whole 'this is 2014' argument is a bit of a farce anyways.
Thats my take on it anyways, I think some people stopped reading your article once you started dumbing down what the app dev wanted to do.
JNI is not always needed to access C libraries from Java, there is Bridj (https://code.google.com/p/bridj/) and similar libraries. They allow you to write Java code that access native APIs pretty easily.
The http://sqlitejdbcng.org project is a SQLite JDBC driver that uses Bridj to access a SQLite shared library. It's probably very similar to what the article author is doing with SQLitePCL.raw.
I think the answers to your questions are entirely dependent on the perspective and agenda of the audience they might be targeted to.
A certain segment of the world of software development cares for only one thing: pushing out as much product as fast as possible. The quality of the product's construction is (almost) irrelevant (or at the very least very low on the priorities list). This segment isn't going to place much emphasis on the importance of having developers with sufficient experience and expertise to understand the actual whole stack. That is, they'd answer "yes" to the last question in your comment.
I'm closer to what I suspect is your view: native all the way. There's rarely a good technical reason to prefer a non-native abstraction-on-an-abstraction language in the world of mobile development (I'd go one further--in the world of any software development), even when there are plenty of "business-y" justifications for it.
I agree. It drives me nuts not to understand the stack I'm using. But sadly, our lower level tools are not good enough. We need higher level tools or a significant fraction of applications and tools will simply not exist for the foreseeable future.
It should be possible though, to bring at least some of that convenience to shallower stacks. Those tools are not as good as they could be. Static compilation instead of VMs (but still with a REPL), Type inference instead of full-on dynamic typing, libraries instead of frameworks, etc.
(For the same reason, I think it's better to rent dedicated servers than to use virtual machines or whatever-as-a-service. And colocation might be better still, if one can afford the up-front expense.)
What isn't clear to me is whether we should still use a high-level runtime like Mono/.NET, for mobile apps in particular, even though we have to be responsible for lower layers. On the one hand, very few developers would want to mess with manual memory management and C-style error handling when writing business logic, database access routines, or UI code. On the other, if we have to grasp the whole stack anyway, then we can more easily do that if there's less of it. On iOS, cross-platform C code plus iOS-specific Objective-C code is less complex than cross-platform C code plus P/Invoke glue for the former plus cross-platform C# code plus UI code in C# (which will be foreign to iOS developers not familiar with Xamarin) plus glue between Mono and ObjC. Similar logic applies to Android (although there will always be JNI glue between native code and Java) and even Windows Phone (as of 8.1, which supports WinRT and native code using that). So, for a more comprehensible software stack since we have to be responsible for the whole thing anyway, should we just give up on higher-level languages and runtimes, acknowledge that we're ultimately dealing with C machines, and stick to C or maybe C++ for cross-platform code? Would that be putting too much emphasis on hypothetical debuggability, and not enough on other things like developer productivity and approachability to less-than-expert developers?