It's Been Real, Android: Why I'm Retiring from Android - <AUTHOR> https://raptureinvenice.com/its-been-real-android-why-im-retiring-from-android/ <comment><USER4> A while back, Dianne Hackborn famously said:

"We often see questions from developers that are asking from the Android platform engineers about the kinds of design patterns and architectures they use in their apps. But the answer, maybe surprisingly, is we often don't have a strong opinion or really an opinion at all." (1)

While that may have been a lofty ideal, in practice Android has many strict requirements on how you partition your code between Activity, Fragment, ContentProvider, and Service classes. Never mind testability and all the new semi-opaque / intelligent battery optimizations Android applies to your app.

After all these years, I still find the most difficult and un-natural thing is mixing concurrency / background tasks that must outlive the UI with complex UI component lifecycles. This is a frequent and necessary thing to do, and also quite awkward. The result is unnecessary complexity that often and easily permeates the code. Dianne says they have no opinions on architecture, but where I disagree is _concurrency is an architectural concern_ and there are definitely many corner cases & snafus mixing that with Android APIs.

(1) [https://plus.google.com/+DianneHackborn/posts/FXCCYxepsDU](https://plus.google.com/+DianneHackborn/posts/FXCCYxepsDU)

<comment><USER5> > After all these years, I still find the most difficult and un-natural thing > is mixing concurrency / background tasks that must outlive the UI with > complex UI component lifecycles.

Completely agree. I've been developing for Android since 1.0 and the complex interaction between background tasks and activity lifecycle is the worst part of Android that a significant majority of devs get wrong, introducing subtle bugs. (And the worst thing is that the documentation pretends like this issue doesn't exist last time I checked. Newbie developers have no chance getting this right, even experienced dev often ignore it.)

Overall, I wouldn't say Android is poorly designed, it's just mediocre, I would expect more from Google. In general, I'd say the design lacks simplicity and elegance. Some examples:

\- Fragments. Activities were already overly complicated and for some mysterious reason they took it to the next level with fragments. (They should get rid of or redesigned activities too.)

\- Older version of Google Cloud Messaging library - hundreds of lines of source code to implement a basic hello world example (wth)?

\- Documentation is unclear in some cases, promoting some cargo cult patterns such view holders (zero effect on performence these days). Also, services, if you don't need IPC, the only "feature" of a service is that it lowers the probability that the app gets killed. I usually just create a simple service and start / stop it as a way to telling the system "don't kill the app".

<comment><USER6> >Overall, I wouldn't say Android is poorly designed, it's just mediocre

I think it is mostly have to do with company's talent pool and focus.

As far as I can see (I may be wrong, this is my estimate) Google tries hard to devote best talents to 1) ads and Search and it's maintaining 2) Chrome team 3) Google apps and services online and on iPhones.

After these option they try to develop Android as kinda (I don't know what is they correct word, so I am going with kinda) side project because they know the world needs an open platform for competing with apples devices.

The reason because why Android is unacceptable from Google is we all used Google's best products. Chrome and search and we kinda (by default) think about Google as non fallible.

But that's nowhere near the reality, they have limited number of super smart guys, and they try their best to keep core products (search and browser) much better than competitors.

Most of the time when Google does release a new app their iOS apps is better than Android's ones.

We would be okay if Android was from mediocre company. But it is not, it is from Google , which is the best in some areas. But they don't have unlimited talent. They are trying their best to balance.

I am not saying people who worked on Android are not that bright. No I am talking about more broader picture. Of course there some excellent people who work on Android. But I am not talking about 1,2 or three. I am talking about management perspective in broader sense.

This is my personal understanding, I may be completely wrong.

<comment><USER7> I really doubt that.

By the way, I think Android UI works much better than iOS's.

<comment><USER6> >By the way, I think Android UI works much better than iOS's.

You should be specific about what about Android UI is better than iOS?

if you are saying android UI design is better than iOS , I agree , but remember Material design is not android's design. Google wants to expend to every platform, it is quite childish if we think they could expand to every platform without having professional UI design language for themselves. They designed Material design for all of their product, not just for android. Yes android was first one to adopt, and I really like Material design. So if you are talking about material design , it was not _only_ for android, it was actually Google Design language, and I really like it.

But if you are talking about performance and how ui fits together, I disagree 100% , for example they didn't had splashscreen for long long time (If I remember correctly they adopt splash screen a year o two ago), every time you were going to open an app, you were noticing a blank screen for quite a long time some times(1,2 second) which was quite ridiculous. At the other hand iOS had fixed splash screen for quite long time. Some third party apps tried to develop splash screen of their own , but almost all the time result was not on par (not even close) with iOS counterparts. Right now their rotation animation have problems which can show itself under pressure. and so many thing I don't even remember right now.

I am not saying android is bad or something , android is wonderful product. But lets be honest, it is not core product for Google like chrome is, and it has huge problems. But its main advantage is its openness.

<comment><USER8> UI is not only design, but also UX.

One of big Android advantages are activities and intents. It allows for application cooperation in a way that's not possible on iPhone. Even the default app concept is based on intent handling - and that's why I can use Firefox as my default browser, Nine as my default mail app and Sygic as my default navigation and send stuff from other apps over Threema. On iPhone, I would be stuck with Safari/Apple mail/Apple maps/iMessage no matter what others offer.

This also affects integration from third parties. There's no reason for an app to support just Dropbox, when there are intents, that all other services support. Unless you want to artificially limit the integration, or you came from iOS and are not used to that.

</comment></comment></comment></comment></comment></comment><comment><USER9> Just like the web platform, Android is hugely improved when you leverage the community libraries and tools they provided. Gradle actually helps a lot with that, since its clear dependency management makes use of external libraries a breeze.

If in 2016 you're still complaining about AsyncTasks and its management, you certanly have missed a lot of progress in the last few years. It's not unlike having people complain about JavaScript issues without ever looking at jQuery, React or newer tooling.

The most useful things you can do for yourself currently are:

* Adopt Kotlin as a language. It's not all that different from Swift, comes with IDE support, tiny standard library and really fixes the pain of Java 6.

* Use MVP patterns and its friends. There are a few libraries which take most of the pain of lifecycles away.

* Use RxJava, Retrofit, Glide, etc. libraries that make your life easier with concurrency. A lot of these tools are better and easier to use than what even exists on iOS. Using AsyncTask in 2016 is just silly, it was never a good API.

* Use Gradle! Driven by its scripting language, you can do so much to script and automatize your build.

Other than that, I agree, after years of development:

* Some Android APIs just aren't well thought out.

* Gradle badly needs performance improvement.

* State of NDK is just sad. Fixable, but sad.

* MultiDEX is a result of a very very dumb decision in Android 1.0 and it's going to hurt us for a long time :/

All-in-all, I honestly think the author didn't really look into Android all that much to have complaints that he had. The blog post is somewhere on the level of someone complaining about IE6 JavaScript bugs when we've already moved on to React and are dealing now with very different issues.

(And no I'm not saying Android is great or even a great platform. It's not. It's just that, just like on Web, you can do a lot to fix major pains.)

<comment><USER10> > It's not unlike having people complain about JavaScript issues without ever > looking at jQuery, React or newer tooling.

But this is exactly what makes being a Javascript developer a miserable experience.

And I can give Javascript some benefit of the doubt since it's a multi-vendor language with complex standardization processes and all the stakeholders have their own interests and limited financial backing. By contrast, Android is a single vendor platform with practically infinite financial and labor resources behind it.

It's just a mess. I'd expect a relatively painless experience: install dev tools, start a new project, build and go! But no, it's jumping through hoops, requires understanding a myriad of different SDK/platform versions and a constant churn in keeping your apps up to date with new versions while trying not to break backwards compatibility.

And a big part of this mess comes from the fact that device manufacturers and mobile operators are unwilling to keep old devices up to date (and Google can't force them, while I think they should with some kind of licensing contracts), leaving customers exposed to security flaws while keeping the developers churn high with multiple versions to be supported.

<comment><USER9> You can open Android Studio, create a new project and "Go!". It'll work. Then you can add a single line of code to dependencies and you get even better APIs!

I also have no idea why are you mixing the device updates into the developer tooling argument. New apps are (should be - and the tutorials tell you so) developed with API 19+ in mind which means that you'll have to work for quite a while to get any problems with fragmentation and updates. You can even start development on API 21 and ditch support libraries all together and STILL not shed significant amount of userbase.

<comment><USER11> >You can open Android Studio, create a new project and "Go!". It'll work

I tried this after their 1.0 release and it crashed. Mileage varies from person to person

<comment> V-2 I believe you, but Android Studio has come a long way since.

I agree it was abysmal at first - when it didn't crash, every new update would break compatibility and your projects wouldn't build anymore etc.

Right now it's pretty decent, considering, although I'm not a fan of Gradle either.

By the way, even though it's a fork of IntelliJ Idea, it's ultimately shaped by Google which has sort of a tradition of realeasing alpha-stage software into the world. Remember first releases of Chrome? I do; they crashed like crazy and lacked basic functionality such as printing.

</comment></comment></comment></comment></comment><comment><USER12> I don't think that the person is being lazy. I've tried my hand at Android. I will continue to do so. I don't like it for the reasons enumerated in the post. The whole damn thing is a hack at this point. No one has a good generalizable architectural model for laying out an Android project. Attempting to target multiple devices is truly a pain. You can do it. You have to really, really think about. You also have to end up making whole sub sections of your product for a specific form factor.

I'm not saying that iOS is better. Don't really know. I've played with Swift and a few of the Apple tutorials.

In general, I'm against the current incarnation of mobile. After years of having an Android (and now having an iPhone due to work), I switched to a Samsung Juke. That's right, a feature phone! The Android just got slower and slower. No updates, not improvements. Finally it screeched in my ears while working. I picked it up and slammed it on the desk (felt great for a week). Both iOS and Android are slow, overly wrought operating systems.

That being said, unlike the author, I'll still use Android and iOS for my products. I have products that need to be mobile. They have to target the machines my customers have now. That also means that I'll have two native app code bases. I'll have to keep track of native app UX/UI standards. I'll have to keep such hardware around ('cause Android's emulator is still sucks when I've got an VM running).

<comment><USER13> I was surprised to learn that Android in 2016 doesn't even natively come with an equivalent of JavascriptCore. You have the pleasure of somehow getting V8 to run and then serialize/deserialize all your native objects manually in order to talk to it if you want javascript outside the browser. Really? From the company that is the most web native around, and even developed the most common browserless JS runtime (V8)?

Google's user faced architecture often just seems like an unmanaged jumbled up bunch of code that they throw at you, good luck have fun.

<comment><USER14> > I was surprised to learn that Android in 2016 doesn't even natively come > with an equivalent of JavascriptCore. You have the pleasure of somehow > getting V8 to run and then serialize/deserialize all your native objects > manually in order to talk to it if you want javascript outside the browser.

That's a little bit like saying that Chez Panisse doesn't even deliver sewage to your table, and that if you want to pour it over your food you need to bring your own chamber pot with you.

Java is not a great language to program in, but if there's any language it is clearly better than, then that language is JavaScript. Why would one want to program an Android app in JavaScript rather than in Java?

There's only one reason to use JavaScript: because one is deploying in a browser, and JavaScript is the only language supported by the vast, _vast_ majority of browsers. In every other way, it's a misbegotten mistake of a language.

<comment><USER13> The big reason: Cross platform compatibility. Not just between mobile platforms, but even between mobile devices and webservers. Our devices are so powerful now that you can run a full blown webserver on it if you choose your DB system wisely. That's why we use CouchDB - replace it with CBL on mobile and take your whole webapp with you for offline use. I'm Swiss - we have lots of tunnels ;-).

</comment></comment></comment></comment><comment><USER15> I think there are no developers that are true experts in both Android and iOS platforms. Every developer I know either leans towards one platform or another. There are also developers who know both platforms pretty well, but I won't call them experts in either.

I consider myself an expert in Android development. The only point that I agree with is multidex, but there are historical reasons for the limitation and I think Google engineers are trying to fix this problem or make it as simple as possible to use multidex.

I occasionally do iOS development and some things in iOS don't make sense to me, but I'm sure they would be obvious for an iOS expert.

My advice for mobile developers or future mobile developers is to specialize in a single platform that you like more. For me it's Android. For the author of the article, it seems to be iOS.

<comment><USER16> I am an expert in iOS dev but I use and want to like Android. It is quite annoying... I really do not like the walled garden of Apple and on Android devices, even cheap MTK ones I am quite handy at installing what I want, but for some reason I find Android development a real pain compared to iOS where I find most older things (stuff, as it goes in life, needs to mature) very obvious and easy.

I would say what most annoys me about iOS is the GPL thing which is the reason, among others, there are no emulators in the Appstore, at least no relevant ones. As owner of a museum and fan of old machines I cannot do without emulators. On my Android tablet I have around 50. Emulators is a niche but no GPL is hampering a lot for everyone on iOS.

<comment><USER17> The GPL incompatibility issue has nothing to do with Apple not allowing emulators. (After all there are BSD/MIT emulators) They don't want (non- sandboxed) interpreters running unreviewed code. Right now the only interpreter allowed to be used with downloaded code is webkit's JS JIT.

<comment><USER16> There are multiple reasons as I said: one is the one you say but some emulators I use are under the GPL and use many GPL libs.

But yes the other restriction sucks too. The point was cannot normally use emulators under iOS which stands, whatever the reason may be.

<comment><USER16> For instance [0] which I use by far the most has both problems; however with another license the runtime issues would be fixable. For instance, recompile the runtime with emscripten. Luckily there is webmsx now which looks promising, but that is not there yet.

[0] [https://github.com/openMSX/openMSX](https://github.com/openMSX/openMSX)

</comment></comment></comment></comment></comment><comment><USER18> > Google's adoption of gradle has been a disaster and proved to be a terrible > decision. It did help out with some previous issues, namely multiple app > targets, but it's slowed down compilation severely. It also makes for > masochistic configuration files with major redundancy and fragmented > dependency hosts. Getting an app to compile shouldn't be a challenge.

The only thing worse than gradle is ANT, which it replaced.

> Wait, what is picasso? Oh wow, I hadn't heard of that one…I was busy > learning Swift.

I just minimize the amount of platform specific tech in the codebase as much as possible. RxJava? That's going to be _real_ fun to port...

Ahh, this didn't even touch on my least favorite part of Android - <USER2> line tools that tell you they've "successfully" deployed APKs. And returned successful return codes. That in reality silently failed due to ever so slightly loose USB connections.

On the plus side, they finally fixed [https://code.google.com/p/android/issues/detail?id=197287](https://code.google.com/p/android/issues/detail?id=197287) in Android 7.0 it looks like...? I'm trying to remember if that was the bug to blame for my last 16 hour day...

<comment><USER19> > The only thing worse than gradle is ANT, which it replaced.

What's wrong with ant? I liked it.. It was simple to understand for the most part.

It also made it easy to develop without an IDE, although I'll admit I don't know how easy it is now as I stopped doing Android a year ago

<comment><USER9> And that's about all it does. Gradle has proper dependency managment with Maven repository support (add one line and your library is in, no fsckery with JARs and whatnot), has scripting in an imperative language instead of craziness of XML (we use it to automate releases, uploads, Git commits, etc.) and really good plugin support.

It's also slow as arse unfortunately.

<comment><USER20> Except many of us are comfortable with XML "craziness" and see no value in Gradle besides wasting battery.

</comment></comment></comment></comment><comment><USER21> We adopted buck at work for android & objective-c ios and it's been amazing speed & low-bullshit wise:

[https://buckbuild.com/setup/getting_started.html](https://buckbuild.com/setup/getting_started.html)

If gradle is killing you, I would suggest trying it out.

Warning: we have a few guys in a mobile developer experience team, so I don't know how good it is for indies.

<comment><USER22> I have the opposite experience -- I tried Buck because I really wanted a Blaze/Bazel clone (it wasn't open source at the time). It works but I find it very slow.

My project involves lots of native code and genrules, though. If you're mostly building Java code I imagine Buck might work well. If starting from scratch I would try Bazel first.

<comment><USER23> Buck's speed improvement is heavily dependent on breaking your code into modules. What was your project setup like?

<comment><USER22> I have 2300 lines in about 40 BUCK files, plus 500 lines in 2 DEFS files. Just parsing the BUCK files seems to take an inordinate amount of time (tens of seconds from cold).

</comment></comment></comment></comment><comment><USER24> I found that as I get older, and still try to learn different languages and platforms, that I have to try and work on my research skills as much as my coding skills.

As the OP pointed out - straddling several languages means that syntax and keywords are not always readily apparent when you sit down to code, but knowing where to look for them and refresh your memory quickly becomes an activity all on its own.

This from a guy who is a week away from being 50, and still occasionally puts a ';' at the end of his ruby code blocks.

<comment><USER25> I always thought those language/framework/library cheat sheets were for newbies only, but I'm beginning to see that's not entirely the case.

</comment></comment><comment><USER26> Unless you are writing a Tier 1 application that needs every fancy do-hicky, I don't see the point of 100% native anymore. Use React Native, then if necessary have a devoted native developer for each platform to handle parts that absolutely have to be executed in native and provide a JavaScript API. If you are a big company with tons of money, sure, create duplicate teams to make the same app for each platform. But if you are small or just starting, React Native is the best choice.

<comment><USER27> I'm all for write-once-deploy-everywhere, but React Native is better suited for apps that could be easily written web-only. Maybe I don't get what's better about React Native over a native app that is just a web view.

<comment><USER28> > Maybe I don't get what's better about React Native over a native app that is > just a web view.

It's better because React Native is actually rendering native components. Stuff like PhoneGap never feels or works quite right as a side effect of being rendered in a web view.

<comment><USER29> I think his point is - why make a native app that just re-renders the data which you can just as well look at in a browser.

<comment><USER30> Next to the fact that something like push notifications require a native implementation, people like apps more.

I'm currently working on a way to make our mobile-tailored website into an app, just because customers keep requesting a _real_ app instead of a webpage.

</comment></comment></comment></comment></comment><comment><USER31> Like the op, I do both iOS and Android development work. However, as an indie, my platform preference is primarily market-driven. So most of my work has been on iOS

Unlike the OP, I like and use Android AsyncTasks. I have no problems with Android fragments either.

However, I did have a lot of other concerns with Android - primarily the low quality of Google's SDK for Android. Here is what I wrote about it [https://blog.cascadesoft.net/2013/12/31/the-bigger- problem-w...](https://blog.cascadesoft.net/2013/12/31/the-bigger-problem-with- android-bugs-and-quality-not-fragmentation-per-se/)

<comment><USER32> >primarily the low quality of Google's SDK for Android.

This has always been my biggest frustration with Android. I've written a few applications for the platform, and while their architecture leaves a lot to be desired I've never had any real problems with it. However, the immense disappoint and anger that comes from their SDK idiosyncrasies is astounding. Google really just hates stability and nice API's, in my opinion. Everything from GAE to Android, it's always just so terribly frustrating to keep track of any one-off decisions they make without any form of actual communication from the development team.

I've been writing Android code since the G1 days.

</comment></comment><comment><USER33> I do not think writing Android apps is straight-forward and would not recommend it to new developers or engineers like the author who want to do other things like iOS. People's expectations for apps is only getting higher, and there are many, many things you need to understand in order to be a produce great Android apps.

As an example, another commenter noted the Android platform engineers not being opinionated about application development as a "lofty ideal", but more likely this is a consequence of the framework team having enough on their plate. The vanilla Java AOSP API surface (not even considering the NDK, support libraries, Google Services, etc.) is enormous. The Activity lifecycle is complicated, and it's very easy to leak memory or write spaghetti code. There are many ways to do similar tasks, and these also change with time. Etc.

That said, I love being an Android developer, and it is improving at an accelerated rate. To start, Android Studio and Gradle are far superior to the pain of getting Eclipse, Ant and the SDK tools working together.

Yes, Swift is awesome and shiny, but there is so much more to a platform than the language. Java has excellent tooling - great support for debugging, monitoring, automated testing for CI/CD (automated UI testing still needs work, but also improving), static analysis, etc.

The support libraries are also a godsend, enabling you to make an app that looks modern while being frequently updated and handling a lot of the compatibility headache from the platform's diversity.

Finally, there's a lot of great content online. The conferences are great and its expected to see their content on YouTube. Google's Android Developer YouTube channel is also fantastic (shout out to Jo and Ian!), and Google is slowly but surely improving the developer docs and integrating their sample code into Android Studio.

So yes, you do need to understand the new functional reactive approach. You need to know how to write a Gradle build. You have to understand the complexities of proguard rules. It's all pretty frustrating. But I also feel that many of the skills are more easily transferrable - I can also write a Gradle build for a library or I can use IntelliJ to better debug a servlet. With Swift and iOS, there's only vendor you can build for.

<comment><USER34> > So yes, you do need to understand the new functional reactive approach. You > need to know how to write a Gradle build. You have to understand the > complexities of proguard rules. It's all pretty frustrating. But I also feel > that many of the skills are more easily transferrable - I can also write a > Gradle build for a library or I can use IntelliJ to better debug a servlet. > With Swift and iOS, there's only vendor you can build for.

I couldn't agree more. Android experience is hard-won. You have to 'discover' and develop an intuition for application architecture and how to use UI components effectively over time.

The upside is a well-architected Android application --using tools like MVP, dependency-injection, and functional-reactive programming-- will have the positive characteristics of a Service Oriented Architecture: encapsulation, statelessness, composability, loose-coupling. This may seem like overkill for an app, but it minimizes the effect of UI lifecycle issues novice and intermediate developers tend to complain about.

Architect a few Android applications in this way and you gain valuable experience composing abstract services together. A competency that is transferrable to backend services and other platforms.

<comment><USER35> Any resources you'd recommend in particular to learn FRP and how it applies to Android, specifically.

As a frequently frustrated intermediate developer I'd greatly appreciate it. I've just begun using RxJava and Robospice to tame my server endpoint call logic, but I know it's just the tip of the iceberg.

<comment><USER34> It's taken a few false starts and experiments for me to become comfortable. Eric Meijer is an excellent resource for understanding the theoretical underpinnings and the 'why' of it all.

Soundcloud has a reasonable and practical approach on Android: [https://www.youtube.com/watch?v=R16OHcZJTno](https://www.youtube.com/watch?v=R16OHcZJTno)

A good bet is to search Github for projects where common Android APIs or libraries are Rx-ified. You'd be surprised at the economy and simplicity of code you can find in some of the best Rx implementations.

</comment></comment></comment></comment><comment><USER36> Without mentioning which platform(s) I prefer, I have to agree with the author. On one hand, it's nice to be able to work cross-platform, and architecting your app such that you maximize code sharing is a worthy and satisfying goal. But quite a bit of code (the UI mainly) cannot be shared and it's kind of tiring to finish your Platform A app, look at it with pride, and then face the need to essentially re-write the exact same thing for Platforms B and C, only in different languages and frameworks "because platform competition". You're splitting your attention, expertise, time, and learning N-ways.

<comment><USER37> I don't get it. How can there then be all of these weekend tossoff games in the Play Store that work just fine? Unless I'm unclear on what you mean by "platform."

<comment><USER26> An app that uses native UI widgets is very different from a game which uses a graphics engine. The game compiles cross-platform with minimal changes.

<comment><USER38> Can you point me to a good resource for "a game which uses a graphics engine". Last week, I built both an android app and an iOS app, and would like to build something that compiles cross-platform to complete the set.

<comment><USER39> I would assume he is talking about something like Unity.

<comment><USER40> Or Godot, or Love2D, or many other open source game engines with both desktop and mobile functionality.

</comment></comment></comment></comment></comment></comment><comment><USER41> I've been doing Android development since the G1 release. I agree with most of these points, but think they're also not a huge deal after you've been working with the platform for awhile. The biggest issue is by far the iteration speed though. Build/install take way too long--Android Studio for some reason takes 15 seconds to start my app even if no changes have occurred.

Instant run is supposed to solve this, but it's too buggy to be useable right now. Sometimes your changes just don't apply, but you never know if that happened or you messed up your fix.

I actually preferred ant since I better understood what it was doing. Gradle error messages are often very vague and confusing, and build times are strangely inconsistent.

</comment><comment><USER42> What is surprising is that google with their much celebrated hiring practices for senior devs managed to hire no one who could say no to such insanities like Fragments and Async and the entire Android dev platform/toolkit as it stands today.

Apple, formerly famous for being design hippies who couldnt care less about performance, have topped the mobile performance charts for nearly a decade straight now and with no end in sight. An entire decade! They merely had the wisdom of not choosing java to base their platform on.

<comment><USER43> Where do you base you claim about apple not caring about performance? They have pushed the performance envelope ever since the first Apple computer where Woz built it with way fewer chips than their competitors. Their ui's have always demanded extreme performance.

</comment></comment><comment><USER44> I don't think lifecycles, phone rotation etc. are much of a problem, because once you know them, you know them.

I think the problem is Android keeps changing the current best practices. I'm not even sure how to know what those are - if you enter code from the Android tutorial into Android Studio, much of it is deprecated.

In January 2011, the way to do tabs in Android was via LocalActivityManager. Then in February 2011, ActionBar.Tab was added. By July 2011, the LocalActivityManager way was deprecated, and ActionBar.Tab was was pointed to as the way.

Then in November 2014 with the release of API 21, ActionBar.Tab was deprecated ( [https://developer.android.com/reference/android/app/ActionBa...](https://developer.android.com/reference/android/app/ActionBar.Tab.html) ). So what do we do for tabs now? Who knows? The most current tutorial ( [https://developer.android.com/training/implementing- navigati...](https://developer.android.com/training/implementing- navigation/lateral.html#tabs) ) is still telling you to do it in the way that was deprecated two years ago.

That's what is maddening with Android - they have a way to do tabs, add a new way, deprecate the old way within five months, then three years later change their mind and dump the new way - without changing the documentation and telling you the new way to do it, it's all just deprecated.

The tutorial is full of deprecated code. What's the new way to do it? Who knows?

A few years ago some corporate director at Google must have gotten a directive to push Google TV. So then they were pushing all apps to work with Google TV. I guess that fizzled out. The latest thing is making sure our legacy apps work with Chromebooks which allow multiple apps on the screen at the same time.

I don't mind Google and Android continually chasing the new shiny, but I wish they wouldn't have a tutorial full of deprecated code, I wish they didn't change how they do things such as tabs every three years (three new ways to do it in three years). I wish they fixed bugs instead of implementing new features. On code.google.com, developers post bug reports, then many other developers jump on saying they see the same thing, and...a few years later, it just closed for being obsolete.

Another example of continuous churn - Google Analytics looks like its going by the wayside, to be replaced by Firebase. Admob is now integrated into Firebase. So that's a whole other thing that needs to be redone in an app. You have to run to stay in place.

<comment><USER45> I've only dabbled in Android but this is what drives me mad. I spend a month digging in and learning "how to develop for Android" and then six months later when I go to use that knowledge for my real job, everything's changed. What was best practice last time I looked is now frowned upon, deprecated or flat- out broken, whole generations of new best practice have churned by, and current 'best practice' isn't compatible with any handset more than three months old.

If you're doing it 40+ hours a week then maybe the ongoing investment is worth it but to me it's a colossal waste of time.

<comment><USER27> I feel that way about most of the development world.

</comment></comment></comment><comment><USER46> Gradle has problems, but it doesn't seem worse to me than making builds in Eclipse was. I would love to hear why people think it is better or worse.

I agree multidex is terrible. Google please fix this.

I do not know when I should use a fragment instead of a view. I know the layout reasons google gives in their developer guide but I don't think I have seen a piece of code that really uses fragments that way. So why?

I do like Android development though.

<comment><USER47> Gradle is just incredibly slow on Android compared to Eclipse. particularly with larger projects. Instant Run has helped alleviate this to some extent, but it's still not uncommon for a build to take 2+ minutes.

I guess this is mostly due to all the resource crunching that Android does, and the fact that Android Studio doesn't perform incremental compilation by default.

Another annoyance is that every time a minor change such as incrementing a version number is made, Android Studio grinds to a freeze syncing gradle files.

<comment><USER48> Incremental compilation seems to be on for newest release of Gradle, but Android is still on 2.x due to the plugin.

For our project, the most time consuming part is... Packaging. Making apk splits is slow, why does it zip the whole thing again if it is just replacing resources?

<comment><USER49> > why does it zip the whole thing again

Maybe fragmented zip files with holes inside are undesired? Because that's what you get when modifying zip files in-place.

</comment></comment></comment></comment><comment><USER50> Kind of an OT whine relative to the contents, but I'm still extremely frustrated at how hard it is to get other languages working on Android due to the multidex-style issues.

Google should be spending millions being able to get app development up and running in something like Python. Have your app up and working in 2 minutes without having to learn Java. It boggles the mind that this isn't the case, and that the current tooling environment is soooo impossible to wrap ones mind around.

<comment><USER51> The same could be said about any platform - e.g. why can't I write my iOS apps in python?

Transpiling languages like that nearly always ends up messy, and adds another layer of potential bugs to the system. Taking the time to learn the platform will end up better in the long run (at least with the current state of transpilers).

And as it stands, you can write Android apps with a native UI in Java, Kotlin, JS (React Native) and C# (Xamarin). And you if you want you can write business logic using any language that will compile to a C binary (using the NDK).

<comment><USER50> So the multidex issue I was referring to makes it pretty hard to write things that will compile to C with the NDK.

In order to get any access to the Android APIs, you have to do C-JDK bridging through JNI. And in android VMs, there's a _hard limit_ on the number of symbols you can reference in the lifetime of an app.

It's the equivalent of if python was like "yeah you can use the standard library, but only up to 100 functions!"

iOS, since it goes through the LLVM framework stuff, doesn't have that many barriers to transpiling from other languages. You can just do raw function calls to the OS libs. But Android doesn't allow this, forces you to go through the JNI, and makes you have to work around this symbol limit.

</comment></comment></comment><comment><USER52> iOS has plenty of developer pain points as well, although in their case a lot of them are as much a result of dumb Apple policies as they are technical mistakes. I'm going the other way. After six years of iOS work I've had enough. I still think the web is the smart long term bet so that's where I intend to focus my energies.

<comment><USER27> I agree. However, I would have never thought that developers would be so miserable in 2016. Say what you will about the desktop; developing for it was a pleasure (except for you, Win32 API) compared to what we have in 2016.

<comment><USER53> The sad part is that things were looking pretty hopeful in 2008-2010.

I particularly liked Cappuccino. It's basically a port of Cocoa to the web. You could design your interface in OSX's Interface Builder. The project is still around and is still being worked on. Sproutcore was pretty similar, and is also still around. Neither of them are being developed as heavily as React or Angular 2, but they have both been mature for a long time, and perhaps don't _need_ a lot of work to be done on them.

Maybe it's just me, but I still find 280Atlas[1] and 280Slides[2] more impressive that many web apps that ship today, and they're nearly 10 years old and ran in browsers far slower and less capable than what we have now.

I actually think more developers would frameworks like these if they didn't feel they had to stay on the latest and greatst JS treadmill to remain employable. And I write that as someone who _likes_ React and Angular. They're both sane ways to develop complex apps, but they don't feel _that_ much better than what was possible 8 years ago.

[1] [https://www.youtube.com/watch?v=ouzAPLaFO7I](https://www.youtube.com/watch?v=ouzAPLaFO7I) [2] [https://www.youtube.com/watch?v=tMZwfh- _QEQ](https://www.youtube.com/watch?v=tMZwfh-_QEQ)

</comment></comment></comment><comment><USER54> When I started development on Android platform I was told that we should not do IO on UI thread. Fine enough. What is the alternative? Every tutorial out there including Google's suggested AsyncTask.

Only after few weeks I learned that we should never use AsyncTask for IO because internally it uses a threadpool of hold your breath 2 threads !

So how do I make all my REST requests ? Through something like Volley. This library is even more disgusting as it does not support some simple urls such as [http://example.org/?id=1&id=2](http://example.org/?id=1&id=2).

So I turned by focus on Services only to learn later that Services are meant for background tasks but run on UI thread.

The best approach to do your own IO is through IntentServices. Something that should have appeared in the first tutorial.

</comment><comment><USER55> Android should drop Java.

It's nothing like writing 'normal' Java, and the baggage that is bought along isn't worth the effort.

I like Java. I hate Android development.

<comment><USER56> Do you still need to do manual malloc/free inside Java code to handle images in Android? That crap tripped me up when developing for it ca. 2011.

<comment><USER20> Yes, they optimized it and did a few changes in the way things work, but you still need to watch out.

[https://developer.android.com/training/displaying- bitmaps/ma...](https://developer.android.com/training/displaying- bitmaps/manage-memory.html)

</comment></comment></comment><comment><USER57> The link from HN redirects me to [https://raptureinvenice.com/its-been-real- android-why-im-ret...](https://raptureinvenice.com/its-been-real-android-why- im-retiring-from-android/wp-admin/install.php) with this error:

The raptureinvenice.com page isn't working -- raptureinvenice.com redirected you too many times.

Anyone having same problem?

<comment><USER58> Yes. I faced similar problem so I went to Google Cache. [http://webcache.googleusercontent.com/search?q=cache:https:/...](http://webcache.googleusercontent.com/search?q=cache:https://raptureinvenice.com/its- been-real-android-why-im-retiring-from-android/)

</comment></comment><comment><USER59> I've never been an Android developer, but i am happy Xamarin (Forms) developer. It is not without some hassle, need to deal with a little amount of platform-specific code, but it's the way mobile development should be in 2017. Code the experience and functionality, do not loose (too much) time on platforms.

<comment><USER60> Last time I checked Xamarin Forms about a year ago it was still limited.

Is it better now? What are some of its limitations?

<comment><USER53> It's still limited in that it's not a good choice if your app requires UI functionality that is very platform specific. I think that's intentional - <USER3> isn't intended to be the right solution for every application.

It's still a good choice if your app mainly involves displaying lists and tables of text and images, and data entry forms. The cross platform Map control works quite well too.

I don't remember exactly what is different now from a year ago, but if you list a few of the limitations you faced, I can tell you if they still exist. A quick look at the Pages, Layouts, and Controls section of the Xamarin Forms page might tell you if they've added things that were missing last time you tried it: [https://www.xamarin.com/forms](https://www.xamarin.com/forms)

<comment><USER60> Thanks for the info. From what I've seen things haven't changed much. The idea still seems to be that Forms is for simple apps that use a number of common components.

<comment><USER53> Yeah, it is similar to React Native ins that way. There's a limited set of cross platform components. In both Xamarin and RN, though, you can also include your own platform-specific components/plugins when necessary.

</comment></comment></comment></comment></comment><comment><USER61> At least Android doesn't require me to buy a Windows license or Mac computer (not just the license: OS X requires Mac hardware which is notoriously expensive). I'll keep it at Android.

</comment><comment><USER23> I was an Android developer, then flipped to being an iOS & Android developer. I chose to go back to solely Android for similar reasons to the OP. It felt like it was impossible to be excellent on both platforms. I was struggling to keep up with the pace of change.

I ended up choosing Android because I found more demand for Android developers in the market. I certainly understand some of the OP's frustration with Android development.

<comment><USER62> Oversaturation of iOS devs. Many people chasing the perceived glamour, diluting each other's pie.

There's a lot of silver lining to doing android development for other people. Inflated demand, and all the client side - server side fires have already been put out when the company did the iOS project. So I would say, easier or less stressful.

But I've been at this for a while, so there's the possibility I'm just good at it.

</comment></comment><comment><USER63> Given all the grief expressed in the post and the comments, it seems like if someone architected a really nice, developer-friendly native mobile API for _any_ platform you would get droves of devs flocking to it.... Despite the two major players, the market seems wide open as long as they focused on the development experience like what Matz did for Ruby... Programmers are customers too! :)

<comment><USER64> I've heard a lot of praise for the Windows phone developer experience, but what really matters is the audience. Dev's flock to the audience. Even just a small pay difference will dev's to deal with the most terrible of developer experiences(ex. Sharepoint)

<comment><USER20> I do hobby coding between Android and WP, and do love the experience.

Microsoft might have lost the mobile war, but they are on good track to win the hybrid laptops one.

</comment></comment></comment><comment><USER65> Allow me to repost two of my rants against android from a while back:

[https://news.ycombinator.com/item?id=8328646#8329034](https://news.ycombinator.com/item?id=8328646#8329034) [https://news.ycombinator.com/item?id=9475825#9476547](https://news.ycombinator.com/item?id=9475825#9476547)

</comment><comment><USER66> I like comparing iOS to Android development as similar to playing Mario Kart and Dark Souls... It truly is a mess and I won't be surprised if/when someone releases an Android SDK SDK (SDK squared!) that generates all the horrible boilerplate so that you can start a network request, rotate your device and get the result in your view with no additional headaches.

</comment><comment><USER67> Cached version as it is down: [https://webcache.googleusercontent.com/search?q=cache:dFoTDF...](https://webcache.googleusercontent.com/search?q=cache:dFoTDFe6w1AJ:https://raptureinvenice.com/its- been-real-android-why-im-retiring-from-android/+&cd=1&hl=en&ct=clnk&gl=au)

</comment><comment><USER68> I get a 404 on that article. Maybe the DB is having issues still. A cache here

[https://webcache.googleusercontent.com/search?q=cache:dFoTDF...](https://webcache.googleusercontent.com/search?q=cache:dFoTDFe6w1AJ:https://raptureinvenice.com/its- been-real-android-why-im-retiring-from-android/)

<comment><USER69> Or here [http://archive.is/girlg](http://archive.is/girlg)

</comment></comment><comment><USER70> As an Android only Dev I cant disagree with any of his reasons, the tools especially are just terrible, its not unusual to spend hours trying to figure out why my project will not build, this is compounded if you live in a country with poor internet connectivity, GB sized updates to the tools are not fun.

</comment><comment><USER71> I get redirected to the Wordpress install page, which cannot connect to the database?

[https://raptureinvenice.com/its-been-real-android-why-im- ret...](https://raptureinvenice.com/its-been-real-android-why-im-retiring- from-android/wp-admin/install.php)

<comment><USER72> I just get infinite redirects.

</comment></comment><comment><USER73> I'm not an Android developer, but I've seen my Android phone and tablet greatly deteriorate in performance over the last couple of years, mostly due to Android updates which were forced on me. I rarely use my tablet anymore because of this.

<comment><USER74> That is the same with all computer platforms, though. I think it is OK if companies have a limited time of support for their OS, but you can debate how long it should be. With Android, it is also the responsibility of the phone manufacturers, not just Android/Google alone.

<comment><USER75> This is certainly true of Windows (which I don't use anymore on the desktop). Until as late as Windows 7, I would do a wipe/install every couple of years, just to get my performance back to the way it was after a fresh install.

I haven't done with this macOS, but I've heard of people doing this.

<comment><USER74> Even with many Linux distibutions you can't run the latest version on older Computers anymore. But at least you can probably find a special Linux for older hardware.

</comment></comment></comment></comment><comment><USER76> After writing a comment elsewhere i find myself wondering if why iOS is preferred, is that once an app is launched the app can behave pretty much like they could back in the dos days.Each app its own island, having the run of the device until the user hits the home button.

Android on the other hand is more about stitching apps together into a larger whole via intents. Thus you have not not only care about what the user will see and interact when tapping the icon in the launcher directly, but also when getting a intent from another app.

And most Android apps seems to fail on the latter. Various IM apps and such have been notorious for not going back up the intent chain when hitting the back button.

</comment><comment><USER77> The comparaison with JS is perfect. Like JS is the asm of the web ecosystem (no one wants to write its code just in JS, we generate it instead), default android and IOS way of programming have to be be generated.

Try Xamarin [0] or the newcomer flutter [1]. It's such a pain in the ass to dev in raw android or raw ios, use multi platform sdks.

And if you start with xamarin, you can target windows phone too, even if nobody cares ;-)

[0] [https://www.xamarin.com/](https://www.xamarin.com/) [1] [https://flutter.io/](https://flutter.io/)

<comment><USER78> I've had some terrible experiences with Xamarin. The tooling is very rudimentary compared to Android Studio, performance is subpar, app size is huge, and development is so slow it's maddening. I wouldn't recommend it other than for some very specific use cases. I'd much rather deal with just plain old Android issues than wrapped-by-Xamarin Android issues _and_ Xamarin- specific issues.

</comment></comment><comment><USER79> Interesting, I have avoided much mobile development for the past decade for the same reasons OP mentions.

However, I have been drawn in by the promise of React Native, which addresses compilation time and cross platform concerns.

</comment><comment><USER80> I've recently been dabbling with the new android studio 2.x and It has improved considerably in the past 3 months.

For a single application all I need is:

\- A main activity where I commit fragments to show stuff

\- A settings activity foryouknowwhat

\- A main application class to store all the data and state

\- Some model classes for downloading/parsing/storing/data

\- A service that can be used from my main activity and notification manager

I've been at it for a few months and the experience hasn't been as terrible as described. (Yes I do have async tasks that update the UI)

</comment><comment><USER81> > Google's adoption of gradle has been a disaster and proved to be a terrible > decision. It did help out with some previous issues, namely multiple app > targets, but it's slowed down compilation severely. It also makes for > masochistic configuration files with major redundancy and fragmented > dependency hosts. Getting an app to compile shouldn't be a challenge.

To be fair iOS dependency management is also a huge pain. CocoaPods is worse than working with Gradle in my opinion.

</comment><comment><USER82> For me I quit android studio to use aide to develop directly on the device. I got the remix os tv box for $50. I got fed up with needing and ultra expensive machine to develop my free software. I don't profit from Android but aide enables me to continue to contribute free apps without bankrupting myself to run an expensive development machine to do hobby software.

</comment><comment><USER60> Mobile development in general is a pita.

We really need a native cross platform solution that doesn't involve either running a JavaScript VM (ReactNative, NativeScript), writing UI code for each OS (Xamarin), and doesn't rely on a WebView.

Xamarin Forms could fit the bill, but last time I checked it wasn't there yet.

What other option are there?

<comment><USER83> Has there _ever_ been a cross platform solution in history that was superior to the native development platform unique to the OS? This seems to be the pipe dream that everyone repeatedly hopes for then gets burned.

I'd actually prefer if Apple and Google had their own development platforms so there are competitive driving forces to improve the platform. It will also accelerate experimentation with new tech where one platform can validate one tech so the other can adopt it quicker.

Then if you have a simple lightweight app you can use some form of cross- platform browsery JS app (about the only point where this makes sense).

<comment><USER60> Superior? Depends on what you are doing.

Working with game engines is a joy since you write "client" code, so to speak, and the engine is compiled for each platform.

QT is also really good, but also really expensive, and you lose native UI which can be a good thing or not depending on your use case.

NativeScript is working on becoming a universal cross platform solution similar to ReactNative. It's already on mobile, and I've read there is a macOS version being worked on.

</comment></comment></comment><comment><USER84> I worked on android for 3 years, then did something else for 3 years, now am back to Android, there are so many vendors selling android phones, so it shall work just fine I assume? or is it getting much worse for developers(system and app developer) these days?

</comment><comment><USER85> I think it's good to remember that it goes both ways [https://twitter.com/devunwired/status/786542912469213184](https://twitter.com/devunwired/status/786542912469213184)

</comment><comment><USER7> I like Android development with React-Native and Clojure.[1]

But this probably doesn't fit the bill for prof Android developers.

[1] [https://github.com/drapanjanas/re- natal](https://github.com/drapanjanas/re-natal)

</comment><comment><USER86> I see two types of dev methods 1) Write it all down, read through the code a few times. Then compile and do a full test. 2) Write in steps, compile and test after each step. The later is a Pita on low level. And produce more bugs.

<comment><USER87> Regardless of the platform, for any application with a non-trivial amount of complexity, iterative development is the best approach. I don't understand how anyone could "write it all down, read through the code a few times and test" and not produce a buggier application that doesn't meet most expectations. It does help to do some initial design work, create abstractions, loose coupling, etc. Iterative development does not mean jumping into coding without a high level plan on how to create the application pieces and how things would work (or do what's called as "cowboy coding").

With the amount of complexity involved in developing applications, considering the architecture, design, interactions between application components, error handling, different classes of platform APIs, UI, UX, state management, concurrency, hardware configurations to support, and many other things, I doubt if any human could really keep all that in one's head and really work through all the possible ways that assumptions during coding would get beaten, when compared to a real execution of the application and using that practical feedback in changing, fixing and improving things.

<comment><USER88> You are confusing scopes here. The parent almost surely meant those approaches applied to a single task (meaning a few hours to a day of work), not to building an application.

<comment><USER87> Being pedantic - the parent was commenting on the article, not on a comment here dealing with a single task or one small piece worth a day's work. I see no indication on how you could make a statement saying "...almost surely meant..." Based on the information available, either of our premises could be true.

<comment><USER86> The authors main complain was that it takes two minutes to start the emulator. And I agree that it is a Pita. But as a mental exercise or fun experience, you should 1) Picture it in your head 2) Make a plan 3) Write it down 4) Read through it and fix errors 5) Test it on the emulator.

You could start with a small ten minute fix, then work your way up. The feeling when it compiles and just works on the first try is amazing.

</comment></comment></comment></comment></comment><comment><USER89> oh you'll be missed. I've worked on Android for ages, I don't remember in the last 3 years of one single AsyncTask I've used.

</comment><comment><USER90> What takes 3 hours for ios development takes 3 days for Android. Things are little bit better now that android studio is maturing, though.

</comment><comment><USER91> I did the same years ago, I had to decide and... well iOS is a paradise compare to Android

</comment><comment><USER92> Sorry for my ignorance, but wouldn't React Native help with these sort of problems?

<comment><USER93> React Native does not help with any sort of problems.

<comment><USER52> If you need to build an iOS _and_ Android app and you don't need to really push the envelope on design then React Native is a godsend. It's not the right solution for everything but for that vast array of apps that are mostly just list/tableviews talking to a REST backend it's a massive timesaver.

I've been doing native iOS work for six years now and I'd still recommend RN over straight native for a lot of projects.

</comment></comment></comment><comment><USER94> Developers do need to pick a set of core technologies, and stick to it or a career can fall apart I bet. I don't know from experience. I've been a Java DEV ever since MSFT tried to hijack the Java language with a proprietary version back in 1998, and I abandoned MSFT and never went back. I can imagine trying to be both iOS and Android developer would be about as insane as trying to be both .NET and Java developer. Oil and water. Doesn't mix. For me there is one and only one word that i need to hear to know I want to avoid iOS: "proprietary". I wouldn't touch any Apple product with a 10ft pole. I like open systems, and Apple is all about maintaining their closed little private invite-only walled-garden of an ecosystem. No thanks. They may be successful a while longer but "open" ALWAYS wins in the end.

<comment><USER95> > Developers do need to pick a set of core technologies, and stick to it or a > career can fall apart I bet.

How boring! I'd go mad if I didn't get to work in new domains with different tools every so often.

<comment><USER96> Every so often is OK, but every a new language / set of technologies with every app means you will be writing junior to intermediate level code every time.

When we are interviewing and I see CV's that have so many technologies listed that I am fairly sure they have very little depth of knowledge to many of them.

<comment><USER20> Or worked as consultants.

On our case we are required to stay flexible and take whatever projects come when one is released from a project, it is not always possible to say "I don't do X".

So every few months there is a new stack to work on.

</comment></comment></comment></comment><comment><USER97> Which is Why he should move to Xamarin. Xamarin Forms can let him maintain one codebase over multiple platforms and leave the rest to convention

</comment><comment><USER98> Librarians often don't realize that they can't keep plugging in method bodies and get what they want forever. Engineering isn't f&@!ing Madlibs for Christ's sake. Learn to build things that will work 100% of the time and never compromise!

</comment><comment><USER62> lol, I've had those sentiments

employers are also skeptical you are content with both, I wouldn't consider it a value add unless you can land a lead position for a mobile team

aside from working on multiple platforms diluting your experience with the latest development patterns, it is just as easy to be stuck maintaining an old project or legacy code with an employer. This isn't unique to mobile of course, but multiple platforms really exacerbates how fast it happens.

<comment><USER62> *competent, not content

</comment></comment><comment><USER99> i have to say, refusing/unable/lazy/ to learn is the most terrible thing ever happened to a developer. I'm always excited about new things even I have to learn them hard, even they start with poor quality, but I believe these are what make developers happy

<comment><USER100> I feel you are concentrating on a very small and negative part of the post in a very disingenuous manner.

I read the article more as: "I have found throughout the years I've become a decent programmer in iOS and Android, I'd rather be a good or excellent iOS developer."

The end just briefly describes why he decided to go with iOS instead of Android briefly, but that's about it.

</comment></comment><comment><USER101> Yeah well, Craproid APIs are awful. It's gotten marginally better in tooling (the new IDE framework shits itself like only half the times compared to the Shitclipse based one), but there's still just too many brainfarts in the APIs. And ofc the implementatations are super fragmented and buggy.

Here's a case in point: Androids MediaPlayer and its state diagram. This is pretty straigthforward pipe to the underlying Khronos OpenMAX API (that is totally brain damaged and horrible by itself). [https://developer.android.com/images/mediaplayer_state_diagr...](https://developer.android.com/images/mediaplayer_state_diagram.gif)</comment>


Bart takeover robbery - <AUTHOR> http://www.sfchronicle.com/crime/article/BART-takeover-robbery-50-to-60-teens-swarm-11094745.php <comment><USER2> Well I guess I'm taking a Lyft back from the airport tonight.

I wonder how these things are planned. Texting, WhatsApp? Sounds like it would be super hard to counter this kind of hit and run style take over.

<comment><USER3> Concealed carry provides a possible solution. Worked against train bandits in the 1800s and this is not much different.

<comment><USER4> I don't know - I'm better armed than most, but I don't think I'd want to shoot it out against 40 people in a train car.

</comment></comment></comment><comment><USER5> [https://en.wikipedia.org/wiki/The_Incident_(1967_film)](https://en.wikipedia.org/wiki/The_Incident_\(1967_film\))</comment>


Secret Network Connects Harvard Money to Payday Loans - <AUTHOR> http://www.bloomberg.com/news/2014-09-04/secret-network-connects-harvard-money-to-payday-loans.html <comment><USER2> Clearly there is a need for something _like_ payday loans, where people in dire straits can get small cash infusion to get them by. It also seems to be the general consensus that these same people are "high-risk", and so require higher interest rates.

So what's the solution to this problem? Clearly a lot of (maybe all) of the payday loan-type places are _evil_ \-- is there a way to service these customers without being evil? Would a not-for-profit (or perhaps even a not- for-an-exorbitant-profit) payday loan organization be possible? Or would the typical nasty collections process, the thousands of dollars of interest on a $500 loan still be required, even if the people at the top _weren 't_ becoming millionaires?

I guess what I'm asking is, in the story, we see someone paying something like $3900 on a $700 loan, made by one of these _evil_ companies. What would their total bill be if the loan was made by a non-profit organization? Would it be more like $1000, or still closer to $3900?

<comment> a-priori Instead of this, set up a non-profit payday loan company that offers loans at market rates, but uses the profits from the loans to offer free financial planning and education for its customers.

<comment><USER3> Market rates? You mean the same rate that people with good credit get? I'm guessing there would be no profit in such a situation.

<comment> a-priori No, by 'market rate' I mean what other payday loan shops are charging in the area.

The real problem isn't the loan itself, even if it seems exploitative: if someone is in a cash crunch, it's perfectly rational to pay something like $20 to get $200 today (that seems to be what places near me advertise, at least as introductory rates) so they can pay their rent and not be evicted. The problem is the cycle they get into where then they're $20 behind for the next one. Then they get another loan and they're $40 behind for the next one, and so on.

So you catch people that are already in the cycle, fix their immediate need (they need $200 to pay their rent), then help them figure out a way to solve the larger problem (have cash on hand in time for next month's rent) and break out of the cycle.

So the 'mission' of the shop would become to put themselves _and all other payday loan shops_ in the area out of business due to a lack of customers.

Of course, this assumes that the root problem is a lack of planning or education about personal finance. Maybe an outsider's perspective would help. Or maybe that's completely the wrong assumptions, I don't know.

</comment></comment></comment></comment><comment><USER4> If you are interested in this topic, you should watch: Last Week Tonight with John Oliver: Predatory Lending (HBO) [1]. I think he does a pretty good job in giving an overview of what predatory lending is. Although, he does not talk about Harvard, MIT, or pension funds, this is all new as far as I know.

[1] [https://www.youtube.com/watch?v=PDylgzybWAw](https://www.youtube.com/watch?v=PDylgzybWAw)

</comment><comment><USER5> There's a documentation called "Master of the universe" by Marc Bauder, which really shows the insides of how finance works nowadays. I don't know if it's available in english yet, :/.

Trailer with english subs: [https://www.youtube.com/watch?v=OIUPWWwEclc](https://www.youtube.com/watch?v=OIUPWWwEclc)

From IMDB [0]: "A former banker in Germany, who entered the business with the advent of modern computer systems reminisces of his working years in some of the world-leading banking corporations."

[0] [http://www.imdb.com/title/tt3129484/](http://www.imdb.com/title/tt3129484/)

<comment><USER6> Even better, check out Last Week Tonight's bit (John Oliver's show on HBO) on payday loan companies [0] - they're utterly appalling.

[0] [http://m.youtube.com/watch?v=PDylgzybWAw](http://m.youtube.com/watch?v=PDylgzybWAw)

Edit: spelling

</comment></comment><comment><USER7> Personally I think if a university is as rich as Harvard is "investing" (unwillingly/indirectly accoding to the interview) in a payday loan, they might as well just make a Harvard Loan Institution which it lends students loans on a reasonable interest rate. Students CAN also invest in this loaning business and get a fair share. But I am sure IRS, the state and the federal government will jump in and make everything impossible to run.

</comment><comment><USER8> Should Google really be selling advertising to these sites? Payday loan operations really are the scum at the bottom of the barrel.

<comment><USER9> Google makes, quite literally, billions of dollars off the bottom of the barrel.

There is a dark iceberg under the consumer Internet. Online pharmacies. Rebill scams. "Government grant" applications. High interest loans. Educational institutions of dubious utility (disclaimer: took one's shilling once, indirectly, and regret it a bit). Spam, scams, and the like, on a massive scale.

There is a UI for AdSense publishers where some Google PM made the decision "If we give them options to tart up their website less, let's tell them how much money it costs."

[http://www.seobook.com/how-make-easy-money- google](http://www.seobook.com/how-make-easy-money-google)

<comment><USER10> At least re: online pharmacy, that's patently false. Coming from someone who currently runs a legitimate online pharmacy, there is a 9-12 month accreditation process (VIPPS) that adwords, etc requires before letting you advertise.

<comment><USER9> That's presumably because Google doesn't want to be fined another $500 million for having their AdWords sales reps give their pharmacy customers advice on how to avoid Google's pharmacy compliance rules.

[http://bits.blogs.nytimes.com/2011/08/24/google- reaches-500-...](http://bits.blogs.nytimes.com/2011/08/24/google- reaches-500-million-settlement-with-government/?_php=true&_type=blogs&_r=0)

<comment><USER11> That would depend on whether Google is ever actually expected to PAY $500 million and whether they earned more than $500 million by breaking the law to begin with. If they made $501 million off of it, all the government has done is guarantee that is the new standard for business conduct. And usually companies that get hit with $500 million fines get that reduced to $100k or so on appeal.

</comment></comment></comment></comment></comment><comment><USER12> I think this raises the interesting point that investments have become increasingly abstract. Money goes in, returns come out, and that's generally the end of the story.

I certainly can't list all of the companies I have investments in, and I bet most people can't either, other than to say they have a mix of mutual/index funds.

<comment><USER13> I refuse to hold broad funds for this reason. It's much less convenient and potentially a lot costlier (making individual stock trades or at least sticking to smaller sector funds, which generally have higher expense ratios, where I can approve of each holding), but I have my own definition of evil companies and I refuse to hold even 0.0000000000000001% of them.

<comment><USER14> >and I refuse to hold even 0.0000000000000001% of them.

You say that, but 0.0000000000000001% of even the world's largest company by market cap (Apple, at 592.44B) would be $0.000000560337

if you ever so much as glance at an ad an evil company runs, then assuming a CPM of $0.01 (two orders of magnitude lower than actual average cost), your single glance is worth $0.00001 or 17 times the value you said you would never hold.

So you'd never hold $0.0000000000000001% of an evil company but you are more than happy to just give them 17 times that value for free by glancing at one of their ads at some point in your life?

You need to lower your purity standards if you don't want to be a hypocrite :)

EDIT: all right, I mixed my metaphor. just think of an evil ad company :)

<comment><USER13> I'm not sure I follow you about giving them 17 times that value. If I think a company is evil, that means I won't be buying their products, so if they're paying for my ad impression, that's good from my point of view because they're just throwing money away without any chance of me buying their product. (Not that the amount of money is meaningful, but still.)

But yeah, the 0.xxx1% percentage was just exaggeration :P

</comment></comment></comment></comment><comment><USER11> The US has usury laws? I thought those were abandoned decades ago? Serious question... I thought Delaware started by getting rid of them and everyone else followed suit to attract the business of consumer lending companies? What level does interest have to be to qualify as 'usury' now?

<comment><USER15> Usury is defined by individual state law. Some states have no usury laws, but many do. There are loopholes in alot of them as well. Here's a summary of the state laws:

[http://www.lendingkarma.com/content/state-usury-laws- legal-i...](http://www.lendingkarma.com/content/state-usury-laws-legal- interest-rates/)

</comment></comment><comment><USER16> What an interesting and complex network.

It says some horrible things about me that what I found most interesting was the demeanor of Zeke Faux. I have rarely ever seen someone so visibly uncomfortable in front of the camera. It was kind of amazing.

</comment><comment><USER17> Once again, ethics gets run-over by the greed bus. Nothing new to see here folks, carry on...</comment>


PyCon 2010: Optimizations And Micro-Optimizations In CPython - <AUTHOR> http://pycon.blip.tv/file/3259830/ <comment><AUTHOR> This is a delightful talk. I don't usually delve into learning what is under the hood in Python, so the clarity here was appreciated.</comment>


I got rejected at YCombinator 3 times in a row - <AUTHOR> I got rejected at ycombinator 3 times in a row.<p>Is that an indicator that I should shut down my startup? Or that I should stop applying to ycombinator, because it won't generate any different results? <comment><USER2> What did you change or do differently between applications?

<comment><AUTHOR> I started having a good number of users. I started generating revenue, it's small though. market validation is completed.

</comment></comment><comment><USER3> did you apply anywhere else? there are a million incubators. there are a million accelerators. try another one

</comment><comment><USER4> It works better in columns.</comment>


Bitcoin and virus signatures - <AUTHOR> http://pastebin.com/ct2WHUK5

<comment><USER2> Yes, the blockchain is globally appendable by anyone with Bitcoins. This is a feature, not a bug. Having it any other way would imply possible censorship.</comment>


What does it mean when there is a (1) by my login name at the top? - <AUTHOR>

Also I want to edit my login name, is that possible? <comment><USER2> The (1) is your karma. Make valuable submissions and comments, people will upvote you, it will increase.

And no, you can't edit your login name.

</comment><comment><AUTHOR> Thank you

</comment><comment><USER3> The "1" is your karma.</comment>


"Super Engine" may fundamentally change the way internal combustion engines work - <AUTHOR> http://www.anl.gov/articles/argonne-achates-power-and-delphi-automotive-investigate-new-approach-engines <comment><USER2> I'm assuming the purpose of developing a more efficient engine is to reduce emissions and thus "saving the planet"? That may seem commendable, but from what I have read it is actually a wasted effort, unless you can make it 99%+ more efficient (which you cannot). So, even if this engine is all that it claims (which most other comments here seems to question), it still uses oil and therefore is part of the problem and not the solution. (Wrote abit about this a while back with more references: [http://torkeldanielsson.se/reducing- emissions-is-not-enough](http://torkeldanielsson.se/reducing-emissions-is-not- enough))

Edited comment: Man, I don't get hacker news... Why do you downvote this? I thought I was adding a valid and important point - that an increase in efficiency is fighting the wrong battle. I even added references via link. I would be super happy if I could be informed of what in this post is offending or off topic!

<comment><USER3> There are advantages and disadvantages to internal combustion engines.

Compared to _external_ combustion engines (steam engines), ICEs have much quicker start-up and response times. Steam engines require building up a head of steam, and actually exhaust the working fluid (water) over time, which is why steam railroads had water towers every so often.

ICEs have been improved over more than 130 years, and scale from a few CCs of displacement to many cubic meters -- the smallest ICEs could fit in the palm of your hand, you could stand in the largest and not reach the sides or top of the cylinder.

Liquid hydrocarbon fuels are exceptionally energy dense by _both_ weight _and_ volume. This makes certain classes of use very difficult to substitute for: commercial passenger and freight aircraft, overland truck transport, and powered marine shipping really have few tractable alternatives. Aircraft would all but disappear without liquid hydrocarbons (gasoline for piston engines, kerosene for gas turbines), trucks would probably be replaced with electrified rail, and shipping would return to wind power. Optimists might suggest nuclear marine powerplants, but I find that unlikely; ships are lost at far higher rates than is commonly realised: about 200 every decade, and existing trials of both military and nonmilitary nuclear marine power have proven it expensive and nonviable for all but the most demanding instances -- aircraft carriers and submarines.

They're also quite stable in storage (proved over hundreds of millions of years), relatively safe to handle (no respiration or exceptional contact protection required), and their combustion products are _mostly_ benign: CO2 (I'll get to this) and H20 with scant quantities of carbon monoxide, sulfer and nitrogen oxides, and other contaminants or partial combustion products, all of which can be greatly mitigated with combustion and exhaust controls and treatment.

The CO2 exhausted isn't a problem _in itself_ but for the, um, slight problem that in the past 200 or so years humans have returned to the biosphere carbon sequestered over several hundreds of millions of years. Which turns out to be a rather considerable problem.

But it's _only_ a problem where what you're burning are _fossil_ fuels. There exist several options, though all _much_ more expensive and/or constrained than present fossil fuels, for creating synthetic hydrocarbon-based liquid fuels. These _also_ have challenges. Biofuels are intractable at scale given natural limits on plant production: what's called "HANNP" \-- the human appropriation of net primary production -- or the photosynthetic ceiling. There's only so much plant growth which occurs and humans already consume much of it (40%, biofuel replacement of fossil fuels would consume another 20%, see Jeffrey S. Duke's "Burning Buried Sunshine" (2003), PDF available online, for more on this.

Another prospect: sequestering carbon from the biosphere, and combining it with hydrogen, electrolised from water. The US Navy and national energy labs (especially Brookhaven), as well as M.I.T., have researched this for the past 50 years. It's proven expensive and hasn't been scaled past very low production (a few litres), but _does_ work. It raises costs of fuel from one unit of input energy per 20-40 units made available to _two_ units per _one_ provided -- that's a 40-80x increase in the real cost of fuel.

Not cheap, but it might still be our best option.

<comment><USER4> For the same reasons you mention, ICEs are also crucial to heavy-duty mobile robots (see e.g. Boston Dynamics).

<comment><USER3> Seems fuel cells might also fit in there. Though yes, powerplant design (and noise/exhaust) are limiting factors.

Also: stored-energy locomotion. Fully-powered walking is _expensive_.

<comment><USER5> From an energy and CO2 emission point of view, fuel cells are no different than an internal combustion engine.

<comment><USER3> Fuel cells:

1\. Run silently or near silently. They're generating electricity via redox reactions, not combusting.

2\. Have effectively no moving parts. Again, no noise or vibration.

3\. Product electricity directly. For powering electronics, this means no secondary generation required.

4\. Utilise extremely expensive catalysts. The reason you don't see fuel-cell automobiles (excluding very small numbers of test vehicles) is that the engines cost, literally, on the order of $1 million, as opposed to a few hundred for a typical ICE. This price premium has proven difficult to overcome.

5\. Operate better delivering fairly steady-state power, from what I understand. A tremendous benefit of ICEs is that they can scale output in a second or few seconds, with very little throttle lag. Yes, straight-up electric motors are even better at this, but straight-up batteries tend to not store much power.

A fuel cell is essentially a battery whose electrolytes you _fill_ rather than _recharge_ or _replace_. This offers the advantages of fuel-based systems (high energy capacity) and batteries (direct electrical output). Unfortunately, it introduces the disadvantages of fuel cells (cost, power delivery profile).

<comment><USER5> I was thinking of hydrocarbon fuel cells (hydrocarbons in, CO2, water, useful energy and heat out). In any case, I agree with your analysis.

<comment><USER3> Yes, that's one option. I'm a little shakey on the specific function, characteristics, and reaction materials, but some form of redox and electron flow is what you're aiming for.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> There is this guy who has made some similar engine prototypes in this field of efficient opposed piston engines.

PatOP: Single-Crankshaft Opposed-Piston Engine

[http://www.pattakon.com/pattakonPatOP.htm](http://www.pattakon.com/pattakonPatOP.htm)

OPRE: Opposed piston Pulling Rod Engine

[http://www.pattakon.com/pattakonOPRE.htm](http://www.pattakon.com/pattakonOPRE.htm)

      > A 500cc two stroke can easily make some 80 Nt*m (8 Kp*m) torque.
      > At 6000 rpm this torque makes some 50 KW (70 PS).
      > 50 KW from 20 Kp means 0.4 Kp per KW.
      > And 0.4 Kp/KW with direct injection Diesel efficiency sounds interesting, especially for an engine with such a low cost."

</comment><comment><USER7> So, as I understand it, it combines the compression ignition of diesels with opposing pistons. The opposing pistons go toward one another and compress the air/gas mixture and ignite it. The exhaust escapes when the pistons move back through ports machined in the sides (kind of like a wankel/rotary engine removes exhaust gasses).

Sounds like they're trading the spark system (a pretty easy to maintain system) for a second piston/crankshaft/etc. Essentially pulling out a cheap and perfected system for one that adds a bunch of high stress, expensive parts. Just from that sounds like a bad idea.

They say the extra efficiency comes from heat loss from the cylinder head, but I have a hard time believing they're capturing that much extra (double-digits) efficiency from heat loss alone, especially given the reduced efficiency of having more moving parts.

<comment><USER8> Side ports are also used in 2-stroke piston engines. Most often found on mopeds and chainsaws.

<comment><USER9> This engine design is, in fact, 2-stroke according to the article.

<comment><USER8> It seems to lack a defining characteristic of your typical 2-stroke though, that the fuel is initially drawn in below the head to lubricate the crankshaft (this require mixing oil in the gasoline, done automatically on modern mopeds).

[https://en.wikipedia.org/wiki/Two- stroke_engine](https://en.wikipedia.org/wiki/Two-stroke_engine)

</comment></comment></comment></comment><comment><USER10> "The new engine will meld the best characteristics of gasoline and compression ignition engines with an innovative piston architecture refined by Achates Power that sets two pistons moving in opposition in one cylinder."

We already have this technology. Diesel engines ignite the fuel through compression. We also had the opposing pistons layout for a while ([https://en.wikipedia.org/wiki/Opposed- piston_engine](https://en.wikipedia.org/wiki/Opposed-piston_engine)).

EDIT: we even have triangular-y shaped opposing engines ([https://en.wikipedia.org/wiki/Napier_Deltic](https://en.wikipedia.org/wiki/Napier_Deltic))

<comment><USER11> This engine appears to burn gasoline rather than diesel fuel. I suspect the compression must be much higher to ignite gasoline than is required for diesel.

<comment><USER3> Compression required to "diesel" petrol (gasoline) is _lower_ , which is why some autos have the problem of continuing to run ("diesel") after the ignition (and spark) are shut off. Most now incorporate other controls and limiters, such as controlled fuel injection, to eliminate this.

Gasoline is comprised of a shorter set of hydrocarbons (mostly 6, 8, and 10 chain) than diesel (about 12-16 chain length, though 8-21 carbon are listed at Wikipedia). Volatility (and ignitability) _increase_ with shorter chains -- methane (C2H6) and butane (C4H10) -- that is, two and four chain hydrocarbons -- are both gaseous at or near room temperature.

Longer chains still get you heavy fuel oils, tars, etc.

<comment><USER12> _Longer chains still get you heavy fuel oils, tars, etc._

...and eventually that results in simple plastics like polyethylene, which is basically a _very_ long chain hydrocarbon:

[https://en.wikipedia.org/wiki/Polyethylene](https://en.wikipedia.org/wiki/Polyethylene)

<comment><USER3> Yep. I regret not having studied more chemistry in college. It's only started coming into context for me recently.

</comment></comment></comment></comment></comment><comment><USER12> Efficiency aside, big two-stroke engines, particularly diesels, tend to have a very distinctive sound. I guess this one, being also two-stroke and compression ignition, would probably sound somewhat like this:

[https://www.youtube.com/watch?v=mkH9QRaQJM0](https://www.youtube.com/watch?v=mkH9QRaQJM0)

Even if they weren't all that much more efficient, I bet a lot of people who miss the 2-stroke diesel sound would want one in their car.

<comment><USER13> Modern car engines are already very silent, but many drivers love roaring sounds (probably due to false logic that more noise == more power). Car makers know that and fake engine sound using audio system(0) on many cars without anyone actually noticing, so I don't see why it can't be done in this case too.

0\. [http://www.huffingtonpost.com/2015/01/23/fake-engine- sounds-...](http://www.huffingtonpost.com/2015/01/23/fake-engine-sounds- car_n_6533596.html)

</comment></comment><comment><USER14> I thought that gas based engines topped out at 30% due to the heat loss intrinsic with burning fuel(all that waste heat). Is this tackling that in some fundamental way or is it just an incremental improvement?

<comment><USER3> Carnot efficiency. 30% is pretty typical in land-based motive systems. Shipboard combustion engines and coal-fired power plants (of all things) are rated as high as 45% efficiency.

This is based on input and output temperatures, more than anything.

<comment><USER14> Got it, so a 1.5x improvement on 30% lines right up with 45%. That's where they're getting their 50% gains number from.

<comment><USER3> Good eye, though it's not immediately clear that that's strictly edging in on Carnot efficiencies or if other aspects (two-stroke power cycle, valveless port-based design, eliminating cylinder-head heat loss -- on which, doesn't that eventually reach equilibrium temp _anyway_?, etc.) are to credit.

I've seen a few other radical reciprocating energy designs, there are some interesting YouTube vids I should track down. I think "radial engine" might reveal something. New Zealand, possibly Australian engineering firm, IIRC.

</comment></comment></comment></comment><comment><USER15> Opposed pistons have had good success in marine and railroad applications.

[https://en.wikipedia.org/wiki/Fairbanks_Morse_38_8-1/8_diese...](https://en.wikipedia.org/wiki/Fairbanks_Morse_38_8-1/8_diesel_engine)

<comment><USER12> And limited success in trucks:

[https://en.wikipedia.org/wiki/Commer_TS3](https://en.wikipedia.org/wiki/Commer_TS3)

</comment></comment><comment><USER16> Opposed pistons is a way to have a very long stroke engine (high torque and smaller piston speeds = smoother), without the bigger radius that the crankshaft pin would have to rotate.

</comment><comment><USER17> Large engines (in giant container ships) are supposed to be approaching the efficiency limit according to theoretical thermodynamics. Does this get small engines close to the limit?

<comment><USER18> I doubt it very much, since the main difference between the two are thermal losses due to size and speed.

</comment></comment><comment><USER19> Achates power has been running engines on test stands since 2011, I haven't heard of any engines installed anywhere.

Maybe this kind of business is different compared to software where you're expected to build something revenue generating relatively quickly.

<comment><USER20> That's why VC loves software, no billion dollar factories to build before you can start selling a product.

<comment><USER21> We have invested in a Company that has Chinese partners building the billion dollar factories for us.

[http://www.ecomotors.com/post/ecomotors-receives-new- investm...](http://www.ecomotors.com/post/ecomotors-receives-new-investment- current-customer-zhongding-power-adding-funding-bill-gates)

</comment></comment></comment><comment><USER22> This is not the same thing as from the article, or even a gas engine, but it reminds me of this project. I never found out what became of this: [http://www.nytimes.com/2000/09/19/science/putting-a- darwinia...](http://www.nytimes.com/2000/09/19/science/putting-a-darwinian- spin-on-the-diesel-engine.html?pagewanted=all)

>Dr. Senecal's test engine consumed 15 percent less fuel than a standard engine while producing one-third as much nitric oxide and half the soot.

<comment><USER23> > I never found out what became of this

That's a common pattern in new (combustion) engine designs; there's a lot of them being published every year, but almost none of them actually end up being mass-produced and they dwindle into silence or as just demonstration models. Why? I don't know; the media only seems to focus on the invention and potential, not the failure (or if I were to put on my tin foil hat, the disappearance under mysterious circumstances). The only nonstandard engine that (AFAIK) ever got some leverage was the rotary wankel engine, and even that was (iirc) in just one car model.

<comment> semi-extrinsic Mazda RX7 and RX8 had wankel engines. Nice cars, but higher maintenance than with normal engines.

I think the main reason for the pattern you observe is that what's optimal and what's cost effective in a car is highly non-intuitive. Take front-wheel drive, for instance. Mechanically more complex than RWD, but (apparently) worth it due to the space savings inside the car.

Or take water-methanol injection: well-understood tech that's been in use since WW2, can save fuel and reduce NOx emissions significantly, or give higher power output. But it requires changes to all the fuelling infrastructure, and that makes it essentially a non-starter outside of racing cars.

</comment></comment></comment><comment><USER24> > The research is being conducted under a three-year project funded by a $9 > million award from DOE's Advanced Research Projects Agency-Energy (ARPA-E) > and an additional $4 million of cost share from the team members.

So, the total cost of designing this prototype was $13 million? What's the size of the R&D budget for a typical automaker?

To me this just shows that typically businesses are in the mindset of "business as usual" because it's what they are comfortable with rather than looking into radical, new, innovation.

</comment><comment><USER25> _cough_ I'm going to leave this here....

[https://en.wikipedia.org/wiki/Napier_Deltic](https://en.wikipedia.org/wiki/Napier_Deltic)

<comment><USER26> It says in the first paragraph that it's diesel.

<comment><USER25> From the parent article:

 _The new engine will meld the best characteristics of gasoline and compression ignition engines with an innovative piston architecture refined by Achates Power that sets two pistons moving in opposition in one cylinder. As the crowns of the pistons slide toward each other, they compress a mixture of air and gasoline to such extreme pressures that the mixture auto-ignites without the need for spark plugs in a process known as compression ignition._

which is the same principle as the deltic engine.

</comment></comment></comment><comment><USER27> HCCI is difficult enough--high compression ratio requires strengthened materials. Plus there's the hydrocarbon issues that come up with low temps. Maybe the heat retained by not having a cylinder head would be able to compensate? High temp burn/lean burn can lead to high NOx which is pretty bad if you need a urea injector system.

Mazda, GM and others are known to be working on CI engines for gas targeting 2020, so this might be the next step in 10 years. Assuming we don't all switch to pure electric...

</comment><comment><USER28> While several people have mentioned the Napier Deltic, there was also the Junkers Jumo 205 opposed-piston diesel aero engine of the early 1930s.

[http://www.enginehistory.org/Diesels/CH4.pdf](http://www.enginehistory.org/Diesels/CH4.pdf)

Claims of innovative internal combustion engine designs that will be significantly more efficient than current ones show up every few months. They never live up to the hype.

</comment><comment><USER29> Hopefully DOE also has $9 Million or more invested into battery research for electric motors.

But I guess $9 Million isn't unreasonable if it actually produces engines that automakers will adopt.

<comment><USER30> Heck, the Obama administration already blew at least $193 million in the Fisker debacle.

<comment><USER29> Note the government gives $10 Billion per year in ethanol welfare to corporations. We could take the loss out of that.

In fact we could fund 50 more startups EACH YEAR with the ethanol subsidy. Some of them will work, some will fail, still would be same $10 Billion.

</comment></comment></comment><comment><USER31> For the curious, [1] (via [2]) shows various engine designs.

[1] [https://imgur.com/gallery/bxzeN](https://imgur.com/gallery/bxzeN) [2] [https://www.reddit.com/r/educationalgifs/comments/468290/a_c...](https://www.reddit.com/r/educationalgifs/comments/468290/a_collection_of_gifs_demonstrating_a_few/)

</comment><comment><USER32> Better tech detail here: [http://achatespower.com/our-formula/opposed- piston/](http://achatespower.com/our-formula/opposed-piston/)

</comment><comment><USER8> Unless its a engine that gets us away from using oil, its not a fundamental change.

<comment><USER33> From _burning_ oil, perhaps. Throwing oil into a mythical "Mr. Fusion" and extracting the mc^2 energy from it that way; yeah, let's do that! =)

</comment></comment><comment><USER34> While not an earth-shattering amount, I'd rather see such grants/cost sharing go to tech that doesn't perpetuate dependence on fossil fuels. In the end, this tech only means we get to burn less, but not eliminate the emissions all together.

<comment><USER35> Combustion engines are so fundamental, they go far beyond fossil fuels. They are one of the best ways of converting chemical energy to work. Fossil fuels just happen to be very high in chemical energy. You can burn hydrogen, ethanol, bio-diesel, paraffin, methanol....

IMO the better combustion engines become, the more options for fuel we have. For example, ethanol compares poorly to gasoline in power & consumption, but with continued engine development, ethanol will be able to develop as much power & economy as gasoline does today.

<comment><USER34> Not familiar with burning paraffin, but of others only hydrogen produces relatively safe emissions (water vapor), the rest produce the undesirable by products.

It would be better for smaller applications to move to electric and produce energy by other means. This requires investment into better batteries/storage applications. I'd rather all the money go to that instead of combustion research.

<comment><USER35> Battery-powered 737's eh? While it's a nice dream, electric motors are _way_ behind on power to weight ratio, thanks to batteries. We might get there someday, but we would need several stacking 10x improvements in battery tech, and who knows if they exist.

There are still a lot of places where very high power to weight ratio of combustion engines is extremely important.

<comment><USER34> How's 737 a small application?

I'm talking cars, bikes and the like...

EDIT: Also, a 737 does not use the type of engine described here, unless you want them to move back to prop design.

<comment><USER35> _shrug_ Jet engines count as combustion research

But my apologies, I did miss the "small application" part.

<comment><USER34> Sure, jets burn fuel, so in that they count. However, the article is talking about a very specific application with opposing pistons and compression-based ignition. This is similar to how a traditional diesel works.

It's definitely useful to burn less fuel, but still.</comment></comment></comment></comment></comment></comment></comment>