Could ImGUI Be the Future of GUIs? - <AUTHOR> https://games.greggman.com/game/imgui-future/ <comment><USER2> Really probably not. I love them and they're very handy in certain situations (debugging tools, quick UIs) but once you need a lot of customization they become extremely cumbersome. Also really kind of makes it impossible for designers or less technical people to do anything. Also, while I think separating view logic is slightly overrated, it is useful, and it's very hard to do that with IMGUI. Also it doesn't thread well. Also... Look there's like a million downsides.

Also saying there's no memory allocation is really misleading. There's PLENTY of memory allocation, per frame, you're just not explicitly doing it yourself. It's actually much worse than an RMGUI in this regard, because at least with an RMGUI you get the allocations over with once. With an IMGUI you're allocating things all the time. They're probably much smaller allocations, but lots of small allocations does not make for good performance.

One final note, the Unity 3D example always gets used. If you've ever written a plugin for unity or a custom editor, you're very familiar with the fact that it's editor gui system is extremely limiting and kind of sucks. I mean, it's an example, but once you're past the basics it's kind of a bad example.

<comment><USER3> On the allocation point, the efficient way to handle this is to use a per- frame memory pool. Because nothing in the IMGUI can persist between frames, you can allocate a single arena of memory for any UI elements that need to store bounding boxes or callbacks or whatever. Each frame just reset your next_ptr to the start of the arena. Technically you are allocating memory, but in practice your allocations are free.

<comment><USER4> Adding a separate complex ad hoc memory allocation scheme is not what I would call free. Granted, computationally-wise it may be relatively cheap but it does add multiple forms of complexity to a problem that doesn't exist in rmguis.

<comment> loup-vaillant Arenas are the simplest allocation scheme ever.

      // Start of frame
      void *arena    = malloc(LOTS_OF_MEMORY);
      void *next_ptr = arena;

      // Allocate something
      object   = *next_ptr;               // return that value
      next_ptr = object_size + alignment; // crash if out of memory

      // End of frame
      free(arena);

By the way, such "separate complex ad hoc" memory allocation schemes are the reason why manual memory management is faster than garbage collection. If you did everything with malloc(), it would be slower (unless the GC language allocates much more than C, which they often do).

<comment><USER5> No need to malloc each frame. Malloc at startup and memset each frame (don't even need to do that, tbh).

<comment><USER6> Nope, just set the pointer back to where it started from. You do need to be super careful doing this though, as anything that relies on RAII (in c++ land) will be busted. You could manually call the destructor on the object in that case, but kind of defeats the purpose of the "no allocation" goals

<comment><USER4> C++ includes it's "placement new" feature specifically to cater to the memory pool needs. There's no allocation, and only constructor and destructor calls.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> FWIW, Unity are moving away from ImGUI (to a classic retained mode UI system) [https://blogs.unity3d.com/2019/04/23/whats-new-with- uielemen...](https://blogs.unity3d.com/2019/04/23/whats-new-with-uielements- in-2019-1/)

<comment><USER8> Also to clarify, UIElements (Unity's new retained mode UI framework) is available now in 2019.1 for Editor UI. Runtime UI will also be using UIElements in the future.

</comment></comment><comment><USER9> In the context of creating debugging UIs for games and graphics applications, Dear imGUI is a godsend. Programmers love it because there is literally only the code to worry about. It's very easy to get it up and running, and all the code that handles the UI drawing and interaction is in one place so it's easy to reason about.

It works very well in the context where you already have fast graphics and an update loop, and you're already expecting to redraw the whole screen every frame. It does not really suit more complex, text-heavy UIs where you're rendering thousands of glyphs with proper kerning and ligatures and anti- aliasing, etc, and want the result of that hard work to be retained in the framebuffer unless it absolutely needs to change.

<comment><USER10> > want the result of that hard work to be retained in the framebuffer unless > it absolutely needs to change

I think immediate mode GUI libraries can get around this issue by still caching and reusing between frames. Conrod does this by still having the state in the background although you are programming to an immediate mode API:

[https://docs.rs/conrod/latest/conrod/guide/chapter_1/index.h...](https://docs.rs/conrod/latest/conrod/guide/chapter_1/index.html#is- conrod-immediate-or-retained)

<comment><USER11> That's a bit antithetical, given the other side of the debate being Retained Mode GUIs.

That said it's a good middle ground. Use whatever API you prefer over a well optimized implementation.

</comment></comment></comment><comment><USER12> The author does a good job explaining some benefits of an immediate mode renderer but vastly misses the disadvantages.

The immediate mode renderer is great for toy programs. Similar to how you could reproduce 'look here is how simple it is to write hello world and compute the millionth digit of PI' in a new esoteric language...

Occlusion, hit-testing, state changes, scrolling/animations even in the simplest forms will fall over. Infact, that's why we have every major browser move their touch and animation systems into a layer based compositor system (into a separate thread / process).

The author also grossly misses their own example of 'how a spreadsheet with many rows and columns will update faster using ImgUI' and how Instagram styled apps will fare better ImgUi.

A retained mode renderer will use virtual scrollers, efficient culling of nodes for both display and hit-testing (scale to billions of virtual cells) and more importantly help a team of people coordinate their work and get things done.

We are no longer in the 90s.

<comment><USER13> In fact, with Javascript JIT engines (whose teams deeply understand the use of libraries like React) relentlessly attacking the overhead of DOM nodes and their initialization, and with users who actually expect the design flexibility provided by CSS... a system like React is actually an ideal layer of abstraction for modern UI implementation on practically any platform.

Sure, if you're on an embedded platform, somewhere a JIT can't run, or if you're doing something with real-time rendering requirements (and honestly modern React Suspense should even make that feasible), you may want to use something lower-level. But most people won't need to do this.

<comment><USER2> The DOM being slow is really more an artifact of browsers/HTML and the history behind doing document based layout. React is a nice solution to that specific problem; but this article suggests immediate mode gui's are the future, which, I don't think that's really the case. And I'm not sure I'd really call React an IMGUI anyway. It's similar, but it's also pretty different.

</comment></comment></comment><comment><USER14> This is really reads like someone trying to sell you something. I've done work on frameworks for both immediate mode and retained mode GUIs. They both absolutely allocate memory behind the scene. There absolutely is state being marshaled around. Caching commonly used state is important. Performance can be bad and great in both. You're really just subscribing to different sets of opinions

<comment><USER15> Any moderately complex "immediate mode" GUI system is going to do something equivalent to constructing a "retained mode" GUI on the fly I'm guessing.

<comment><USER16> It will. In fact, even a simple one will require this. But it's not much of a problem - 99% of the time, the UI is the same from one frame to the next, and it isn't much work to detect this. So even if every change requires a complete rebuild of everything, it's not much of a problem.

(I've written systems like this for Cocoa and Win32, and it never turned out to be necessary to do anything other than just regenerate the entire UI any time anything changed. The update runs at 30Hz or 60Hz, and when anything is changing, the UI gets regenerated a lot! - but so what? Most of the time, the UI doesn't get regenerated at all. Then something happens, and the code spends 2 seconds getting absolutely hammered continuously, malloc malloc malloc malloc malloc, god help us all... and then, once again, nothing. The operator puts their fingers to one side and stares at the result with their eyes. Repeat.)

</comment></comment></comment><comment><USER17> I think the author is over exaggerating the problem of object creation and destruction in traditional gui frameworks. List/collection views are designed to reuse objects as you scroll. Secondly I think the author is also downplaying the fact that retained GUIs can also cache object rendering. Just as the gpu doesn't have to draw the whole screen when only the cursor is blinking, it also doesn't have to redraw widgets unless their size changes.

Immediate vs retained is a simple case of budgeting against cpu usage or memory usage, and it should be considered in that light. (immediate uses more processing, retained uses more memory)

<comment><USER18> Thinking about this decision just as a performance one disregards the fact that the code is substantially different. It does seems likely that one way is more intuitive / easier to work with than the other, I wouldn't know which though.

<comment><USER19> It depends on the probkem younare trying to solve with your GUI, I suppose. Sometimes, it is better to just recreate the whole GUI to adapt to a model change (e.g. the user moved half of the tree nodes somewhere else), sometimes it is easier/faster/... to just update the existing GUI (e.g. update the text of a label inside a complex dialog widget).

</comment></comment></comment><comment><USER20> Retained GUIs vary wildly in implementation.

Many of authors most significant criticisms on retained GUIs are implementation considerations. GUI frameworks exist that solve his key criticisms of complexity and are pleasant to work with.

Criticisms that target core architecture of retained GUI I don't consider to be valuable design goals, at least in settings where I work on GUIs. e.g. memory usage.

Alot of things are glossed over that remain challenges in both, e.g. layout management.

HTML is an interesting example. First iteration of HTML was essentially immediate mode if you think about a single client/server interaction as a GUI update cycle. Server sends draws to client browser and client browser sends back to server user selections. There is no retained state on gui side. Now with programmatic access to DOM, ability to attach events to DOM elements from client side it is now a retained GUI. Seems to be where things evolve to naturally.

The GUI framework I use nearly daily is retained and very pleasant to work with in terms of ease of belting out screens & readability/maintainability of code. The simplicity comes with compromises though as there are limits on GUI idioms that can be expressed. Occasionally run into those boundaries and resulting GUI does look a little plain and unexciting, but for something that is substantially about data entry its fine.

</comment><comment><USER21> Recently I started playing with [https://github.com/ajnsit/concur- documentation/blob/master/R...](https://github.com/ajnsit/concur- documentation/blob/master/README.md) which has been the most refreshing UI paradigm i've used in a while. and it reminds me a lot of this ImGUI approach, but behind the scenes it uses coroutines instead.

The idea is that a button is a UI element that _blocks_ until an event is fired. You can then compose elements in time like:

        button "hey" >> label "clicked"

which is a program that displays a button, you click it, the button goes away and the text "clicked appears"

Or you can compose programs in space:

        (button "hey" <> label "not clicked")

this is a program that displays both a button, and a label at the same time.

Now, by combining both space and time, we can create a program that changes the label when clicking as follows:

        program = (button "toggle" <> label "off") >> (button "toggle" <> label "on") >> program

This is an application that toggles a label on and off when you press a button. (Note that the definition is recursive)

</comment><comment><USER22> There's a difference bt poor impl and poor design.

As the author points out, HTML has a poor design (eg. if you want to have a 1000x1000 cell table, you have to have 10^6 actual cells - that's a lot of tds or whatever to parse).

Modern OO GUI frameworks don't do this - they say something like:

cellRenderer.draw(target, row,col,position,size)

No creation of objects required. Of course since it's so easy to create OO programs a lot of code isn't great... and then others copy that code and so it goes.

Seems like we keep re-creating software b/c we haven't taken the time to look at what exists and only then decide on what to keep and what to change. "This is too complex - I'll re-write it!". 10 years later: "We added all the features that the existing software had and now the new one... is just as slow... but we did sell a lot of conference tickets and books so... totally worth it."

When I was 20 I also thought I knew better so I get it.

</comment><comment><USER23> I feel that the future lies in combining retained and immediate interfaces, preferably with the granularity to allow deeply nested retained interfaces that are fast for complex ui (or for a realtime system with memory to spare), whilst still allowing one to go the other direction, such that a simple ui can be written cleanly and logically for low-memory systems (such as embedded or boot guis). It would need a very well designed api for this, but I feel the benefits are worth the effort (and I'll probably look into this next time I have the freedom to choose ui apis).

A balance may be letting people define it either way, so that manually written ui still can have auto-layout yet intuitive code (following control flow primitives), whilst allowing generated retained uis to be manually editable -- perhaps even allowing one to then embed one within the other, a boon for scripted interfaces that perhaps have people of various levels of experience producing ui elements, such as a musician with little experience being able to add a simple visualiser in an immediate manner to a deeply retained daw gui.

Of course, there's a lot here that is implementation, and some criticism either way can be optimised out. Immediate mode can still cache its rendering, we've had optimised blitting since the early days, and is only usually a problem with complex ui. Retained would get fewer cache misses if we weren't allocating madly across the heap and took a more disciplined approach allocating to contiguous memory -- which is almost entirely a language/api problem (in my experience) that can also happen with immediate but we typically don't see since it's often done in a more procedural style that is allocating to some pool.

Other api elements, such as handling lists etc aren't really a differentiation between retained and immediate, those can be made in either.

For me, I often find that the ability to write out prototype ui code in an immediate style in very quick and satisfying (exactly what I want in prototyping), however once I start to expand upon a ui, I find it best to over time refactor towards a retained style, since by then I will typically have some templates for what ui elements look like, and so I just have to pass a string and function pointer to fill in the template.

Can't see why we can't have nice things and let both coexist...

</comment><comment><USER10> Conrod is an immediate mode GUI library for rust[1]. I've been using it for an image processing app[2] and have enjoyed the way the code turns out. Everything is much more straightforward as you don't have to reason about callbacks interacting with a loop that's not yours to control and the performance seems good.

[1] [https://github.com/pistondevelopers/conrod](https://github.com/pistondevelopers/conrod)

[2] [https://github.com/pedrocr/chimper](https://github.com/pedrocr/chimper)

</comment><comment><USER24> Immediate mode uis are fine for debug displays or for displaying data that's changes every single frame, but for anything else, in a shipping product they are just a waste of resources. The primary wasters are excess memory allocation, string generation, and the sheer amount of redundant function calls. Anything you do to address those problems result in converting your ui to a retained mode UI. For those advocating react like approaches to solving this.. similar problems are involved. Diffing state is wasting cycles unless it's done so optimally and carefully that it becomes a technical feat and ends up being as complex as just doing something retained. Source: game developer for 25 years on console, desktop, and mobile.

</comment><comment><USER25> Probably not. With technologies like React that make retained-mode UIs look more like immediate-mode ones, there is less need for full blown immediate- mode UIs. React achieves the programmability of an immediate-mode UI without sacrificing the performance of a retained-mode UI (at least, that's the goal).

</comment><comment><USER26> > A few problems with this GUI style are:

> You have to write lots of code to manage the the creation and destruction of > GUI objects. [..]

> The creation and destruction problem leads to slow unresponsive UIs [..]

> You have to marshal your data into and out of the widgets. [..]

My biggest pain point with the retained mode GUIs I worked with was none of the issues mentioned above. It was always the centralized GUI thread and the consequential synchronization complications. I don't know if this is an inherent problem of retained mode GUI frameworks and if there are some that don't force all widgets into a single thread. If not, this alone is a reason to for me to find immediate mode interesting.

<comment><USER2> Immediate mode, if anything, makes this harder. (You absolutely have to run the GUI on one thread, for instance). Really though you can get around that on either of them by spawning a worker thread/coroutine/etc. on button clicks and so on.

<comment><USER26> The real problems start, when the worker thread needs to update the GUI, for example to advance a progress bar. With the frameworks I know I have to build a communication channel between the threads and tell the GUI thread to show and update the progress bar.

My hope was that with an immediate mode framework I could just show a progress bar on top of the existing GUI right from the worker thread. I don't know enough about immediate mode to say if this is really possible. It would simplify a lot of my code though.

</comment></comment></comment><comment><USER27> I recall reading this article in your comments on the last GUI-specific link posted here... where you just kept disagreeing with comments that took the time to point out how this stuff is largely off base.

We moved away from WM_PAINT for a reason.

</comment><comment><USER28> Here's a downside that wasn't mentioned:

        if (ImGUI::Button("Click Me")) {
            IWasClickedSoDoSomething();
        }

This forces Button to be stateless, which limits the possible quality of implementation. If you mouse-down on a button and the button changes before you mouse-up, it shouldn't register as a click. Similarly, if you mouse-down on a button, drag to the button, and mouse-up, it shouldn't be a click. Implementing this in a fully immediate-mode GUI with this interface is either impossible or requires gross hacks.

<comment><USER29> A naive implementation would have the problem you describe. However, a smarter library implementation avoids this (e.g., by generating an id for the button, saving the id on mouse-down, and checking the id on mouse-up). The user of such a library won't have to worry about it.

<comment><USER28> And how, exactly, is the id created? Some hash of the button's text and coordinates?

I would call that a dirty hack, no to mention being implicitly stateful.

<comment><USER30> But a stateful GUI is not a sin: the program as a whole has state, application code needs to process GUI inputs to update application-level state (e.g. currently set game options) while tracking mechanical details like whether a button is "half clicked" is suitable for automation at the GUI library level.

Regarding IDs, they can (and must) be provided by client code, as client code is responsible for managing widget identity (i.e. whether the button that might have a mouse up event this frame is "the same" that received a mouse down event some frames ago). In C or C++, string names could usually be autogenerated with trivial macros relying on __LINE__ and __FILE__.

</comment></comment></comment></comment><comment><USER31> Can we please just stop moving around in circles in the tech industry? Nobody seems to learn anything from past methods, tech and everything.

<comment><USER32> LOL. My favorite part of it was the last line:

"More research into ImGUI style UIs could lead to huge gains in productivity."

Don't tell this cat that the research on this stuff goes back >40 years and that the introductory chapter of any book on computer graphics would have talked about all of this. Not like it would help him - he hasn't read anything about it, didn't even do a cursory Google search. Sheesh. A low, low bar.

<comment><USER16> Do you have any recommended links?

<comment><USER32> I do!

One of my favorite is "Don't Fidget with Widgets, Draw!" ([https://www.hpl.hp.com/techreports/Compaq- DEC/WRL-91-6.pdf](https://www.hpl.hp.com/techreports/Compaq-DEC/WRL-91-6.pdf)) It's modern enough to be understandable, and while it's referencing Ezd (a Scheme drawing system) it greatly influenced Tk (which is still used in all kinds of heavy-hitting EDA software).

That one's only been around for 28 years though (well, the paper was published in 1991, so code was before that...) but let's go further:

The drawing system(s) that greatly influenced Ezd came largely from Xerox PARC, such as ALTO: [https://www.computerhistory.org/atchm/xerox-alto-source- code...](https://www.computerhistory.org/atchm/xerox-alto-source-code/)

There's code in there for a vector drawing program (in 1980!), as well as interacting widgets. Let's go back further...

Finally, we have to mention the Mother of All Demos, in 1968: [https://en.wikipedia.org/wiki/The_Mother_of_All_Demos](https://en.wikipedia.org/wiki/The_Mother_of_All_Demos)

Which if you haven't watched MOAD before, give it a spin. It will still blow your mind, but the interactive graphical drawing mechanisms will be recognizable.

Also, this "paint the screen every time" method is how a tremendous number of people who cut their teeth on DOS did things on the screen. DOS release date: 1981. So you don't have to have been an academic (which I am NOT) to have tried these techniques while solving practical problems.

As far as books: Computer Graphics Principles and Practice in C (later editions use C#/C++/etc. - the ideas are the same)

The 1995/96 one talks about retained mode graphics directly. That book has been standard in "intro computer graphics" courses for as long as it's been out. So at least 20+ years it's been the "start here" book.

So yea, this stuff has been around for a while...

</comment></comment></comment></comment><comment><USER33> IMGUI must sound appealing to people who have never done UI work. Just try to implement a responsive UI in an IMGUI. Layout code is not fun.

</comment><comment><USER34> I got fed up of ImGUI when I wanted to route events to my application instead of the GUI. Its good "out the box" ut when you need to get down and dirty to customise, it can be awkward.

Nowadays I do a hybrid approach, so I have use NanoGUI and create my own "live data" "retained mode" controls. Now I have either the best of both worlds or the worst of both worlds. I think the best:

Pros: \- I don't have to bother with data binding. As the control is passed a pointer to the actual memory for he value, it can "go get it" when rendering, rather than my application setting its state. \- I still have classes to represent elements and state, so its conceptually simple to build controls on controls. I found this difficult with Imgui.

Cons: \- renders 100% full speed, but I am working on way to speed up and slow down render loop depending on user activity, so that when sitting idle, the cpu is not burning.

<comment><USER35> This is the exact issue I'm running into right now with dear ImGui. There is no event propagation. You can either transfer control over to ImGui, or you retain control. In Qt it would be possible for the focus widget to not accept events, so they would bubble up the hierarchy. Considering how the hierarchy is tied to the callstack, this seems difficult to achieve with an ImGui.

<comment><USER34> NanoGUI + live data custom controls = happy days

</comment></comment></comment><comment><USER36> I have implemented a bunch of UIs for games. Immediate mode sounds good, but each time the thing that has bit me has been layout.

Sometimes you need to traverse the hierarchy to figure out where things will be placed. Before traversing it for render. If your hierarchy is implicit in a call graph, you have to either duplicate your calls, or implement some kind of backend retained system so you can defer rendering until after layout.

Beyond the absolute simplest of toy UIs, immediate mode doesn't work in my opinion.

</comment><comment><USER37> Every time a developer decries some abstractions and tools as unnecessary complicated and too "enterprise", it probably means he haven't encountered a problem that this solution was created to address.

As a Unity developer, I love immediate mode GUI for debugging. But I would never in my right mind attempt to use it for actual in-game GUI. Project I'm working on right now is not incredibly complicated, it's just a typical mobile match3 game. But a typical screen here has: (1) background that has to be scaled over all screen, eveloping it around while keeping aspect ratio, (2) frame that has to be scaled to screen without keeping aspect ratio, (3) a "window" background that has to be scaled somewhat to screen (with margin), being enveloped by it, (4) interactive elements, that have to be scaled down from the "safe area" (so that there are no button under the iPhone bevel), (5) match3 game field that has to be scaled according to physical sizes of the screen, (6) pixel-perfect elements that have to be chosen according to pixel size of the screen (1x, 2x and 3x options) and scaled appropriately.

So, no, immediate GUI is definitely not the solution here.

</comment><comment><USER35> From dear ImGui's mission statement:

 _> Designed for developers and content-creators, not the typical end-user! Some of the weaknesses includes:

> \- Doesn't look fancy, doesn't animate.

> \- Limited layout features, intricate layouts are typically crafted in > code._

It may not replace retained mode GUI toolkits, but it can certainly make the life of devs easier. If all you need is to quickly hack together an internal tool, or some quick debugging interface, keep ImGui in mind.

</comment><comment><USER38> I have seem other programs doing stuff like that before, and I have also done some of that in my own programming (although not with this or any other library). I did not know what it is called, until I read this today. It look like good to me. Also, you will still need to add some extra variables if you are doing such thing as tab to focus, I think.

</comment><comment><USER39> Anyone experienced with ImGUI ever use Rebol and Red's DRAW DSL?

I believe Rebol's GUI support is even easier to use than ImGUI, but of course it can't be embedded and used in the same way as ImGUI either. I wonder if non Red projects could possibly hook into Red's system once Red/System gets closer to C level performance?

</comment><comment><USER40> > ... people scroll almost constantly in which case the ImGUI wins by a > landslide

I think this is a misrepresentation of how fast scrolling is usually implemented.

For fast scrolling, you render the page (which is larger than the viewport = "what fits on the monitor") ONCE onto a GPU texture, and then all scolling happens on the GPU side (the CPU just tells the GPU the offsets into that texture).

Immediate mode has to recreate the texture every frame, instead of once for multiple frames. So "It might use more CPU" is quite certainly true.

<comment><USER40> You can also do some simple math to arrive at a justification:

Assume a 4k x 2k display at 60 FPS.

Compute the throughput needed (Bytes per second) to draw an RGB framebuffer.

That is: 8M pixels x 3 Bytes x 60 fps = 1.44 GB/s

Note how we haven't done any computation yet to decide what the colours should be, this is just the CPU effort to do IO to tell the GPU about the new colours to show.

This would incur significant CPU usage, and your device would get hot quickly. In contrast, if you let the GPU scroll, you have to send two floats (for X and Y offset) per frame, and the GPU just does a hardware-parallelised lookup.

This is why we have GPUs, and why scrolling immediate-mode would make your device burning hot while a GPU does the task with minimal energy usage.

<comment><USER41> Following the same logic that you use... have you calculated how much memory do you need to store the memory of a single treeview, or a single scrolling document of just several pages?

Two floats? You are using a memory that is a CPU memory, a big chunk of memory. That does not exist in the GPU. In the GPU the memory is distributed so it can be used in parallel.

Immediate GUI exist because of GPUs, because with GPUs you can draw frames fast. If you look at Imgui code it uses GPU drawing for everything. In fact it uses only two drawing functions copying small rectangles in the screen.

It is drawing a single big chunk of memory what is extremely slow, and you need to do that before you do offsetting.

And if you work with variable data, like a treeview, you need to allocate for a finite amount of memory in the GPU buffers.

</comment></comment></comment><comment><USER42> I'm having a hard time to understand what is ImGUI (and what is the opposite RmGUI)... any could help me with ELI5? It sounds like ImGUI is reactive while RmGUI is not?

<comment><USER43> Games (normally) re-render the whole scene every frame.

ImGUI exposes that to their API users: you have to re-render and check for clicks on every frame. The code looks like React, (but not as optimized, it re-renders every frame!), and normally you have to keep state by yourself. Code example: [1].

Retained Mode is closer to the DOM, Cocoa or WPF: you create objects and there's an abstraction between the API and the renderer: they get re-rendered every frame for you. Componentes normally have events and state by themselves. Sometimes there's a visual editor too.

The main difference is the API. One is lower level than the other. In practice, the APIs aren't that different, except when it comes to event handling.

[1] - [https://docs.unity3d.com/Manual/gui- Basics.html](https://docs.unity3d.com/Manual/gui-Basics.html)

<comment><USER44> > Games (normally) re-render the whole scene every frame

They don't re-upload the whole scene to the GPU every frame, they don't recreate objects all the time. Immediate mode was only used in, like, the GL 1.x times.

<comment><USER43> But I never said they did?

</comment></comment></comment></comment><comment><USER45> Related recent thread: [https://news.ycombinator.com/item?id=19744513](https://news.ycombinator.com/item?id=19744513)

</comment><comment><USER46> Great find! I haven't done much work GUIs myself, but I would love to read more about alternative design philosophies in human-centered computing and their downfalls.

</comment><comment><USER47> React hooks is the closest you'll get in practice, once you factor in async, layout measurements and other practical things. But useState is pretty much just imgui with built in getters/setters rather than external state.

</comment><comment><USER48> The single most important factor when it comes to UI is text rendering. Immediate mode UIs are based on text rasterization, ie polygon creation for each character of the text while retained mode text is usually featuring texture atlases containing all characters in upper and lower case. This of course introduces a limitation on the number of fonts available to the developer, font sizes, etc. My 3D engine is using an immediate mode UI for the editor and tools while it allows for creation of retained mode UI for in-game UI components by automatically generating texture atlases for the selected font types

</comment><comment><USER49> Didn't Firefox put forward a big plan to basically implement the browser as an immediate mode UI designed to redraw everything on every frame?

<comment><USER44> WebRender is not just a "plan" but a real thing (I'm using it right now), and it's fully retained.

Immediate doesn't mean just redrawing everything on every frame, immediate means what's described in the article — not keeping state. WR _aggressively_ relies on kept state to optimize rendering of each frame as much as possible.

<comment><USER49> Very interesting, thank you.

</comment></comment></comment><comment><USER50> I hadn't heard of ImGUI, but after reading the definition realised that's exactly how you made custom menus in RM2k/3 :)

</comment><comment><USER51> Say I want to make a program, X, that draws a 50x50px square over another program, Y, at (200,100) and only program Y. Do i need a low level stuff for this, can imGUI be used here? or is it possible with electronjs etc... Also, would program Y be able to detect, with administrator privileges that another program was targeting its pixel space and drawing over it?

</comment><comment><USER52> >programmers find it more performant >plusses speed >minuses uses more CPU what?

</comment><comment><USER53> Are any implementations of this approach available for high-level languages?

</comment><comment><USER54> ImGUI is the past of GUIs.

That is how we used to do it on 8 bit and 16 bit platforms, before frameworks like Turbo Vision, GEM and Workbench came into the scene.

</comment><comment><USER55> Could somebody please ELI5 this? How is this different from traditional UI approaches and why would I want to use this?

</comment><comment><USER56> this feels more like drawing UI's using state charts in terms of expressiveness.

</comment><comment><USER57> Isn't the future of GUIs to have no GUI?

</comment><comment><USER58> It's important to point out why games use immediate mode GUIs:

1\. The GUI needs to be overlaid on the game image (OpenGL/DirectX). This is difficult with traditional GUIs like QT.

2\. The GUI needs to be updated in sync with the game, again, it's difficult to integrate traditional GUIs event loops into the game loop, especially with stuff like double/triple buffering.

3\. The GUI needs to be as fast as possible, games are severely CPU bound.

A retained mode GUI is typically easier to use, convenience is not why people use immediate mode GUIs.

It's worth pointing out that the immediate/retained split doesn't apply only to the GUI - there are retained mode graphical APIs - DirectX used to have one. They are only used in low-demand games, they sacrifice a lot of speed for the convenience of using a retained mode.

<comment><USER59> I've written real-time game UIs before so I think I have some relevant experience here.

1\. It is very possible to write a retained-mode GUI in a graphics API like DirectX or OpenGL. In fact, a retained GUI would typically wipe immediate GUIs in terms of performance in this context. In immediate mode, the GUI's vertex buffers need to be completely reconstructed from scratch every single frame, which is _slow_ , CPU bound, and cannot be (easily) parallelized. It's like reconstructing the game world every frame -- that would be ludicrous for any non-trivial game.

2\. I don't think there would be that much of a difference between the two UI models, since data updates can be dispatched from the event loop. It would be faster, too, because only UI components that need updating could be redrawn. This is far faster than updating the entire UI every single frame.

3\. As mentioned earlier, immediate mode GUIs are going to be a lot slower than retained mode, when implemented properly. Immediate mode GUIs put most of the work on the CPU instead of offloading most of the work to the GPU like in the retained model.

I think developers that are using immediate mode GUIs are doing so because of their ease of use. I think retained mode is typically harder for a game developer to conceptualize because immediate mode is conceptually similar to a game loop. Also, I don't know of any free & open source retained mode GUIs for DirectX and OpenGL and the like.

Also, DirectX at least (and probably OpenGL) encourages a retained-like model for general rendering. The only way to get decent performance is to re-use vertex buffers between frames and only update them when something changes.

<comment><USER16> I've written real-time game UIs too. I think you underestimate just how ludicrously fast CPUs and GPUs are, and overestimate the complexity of your average GUI. What does your average screen's-worth of GUI consist of, after all? How many widgets are there? I double dare you to tell me that a modern computer or games console can't handle 500 widgets per frame. And I now triple dare you to tell me that your UI designer has put that many damn widgets on one stupid screen in the first place.

(Every UI I worked on actually did redraw everything every frame anyway. It's really not a big deal. Your average GPU can draw a monstrous amount of stuff, something quite ridiculous, and any sensible game UI that's actually usable will struggle to get anywhere near that limit.)

<comment><USER59> I'm sure many games can get away very well with an immediate mode GUI. I think the question is not _can_ you, but rather _should_ you. My last project used a custom immediate-mode GUI. At the absolute pinnacle of optimization, it was pushing 2,000+ FPS on my machine with something like 3-4k vertices, with heavy texture mapping and anti-aliasing. But the problem was that even with peak optimization, the CPU was spending 15-20% of its time every frame recreating the UI's vertex buffer. Now imagine if we had done a retained-mode GUI instead. That 15-20% overhead would be reduced to near 0% on a typical frame. For nearly any type of game, that kind of savings is really significant. Think of how many more vertices your artists can add, or cool gameplay elements you can add that you didn't have the CPU time available before, and how much better it will run on lower-end hardware.

Why settle for "good-enough" performance?

<comment><USER43> > The CPU was spending 15-20% of its time every frame recreating the UI's > vertex buffer.

Not saying it is easy, but it's possible to optimize and cache vertex buffers by using something similar to React's VDOM.

<comment><USER60> Doesn't your cache just become a limited retained mode with a somewhat hacky, opaque API?

<comment><USER61> Basically yes. If an immediate mode API is much easier to use, and a retained mode underlying implementation has much better performance, then putting a React-style VDOM layer in-between could get the best of both worlds, depending on how well the middle layer is implemented.

</comment></comment></comment></comment></comment></comment></comment><comment><USER62> So basically go back to WM_PAINT

<comment><USER54> Not really, it is a go back to mode 13h.

</comment></comment><comment><USER63> No. ImGUI could not be the future of GUIs.

GUIs are multi-process, multi-system, multi-clock, multi-network entities, or at least they have the potential to be. Immediate Mode GUIs are almost non- scalable by design.

Imagine a multi-system asynchronous AR collaboration environment. Now imagine that as an Immediate Mode GUI. If we had enough horsepower to do that, we'd be doing something far better with it.</comment>


What killed my iPhone app sales? - <AUTHOR>

Hello HN,
I am an iPhone developer with two apps in the App Store and the question I had is what did I do wrong? My apps Wedding Songs Planner - First Dance and Weddings Songs Planner - Professional are a free and paid version of the same application. This app will help brides and grooms create the perfect playlist for the songs during their wedding.
Originally, I had only put out the paid version of the app. After one marketing campaign and few wedding blogs posting about the app I had sales at about 5-10 apps per day. Which is not great by any means, but it was at least fairly consistent. In an attempt to get more downloads and sales, I decided to put out a BIG update to improve the user interface and the overall functionality of the app. Along with this update, I put out a free version of the app with reduced functionality in the hopes of converting some users to buy the paid version.
After some issues with Apple accepting the updates, the app was finally updated and released. The problem was that the sales DROPPED to levels that I hadn't seen since before any blogs had picked it up and some days I was seeing 0 sales. The main points that I could see that might have caused this were:
- A name change: Wedding Songs Planner to Wedding Songs - Professional
- An icon change: What I had thought was a much improved looking icon but may have blended into App Store more.
- Overall look: The overall look was much improved but maybe the audience did not agree.
Once the free version was approved I released it in the App Store, sales did not go up. I tried reducing the price to $0.99, sales did not go up. I tried changing the border to red, sales did not go up. I changed the name back to Wedding Songs Planner - Professional which may have helped.
The price is back up since the sale did not help increase downloads. I'm hoping the name change was main problem but now that my app has dropped in the App Store it will be hard to bring it back up to where it can be noticed.
This is a cautionary story, sometimes when you think something is an improvement, the market doesn't agree. Test things before putting them out!
If you have time, please check out the free version of my app
http://itunes.apple.com/us/app/wedding-songs-planner-first/id497832316?ls=1&mt=8 and if you have comments good or bad leave them for me!
If you want to contact me directly please send me an email at firstname.lastname@example.com
Thanks,
Jeremy Jacques <comment><USER2> I think Wedding Songs Planner[ - Professional] is a much better name than Wedding Songs - Professional. It much better says what the app does, as the second name sounds like it's just a list of wedding songs.

It's hard to comment on the icon and look, since we haven't got access to the old app listing.

<comment><AUTHOR> heres a link of what the previous version looked like

[http://ruffledmedia.ruffled.netdna-cdn.com/vintage- wedding-b...](http://ruffledmedia.ruffled.netdna-cdn.com/vintage-wedding- blog/iphone-wedding-apps.jpg?b03aa7)

</comment></comment><comment><USER3> When you first release, you get a boost of exposure by being on the new releases list. Now that your off, you need to find a way of either being visible on the app store or getting attention outside of it. Both are very hard, million dollar questions.

<comment><AUTHOR> good point but we had already been in the App Store for 4 months, sales were actually increasing right before the update. The update came and the sales bottomed out.

</comment></comment><comment><AUTHOR> good point, I'll add a link to the old icon and screenshots</comment>


Use-Case 2.0 - <AUTHOR> http://queue.acm.org/detail.cfm?id=2912151 <comment><USER2> So this is going to take some time to read and process but I'm not convinced people should (I mostly skimmed). It's essentially another methodology for getting work done that, like all the others, are so close to how each other work it may not be useful to really understand or switch between any of them. Even if you use this methodology I'm not convinced it's useful or helpful to understand all the intricacies of it.

For example their section on how use cases and user stories differ are vague and generic. It explains how user stories and use cases are similar but how they differ is simply a list of generic, non-useful tripe such as "flexible", "better", "easier", "increased understanding", "easy focus", etc.

I left this article not knowing if this is just a slight re-branding of every other methodology out there nor any compelling information saying why I should or should not use this one over others. Granted I didn't read the entire thing but I read the beginning, end and skimmed the middle. You should be able to convey your value in the first few sentences if you want people to use your methodology. In my opinion anyway.

I get in big teams you need _some form_ of process but I feel like if your process takes longer than a page to articulate then it's never going to be followed and is a waste of time.

<comment><USER3> i agree, mostly. i had a hard time figuring out what the 2.0 part about it is. if it's just about the slice, then i feel like the author is talking about it from a perspective of where project/feature planning is being done wrong.

i wasn't particularly confused with the terms use case vs user story, but if i didn't know those concepts already, the article would not have explained them to me.

(fwiw a use case is a series of steps that a user must take to complete an action, but a user story is usually a sentence told from the viewpoint of the user such as "as a user, i want to log in so i can add a new post")

</comment></comment><comment><USER4> My take, is that this primarily attempts to address one of the key criticisms of use cases - the granularity issue. Use cases are often too broadly written initially. When examined closely, one discovers that that the use case presented really needs to be broken down into many more detailed (and changed) cases.

The introduction of "slices" appears to acknowledge that. The problem is that like functional decomposition in structured programming, constant re- arrangement of the functional "tree" representing the problem will likely result.

</comment><comment><USER5> To put this in a slightly more recognisable context, Use Case design is where Bob Martin's Architecture: The Lost Years talk sprung from; you can draw a line from there to the Hexagonal Architecture ideas that were floating around at the time.

</comment><comment><USER6> We have finally come a full circle. Agile UML and IBM Rational Scrum are just around the corner

</comment><comment><USER7> See also the whitepaper of use-cases 2.0: [https://www.ivarjacobson.com/publications/white- papers/use-c...](https://www.ivarjacobson.com/publications/white-papers/use- case-ebook)</comment>


Seeking: Side project co-founder/developer - co-founder I'm looking for a seasoned developer who is ready to start tinkering on something on the side.
Who I am: I'm a product designer with experience ranging from startups to large corporations.
While I'm content at my current job, I'm just not totally satisfied. I'm cursed with the need to always be building and creating, and for as long as I've tried to shake that feeling, I've finally come to terms with the fact that it isn't going away. It's time for me to start something new.
In the past, I've worked as a UX designer, a front end developer, and I've even run my own (VC-backed) startup.
What I want to build: Some of my areas of interests include "big data" (apologies for using that phrase), B2B software, and even home automation. I'd prefer to build something where users actually pay money for a service, as opposed to just growing an audience.
I have a few ideas, but I'd love to hear yours, too.
Next steps: If this sounds interesting to you, I'd love to hear from you, along with what you might be interested in building.
Email me: email@example.com <comment><AUTHOR> can you tell us a bit more about yourself ? What was the VC-backed startup that you ran ? What were the outcomes and what did you learn from it ?</comment>


Drape – a Fabric Simulator - <AUTHOR> http://aatishb.github.io/drape <comment><AUTHOR> Hi, thanks for voting this up! I created this with a few colleagues. Our goal was to make a fabric simulation tool that might inspire creative exploration among artists and engineers. I hope you find it fun to play with, and welcome any feedback and suggestions on how to improve this.

We started from a three.js cloth simulation example and made a bunch of modifications. The cloth is modeled as a grid of point masses (particles) connected by springs. We've got options for horizontal & vertical springs (simulating cross grain, where the cloth threads run parallel to the edges), diagonal springs (simulating bias grain, where the cloth threads run diagonally), and springs that connect particles two units apart (simulating drape / bending stiffness, similar to a starched tablecloth). It's kind of amazing how a simple system of particles and springs can result in such rich cloth-like behavior. Other than the springs (which are modeled as constraints on the distance between particles), the only forces on the particles are wind and gravity. In addition we have constraints that account for collisions and simulate friction-like behavior.

We've submitted a paper that explains the details of how this works which I'll share once it's published, but for now if you're interested in learning more here are a few references, or google 'verlet integration constraints'. Also happy to try to answer your questions.

[https://graphics.stanford.edu/~mdfisher/cloth.html](https://graphics.stanford.edu/~mdfisher/cloth.html) [http://www.pagines.ma1.upc.edu/~susin/files/AdvancedCharacte...](http://www.pagines.ma1.upc.edu/~susin/files/AdvancedCharacterPhysics.pdf) [http://kucg.korea.ac.kr/education/2005/CSCE352/paper/provot9...](http://kucg.korea.ac.kr/education/2005/CSCE352/paper/provot95.pdf) [http://luthuli.cs.uiuc.edu/~daf/courses/Games/SimList/Papers...](http://luthuli.cs.uiuc.edu/~daf/courses/Games/SimList/Papers/Baraff-1998-LSC.pdf)

<comment><USER2> Turning on "no self intersect" produces much more realistic-looking results; any reason you don't have that on by default?

<comment><USER3> I'm not the author, but enabling NoSelfIntersect totally ruined the frame rate for me. I was barely able to open the controls to disable it again. It's possible it's not on by default as a performance consideration.

<comment><AUTHOR> Yup, that setting is implemented in a somewhat naive way. The way it works is that I iterate through every pair of points on the cloth, check for when they get too close, and if they are, I introduce a spring to push them apart. So effectively this introduces a short-range repulsive force between pieces of the cloth.

Avoiding self intersections results in more realistic cloth behavior like folds and wrinkles. The problem is, iterating through all pairs of points comes at a computational cost, and can really drop the frame-rate, particularly for large cloths. So I decided to keep this setting off by default until I have a smarter way to implement this (e.g. using quadtrees).

</comment></comment></comment></comment><comment><USER4> This is neat as a personal project restricted to WebGL and real-time.

The state-of-the-art in commercially available cloth/clothing creation simulation these days is Marvelous Designer and it is available for ~$400. It does produce results that are pretty phenomenal and hard to tell from real- life.

[http://www.marvelousdesigner.com](http://www.marvelousdesigner.com)

[http://www.marvelousdesigner.com/product/features](http://www.marvelousdesigner.com/product/features)

[http://www.marvelousdesigner.com/cases/](http://www.marvelousdesigner.com/cases/)

<comment><USER5> Their collisions are ok... I like this stuff from Disney: [https://www.youtube.com/watch?v=uHfQL5UjXhk](https://www.youtube.com/watch?v=uHfQL5UjXhk)

Those knots are gnarly!

<comment><USER4> That is beautiful. This one also impressed me, modeling individual yarns: [http://www.gmrv.es/~gcirio/pdf/YarnLevelWovenCloth_SIGASIA20...](http://www.gmrv.es/~gcirio/pdf/YarnLevelWovenCloth_SIGASIA2014.pdf)

</comment></comment></comment><comment><USER6> Dynamic fabric is something I'd love to see more artists working with.

So far the most impressive example I've seen is ZEITGUISED's geist.xyz: [https://vimeo.com/150824660](https://vimeo.com/150824660) Undulating impossible fabrics with photo-realistic shaders (and a soundtrack that makes my head hurt).

It's definitely an experimental art film but it feels more like an impressive tech demo for what they've been able to accomplish with textile simulation. Sadly like most art pieces, there's very little in the way of technical on how they pulled off such interesting stuff.

<comment><USER4> > Undulating impossible fabrics with photo-realistic shaders

I am fairly sure they were not using custom software, rather off the shelf tools for both rendering and simulation.

</comment></comment><comment><USER7> That's pretty cool! Do you have any plans to have it respect the boundaries of solid objects it comes in contact with such as the poles it's tethered to? Currently, the cloth will go through the poles instead of interacting with the poles as solid objects.

<comment><AUTHOR> I'd started off this project by using a fancier ray-tracing method of detecting and avoiding collisions with arbitrary shaped objects. Unfortunately it was just too slow for satisfying real-time performance. So finally, I went with doing the collision detection in a case-by-case way for more simple shapes (ball, table, etc.). The poles would be easy to add as an option, I may try to add that in. Thanks for the suggestion!

</comment></comment><comment><USER8> I wish I had more knowledge of the math behind it. Is it done by solving multiple partial differential equations using finite difference method?

<comment><USER9> Probably some form of verlet integration: [http://gamedevelopment.tutsplus.com/tutorials/simulate- teara...](http://gamedevelopment.tutsplus.com/tutorials/simulate-tearable- cloth-and-ragdolls-with-simple-verlet-integration--gamedev-519).

Author's github page also has links to a list of cloth simulation resources.

<comment><USER10> That might be what the physics engine does, but the demo is just using a physics engine to build a constrained array of particles with springs.

</comment></comment></comment><comment><USER11> I disabled cross-grain and drape and it billowed and exploded: [https://twitter.com/eigenbom/status/738887973559668736](https://twitter.com/eigenbom/status/738887973559668736)

Not sure if bug or if those parameters are not in the space of valid options.

Cool project btw!

<comment><AUTHOR> Haha nice! Try that in wire-frame mode and it looks even crazier: [https://twitter.com/aatishb/status/727270083601551360](https://twitter.com/aatishb/status/727270083601551360)

I left that in as allowable behavior, because our goal with this was not necessarily to model a realistic cloth but more to experience interesting and unusual movements and behaviors. So glitch away!

</comment></comment><comment><USER12> Reminds me of an old PhysX demo I found in a game years ago.

Can't seem to find much besides this video though: [https://www.youtube.com/watch?v=eoCbSL2kis4](https://www.youtube.com/watch?v=eoCbSL2kis4)

</comment><comment><USER13> I think I posted this last time this link was shared. But just yesterday I uploaded my code to github after a request on the video.

It is cloth with tearing and verlet integration. Nothing fancy or even difficult but it is probably a nice starting point.

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

Code: [https://github.com/jontelang/VerletClothTearing](https://github.com/jontelang/VerletClothTearing)

</comment><comment><USER14> As a note: this works for me in Chrome 51, but Pale Moon 26 and Firefox 46 both reported that my GPU seems to be incapable of WebGL, when I first tried it. I had to force it to be enabled in my about:config settings, after which the demo displayed nicely.

I'm not sure if there's something that I've done wrong, or what.

</comment><comment><USER15> Very nice. Turn on "No self intersect", or the cloth keeps going through itself. Turn off "Wind" to see it come to rest.

</comment><comment><USER16> Could've used a warning, my shitty i3 laptop went to 80°c

<comment><USER17> Interesting. It works great on my iPad Mini 4 on Safari. Maybe the problem is either the browser or your graphic drivers, not the CPU.

<comment><USER16> It's an old laptop with an integrated GPU running Ubuntu so it's a combination of all.

<comment><USER18> >old laptop

Last time you cleaned it?</comment></comment></comment></comment>


Folding At Home Now More Powerful Than World's Top Supercomputers, Combined - <AUTHOR> https://www.tomshardware.com/news/folding-at-home-worlds-top-supercomputers-coronavirus-covid-19 <comment><USER2> Moderatorbot broke the headline.

Should be: "Folding@Home Now More Powerful Than World's Top 7 Supercomputers, Combined"

</comment><comment><USER3> Why is it comparing against the linpack performance of supercomputers? The folding@home network wouldn't even come close to Summit on that benchmark. Its internode communication latency is measured in full seconds.

</comment><comment><USER4> Rookie mistake: It's not just about the FLOPS, the interconnect matters too.

There is a reason why everyone builds super computers in a large local cluster. It's so they can have a high-bandwidth low-latency interconnect between all of the compute. The second you need to shuffle partial data results between compute nodes, you have to pay the latency hop. Interconnect quality is often a huge bottleneck, ignore it at your peril.</comment>


Open mailto: links in Gmail - <AUTHOR> http://blog.monstuff.com/archives/000238.html

<comment><USER2> Hey, that's A BIT old. May 2005? Firefox already supports this with minimum configuration required, much less Greasemonkey scripting.

</comment><comment><USER3> Safari supports using gmail as your mail client. I just wish I could get mobile safari to do the same.

<comment><USER4> How do you configure that?

<comment><USER3> I was slightly mistaken. It works because I have Gmail Notifier installed. It sets OS X's default mail application to Gmail.

</comment></comment></comment><comment><USER5> the google gmail notifier takes care of that, as well as having a bunch of other features.

<http://toolbar.google.com/gmail-helper/></comment>


Gist: Docker and Nginx with dynamic virtual host - <AUTHOR> https://gist.github.com/morgangiraud/9c49d596991dbb47be6b52bfa3bce862 <comment><AUTHOR> Hi people, OP here,

I finally find a solution with docker for mac to have an easy way to plug different virtual host to my Nginx on OSX dynamically.

Feedback welcome!</comment>


White Pages May Go Way of Rotary-Dialed Phone - <AUTHOR> http://www.nytimes.com/2010/05/08/nyregion/08verizon.html?hp <comment><USER2> It's about time. I haven't cracked a phone book in 7 years, but I've thrown out about 10. They are not small books. (Kansas City)

<comment><USER3> Likewise. Last time I used one to look up a person was probably around 1992-1994 - though I actually used the yellow pages (to find an emergency HVAC repair person) in 2003. I started getting free 411 service with my cell phone in 1998, so I'm pretty certain I've never used the white pages after that.

I was in a cab recently, and asked him if he advertised in the Yellow Pages - he looked at me like I was a martian - "Everyone uses Google" was his feedback. (I'll admit that iPhone + GoogleMaps + Search is a pretty good replacement for the Yellow Pages - It's all I ever use now )

</comment></comment><comment><USER4> Why has this taken so long , why is this not self-evident ?

</comment><comment><USER5> Over the last few years I've grown more and more into the idea that the makers of white/yellow pages ought to be charged with littering for distributing their unnecessary, unwanted, and unused phone books to everybody's doorsteps.</comment>


Ask HN: Alternatives to Shazam? - <AUTHOR> In the last year Shazam has become very unreliable for me, particularly on classical music.<p>Any alternatives out there...? <comment><USER2> Can't vouch for their accuracy on classical music, but SoundHound[1] and Midomi[2] might be worth a try.

[1]: [http://www.soundhound.com/soundhound](http://www.soundhound.com/soundhound)

[2]: [https://www.midomi.com/](https://www.midomi.com/)

</comment><comment><USER3> Try asking Siri or Google Assistant "what song is this?"

<comment><USER4> I wouldn't bet on Siri doing better. Apple bought Shazam in December 2017 ([https://www.cnbc.com/2017/12/11/apple-confirms-shazam- deal-b...](https://www.cnbc.com/2017/12/11/apple-confirms-shazam-deal-buying- music-recognition-app.html)), completing the deal in 2018 ([https://www.apple.com/newsroom/2018/09/apple-acquires- shazam...](https://www.apple.com/newsroom/2018/09/apple-acquires-shazam- offering-more-ways-to-discover-and-enjoy-music/)), so Siri likely uses Shazam under the hood.</comment></comment>


India might ban VoIP calls  - <AUTHOR> http://latestgeeknews.blogspot.com/2009/09/india-might-ban-voip-calls.html

<comment><USER2> This is people who don't understand the internet trying to apply rules to the internet.

</comment><comment><USER3> I have a hard time believing India will randomly nuke all of their call centers and IT shops in one fell swoop.

<comment><USER4> That is exactly what bad governments do. And it is exactly why the developing world is poor, because of bad governance. Not because of some other inherent quality of the climate, geography or people, but simply because of crap like this. Stuff like this is sadly in no way unique to India.

</comment></comment><comment><USER5> Bad side of this: Call costs will go up.

Good side of this: Costs of setting up a call center in India will go up!

</comment><comment><USER6> The incompetence of India's Intelligence Bureau knows no bounds.

Anyone remember last year's Blackberry ban fiasco ?

<comment><USER7> and before that, the blogger block (revoked after an uproar. there are some advantages to living in a democracy).

</comment></comment><comment><USER8> Just about when Vonage announced that all calls to India is included free in the plans ... sucks!

</comment><comment><USER9> This is a threat: authorities say this sort of thing to get the interested parties around that table to talk. This does not make the service out-of- touch, just it gets people to take notice. This strategy worked with the Blackberry, the company agreed to work with the security authorities.

What this means for privacy though is a different matter.

</comment><comment><USER10> I think the main reason is exactly this: the local telcos don't earn money on voip telephony. India is looking to increase income - being able to bill phone calls is definitely desirable for some people.</comment>


Ask HN: What to use after SQLite? - <AUTHOR> All
I love SQLite and use it to for a client/server web app. I'm fully aware it's designed for embedded application use but the developers encourage you to use it for client/server task if the concurrency is relatively small. [1]
My web app has grown and I'm now running into currency issues.
What do you recommend to replace SQLite?
I love the simply, how small it is (code base, install, resources) and focus on being bug free of SQLite.
But am worried that replacing SQLite with something like MySQL or Postgres is replacing SQLite with a slow and heavy tank.
Does anyone have any good recommendation on what database I should move to next?
[1] https://sqlite.org/whentouse.html <comment><USER2> If you're running into concurrency issues, than both MySQL or Postgres are good solutions. Tanks compared to SQLite? Yes. Slower? No.

But if you're looking into something small, check out Firebird ([http://firebirdsql.org/](http://firebirdsql.org/)).

It's fully ACID compliant relational database, can work both in embedded or client/server mode, fast, easy to maintain and cross platform. IMHO, the only drawback of that RDBMS is small(er) developer mindshare. I worked a lot with it before (8 years ago) and loved it.

<comment><USER3> 8 years ago I actually disliked it, because it was descendant of Borland's database and shared with it the administration tools and documentation. In both aspects it was worse than PostgreSQL or MySQL. I don't know if anything got better, because I haven't worked with it ever since.

<comment><USER2> Yes, Firebird came to the world after Borland's Interbase got open sourced. After that, Borland continued with Interbase development and they kinda existed for a while. I have no clue what happened to Interbase afterwards, as I've stopped caring.

As a former Delphi developer, I also dislike Borland. But I very much loved their products, no reason I would dismiss one just because it was made by Borland (and I'm talking about "new" Borland, not the Borland of the 80es and early 90es which was awesome).

<comment><USER3> It's not that I disliked Firebird because Borland. I disliked it because tools and procedures (mainly the latter) were underdocumented and felt unpleasant to work with from a sysadmin's perspective compared to PostgreSQL and MySQL.

At that time I didn't care about Borland for a long time already, because I was a Linux sysadmin then.

</comment></comment></comment></comment><comment><USER4> PostgreSQL, it also has the advantage, that SQLite is modelled after pgsql, so porting is going to be slightly easier than MySQL.

Also, both of them (MySQL and PostgreSQL) can handle an enormous amount of concurrent work at very high speed.

Unless you are relying on optimizing nanoseconds in response time, you will never feel the difference...

</comment><comment><USER5> SQLite has an option to use a different commit/rollback mechanism called the Write-Ahead-Log. It can alleviate some of the concurrency issues in certain workloads. [https://www.sqlite.org/wal.html](https://www.sqlite.org/wal.html)</comment>


Which Tech Leaders Do Tech Professionals Admire? Elon Musk Heads the List - <AUTHOR> https://spectrum.ieee.org/view-from-the-valley/at-work/tech-careers/which-tech-leaders-do-tech-professionals-admire-elon-musk-heads-the-list <comment><USER2> When you see Zuckerberg as number four on the list, you begin to question the study.

<comment><USER3> Musk as number 1 already made me question this study and humanity.

<comment><USER4> Not trolling- why do you think that?

<comment><USER5> Musk is the closest we have to a trump-like personality in tech. Some similarities between them include but are not limited to those below. And I can expand on each of them.

1) Picking fights and raising conspiracy theories on Twitter, just like trump. This is bad since Twitter enhances mob mentality even more than fb does, by having a vocal monitory drive all communication. Elon musk constantly gaslights his fanbase against big oil, malicious shorts, stealerships, sabotage against SpaceX, and encourages them to dox skeptics.

2) He personally participates in such activities. He personally had the doxxed skeptic threatened about losing his job. He also called the British diver who helped rescue Thai kids a pedophile, then doubled down on it while emailing a journalist, and then bet a signed dollar on it.

3) He also lies constantly, just like trump. In the case against musk by the diver, he claims that he used pedo only to call him an old person, and didn't mean the opposite. Inspite of the fact that he doubled down and bet on it.

4) Calling news he doesn't like as fake instead, just like trump. Elon musk literally said that and proposed a journalist ranking system called Pravda. When a website like electrek criticizes Tesla, he blames the author to be suspiciously biased against Tesla.

5) Behavior not suitable to his position, just like trump. It may be "4 Ford CEO in 3 years", or "420$ funding secured. Short burn of the century!"(oh another lie), Or just smoking weed on a podcast.

6) Constant stream of lies about capabilities and over-exaggeration in general, just like trump. Self driving was apparently solved in 2015, and we were going to have cross country summon in 2016. Then coast to coast autonomous drive in 2017. Then fsd with driverless taxis in 2018. Where are we now? Will they ever own up to false marketing and the shortcomings of autopilot? This extends beyond Tesla to SpaceX, boring company, neuralink, openai, and well anything Elon musk touches.

7) And finally the cult around his geniusness, just like trump. Ironman personified! The Tesla of our generation! He's never wrong. Let's dump public transit because it's costly (60 billion for high speed train), because Elon musk said he can make high speed trains in a vaccum tube for 6 billion! Sometimes, this fanbase is just pathetically stupid.

<comment><USER4> Thanks for responding. To be honest, I'm a little underwhelmed by the list which mostly relies on likeness-to-Trump as an indictment, as opposed to focusing on the reasoning.

The reasons themselves are a bit flimsy: Too erratic on Twitter, acting in his own self interest, over-promising things... I've forgiven people for a lot more than that.

Number 7 isn't even a reason not to like him, it's just your frustration that people _do_ like him.

<comment><USER5> Flimsy? Will musk lost your vote if he shoots someone on fifth avenue?

</comment></comment></comment></comment></comment></comment><comment><USER6> Makes sense. He founded a tech company with his brother, got super rich, reversed his balding, got super sexy, and now builds rockets and fancy cars.

</comment><comment><USER7> When I was a kid, the magazine that came with the Sunday paper would once a year give a list of the world's most admired persons. The first time I read one, I couldn't understand the criteria, and asked my parents. They said, Oh, it's about name recognition--people start fishing their memories for names, and the overlap polls highest.

</comment><comment><USER8> So, with a few exceptions, making a few billions of dollars through some less than ethical shenanigans makes you admired by the Hired crowd.

Good to know.

</comment><comment><USER9> Why is Jack Ma anywhere near this list.

<comment><USER10> Worthington's Law: [https://www.youtube.com/watch?v=y6WEo9Ix_7Q](https://www.youtube.com/watch?v=y6WEo9Ix_7Q)

</comment></comment><comment><USER11> where is Torvalds?

the hell, where is Sergej Michajlowicz Brin?

<comment><USER8> Brin isn't of Polish descent, so "cz" would be an unusual transcription.</comment></comment>


Beat procrastination with Kaizen - <AUTHOR> http://vitomd.com/blog/coding/beat-procrastination-with-kaizen/

<comment><AUTHOR> I knew how kaizen gave great result to japan industry, but in this book it tell you how to apply the same concept to your daily life. It's great to beat procrastination and really easy to follow. Give it a try</comment>


Actually Reading the Facebook Feed Patent - <AUTHOR> http://ynniv.com/blog/2010/02/looking-at-facebook-patent.html <comment><USER2> If you look at the file history of the patent application (which you can get from <http://portal.uspto.gov/external/portal/pair>), you will see that the patent was allowed only after adding the "where the link enables a viewing user to participate in the same activity" limitation. It is mentioned in the Interview Summary.

<comment><AUTHOR> This is an excellent resource that I was unaware of. That limitation was not present in the 8-19-2009 claims, but was in 12-16-2009. I made a cursory glance over the documents available on PAIR, but was unable to find the examiners specific rejection that caused them to add this. There are a lot of references on this application, tho.

<comment><USER2> Look at the 12/14/2009 interview summary (an interview is where the patent applicants talk to the examiner), and in particular the third page.

</comment></comment></comment><comment><USER3> I guess I'm failing to see why this doesn't apply to a whole bunch of generic social activity feeds. Github's activity feed, for example, seems to fall under the patent. What am I missing?

<comment><AUTHOR> Does clicking a github news item cause you to also make a commit?

And realize that if github and other social networks have similar features that were added after 2006, they are infringers, not prior art.

<comment><USER3> You are referring to this clause, correct?

 _"attaching a link associated with at least one of the activities of another user to at least one of the plurality of news items where the link enables a viewing user to participate in the same activity as the another user"_

The github news feed includes notifications of comments, and there is a link that can be used to go to the comment page and also comment. As I'm reading clause, the link itself doesn't need to actually cause an action, and the link in that github news item "enables a viewing user to participate in the same activity as the another user."

Also, you can edit and make commits from the web interface, so this could fall under this as well.

<comment><AUTHOR> _The github news feed includes notifications of comments, and there is a link that can be used to go to the comment page and also comment_

Ah, that would likely infringe. They could easily get around this by removing the direct link to comment and having users view the comment thread before commenting. Or have a text box instead of a link, where the user would enter their comment directly in the news feed.

</comment></comment></comment></comment><comment><USER4> Did you know having read a patent could increase the damages if you are later found to infringe it?

Most bad patents die in obscurity, never enforced, never discussed -- which is as it should be.

The best thing to do if you hear informally about a dubious patent is to ignore it -- don't promote it, don't mock it, and for god's sake don't study it.

Of course, if your professional patent counsel tells you otherwise, for example after you are specifically alleged to infringe by someone with the power to prosecute, that's different. In the meantime, amateur patent kibbitzing only helps the trolls.

<comment><AUTHOR> Yes, knowledge of a patent could increase damages if you are found to be infringing. However, ignorance of all patents causes Fear Uncertainty and Doubt at the slightest mention of the an overly broad patent title. Knowledge of the patents in your field is the only way to avoid infringing them. I used to believe that ignorance was the better path, but that only leads to you being sued over something you were unaware of. Now I opt to avoid being sued in the first place.

<comment><USER5> That works if it's actually possible to avoid infringing all overbroad patents. But the USPTO's bar for "novel and non-obvious" is so absurdly low that I don't believe we can assume they left us any gaps in the minefield.

<comment><AUTHOR> True. Throughout the blog post and comments here, I never mentioned that I am not in favor of software patents, but I absolutely agree. That said, there is usually some way to weasel out of the shadow of a patent, and being sued for a smaller outrageous amount isn't as useful as not being sued at all.

</comment></comment></comment></comment><comment><USER6> This sounds very much like it can apply to twitter.

@foobar said cool. <reply button> <retweet button>

That's an activity that can be public or only be viewed by your friends. People can participate by doing the same activity (retweeting or replying).

This also applies to google buzz, myspace, hi5, github comments, linkedin and tons of other services. It looks like the OP should re-read the patent.

<comment><AUTHOR> _It looks like the OP should re-read the patent._

Thank you freetard, that was insightful.

 _That's an activity that can be public or only be viewed by your friends. People can participate by doing the same activity (retweeting or replying)._

In this patent, "News Items" are different from status updates, which would be considered "actions". The related art section of the patent discloses that users of social networks can already see direct actions of other users, and the utility of this patent is to filter this list to dampen the noise. A more apt example would be twitter providing a list of people who have been recently followed by people that you are following, with the option of clicking the news item to also follow this new person.

<comment><USER6> > A more apt example would be twitter providing a list of people who have been > recently followed by people that you are following, with the option of > clicking the news item to also follow this new person.

How would that be more apt? In twitter you can make your account private, so only a few selected people can see your actions.

Also a retweet, a reply or even a tweet are all actions (the action to retweet, reply and tweet ie say something).</comment></comment></comment>


Apple's Mistake (2009) - <AUTHOR> http://paulgraham.com/apple.html <comment><USER3> I don't know if I can agree with this essay. I've found the App Store review process has helped me as a software developer, and has helped my customers.

I've learned to take the rejections positively, and in many cases it has improved the quality of my software. Two cases specifically come to mind:

\- Apple rejected an app for not putting in battery usage warnings when the app made use of background location

\- Apple rejected an app for including placeholder artwork for in-game achievements

In the cases where I felt I was right, I have almost always been able to argue my point with the reviewer and was allowed through. This has been the case both for policy issues and software design.

That said, there have been moments of pain. Like when I was involved in a trademark dispute and was required to rename my app. Apple delayed the process a lot, causing the other party to become concerned (eventually Apple approved the update but it caused some tension). I think Apple has since improved their review mechanism to handle cases like this (e.g., now including the option "Is this update being submitted for legal reasons, such as copyright or trademark infringement?")

It sometimes feels like software developers think they should be above judgment; that they should be treated as first-class citizens and not their customers. I personally prefer Apple's approach. Though I'm glad there are platforms which cater to both sides.

<comment><USER4> The review process _can be_ great. But it can also suck. I'm sure you've read the horror stories. I won't reiterate them, but will say that I've been involved in some personally.

I don't think it's worth the tradeoff.

I'm glad there are platforms which cater to both sides, but I wish the _all_ did. There is no reason iOS couldn't have the curated, reviewed, controlled App Store _and_ the ability to sideload whatever apps you wanted, for those of us who don't want Apple deciding what we can or cannot run on our own hardware.

<comment><USER3> I wonder about being able to sideload — because I sell a relatively expensive app on the App Store (at least, expensive in App Store terms: $10).

If sideloading were possible I wonder if it would increase the piracy rate for my app, on which I make a living.

Personally, I would love to do away with the certificates and signing and be able to run whatever. But I wonder if it would hurt my business. I realise that piracy is already possible, but I suspect any form of sideloading makes it a far more accessible option.

Edit: as I said, I'm pretty aware of the sucky bits. My review process (expedited!) went on for _months_ while the trademark dispute played out. It was an incredibly anxious time.

<comment><USER5> There is a 3rd option here:

Allow apps to bypass review. These apps will be hosted on Apple and charged the 30% fee, but they will not be indexed and not be displayed in any way on iTunes. You will have to have a direct link to buy them and download them.

</comment></comment></comment></comment><comment><USER6> Four years and change later the central thesis that developers will abandon Apple en masse because the App Store is a great crime against programmers rings hollow. iOS is still the first target for many developers and for those where it isn't, they're more likely following the enormous Android userbase most of which Apple doesn't even compete for. I'm sure it has cost them some developers but the short list of big time Android first apps tells you the score.

At the end of the day hot dog vendors sell hot dogs in highly regulated NYC because people in NYC buy hot dogs. Companies sell their goods to Wal-Mart and Neiman Marcus instead of at the flea market because that's what keeps the lights on. Small publishers work with Amazon despite horrible terms because it puts steak on the dinner table.

One thing this article reminds us of it that pg has the not uncommon HN blind spot for Google who he claims has "remained true to their founding principles". I guess stabbing a close partner in the back by releasing a clone of their flagship product is not being evil. I wonder if he's also a fan of the Samwer brothers?

<comment><USER7> _" I guess stabbing a close partner in the back by releasing a clone of their flagship product is not being evil."_

What is the product you're referencing?

<comment><USER8> Steve Jobs would say the iPhone

<comment><USER7> I guess that's what OP was referring to but how is it surprising that a major tech company was getting into the mobile device business? Even Amazon created a tablet.

<comment><USER9> Their early versions looked closer to a blackberry. The general Jobs assertion is that Google switched to full touch screen after seeing the prototypes.

</comment></comment></comment></comment></comment><comment><USER10> 2009 seems like yesterday, it's crazy how different the world was merely 5 years ago.

Since then, Android has certainly grown into an _viable_ competitor to the iPhone, though it's still far behind in many ways, _particularly_ developer adoption and the high end of the market (which is by far more profitable).

Apple has also gotten a bit better and faster in app approval from what my friends say. Still, the iPhone is a _lot_ less hackable than especially the _nexus_ phones. It's still bewilderingly hard to test an app with real people (I'm writing my first iOS app right now and so wish I could just email an apk to even 5 friends). I know many get around this surreptitiously using the "enterprise" program (my hunch is Apple knows but quietly lets it slide knowing that a lot of the best developers do this).

Compared with rooting an android, jail breaking an iPhone seems more risky and less effective. And Apple seems to have succumbed to carriers wrt banning tethering apps not only from the app store, but also in code (from what I hear, haven't had the chance to see if it's possible yet).

 _However_ , there are a lot of reasons startups still start with iOS and leave android as a second thought:

1\. iOS users actually _buy_ apps, use them, and spend money in them which is extremely rare amongst android users

2\. A _lot_ more iOS users have the latest OS and _enough_ also the latest hardware, which means you can do the coolest stuff the platform allows and (at least initially) not have to worry about deprecating well for legacy devices/OS.

3\. the devices themselves are (as pg wrote) _just too much better designed_ compared to to even the best android phones. I have a nexus 5 and iPhone 5s and slowly over time I pretty much only use the iPhone except when developing for android. It's _little_ things that cause this behavior, like being able to plug in the iPhone's power cord in the dark (since it's symmetric).

It's still too early to decide whether Apple's tight control is purely a good or bad thing. You could make a decent case either way.

<comment><USER11> >iOS users actually buy apps, use them, and spend money in them which is extremely rare amongst android users

So do Android users. Over a year ago iOS and Android phone apps were dead even in revenues. [1]

Android tablets are behind the curve still, but for the first time Android tablets are outselling iPads -- Android tablets took 62% of the market in 2013. [2]

It will take a while for that lead to actually cause Android tablet revenues to exceed iPad revenues, but it seems inevitable. So in eventually the Android tablet revenue numbers will match or exceed the iPad's as well.

>the devices themselves are (as pg wrote) just too much better designed compared to to even the best android phones

iPhones are nice, but they totally don't trump the features if that's what you care about. I have the Nexus 5 and I wouldn't give it up for an iPhone; the screen size alone makes a huge difference to me.

The Lightning connector is elegant. But I can buy a micro-USB cable for a dollar; a Lightning cable is at least $9. I can have extra cables everywhere I need one for next to nothing. And yes, getting the polarity wrong sucks, but having a standardized cable that works on ALL the devices I need to charge is even better.

It depends on what you care about.

[1] [http://www.forbes.com/sites/terokuittinen/2013/03/27/android...](http://www.forbes.com/sites/terokuittinen/2013/03/27/android- apps-closing-rapidly-the-revenue-gap-with-ios-apps/)

[2] [http://techcrunch.com/2014/03/03/gartner-195m-tablets- sold-i...](http://techcrunch.com/2014/03/03/gartner-195m-tablets-sold- in-2013-android-grabs-top-spot-from-ipad-with-62-share/)

<comment><USER8> >> iOS users actually buy apps, use them, and spend money in them which is extremely rare amongst android users

> So do Android users. Over a year ago iOS and Android phone apps were dead > even in revenues. [1]

That statement was new to me. I'm guessing it is specifically talking about revenue from ads, since the source of the quote works for an ad network. This discounts revenue from sales (which I believe is nearly nonexistent on Android), IAP (which drives major revenue for "free-to-play" games on iOS, but I don't know about Android), and subscriptions (who knows).

I also find the "Android tablets outsold iPads" interesting news. The breakdown of tablet by manufacturer shows Apple clearly winning (36%), Samsung #2 (19%), and everyone else below 6% with a large bucket of "Other" (31%). That's still a strong position for Apple at the high end of the market, and mirrors the smartphone market where Apple & Samsung make all of the profit.

I think Apple has staked out the premium devices, and will continue to be successful there. But, won't most of the growth come from global markets where their products are out of reach for most consumers? Where does that leave them, and can they afford to continue to ignore the rest of the market?

<comment><USER10> Most of the growth in smartphone _adoption_ will undoubtedly come from low-end devices. However, much of the growth _in profit_ will come from people moving into the segment that buys higher end devices and pay for apps/services.

</comment></comment></comment></comment><comment><AUTHOR> I submitted this because I just realized it's been half a decade since this was written, so if it's true then we should be able to see some evidence of whether or not Apple actually made a mistake. Has the essay turned out to be true? Mistaken? Or possibly true in the future?

And if Apple made no mistake, then what does that bode for the future of programming?

<comment><USER12> On the whole, it's tough to say. But parts of it were certainly prophetic. The rise of Android is, at least to a degree, testament to the fact that a lot of developers believe Android is a better platform.

This is a crucial passage:

 _" But Android is an orphan; Google doesn't really care about it, not the way Apple cares about the iPhone. Apple cares about the iPhone the way Google cares about search."_

Google ended up caring a great deal about Android. Maybe it didn't in 2009. Maybe it did, and it was just taking time to figure things out. But it's hard to argue now that Google doesn't take Android seriously. And now Android is a big threat to iOS.

In any event, I wouldn't say PG was wrong about this point. Rather, I'd say that hindsight is 20/20\. Android was in its infancy when PG wrote the essay, and he was correct in calling it out as a viable threat to iOS.

I don't necessarily agree with the "why" of it, though. Android's rise isn't really the result of arrogance on Apple's part. It's largely the result of two factors: 1) its distribution as a decentralized platform; 2) the price- competitiveness of Android devices. To the extent a lot of developers prefer Android to iOS, it's an opportunistic preference -- not a moral or philosophical one. Developers will go where the users are. More and more users are on Android. A secondary factor is that Android is an easier testing and deployment environment.

<comment><USER13> Android isn't a threat to Apple, Android just replaced the incumbents Blackberry and Nokia. There is no Android OEM that can go head to head with Apple in the market they compete in but Samsung (high-end phones), and even there Samsung is losing ground to Apple. Market share is only an important statistic because it may influence developers to focus on one platform or the other. But Apple had great developers and apps on OSX on smaller market share and a smaller install base, so there's no way iOS is going to stop being a developer focus. As for what concerns Apple and their business, as long as they keep selling more iOS devices every year than they did the last year, they don't really care how small their market share is.

Market share could get so tiny that developers decide to switch to Android- first, but as of now iOS still holds the crown. Without other metrics like user engagement turning against Apple, developers have no reason to be Android-first.

<comment><USER12> _" Android isn't a threat to Apple, Android just replaced the incumbents Blackberry and Nokia."_

I'd say it's entirely too early to call the ball here. The long game for both Apple and Google isn't limited to phones and tablets; it's to gain platform ubiquity across all devices, across all aspects of your daily life. Both platforms have a very strong horse in that race, and I'd have a tough time betting on one or the other right now.

</comment></comment></comment></comment><comment><USER14> I run a small game development studio in San Francisco. This still resonates with us. So much so that our most recent game is Google Play only, at least to begin with.

We can iterate on the product at near web-speed on Android. Our last game started on iOS first and at one point it had an update take 22 days to go through Apple's approval process. It was a complete black box to us - <USER2> was no reason given why it was taking so long and there was no one to contact regarding why. After not being able to submit a critical bug fix for 22 days to our players we decided that it wasn't the right place for us to launch on in the future.

So far I've been very happy with our decision to focus initially on Google Play. Launching first on that platform has allowed us to iterate on our latest game quickly, improving the experience continuously for players. Our players appreciate the quick improvements, and I'm not just talking about bug fixes here; we're also adding features to address player requests.

Once the rate of change slows we'll port it back to iOS.

<comment><USER15> I've heard that rapid-fire updates to Android apps can hurt rankings. Have you had any problems with this?

</comment></comment><comment><USER16> My impression of this is that Apple and Android still cannot 100% guarantee that your personal information is safe from apps, or that content is used as licensed. Apple's mitigation for this is aggressive curation of the Appstore, while Google attempts to automate this (there is a delay of a few hours), which is far more developer friendly. Hopefully over time Android and iOS will improve further and reduce information leaks in the platform, make granting permissions optional (no take it all or leave it), and perhaps add an ARM version of Intel's software guard extensions (SGX) so we can have mutual distrust between apps and the platform, and have the platforms be far more open by default.

</comment><comment><USER17> Way off the mark.

The number of independent iOS Developers that are out there, who make a great living building a few apps and supporting their users grows everyday. They didn't alienate Apple, they reaped the benefits of a well thought out system that works for everyone.

</comment><comment><USER18> I believe the process on Apple's side has improved significantly compared to four years ago.

</comment><comment><USER19> Unbelievable how we're still facing the same issues 5 years later.

<comment><USER20> That's because we're not.</comment></comment>


Automate Your Dating Life with 100 Lines of Python - <AUTHOR> https://elimernit.com/blog/auto-swipe/ <comment><USER2> This is the most Hackernews post title I've ever seen.

<comment><USER3> I bet this guy is still single.

</comment></comment><comment><USER4> This is good as a technical exercise, but poor as an actual solution to a problem.

Matching with potential partners is about showing interest.

If you're matching with many people, you likely won't be able to divide all your time between them at once.

If you're matching with people and not messaging them, it's similar to blowing them off or not showing enough interest.

This will have a negative impact on your dating life.

For anyone looking for love, I would recommend quality over quantity.

Just my 2 cents, and based on nothing more than my own experiences.

</comment><comment><USER5> When tinder had a webapp, not sure if they still have it, I've made a Chrome extension to swipe right.

I used to leave my personal laptop on with the thing enabled when I left for work in the morning. Got me plenty of matches, but not that many dates, since you need to engage in conversation very soon after the match, or the lady is going to lose interest.

</comment><comment><USER6> Don't you get banned if you automatically swipe right everything?

<comment><USER7> Seems like you could work around that by swiping right at random.

<comment><USER8> In which case you probably don't care about quality matches and begs the question why are you dating?

<comment><USER9> Do you really need the answer?

It starts with f..

<comment><USER10> fear of loneliness?

<comment><USER11> ...for unlawful carnal knowledge.

</comment></comment></comment></comment></comment></comment><comment><USER12> Tinder used to use the Elo algo (from chess) but apparently they don't use it anymore (I think they prob still use something like this)

[https://www.theverge.com/2019/3/15/18267772/tinder-elo- score...](https://www.theverge.com/2019/3/15/18267772/tinder-elo-score- desirability-algorithm-how-works)

<comment><USER13> Isn't elo pretty bad for subjective/multidimensional matters?

</comment></comment><comment><USER14> I remember I checked Hinge API a few years ago and the exposed their users last name. Wonder if this has been fixed by now.

</comment><comment><USER15> Hinge has unlimited swipes...</comment>


Useless but fun: encoding video as pure CSS background gradients - <AUTHOR> http://sandropaganotti.com/wp-content/goodies/demos/video2css/

<comment><USER2> Demo didn't work for me...but that's pretty interesting. Useless indeed, though.

<comment><AUTHOR> Have you clicked on one of the demo video links ? Which browser are you using (I'll try to fix it :D ) Thanks for the feedback :D

<comment><AUTHOR> Ok, now fixed (there was a problem on Firefox). Thanks for your feedback :D</comment></comment></comment>


Airtel,telecom provider in India breaking net neutrality and web censorship - <AUTHOR> http://www.reddit.com/r/india/comments/2qabsd/airtel_breaking_net_neutrality_and_web_censorship/

<comment><USER2> Thanks for bringing this up. Hate to see how unethical telecom companies across the world can be.</comment>


Ask PG: Would you put your house on Airbnb? - <AUTHOR>

Sorry if this question sounds snarky, but I'm genuinely interested if you would or not and the reasons why or why not.<p>(And my apologies if this question has been asked before in one of the other mammoth threads). <comment><USER2> I don't need the money, but if I did want to rent it out I would sooner do it through Airbnb than any of the other options.

</comment><comment><USER3> Great question. Fundamentally I would be sincerely interested in his take on the whole situation but given the contrversy & ongoing investigation I think it will be highly unlikely that he will make his position known any time soon and I can't blame him.

</comment><comment><USER4> Normally, Airbnb hosts exchange their property (plus a little house work) for some cash.

I doubt pg needs it.</comment>