unsoundInput

I don't buy it.

At least two core products of the biggest advertisement company in the world have no problem providing you value and generating ad-revenue without you having to be logged in. Google and YouTube would be nowhere near the success they are if they'd force you to log in.

I'm wondering why they're getting more and more adamant that people register an account, even though a lot of people don't care about having an online persona outside of Facebook and wouldn't ever contribute anything to the platform.

I honestly believe that could do much better by providing a good experience to people that just want to stay up-to-date and follow a few people that they find interesting.

There are two valid ways for a disassembler mitigate this: a) decompile to a language in which the bytecode can be expressed (in a concise / expresive manner, Java would always be a "possible" target because of turing completeness) or b) accommodate for the fact that there could be signature collisions in java, e.g. by prefixing/suffixing the method name

Well, it's not a jvm class file but a dalvik Dex file. A disassembler which can't generate compilable code from this valid Bytecode is incomplete or in other words: buggy.

Even though I agree that >>insert method of std::map is roughly 7 times slower than it should be<< is bad, these kind of problems are not too hard to find and solve if they are actually problematic for your software.

The most problematic performance issues I've come across were usually bad/premature optimizations that were not (correctly) validated against a simpler implementation as a performance baseline. Things like parallelism (multi-threading, web workers) or caching can absolutely tank performance if not done correctly. Plus they usually tend to make stuff more complex and bug-prone.

Funny, I tend to go the opposite way (immutable value types, stateful-as-needed behavior classes). I wonder how you argue that you have less stateful objects considering data objects are usually instantiated more than logic objects?

IMHO you overestimate the use of macs as development machines, doubly so in parts of our industry that works on projects where high performance GPU APIs are actually needed (games, cad, simulations)

I can't find the okhttp case you reference, but retrofit has a bunch of extra adapter artifacts that add an external library as a transient dependency to your project.

The code for the binding classes lives in retrofit.adapter.{guava|rxjava|…} [0] but the respective library still lives in its usual package. [1]

If that weren't the case you could A) not manually provide a minor version via your dependencies block in your build script and B) would have interop problems between libraries and between a library and your code as the same interface copied to a different packages is not the same interface for Java.

[0] https://github.com/square/retrofit/tree/master/retrofit-adap...

[1] https://github.com/square/retrofit/blob/master/retrofit-adap...

I started using sqlbrite (in combination with sqldelight) and stopped treating the database as an object store. Instead I create an interface for the data the customer needs (e.g. an item interface for elements in a listview), write a select query whose result fulfills this interface, and let the rest happen via databinding. This seems to work fine up to a couple of thousand of elements for me.

That is actually not true. Afaik multiversioning of dependencies is not actually supported by build systems without manual effort (not counting major versions in non-conflicting namespaces). Problem is really more in fat libraries and "unnecessary" (getters, setters) and synthetic (e.g. access to private methods from inner classes) methods that are usually not optimized away, especially in debug builds.

I don't think so but I might also interpret the article wrong.

The problem - from what I understand - is that you used to be able to use the systems sqlite.so to access databases owned by your app from the native environment. With Android N you are no longer able to do this, you need to ship your own sqlite binary.

This can lead to problems when you want to access the same sqlite files from both the Android platform APIs and native (e.g. use it from native for business logic, debug it with a tool like Stetho [0] that uses android.database.sqlite) because of a version mismatch.

Would Google offer (a copy of) the Android API with the ability to plug in a different sqlite-compatible binaries, it would very likely find broad adoption. Then the problem stated by the article could be solved by shipping the app with a sqlite build that is used by both the native code and plugged into the compat library.

[0] https://facebook.github.io/stetho/

Kind of related: There is an outstanding request [0] on the Android issue tracker to offer an official support/compat library for Android's sqlite bindings, that would bridge Android's API (in a different java package) to a sqlite binary that you provide.

There are already implementations [1][2] of this, but because it is not provided by the Android team it is hardly supported by ORMs, libraries, etc.

[0] https://code.google.com/p/android/issues/detail?id=202658

[1] https://www.sqlite.org/android/doc/trunk/www/index.wiki

[2] https://github.com/requery/sqlite-android

I imagine that the industry is under comparatively little scrutiny by regulators and the public, and can therefore be as fast-moving and rule-bending[0] as the top SV startups. This combined with less (at least perceived) prudence in Europe might give them the edge over their competition.

[0] https://news.ycombinator.com/item?id=12855554

It is about treating new versions with major API breakage as if they were completely new libraries, not as a "maybe, possibly drop-in replacement, iff we use just the right feature subset". E.g. RxJava changed their maven artifact ('io.reactivex:rxjava:1.y.z' -> 'io.reactivex.rxjava2:rxjava:2.y.z') and the package name where in which their code lives ('rx' -> 'io.reactivex'). This makes it possible for both versions to be used at the same time while transitioning, without breaking dependencies that rely on the older version and without having to bother with automatic multi-versioning in buildtools.

With that in place it is questionable what the actual advantage of semver vs a simpler monotonous versioning schema (like build number or UTC date) is.

I think this talk makes his opinion on how breaking changes in libraries should be handled (in the context of the JVM ecosystem) very clear:

A) avoid breaking API changes

B) if you have to do large breaking API changes, that will probably affect alot of dependent projects, make it a new artifact / namespace / library that can live side-by-side with the old version

B is actually pretty common in large java library projects (rxjava -> rxjava 2, retrofit -> retrofit 2, dagger -> dagger ‡ all have independent maven artifacts and I think also packages) and imho this approach makes a lot of sense. It's also the more important part of this talk compared to his critique of semver.

I am very confused what kind of state management MobX implements, especially after reading their current README (https://github.com/mobxjs/mobx/tree/6ed404b96a8b4074a473accd...)

Is it Ember/Vue-style "mutate, observe, compute" as implied by most of their example code or Flux-style as implied by their introduction visualization (https://github.com/mobxjs/mobx/raw/6ed404b96a8b4074a473accd2...)? Do I create actions or just mutate state directly (again, visualization and some text in the readme vs examples)? How is "observer turns React (function) components into derivations of the data they render." any different from just plain React components?

MobX feels like someone tried to make an easy state management solution (obviously a great goal) and in the process just threw together whatever pattern exist out there right now. It obviously works for many people, considering how often someone comments about it on HN, but I wonder what makes those user stick with React vs a framework that completely embraces this approach like Vue or Ember.

Is it some hard requirement on React?(EDIT: Or maybe preference of JSX?)

Imperative (especially Java-style OO-imperative) programming will just about always win over non-OO declarative programming in an analogy like that (i.e. a Simulation of a real world process) by nature of them being focused on step-by-step "world manipulation" (and object interaction in case of OO).

The value for FP comes from proper abstraction over these processes in functional terms, at which point they can be trivially implemented (few bugs, few iteration cycles to get right). This can probably be done for every problem space, question is at which the abstraction costs outweight the gain. Considering that FP becomes more and more mainstream it's probably more viable than thought in the past, still I imagine system-driven games or complex real-world simulations, with lots of side effects, would lose more from FP than they'd gain.

I honestly don't see why you wouldn't consider SQLite to be a "proper database." I think it has a reasonably competitive feature set.

In a usecase where you consider independent databases, with few interactions between them, for millions of users (and a few MBs + binary blobs of data per user) I'd certainly consider it as a possible solution.

This obviously depends on the workload / amount of data per customer, but for some use-cases this could be done with SQLite.

EDIT: Well, looks like someone beat me to it

Fully agreed that there are limitations, but I still think calling it an out-dated approach is unfair.

I don't see a simple, low on boilerplate, one-size-fits-all solution for reusable and separated components on Android at the moment. I love that the community didn't settle with just Activities or just Fragments and is actively trying new stuff (after all, if you look at React or Vue or even freaking backbone.marionette, the web is in a much better spot right now regarding UI composition), but right now the right solutions always seems to take the path of least resistance and use whatever mix of pattern that gets you to your goal as easily as possible.

I disagree with you regarding Activities. For apps they do most of the screen management the developer needs just fine, especially if they are backed by a strong view and data model. If you download the App you can actually really quickly make out where they leverage the single Fragment (switch the project category via the drawer) and it makes sense there; but I think the same App build with a single Activity and Fragments would be much messier (especially regarding animations and back-navigation) and they'd gain (next to) nothing.

Kudos to them. Compared to the web it's rather cumbersome to poke into packaged and released mobile apps, so I really appreciate access to the source of a real world app for learning and comparison.

The Android codebase looks very modern and well structured. I think it makes great use of many of the goodies (gradle, rxjava, retrofit, dagger, android support lib, ...) and learnings (bring your own MV*; use Fragments when you need them, stick to Activities if you can) that is state of the art in Android development. I think it's a great thing to skim through if you are interested in developing for Android or to compare it to you own app.

I can only assume that the same is true for I iOS. I'll certainly check it out should I start developing for that platform.

What bothers me about this and other templating is that branching is so inconspicuous and therefore hides its complexity . Lets takes this extended example:

  <template>
  <div>
      <h2 class="c-section-heading">HELLO</h2>
      <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p>
      <p v-if="location.query.home">You specified a home query: {{location.query.home}}</p>
      <a v-else v-on:click="specifyHomeQuery" class="u-warn">No home query was specified</a>
  </div>
  </template>

And compare it to:

  <template>
  <div>
      <h2 class="c-section-heading">HELLO</h2>
      <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p>
      <p>You specified a home query: {{location.query.home}}</p>
      <a v-on:click="specifyHomeQuery" class="u-warn">No home query was specified</a>
  </div>
  </template>

The first one creates a div with 3 children with the type of the last one depending on the condition. The second one creates a div with 4 children (and a warning in the dev console). Both have 4 lines between the <div> with the same content except for two attributes on two elements and are indented the same by convention of the framework. They look nearly identical when quickly parsing over them but results are very different.

Compare this to the other react solutions, or my personal favorite:

  const Home = ({location}) => <div>
      <h2 className="c-section-heading">HELLO</h2>
      <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p>
      {location.query.home
    	  ? <p>You specified a home query: {location.query.home}</p>
          : <a onClick={specifyHomeQuery} className="u-warn">No home query was specified.</a>}
  </div>

I think it's pretty clear which "templating system" better represents the fact that this has more complexity than just a simple, linear component.

The input still needs to be cached for eventual output in case the hash matches I assume.

I don't think of something as React-like just because it puts HTML and JS in the same file or combines HTML tags with blocks of JS code.

The difference between React and other databinding methods is that you can use all JS language features (i.e. if, for, while, .filter(), .map(), libraries like Rx.js, etc.) when defining what you want your DOM to look like.

Suppose I want to have a list of items based on some array, which I want to filter based on some predicate, and display the items differently based on their content type.

In a React render() function I would just use

  filter( (it) => { //some predicate } ) 

to filter unwanted items, and

  map((it) => { switch (it.contentType) { // cases } }) 

to map the individual items to how I want them to look like.

To me it looks like to implement something like this in Riot would require to build / use something that is more like Angular's computed properties.

But I'd like to be proven wrong.

I agree that calling it "React-like" seems misleading. When I read about a 'x'-like library I expect something that could actually replace 'x' and provide nearly the same features.

Pete Hunt did a great talk on what actually makes React / virtualdom different from other databinding approaches.[1] Using this definition Riot.js looks a lot more like Angular, Ember et al. to me.

[1] https://www.youtube.com/watch?v=-DX3vJiqxm4