Ask HN: What happened to the ORM? - <AUTHOR> After all those years, I sometimes feel like the whole ORM thing hasn't made progress or been settled. Which ORMs do you like and what do you like about them? What is the sweet spot? I'm asking this because database I/O has always been my biggest frustration when doing application programming. These days, I do more functional programming and tend to side with the ORM haters but I do occasionally wish I could just abstract out the database more. Anyways, I'd just like to hear HN's thoughts on this. <comment><USER2> I'm the original author of Sequel [1], an ORM for Ruby. Lately I've been finding that ORM's actually get in the way of accomplishing stuff. I think there's a case to be made for less abstraction in programming in general, and access to data stores is a major part of that.

I believe in most cases the efficiencies that can be gained from using an ORM is quickly offset by a substantial dependency on third-party code, limited control of performance, and inability to express more complex SQL expressions, such as CTE's, lateral expressions, JSONB functions and operators etc.

ORM's also tend to pile on lots of functionality, of which most projects will normally only use a small fraction.

For an in-production system I've been maintaining for the last 10 years, I've recently ripped out the ORM code, replacing it with raw SQL queries, and a bit of DRY glue code. Results: less code, better performing queries, and less dependencies.

[1] [https://github.com/jeremyevans/sequel](https://github.com/jeremyevans/sequel)

<comment><USER3> > _I think there 's a case to be made for less abstraction in programming in > general, and access to data stores is a major part of that._

I'd like to hear more of your thoughts on that.

My experiences with ORMs are less about too much abstraction, and more about them encouraging _wrong_ abstractions. I'm yet to work with an ORM-using project that doesn't employ ORM objects as business model objects. The ones I've worked with always exploded due to the fact that even with ORM, database model doesn't map 1:1 to how the business logic would like to see the world - and the tension of trying to use one set of objects for both purposes at the same time is what messed up the codebase.

<comment><USER2> > I'd like to hear more of your thoughts on that.

These days it seems that even for the most rudimentary programming tasks everybody reaches straightaway for their favorite framework/lib without too much thinking.

I think in a way all these frameworks and libraries have had a negative impact on the general quality of coding. Programmers end up with limited knowledge of how the underlying technologies work: the HTTP protocol, SQL, the DOM...

And because these frameworks tend to grow over time, in an effort to be comprehensive and serve everyone's needs, they introduce more and more dependencies, more and more tooling, more and more code, which you'll need to get to know sooner or later.

Programmers who use said frameworks and libs become more and more "hooked", start using more features than actually needed (do you really need that auto generated REST API for that 3-page dry cleaning website?), and in the process become, well, dumber.

You can of course take this argument to absurdity by claiming that everybody should just write machine code. That's of course not what I mean. I just think that for many programming tasks, programmers would be better off - and no less productive - just by attacking the problem head on, with a good understanding of the technologies involved.

Sometimes a simple handsaw is more efficient and less hassle to use than that fancy sophisticated table saw you got in the corner.

</comment></comment></comment><comment><USER4> ORM's are good form, why?

\- Avoids mistakes when dealing with writing raw SQL queries (SQL is quite repetitive in practice)

\- The declarative nature of classes maps well to types and relationships

\- The declarative nature of classes maps out well to tables, even with polymorphism [1]

\- Keeping "Models" in an ORM often maps out well to migration utility (Alembic, Django Migrations)

\- Object-chaining map very well to queries

\- ORM objects can be reused and composed

\- They can abstract out intricacies across SQL dialects

\- They can potentially make it easier to migrate to different SQL servers if no specialized features were used

\- Can help avoid common security vulnerabilities like SQL injections

\- When something can't be expressed via ORM relationships, they tend to allow the dev to drop down to raw SQL. In the case of SQLAlchemy, there is a core query language [2], too.

\- In the case of Django, QuerySet is used as a standard throughout extensions that power a whole community. Plugins that don't even know each other (e.g. django-filter and django-tables2) can operate on the same django queryset to filter/search and sort/display data.

I mention QuerySet/Django ORM quite a bit in a recent blog post at [https://www.git-pull.com/code_explorer/django-vs-flask.html](https://www.git- pull.com/code_explorer/django-vs-flask.html).

[1] [http://docs.sqlalchemy.org/en/latest/orm/inheritance.html](http://docs.sqlalchemy.org/en/latest/orm/inheritance.html) [2] [http://docs.sqlalchemy.org/en/latest/core/](http://docs.sqlalchemy.org/en/latest/core/)

<comment><USER5> > Object-chaining map very well to queries

This isn't remotely true; it turns what looks like an in-memory access into a network round trip. Navigating your database using an idiom of lists and member accesses is a fast path to n+1 queries all over the place, or ORM tuned to eagerly fetch the whole world when you only touch a tiny piece of it.

The closer an ORM's API is to a monad, the happier you'll be. Fundamentally, accessing the database is executing remote code; the more you can package up into the query before it goes off and does anything, the better performance you'll see.

IMO trying to shoehorn objects (in the OO sense, with polymorphism, data hiding and behaviour) into a database is wrong-headed. Data hiding in particular is a wrong mental model for thinking about facts in the database, and the more is hidden, the harder it will be to reason about performance and bulk remote operations generally.

<comment><USER6> _> This isn't remotely true; it turns what looks like an in-memory access into a network round trip. Navigating your database using an idiom of lists and member accesses is a fast path to n+1 queries all over the place, or ORM tuned to eagerly fetch the whole world when you only touch a tiny piece of it._

That isn't true for e.g. Django's ORM, which lazily evaluates the query and only actually accesses the db after that, with a single query, and filtering done in SQL.

<comment><USER7> This is not the case - with Django's ORM you are still susceptible to the N+1 problem. It can be largely mitigated through `select_related` and `prefetch_related`, but the fundamental issue is there - that simply by accessing an attribute for an object that wasn't already fetched, you can do another database query without it being at all clear in the code that this will happen.

<comment><USER6> That's true, though select_related is mostly the default, and that behaviour is documented well. In practice, I very seldomly find N+1 cases with Djangos ORM, even when doing relatively complex data analysis.

</comment></comment></comment></comment></comment><comment><USER8> They're still alive and well, just not sexy anymore. The most popular one is probably still Hibernate which is helped by Java being the top high level language.

I never understood the ORM hate. Every place I worked we intermingled raw SQL when needed. Hibernate has a way to clear query caches so you can use raw SQL when you need to. You can just write raw SQL exclusively if you want within hibernate so I don't get how you could lose anything :) .

Still, my experience is mostly with Hibernate. It's extremely mature, meaning reliable, feature complete, and only 0-30% slower than raw queries in most cases. It makes adding support for things like multitenency and audited tables a breeze without losing database agnostic behavior. It makes database upgrades a no-brainer 95% of the time too. It has a built in memory caches that help enormously with common queries. Probably the biggest thing is it makes the database strongly typed so it's possible to refactor. Code refactoring in Java is easy but raw stringified SQL is nearly impossible to fix in any language.

I think the biggest counterpoint to ORM is shitty ORM. Things like SQLAlchemy generate downright horrific SQL slowing everything to a crawl and causing deadlocks. Another honest counterpoint to ORM is the learning curve. Everyone is taught SQL but the ORM is more abstract and harder to reason about, not a fun thing to learn.

TBH I think most ORM's are just poorly done. Putting an object abstraction on a relational database is hard. The only ones I've enjoyed for completeness and performance are Hibernate and to some extent Entity Framework. EF being the easiest to use but a bit slower with less features.

I have heard good things about Dapper but never used it. I like the idea of injecting a SQL DSL into the language itself, wish it was more prevalent.

<comment><USER9> >> Things like SQLAlchemy generate downright horrific SQL slowing everything to a crawl and causing deadlocks.

Not my experience... Would you care to explain ? SQLA works pretty well for me, as long as I stay in rather simple queries. For example, data analysis queries are next to impossible to express with SQLA, but that doesn't matter much.

For the simple update queries, it just works fine for me. It also allows for very good control on relationships, etc.

<comment><USER10> I've always had success with ORMs when I let them write the 95% of trivial queries (SELECT * FROM table, INSERT INTO table, UPDATE table SET ... WHERE id = x). The complex queries I'd always rather write by hand to take advantage of the expressiveness of SQL, and to make sure that queries hit my indexes correctly.

<comment><USER11> I totally agree. Mr. Fowler's article lays out a good case for ORMs being a good, leaky abstraction with manholes for diving deeper when necessary. That implies that we can't, as application developers, use it as a black box, because underlying knowledge is important. Until someone comes up with a magic algebra for paving over the details SQL, we're stuck mitigating or dealing with its realities.

One of the things I've recently prioritized is the ability to run arbitrary queries (generally read-only) at some sort of REPL prompt, for debugging and investigative purposes. ORMs and their offshoots offer a great deal of support in that area because you can converse with an ORM in a domain-specific way without dropping into raw SQL. That can be a big advantage.

</comment></comment></comment></comment><comment><USER12> It's now called GraphQL. Let me explain.

First, the need for data has moved from the server to the client side in API- centric architectures. The backend is often just a dumb HTTP layer on top of a (sometimes relational, sometimes not) data persistence. Heck, I even built apps without server, using PostgREST.

Second, on the client side, we don't need an object-oriented interface to the datastore, because JavaScript. But we do need a powerful declarative query builder, and static data types to build up on. GraphQL provides that.

Third, if the purpose of the ORM was ever to abstract the SQL dialect of the database, GraphQL has resolvers, which turn a GraphQL request into a request for the database of your choice. So it does that job, too.

Last, for the data crunching jobs that you decide to do on the backend, you often need specialized data stores (event store, document store, full-text search index), and ORMs don't address that. And since these jobs are often resource intensive, you need the best performance - therefore falling back to raw SQL in most cases.

ORMs were a good solution for the kind of software architectures that were used for the web in the 00s. Since then, we have different needs, which require different solutions.

Disclaimer: I was the maintainer of a popular open-source PHP ORM [1] for 3 years. I no longer use ORMs.

[1] [http://propelorm.org/](http://propelorm.org/)

<comment><USER13> What have you used PostgREST for?

<comment><USER12> Public and private web apps for a French media company. Dumb backend, most of the logic was in the frontend (React) and in async workers (Node.js, with direct access to the database without ORM).

<comment><USER14> Serious question, if you do most logic in the frontend then where do you do the server side input validation and where do you do the business logic? If I fumble around with your client side code and you don't check that then I could theoretically do whatever I want in your database.

</comment></comment></comment></comment><comment><USER15> What happened to the ORM?

To my opinion, it was a bad solution to the wrong problem.

For one, we're not that enamoured with objects anymore (what with functional programming, immutability, etc).

Second, SQL and DDL, being declarative, is both a higher abstraction that (at least) most ORMs, and offers more fine level control to the DB at the same time!

Third, people don't really switch databases that often, for the abstraction between different SQL syntaxes to matter.

<comment><USER16> > Third, people don't really switch databases that often, for the abstraction > between different SQL syntaxes to matter.

But third-party libraries shouldn't assume any specific SQL database, so if you want libraries that can do database things, ORMs are very useful.

<comment><USER3> They can always do SQL abstraction _without_ doing the object-relational mapping.

</comment></comment></comment><comment><USER17> An old article, but still somewhat relevant I think:

"ORM is the Vietnam of Computer Science" (2006)

[https://blog.codinghorror.com/object-relational-mapping- is-t...](https://blog.codinghorror.com/object-relational-mapping-is-the- vietnam-of-computer-science/)

</comment><comment><USER18> I thought we've been through :-)

"ORMs are a thing of the past" (2009) [http://codemonkeyism.com/orms/](http://codemonkeyism.com/orms/)

"Be careful with magical code" (2010) "[...] ORMs and in particular Hibernate [...]" [http://codemonkeyism.com/beware-magical- code/](http://codemonkeyism.com/beware-magical-code/)

</comment><comment><USER5> My experience is strongly flavoured by developing and optimizing on the edge of what the database is able to do; and my performance condition isn't scaling up millions of tiny trivial queries, but getting big hairy dynamically generated queries to execute efficiently within a deadline.

No ORM comes remotely close to being able to solve this kind of problem. The kinds of things I need to consider:

\- analyzing select / predicate / order / etc. for tables used and selectively including tables

\- forcing query evaluation order by creating a subtable query with conditions, projecting out an id, and rejoining in the next query up

\- analyzing predicates and rewriting predicate trees to push predicates down into subtable queries, or convert predicates into joins, or replace references to columns on other tables with denormalized columns

\- gathering heuristics about query set size and changing query generation technique

\- splitting queries into parallelizable queries and composing result set client-side

An ORM doesn't really help me. Even a library tuned for symbolic manipulation of SQL doesn't help hugely; my life is made much simpler when I can freely extend the SQL AST classes with my own analytic and rewrite methods.

<comment><USER19> Isn't this the type of thing that 'the' (or a) query optimiser is meant to do?

With a suitably tweaked ORM, you can pass platform-specific hints down to the DB. The platform's query optimiser should be (obviously up for debate!) the one that's taking a query and working out the most efficient way of executing it.

Not saying it always will always pick the best execution, but if you're getting to the point of supplanting the optimiser you're starting to replace the database itself.

At which point you're probably beyonds the realms of what an ORM can and should reasonably doing, you're starting to writing your own custom persistence platform.

<comment><USER5> No, query planners are generally hopeless; for my use cases, it's trivial to get orders of magnitude better performance with different query structures.

If you have just a predicate, or a single join, most query planners are just about ok; with multiple tables and predicates touching those tables, there's ever increasing risk it will start the join on the wrong table and produce too many rows somewhere in the plan. Engines like PostgreSQL are unpredictably stupid (but sometimes very smart), while MySQL is predictably stupid (but consistently fast when you keep it simple and avoid specific constructs).

When designing for interactive use, you want to design for a maximum run time on the query. If that means using a query which is often not the fastest, but is never slower than X, it's the query to use. Smart planners are more of a hindrance than a help, because they reduce predictability.

The worst case is when a planner starts with a small row set (planners usually like starting with small row sets) and joins against a big table expecting a similarly small joined set, but ends up with an enormous result set because of the cardinality of the join. Estimating join cardinality is a tough problem for database vendors to solve, and it's critical to figuring out the correct join order - particularly since the number of join strategies grows with the factorial of the number of tables to join, so the planner can't spend much time on it. Meanwhile, the application developer may very well know the designed cardinalities and a join sequence that minimizes the chance of a blowup, the most important thing for interactive use.

<comment><USER19> Well yes, this is exactly what a query optimiser is meant to do.

What you're meant to do is add a few indexes, maybe sprinkle some hints into your query (platform specific), based on your knowledge based on your rough knowledge of the statistics of your data structures and let the optimiser/planner work out the best way to execute it.

Now yes, the optimiser may sometimes get it hilariously wrong, but I guess that's the price you pay for a relatively portable (across DB platforms, with some tweaking of the hints) solution.

The risk of going too far down the rabbit hole of dynamically re-writing the SQL is that you're essentially trying to second-guess any query optimiser/planner and for most of people making software they're going to do a poor job building a 'shadow optimiser' based on 'experience' of a specific platform and how it behaves in observed scenarios. If the people building databases are finding it hard, there's probably a reasonably good reason.

I'd also note that this isn't really a problem with ORMs per-se, but with relational DB platforms and their performance when running arbitrarily complex SQL.

<comment><USER5> You can concretely measure how much time it takes to scan X million rows of a table; how much slower it is for every join you add; how much slower an index is to scan for every column that's added to it; how much slower it gets for every column you add to the select clause; etc. And determining optimal join order in my case isn't particularly hard (it's a lot like a star schema; the key thing is not to bring in the whole of the big table in the middle).

I was a compiler engineer in my previous job; transforming and optimizing expression trees are my bread and butter. I'd give myself good odds of improving MySQL for my particular use case - I'd know where to look, what stats to collect and how to approach things differently. But likely my optimizations would be pretty specific to my situation, and not everybody would be happy with more predictable, sometimes slower performance.

</comment></comment></comment></comment></comment><comment><USER20> They still have their uses, particularly with largish LOB/enterprise apps. For me they are no longer the goto solution for apps I write though, if I started building one today I would start with an "ORM lite" (never liked the term) like dapper. If it ever got big and complicated enough that an ORM was justified then I would introduce one.

I find an ORM really excels when you've got complicated business logic, the sort of thing where there are dozens of business rules that may or may not be involved in any given installation. Something like this is extremely stateful and and ORM does a great job of tracking this state. In fact, this is what I'd define an ORM as, a state tracker for database modifications. If you don't have much state then you probably won't get much out of an ORM.

Even when using an ORM does make sense, it's important to remember that they don't make sense everywhere. For a performance critical or particularly complicated query then SQL should still be a fallback.

</comment><comment><USER21> Not sure in other platforms, but in the .NET world, ORM(read Entity Framework) usage skyrocketed and improvements are made with each version of .NET released. I use Entity Framework. Both at work and when doing my home projects. Code First. I started with Database First and only recently moved to Code First. It feels so good modeling my database using C#.NET classes instead of doing it in SQL. Don't get me wrong. I do like SQL and I am very good with it, but I prefer C# better.

Speed of development greatly improved since I switched to EF. Speed of development is what matters most for me when building first version of an application.

</comment><comment><USER22> It could be that most haters are simply using the wrong one? If JPA was my sole experience with ORM I would side with the haters as well, fortunately I built enough successful projects using DBIx::Class and SQLAlchemy to understand the advantages of using an ORM to the point that I refuse working without one.

</comment><comment><USER23> I still use ActiveRecord a lot (Rails) and I would not write SQL queries manually since the ORM works so well. But I used ORMs in other languages and they were not as convenient so maybe it depends on the ORM itself. The time it saves compared to standard queries is massive.

ORM haters would likely point out that complicated queries are hard to write with an ORM but these complicated queries are not a massive part of the work and can still be abstracted away in a method using SQL if needed.

Another good point of the ORM: validation of data. There are plenty of validation you cannot enforce in SQL (regex, postcode...).

<comment><USER24> > Another good point of the ORM: validation of data. There are plenty of > validation you cannot enforce in SQL (regex, postcode...).

Those particular examples are trivial to enforce in every DBMS I am aware of...

<comment><USER25> Dbms constraints are a usually a subset of constraints that are supported by ORMs.

</comment></comment></comment><comment><USER26> The big question is when to use ORMs/raw SQL.

SQL is the most concise and perfect fit for RDBMS.

However, at the application level there are benefits of using ORM.

\- The application itself is usually imperative style as against the declarative nature of SQL.

\- Chaining is sometimes more readable and concise. One can chain dynamic filters.

\- Abstract the underlying data model with higher level names. SQL eq. of table views.

\- Hides the underlying relational model. Which can sometimes be helpful in a large code base. And sometimes a curse.

I normally opt for ORM in Rails/Django web apps. But SQL in

\- Performance critical \- Report generation, where it might be complex and declarative nature of SQL shines.

</comment><comment><USER27> I have the same opinion now that I did at the beginning. They provide a decent abstraction of the database. But that abstraction leaks.

Just a week ago, I ran into an issue where SQLAlchemy wouldn't support a "in" clause against a list of Model objects. There's a leak that I had to patch by using a list comprehension to generate a list of integer IDs from those objects.

Then I ran into a "you're doing a check against an empty list; we are pretty sure this will come back with no results, but we're going to run the query anyways." Another leak (and it's a valid one), but I have to manually work around it if I don't want that extra query run (I didn't).

Finally, we get the script to the point where it's passing all of the unit tests, and package it up for the integration tests. Those integration tests fail, because SQLAlchemy dynamically imports DB connecters based on the DB being used. The unit tests were running in SQLite in-memory DBs, the production Aurora, requiring a connector to be installed. Another leak.

Ultimately, ORMs can be useful, but they are an abstraction which leaks all over the place. So long as you're OK with the tradeoffs (the rest of my team was; I'm ambivalent, though I was the one who ended up fixing all of these leaks), they're another good tool for your programming toolkit.

</comment><comment><USER28> I think part of the reason they are not talked about anymore is that people like to talk about the hot and sexy and not the mature and incrementally improving. The hot and sexy now is full of Javascript and noSQL so ORMs aren't as relevant as before. ie: schemaless JSON + dynamic languages have eaten a big piece of the cake.

That said, people seem to still use ORMs in Ruby, Java, C#, etc. and frameworks look fairly mature.

</comment><comment><USER29> The point of an ORM is not to be some magic 1:1 powerhouse, but to make it easy to abstract your storage layer. If I had the time and resources, I would make storage plugins with testing interfaces and dependency injections that precisely match the query patterns of my application. ORMs are almost never an ideal fit but they give me that for free out of the box.

</comment><comment><USER30> I was part of the team that developed TopLink, later EclipseLink that became the reference implementation of JPA. After I left Oracle, almost all of the original 30+ Engineers/QA/Managers were moved to a different project. The git- repo is infrequently updated by only a few support Engineers. From my point- of-view this means that the de-facto Java ORM is Hibernate (even though we were first!). It is very mature, well-tested yet still getting some 'love' (c.f. recent changes for Java 8 streams).

Other posters have mentioned the 'Vietnam of CS' post from many years ago - the main message I would like to highlight is that ORM's are deceptive: it _appears easy_ to create one, but once you spend some time with how people actually use databases, the real-world starts to drag you down (the 'leaky abstraction' meme thrown around). An example of this is: how many ways are there to map a One-to-One relationship (hint: greater than 5)

<comment><USER30> Answer: nine ways to map 1:1

See slides 20, 21 and 22: [http://images.slideplayer.com/9/2645248/slides/slide_20.jpg](http://images.slideplayer.com/9/2645248/slides/slide_20.jpg)

</comment></comment><comment><USER31> I currently think ORMs might be an anti-pattern, but I'm interested in what other folks think. It's the same kind of anti-pattern that led us down the path of taking Object-Oriented Analysis and generating an entire stack using MDD.

The thing is, you should really only want your database to do a small number of things, and those things you should pay special attention to. You don't want a database that does everything and all runs on autopilot. Then who the heck is coding the system?

I think most any app has a reasonable number of features which map to an also- reasonable-number of function calls back to persistent storage. Identify those and make them first-class citizens in your coding. After all, aside from UI dazzle, that's where all the magic happens.

</comment><comment><USER32> Nothing happened. 99% of scenarios are a great fit for a _tool_ that maps and moves data from the object-oriented programming language to relational databases. They decrease errors, increase productivity, and for the most part well.

Most of the complaints seem to be from using exceptionally bad ORMs or using them in the 1% of scenarios where performance is critical or very complex queries must be produced.

There really needs to be less blind hate and more understanding of when and where tools should be used (as well as the general quality of the tool itself). That's one of the basic tenets of programming so it's rather unfortunate to see so many misguided arguments here.

</comment><comment><USER33> One of the issues is that programming languages are evolving so fast it is hard for ORM libraries to keep up.

A good ORM library needs to be well designed, battle tested and mature. Then it provides great benefits over writing just raw SQL. That takes years of development effort.

The problem is that with new languages (Node, Golang, Rust) there hasn't been enough time and effort put into ORM yet to produce something good enough to be usable.

When developing in Java or Python there are great, mature and battle tested ORMs I would use but with these new languages I had bad experience with ORMs as they still seem experimental and have issues therefor stick to raw SQL when working in newer languages.

</comment><comment><USER34> there's raw SQL, there are ORM and then there's the mid layer of DSL-ish query builders like sqlalchemy.core, which are amazing if you've ever been dissapointed by not being able to compose queries in a sane way in SQL.

<comment><USER35> SQL is getting better though, see

[http://modern-sql.com/blog/2017-06/whats-new-in-sql-2016](http://modern- sql.com/blog/2017-06/whats-new-in-sql-2016)

[http://modern-sql.com/use-case/literate-sql](http://modern-sql.com/use- case/literate-sql)

</comment></comment><comment><USER36> I come from a heavy C# background. I can say that MS has been revising their Entity Framework platform and it's a perfectly good ORM tool to use.

Being stubborn and old-school, I prefer the lower level roll your own approach for speed and efficiency. That said, if dealing with an enterprise application where ease of code mendability/adaptability is key, I'd happily go with something like Entity Framework.

It would be interesting to see if code generation tools have progressed in this domain at all. I remember several data layer class generators which although not exactly an ORM, could provide many of the same benefits.

</comment><comment><USER37> Using just SQL or using an ORM is not a binary choice (and I'm not talking about the ability to drop down to SQL in an ORM). There is a middle or third option: libraries that wrap SQL (with a thin or thick layer) and provide a somewhat higher level of abstraction. Often called Data Access Layers, or similar names. SQLAlchemy Core is one such, and the pyDAL of web2py is another [1].

[1] I had blogged briefly about pyDAL here: pyDAL, a pure Python Database Abstraction Layer:

[https://jugad2.blogspot.in/2014/12/pydal-pure-python- databas...](https://jugad2.blogspot.in/2014/12/pydal-pure-python-database- abstraction_30.html)

I'd worked as the team leader on one such database middleware product, written in C for Windows, some years ago. It was successful, and somewhat widely used in projects for clients at the company where we built it.

Such products can enable you to write less boilerplate SQL code, and also to work at a somewhat higher level of abstraction, thereby providing some productivity.

I agree with some of the other comments here, that 1) such abstractions can sometimes be leaky, and 2) SQL is not hard to learn (for the basics and a bit more - hell, it used to be considered bread-and-butter tech), but for some reason there seems to be an impression that it is tough, from the last few years - sometime after Web 2.0, maybe.

</comment><comment><USER38> I think the answer is to take a hybrid approach. Use an ORM where it makes sense. You shouldn't need to write SQL to do simple CRUD and elementary queries with a join or two. But when things get more complex, you should be able to easily drop to SQL, and have the results mapped back to an object. Perhaps also a DSL that allows you to write queries in code. I have yet to find an ORM that can elegantly accomplish this, although SQLAlchemy comes close.

</comment><comment><USER39> I never seen orm as abstracting database out. More like easier to maintain way to access it and have features like caching/consistency available without much work.

</comment><comment><USER40> Take a look at Ecto (kind-of-orm for elixir), didn't even hear about anything comparable for other languages (which is sad)

* No impicit N+1 and stuff like that (elixir is functional with immutable variables)

* Whole "orm" is really fast, thanks to macros (compile-time metaprogramming)

* Can express very complex queries, allowing raw sql then necessary

[https://hexdocs.pm/ecto/Ecto.html](https://hexdocs.pm/ecto/Ecto.html)

<comment><USER41> I agree, Ecto is a great.

Ive always appreciated ORMs, but disliked how people tend to forget about the database behind them.

Ecto gives you a lot of power and flexibility, and its very easy to remember there is SQL behind there.

Compose-able queries are awesome.

Schemaless queries are awesome.

Not tying your "model" or "context" directly to a table or letting it be a portion of a table is awesome.

Backing "validations" with database constraints is awesome.

That Ecto team kills it.

</comment></comment><comment><USER42> It depends a lot on the project. I think learning SQL and basic database theory are a strict requirement. ORMs are a great tools to help make life easier, but you'll need to reach in sometimes in order to fix performance bugs. I've learned to love both.

ActiveRecord is amazing. It makes it really easy to get stuff up and running, and it works for a wide range of problems. There's nothing better for typical CRUD operations, especially when you models map mostly 1-to-1 to your tables. You start to encounter problems later on as the application grows, especially when you have lots of associations, complicated queries, or your models grow too fat.

Maybe your problem isn't really with ORMs, but with MVC or whatever application architecture you're using. For example, Rails has been criticized because of its fat models and its overall "flavor" of MVC.

Trailblazer [0] was created by a Rails critic as an alternative approach for structuring your web application. I won't go into the details, since the website already does a good job explaining. But he effectively kills the traditional model and shifts the persistence layer around, which is a fairly common pattern.

I remember reading book that discussed ASP.NET's approach to MVC. I don't quite remember all the details, but it mostly amounted to having four primary layers (presentation, application, domain, infrastructure) which were further divided and given specific responsibilities. This approach is overly verbose and complicated for some cases, but the abstractions appear to make more sense as the application increases in complexity. A small example is an application in which you have to break up a model's data between multiple storage services like Redis and the RDBMS.

You'll probably like Ecto [1]. It's an ORM for Elixir. After the 2.0 rewrite it's a lightweight embodiment of some of the concepts mentioned above. One of the key insights is that you'll want to separate business logic from data and presentation. But it really depends on the project! It might help or it might just add more boilerplate.

[0] [http://trailblazer.to](http://trailblazer.to)

[1] [https://hexdocs.pm/ecto/getting- started.html](https://hexdocs.pm/ecto/getting-started.html)

</comment><comment><USER43> I never understood the ORM hate/bashing. It's like the framework fanboy paradigm. "I love framework X, and framework Y sucks!"

They are tools built to help solve a particular problem.

ORMs are great when dealing with CRUD operations on entities and remove the need to write tedious boilerplate code every time. On the other hand, ORMs can be misused and cause all kinds of performance related problems. Most obvious use-case is developers that don't have much experience with databases, and instead of choosing to perform processing of data in the database run-time, they fetch data through the ORM and write poor performing code riddled with business rules in the application layer.

I think it's good to take a step back and understand that the ORM is a tool, which when used for the purpose it was designed for, works well.

Complex joins and queries can still take advantage of an ORM. One example is using materialized or non-materialized views, which can then map to an Object using the ORM to query it.

That way the bulk of the processing is done in the database runtime, and simply accessing the object is done through the ORM.

There's also the separation of concerns. A seasoned developer will opt for creating a well defined schema, and baking business rules into the database layer, because he knows that a well designed, and highly normalized data model will outlive any application where the business rules are housed in the application layer.

All things considered, I do love the ActiveRecord ORM design-pattern. I've worked with hibernate, JPA, and some other ones in the past, but ActiveRecord as employed by Rails and Django, is still my favorite.

</comment><comment><USER44> Nothing. They're just as bad an idea today. I think perhaps that message had begun to sink in.

Developers have this unreasonable fear of the SQL language, and I can't really understand why. Sure, it's different. But then so is CoffeeScript and everybody seemed fine learning to draw little arrows in their code for the six weeks that was popular.

For me, SQL is the perfect language for describing and working with databases. "Computer, give me a list of Students who are taking Algebra 101". But developers really seem to prefer taking that whole Student list and spinning through it themselves, looking up every class everybody is taking and building their own list thank you very much.

And instead of using a simple, concise way of defining data tables (that follows that same elegant data retreival and manipulation language), devs would much prefer something with angle brackets.

So they never bother learning the easy way of doing things and spend several years inventing something more complex and opaque.

Eventually, I guess enough people got fed up of dealing with the silliness and picked up a book on SQL.

<comment><USER45> I'm not sure which ORMs you worked with (any?), but that's not how they work. You don't pull the whole table to filter it in your code. Any non-toy ORM is perfectly capable of filtering on a known attribute or relation of a class on the db side.

There's some irony in the fact you're making fun of devs who don't want to learn SQL, while you don't understand ORM...

</comment></comment><comment><USER46> SqlAlchemy and the Django ORM are good - recently worked on a C# project and the devs are very anti-orm.

I think, the REPL makes a huge difference.

In a python project, getting a shell at any point - or experimenting in the shell Jupyter is really straightforward.

The brackety languages have options for this sort of thing now, but it is still just a lot more hassle - the easiest way to get something similar is to just write SQL.

</comment><comment><USER47> ORM gets in the way of programming.

ORM abstracts which something developers know as his/her fundamentals : SQL statements. For simple operations this abstraction doesn't hurt. But this abstraction becomes obfuscation when we write complex queries or statements.

First a developer has to figure out complex SQL query to solve a business problem. Then has to figure ORM equivalent to it. Then ,ofcourse one should, write original SQL query in comment section above ORM API query to help figure whilst debugging.

Once into debugging, if original SQL query is missing in comment section or hasn't been updated. Spend extra time on what is wrong with both queries. Which one is right/wrong and then how to solve the problem.

Although, I do see some value in ORM in migrating to another DB or abstracted objects of tables-and-properties.

But for simple reason of learning additional set of apis to run SQL statements hurts!

</comment><comment><USER16> We write science and GIS related interactive web applications. All our backends are Django because every application has some CRUD components somewhere and in general Python and Django have fantastic libraries available.

The Django ORM just works, I love it, it's never in our way and does what we need.

</comment><comment><USER48> Nowadays I'd say there's something better than ORMs, take Slick (Scala) for instance, it's an FRM (Functional Relational Mapping) or JOOQ (Java). Both of those provide pretty much 1:1 DSL to SQL while at the same time granting a lot of flexibility and type safety.

</comment><comment><USER49> ORM is a leaky abstraction. It does provide benefits, like avoiding SQL injection, however, it still don't have the level of flexibility as SQL, and probably will never do.

It is still useful though, but hardly stands on its own term.

</comment><comment><USER50> In Node, I consistently reach for Knex, which is less of an ORM (like Bookshelf) and more like a query builder.

This simplifies binding, mapping, and most queries.

There have been rare situations to use ".raw", but the escape hatch id there.

</comment><comment><USER51> I made my own ORM: [https://code.google.com/archive/p/memory/](https://code.google.com/archive/p/memory/)

It had a pretty nifty graphical editor: [http://rupy.se/logic.jar](http://rupy.se/logic.jar)

But now since I need a distributed database I built my own async-to-async HTTP/JSON thing: [https://github.com/tinspin/rupy/wiki/Storage](https://github.com/tinspin/rupy/wiki/Storage)

</comment><comment><USER52> I've used several. Liked some, hated some. My favorite is SQAlchemy, can't say I have any real complaints about it.

The few times I've had to strain the object model, SQAlchemy has degraded nicely and lets me use raw SQL. It's a great compromise.

I feel like, just like using an ORM can turn into an "all-solving" hammer, so can functional programming. If a project one's working on feels like it would benefit from being represented as mapped objects, maybe one should... Do that.

Then again, I don't have much experience nor interest in FP. Haven't needed it, I guess.

</comment><comment><USER53> There are ORM's in functional languages too, but they too have problems. Mainly the problems arises from SQL being structurally typed, meaning you can JOIN totally unrelated tables as long as they have columns with same types.

Practically there are no programming languages that allow to do all set operations on properties of records. Though Elm comes close. If the language has this peculiar feature, it should be possible to write a "ORM" that just works for all queries (given that the language has similar flexibility).

</comment><comment><USER54> I mostly use this now: [https://pandas.pydata.org/pandas- docs/stable/generated/panda...](https://pandas.pydata.org/pandas- docs/stable/generated/pandas.read_sql_query.html)

Which is basically an easy to use API that turns a SQL query into an efficient columnar table in memory.

Yes, this still requires writing actual SQL. And yes it does not help you insert or update data. But for 95% of uses it works well.

</comment><comment><USER55> Django user here. I feel like it got settled a while ago.

I think that probably encapsulates the whole issue here. ORM isn't one thing, it's a whole range of implementations and use-cases. For the sorts of annotations and reports I need to generate, Django has really started to come into its own in the past couple of years. Well on top of schema migration, caching and things like that.

So I wouldn't go looking for one answer. It's always going to be contextual.

</comment><comment><USER56> I work someplace where the primary db schema is very poorly structured, and the one attempt we (or rather a single dev that was under-supervised) made to use an ORM was disastrous - a single http request would generate literally hundreds of queries. I don't know whether the problem was the dev himself or the ORM or the db, but either way we're having to replace everything and I've been put off ORMs for a very long time to come

</comment><comment><USER57> I used to use an ORM but I discovered in fact that SQL gives me precision, control and performance and indeed I like it. I'll never go back to the ORM.

</comment><comment><USER58> _I sometimes feel like the whole ORM thing hasn 't made progress or been settled._

The object and relation impedance mismatch is not a new concept. The feeling of progress in ORM was just the act of bringing ORMs to ecosystems that hadn't had good libraries for it, introducing ORM to a generation of developres that had never used it, and improving the libraries.

</comment><comment><USER59> _Which ORMs do you like and what do you like about them? What is the sweet spot?_

I've worked with and liked

\- JPA, mostly Hibernate (although we were mostly sticking to the standard parts)

\- a few months of Entity Framework which was one of my favourite parts of my .Net experience (2.place I think after Asp.Net MVC which I really liked.)

\- SQLAlchemy (a few years ago) at least I think I liked it.

</comment><comment> ux-app ORMs aren't very good. They make simple things slightly simpler and get in the way the rest of the time.

</comment><comment><USER60> The problem with ORM? I always forget DQL "like" syntaxes while I never forget raw SQL.

</comment><comment><USER61> There are a number of things you can do to improve performance of queries generated by ORMs.

* Make sure you are indexing properly

* limit the number of items returned by introducing paging

* use lazy loading where applicable

I'm sure there are other techniques, but these are my gotos.

</comment><comment><USER62> What I see are often custom ORMs implemented for a specific library or purpose. Many of the APIs I work with daily are in fact a type of ORM.

That said, I never use an ORM myself unless it's one I implemented as stated above.

</comment><comment><USER63> My point against ORM are that will always, no matter what you try, will limit your domain logic. But it will help you to get things done. What I'm doing is use ORM only as a mapping for database layer.

</comment><comment><USER64> It is a good tool, people use it, however it turns out it was not a silver bullet (tm). I think it is pretty much settled for what things it makes sense or not.

</comment><comment><USER65> I'm still using Linq-to-SQL in the .net world. For 99% of what I need it to do, it works golden. Once in a while I've got to go in and profile and rewrite a query when somebody that doesn't know what they are doing has introduced an n+1 query, or done something overly "clever" that's resulted in gnarly SQL being generated.

</comment><comment><USER66> What's wrong with ORMs? I tend to use Dapper. I've found that it can solve most of my problems, and it's easy to drop back to raw SQL as needed for the last 5% that need finer control. It's also super easy to extend and customize based on my requirements, and it's almost as fast as raw SQL.</comment>


Ask HN: Feedback on Genie Timeline 2.0 Please - <AUTHOR> http://neosmart.net/blog/2010/genie-timeline-2-0-quality-free-backup-for-all/

<comment><AUTHOR> Genie-Soft - a Jordan-based startup I'm currently working with - has just released Genie Timeline 2.0 Free, which is a comprehensive backup solution for Windows.

I'm not sure if anyone else has had a similar experience, but before working with Genie, I could never find a free backup product that didn't suck to recommend for family and friends that don't realize the value of backups enough to shell out for a backup program.

I'm really excited about GTL2 because it takes many queues from version control systems. It actually monitors your system for changes to protected data in realtime, and queues the files for backup. The nice thing about it is, you just configure it and forget it, it'll perform automated near-realtime backups on its own. You only use it when you need it: to revert changes and undelete files.

Anyway, I'd really appreciate any feedback you guys can give on the product. There's a lot going on behind the ostensibly simple UI, and sometimes focusing too hard on the core means missing out on the big picture. Any feedback/critique fellow HNers can give would be very much appreciated!

I know giving feedback on a software product is a lot more involved than doing so for a webappp, but it's very much appreciated.</comment>


How to generate a double-precision floating-point number in [0, 1] uniformly - <AUTHOR> http://mumble.net/~campbell/2014/04/28/uniform-random-float? <comment><USER2> If you can live with [0, 1), there are simpler ways of doing this. Generate a number [1,2) by filling the 52-bit fractional component with a random integer. Then subtract 1. And you're done.

[http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/ARTICLES/dSF...](http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/ARTICLES/dSFMT.pdf)

<comment><USER3> Well, technically the probability of getting exactly 1 should be 0. Thanks to rounding, it isn't literally a 0 probability, but for any practical purposes the open and closed sets should be equivalent.

<comment><USER4> No. No no. No no no! Stop that. Stop that right now. You are a bad person and should feel bad.

I've dealt with more than a few crashes that came from open vs closed set differences. Yeah, the odds of it happening on a given roll of the dice is low. About one in 8 million for a 32-bit float. But if you have 100,000 users and they each roll that dice even a single time per use of your application then it soon becomes less about the odds of it happening and more about how many times it happens per day. And if it happening can cause a crash, well you're gonna have a bad time. And since you're dealing with floating point numbers they're interacting with gods know what so all it takes to cause a crash is "oh this operation can never result in a divide by zero because this other value can never be _exactly_ one". Oops.

<comment><USER5> Heh. You're very right about the generation of 1. Even 2^54ish is not rare enough to ignore. Put it in GPU code and you could find it breaking in seconds.

But would you be comfortable ignoring double precision 0, with a proper algorithm that makes the probability somewhere around 2^-1070 or 2^-1020?

<comment><USER4> I'd always prefer an algorithm to be correct 100% of the time than any rate than 100%. This is the type of thing for which there is no fundamental reason why you can't simply do it right. The more things you can do right the less you have to worry about! It's much simpler.

That said, I'd certainly listen to the tradeoffs of being correct 100% of the time vs being wrong a mere 1 in 2^1020 times. I wonder if 2^-1020 is greater than or less than the chance of a cosmic ray flipping a bit...

<comment><USER5> It's far far far smaller of a chance than a memory error. Unimaginably smaller.

Now that I think about it, smaller enough that the execution time difference makes it more dangerous to check. :)

<comment><USER4> Since I was curious, it appears that IBM did research in the 90s and came up with 1 per 256mb RAM per month. That's 3.7 × 10-9 per byte per month or 1.4 × 10-15 per byte per second.

[http://stackoverflow.com/questions/2580933/cosmic-rays- what-...](http://stackoverflow.com/questions/2580933/cosmic-rays-what-is-the- probability-they-will-affect-a-program)

<comment><USER6> The surface area of 256MB of ram has shrunk a lot since then.

<comment><USER5> Though the bits have gotten more fragile.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> I appreciate the effort to write this up, but I'm not seeing that this has applicability to any real problem. If you put 53 random bits in the mantissa with a fixed exponent, you get a smooth distribution from from [0, 1 - 2^-53] in increments of 2^-53. He seems to be concerned that you will never get a number between(0, 2^-53). True, but you'll also never get any other number between (n * 2^-53,(n+1) * 2^-53) for all the rest of the range.

[wrong statement about denormals deleted]

His talk about "dividing" to produce the desired range seems misguided. Floating point division is ~10x the cost of any other floating point operations. If you are trying to produce precise floating point numbers, you almost certainly want to be working at the level of bits rather than hoping that division will do the work for you.

<comment><USER8> Numbers less than 2^-53 aren't denormals. Denormals occur when the exponent is all zeros, i.e. less than 2^-1022, the floating point representation of a double (ignoring sign) is normally:

      1.mantissa * 2^(exponent - 1023)

A denormal occurs when the exponent is all zeros, and the representation switches to

      0.mantissa * 2^(1 - 1023)

<comment><USER7> You are completely right, and I just got lost. I deleted my nonsense above. Is there more to the main article that I'm missing too?

</comment></comment></comment><comment><USER5> First off this seems like unordered notes and I spent 15 minutes trying to figure out what the actual requirements were, because it was saying things it needed and then talking about solutions that didn't have those features.

Anyway, the main goal seems to be even density of chosen numbers, while also not skipping floats. In other words the probability of any specific float being chosen is proportional to its width.

This is easy to do, and needs no rounding. At least for [0,1)

Observe that floats [.5,1) are half the probability space. Use one random bit to choose between them and smaller values.

Then floats [.25,5) are half the space. Use another random bit.

Once you've chosen the exponent, fill in the mantissa with 52 random bits. All floats in the range are the same distance apart, so random bits work fine.

      mantissa := random(2^52)
      exponent := -1
      while random(2) == 1:
        exponent -= 1
      return (1 + mantissa/2^52) * 2^exponent

If you _really_ want [0,1], then you must first define how wide of a range of real numbers you want to assign to "1". Rounding toward zero makes more sense. Alternatively, note how nonzero double precision floats go down below 2^-1000. You will never ever actually generate a zero, no matter what you do. Why should "1" be more likely than "0"?

But if you insist on rounding to nearest then you can put in a special clause where a mantissa of 0 has a 50% chance of being treated as 2^52.

<comment><USER9> If you really want [0,1], it might be more simple to include a check at the start:

        if (1-in-number-of-floats-in-[0,1)) return 1;

Your version of 50/50 split with the mantissa will mean that 0 and 1 will be less often chosen than others.

However, your version won't generate a (quite) uniform distribution anyways, due to subnormals. I _think_ a simple fix for that would be to, if your exponent reaches the subnormals, just return a random mantissa with the subnormal exponent.

<comment><USER5> I suppose my version might be wrong when it hits a denormal. It would depend on the rounding mode. Also it would never actually get to a denormal.

But you're right that to be obviously correct it should stop when it reaches denormals.

>Your version of 50/50 split with the mantissa will mean that 0 and 1 will be less often chosen than others.

That's intentional, because rounding a real number to the nearest float has the same behavior. The spec is wrong, I advise against following the spec, but that is how you do it.

</comment></comment></comment><comment><USER10> I like the idea of an random number generator that exploits the full precision of the floats. However, the issue with the naive method is loss of accuracy, not bias. When the article states

 _If k is 64, a natural choice for the source of bits, then because the set {0, 1, ..., 2^53 - 1} is represented exactly, whereas many subsets of {2^53, 2^53 + 1, ..., 2^64 - 1} are rounded to common floating-point numbers, outputs in [0, 2^-11) are underrepresented._

this is very misleading, because the points that are "underrepresented" are closer together. The discrete probability density created by the naive method is a perfectly good approximation to the uniform distribution.

Furthermore, although as the article shows, we can do better, this can, and must, come at a cost. Since the small numbers occur with much lower probability, the only way to generate them (without importance sampling) is by generating much more randomness (1088 bits in the article). Generating random bits is expensive, and this uses 17 times more randomness than the naive method.

EDIT: it would be possible to avoid generating all the extra bits in most cases, and so an efficient average time algorithm should be possible, but the worst case still requires 1088 bits to be generated.

</comment><comment><USER11> For [0, 1), would the naive approach of generating a string of, say, 16 digits, sticking a "0." in front of it and calling strod / atof yield similarly uniform results?

</comment><comment><USER12> Wouldn't the best (and coincidentally simplest) way be to synthesize the double-precision word by combining a random integer exponent, a random integer mantissa, and a random sign bit? You'd need to account for the logarithmic distribution of the exponent, but that seems like the biggest complication.

I don't understand the debate about rounding. What does it mean to round a random number? If the rounding process is biased, the number will be less random as a result, so you shouldn't have rounded it. If the process isn't biased, the number will be no more or less randomly-distributed than it was before, so there was no point in rounding it.

<comment><USER13> The clue's here:

> What is the `uniform' distribution we want, anyway? It is obviously not the > uniform discrete distribution on the finite set of floating-point numbers in > [0, 1] -- that would be silly. For our `uniform' distribution, we would like > to imagine[*] drawing a real number in [0, 1] uniformly at random, and then > choosing the nearest floating-point number to it.

Because of the logarithmic representation, there are as many floating point numbers between .25 and .5 as there are between .5 and 1. If you uniformly sample numbers with an exact, finite floating point representation then you don't get something that 'looks like' a uniform distribution of real numbers in [0, 1] -- which is more likely what was wanted.

<comment><USER12> Right, which is why I said you'd have to account for the log bias when you pick a random integer exponent. Otherwise most of your results would be really tiny.

The method bhickey suggests above sounds like a nifty workaround for the problem as well.

<comment><USER13> You're right, sorry. I responded to 'why round?' but missed that comment.

</comment></comment></comment></comment><comment><USER14> I'm sure that there are valid reasons to want to do this, but if your find yourself needing to do this, I think you should at least _consider_ whether there might be some other way to get what you want.

</comment><comment><USER15> Using a computer algorithm, [http://en.wikipedia.org/wiki/Mersenne_twister](http://en.wikipedia.org/wiki/Mersenne_twister) is a good choice.

"Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin." \-- Von Neumann.

Using a computer, maybe look for small current variations around a resistor or similar device? [http://en.wikipedia.org/wiki/Hardware_random_number_generato...](http://en.wikipedia.org/wiki/Hardware_random_number_generator)

<comment><USER16> The problems in the article have nothing to do with the source; it assumes that a source of randomness already exists. Mersenne Twister provides you with some random numbers (generally sequences of random, uniformly distributed, 32 bit integers). It does not solve the problem of picking a random double between 0 and 1.</comment></comment>


Ask HN: What journals or magazines do you read to learn about new developments? - <AUTHOR>

<comment> andrew-lucker This should depend on your field, because some are more gated than others. If you are lucky enough to pick an open one, then you can find good work published and available online.

In my case, I work in an open field. To find new work I simply identify thought leaders and start following their careers. Work happens pretty slowly, so checking in once or twice a year is usually enough to see whats happening and what is in the works.</comment>


Show HN: Countdownto.xyz – Make a minimalist countdown to any event - <AUTHOR> https://countdownto.xyz <comment><USER2> human redable urls have already been mentioned, to make them more readable and so I can type them from memory to check how much time is left until the event

also making them embeddable on other websites

I've thought about building a website with a bunch of these simple webelements before

</comment><comment><USER3> Looks nice. I would have expected the URLs to be more human-readable (SEO friendly? :) )

<comment><AUTHOR> Yes, good idea. Thanks!

</comment></comment><comment><USER4> Useful tool, liked.</comment>


Google Voice Alternative Line2 Is Now Live On The App Store  - <AUTHOR> http://www.techcrunch.com/2009/09/02/google-voice-alternative-line2-is-now-live-on-the-app-store/ <comment><USER2> The article seems to downplay the lack of SMS and the fact that Line2 provides a distinctly new feature set that Apple may have no intention to provide. Instead they stick with the very media friendly overly simplistic story of "Apple is scared of Google". SMS is a huge moneymaker for ATT and shouldn't be ignored as potentially the primary reason for Google Voice being rejected.

<comment><USER3> What new distinct feature set? All I saw in the article was "Line2/Toktumi is business-class Google Voice minus SMS." The only feature GV doesn't have that was mentioned was the ability to build a phone directory menu - which I would expect from a "business-class Google Voice".

Also, both ATT and Apple swore (cross their heart, hope to die) to the FCC that it was 100% Apple, 0% ATT in the GV decisions.

Oh, and there are other apps in the store that provide free SMS, so it's not like Apple's all gung-ho about blocking the SMS leechers.</comment></comment>


Crowdfunding video games - <AUTHOR> http://www.economist.com/node/21562213

<comment><USER2> _Not all are successful, and some observers worry about what might happen when a fan-funded game flops._

This is the great thing about crowdsourcing - if the game sucks, you've probably invested less into the game than if you had bought one you were less interested in. So when the invevitable flop happens, most of the contributors are just going to shrug their shoulders over their $8-$15 and move on to another game.</comment>


Suggestions for Tech Documentaries? - <AUTHOR>

Hoping something along the lines of ...<p>* Pirates of the Silicon Valley<p>* Triumph of the Nerds<p>* Download: True Story of the Internet <comment><USER2> The Code <http://www.imdb.com/title/tt0315417/> interesting even if you're not a Linux person.</comment>


Python Visual Tutorial - <AUTHOR> http://people.csail.mit.edu/pgbovine/python/ <comment><USER2> To my surprise, a lot of people don't know there exist things called debuggers. Debuggers are tools that let you step through code, see variables, set break points. Debuggers are common for compiled languages, less common for scripting languages. For example, you can debug Java code from most IDEs, or C++/C# code from Xcode or Visual Studio.

<http://en.wikipedia.org/wiki/Debugger>

<comment><USER3> hi (i'm the guy who created this app) ... the purpose of this app is to be an educational tool (e.g., visualizing how data structures change over time), so it's not really filling the same role as a symbolic debugger.

<comment><USER4> when I first saw this, I was thinking to myself "great, someone threw PDB into a web app" and was going to write it off until I saw that on every step of the way, you actually also visually output the contents of all the variables. In PDB, you have to manually know what's there and explicitly type in the command to inspect it. People learning how to program don't know where all the knobs are, much less which one to push.

There's power to such simplicity, and I immediately forwarded it to people I know are new learning programming in Python right now. Good stuff, keep it up!

<comment><USER5> pylons web framework has something akin to PDB in a web app

</comment></comment></comment></comment><comment><USER3> hi (i'm the guy who created this app) ... if anyone finds security vulnerabilities, please email me (and don't rm -rf my account hehe). i put this up a few months ago as a small hack to teach people Python, so it wasn't meant to be pounded by 1337 h4x0rz. thanks!

<comment><USER6> I KNEW that nick looked familiar. Though this probably isn't the place for it, I felt the need to tell you that your "Advice for Grad School Applications" essay was my bible for apps last December. I just moved to palo alto and will buy you a beer any time you want.

<comment><USER3> cool, thanks. please email me personally (i can't find your email addr from your HN profile)

</comment></comment></comment><comment><USER3> One of my goals is to use this app as the foundation for some free online introductory programming tutorials. Unfortunately, I don't have much free time right now to pursue this goal; but if you're interested in getting involved, please email me!

<comment><USER4> I might be interested, do you plan on open sourcing this ?

</comment></comment><comment><USER7> The idea of a code stepper is pretty cool. Two other projects that come to mind after seeing this: <http://jonnytran.com/machina/> and the Macro Stepper in Racket: <http://docs.racket-lang.org/macro-debugger/index.html>

</comment><comment><USER8> I'm teaching someone Python on the side, and this is a great help! Thanks!

<comment><USER9> I'm thinking about how this would change my niece's learning path.

Obviously it would omit things like argv, files, the os module. I've seen working with IO to be extremely valuable. She was able to quickly write fill in the blank form letters and simple interactive scripts. But there is plenty one can do with just print and loops.

Unfortunately I see that raw_input(), dir(), and __builtin__ all raise problems. My niece was extremely excited to find out about all the 'hidden' objects that she could play with.

<comment><USER3> sorry, those modules were omitted due to obvious security concerns ;) raw_input() sounds like something reasonable to include, though, since it could simply pop up a text box and ask the user to input a string. please email me if you have other suggestions for how to improve this app. thanks!

<comment><USER9> I support your idea of supporting raw_input through a pop up. You may run into problems with the browser supporting them. For one thing it will not be the result of a user action. If it isn't an acceptable experience, perhaps a dynamic inline form in the "output"?

<comment><USER10> A full HTML popup window shouldn't be necessary:

        javascript:alert("hello, " + prompt("what is your name?"))</comment></comment></comment></comment></comment>


More billionaires pledge to give half of their wealth away - <AUTHOR> http://www.guardian.co.uk/world/2010/dec/09/billionaires-giving-pledge-wealth

<comment><USER2> I hope not just billionaires but multi-millionaires will pledge as well.

<comment><AUTHOR> Yeah even i hope so!!! There are a lot of people out there who are desperately trying to live properly, so i guess the multi-millionaires will come as well, seeing their billionaire superiors!!!</comment></comment>


Report: Google suppressed an explosive memo about its Chinese search engine - <AUTHOR> https://www.cnet.com/news/report-google-suppressed-an-explosive-memo-about-its-chinese-search-engine/ <comment><USER2> It's probably safe to assume this is already being used on Americans and they're just trying to edit it to abide by Chinese laws & regulations for another massive tracking & censorship market.</comment>


Ask HN: Do you drunk code? - <AUTHOR>

Can you write code while drunk? Do you have a drink  or two while coding or looking over code or doing research at the end of the night?<p>Know anyone who does? <comment><USER2> I have read that sleep deprivation is as bad as getting drunk in terms of the number of IQ points' hit taken, so I would argue that many folks in the industry are effectively coding drunk :-)

</comment><comment><USER3> I don't enjoy solitary activities when I drink so no. That being said, I do comment on HN under the influence sometimes.

</comment><comment><USER4> I drunk code often enough. One thing I've learned is to make a backup of whatever I'm working on and put it somewhere out of easy reach (be it on a remote server, or a flash drive that is removed from the machine.) You will inevitably break something, but I typically come up with more gold than overall damage.

</comment><comment><USER5> it depends, for some critical line of code you can't make mistakes (for example if you are writing something involved with security , or in some worse case if you are programming an airplane consolle). So my point is: you can be drunk while coding but you have to be 100% sober while planning your tests for that code. Accordingly to a lot of studies alchool (also drugs) helps our brain to "think different" so while you are drunk you could find a solution for a problem you were stuck in just because while you are drunk your brain discovers different patterns. However i don't have much experience about this ... i've coded something while i was mildly drunk and i saw no difference.

</comment><comment><USER6> I am part of the Friday Club at work, basically we have about 3/4 pints every Friday lunch time. My output on a Friday afternoon is close to zero, I cannot concentrate and really don't recommend it!

</comment><comment><USER7> This question comes up every 3 weeks periodically. What a bunch of alcoholics!

</comment><comment><USER8> There are a lot of fun things you could do drunk. Coding is not one of them.

</comment><comment><USER9> I had a co-worker who coded his own CMS for a relatively successful web agency (it was the pre-wordpress era). And he coded part of this CMS on paper at a party. Must have been one crazy party :)

</comment><comment><USER10> Part of why I quit drinking is so I have more time to study programming effectively. There's no way I can do that buzzed.

</comment><comment><USER11> For me, coding is more fun getting in the zone, doing it for a few hours at a time... so nyet.

</comment><comment><USER12> It Slows me down. I've had a few drinks, but don't recommend it.

</comment><comment><USER13> Does 8 cups of coffee should count as "under the influence"?

</comment><comment><USER14> [http://xkcd.com/323/](http://xkcd.com/323/)</comment>


Thrift, Scribe, Hive, and Cassandra: Open Source Data Management Software - <AUTHOR> http://www.cloudera.com/blog/2008/10/24/thrift-scribe-hive-and-cassandra-open-source-data-management-software/ <comment><USER2> This is interesting stuff (especially Cassandra), but I have to confess I've had nothing but troublesome and negative experiences with Thrift in my experiences with it, and right now I'd say that's the weakest link in this structure.

Thrift is fantastic when you're working in a C++-ish mode where CORBA-style IDL was as good as it got. But when it comes time to try and build something more flexible in terms of the protocol, or interface with scripting languages like Python which depends on a less typed kind of architecture, you're going to hit a lot of growing pains.

For example, I work on a project (which you can see public code for, check my github for Fuzed) that we'd like to look into providing a generic thrift interface for. But so far the Thrift infrastructure, despite being entirely capable of it, doesn't seem to show much interest in embracing flexible or generic protocols. Everything needs to be big-banged out up front, and this just doesn't jive with larger meta-projects building out fault-tolerant and flexible infrastructure that Hadoop doesn't meet the needs of.

This post's intent is not to say, "Thrift is terrible." Indeed, it is awesome at what it currently does. But if you want to go beyond that you're going to have to invest significant time and resources to get the protocol that binds all these amazing services up to snuff.

</comment><comment><USER3> Interesting stuff. I also noticed another article that explains how to configure and use Scribe for Hadoop Log collection:

[http://www.cloudera.com/blog/2008/11/02/configuring-and- usin...](http://www.cloudera.com/blog/2008/11/02/configuring-and-using-scribe- for-hadoop-log-collection/)

The e-mail address at the end of the article goes to support id. That is a good way to attract customers in startup mode.

</comment><comment><USER4> Amazing stuff.

I am particularly interested in Scribe:

 _A Thrift service for distributed logfile collection. Scribe was designed to run as a daemon process on every node in your data center and to forward log files from any process running on that machine back to a central pool of aggregators. Because of its ubiquity, a major design point was to make Scribe consume as little CPU as possible._</comment>


Six Years of Hacker News Comments about Twilio - <AUTHOR> https://kev.inburke.com/kevin/six-years-of-hacker-news-comments-about-twilio/ <comment><USER2> Seems like he just cherry-picked the negative comments. That'd be fine, but choosing not to mention this kind of hurts his argument. (Could have titled the article "Six Years of Twilio Doubters on Hacker News" or something more clever than I can come up with.)

The comment he gives for "Twilio Launches UK SMS" is from the bottom of the page with one or more downvotes. Meanwhile, the first comment on that page says "Awesome work Twilio, been looking forward to being able to play around with SMS as much as I have calls without having to use a US number."

<comment><USER3> that whooshing sound you hear is The Point, flying past your head

<comment><USER4> That's not nice, especially after criticizing others for being negative.

</comment></comment></comment><comment><USER4> It's no secret that commenters on the internet produce a lot of lame, negative comments. If you filter for those, you're basically trolling yourself at a meta level.

I bet if you collected the best and most insightful comments about Twilio over the same time period, you'd find they go further in the positive direction than these ones do in the negative.

<comment><USER5> The collection of negative Twilio comments isn't self-trolling, it's "lol those haters were wrong."

</comment></comment><comment><USER6> > Keep doubting! And don't forget to crap on any new thing that gets launched.

For every post like this, you get two complaining that HN is a bunch of cheerleaders for XYZ. I don't know if the positive/negative balance is quite right on HN, but I do know that it's not all "haters gonna hate"-worthy. Further, some of the highlighted comments are pretty factual and useful. For instance: Authy is/was a fairly sloppy app, and it managed to lose my data during one of its many upgrades.

</comment><comment><USER7> What is the point of this post?

<comment><USER8> revenge?

</comment></comment><comment><USER9> This is terrible. There should be a law against it.

<comment><USER9> Also how long before it comes out that Peter Thiel is secretly running Twilio out of his basement.</comment></comment>


Ask HN: Certificates any good? - <AUTHOR>

Thinking about getting a CompSci certificate from Harvard. Partially for the challenge, something to do, and "why not," but I would like to also have some opinions if such a certificate would be beneficial towards a programming/project manager career. <comment><USER2> Although I can't speak from experience, I think building something useful and collaborating with others on projects might help you the same, if not more, than a certificate.</comment>


Plot: A Programming Language for Old Timers (2009) - <AUTHOR> http://users.rcn.com/david-moon/PLOT/ <comment><USER2> There is a newer version here: [http://users.rcn.com/david- moon/PLOT3/](http://users.rcn.com/david-moon/PLOT3/)

<comment><AUTHOR> wow, thanks for the pointer!

</comment></comment><comment><USER3> As an aside - I clicked on one of the links and the page changed so quickly that I initially assumed something had gone wrong!

<comment><USER4> amazing what happens when you throw out all the excessive JS and CSS isn't it. ;)

People complain about the web being slow but it's not the web, or web browsers. It's all the crap we've shoved into web sites that they just don't need.

</comment></comment><comment><USER5> Not sure I read this correctly (and I know nothing about LISP), but this seems to support multiple dispatch (ie method selection based on the types of all function arguments)?

<comment><USER6> Yes, it supports multiple dispatch. And so does CLOS (Common Lisp Object System)

</comment></comment><comment><USER7> This is such a cool language. The Macro system is really interesting. Its a mostly like Dylan (Common Lisp + CLOS, Basic Syntax) but with Python Syntax.

<comment><USER2> The designer of this language, David Moon, was also one of the designers of Dylan and Common Lisp.

<comment><USER7> I know, he is amazing.

</comment></comment></comment><comment><USER8> Has it ever been implemented? Or is it still just a thought experiment in language design?

<comment><USER9> I'm pretty sure Moon (who is a famous old-school lisp hacker) will have at least some prototyping quality implementation somewhere, the design is to detailed for a mere thought experiment and there are longer code snippets around:

[http://users.rcn.com/david- moon/PLOT/page-35.html](http://users.rcn.com/david-moon/PLOT/page-35.html)

I read about PLOT years ago and thought the approach to syntax (and macros) was quite clever; I don't remember the exact details but it was the first time I had seen something that was both hygenic and not horribly complex to implement.

BTW, his markdown alternative (MMD -- Moon's Mark Down) also looks pretty nice (expressive and lightweight, but unlike org mode or other monstrosities trivial to parse and unambigious). [http://users.rcn.com/david- moon/MMD/HTML/index.html](http://users.rcn.com/david-moon/MMD/HTML/index.html)

He also has a ~700 LOC standalone python implementation which includes the sequence diagram drawing code: [http://users.rcn.com/david- moon/MMD/MMD.py](http://users.rcn.com/david-moon/MMD/MMD.py).

</comment></comment><comment><AUTHOR> slides from International Lisp Conference 2009: [http://users.rcn.com/david- moon/PLOT/Moon-ILC09.pdf](http://users.rcn.com/david-moon/PLOT/Moon-ILC09.pdf)</comment>


Ask HN: Contract Forms: Give away Word doc, sell annotated PDF?  Or vice versa? - <AUTHOR>

BACKGROUND:  I'm a lawyer, formerly a public software company GC and large-IP-law-firm partner, now in private practice; I have other credentials I won't go into here.
For a long time I've been interested in streamlining my contract-drafting and -review work. I've never been fond of the reinventing-the-wheel that seems to go on in just about every negotiated transaction.
"THE PRODUCT":  With that in mind, I've been developing some easily-editable contract forms -- really, they're highly-configurable, checklist-like compendiums -- that I'll be making available under a Creative Commons license.  I've annotated the forms pretty extensively with what I hope is reader-friendly commentary.  The forms aren't a substitute for legal advice, of course, but they could give lawyers a decent head start in drafting and reviewing contracts.  I've also found them very useful as teaching materials in a law school contract drafting course that I teach.
Following the advice I've read here and in pg's essays, I want to get a version of  "the product" out there for people to look at.  Toward that end, I've posted a sample two-page nondisclosure agreement (NDA) as an editable Word document, along with a PDF excerpt from the longer-form annotated NDA compendium.
The documents are at http://www.TATECompendium.com.
QUESTIONS:  Most HN readers aren't lawyers, but some of you probably work with lawyers from time to time, so I'd appreciate your input as business people on the following.  (I'm posing analogous questions to lawyers.)
QUESTION 1:  To what extent would you be comfortable giving your lawyer either a short form or a compendium form like this, and asking whether it made sense for him/her to use it as a starter draft in doing your legal work?
QUESTION 2:  I've put a good bit of work into the project, so I'd like to try to monetize it at least somewhat, but I'd also like to create as few barriers to widespread adoption as I can.  Should I --
OPTION A:  (1) Give away for free an editable Word-document version of both the short-form NDA and the complete NDA compendium, _without_ annotations, and  (2) use e-junkie to _sell_ a locked- and branded PDF of the complete compendium _with_ annotations?
Option A would amount to selling the annotation content as an e-book, while giving away editing convenience for both short- and long-form drafts.
or
OPTION B:  (1) Give away the short-form NDA, in editable Word-document form, and a locked PDF of the complete annotated compendium, and (2) sell an editable Word document of the complete compendium?
Option B would amount to giving away an editable short-form starter draft, and also giving away the annotation content, but selling editing convenience for a long-form draft.
For weeks I've been leaning toward Option A, but recently I've been wondering whether Option B might be better over the long run.
Any thoughts?  All (constructive) comments and suggestions gratefully received.   I'm especially interested in feedback about what other contract types could use starter-draft compendiums like this.
FYI, I've got a few other contract types pretty much done -- consulting-services agreement, Web site terms of service, employment agreement, reseller agreement, etc.
Thanks in advance. <comment><USER2> Until recently, I worked for a major retailer of online legal forms. You can get in touch with me if you'd like to learn more about the landscape. To answer the questions:

1) I'd expect my attorney to react like my doctor would if I brought him a kidney in an icebox and asked him for a transplant. The kidney might be good, but how does he know?

2) If you're giving away a usable product, don't plan to sell much of it -- even if the full version is better in some significant way. If the freebie is good enough, why buy?

Overall, I think you're going to find that you have tough competitors -- huge document libraries, low prices, and solid marketing. Have you surveyed the competitive landscape?

<comment><AUTHOR> Responding to both apowell and underdesign:

Yes, I've surveyed the competitive landscape pretty extensively. I agree with your analyses of potential weaknesses.

Two possible differentiators I see are:

(1) the "open source" nature of the contract clauses themselves, which eventually could result in the compendium becoming a de facto standard; combined with ...

(2) ease of configuration (checkboxes) and ease of editing.

But those two points might not be enough to motivate people to pay anything.

Thanks for the input.

</comment></comment><comment><USER3> You're getting into a market rife with competitors, and they're all offering the same product for free, or more value for less money.

Plus, no one like NDA's and they've very hard to defend legally. That product is designed for big business, who already have lawyers drafting NDA's. Not regular consumers.

Selling legal opinion (and it's _opinion_, not fact) is a valid business model, but there's no real accountability. How can one defend a contract when you never met the writer?

My 2¢: Start a blog, give away (free!) a template contract a month, along with regular postings of explanations of the legal areas your covering along with further research. Start a dialog with the public about what they need and tailor your products to the market.

Get subscribers to your legal opinion, be the expert, and find new legal business by simply being the best at what you do.

Also, your domain name sucks.

<comment><AUTHOR> Which domain name sucks - TATECompendium.com, or OnTechnologyContracts.com? (Or both?)</comment></comment>


Parse Alternatives - <AUTHOR> https://github.com/relatedcode/ParseAlternatives <comment><USER2> Over the past two days I've seen people hocking ad platforms, database products, push services, pubsub thingers, etc... But obviously there is a gap because nobody has the full solution in the package that parse wrapped up.

It's like the iPhone. Yeah the capacitive touchscreens, multitouch, and web browsers on phones existed but until Apple combined them they were just crap that didn't work well together.

Parse wasn't perfect either but what we don't need is everyone who has built a api that saved data to something claiming they can replace Parse tomorrow.

<comment><USER3> There were fine tablets what was missing was prestige / cool factor / effective advertising.

</comment></comment><comment><USER4> I'd also encourage people to check out gun - [http://gun.js.org/](http://gun.js.org/) (disclaimer: I'm on the gun team)

GUN is a highly modular, open-source, real-time, offline-first, distributed cache storage engine. By default gun uses localStorage for data storage, but with gun-level there are many more data storage engines just a module away. GUN defaults to pushing all data. The gun team is regularly releasing new modules, new and improved functionality, and improving performance. If you have any questions, please feel free to ping the gun team on Gitter.

[gun-level]: [https://github.com/PsychoLlama/gun- level](https://github.com/PsychoLlama/gun-level)

[available data storage engines]: [https://github.com/Level/levelup/wiki/Modules#storage](https://github.com/Level/levelup/wiki/Modules#storage)

[gun's gitter channel]: [https://gitter.im/amark/gun](https://gitter.im/amark/gun)

</comment><comment><USER5> I don't see why anyone would choose a Parse alternative. This would require rewriting your app to support another PaaS that will probably die in the next 5 years. What I am looking for is a managed Parse Server solution so all I have to do is import my data then do a find/replace in my code to change the parse domain to the new host.

</comment><comment><USER6> I'm not familiar with Parse, but just recently Kinto was announced as an alternative:

[https://news.ycombinator.com/item?id=10994736](https://news.ycombinator.com/item?id=10994736)

</comment><comment><USER7> The Serverless Framework - Open-source application framework that allows you to create serverless backends with AWS Lambda and AWS API Gateway. Lambda only charges you when your code runs and auto-scales out-of-the-box.

[https://github.com/serverless/serverless](https://github.com/serverless/serverless)

</comment><comment><USER8> I'm not sure what provider I will transition to after Parse, but I fully expect support for GraphQL.

So far, it seems my leading option is [https://www.reindex.io/](https://www.reindex.io/)

If you've thought about getting into GraphQL or Relay, the Reindex tutorial is a great way to get a feel for it. By the time you finish step two, it gives you an instance of graphiql, a query tool which really shows off the power of GraphQL, with query autocomplete and built-in documentation in the right panel.

</comment><comment><USER9> Or you could, just, you know, build your own API and be in control of your own destiny. Though, I understand that some mobile devs prefer/want to just be mobile and not web devs. To each their own.

Shameless plug: I could use some work right now. I've built a handful of APIs that have moderate-heavy production use (50k users). I'm a good fit. :) Email in profile.

</comment><comment><USER10> [https://sheetsu.com](https://sheetsu.com) can be used as a simple DB (spreadsheet as a DB). It provides whole CRUD, auth, permissions (more here [https://sheetsu.com/docs/beta](https://sheetsu.com/docs/beta)) and is super simple in setup. I'm founder.

</comment><comment><USER11> QuickBlox especially if you're looking for chat / video calling / push on top of data APIs: [http://quickblox.com/](http://quickblox.com/)

</comment><comment><USER12> On the push notifications side, Batch (disclaimer: I'm a founder), is very solid:

[https://batch.com/features](https://batch.com/features)

<comment><USER13> How does your pricing work for my app that is very bursty with regards to notifications? Think real time sports scores.

</comment></comment><comment><USER14> Here's a list of alternatives geared for game developers. This is taken from a post that also includes a pricing comparison table: [http://blog.soom.la/2016/02/top-10-parse-alternatives- game-b...](http://blog.soom.la/2016/02/top-10-parse-alternatives-game- backend.html)

GameSparks - a good mobile backend as a service option, and one of the more popular ones. It is flexible and has a good set of features. It runs a MAU (Monthly Active Users) cost which can be confusing, leading people to think it's too expensive when, in fact, it offers quite a competitive price.

PlayFab - only been around a bit over a year (it was in development for three years under the name Uber Entertainment) – it launched in September 2014. Some will say it is the most complete backend platform, especially after it partnered with Photon, the multiplayer cloud service. Some of the features include player accounts, virtual goods management, in-game messaging, and game data storage.

HeroicLabs - The key selling point is the API which allows game developers to easily integrate multiplayer and social elements without needing a server backend. It focuses and optimizes mostly for massive games, games of high volume. HeroicLabs also has a code sample with SOOMLA in our knowledge base.

Gamedonia - complete backend solution for mobile games. The cloud platform for game developers does not require a server and offers many social games and real-time elements such as PvP (player versus player) modules, in-game chat or social sharing. Gamedonia was founded in 2012 and besides offering mobile support, also works in the browser.

Kii - another developer sweetheart and a Unity partner, making its community support quite strong. Its key selling point is a burst limit of 150 API calls per second, which is quite important. On the other hand, it does not allow anonymous users. Other features include server extensions, push notifications, leaderboards and achievements. It supports iOS, Android and Windows 8.

Kinvey - one of the pioneers in the MBaaS game, which by default makes it a strong contestant for the best service out there. Compared to Parse, I'd say the two are quite similar in features: it offers cloud storage and push notifications. There's also an easy way to integrate Facebook Open Graph for all those apps without websites. However, like Parse, it's a general purpose MBaaS for all mobile apps, not just games.

brainCloud - might make your brain hurt :) of all the features it offers. It calls itself "backend in a box." It is a ready-made, cloud-based backend designed for game developers, allowing them to jumpstart their game creation with various pre-built features. Its features include Cloud Data, including user and global statistics, shared data and custom files, Multiplayer, with support for turn-by-turn and one-way offline (clash-style) multiplayer. Other features include Achievements, Leaderboards and Monetization features.

Gamua Flox - scalable and lightweight cloud backend for mobile games built by Gamua. It runs on all mobile devices supported by Adobe AIR, and also allows offline play. Players can be authenticated through Google+, Facebook, email or the iOS GameCenter API. It comes with rich documentation and a powerful customer support. If you're developing with AIR, or specifically the Starling framework, this is the backend for you.

App42 - many features, including all the usual ones like leaderboards, cloud storage or social sharing. It used to be cheaper than Parse (now it definitely is), while offering the same burst limit. A great solution for any mobile game developer.

Photon - cross-platform multiplayer game backend. It allows you to easily add multiplayer to your games and run them in the Global Photon Cloud. You can also host your own Photon servers, if that kind of hybrid is your thing. It is a good choice for game developers of all sizes, from indies to AAA studios.</comment>


Follow buttons and the logged out user - <AUTHOR> http://blog.superfeedr.com/follow-buttons-logged-out-users/

<comment><USER2> > Fred Wilson coined the term over 2 years ago

What? No. That's ridiculous. For as long as people have used the phrase "logged in" there have been logged out users. A simple Google search for the phrase turns up a thread† from 8 years ago, and that's certainly not the first either. Coined the term? Really?

† [http://www.unix.com/unix-advanced-expert- users/25178-who-9-c...](http://www.unix.com/unix-advanced-expert- users/25178-who-9-command-shows-logged-out-users.html)

</comment><comment><USER3> I habitually hover over links before clicking them to see the url in the status bar.

It _deeply_ unsettles me when I see a button for which this tactic doesn't work. Rationally, I know there's no difference; you could have an href="example.com" and just capture clicks to do whatever you want. Nevertheless, it still spooked me enough to stop me from clicking the button.

<comment><AUTHOR> That's a very good point. I think we can do that by setting up a href on the <a> will still return false on the onlick. right?

</comment></comment><comment><USER4> The solution proposed seems interesting, but still requires an account with a third party, in this case the feed reader (if not online, a downloaded native app).

Given the nature of self-updating browsers and devices being permanently with or around users, I suggest something else.

Let me follow whoever I want without creating an account, store these preferences in localStorage, then use it to build a news feed on the home page, just like a logged in user.

Then, unobtrusively suggest other features that can only be made available to signed up users, due to technical constraints.

(No, notifications are not such features; a browser extension that checks localStorage and raises browser notifications a la Chrome should be enough for non-logged in users).

</comment><comment><USER5> Sidenote: They updated their WP plugin today as well [http://wordpress.org/plugins/subtome/](http://wordpress.org/plugins/subtome/)

</comment><comment><AUTHOR> I hope HN had a follow button too :)</comment>