Escape from Callback Hell: Callbacks are the modern goto - <AUTHOR> http://elm-lang.org/learn/Escape-from-Callback-Hell.elm <comment><USER2> If you don't want to use another language and compile down to JavaScript-- which is what Elm offers--there are some interesting options that are just JavaScript libraries.

The one I've personally played with is called Arrowlets[1], which introduces a control structure called an arrow that lets you abstract over callbacks and event handling (among other things). Using that style of programming can significantly simplify some fairly common tasks in JavaScript; the drag-and- drop demo on their site is a good motivating example. However, unless you are already familiar with functional programming and arrows, you should probably read some background before diving into the examples.

[1]: <http://www.cs.umd.edu/projects/PL/arrowlets/>

Another interesting option I've toyed with is RX.js[2]. This is a JavaScript version of C#'s Reactive Extentions (RX). If you are familiar with Linq, then this library's style should seem natural immediately. The core idea here is to abstract over events as streams that can be composed and manipulated conveniently.

[2]: <http://rxjs.wikidot.com/>

If you don't mind using a different language, but want something that mostly looks like JavaScript, another option is FlapJax[3]. I haven't tried it myself, but I've certainly heard good things about it.

[3]: <http://www.flapjax-lang.org/>

There are probably more options in the same vein that I forgot or don't know about. However, I think these three are a good starting point and could help clean up much of your event-driven JavaScript code in the short term.

Of course, if you are willing to use a language radically different from JavaScript, then Elm is a great option. Once you get used to functional languages with good type systems, there is really no going back ;). The syntax is also simpler and more minimalistic than JavaScript's, which leads to more readable code.

<comment><USER3> Promises are a good option as well: <https://gist.github.com/3889970>

Node.js had promises early on, then were removed, but they're slowly gaining traction again.

<comment><USER4> My understanding is not that promises weren't valued, but that there were conflicting opinions on how to implement them, so promises were left in user land, in hopes that the community would vet a better solution than could be prescribed by the node team. [https://groups.google.com/forum/#!msg/nodejs/jaufClrXU9U/ov5...](https://groups.google.com/forum/#!msg/nodejs/jaufClrXU9U/ov5WHIk7SAwJ)

q seems to be a popular choice. <https://github.com/kriskowal/q>

</comment></comment></comment><comment><USER5> Callback hell is certainly a real thing, but that Javascript snippet is a poor example for a goto comparison, since it's pretty much as linear as you can get.

The problems with Javascript and callbacks are usually (in reverse importance): noisy verbosity (all those "function()"s), the deeper and deeper indentations, and then ensuring execution order on interdependent async steps while keeping it readable. In the blog post's example, you pretty much of a serial chain of dependent steps, and the only thing really wrong with it is that it's just ugly and approaching unreadable (syntax highlighting will help quite a bit, though).

I think most people heavily involved with Javascript recognize those problems, though. Promises/deferreds have entered mainstream js usage. They can be somewhat confusing for newcomers, but several libraries can help, as others have pointed out. Language support is evolving: "let" as an option for more control over scoping, the arrow syntax for simpler function expressions, yield for shallow continuations, etc. These will in turn feed back into making libraries smaller and easier to use (I'm really looking forward to when I can use <http://taskjs.org/> for all my async needs. Combined with the arrow syntax, I feel like I can pretty much always avoid a callback mess and retain clarity of (high-level) flow at a glance).

This isn't a knock on elm (this article is the extent of my knowledge of it), and it isn't a dismissal of the problem, but it isn't clear to me from this article what is broken in JS that is fixed in elm. In other words, this could be another tutorial on promises in Javascript and make the same points about excessive callbacks being poor coding style and bad news for readability and maintainability.

Syntax that makes clear code the lowest energy state _is_ a feature, but (if we limit our discussion to callbacks) in JS it's partly solved, partly being worked on, and it's not clear to me yet what the energy differential is in typical elm usage between this code and the nasty spaghetti code you can always write if you try.

</comment><comment><USER6> Personally, any solution to callback hell will also need to be a language that supports returning multiple values. The following convention is simply too useful to me:

      foo.doSomethingAsync(function(err, result) {
        if (err) {
          ...
        }
        ...
      });

You can obviously accomplish this with exceptions, but then you have a million try/catch blocks floating around all over the place and the code becomes even _harder_ to read (and more verbose to boot).

<comment><USER7> There's a way without exceptions. Use an ErrorT[Promise[A]] monad. I've done this in Scala before and it is _so_ much simpler than the JavaScript convention you pointed out.

It allows you to write code like this:

        val query = "Brian"
        val result = for {
          db <- connectToDatabase
          user <- userFromDatabase(db, query)
          friends <- friendsFromDatabase(db, user.friends)
        } yield friends

Whenever one of the functions above returns an error, the whole expression is that error. The outcome is either an error (if there was any) or the end value of Set[User]. No need to manually handle an error until you get to the end result.

<comment><USER8> That's basically what the promises spec for Javascript gives you.

<comment><USER7> Exactly. The promises spec defines the Promise monad. The problem is that JavaScript doesn't have monadic syntax, which would make the code a lot more readable.

</comment></comment></comment></comment><comment><USER9> The "callback hell" example is a rather tame one, since the code is readable in a single location just with some nesting. So when I see the FRP solution which is the same amount of code I'm not certain that in a complex example this actually solves the problem. You can still have lift statements scattered around a program just like you can have callbacks to various functions scattered around.

The solution to GOTO was to remove it and replace it with a few control structure forms that enforced locality. I remember converting someone's GOTO- laced code once and basically everything could be re-written with some clever use of do-while with break statements and an occasional flag variable. do- while, while, for, etc. replace GOTO in 99% of cases and enforce the desired code locality for readability.

So what syntactical structure could enforce locality of time-connected variables?

E.g. some idea like this:

        data, err <- $.ajax(requestUrl1)
        if( err ) {
          console.log(err)
          return
        }
        data2, err <- $.ajax(makeRequestUrl2(data))

Where the <\- syntax could be like an = statement but say that the assignment and all following statements are placed in a callback.

<comment><USER10> C# 4.0 has async/await to solve this.

[http://msdn.microsoft.com/en- us/library/vstudio/hh191443.asp...](http://msdn.microsoft.com/en- us/library/vstudio/hh191443.aspx)

<comment><USER11> Async looks nice, but this ([http://www.jayway.com/2012/10/07/asyncawait-in-c- a-disaster-...](http://www.jayway.com/2012/10/07/asyncawait-in-c-a-disaster- waiting-to-happen/)) makes me wonder whether it is the right solution for this problem. Breaking what most programmers think are the 'laws' of refactoring is not a good thing.

<comment><USER12> The problem in the linked article is not async/await, but rather specifically async void, which you don't get by following the straightforward sync->async refactoring rules. A normal void method would start returning Task when turned async (and a non-void method returning T would start returning Task<T>). Async void is a special, distinct beast which is fire-and-forget by definition, and it only exists in async land. Perhaps they should have used a special new keyword for that instead, but in any case, it's a completely orthogonal problem.

</comment></comment></comment></comment><comment><USER13> Callbacks are different than gotos in that they are aren't even remotely close to gotos.

With a callback, you can get into 'callback hell,' however the root cause of that is that you probably don't understand the nuances of properly architecting a solution that involves the power of first-class functions.

JavaScript is nice because the scoping of the callback is easily controllable through your invocation method, and if you've created a good object model then it's relatively easy to maintain an understandable state.

When you explicitly define callbacks like in the examples, you're tightly coupling the response handlers to their requests, which is a relatively poor implementation and will bite you in the ass later on.

<comment><USER7> _Callbacks are different than gotos in that they are aren't even remotely close to gotos._

The analogy is that callbacks create non-linear control flow. Using a monadic syntax like in Roy, we can easily have callbacks without having them look non- linear:

        let deferred = {
          return: \x ->
            let d = $.Deferred ()
            d.resolve x
            d.promise ()
          bind: \x f -> x.pipe f
        }

        let v = do deferred
          hello <- $.ajax 'examples/helloworld.roy'
          alias <- $.ajax 'examples/alias.roy'
          return (hello ++ alias)

        v.done console.log

Which compiles into continuation passing:

        var deferred = {
            "return": function(x) {
                var d = $.Deferred();
                d.resolve(x);
                return d.promise();
            },
            "bind": function(x, f) {
                return x.pipe(f);
            }
        };
        var v = (function(){
            var __monad__ = deferred;
            return __monad__.bind($.ajax('examples/helloworld.roy'), function(hello) {
                return __monad__.bind($.ajax('examples/alias.roy'), function(alias) {
                    return __monad__.return((hello + alias));
                });
            });
        })();
        v.done(console.log);

Anyway, continuations (with call/cc) are definitely a controlled form of goto. Take a look at an example from Paul Graham:

<http://lib.store.yahoo.net/lib/paulgraham/cint.lisp>

        ((call/cc
          (lambda (goto)
            (letrec ((start
                      (lambda ()
                        (print "start")
                        (goto next)))
                     (froz
                      (lambda ()
                        (print "froz")
                        (goto last)))
                     (next
                      (lambda ()
                        (print "next")
                        (goto froz)))
                     (last
                      (lambda ()
                        (print "last")
                        (+ 3 4))))
              start))))

<comment><USER14> All of structured programming consists of various controlled forms of goto.

<comment><USER15> Yesterday, I found an email from Jon Callas where he was giving advice on where SAML falls in the Chomsky hierarchy of languages:

 _"If it has backwards gotos in any form, it's Turing-complete. Loops, recursion, etc. are backwards gotos. If-then-else is a forward goto."_

I hadn't ever thought of things that way, but I thought it was interesting.

<comment><USER16> Once you've worked in assembly language, you realize everything is just another form of _jmp_.

</comment></comment></comment></comment></comment><comment><USER17> One way to escape callback hell is to use a async.js (<https://github.com/eligrey/async.js>), which uses yield to abstract away callbacks. It's Firefox-only (JS 1.7+) though, but that can probably be resolved by using a JS parser and replacing every yield with JS 1.5 callbacks.

Full disclosure: I wrote async.js.

<comment><USER18> There's also this library: <https://github.com/caolan/async>

<comment><USER17> That library uses callbacks and isn't really related other than the name. I don't think that the author googled async.js to see if the library name was already taken.

<comment><USER3> <https://github.com/caolan/async>: 3293 stars on Github

<https://github.com/eligrey/async.js>: 15 stars on Github

Sorry, you lost this one.

<comment><USER17> Sorry, but what do stars have to do with it? That's like saying DuckDuckGo should be allowed to rename itself as Google if they become more popular than Google. <https://github.com/caolan/async> had zero stars (i.e. didn't exist) back when I released async.js.

<comment><USER3> I'm just saying you're going to have a hard time convincing everyone that your project is _the_ "async" JavaScript library. I presume you don't plan on suing them for trademark infringement.

It's annoying (it's happened to me too) but I don't think there's much you can do about it. Especially when the name is incredibly generic.

</comment></comment></comment></comment></comment></comment><comment><USER19> The problem is not callback, the problem is that callbacks exists in Javascript.

Callbacks themselves, when used wisely, can often enhance code readability, hell LISP has had function references since forever, but I think the most complain about callbacks are actually complains about callbacks in noisy languages, mostly likely languages with noisy syntaxes like Javascript and Java. When read that way, the disgust towards callbacks do seem to have merits. As the author has pointed out, the 2 getPhoto() functions at the end express and do exactly the same things, but obviously the CoffeeScript version reads better.

Callbacks have been around a long time and I've never heard of people complain as much about them as people have for Javascript and I conjecture the reasons are as follows:

1) There's no named parameters (keyword arguments) in Javascript, so people pass around objects literals into functions to emulate them. 2) Making lambdas in JS is too easy, but the syntax is too noisy. 3) Oh so many aliasing of _this_ ; 4) Self-chainable JS libraries like jQuery makes the style of calling multiple functions too easy. But lines can only go to long before becoming unwieldy, so people tend to indent chained method calls multiple times. 5) No modules and global namespace pollution is frown upon, so people are hesitant to flatten deeply nested callback chains. 6) There are a dozen ways to make a JS class and/or object depending on frameworks, and they are not at all compatible.

All of these "features" coagulate in JS into giant blobs of snot like this:

      <script>
        $(document).ready(function() {
          var $main = $("#main");
          $main.
            hide().
            click(function(e) {
              $.ajax({
                type: "POST",
                dataType: "json",
                contentType: "application/json",
                success: function(data, textStatus, jqXHR) {
                   data['rows'].forEach(function(line) {
                       $main.append($("<p>", {
                          className: "row"
                       }).append(line));
                   });
                }
              });
            }).
            show();
        });
      </script>

Words for the wise, when you see a shiny new jQuery plugin, stop, think for 3 minutes, and then put it inside a Backbone View or whatever your favorite framework is other than jQuery*. If you don't know anything other than jQuery, now is probably the best time to learn a few.

</comment><comment><USER20> This reminds me of the pain of dealing with python's twisted library, albeit before inline callbacks were implemented.

Inline callbacks as implemented in python can make asynchronous code a lot easier to read: [http://hackedbellini.org/development/writing-asynchronous- py...](http://hackedbellini.org/development/writing-asynchronous-python-code- with-twisted-using-inlinecallbacks/)

<comment><USER21> And using something like Eventlet or Gevent can make asynchronous code downright pleasant. Of the two, Eventlet has the better docs, and both are easy to get started with, and stable enough for production use:

<http://eventlet.net/doc/>

Give it a try! You almost definitely won't regret it!

</comment></comment><comment><USER22> Isn't `yield` the solution to all the problems? It makes things responsive and avoids the callbacks entirely.

For example: <http://www.tornadoweb.org/documentation/gen.html>

<comment><USER23> It is _a_ solution, kind of, but annoying on a few accounts:

0\. it plays hell with threadlocals-as-dynamic-scoping, which is the only way most "modern" languages permit dynamically scoped variables

1\. it needs to be correctly passed along to callers, and given it's usually used in dynamically typed languages there's a high risk of forgetting and dropping a yield

2\. yield being also used for iteration, it can be confusing to keep them straight.

It's definitely a better solution than callback hell though. An other approach is runtime support as in gevent, where the "yielding" is done by the library/IO code and invisible to the caller. The final two I know of are baking lightweight concurrency and communications into the language itself (Erlang, and to a lower extent Go and Rust) or monadic systems (Haskell)

</comment></comment><comment><USER24> You've got to ask, why is async programming used at all? The reason is twofold: first, the C10K problem, where too many threads kill performance, and second, sometimes you want to have multiple tasks run in parallel.

There are fairly simple syntactical solutions to both problems.

      result = doSomeAsyncTask()
      result.yield() // drops the thread, picks it up on response
      // do stuff with result here

This magic yield() doesn't exist (to my knowledge), but if it did, it would preserve linear code and also solve the C10K problem.

You could have similar code to solve the multiple task problem:

      result0 = doSomeAsyncTask0();
      result1 = doSomeAsyncTask1();

      while (result = getNextCompletedTask(result0, result1)) {
        // do something to result
      }

A Future in Java does something like this, but it doesn't drop threads.

</comment><comment><USER25> Callback Hell is certainly a real thing. I decided 12 years ago that I would never use callbacks if I could avoid it (the only wai you can't avoid it is if an API forces you to use them); I have never looked back. Regular, simple, straightforward imperative flow control is a very powerful thing, and any time you give it up or make it more squishy and indirect, you had better be getting something _big_ in return. Usually you aren't.

That said, what the article proposes as a solution is bananas. You don't need to do crazy functional acronym things; just don't use callbacks. Good C/C++ programmers in the field where I work (video games) do this all the time. It's not hard except that it requires a little bit of discipline toward simplicity (which is not something exhibited by this article!)

<comment><USER26> Actually, you're wrong. This is bananas (based on very closely related FPR concept)

<http://www.haskell.org/haskellwiki/Reactive-banana>

Secondly, you come off sounding defensive and ignorant. This is a new programming paradigm. Hopefully it will give people new ways to approach the same difficult problems. (And I really hope you believe GUIs are inherently difficult...)

No one is twisting your arm to learn FPR. If callbacks work for you in your job, then stick with what works.

<comment><USER25> When I was in college, and shortly afterward, I was very much into "new programming paradigms" and would get excited about lazy evaluation or continuations or whatever was the new cool idea going around. I have designed and implemented several programming languages built around new / wacky features; the most recent of these was ten years ago.

What you are hearing now is not ignorance, it is experience. I am a tremendously better programmer than I was in those days, and the way I got better was not by getting excited about wacky ideas; it was by really noticing what really works, and what doesn't; by noticing what are the real problems that I encounter in complicated programming projects, rather than what inexperienced / pundit / academic programmers tell me the problems are.

Clearly you didn't really read my comment, though, since you are saying "If callbacks work for you in your job..." and my entire point is that callbacks are terrible.

</comment></comment></comment><comment><USER27> The author offers an alternative that would require a change to the language. Callbacks and their use in "callback hell" are a little different than use of "goto"; "goto" appears to have an obvious alternative that was more logical to use already implemented in the language. For javascript, there is none of the nice syntactic sugar (reminds me a lot of C# recent async changes) that the author suggests and is not even being proposed for ECMA 6.

I agree it would be nice to have that stuff, and that callbacks can get a little hairy, but they are the best solution available at present. Shall we stop developing applications in the mean time while the language catches up, or even worse, browsers actually consistently implement the changes?

<comment><USER28> No, we should stop writing javascript and start writing elm - a language that compiles to javascript, works like described in that page, and is the subject generally of the site hosting the article.

At least, that's what the article is saying. There are a few interesting things on the horizon there, but I've been watching elm with some interest.

</comment></comment><comment><USER29> This kind of confuses two important ideas, both discussed by Dijkstra.

The most popular was his article about gotos.

Another idea in his writings was that time-dependent programming was dangerous. He was talking about interrupt based programming specifically, and also addressed the common practice of some hardware to have asynchronous IO. You would start an IO operation, and go on and do other things, come back later and see the values there.

So these two things are not alike. They both cause confusion about what the program is doing, but they are not "like" each other.

To be a better programmer, it is good to read Dijkstra. It is really all about avoiding errors in programming.

</comment><comment><USER30> As someone who writes C code for a distributed system that uses event-driven callbacks ( Zscaler) (yes,the binding is at compile time), I was aghast when I saw goto's in the codebase. I mean,I believed programmers were indoctrinated with " using goto = goto hell". I have realized that if used smartly,goto's cause no problem-say in error handling. I can confidently say I have not seen a single bug because of improper usage of goto in the last 1.7 years. And we do a lot of interesting things in C,including talking to a Postgres database,having a messaging protocol layer,doing shared memory manipulation etc.

</comment><comment><USER31> One thing I'd like to see from languages that compile to js: Some kind of evidence that output readability is a concern. You can make some beautiful abstractions, but if I can't debug it when things go wrong, then there's no way I would use it.

Not making any comments about Elm's output, but the author clearly doesn't consider it a priority in the post.

<comment><USER32> But how? Does your C code compile to readable assembly? Does Haskell compile to readable C? The high level language is created because the lowlevel language is unreadable when solving problems the high level language solves.

<comment><USER33> While I agree with your premise, the thing that is driving the parent comment is the fact that when debugging a language such as Elm, there is no tooling to make sense of the output code. This forces the user to use standard JS debugging tools on a pile of JS that was not written to be debugged. This is a contrast to Java or C, where debugging tools and hooks have been built to indicate where the low-level code is mapped to high-level code.

At the end of the day this is more a call for language authors and the people around them to develop tools to debug the language.

</comment></comment></comment><comment><USER34> This seems like a bad analogy. Dijkstra's paper was in favor of "structured programming",and the problem was that goto was too-unstructured. If anything, callbacks are excessively structured.

Also, why is nonlinear code a bad thing? If the program behavior should be nonlinear, then neither should the code.

<comment><USER32> Because people have trouble reasoning mon-linearly.

</comment></comment><comment><USER35> Two observations. First, great how do we debug it? How can we see our signals between each step? How about beyond simple print/logging?

And two, I like his contrast between async vs synchronous flows, and recognizing synchronous style programming has many benefits that CPS doesn't. However, I think even this style still hasn't solved the bigger problem with asynchronous style programming. The ability to reuse it easily. In synchronous style programming I can reuse code and add to that block by calling the method, then after that method is done add my code.

       ... my code before ...
       var result = someMethod()
       ... my code after ...

It's just that simple with synchronous style. With async style the author has to provide you a hook to hook onto the end or beginning of this flow (adding a callback param, returning a promise, etc). I think even with using signals you have the same issue. Without explicit hooks you can't hook more code onto it like you can with good old fashion synchronous programming. Not to mention error control flow is turned upside down too.

I'm intrigued by the ideas of signals over callbacks, but I don't know if they fix enough problems with callbacks yet.

<comment><USER36> The following is a dead comment by seanmcdirmid... reposting since it seems perfectly legitimate and I have no idea why this would be voted down. (Glitch?)

Debugging is one of the problems with FRP/signals, or functional code in general. No one has come up with a good dataflow debugger yet, and it might not even be viable. The best you can do is interpose "probes" on your code like you would take measurements with an oscilloscope. Disclosure: I did my dissertation on signals (object-oriented ones to be precise), and am a bit disillusioned with it.

On the other hand, the argument from the declarative community is that you don't need to debug your code.

A better alternative to FRP/signals might be immediate mode user interfaces. Since they are conceptually called on every frame, you get the benefits of FRP while still being able to debug in the old way. On the other hand, they are quite inefficient, though I think we could play some tricks with technology to make them better (memoize, refresh blocks of computations only as needed via dependency tracing).

</comment></comment><comment><USER37> So, this Functional Reactive Programming stuff compiles to Javascript, right?

Is the resultant Javascript just a bunch of nested callbacks, as in the example the blog post uses to illustrate spaghetti code?

<comment><USER38> The 'big problem' with callbacks isn't the callbacks themselves - it's the resulting difficulty to the developer to keep track of the flow of control.

This is analogous to goto's - _programming_ with goto is a nightmare, but all code 'compiles to' some sort of immediate form using goto's. The goto is not the problem, programming with goto is.

</comment></comment><comment><USER39> Actually, callbacks are the Intercal's COME_FROM instruction (<http://en.wikipedia.org/wiki/COME_FROM>).

So, it is even worst!

</comment><comment><USER40> Here are the slides from Evan's talk at Strange Loop:

[https://github.com/strangeloop/strangeloop2012/blob/master/s...](https://github.com/strangeloop/strangeloop2012/blob/master/slides/elc/Czaplicki- ElmMakingTheWebFunctional.pdf?raw=true)

</comment><comment><USER41> @mpolun - It appears your account has been hell-banned. You need to create a new account so I can upvote your comments:

mpolun> I agree that raw callbacks can get out of hand, but the typical solution in js is to use an event emitter (<http://nodejs.org/api/events.html>) or promises (like <https://github.com/kriskowal/q>), the latter of which seems to be pretty close to what this article is talking about. Is there a fundamental difference, or are promises an example of functional reactive programming in a language without direct support for it?

</comment><comment><USER42> Voting up just for not using a "...Considered Harmful" headline, particularly since the author obviously is familiar with the idea.

</comment><comment><USER43> Another approach to async IO is CPS (continuations passing style), in which you write imperative style code. This imperative style code is then compiled such that the blocking IO operations are called with callbacks, which are the remainder of that block of code (the continuation) - allowing the calling thread to be re-used while blocking for IO. Relies on the continuation having access to the outer/parent/previous-part function via closures.

It'll be interesting to see if people start doing this. Requires people to understand continuations and closures (which more people have exposure to now via JavaScript), and library support.

<comment><USER44> Hey, that was my idea too, see my own comment [1]. I've actually developed a (very simplistic) programming language utilizing this approach. I even compiled the interpreter to Javascript so you can try it our from the browser.

[1] <http://news.ycombinator.com/item?id=4736630>

</comment></comment><comment><USER45> Agreed. It's one of the reasons why I wrote lthread. Implementing any non- trivial protocol over a socket for example will lead to callback hell. There are plenty of states to transition from/to and it's very easy to get it wrong no matter how good the code is structured.

Forget Javascript for a second, and take a look at a typical http proxy written in C using callbacks to see what a callback hell looks like. If 5 developers are working on such a project, it will require a lot of mental effort from each developer to keep the callback flow up-to-date in their head.

</comment><comment><USER46> Having programmed in many languages, but most recently Node.js for the last two years, I don't think "callback hell" is as big a problem as the OP makes it out to be.

Debugging huge, complicated, and even poorly written Node applications doesn't feel much different to me than debugging huge, complicated, or poorly written Java applications. Sometimes it's a pain, that's unavoidable. You can prevent it to an extent by writing clean, tested code.

I don't see a strong resemblance between goto and callbacks. The resemblance is just as strong between goto and any function, or class

</comment><comment><USER47> I've been a JS (which is the land of callbacks) programmer for only a few months now, and I would disagree. Yes you can write deeply nested callback chains, but you don't have to most of the time. There are a couple of ways to avoid it.

* The async library mentioned by other posters helps a lot.

* Libraries like backbone make writing event-driven software easier.

But to sum it up: it's like anywhere else, bad programmers write "callback hell" code, and good programmers don't.

<comment><USER48> This excuse is as old as programming languages.

* Programmers who need a higher level language (e.g. C instead of assembly) are just bad programmers.

* Programmers who can't manage manual memory allocation are just bad programmers.

* etc

</comment></comment><comment><USER49> I'm not convinced.

I'm not familiar with the last approach but it seems to me that with a couple of higher-order functions in JavaScript, the code will quickly become more manageable.

      function getPhoto(tag, handlerCallback) {
         asyncChain(requestTag, requestOneFrom)(tag, function(photoSizes) {
           handlerCallback(sizesToPhoto(photoSizes));
         });
      }

      getPhoto('tokyo', drawOnScreen);

</comment><comment><USER50> I used a functional-reactive-language-that-compiles-to-javascript for a web app, in a project that lasted about 3 years. It solved callback hell, and solved some UI problems, but created some hard UI problems as well. I'm not sure how this would translate to a server, but some examples anyway.

It seemed impossible to completely escape imperative programming. Mouse click handlers for example were much more natural to write imperatively; changes made in the imperative code would propagate as signals in a reactive way.

Reasoning about what happened around the boundaries of imperative and reactive code was hard, especially as the application grew in complexity. If I have a UI element that depends on two other signals - think spreadsheet cell with a formula that depends on two other calculations - do I want to update it as soon as one signal changes? do I wait for both to change? Do I want different behaviors in different circumstances? It often led excessive layout changes as values passed through intermediate states, or code being executed multiple times unnecessarily.

<comment><USER32> Is non-reactive code any better at solving those problems? Those are hard problems.

</comment></comment><comment><USER51> The number of languages that compile to JavaScript is starting to become disconcerting.

How long until we get tired of adding epicycles and just specify a VM and bytecode standard that all the browsers can implement and all the client-side languages can compile to?

<comment><USER52> Who would implement in their browser a VM no website used, and who would use a VM no browser implemented?

I'm not sure who you think "we" are, who should specify a VM and bytecode standard. If we wanted a bytecode standard, there doesn't seem anything deeply wrong with Java, and we seem to be in the process of phasing that out of every browser.

<comment><USER51> It'd have to be bootstrapped the same way other Web standards such as CSS had to be, which admittedly might take a while.

Java and Flash are no-gos because they're not open enough - they're owned by companies that want to maintain tight control over the platforms. They're also too heavily built around their own private APIs; what would really be needed is something that sticks to the same APIs and DOM that JavaScript interacts with, in order to ensure a reasonable migration path for existing technologies.

My guess is that the easiest option would be to base such a standard on a VM and bytecode format that a major browser already does implement: the one from the Spidermonkey Javascript engine.

<comment><USER23> So alternative VMs and VMs progress can go die in a fire, one runtime to rule them all and in the darkness bind them? No Carakan, no JavaScriptCore/Squirrelfish, no Chakram, no V8?

Here's an idea: javascript is your bytecode, and you have every single javascript VM as your runtime.

<comment><USER51> Perhaps not all of those specific ones, at least not without modification. But you're being hyperbolic; there's absolutely no reason you couldn't have multiple implementations of the VM standard. In fact, there should be - in the grandparent I pointed out that single-owner standards like Java are a no-go in my opinion.

My only thought here is that having a bytecode standard to work from might give a little more flexibility and power to folks who want to experiment with alternative client-side languages.

<comment><USER52> A byte-code based on Javascript VMs would be less useful than you might think.

For many years people who have tried to build dynamic languages on Java have had to go through horrible pain to build their languages, and not gained the performance they would want -- only the recent addition of invokeDynamic have finally allowed fast implementations.

Personally, I would hope any browser bytecode would have big integers as a primitive, as implementing them in dynamic language is very slow. However, no Javascript byte code would have big integers, as they aren't in Javascript!

<comment><USER51> What Javascript's capable of would really only need to be a starting point.

I certainly wouldn't want to limit what's possible to what Java or Javascript are capable of. Certainly not Java. Java is (IMO) practically defined by stagnation as a result of poor management by the companies that have owned it.

And part of what I'm thinking here is getting away from the limitations imposed by Javascript. For example, Javascript lacks big integers, and is a dynamic language. My thought is that decoupling the HLL from the runtime would allow for faster evolution, because it's hypothetically easier to add new opcodes to a bytecode and VM than it is to make large shifts to a high-level language. Consider the whole dynamic thing in particular - .NET has a great VM with pretty good support for both static and dynamic languages. Java didn't, but again we aren't strictly required to repeat the mistakes of the past. And by just using "Javascript as the bytecode" we commit the reverse sin - that's a 'bytecode' with poor support for static languages.

</comment></comment></comment></comment></comment></comment></comment><comment><USER53> Here's a google cache link: [http://webcache.googleusercontent.com/search?q=cache%3Ahttp%...](http://webcache.googleusercontent.com/search?q=cache%3Ahttp%3A%2F%2Felm- lang.org%2Flearn%2FEscape-from-Callback-Hell.elm)

</comment><comment><USER54> _It [synchronous call] basically dodges the issue of time-dependence by just freezing if it is waiting for a value. This blocks everything in the program. Mouse and keyboard input just piles up, waiting to be processed, presenting the user with an unresponsive app. This is not an acceptable user experience._

It depends on what else your user can realistically do before the call completes. In many cases the answer is "nothing." He needs the result of the call before he can proceed in his task. In simple web apps this happens a lot. In those cases I will often just make a synchronous call and avoid all the callback complexity.

<comment><USER32> What about auto save in gmail, prefetching, loading resources in parallel, updating buddy chat status, realtime stock prices, ...

</comment></comment><comment><USER55> Callbacks do lead to hell. The back traces half the lead you now-where. I have been writing a scrapy crawler and sometimes when an exception happens it takes some grepping around to figure out where the value that is wrong actually was generated.

Has anyone touched the Google Chrome code base? It is quite difficult to start debugging problems because of the sheer volume of callbacks. Add to that the stack-traces are massive because of the use of templates and other C++ language features.

Async coding needs to be an abstraction within the language. I am curious how languages manage the shared memory. What about the risk of dead locks?

<comment><USER56> > The back traces half the lead you now-where.

Yes. This can be solved by maintaining your own backtrace of callbacks (say, as part of your request object/structure), but it's really something that should be implemented in the language or framework.

<comment><USER32> It is crazy. This is a huge problem that is so easy for the language writers to solve (add a history object to each function call, when compiling/running in debug mode), but no one solves it.

</comment></comment></comment><comment><USER57> "It is pretty much the same as using goto to structure your programs."

I don't see how a self contained block of code can be equated to goto where the flow can bounce around all over the place.

The example callback "hell" code doesn't look any more complicated than the solution Elm code to me. Maybe the improvement is going over my head and I need to read it again. I just don't see it. Then again, I feel the same way about Coffeescript. These javascript helper languages just seem like an unnecessary added level of complication and cognitive load.

<comment><USER58> This is the typical "blog sample" complaint: "Four lines of code doesn't prove your conjecture". Of course, putting an entire application in would make for a challenging read.

While I'm not sure I would go as far as saying goto==callback, after wading through a fairly extensive browser extension, I know that callbacks are inherently more difficult to reason about than imperative code.

I haven't decided if the tradeoff of more flexible code versus more difficult reasoning is a good one. In some ways, I think the article got it right: we are expecting the programmer to do a lot of book-keeping that a compiler could do more cleanly. After all, it is possible to write goto-laden code that is just as readable as function-laden code. It's just nice to let the compiler manage all the baggage of frames, stack pointers and jumps for us.

</comment></comment><comment><USER59> Does anyone recall the article a few months back that sort of dealt with callback hell? It was a concept from a different language (which one, I don't recall) that worked basically with returning 2 values and formatting your functions according to a general model.

Yes, that's a bit vague, but that's all I've got to go on. :)

</comment><comment><USER60> Marginally related but IYI, I recently wrote a JS lib for writing loops with a delay, to avoid one instance of callback hell:

[http://brandon.si/code/dilly-dot-js-a-library-for-loops- with...](http://brandon.si/code/dilly-dot-js-a-library-for-loops-with-delays- in-javascript/)

</comment><comment><USER44> I think the author is missing the obvious and natural solution: let the programmer write code in a completely synchronous (blocking) style, but have the programming language execute it an an asynchronous and concurrent fashion. Something like that:

      # this appears very synchronous
      function getPhoto(tag) {
          var photoList  = syncGet(requestTag(tag));
          var photoSizes = syncGet(requestOneFrom(photoList));
          return sizesToPhoto(photoSizes);
      }

      # Two getPhoto() "processes" are spawned. After this,
      # the language multiplexes between them via the (single) event loop,
      # in a single OS thread.
      job1 = spawn getPhoto('tokyo');
      job2 = spawn getPhoto('tokyo');

      # Wait for both of them to finish. This too happens in an asynchronous
      # fashion, i.e. calling job1.join() does not prevent the two jobs from
      # running. In effect at this point we have three "processes" running
      # (the main process doing the joins, the job1 process and the job2 process).
      photo1 = job1.join();
      photo2 = job2.join();
      drawOnScreen(photo1);
      drawOnScreen(photo2);

Yes, I know this may be very hard to implement in Javascript/Node, because it fundamentally changes the way the JS engine needs to work.

NOTE: It seems this approach is not new; "green theads" seems to be the right term, and there seem to be a lot of Python-based implementations. Go's goroutines also appear similar (but you can have them run truly in parallel).

 _BUT_ note a crucial difference from the "green threads" approach - in my suggested design, there would be no real scheduling. If you perform sequence of operations and they are all guaranteed not to block, this sequence is _automatically atomic_ , and cannot be interrupted by another "process".

I should also mention this programming language I'm developing, called NCD [1], which employs the same idea. See the in-browser demo [2], click on the Spawn example.

Note that NCD implements a unique extension of imperative programming. Statements in general persist even after they have "returned", and they get the chance to do stuff when they are about to be "deinitialized" (see what happens when you click "Request termination" in the Spawn example). Plus, any statement can trigger "backtracking" to its point within the process, causing automatic deinitialization of any statements that follow (try Count example).

Also, IMO promises [3] are just a hack around the fact that the language is not inherently asynchronous. Seriously, who would prefer:

      doFoo()
          .then(function (foo) {
              return doBar(foo);
          })
          .then(function (bar) {
              return doBaz(bar);
          })
          .then(function(baz) {
              console.log(baz);
          });

Over this?

      function myWork () {
          foo = doFoo();
          bar = doBar(foo);
          baz = doBaz(bar);
          console.log(baz);
      }
      spawn myWork();

[1] <http://code.google.com/p/badvpn/wiki/NCD> [2] <http://badvpn.googlecode.com/svn/wiki/emncd.html> [3] <https://gist.github.com/3889970>

<comment><USER61> Green threads are indeed very useful, and probably the right way to go. In Javascript, see Tamejs: <http://tamejs.org/>

NCD looks interesting, in particular the backtracking feature. But I'm a bit concerned by your choice of developing a new language from scratch, with a very awkward syntax (at least at first sight). Why not extend an existing language?

See CPC for instance, which extends the C language with a spawn primitive (disclaimer - this is my PhD thesis project): [http://www.pps.univ-paris- diderot.fr/%7Ekerneis/software/cpc...](http://www.pps.univ-paris- diderot.fr/%7Ekerneis/software/cpc/) and <http://www.pps.univ-paris- diderot.fr/%7Ekerneis/research/> for more details.

<comment><USER44> Yes, Tamejs and CPC indeed do exactly what I had in mind. CPC is particularly amazing for doing this to C.

Considering NCD: you might have noticed that NCD was never meant to be a general-purpose language, but rather a simple scripting language for controlling other programs and OS configuration. My thinking was that extending a language with the features that define NCD (asynchronous execution, backtracking and extended statement lifetime) would essentially require a complete rewrite of a language implementation. However after seeing tamejs and your CPC I'm not so sure anymore :)

P.S. Check out the Read File example I just added to the NCD demo page; it shows how backtracking can be used to handle errors elegantly.

</comment></comment></comment><comment><USER62> An alternative method of decoupling callbacks is to make heavy use of events within your program. However, perhaps an event is even more like a goto because it doesn't encapsulate state.

<comment><USER32> What is the different between events and callbacks? I though an event triggers a callback.

</comment></comment><comment><USER63> Can anybody recommend a way to avoid Callback Hell in Objective-C?

<comment><USER64> blocks. but they are dangerous when dealing with threading.

<comment><USER65> Huh? As far as I can tell, blocks _are_ callback hell in this case, certainly the nested callback lambdas in the JavaScript examples are essentially equivalent to blocks.

</comment></comment></comment><comment><USER66> Amen brotha! I totally agree. Callbacks, especially nested callbacks are a nightmare to debug, and especially to refactor.

</comment><comment><USER67> The solution to all of this is incredibly simple but for some reason very few people seem to utilize it: State machines.

<comment><USER21> The reason people don't use explicit state machines more is because it's kind of a painful way to write code. Suppose that I want to do a bunch of HTTP GETs, munge the data, and then fire off corresponding HTTP PUTs. I would _like_ to be able to write something like:

        def process(job):
            http.put(job.destUrl, munge(http.get(job.srcUrl)))

        print "Processing some jobs"
        workerPool(MAX_CONNECTIONS).map(process, jobs)
        print "All done!"

Wouldn't that be great? And in fact, you can do this easily with something like Eventlet, so I'm not asking too much here.

<comment><USER33> Amusingly, in an environment with a level of parallelism, the above code poses few problems even if http.get/put are synchronous & blocking. A scheduler handles a bunch of blocked threads perfectly fine, and the series of calls per job aren't inefficient when executed in series.

We hit pain points when we can't have parallelism in our programs, and are forced to make elegant the work-arounds intended to unclog those programs.

</comment></comment></comment><comment><USER68> Link seems broken, page fails to load.

<comment><USER69> It seems that web site does not like IE9. I can view the source, but nothing shows up.

Thankfully other browsers work fine. Makes me wonder what they are doing to completely break rendering on IE though...

</comment></comment><comment><USER70> So essentially, everything about node.js is wrong? Hmm. Didn't see that coming!

<comment><USER71> To be less inflamatory, using callbacks to specify those low level APIs certainly makes sense, since the main desire here is to make them simple and interoperable, not necessarily human friendly.

You can then layer your favourite libraries or tools on top of that to make things better to live with. (For example, a promise-based wrapper for the low level libs or a compiles-to-js dialect)

I do agree that all those posts with people writing callback-based code as though it were the future were kind of sad though.

</comment></comment><comment><USER72> goto is sweet

</comment><comment><USER73> Why is it that nearly everytime some coding blog writes about something interesting you've got lots and lots of people criticizing the entry and saying, basically, that "the old way of doing thing is just fine, it's just you that are too stupid to understand it".

I'm sorry but that's not how it works. I've been coding for 20 years or so and I'm always open to new things. The first time I heard about using immutable objects in Java nearly everybody was laughing at the idea, making fun of it. Nowadays it's the contrary that is true. Same thing for using composition instead of concrete inheritance: everybody was there, ten years ago, saying that there was no problem with Java's concrete (implementation) inheritance. Or checked exceptions. Etc.

It's nearly always the same thing: a concept that is not mainstream but that looks very promising is explained in great details and yet people come here, bragging: "You're too stupid to understand ${common way of doing things}, there's no need for ${less commonly used technology}".

This really saddens me.

<comment><USER74> I've been coding for 20 years too and I'm also open to new things. But no one can be proficient in everything anymore so there is a cost to learning something new: we have to forget something we previously spent time to become familiar with.

Don't be sad, it's clearly a natural reaction that has some utility. I agree that there's a better way to phrase it, usually something like "is it really _that_ much better than what we have now?"

<comment><USER75> "we have to forget something we previously spent time to become familiar with."

<http://www.youtube.com/watch?v=8dbDJzDV1CM>

</comment></comment></comment><comment><USER32> I don't get it. His example just uses "let ... in" syntax instead of putting the next func as an argument to the first. It seemed to be exactly the same thing "deeply nested functions". He just chose not to indent after the "in", and he has a nicer syntax for nested functions.</comment>


Ask: Stigma of the unemployed - a better job title for a lifestyle entrepreneur? - <AUTHOR> I run a small, unsexy internet business in Europe, with a two person office and about 20 people working from home.
Around here, 'entrepreneur' is assumed to mean 'unemployed' or at best 'freelancer'. I'm dating at the moment and find it difficult to succinctly describe my occupation in a way that does not kill the conversation dead, as it either comes across as bragging or an attempt to disguise unemployment. It's major taboo here to talk figures or numbers.
So any ideas for pithy ways to describe a happy lifestyle entrepreneur without coming across as defensive? <comment><USER2> > I'm dating at the moment and find it difficult to succinctly describe my > occupation in a way that does not kill the conversation dead

As a general rule, don't answer questions like that straight. They're bound to kill the conversation, you're not at a job interview.

Jewel thief ("casing the joint" if it fits), duck cleaner (watch dirty jobs), art forger ("\-- Really?! Can you draw something for me? -- No, that would be _original art_.")... will all go over much better than whatever your real occupation is.

It's the same with age ("64, hanging in there! Just 8 more months to retirement. Great genes though, right?"), where you're from, what your hobbies are... The difference between lying and flirting is that the embellishment should be almost obvious.

</comment><comment><USER3> Why not simply say 'run a small company'. Nothing says 'success' like success, I'm assuming that your company actually works and makes money. That's as good as any employment or better depending on how well you're doing. Any date that just wants you if you have a steady job is not worth having imo, then it's no longer about you but about a search for financial stability.

<comment><USER4> I wonder about this. Why can't a person have some criteria to narrow the pool, and from that subset select for love? It would be different if they took the first person who came along with financial stability, if that was the _only_ thing that mattered.

If a person aims to have a family, financial stability is important. Note, I don't believe that kids actually need financial stability all that much, but the stress and conflict between parents commonly caused by financial instability definitely do affect them.

<comment><USER3> Financial situations that are attributable to state of employment are subject to violent and sudden change. They're not a good basis for any future predictions, especially not for viability of a relationship.

</comment></comment></comment><comment><USER5> Well, i am from Eastern Europe too, and my business can be best described exactly as yours, and i don't see absolutely any stigma. Everyone is ready to accept that running a small business is way better than working 9-5 for a meager wage.

Maybe in U.K. or Germany it might sound as 'unemployed', but in Eastern Europe 'employed' almost always means 'poor loser' unless you work for a big name company (SAP/Gazprom) or at least a mid-tier manager. So, there is more stigma attached to employment than unemployment. In fact, many people just tell to girls 'i don't work' and that adds to their image rather than subtracts. Remember old Soviet curse "i wish you live on your salary alone!"

If you feel bad telling you don't work 9-5, buy a sports car. It helps.

</comment><comment><USER6> I used to pitch myself as a freelancer/entrepreneur/self-employed. Lots of women were not interested, and that was good. I found one who bought that that my status was cool, was supportive, and we ended up getting married after a few years. Just had our 25th anniversary.

Be who you are, and if women don't like it, they're not a good fit. Bullshit now comes back to haunt you later.

<comment><USER7> "Be who you are, and if women don't like it, they're not a good fit. Bullshit now comes back to haunt you later." These are extremely wise words to live by.

</comment></comment><comment><USER8> I run a small software company which $BENEFITS_STATEMENT.

You can tailor the benefits to whatever you thing the person you are speaking to values.

<comment><USER9> Did you A/B test those kinds of statements with girls prior to getting married? :-)

<comment><USER8> No, because dating a statistically significant sample of women sounds dreadfully expensive and conversions would be too slow to get results while I was still young enough to use them.

Sorry, I'm a bit literally minded. OK, so did I try saying different things to ladies to see how they reacted? Yes.

What worked very poorly: self-deprecation ("I'm gainfully unemployed"), describing myself as an engineer, and minimizing my accomplishments in starting a company. What worked very well: focusing more on the benefits of software rather than on the "software" bit, leaving a bit of ambiguity about what I actually did for a living, and mentioning things which "normal people" tend to associate with successful businessmen. (e.g. It was, at one point, equally truthful to say "I do A/B testing" and "A firm in Germany recently flew me there to speak to the CEO about what they would need to do to increase sales by a few million dollars." Try asking young ladies of your acquaintance to rate the attractiveness of two friends with those occupations.)

I got radically more successful with dating after I treated it as a marketing exercise and realized that some scripts I had internalized about it were the dating equivalent of "Good products always win so just focus on product quality and that obviates your need for a marketing strategy."

</comment></comment></comment><comment><USER10> I am Italian and have been an entrepreneur myself, for this reason, I understand your difficulty.

However, before even trying to describe your lifestyle in a less defensive way, I would suggest to change attitude about your job.

Far from being a stigma, running a small business makes you a successful person if you enjoy what you do, if your business is stable, if it grows organically, if it allows you to employ people, if it leaves you time to live your life fully.

Saying "I am an entrepreneur in the <your business goes here> field" should be convincing enough if you feel strong about what you are doing.

After all, if you feel strong about your choices, anyone who kills the conversation at this point might not be someone you want continue dating anyway.

<comment><USER11> Definitely. If it were a dating game, I'd almost go with 'I don't have an employer, I'm really passionate about software though' and leave it there.

girls.filter( girl => !girl.isGoldDigger ).map(_.reply("how about you?"))

</comment></comment><comment><USER12> You don't have to use the "entrepreneur" label. I don't, but mostly because it sounds stupid. If you run a popular media site, you're in the media business. If you sell e-books, you're a publisher. If you run a time tracking SaaS, you're a business tools provider, software engineer, productivity expert, whatever.

</comment><comment><USER13> I am co-owner of a company that make children games.

When people ask what I do, I say: "I make children games."

</comment><comment><USER14> I do consulting in quantitative software and analytics for finance. I have my own small company and can give myself any title. "CEO" sounds too pretentious to many, so I went with managing director, the title for upper-middle to upper management in many financial companies.

Choose something similar for your industry. Couple of guesses: vice-president of business development, director of professional services, executive producer...

<comment><USER15> That's funny, since in Commonwealth-speak managing director means CEO.

</comment></comment><comment><USER16> Business owner? Businessman? Or maybe it's the way you talk about it. I'm from Europe too and I'm not aware of this phenomena. Maybe the translation for that in your language has some other connotation or evokes a different feeling. In my native language we have a word for that too, but to be honest it feels completely different.

Anyways how does that kill the conversation? -What do you do for a living? -I'm an entrepreneur. -Ohhh, I see. I have to go now, bye! A bit odd.

Anyways - optimize for quality rather than quality. Having everyone fall in love with you is pretty crap if you don't like them back. You need just one.

</comment><comment><USER17> I guess in SV the coolest is Founder and Investor, then Board Member and Advisor, but we still have CEO, CTO, Exec, etc. followed by standard positions like Distinguished Engineer, Senior Engineer, etc. and generics like partner, associate, and employee. VP isn't worth much since some industries use them at very low level.

If you can't call yourself a founder, or it doesn't go over well in Europe, what's to stop you from just saying I work for company x. No one knows it is a two person company + outsourcing anyway. It's the same as saying I work for amazon, etc..

</comment><comment><USER18> "I own a business." Oh? What kind? "We make X for Y."

</comment><comment><USER19> Just tell that you run a business. Most people who you don't want to be confused with (who actually don't do much and are business wannabes) wouldn't tell that about themselves. They "are entrepreneurs" in state of their minds and in their daydreams but they don't run any business. Actually, most of them think that "being an entrepreneur" > "simply running a business" so they wouldn't lower themselves to claiming that as they always aim so high and want to feel so important, right?

</comment><comment><USER20> I got this from some older friends when I started DataStax. They took my wife aside: "Sure, Jonathan's 'starting a company.' But seriously, do you need help?"

</comment><comment><USER21> Just tell people "I write software for x" where x can be anything. Teachers, government, hospitals, dogs, whatever it is. In my case it's "lawyers". You don't have to go into any more detail than that. Anyone who really cares will ask followup questions or say something like "oh you should talk to my brother, he's a lawyer".

</comment><comment><USER7> Have pride and confidence when you speak of being an entrepreneur. Dammit, you're an innovator! A job creator! A creative person! With a variety of skills and challenges! You love what you do! You're a risk taker! You're your own boss! You are in control of your future and you are doing exactly what you want with your life!

</comment><comment><USER22> There is no magic word, just say it confidently. And just hint at it, more can come out later. Mystery helps.

Though I think sprindrifts suggestions are better. If they're truly Iinterested in knowing they'll ask again later and you can respond seriously.

</comment><comment><USER23> Honestly any woman is lucky to find a decent guy who has this kind of work. Mainly, because you'll have a lot more freedom and probably be able to spend more time with her than 9-5 slaves.

If they don't bite, then it's their loss. Good luck man.

</comment><comment><USER24> Why don't you just keep it simple ?

You: I run my own business

Girl: hmm what kind of business ? (or she might just stop here)

You: Online business to sell $XYZ

Girl: Oh cool. <She asks another question about the business>

You: Well yea its kinda complicated. So what were you saying about that tilapia ?

</comment><comment><USER25> Give yourself a title, like CEO or Director, of the company. Don't call yourself an entrepreneur, just a simple, but nice title.

You don't need to defend something that definitely works for you. Be proud, but not arrogant.

</comment><comment><USER26> "I work online" is my go-to, it gets around the 'Im an entrepreneur aka out of work bum' trip wire that even I look out for, and leads well into a description of my service biz.

</comment><comment><USER27> You're a CEO, a business owner and your own boss. I'm from eastern europe and maybe things are too different here, but I don't see how that would ever mean unemployed.

</comment><comment><USER28> instead of saying you're an entrepreneur, say what you do. for instance:

blogger = author

information marketer = teacher

outsourced app = product designer

affiliate marketer = international sales manager

ecommerce store = ceo of import/export business

and so on

<comment><USER29> Some of those are deceptive. Nobody would mistake an information marketer for a teacher (One has a stable job educating a classroom, the other sells overpriced weight loss ebooks.). And international sales manager is a huge stretch from affiliate marketer.

Honesty is the foundation of a successful relationship. So when dating for love, you should always tell the truth. If you own a business, say you own a business. If your date can't accept your career, then they aren't worth dating in the first place.

<comment><USER23> >Some of those are deceptive.

All of those are deceptive.

</comment></comment></comment><comment><USER30> Obligatory Seinfeld reference: [https://www.youtube.com/watch?v=IrLtHatB6IU](https://www.youtube.com/watch?v=IrLtHatB6IU)

</comment><comment><USER31> I don't know what country you are in, but in Germany, the Mittelstand is a quite respected part of the economy, and that describes what you do.

</comment><comment><USER32> I do what I want, when I want. Right now I want a sandwich. (Insert long pause and do not speak again until she gets you a sandwich.)

</comment><comment><USER32> Obligatory manhood reference: [http://manhood101.com/](http://manhood101.com/)

</comment><comment><USER33> Businessman/woman? Executive? Director? Founder? Cofounder? Go with something they're familiar with.

</comment><comment><USER34> State what you do. Don't look unemployed.

Some can't take a spouse with unsteady income. That can't be helped.

</comment><comment><USER35> what is your job title at the unsexy business? manager of sales, VP of sales, programmer? choose one and move on. if the person asks for more info, they you tell them what you do, just leave out of the entrepreneur thing.

</comment><comment><USER36> startup founder is well understood in Europe...or MD of one</comment>


bcal storage conversion and expression calculator v1.8 released - <AUTHOR> https://github.com/jarun/bcal/releases/tag/v1.8 <comment><AUTHOR> Features: [https://github.com/jarun/bcal#features](https://github.com/jarun/bcal#features)</comment>


Lidar: Peek into the Future with iPad Pro - <AUTHOR> https://blog.halide.cam/lidar-peek-into-the-future-with-ipad-pro-11d38910e9f8 <comment><USER3> I would be curious to know if this could be used (with a heavy dose of software and a rotating mount) to replace a Matterport scanner for real estate agents. That would be a $2495-$3995 cost for device, a fixed cost of $19-$29 per house walkthrough and a $49-$149/mo hosting fee. Seems like a boatload of cash could be made for a first-to-market product here.

<comment><USER4> How common are those? I've looked at a lot of properties and am yet to run across a 3D scan, but it may be very location dependent/value of property.

<comment><USER5> Very common in my area. When we just put our previous home up for rent, the agent had somebody come in, scan and photo the house and it was up the next day with virtual 3d walkthroughs and everything. We kinda couldn't believe they would do that just for a rental.

<comment><USER6> Side effect - these become documents of record if you damage/modify a rental property.

<comment><USER7> After one ugly experience with a dirtbag landlord, I started taking my own photos and had the landlord sign/date them before moving in.

Always have your own documentation.

</comment></comment></comment></comment></comment><comment><USER8> The longer Apple goes without releasing their AR headset the weirder adding AR to the iPads and iPhones as some sort of developer platform test bed becomes.

It's fine for developers but for end users these handheld AR experiences are so frustratingly poor, frustrating in the sense that the tracking and occlusion tech is getting really good but poor that you're experiencing the whole thing through this silly handheld porthole to the world.

Just starting to get stranger and stranger that every year for around 5 years now we've had to have Apple showing off these features and we nod along knowing we'll never ever use them but understand they're only there for developers, like this lidar sensor.

<comment><USER9> Apple's not going to launch a consumer feature until they think it's insanely great. Until then they need developers to keep working at it.

<comment><USER10> Wish they'd taken that approach with Catalina...

<comment><USER11> different teams, and plus the macos team at apple is notorious for releasing buggy and half baked software.

</comment></comment></comment></comment><comment><USER12> Are the demos impressive in a way I'm failing to spot? It still seems about on par with others and still has plenty of noise in the pop art chair and kitchen. I was hoping this would put the magic leap to shame but it doesn't seem much better.

<comment><USER13> They're showing off the environment scanning capability. The visualisation system is just something they knocked together quickly with some basic APIs, so it would be a bit much to expect ML equivalence.

<comment><USER12> Hmm I suppose you're right that the mesh generation system could be hiding some of the capability of the lidar. I expected the floating, mid-air meshes seen in the kitchen demo to go away but it could be a software issue.

<comment><USER13> I think the meshes are what the LIDAR API provides to the application.

</comment></comment></comment></comment><comment><USER14> I knew I recognized that name! Sebastiaan de With, who famously (in my mind) traveled from SF to the north shore of Alaska. I looked that post up the other day, from 2014, because I have a nice camera and a KLR - and I dream. [1]

When I read the iPad Pro announcement, the trifecta of Real Keyboard/iPadOS improvement/LiDAR got my attention. With the pandemic, I have found myself working with laptop actually in my lap, so I don't know how stable an iPad+keyboard would be. Otherwise, I would get it today to be my next personal workbook.

The opportunities for AR are incredible - that demo of walking around a scan is amazing. Interior design certainly looks like one of the first places that could benefit.

[1] [https://imgur.com/a/J7kZJ](https://imgur.com/a/J7kZJ)

<comment><USER15> Sebastiaan's original post about this album, including his replies to comments and questions: [https://www.reddit.com/r/pics/comments/2gejnr/got_divorced_l...](https://www.reddit.com/r/pics/comments/2gejnr/got_divorced_lost_my_job_so_me_and_my_buddy_got/)

</comment></comment><comment><USER16> Pretty excited to see what this does to the price of Lidar tech. I used to hear (need to validate with more research) that GPS and gyros/imu's are so cheap because of the need to get them so small and production friendly for so many mobile phones. I think Pixel 4 also has Lidar so I hope this trend continues.

</comment><comment><USER4> I think LIDAR could be very cool but as the article alludes it definitely has the "Chicken & Egg" problem is that you need the hardware so developers can develop, and you need the software to justify having the hardware. Sounds like even the API isn't on-tap quite yet.

It would definitely be cool if you could e.g. walk around a room and scan it into a home re-modelling app. I know the stated aim is more AR, and that's fine, but I can see apps using LIDAR far beyond that for example a clothing app scanning your body to determine perfect size.

Usage though depends a lot of level of detail, particularly using it to scan people instead of surfaces.

<comment><USER17> > _it definitely has the "Chicken & Egg" problem is that you need the hardware > so developers can develop, and you need the software to justify having the > hardware._

Although it's worth pointing out that the "Chicken & Egg" problem actually has a real life answer that applies equally to a lot of scenarios it's posited. In terms of "which came first" the answer is definitively eggs, with macrolecithal eggs and birds themselves evolving from dinosaurs and other previous ancestors. Evolution sees use of "existing hardware" which then undergoes incremental change, competitive ones of which are kept.

Similarly, in a developed platform you don't actually need software to justify incremental advances in hardware. The justification for the hardware is all the other already useful stuff it does and has inherited from previous generations. Apple, and other established platform companies, can get away with bootstrapping from the hardware side that way. Just as with other evolutionary processes sometimes there are even things that just fail to stick (like Force Touch) for better or worse, but even dead ends don't kill the whole platform. I guess it's also kind of another side of a certain degree of dominating market power. Often it's used for ill, but sometimes certain kinds of monopolies and lock-in can also give companies more freedom to experiment and look for longer term gains even if it's not justified in the next few quarters.

At any rate work got a few of these and it wasn't for LIDAR at all, wouldn't change the value if it never did anything. Except for an odd network issue I'm working through they're nice upgrades from previous iPad Pros so far. But from this demo LIDAR certainly could be put to real use in some architectural brainstorming for example, so happy to see it there.

</comment></comment><comment><USER18> Ok, this is tangential but there's a lot of people in this thread who seem to have a good knowledge of lidar:

How close can you get to creating a decent topographical survey of your property with what's available to consumers? Could you walk around with an iPad Pro and build a decent 3D model? Is there a not exorbitant drone solution?

<comment><USER19> I work at a company that does lidar SLAM. You can actually produce really high quality maps/slam with lidar/tof sensors, and it's a lot more robust/dense than visual/imu mapping.

<comment><USER18> How does the price compare to traditional survey methods?

<comment><USER19> Depends on what you're comparing to what. Big spinning lidars on cars are still expensive (few thousand dollars) but are coming down on price. Handheld 3D scanners on the other hand might start to become obseleted by a combination of cheap phone camera + lidar (really tof) sensors that are evidently cheap enough to put on phones. They can actually produce really high quality (SLAM) maps - Apple has figured out that they can have a much faster initial mapping phase by not having to do monocular mapping for their AR. So I guess I'm saying it's cheaper and a bit worse, but it's rapidly getting better.

</comment></comment></comment></comment><comment><USER20> Has anyone seen specs of the Lidar sensor? I'm coming from GIS background (geography) where Lidar scanning is very often used for ground measurements and would like to compare specs with the gear I know. I couldn't find any on Apple's website and those "tech blogs" don't tell much either.

</comment><comment><USER21> Wonder how well it would work as night vision?

Also my biggest wish with this tech is to be able to use with a 3D printer when you need to add a replacement part or some sort of shim.

<comment><USER20> one of the "real" applications of Lidar, which is aerial photogrammetry, is to map terrain from the sky. It is very often done at night, as there is very little traffic. You should be fine with measuring objects in the dark with this iPad Lidar as far as I can tell.

About 3D printing - the iPad Lidar seems to have a _very_ low resolution, so for 3D printing you should wait for some next generations of micro-lidars.

</comment></comment><comment><USER22> I just got one of these and it's very strange to me Apple did not include any apps on the iPad itself that demonstrates the Lidar hardware. They go to all of the trouble of putting it in there, and then when you turn it on and it's as if it doesn't even exist. Why not just include an app that allows me to play with the data stream?

<comment><USER23> A a previous comment called it - chicken and egg situation. But at least we have the chicken, so the eggs will come.

Though for nothing built in to use or avail in any way this tech, sure does seem a bit surprising, though now the HW is there, they will certainly have the software eventually.

The cynic in me says that Apple will wait for some wonder app and then buy or copy it. I say cynic as there have been a few instances of that transpiring previously with Apple - [https://www.telegraph.co.uk/technology/apple/8565673/Apple-a...](https://www.telegraph.co.uk/technology/apple/8565673/Apple- accused-of-ripping-off-students-iPhone-app.html)

<comment><USER22> I mean, the whole reason I bought it was to use it to make neat apps so I guess they figured that's what everyone would do. But even with something like the Kinect, Microsoft provided a suite of apps that at least demoed the apis and allowed you to look at the raw sensor data. Nothing like that is even available on the app store as far as I can tell. Apple even demoed a number of apps using it (some anatomy app, a home scanning app, some AR game with lava), but you can't even download those.

<comment><USER23> Honestly, if there is nowt there atm, then a basic simple knocked up app to show what it can do, even very basic - pop on app store for something like a dollar or less and lap up the sales from those curious like everybody else.

As you have the device and plan on doing app stuff, I'd go for that gold rush.

</comment></comment></comment></comment><comment><USER24> Lidar tech sounds really nice. But as someone how still tries to figure stuff out. Where is the difference of a Time of Flight Sensor and a Lidar sensor? Where are the differences and what are the advantages between these two sensors?

<comment><USER25> Lidar is a time of flight sensor. "Time of flight" is the name for the method in which they time The pulses yo sense depth. In practice, when someone says "time of flight camera", they're referring to a broader class of devices that use similar methods. Lidar usually refers to a specific class of time of flight sensors.

<comment><USER24> Thank you so much. Makes totally sense now.

</comment></comment></comment><comment><USER26> If anyone from Halide is reading this there's a slight typo in the copy:

> This is the first time a new imagining capture technology has appeared on > iPad before iPhone.

I believe that should read "... imaging ..."

<comment><USER15> You can let them know directly: email@example.com

</comment></comment><comment><USER27> If this is using a projected pattern, then it's not lidar -- it's probably a form of projected stereo. I.e. it's not a true time-of-flight measurement.

<comment><USER28> This is a laser based ToF sensor, not pattern projection.

<comment><USER27> My mistake. Thanks for the clarification.

</comment></comment></comment><comment><USER29> Nice article. Reading about Lidar's capability when paired with a mobile device makes Google Pixel's AR sensing seem obsolete overnight.

</comment><comment><USER30> ... the name LIDAR is a play on RADAR, but instead of using dangerous RAdio waves, it uses infrared light. hmmm...

<comment><USER31> For people downvoting this, this is actually a quote from the article. I'm honestly curious if this was serious, or a joke that went over my head.

</comment></comment><comment><USER19> I've had a play around with the new ipad. The big problem is (as far as I can see), absolutely no way for a developer to get access to the underlying depth data.

I'm assuming it's coming in the next version of iOS, because you _can_ get access to the faceid depth data in a useful format.

<comment><USER32> Is it not available through 'AVCaptureDepthDataOutput`? My understanding is that depth data is a separate channel stored in photos.

<comment><USER19> Maybe I screwed it up, I'm not the best developer ever. I took their sample code to extract the depth data from front camera and this worked - <USER2> to .back caused it to return a nil device, so didn't really know where to go after that.

</comment></comment></comment><comment><USER33> Unfortunately for someone like me who's not enthusiastic about photography at all and takes maybe a dozen photos a year, every time I buy a new iPhone or in this case an iPad Pro I feel like I'm wasting hundreds of bucks on a camera I'm not really gonna take advantage of.

<comment><USER34> They could delete the camera and related sensors and it would not appreciably affect the price of the tablet. The camera is probably something like 5 bucks in quantity, and I doubt the "LIDAR" sensor is particularly expensive either.

<comment><USER35> Actually that's not true -- some quick searching reveals iPhone cameras cost $30-50, generally about 10% of the total BOM. Which means that for a ~$1,000 tablet, it would be ~$900 if it didn't have cameras.

So it's not doubling it or anything... but it's not nothing.

(On the other hand, the vastly lower-quality webcam cameras built into Macbooks are probably closer to the $5 you're suggesting.)

<comment><USER36> The iPad cameras in this article are significantly lower-quality than iPhone cameras, other than the LiDAR sensor. So it's definitely cheaper than the larger sensors and optics in new iPhones.</comment></comment></comment></comment>


Google Body Browser - <AUTHOR> http://googlesystem.blogspot.com/2010/12/google-body-browser.html

<comment><USER2> This submission has ended up with the love:

<http://news.ycombinator.com/item?id=2012707></comment>


What I Look for In Tech Startups - <AUTHOR> http://blog.capitalandgrowth.org/chris-devore/ <comment><USER2> _G &G: A hotly debated question in the tech investor community is, "What is the single most important factor for startup success?" Some say it's the team. Some say it's the product/market fit. Others say it's timing. Obviously, all three are important, but if picked one single factor, which would it be?

Chris: I'd say opportunity is the most important. I often meet talented entrepreneurs who put an incredible amount of time and effort into solving problems that ultimately lack real market opportunity.

It's a waste of their talents. I'd roll back on the team that's doing something unproductive because it's an awesome team. I will bet on an exceptional team if they're doing something productive. By that hierarchy, the opportunity is first, people the second._

I've heard this from quite a few VCs. The difference between a good and great engineer is 10x. The difference between a good and bad market is 100x.

<comment><USER3> There are a lot more great teams than billion dollar ideas. I wrote an essay on this topic a few years ago [0].

0\. [https://www.tillett.info/2015/12/18/execution-is-just-the- mu...](https://www.tillett.info/2015/12/18/execution-is-just-the-multiplier- of-ideas/)

<comment><USER4> Ideas are always priced in hindsight - you can't say it is a billion dollar idea until a business is built around it. For all practical purposes there are no billion dollar ideas, just billion dollar business.

<comment><USER3> Yes, of course an idea is only a billion dollar idea once it is built out, but a good team is also only determined in hindsight too.

More importantly, while some ideas have the potential to be billion dollar ideas, most don't. The ideas that have a reasonable chance of being billion dollar ideas are very rare, much rarer than teams that have the same potential.

</comment></comment></comment></comment><comment><USER5> Not to sound like an asshole but we've read this type of "interviews with VCs" at least weekly lately...and they ALL say the same stuff over and over. Its all "great founders", "great market", "great team" dreamy stories.

<comment><USER6> Unfortunately I agree. I strongly suspect investors exhibit survivor bias, and assume causation where there is none. That's not to say it's all luck, or that they're dumb. Instead I feel they're simply unconsciously expert: they don't actually know what makes them good at what they do. Asking them how they do it elicits guesses. The fact that the guesses all sound the same suggests that either they're true, or there's an echo-chamber.

There was a link posted here some months ago where an investor gave a frank account of how hard it is to invest, and how frequently he made terrible decisions and got burned, how time consuming it was, and so on. I think he actually said "don't become an investor if you want to make money, do it because you want to help people". Shame I can't find it now.

<comment><USER7> This reminds of the story Stevie Yeggie wrote about teaching a Chicken to play the piano.

He had the chicken peck at the piano, and everytime it hit the correct key, someone would give it pellet. By this method, the chicken could memorize how to play a simple melody. But, one day, the chicken introduced a random foot kick along with a correct key peck. The pellet still needed to be given to the chicken to reinforce the melody. Ever since then, the chicken kept pecking at the keys with a foot kick.

</comment></comment></comment><comment><USER8> > Everybody focuses on patents and the tech, yet tech matters less and less.

Then why is he talking about what he looks for in _Tech Startups?_ It doesn't seem that he's looking for _Tech_ Startups at all. Plenty of other kinds of startups than tech startups.

<comment><USER9> Tech, as used by investors no longer really means technology. It means a website essentially.

It would rarely (in my experience) even encompass hardware. Certainly nothing requiring novel basic technology (science based startups).

I don't know why terminology is used like this. Essentially it's like saying mail order catalogs are technology companies because they take advantage of advances in printing, telecommunications etc.

I guess it's because the process of building websites is still messy, and somewhat easy to get wrong.

<comment><USER8> He definitely used the word _patents_. So I really think he means new technology when he says tech rather than websites, deployment, logistics, ....

<comment><USER9> Well, he uses the word patents in a context which suggests he doesn't care much about patents...

The examples cited in the article are mostly websites. And I think (given the title of the article) he would describe himself as a tech investor.

In any case, what investors say isn't as important as what they do. In my experience they often say they are interested in Biotech, Science based startups, or hardware. The reality is they rarely invest, and when they do, they invest in very conversative plays (aside from the occasional misguided Theranos type play).

The reality is in general tech to then means "some kind of website where I understand the engagement metrics" most of the time.

</comment></comment></comment></comment><comment><USER10> Sorry inappropriate deleted.

<comment><USER11> Please don't post like this to HN. It just repeats the repetitive, which is most of what we're trying to avoid here.

Edit: you've unfortunately posted a lot of unsubstantive comments to Hacker News. Would you please just not do that? We're hoping for either civil, substantive comments, or no comments.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)</comment></comment>


Humble Bundle Python Dev Kit - <AUTHOR> https://www.humblebundle.com/software/python-dev-kit-bundle <comment><USER2> Would probably have considered it if you got a 12month subscription to pycharm. Otherwise you don't get their "perpetual fallback license"</comment>


Browser Plug-In Punches a Hole in China's Great Firewall - <AUTHOR> http://www.technologyreview.com/news/543711/browser-plug-in-punches-an-unfixable-hole-in-chinas-great-firewall/ <comment><USER2> Prediction: if this does take off and become a serious problem for the Chinese government, they will approach the CDNs and force them to implement blocking or get filtered. A few may take an ideological stand, but most CDNs will comply, as if they don't, their customers who need to reach China will simply switch to those that do. If they don't care about the Chinese market and refuse, they'll simply get blocked.

Of course the more likely scenario is that this simply doesn't catch on in the first place, or not to a significant enough degree that it requires a response.

</comment><comment><USER3> > Censors tend to leave content delivery networks alone because their servers > host many different sites, most of which they don't want to block, says > Houmansadr.

That has changed since last year. Many CDNs are now indeed blocked, or at least interfered with by the GFW within China.

</comment><comment><USER4> No, this would only make things worse. A lot of major websites used Google's services, but Google was nevertheless blocked.

</comment><comment><USER5> Aside from CDNs being blocked, some regions' network conections to foreign servers (like VPS for proxies) are slowed down a lot recently.

</comment><comment><USER6> I'm surprised the article doesn't mention `meek`, which is a pluggable transport for Tor which also takes advantage of the way CDNs work in order to circumvent censorship.

Clients take advantage of domain fronting, where they send a request to "google.com" with a Host header pointing to a Google App Engine instance which is a Tor bridge: [http://www.icir.org/vern/papers/meek- PETS-2015.pdf](http://www.icir.org/vern/papers/meek-PETS-2015.pdf)

<comment><USER7> Section 7.1.1 in the CacheBrowser paper references the paper you linked.

</comment></comment><comment><USER8> Are there any steganographic content sites running now? One could probably run HTML/images only sites purely through steganographically disguised data on imgur, tumblr, Facebook, and others. (Images would be lowered resolution, and involve the combination of 2 or 3 images.) A secret browser extension would be needed for recombination. This browser extension could come in multiple variants, in such a way that it would be hard for one agency to know all of the content channels.

</comment><comment><USER9> > The core idea of CacheBrowser is to grab censored content cached by Content > Delivery Networks such as Akamai and CloudFlare directly from their CDN edge > servers…

Isn't this what websites do in the first place? They put their assets on CDNs, so that it can be delivered faster.

What about dynamic pages? CDNs cover static assets, but the dynamic pages have to be generated on the origin servers.

</comment><comment><USER7> Link to original paper: [https://people.cs.umass.edu/~amir/papers/CacheBrowser.pdf](https://people.cs.umass.edu/~amir/papers/CacheBrowser.pdf)

</comment><comment><USER10> i fail to see how that's useful except for sites that _have_ a CDN cache. And also, couldn't the firewall block those paths to the CDN cache directly (seeing as they do deep packet inspection) just as easily?

<comment><USER7> "i fail to see how that's useful except for sites that _have_ a CDN cache."

It doesn't.

"And also, couldn't the firewall block those paths to the CDN cache directly (seeing as they do deep packet inspection) just as easily"

The paper addresses this: make an HTTPS connection to the CDN's edge server, and make a request. The GFW doesn't know the URI, so doesn't know whether you are accessing forbidden or legit content.

</comment></comment><comment><USER11> Oh I get it, "If you try to kill me, you'll have to kill your friends first, or just let me in, your choice."

</comment><comment><USER12> The GFW started to take off when I was in college somewhere in Beijing, China. In almost two decades, not a single tech trick can survive and grow to a meaningful scale. One technology might work for either limited case or very limited audience, or just get blocked completely.

Technology can't fix politics.

</comment><comment><USER13> Maybe so but I would argue that censored google is not the same google we know.

[http://www.traininginsholinganallur.in/oracle-training-in- ch...](http://www.traininginsholinganallur.in/oracle-training-in-chennai.html)

</comment><comment><USER14> I remember Houmansadr for his papers on steganography over Tor. Glad to see he's scratching his itch.

</comment><comment><USER15> See: collateral freedom</comment>


Foxconn is confusing the hell out of Wisconsin - <AUTHOR> https://www.theverge.com/2019/4/10/18296793/foxconn-wisconsin-location-factory-innovation-centers-technology-hub-no-news <comment><USER2> Here's a rule of thumb I've come up with: whenever a politician or industry lobbyist says that some policy will create/destroy X jobs, divide X by 100 to get the real number. You'd be amazed how consistently accurate it is.

</comment><comment><USER3> With a name like Foxconn what could possibly go wrong. If I were the FBI I would start looking into what was actually going on behind the scenes and the politicians involved. This seems much deeper than merely waffling on stuff. Also this is not China, it's Taiwan.

</comment><comment><USER4> Utterly hilarious ... come on Wisconsin ... cheese yes but AI ???.

<comment><USER5> Not just AI but AI 8K + 5G!

<comment><USER6> Wondering why they didn't throw "quantum" in there too</comment></comment></comment>


New Airless Bike Tires That Will Never Get Flat - <AUTHOR> http://www.boredpanda.com/airless-flat-free-tire-bike-nexo/?_t=1&_f=featured <comment><USER2> Unfortunately the "science behind" video doesn't give much information about why this solution is better to other flat-free tires. [https://www.youtube.com/watch?v=bm8P6UYrTCs](https://www.youtube.com/watch?v=bm8P6UYrTCs)

This has been tried many times before, and it appears the difference in approach here is to have stability plugs along the center of the rim which the tire attaches too.

The thing is, is this really a problem people are currently having? I've been running tubeless on my mountain bike for years with a latex filler inside and haven't had a flat in ages. On my road bike, I run armadillo tires and same thing. I'm actually thinking of replacing the tube in my road tire just because I'm sure it is degrading as it hasn't been replaced in at least 3 years.

</comment><comment><USER3> Yet another Kickstarter link, AKA "Thing That Doesn't Actually Exist®". I really wish people would stop posting links to Kickstarter projects under headlines which make it sound like an actual product, rather than a TTDAE®. It's little better than clickbait —and just as annoying</comment>


One Dev's First Thoughts on BitBucket's CD Tool: Pipelines - <AUTHOR> https://www.cuttlesoft.com/bitbucket-pipelines-first-impression/ <comment><USER2> Scott announced at Summit that it is free for the rest of the year then 1/c a minute thereafter.</comment>